一个人干所有事 = 自己写代码、自己 review 自己的 PR、凌晨三点推到生产。任何一个工程经理都知道这为什么失败。
Boris Cherny（Claude Code 作者）用三人 Agent 架构替代了它：每人一个专属 system prompt，一个共享工作空间，一个文件目录做通信。从想法到上线，你做监督者，不做瓶颈。
三个 Agent 各自的角色
Agent 1 — Writer
唯一任务：实现功能和修复。
写干净可读的代码，遵循代码库现有模式。不重构没被要求改的代码。不写测试——那不是它的活。不 review 自己的成果——另一个 agent 负责。
Writer 的核心特质是快，不停笔，写完就过。
Agent 2 — Reviewer
唯一任务：找问题。
仔细读每一个 diff，检查 Bug、边界情况、安全问题。不自己修——只报告。给出具体行号、问题是什么、为什么重要。
如果代码通过了审查，批准它。不要 nitpick。
Reviewer 没有批准的动机。它的 job 是找问题。这是从"自己 review 自己"变成"有第二双眼睛"的关键差异。
Agent 3 — Deployer
唯一任务：把经过批准的代码发到生产。
只部署明确被 Reviewer 批准的代码。部署前跑完整测试套件，任何测试失败就停止。
创建部署总结：什么变了、测了什么、部署了什么。
有任何不对劲，不部署，报告问题。
Deployer 是三个 agent 里最保守的。它不写代码，不 review 代码，只发 Reviewer 批准通过的东西。
完整工作流
你给 Writer 一个任务 → Writer 实现 → Reviewer 读 diff，找问题或批准 → 如果被拒，反馈传回 Writer 重做 → 一旦批准，Deployer 跑测试并发版。
真正强大的地方在于用 loops 自动化这个循环。设置一个每 5 分钟跑一次的 cron：
- 检查 Writer 是否完成了任务
- 把 diff 交给 Reviewer
- 如果批准，交给 Deployer
- 如果被拒，把反馈传回 Writer
Agent 之间通过共享目录里的文件通信。每个人读和写特定文件夹，不需要人在中间。
具体配置
- 模型：三个 agent 全部用 Opus 4.7
- 模式：Auto 模式，不希望每次文件读取都要点批准
- Effort：Reviewer 用 X-high，Writer 和 Deployer 用 High
- 分离 claude-md 文件：每个 agent 有自己的项目文件夹和规则手册，agent 之间不共享
三周之后的变化
第一周：Writer 实现速度比你自己写还快。Reviewer 抓到了你可能会漏的东西。Deployer 跑测试比你更守纪律。
第二周：加上更多 agent。一个写测试，另一个更新文档。架构可以扩展，因为每个 agent 都是独立的。
第三周：你不再把 Claude 当工具，开始把它当团队。你变成管理者，agent 负责执行。
核心洞察
当 Reviewer 的激励被正确设置（它的 job 是找问题，不是批准），第二双眼睛才真正有效。
自己 review 自己的代码，无论人工还是 AI，都会漏掉同样的东西。分离关注点，把"执行"和"验证"分给不同的 agent，才是把聊天机器人变成团队的那个设计。
三人 Agent 团队，三份 claude-md 文件，一个 pipeline。从想法到生产，你做 manager，不做工程师。