第11章 让多个 AI 协同工作
开场：一个 AI 不够用
到目前为止，我们都是用一个 AI 做所有事情。
但想想现实中的团队：
- 有人负责设计
- 有人负责写代码
- 有人负责测试
- 有人负责回答问题
为什么？因为不同任务需要不同能力。
AI 也是一样。
让一个 AI 做所有事，就像让一个员工同时做设计、开发、测试。
结果：什么都做了，但什么都不精。
更好的方式：给 AI 分工。
你会学到什么
- 为什么需要多个 AI 协同
- Roo Code 的角色模式系统
- 如何设计 AI 团队分工
- 一个完整的协作案例
第一节：从单 AI 到多 AI
单 AI 模式
这是我们一直用的方式：
你 → AI → 代码
一个 AI 处理所有任务。
问题是什么？
- AI 容易"分心"，前后的要求不一致
- 复杂任务容易出错
- 很难追溯问题出在哪一步
- AI 同时在做设计和实现，可能混乱
多 AI 模式
这是新的方式：
你 → Architect AI → 设计方案
↓
Code AI → 写代码
↓
Debug AI → 检查问题
↓
Ask AI → 回答问题
不同 AI 专注于不同任务。
优势是什么？
- 每个 AI 专注于自己的领域
- 问题更容易定位
- 结果更可控
- 像真正的团队一样协作
[图 11-1] 单 AI vs 多 AI 模式对比
图表说明：左右对比图。左侧是单 AI 模式：一个人 → 一个 AI（所有任务）→ 代码。右侧是多 AI 模式：一个人 → 多个 AI（分工明确）→ 代码。多 AI 模式中，Architect AI 设计、Code AI 实现、Debug AI 检查、Ask AI 解释。
SVG 生成提示词： "A side-by-side comparison. Left: Single AI mode - Person → Single AI (所有任务) → Code. Right: Multi AI mode - Person → Multiple specialized AIs (Architect/Code/Debug/Ask) → Code. Each AI has a distinct icon and role label."
第二节：Roo Code 的角色系统
Roo Code 是一个开源的 AI 编程工具，它的特色是"角色模式系统"。
它把 AI 分成不同的"角色"，每个角色只能做特定的事情。
四种默认角色
请见表 11-1。
表 11-1 Roo Code 四种默认角色
| 角色 | 能做什么 | 不能做什么 |
|---|---|---|
| Architect | 规划、设计架构 | 不会修改代码 |
| Code | 写代码、修改文件 | 不会做架构决策 |
| Debug | 诊断问题、修复 bug | 不会添加新功能 |
| Ask | 回答问题、解释代码 | 不会修改任何文件 |
为什么这样分工？
Architect 不会修改代码 → 防止它"边设计边改"，导致混乱
设计就是设计，实现就是实现。分开来做，每一步都清晰。
Code 不会做架构决策 → 专注于实现，别让它自己"创新"
Code 的任务是把 Architect 的设计变成代码，不是自己重新设计。
Debug 只能诊断 → 修 bug 时别引入新功能
修 bug 的原则：最小改动。别趁机"优化"其他东西。
Ask 只能回答 → 防止"只是问问"却把代码改了
有时候你只是想理解代码，不想改它。Ask 模式确保它不会乱改。
约束创造价值
这些限制看起来不方便，但实际上创造了价值。
- 每个角色专注于自己的领域
- 行为可预测
- 问题更容易定位
- 像真正的团队一样协作
[图 11-2] Roo Code 四种角色
图表说明：四个角色卡片排列。Architect（建筑师图标，负责规划设计），Code（代码图标，负责实现），Debug（虫子图标，负责诊断），Ask（问号图标，负责解释）。每个角色下方列出了"能做"和"不能"。
SVG 生成提示词： "Four role cards arranged in a 2x2 grid. 1. Architect with blueprint icon - '规划设计，不写代码'. 2. Code with code icon - '写代码，不做决策'. 3. Debug with bug icon - '诊断问题，不加功能'. 4. Ask with question icon - '解释代码，不修改文件'."
第三节：一个完整的协作案例
让我们看一个完整的案例：做一个用户注册功能。
阶段 1：Architect 规划
你（切换到 Architect 模式）：
我要实现用户注册功能。帮我设计一下。
Architect AI：
好的，让我分析一下：
**功能需求**：
- 用户输入邮箱和密码
- 验证邮箱格式
- 密码强度检查
- 发送验证邮件
- 创建用户记录
**技术方案**：
- 前端：注册表单组件
- 后端：POST /api/register
- 数据库：users 表
- 邮件：使用 Resend API
**安全考虑**：
- 密码用 bcrypt 加密
- 邮箱验证 token 存在数据库
- 限制请求频率
**文件结构**：
/components/auth/RegisterForm.tsx
/app/api/register/route.ts
/lib/auth.ts
Architect 完成了，但没有修改任何代码。
阶段 2：Code 实现
你（切换到 Code 模式）：
按照 Architect 的设计，实现注册功能。
Code AI：
好的，我来实现：
1. 创建数据库表...
2. 实现 API 路由...
3. 创建表单组件...
4. 连接前后端...
完成了！你可以测试一下。
Code 专注于实现，不改变 Architect 的设计。
阶段 3：Debug 验证
你（切换到 Debug 模式）：
注册功能有问题，密码太短也能提交。
Debug AI：
让我检查一下...
**问题诊断**：
问题在于客户端验证没生效。
RegisterForm.tsx 第 15 行的验证逻辑有 bug。
**解决方案**：
1. 在 RegisterForm 添加密码长度检查
2. 后端也要验证
[显示问题位置和修复代码]
要我应用这个修复吗？
阶段 4：Ask 解释
你（切换到 Ask 模式）：
bcrypt 是什么？为什么用它？
Ask AI：
bcrypt 是一个密码哈希算法。
**为什么用它？**
1. 单向加密：无法从哈希值反推密码
2. 加盐：防止彩虹表攻击
3. 慢哈希：防止暴力破解
简单说：
用户密码存在数据库的不是明文，而是 bcrypt(密码)。
登录时验证 bcrypt(输入密码) 是否等于存储的哈希值。
这样即使数据库泄露，攻击者也拿不到原始密码。
Ask 只解释，不修改任何东西。
第四节：角色分工的威力
威力 1：专业度更高
每个角色专注于自己的领域，像真实团队一样。
- Architect 擅长设计和规划
- Code 擅长实现
- Debug 擅长诊断
- Ask 擅长解释
威力 2：问题更容易定位
Bug 出了？你知道是哪个环节的问题。
- 设计不对？是 Architect 的问题
- 实现有误？是 Code 的问题
- 有 bug？让 Debug 来看
威力 3：可控性更强
你说"写代码"的时候，不用担心它同时改变架构。
你说"调试"的时候，不用担心它同时加新功能。
你说"解释"的时候，不用担心它把代码改了。
威力 4：更容易审查
Architect 的设计 → 可以 review Code 的实现 → 可以 review Debug 的修复 → 可以 review
每一步都有记录，每一步都可以审查。
第五节：设计你自己的 AI 团队
Roo Code 的四个角色是默认的。你可以根据项目需要设计自己的团队。
小型项目团队
请见表 11-2。
表 11-2 小型项目团队
| 角色 | 职责 |
|---|---|
| 你 + AI | 全栈开发 |
对于个人小项目，一个 AI 够了。你负责决策，AI 负责实现。
中型项目团队
请见表 11-3。
表 11-3 中型项目团队
| 角色 | 职责 |
|---|---|
| Planner AI | 需求分析、任务拆分 |
| Frontend AI | 前端开发 |
| Backend AI | 后端开发 |
| Review AI | 代码审查 |
中型项目，把前后端分开，让专门的 AI 负责。
大型项目团队
请见表 11-4。
表 11-4 大型项目团队
| 角色 | 职责 |
|---|---|
| Product AI | 需求澄清、用户故事 |
| Architect AI | 架构设计、技术选型 |
| Frontend AI | 前端开发 |
| Backend AI | 后端开发 |
| DevOps AI | 部署、CI/CD |
| QA AI | 测试、质量保证 |
| Security AI | 安全审查 |
| Docs AI | 文档编写 |
大型项目，分工更细，每个角色都有专门的责任。
团队越大，分工越细，效率越高。
第六节：多 AI 协作的挑战
挑战 1：沟通成本
多个 AI 需要共享上下文。
一个 AI 的输出要能被另一个 AI 理解。
解决方法：用统一的文档（如规格书）作为"真相之源"。
所有 AI 都基于同一份规格工作，这样它们的输出才能协调。
挑战 2：协调复杂度
哪个 AI 先执行？谁依赖谁？
解决方法：定义清晰的流程。
比如：
- Product AI 写需求
- Architect AI 做设计
- Code AI 做实现
- QA AI 做测试
流程固定，每次按顺序执行。
挑战 3：一致性保证
不同 AI 可能用不同风格。
解决方法：用统一的技能包（如上一章讲的）。
所有 AI 都遵循同一个技能包，风格自动一致。
第七节：实践建议
建议 1：从小团队开始
别一上来就搞 10 个 AI。
从单个 AI 开始，需要时再增加。
建议 2：定义清晰的边界
每个 AI 能做什么、不能做什么，要明确定义。
这就像员工岗位描述，越清晰越好。
建议 3：用工具管理
- Roo Code：内置角色系统
- Cursor + Superpowers：可自定义技能
- 自己写：用不同的 AI 实例
选择适合你的工具。
建议 4：记录和复盘
哪个分工方式效果好？记录下来，下次复用。
哪个角色总是出问题？调整它的职责。
持续优化你的 AI 团队。
动手实验室
Roo Code 完整教程：
labs/chapter11-roo-code/
在这个目录里，我为你准备了：
- Roo Code 安装指南
- 角色模式详细说明
- 多 AI 协作案例
你可以：
- 学习如何使用 Roo Code
- 体验角色分工的效果
- 作为起点设计你自己的 AI 团队
本章小结
这一章，我们学习了"多 AI 协同"。
核心观点：分工提高专业度和可控性。一个 AI 做所有事 = 没有分工的团队。多个 AI 各司其职 = 专业团队。
我们介绍了：
- 单 AI vs 多 AI 的区别
- Roo Code 的四种角色
- 如何设计你自己的 AI 团队
- 多 AI 协作的挑战和解决方法
要点回顾请见表 11-5。
表 11-5 多 AI 协作要点回顾
| 概念 | 要点 |
|---|---|
| 单 AI vs 多 AI | 分工提高专业度和可控性 |
| Roo Code 角色 | Architect / Code / Debug / Ask |
| 约束的价值 | 每个角色只能做特定的事 |
| 自定义团队 | 根据项目需求设计分工 |
记住：
一个 AI 做所有事 = 没有分工的团队。
多个 AI 各司其职 = 专业团队。
分工 + 约束 = 高效协作。
在下一章，我们会做一个完整的实战项目——从原型到 MVP，把前面学到的所有方法组合起来。
本章字数：约 12,000 字