多 AI 协助编程开发

一、背景

随着大语言模型（LLM）的快速发展，AI 辅助编程已从"单点工具"演变为"多智能体协作"的工作模式。在实际项目中，我们尝试引入多个 AI 角色——包括架构设计、代码生成、代码审查、测试编写、文档整理等——分工协作，共同完成一个完整的开发流程。

本文对这一实践过程进行小结，记录经验、问题与思考。

二、多 AI 协作的整体架构

2.1 角色划分

2.2 协作流程

需求输入
  │
  ▼
架构 AI ──→ 技术方案 + 接口定义
  │
  ▼
编码 AI ──→ 初始代码
  │
  ▼
审查 AI ──→ 问题反馈 ──→ 编码 AI（修复）
  │
  ▼
测试 AI ──→ 测试用例 ──→ 执行验证
  │
  ▼
文档 AI ──→ 最终文档 + 变更日志
  │
  ▼
交付

核心思路：每个 AI 专注一个环节，上游的输出作为下游的输入，形成流水线。 审查 AI 发现问题后回流给编码 AI 修复，形成闭环。

三、实践中的关键经验

3.1 上下文传递是最大的工程挑战

多 AI 协作最容易出现的问题不是单个 AI 的能力不足，而是上下文在传递过程中丢失或变形。

• 架构 AI 输出的接口定义，编码 AI 可能"理解偏了"，生成的代码与设计意图不一致。
• 审查 AI 指出的问题，编码 AI 修复时可能引入新问题（修 A 坏 B）。

应对策略：

1. 结构化中间产物：架构方案用 JSON / YAML 等结构化格式描述，而非自然语言段落，减少歧义。
2. 显式契约：接口定义以契约文件（如 OpenAPI Spec、Protocol Buffers）为载体传递，而非"口头描述"。
3. 校验关卡：每个环节输出后，由下一个 AI 先做"理解校验"——复述它对输入的理解，确认无偏差后再执行。

3.2 审查 AI 的价值远超预期

最初我们认为审查 AI 只是"锦上添花"，实践中发现它是质量的核心保障：

• 编码 AI 生成的代码"看起来对"是常态——语法正确、逻辑通顺，但存在边界条件遗漏、资源未释放、并发安全隐患等隐性问题。
• 审查 AI 以"挑刺"视角介入，能发现编码 AI 的盲区。
• 审查 AI 的反馈不是简单的"这里有问题"，而是带有具体修改建议和理由，编码 AI 可以直接采纳。

经验：审查 AI 的 prompt 要明确"你是严格的 reviewer，不是鼓励者"，否则它倾向于说"代码整体不错，小建议如下……"——这会漏掉真正的问题。

3.3 测试 AI 与编码 AI 的关系应该是"对抗"而非"配合"

• 如果测试 AI 和编码 AI 用同一套思路生成测试，测试会"顺着代码写"，覆盖不到代码没考虑的路径。
• 理想模式：测试 AI 只看接口定义和需求，不看实现代码，基于"黑盒"视角生成测试用例。这样测试才能真正验证"实现是否符合预期"，而非"实现是否自洽"。

3.4 文档 AI 放在最后，但要"回灌"

• 文档 AI 生成的 API 文档、使用说明，反过来可以作为下一个迭代的输入——开发者（人或 AI）通过文档理解系统现状，避免重复造轮子。
• 变更日志（CHANGELOG）尤其重要：多 AI 协作中改动频繁，没有变更日志就无法追溯"这个改动是哪个 AI 在哪一步做的、为什么"。

四、遇到的问题与反思

4.1 "AI 之间互相迁就"现象

编码 AI 生成了略有偏差的代码，审查 AI 看到了但觉得"差不多也行"就放过了，测试 AI 顺着这个偏差写测试，最后所有人都认为"没问题"——但整体结果偏离了原始需求。

根因：每个 AI 都倾向于"接受上游的输出"，缺乏一个独立于流水线的最终校验者。

解法：在流水线末端增加一个"验收 AI"，它只看原始需求和最终产物，不看中间过程，做端到端的符合性检查。

4.2 成本与延迟

多 AI 流水线意味着多次模型调用，延迟和成本叠加：

• 一个中等复杂度的功能，完整跑一遍流水线（架构→编码→审查→修复→测试→文档）约需 6-10 次调用。
• 实际开发中并非每次都需要全流程——简单改动可以只走"编码→审查"两步。

建议：根据改动规模动态选择流水线深度，而非每次都全跑。

4.3 人的角色不可缺席

多 AI 协作不等于"无人值守"。实践中人在以下环节不可替代：

• 需求拆解：AI 对模糊需求的理解容易跑偏，人需要把需求明确化后再交给架构 AI。
• 关键决策：技术选型、架构方向等高影响决策，AI 可以提供方案对比，但拍板权在人。
• 冲突仲裁：审查 AI 和编码 AI 意见不一致时（“这个设计应该改” vs “这个设计有理由保持”），需要人判断。

五、效果评估

做得好的方面

1. 分工明确后，单个 AI 的输出质量提升——专注一个角色时，prompt 更精准，幻觉更少。
2. 审查 + 测试的双重保障，使交付代码的缺陷率明显低于"单 AI 一把梭"模式。
3. 文档自动生成，解决了团队"代码写完但文档不更新"的老问题。

仍需改进的方面

1. 上下文传递的可靠性仍依赖人工检查，缺乏自动化的"契约一致性校验"。
2. 流水线的编排目前靠手动串联，理想状态是有一个 orchestrator 自动调度各 AI 角色。
3. AI 间的"知识对齐"——不同 AI 可能对同一技术栈有不同理解（如一个推荐用 Promise，另一个推荐用 async/await），需要统一技术规范作为约束。