IDEA + JavaAI = 真香！

上个月我需要编写一个相对底层的组件工具，尝试了市面上几款主流的 AI 插件来生成代码。初步冒烟测试没有太大问题，单个原子功能基本都能跑通，但一旦进入全局闭环验收，就暴露了一系列问题：边界条件处理不当、资源管理缺乏合理的约束机制、异常场景下的状态一致性无法保证。排查和修复这些缺陷所花费的心力，远超过自己从零编写的成本。

这些工具生成的代码"能跑"，但距离"能交付"还差得远。单个原子功能没有问题，一旦涉及全局的边界条件和约束处理，就暴露出对项目整体架构理解的缺失。给的是"能运行的片段"，不是"可交付的工程"。

后来朋友安利了飞算 JavaAI 的智能体模式，它一款 IDEA 插件。与其它 AI 插件那种简单描述需求之后，AI 直接粗暴阅读上下文并进行编码落地不同。它采取一种"多专家 Agent 协作"的模式，即"一个问题，一个专家" 分步完成如下五个环节：

• 需求规划
• 接口设计
• 数据库架构
• 业务逻辑
• 源码生成

对应每个环节各有一个专门的 Agent 负责，全程可视化，每一步都可以干预和确认和按需调整，知道每个步骤完全澄清之后，才能继续执行后续步骤。

实战记录

前置准备

在正式演示飞算 Java AI 执行，我们需要进行必要的安装和配置步骤，对应安装步骤如下：

1. 打开 IDEA，点击菜单栏 File → Settings（Mac 系统为 IntelliJ IDEA → Settings）
2. 在左侧导航栏选择 Plugins
3. 点击上方的 Marketplace 标签页
4. 在搜索框中输入"CalEx JavaAI"或"飞算"
5. 找到对应插件后点击 Install，安装完成后重启 IDEA 即可

需求说明

刚好我朋友 sharkchili 有个开源项目叫 mini-redis，用 Go 语言复刻了 Redis 的核心指令。本着研究和学习的需要尝试了解这个项目。考虑到现有架构的复杂性和指令处理的复杂链路。他建议我从 RESP 协议入手，以客户端的视角去了解 Redis 客户端与服务端的通信流程。

于是，我便打算基于 mini-redis 写一个 Java 客户端，也就是 mini-redis-spring-boot-starter。这通过深入到协议层面去处理编解码、连接管理、指令适配，以核心交互视角解读 redis 指令解析和处理过程。

因为这个组件需要涉及复杂的协议解析和连接池管理和指令封装与响应等多个功能，正好拿飞算 JavaAI 试试，查看其是否具备处理这种企业级组件的研发能力。

按照我的个人思路，该组件具体的要求如下：

1. 准确按照 RESP 协议与 mini-redis 进行交互
2. 完全覆盖 mini-redis 现有版本支持的所有指令和参数细节
3. 支持自定义慢查询监控，即针对完整 RT 的读写慢查询监控
4. 支持将慢查询信息持久化，便于即时观测既定时间内客户端与服务端稳定性

上下文准备与需求输入

需求明确之后，先别急着让 AI 写代码，第一步应该是给予足够的上下文信息。于是，我把 mini-redis 中带有项目基本介绍概要信息的 README 文件作为上下文导入飞算 JavaAI：

这份 README 的信息量很大，包含了 mini-redis 所有支持的指令及其参数细节：

同时也完整介绍了 mini-redis 所用的 RESP 协议规范，由此我们在研发初期完成充分的准确工作，飞算 Java AI 就可以基于上下文中明确的协议规范和指令集来执行研发任务。

上下文准备就绪后，我选择了智能引导模式，同时考虑到项目并非简单的 Java web 工程，所以笔者在左下方的场景直接选择了通用场景。随后键入核心的核心需求，并点击右下角的提示词优化按钮，飞算 JavaAI 自动帮我补充了技术细节和约束条件，最终得到完整的需求提示词：

对应这里也给出详细的文本：

开发一个名为 mini-redis-spring-boot-starter 的 Spring Boot 自动配置库。该库提供一个轻量级的 Redis 客户端实现，旨在替代或简化标准的 spring-data-redis 使用场景。核心功能包括：基于 TCP Socket 的原生 RESP 协议通信、高性能连接池管理、灵活的序列化策略（String/JDK/JSON）以及可选的 AOP 慢查询监控与带宽统计功能。

设计阶段

在明确规范需求之后，飞算 Java AI 迅速进入设计阶段。这一步由的功能设计 Agent 接手，让其基于给定上下文信息和需求，自动生成整体架构方案。这也是多专家 Agent 模式的一个体现——不同阶段交由不同的 Agent 独立完成，划定好特定的领域边界，各自专注自己擅长的环节。

稍待片刻后，我们看到了飞算 Java AI 的输出，整体方案让人感到惊喜：

1. 技术选型：它选了 Netty 而不是 JDK 原生的 Socket，说明 AI 理解了这个组件对网络 I/O 性能的要求。
2. 自动配置：按 Spring Boot Starter 的规范完成了，没把业务逻辑和框架集成混在一起
3. 协议封装：RESP 协议的解析被单独抽成了一个模块，和业务逻辑解耦，这个分层是合理的。

不过最让我意外的是它对上下文的理解程度。它很明确地理解了 mini-redis 这个用 Go 语言复刻 Redis 的项目支持哪些指令以及对应的参数细节。比如在设计列表操作模块时，它只暴露了 lpush 和 rpop 这些 mini-redis 实际支持的指令，而没有把 Redis 完整指令集里的 linsert、lrem 等不支持的操作也塞进来。这种"知道什么该写、什么不该写"的克制，说明它确实理解了上下文，而不是在套模板。

代码生成计划

设计方案确认后，进入代码生成阶段。这一步交给了源码生成 Agent。值得说的是，它没有拿到需求就直接开始写代码，而是先给出了一个任务拆解计划：

1. 项目初始化，构建父子模块和自动装配的基调
2. 封装 RESP 协议引擎，基于 Netty 实现。这是整个组件的基石，后续的连接池和指令执行都依赖它
3. 高性能连接池管理，依赖上一步的协议引擎来管理连接的获取与释放
4. 封装可定制消息的序列化模块，作为最上层对开发者暴露的 API

我们再来看看它的构建顺序：先搭项目骨架，再从最底层的协议引擎开始，逐层往上构建。先有基础模块，再在上层组装业务逻辑。说实话，这种"自底向上"的构建顺序，即使是让一个有经验的 Java 工程师来规划，大概率也是这个思路。这说明它确实理解了模块之间的依赖关系，而不是把各个功能当作独立片段随便拼的。这一点让我对它后面生成的代码多了一份信心。

代码生成与 Review

计划确认后，点击生成源码，源码生成 Agent 开始逐模块落地代码。整个过程就是多专家 Agent 模式的实际运作：前面需求 Agent 帮我把需求理清，设计 Agent 把架构定好，到这一步源码生成 Agent 直接基于前面确认的方案写代码，因为每一步都做了需求澄清和方案确认，我几乎不需要做任何调整，全程跟着它的设计思路点下一步就行：

等了几分钟，拿到了一份完整且可运行的代码。这里以最核心的指令处理器 MiniRedisTemplate 为例，它准确地结合设计文档完成了所有指令的封装，整体无论是语义还是逻辑判断都处理得不错。

仔细看了一下生成的代码，有两个细节值得单独拿出来说：

1. 为了避免开发者对 Redis 的过期参数（EX/PX）和条件参数（NX/XX）混淆，它把 NX 语义封装为了 setIfAbsent。这个命名和 Java 并发包里 ConcurrentHashMap.putIfAbsent 的风格一致，对 Java 开发者来说很自然
2. 像 Redisson 这些企业级框架一样，它为每条指令都提供了同步和异步两种调用方式，并且在方法层次上做了抽象，让同步方法复用异步方法的逻辑，避免了重复代码

再来看看底层连接池的管理，对应方法名为 getConnection。它用 JDK 的 Semaphore 统一管理池化连接，Semaphore 的数值直接绑定配置的最大连接数。获取连接时优先从空闲池中复用，没有可用的才新创建。针对并发获取阶段还设了 5 秒超时阈值，避免长时间阻塞。

最关键的部分，也是我最关心的——RESP 协议的编码和解码逻辑。因为底层选用了 Netty，所以我直接定位到了飞算生成的 ChannelOutboundHandlerAdapter 编码器。它准确地按照 RESP 协议的规律来处理：

1. * 指定数组长度
2. $ 指定后续字符串长度，再用 \r\n 拼接实际内容

说得可能有些抽象，我结合近期用 Wireshark 抓包的 scan 指令来举例说明。通过 scan 0 输出 Redis 所有元素，对应结果为：

1) "0"
2) 1) "user:1"
   2) "user:2"

按照 RESP 协议规范，这是一个长度为 2 的数组：数组 1 是数字 0，数组 2 又是一个数组，元素分别是 user:1 和 user:2，对应格式为：

*2\r\n # 输出数组长度为2

$1\r\n # 数组1是一个长度为1的字符串"0"
0\r\n

*2\r\n # 数组2是一个数组，用*指定数组长度

$6\r\n # 长度为6的字符串user:1
user:1\r\n
$6\r\n # 长度为6的字符串user:2
user:2\r\n

对应的抓包结果也印证了这一点：

明确了 RESP 协议规范之后，再来看飞算 JavaAI 的输出。它在 ChannelOutboundHandlerAdapter 编码器上完成了数据流输出端的通用编码工作，把协议规范准确地转化为了代码逻辑。说实话，如果 AI 只是套模板，不可能把 RESP 这种二进制协议的编解码写得这么准确——这种底层协议的封装能力，恰恰是"工程代码"和"片段代码"的分水岭。

验收微调

整体来看，方案的基调和输出结果都让我比较满意。不过我对连接池控制的粒度要求更细，希望 getConnection 这一块可以更灵活一些，于是我给出了一段提示词让飞算 JavaAI 进行调整：

最终输出的结果遵循度很高，既保证了复用性，又保留了脚手架使用的灵活性。这也是多专家 Agent 模式的好处——每个 Agent 负责的环节都可以单独介入调整，不用推翻重来。

单元测试验证

代码生成完毕后，还需要验证功能是否正确，于是，按照官方文档的说法，我找到的 AI 工具箱，打算通过单元测试生成器进行验收工作：

考虑到指令操作是所有逻辑的核心入口，所以我将 MiniRedisTemplate 直接注入，然后点击运行：

此时单元测试 Agent 在进行详细的环境检查之后，开始生成对应的测试代码，从生成用例过程中不难看出，它很好的分析的方法之间依赖和所有功能的输入，然后针对每个指令的正常情况、边界情况、异常情况进行详细的覆盖，由此可见飞算 AI 在职责拆解和 Agent 设计的独到之处：

随后我们得到的详尽的单元测试代码，我以常规的 set 和 get 指令来验证逻辑闭环：

运行结果如下，写入和读取的字符串完全一致，指令的封装和发送逻辑验证通过：

回顾整个过程：需求 Agent 梳理需求、功能设计 Agent 规划架构、源码生成 Agent 落地代码，最后还有测试验证 Agent 全链路覆盖验收，我几乎没有做任何手动调整。这就是"一个问题，一个专家"的协作方式带来的效率——每个环节各司其职，开发者只需在各个流程进行轻度决策

小结

经过本次与飞算 Java AI 的全流程协作来看，其多 Agent 模式确实交付出了满意的答卷。它不是让一个 AI 简单阅读上下之后一口气生成代码再循环修复代码，而是"一个问题，一个专家"：需求规划、功能设计、代码生成、单元测试，每个环节由专门的 Agent 负责，每一步都可以 Review 和调整。五个 Agent 各司其职、协同推进，全程可视化、可干预，最终输出的不再是需要开发者收拾烂摊子的"半成品"，而是经过逐步确认、可以真正交付的工程代码。

当然，这并不是说 AI 生成的代码可以直接上生产不做 Review。任何 AI 生成的代码都应该经过人工审查，但至少，飞算 JavaAI 降低了我审查的复杂，解放我的生产力。