我让 5 个 AI 同时帮我写代码，然后发现了一个所有人都忽略的问题

人工智能, 实践

让多个 AI Coding Agent 并行开发一个项目，失败 4 次后总结出一套基于文档和 Git worktree 的协作方法论 ADD，把软件工程的管理实践搬到 AI Agent 身上。

上周我做了一件事：开 5 个终端窗口，每个窗口里跑一个 AI Coding Agent，让它们同时给我写一个全栈项目的不同模块。

后端 API、数据库逻辑、前端页面、组件库、集成测试——5 个 Agent 各干各的，并行推进。

3 天后，项目跑通了。 一个完整的全栈应用，带前后端、带数据库、带 AI 功能，从零到闭环验证通过。

但我要告诉你的不是这个结果。我要告诉你的是，在到达这个结果之前，我失败了 4 次。

AI 写代码很强，但没人告诉你多个 AI 怎么协作

2026 年了，AI 写代码已经不是新闻。Claude、Codex、Gemini，随便哪个都能帮你从零搭一个项目。

但你有没有试过让多个 AI 同时帮你做一个项目？

我试了。然后我发现了一个所有人都忽略的问题：

AI 的编码能力已经很强了，但它们的协作能力几乎为零。

一个优秀的人类开发者会主动了解同事在做什么，发现接口变了会及时沟通，遇到不确定的设计决策会找人讨论。

AI Agent 不会做以上任何一件事。

它只管低头写自己的代码。写完了跟你说”做完了”。至于隔壁那个 Agent 改了什么、会不会和它冲突——它完全不知道，也不关心。

我的 4 次失败

第 1 次：让一个 AI 做所有事

最直觉的方式。一个 Claude session，前端后端全包。

结果：聊了 30 分钟后，它忘了最开始约定的 API 格式。前端调后端，接口对不上。改来改去，越改越乱。

教训：一个 Agent 的上下文窗口是硬瓶颈。

第 2 次：让 AI 调用 AI

我想，既然一个不够，那就让 Claude 作为”老板”，自动调用 Codex 来干活。

装了插件，写了调用链。结果：插件不稳定，调用链一环出问题整体就断，调试比自己写代码还累。

教训：Agent 之间的实时调用链太脆弱了。

第 3 次：多开窗口，各写各的

好，那我自己来协调。开 3 个 Agent 窗口，一个写后端 API，一个写数据库，一个写前端。

结果：后端 Agent 改了返回格式，前端 Agent 不知道，写了一堆对不上的代码。两个后端 Agent 同时改了同一个文件，合并时冲突。Agent 做完了只说”做完了”，没有任何文档，我不知道它到底做了什么。

教训：没有规范的多 Agent 并行，比单 Agent 更混乱。

第 4 次：用了一个很火的 Skill

社区里有人做了一个号称”让 AI 像真正的软件工程师一样工作”的 Skill。我试了。

结果：它破坏了 Claude 的对话流程，整个 session 崩了，只能重开。

教训：稳定性 > 花哨的功能。

第 5 次，我换了一个思路

前 4 次失败让我意识到一件事：这不是一个技术问题，这是一个管理问题。

我不需要更好的 API，不需要更智能的调度器，不需要什么 Agent-to-Agent 通信协议。

我需要的是一套管理规范——就像人类团队需要 Scrum 一样，AI Agent 团队也需要自己的协作流程。

然后我做了三件极其简单的事：

1. 让 Claude 当项目经理，而不是程序员

我不再让 Claude 写代码。我让它管人。

它的工作变成了：理解我的需求 → 拆成独立任务 → 为每个任务写清楚的指令和验收标准 → 审查其他 Agent 交上来的代码 → 决定能不能合并。

就像一个真正的 Tech Lead。

2. 每个 Agent 在独立的沙箱里工作

用 Git 的 worktree 功能，给每个 Agent 一个独立的工作目录和分支。物理隔离，想冲突都冲突不了。

3. 所有沟通通过文档

不用 API，不用消息队列，不用任何中间件。

Agent 之间的全部通信就是两种 Markdown 文件：

  • 任务文档（Leader → Worker）：你要做什么、做到什么标准
  • 交付文档（Worker → Leader）：我做了什么、测试结果如何、有什么问题

就这么简单。

结果

用这套方法，我跑通了一个完整的开发周期：

  • 1 个 Leader Agent（Claude）负责规划和审查
  • 3 个 Worker Agent（Codex）并行写代码——2 个后端、1 个前端
  • 0 次文件冲突（因为 Git worktree 物理隔离）
  • 每个 Worker 完成后都有结构化的交付报告（Leader 审查效率极高）
  • 最终产出是可长期维护的代码（不是一次性 demo）

关键数据：前后端并行开发，总耗时取决于最慢的那个任务，而不是所有任务的总和。

我把它做成了一个 Claude Code Skill

我把这套方法论封装成了一个 Skill，叫 ADD（Agent-Driven Development）。

安装后，你的 Claude Code 会自动变成 Leader Agent。你只需要说”帮我拆解任务，我准备开 3 个 Agent 来并行开发”，它就会：

  1. 帮你创建项目上下文文档
  2. 把你的需求拆成可并行的独立任务
  3. 为每个 Worker 生成启动指令（你复制粘贴到新窗口就行）
  4. Worker 做完后帮你审查代码
  5. 审查通过后给你合并命令

你不需要写任何代码来管理 Agent。你只需要一套文档。

为什么这个方法有效

说白了，这套方法就是把软件工程的管理实践搬到了 AI Agent 身上：

人类团队的做法 ADD 的做法
用会议同步信息 用文档同步信息
用分支和 PR 隔离工作 用 Git worktree 隔离 Agent
Code Review 后才合并 Leader Agent 审查后才合并
新人入职要读文档 新 Agent session 启动要读 CONTEXT.md
做完写周报 做完写 DELIVERY.md

不需要发明新技术，只需要正确地组合已有工具。

7 条原则

如果你想自己实践，记住这 7 条：

  1. 文档优先于 API — Agent 之间用 Markdown 通信，最简单所以最稳定
  2. 物理隔离优先于逻辑隔离 — 不要依赖 Agent 的”自律”，用 Git worktree 给它们建围墙
  3. 审查门禁不可省略 — Agent 不能当自己的裁判
  4. 上下文按需加载 — 给 Agent 刚好够用的信息，不要把 100 页文档全塞给它
  5. 结构化模板 > 自由格式 — 固定模板减少 Agent 犯错的空间
  6. UI 设计前置 — 不要让 Agent 自由发挥 UI，先对齐期望再写代码
  7. 强制工作日志 — 每个 Agent 做完都要写报告，不写报告的 Agent 不是好 Agent

最后

AI Coding Agent 已经很强了。但”一个强大的 Agent”和”一个能高效协作的 Agent 团队”之间，还差着一个管理层。

ADD 就是那个管理层。

它不酷，不花哨，没有什么颠覆性的技术创新。但它管用。

如果你也在尝试让多个 AI Agent 一起做一个正经项目，而不只是写 demo，欢迎试试。

GitHub：agent-driven-dev（Skill + 完整方法论文档 + 实战案例）

*作者：喻承龙 2026 年 5 月*

标签： AI Agent, Claude Code, 多 Agent 协作, Agent-Driven Development, 软件工程, 开发工具

评论

评论系统尚未配置。

*** End of File

评论

评论系统尚未配置。