用四个 AI 编码会话组一支开发小队：tech lead、两名 dev 和一名 reviewer

作者把四个编码 agent 拆成 tech lead、Dev 1、Dev 2 和 Reviewer，你只跟 tech lead 对话，由它派活、收 review、合并。文章给出可直接复制的启动 prompt、git worktree 隔离方式，以及几条踩坑后总结的规则：一次只跑一个重任务、review 只报关键问题、离开前把决策攒成清单。

角色分工与唯一沟通入口

• 四个会话：tech lead 负责把你的需求拆成任务、给 dev 写 brief、收 review 结果、合并代码；两名 dev 一次只做一个任务，各自在自己的分支和 git worktree 里干活；reviewer 只审代码不写代码。
• 最关键的一条规则：你只跟 tech lead 说话。它是唯一知道所有会话在干什么的地方，绕过它提的需求没人跟踪。
• 四个会话都由你自己在同一个仓库里开，并手动命名 Tech lead、Dev 1、Dev 2、Reviewer。不命名的话会话会拿第一条消息当名字，队友就找不到它了。
• 项目自身的规则（怎么跑测试、代码风格）放在各 agent 会自动读取的文件里：Claude Code 用 CLAUDE.md，Codex 用 AGENTS.md，Gemini CLI 用 GEMINI.md。

用 git worktree 隔离两个开发者

• 给每个 dev 单独开 worktree，避免两个 agent 同时改同一批文件：git worktree add -b dev-1 ../myapp-dev-1，dev-2 同理。
• 作者提到 Moontors 这个桌面工具可以在建会话时一并指定标题、agent 和新建 worktree，四个会话直接排在同一个看板上。
• dev 和 reviewer 开局先待命，等 tech lead 发来介绍消息后才开始工作。

一条 prompt 启动整支队伍

• 你只给 tech lead 发一条长 prompt，里面写清：团队有哪几个会话（按标题指认）、各自角色、一个任务从 brief 到合并的四步流程、以及硬性规则。
• 任务流程：tech lead 给 dev 写 brief（做什么、为什么、从哪个 commit 开始、可能碰哪些文件、哪些已经定了）→ dev 在分支上实现并跑相关检查，交回分支和改动说明 → reviewer 只报用户会碰到的 bug、安全漏洞、重复逻辑、缺失的测试或文档 → 一轮修复后由 tech lead 合并。
• 规则里包括：先读项目文档，冲突时以文档为准；没有你点头不许 push、开 PR 或往仓库外发东西；同一台机器一次只跑一个重任务（全量测试、端到端、构建）；流程不要超过任务本身需要。
• prompt 末尾让 tech lead 先读项目，再分别给三个会话发介绍，最后向你汇报项目现状和第一个要派的任务。

prompt 里每条规则的理由

• brief 必须自包含：dev 会话除了 tech lead 写下的内容一无所知，只说「修一下登录 bug」只能得到猜测，写清文件、原因和已定方案才能拿到正确的修复。
• review 要限定范围：让 reviewer 什么都报，它会返回二十条风格意见，把真正的那一个 bug 埋掉。
• 修复只做一轮、由 tech lead 拍板：不设上限，dev 和 reviewer 能互相来回改一整夜。
• 一次只跑一个重任务：四个 agent 同时跑全量测试会让每次运行都变慢，还会出现莫名其妙的失败，轮流跑反而更快。

让队伍持续运转的几条经验

• 离开前明确告知：agent 最贵的状态是等你拍板。告诉 tech lead 你要去睡了，让它继续做不需要你的工作，把需要你决定的事连同建议列成清单，回来一次性给你。
• 按标题而不是 id 寻址：在 Claude Code 里要列出运行中的 agent 拿 id 转交，会话一重启（一次 IDE 更新就够）id 就变，得重新登记；按标题寻址的会话名单能扛住重启。注意消息在接收方自己的权限模式下执行，所以每个会话的权限模式要按「你允许任何队友向它提什么要求」来设。
• 不同角色可以用不同模型：比如 tech lead 和 dev 用 Claude Code，reviewer 用 Codex，没写过这份代码的模型更容易发现作者共同的盲区。
• 瓶颈在哪就加哪：dev 排队就加 Dev 3（新开 worktree 后让 tech lead 发介绍），reviewer 排队就加第二个 reviewer，比加第三个 dev 有用。
• 团队外的 agent（比如写文案和发布说明的 marketing agent）直接对你负责，介绍给团队时明确它不属于团队、不能给团队派活。