AI 编程进阶：需求拆分、并行开发、自动测试与独立代码审查

上一篇《用 AI Agent 完成一个真实开发任务：从需求分析到代码审查》发布后，不少读者问了一个更进一步的问题：

一个 Agent 已经能写代码了，如果同时启动多个 Agent，分别负责后端、前端、测试和审查，开发效率是不是还能翻几倍？

答案是：有可能更快，但绝不是 Agent 越多越快。

如果没有清晰的接口契约、文件边界和验收标准，四个 Agent 很可能只是同时制造四份冲突。真正有效的多 Agent 协作，更像一个人带领一支分工明确的小型开发队伍。

本文不讲抽象概念，而是用一个常见的全栈需求，完整演示如何组织多 Agent 协作：

在用户列表增加“账号状态”筛选，支持全部、正常、禁用三种状态；前后端同时改造，保持旧接口兼容，并完成自动化验证与独立代码审查。

文中的项目结构、字段名和命令都是通用示例，实际使用时请以自己项目的源码、接口和构建工具为准。

一、为什么单 Agent 容易在真实项目里失控？

单 Agent 完成小改动通常很顺手，但任务一旦横跨前端、接口、业务逻辑、数据库和测试，三个问题就会逐渐暴露。

1. 上下文越来越混乱

它先读需求，再查数据库字段，然后修改接口，又切换到前端页面，最后还要回头审查自己的代码。信息越多，早期约束越容易被后续内容冲淡。

2. 自己很难真正审查自己

写代码时形成的错误假设，往往也会被带进审查阶段。例如它一开始误以为状态字段叫 status，后面检查代码时仍可能沿用这个假设。

3. 本可并行的工作被串行执行

接口契约明确后，前后端可以同时开发；后端完成后，测试和审查也可以从不同角度并行验证。单 Agent 却只能一个环节接一个环节地处理。

多 Agent 的价值，不是复制四个“全能程序员”，而是把不同职责的上下文隔离开。

二、第一原则：不是让所有 Agent 修改所有文件

多 Agent 协作最危险的做法，是把同一份需求发给四个 Agent，然后告诉它们“各自完成任务”。

这样会直接产生几个问题：

• 多个 Agent 同时修改相同文件；
• 前端和后端各自猜测接口参数；
• 测试 Agent 为了通过验证，擅自修改生产代码；
• 审查 Agent 顺手重构，反而引入新的变更；
• 最后没有人能说清哪些结论已经验证。

正确方式是设置一个主 Agent 负责调度，其他 Agent 只拥有明确的工作范围。

这里的“拥有”并不是组织架构上的职位，而是本次任务的文件修改权。

角色	文件或职责范围	输入	必须输出	禁止事项
主 Agent	需求拆分、契约、汇总与冲突决策	原始需求、项目结构	子任务、接口契约、最终交付报告	在边界未明确前要求全面开工
后端 Agent	Controller、Service、Mapper、后端测试	已冻结的接口契约	后端代码与改动说明	修改前端页面
前端 Agent	页面、请求参数、类型定义	已冻结的接口契约	前端代码与交互说明	猜测或修改后端字段
测试 Agent	编译、单测、接口回归	前后端交付结果	实际命令、结果、失败证据	删除测试或改业务代码换取通过
审查 Agent	当前变更和相关调用链	代码差异、需求、测试证据	按严重程度排列的问题	只给“看起来没问题”的结论

最重要的一条规则是：每个生产文件同一时间只能有一个明确的修改者。

三、开工前先冻结四类事实

不要拿到需求就立刻写代码。主 Agent 应先完成一次只读调查，把以下事实查清楚。

1. 数据字段与枚举

例如数据库里真实字段究竟是 account_status、user_status 还是 enabled？“正常”和“禁用”对应 1/0、字符串还是枚举？

这类事实必须来自实体、数据库映射或现有代码，不能凭经验猜。

2. 当前接口契约

假设现有接口为：

GET /api/users?pageNum=1&pageSize=20&keyword=张三

新需求增加可选参数：

GET /api/users?pageNum=1&pageSize=20&keyword=张三&accountStatus=ENABLED

为了保持兼容，未传 accountStatus 时必须仍然查询全部状态，而不是默认只查正常用户。

3. 参数传递链路

需要确认参数经过哪些层：

页面筛选项
  → API 请求参数
  → Controller
  → Service
  → Mapper
  → SQL 条件

只修改链路的一部分，页面看起来可以选择状态，但后端可能根本没有收到参数。

4. 可执行的验收标准

不要只写“功能正常”，而要写成可判断的条件：

• 不传状态时，结果与旧接口一致；
• 传 ENABLED 时，只返回正常账号；
• 传 DISABLED 时，只返回禁用账号；
• 清空筛选后恢复全部数据；
• 翻页、关键字与状态条件可以组合使用；
• 非法状态值按项目既有规则处理；
• 前后端至少完成对应的编译或测试验证。

四、正确的执行时序

多 Agent 不等于所有任务从第一秒同时启动。只有不互相猜测、输入已经稳定的工作，才适合并行。

推荐顺序如下：

1. 主 Agent 调查现有实现，确认真实字段和调用链路；
2. 主 Agent 输出并冻结接口契约与验收标准；
3. 后端 Agent 和前端 Agent 根据同一契约并行开发；
4. 测试 Agent 执行编译、单测和关键回归；
5. 审查 Agent 独立检查兼容性、边界条件和代码差异；
6. 主 Agent 汇总证据、处理冲突，并给出人工验收清单。

注意：测试 Agent 可以提前阅读验收标准、设计测试用例，但应该等可运行的代码形成后再执行验证。审查 Agent 也不应参与最初实现，否则“独立审查”会退化成自我确认。

五、四类 Agent 的提示词可以直接这样写

后端 Agent

你负责本需求的后端实现。

目标：用户列表新增可选参数 accountStatus，支持 ENABLED、DISABLED；不传时保持旧接口行为。

你的修改范围：用户列表对应的 Controller、Service、Mapper 和后端测试。
禁止修改：前端页面、前端请求封装以及无关模块。

开始前请先核对实体字段、枚举值、Mapper 参数位置和现有查询条件。
完成后报告：
1. 修改了哪些文件；
2. 参数如何传到 SQL；
3. 如何保证旧接口兼容；
4. 执行了哪些验证，实际结果是什么；
5. 仍未验证的风险。

你不是独自在仓库中工作，不要覆盖或回退其他人的改动。

前端 Agent

你负责本需求的前端实现。

接口契约：请求参数 accountStatus 可不传，可选值为 ENABLED、DISABLED；清空筛选时不得发送空字符串冒充有效值。

你的修改范围：用户列表页面、请求参数和相关类型定义。
禁止修改：后端代码和无关页面。

请实现“全部/正常/禁用”筛选，切换条件时回到第一页，并确认关键字、分页与状态能够组合。
完成后报告修改文件、交互行为、请求示例及尚未验证的内容。

你不是独自在仓库中工作，不要覆盖或回退其他人的改动。

测试 Agent

你只负责验证，不修改生产代码。

根据验收标准执行风险匹配的检查：相关模块编译、已有单测、新增测试和关键接口回归。
必须记录实际执行的命令、退出结果和关键输出。

若失败，请区分：
- 本次代码缺陷；
- 项目原有失败；
- 环境或依赖问题。

禁止删除测试、放宽断言或修改业务代码来制造“通过”。

审查 Agent

你负责独立审查当前需求产生的代码差异，不负责润色或大规模重构。

重点检查：
1. 未传新参数时是否保持旧行为；
2. 前后端枚举和参数名是否一致；
3. 动态 SQL 是否在正确位置生效；
4. 空值、非法值、分页和组合查询是否存在问题；
5. 测试证据是否真的覆盖主要风险。

发现问题时必须给出文件位置、触发条件、影响和修改建议，并按严重程度排序。
没有证据时不要使用“应该没问题”作为结论。

六、测试结果不能只写“已验证”

AI 最容易制造的一种错觉，是把“我认为能通过”写成“已验证通过”。因此最终报告必须把事实分成三类。

已执行并通过

例如：

后端用户模块测试：已执行，通过，12 个用例全部成功。
前端类型检查：已执行，通过，无类型错误。

已执行但失败

前端完整构建：已执行，失败。
原因：构建环境无法下载某依赖，与本次变更文件无直接关系。

失败并不可怕，隐藏失败才危险。应保留关键报错，并说明它是否阻断本次功能判断。

尚未验证

真实浏览器中的筛选交互：未验证，需要人工登录测试环境检查。
生产数据库执行计划：未验证，需要在接近生产数据量的环境确认。

“未验证”不是一句推卸责任的话，而是在划清自动化结论的边界。

七、最常见的六种翻车方式

1. 多个 Agent 修改同一个文件

解决方法：在分派任务时写清文件所有权。若确实需要接力修改，由主 Agent 明确交接顺序。

2. 前后端各自定义接口

解决方法：先冻结参数名、可选值、空值语义和错误处理，再开始并行实现。

3. Agent 在错误的项目副本中工作

解决方法：提示词中写入准确工作目录；交付时报告实际路径和变更文件，主 Agent 再统一核对。

4. 测试 Agent 为了通过而改代码

解决方法：测试 Agent 默认只读生产代码。发现缺陷后返回证据，由对应实现 Agent 修复。

5. 审查只有结论，没有证据

解决方法：每个问题必须包含文件位置、触发条件和影响。纯风格建议不要冒充功能缺陷。

6. 主 Agent 只收集总结，不检查冲突

解决方法：最终交付前统一检查代码差异、接口契约、测试结果和未验证项。子 Agent 的总结只能作为线索，不能替代证据。

八、出现意见冲突时，谁来决定？

例如后端 Agent 认为空字符串应当等同于“全部”，审查 Agent 却认为空字符串应该报参数错误。这不是靠“少数服从多数”解决的。

主 Agent 应按以下顺序决策：

1. 项目现有接口规范；
2. 已冻结的需求与接口契约；
3. 相邻接口的既有行为；
4. 兼容性和实际风险；
5. 如果仍无法判断，再交给人做产品或架构决策。

AI Agent 可以提供分析，但不能凭投票创造业务规则。

九、怎样判断多 Agent 到底有没有提效？

不要只比较“开始到结束用了几分钟”，更不要因为同时开了四个窗口就断言效率提升四倍。建议连续记录几次类似任务的以下指标：

• 从需求确认到可验收版本的总耗时；
• 人工补充上下文和纠正方向的次数；
• 文件冲突及重复修改次数；
• 测试阶段发现并返工的问题数；
• 审查后仍遗漏到人工验收的问题数；
• 最终需要人工阅读和确认的范围。

如果并行开发节省的时间，小于协调、冲突和返工增加的时间，多 Agent 就没有带来实际收益。

十、哪些任务不适合多 Agent？

以下情况通常一个 Agent 更省事：

• 只改一个配置项或一个简单函数；
• 所有步骤都强依赖前一步，无法并行；
• 需求本身还没有确定；
• 项目很小，完整上下文一次就能读完；
• 多人修改同一核心文件无法安全拆分；
• 验收标准只能依赖尚未明确的主观判断。

多 Agent 最适合的是：任务可拆分、边界可描述、子任务能独立产出证据，而且合并成本可控。

十一、一份可复用的主 Agent 编排提示词

你是本次开发任务的主 Agent，负责调查、拆分、协调和最终交付。

请按以下顺序工作：
1. 只读调查现有实现，确认真实字段、接口、调用链路和项目约束；
2. 输出接口契约、验收标准、风险点和子任务依赖；
3. 按文件所有权分派后端、前端、测试和审查任务；
4. 只有输入稳定且文件不重叠的任务才能并行；
5. 要求每个 Agent 报告实际改动、实际验证结果和未验证项；
6. 汇总前检查代码差异，解决接口与文件冲突；
7. 测试 Agent 只验证，审查 Agent 只审查，不允许通过越权修改制造成功；
8. 最终输出：需求完成情况、变更文件、验证证据、遗留风险和人工验收清单。

任何 Agent 都不能用“应该可以”“看起来正常”替代实际验证。
如果业务规则无法从需求和源码中确定，请明确标记并请求人工决策，不要自行编造。

十二、写在最后

多 Agent 编程真正提升的，不只是代码生成速度，而是把一个复杂任务拆成若干条可独立验证的责任链。

主 Agent 负责边界和决策，后端与前端负责实现，测试负责提供运行证据，审查负责挑战已有假设。它们最终交付的不是几段“完成了”的文字，而应该是一份可以被人复核的代码、测试和风险说明。

所以，多 Agent 协作最重要的公式并不是：

4 个 Agent = 4 倍效率

而是：

清晰边界 × 稳定契约 × 独立验证，才可能带来真正的并行效率。

如果职责混乱，Agent 越多，返工越快；如果边界清楚，一个人也能指挥出一支可靠的 AI 开发小队。

---

如果你觉得这篇进阶实践有帮助，欢迎收藏。下一篇可以继续实战：如何让 AI Agent 自动定位线上 Bug，并在不扩大改动范围的前提下完成修复与回归验证。