用四个编码智能体组织开发与审查

一个 AI 写代码，像结对编程；四个 AI 分工合作，就能成为一支开发团队吗？作者给出的配置是：一个 Tech lead、两个开发者、一个 Reviewer，人类负责方向和关键决策，日常任务统一经过 Tech lead 流转。

这套方案真正值得看的，是它如何处理上下文、代码隔离、审查和等待。作者提供了可复制的启动提示词，但没有给出效率对照数据。读它更适合拿走一套协作规则，再判断自己的项目是否需要四个会话。

四个角色能协作，靠的是一个任务入口

作者要求用户亲自打开四个会话，放在同一个仓库中，分别命名为 Tech lead、Dev 1、Dev 2、Reviewer。用户只和 Tech lead 沟通，由它拆任务、分配开发者、安排审查、合并代码并汇报进展。

这套组织方式的关键，是让任务状态集中在一个入口。

如果用户绕过 Tech lead，直接让 Dev 1 顺手改个功能，负责统筹的会话就不知道这件事，也无法判断它是否影响其他任务。这里的 Tech lead 更像任务调度员：谁在做什么、依赖谁、卡在哪里，都需要它掌握。

角色权限也划得很清楚。只有 Tech lead 能修改 main；开发者在各自分支提交；Reviewer 只审查，不写代码；人类保留优先级和关键决策权。推送、创建 PR、向仓库之外发布内容，都需要用户明确许可。

作者还要求用户亲自创建会话，而不是交给 Tech lead 代开，目的是让每个工作现场都能被用户看见。项目级约定则放在各工具会读取的文件中：Claude Code 对应 CLAUDE.md，Codex 对应 AGENTS.md，Gemini CLI 对应 GEMINI.md。

这里要区分两类信息：项目规则应该长期留在仓库里，具体任务则由 Tech lead 单独交代。没必要每次派活，都重新讲一遍整个项目。

并行开发之前，先把代码和上下文隔开

两个开发者同时工作，先要解决的不是模型能力，而是工作目录冲突。作者为每个开发者分配独立的 git worktree：

git worktree add -b dev-1 ../myapp-dev-1
git worktree add -b dev-2 ../myapp-dev-2

注意每行的 -b 和最后一个路径：它们分别指定新分支与工作目录，让两个开发会话拥有独立的工作现场。

但 worktree 只能隔离编辑过程。两个分支仍可能改到同一模块，最后合并时照样需要处理冲突。因此，Tech lead 派任务时还要写明：做什么、为什么做、从哪个 commit 开始、可能涉及哪些文件，以及哪些方案已经确定。

作者强调，开发会话并不会自动拥有 Tech lead 的上下文。「修一下登录问题」只够让它猜；如果交代相关文件、已知原因和已确定的处理方式，任务才有可靠边界。

并行会话越多，任务说明越需要自洽。

开发者完成后，要交回分支、行为变化和实际执行过的检查。Reviewer 再检查用户会遇到的 bug、安全缺口、重复逻辑，以及缺失的测试或文档，不纠缠细枝末节的风格问题。

作者规定只进行一轮修复：Tech lead 决定审查意见如何处理，开发者修改，Reviewer 只复查这些修改，然后合并。它想解决的是开发者与审查者来回争论、任务迟迟无法结束的问题。

另一个约束很实用：同一台机器一次只跑一个重型任务，包括完整测试套件、端到端测试和构建。开发可以并行，昂贵的验证需要排队。作者称同时运行会拖慢所有任务，还可能造成无关失败，但没有提供耗时、机器配置或失败率数据。

真正拖住团队的，可能是消息和等待

作者使用的 Moontors 支持按会话标题互发消息。Tech lead 给其他三个会话发送介绍，就能让它们知道团队成员、自己的职责、任务流程和汇报对象。

这个前提不能省略。原文提示词假定会话能按标题找到彼此，而且消息发送后不阻塞，回复会稍后作为新消息到达。换一个环境，必须先说明通信方式，单独复制角色提示词并不会自动建立消息通道。

作者提到，在 Claude Code 的相关操作中，运行中的 agent 通过 id 寻址；会话重启后 id 会变化，需要重新查找并告知 Tech lead。Moontors 则用标题维持寻址。原文也提醒，收到的消息会按接收会话自己的权限模式执行，因此每个会话的权限都要分别设置。

人类离开也是阻塞来源。作者建议睡前给 Tech lead 留下这段指令：

I'm going to sleep now. Until I'm back, don't wait for me: keep the team on work that doesn't
need me, put every decision that does on a list with your recommendation, and give me the list
when I'm back.

要看的是 work that doesn't need me：继续推进不依赖用户决策的工作，把需要用户判断的事项连同建议集中记录，并没有授权它自行决定所有事情。

扩容同样看等待发生在哪里。开发任务积压，就增加带独立 worktree 的 Dev 3；审查任务积压，就增加 Reviewer。作者还允许不同角色使用不同工具，例如 Tech lead 和开发者用 Claude Code，Reviewer 用 Codex，试图借不同模型减少共同盲点。

开发团队之外也可以有 Marketing 会话，直接接受用户指令。它向 Tech lead 查询产品事实，但不能给开发团队派活；Tech lead 同样不能从它那里接任务。这是在防止另一条沟通链绕过原有调度入口。

我的判断

我认可这套方案对职责、任务交接和权限的划分。尤其是独立 worktree、完整任务说明、审查范围和重型检查排队，都对应着具体的协作问题，适合拿来检查现有 AI 编程流程。

但「四个会话就是一个小团队」仍是组织比喻。作者说这些规则来自使用经验，却没有给出任务规模、完成时间、返工率、模型费用，也没有与单会话开发做对照。跨模型审查能发现共同盲点，同样是合理判断，原文没有量化验证。

单会话的优势是上下文集中、交接少。若只是改一个组件或修一个局部问题，四个角色之间传递信息的成本可能更高。任务能够独立拆分、验证方式明确时，并行开发才更有发挥空间。

「一轮修复后合并」也需要保留判断余地。它可以限制风格争论，却不应成为带着未解决安全问题或关键缺陷合并的理由。流程轮数不能代替验收标准。

另外，作者就是 Moontors 的开发者，文章同时承担产品介绍。原文称它是支持 macOS、Windows、Linux 的免费桌面应用，可并排运行 Claude Code、Codex、Gemini CLI。按标题通信是它提供的便利；角色分工和任务交接规则，则可以脱离这个产品使用。

能拿来做什么

• 给下一次 AI 编程任务补齐交接信息：起始 commit、目标行为、涉及文件、已定方案和验收方式。即使只用一个开发会话，这份说明也能帮助后续审查。
• 当前端页面与 Node 接口确实能独立推进时，再分给两个带独立 worktree 的开发会话，并提前约定接口。不要仅凭文件位于不同目录，就认定任务没有依赖。
• 把审查要求收敛到真实缺陷、安全、重复逻辑和必要测试，并要求开发者说明实际跑过什么检查。完整测试、端到端测试和构建按机器资源排队执行。
• 离开前明确哪些工作可以继续、哪些决策必须等你；先按作者建议试运行一天，观察任务主要等开发、等审查，还是等人，再调整角色数量。