并行开发之书

如何让多个 AI Agent 并行推进而质量不崩塌

这本书是什么

这是一本给已经在单线程使用 Cursor / Claude Code / Codex 等 Agent 的工程师写的实操指南，目标是帮你迈出下一步：在真实项目里同时跑多个 Agent，而产出质量不会在压力下崩塌。

这本书的论点其实很简单：

并行 AI 开发不是"同时开更多 Agent"，而是把人从那三个必须人类深度参与的卡点里抽出来——做到这一点以后，再开更多 Agent 才有意义。

这三个卡点分别是 需求对齐、正确性验证 和 可维护性。书里每个卡点各有一章对应，另外还有一章专门讲一个几乎所有人都忽略的前提——磨合期——也就是你和你的工作流要一起演化的那段时间。

本书结构

第一部分——前提：建立主论点。AI 开发的瓶颈已经从"敲代码"转移到了三个你依然被卡住的地方。只要这三个地方还是由你亲自守着，加再多 Agent 也只是让队伍变长。

第二部分——磨合期：描述每个人在并行 AI 开发真正回报之前必经的那条四阶段学习曲线。绕过或否认这个阶段，是"并行 AI 是炒作"这类结论最常见的来源。

第三部分——三把钥匙：每个卡点一章，讲怎么用机制替代人的实时介入：结构化的需求对齐、测试计划驱动开发 + 按复杂度分层审核、把工程纪律编码为 skill。

第四部分——并行手册：执行层。廉价失败的经济学相变、四种调度模式（从跨项目到 Agent 内部），以及下一个会出现的瓶颈——并行产出本身——如何再用同样的思路（让 Agent 分诊 Agent）解决它。

第五部分——坦白：书的最后一部分说实话。你不会变得更轻松，你只会更累。产出翻倍，认知负担持平甚至上升。最后一章把整个框架推广到代码之外——任何可以拆成独立子任务的脑力劳动都适用。

参考：引用目录 列出了书中引用的先驱实践、产品文档，以及 zero-review/* 配套 skill。

阅读路径

  • "我怀疑并行 AI 开发到底值不值得做" → 第 1 章 → 第 9 章（一气读完开头的论点和结尾的坦白，再决定）
  • "我同时开过两个 Agent，一团乱" → 第 2 章（你处在磨合第一阶段，这是正常的）
  • "一个 Agent 跑得不错了，想扩到三个" → 第 3、4、5 章，然后第 7 章
  • "三个 Agent 在跑，但我消化不过来产出" → 第 8 章
  • "想看底层经济学" → 第 6 章

元原则

并行 AI 工作流不是一个你安装上去的配置。它是一种从你、你的代码库和你的 Agent 几个月的相互适应中长出来的实践。这本书描述这种实践的形状。它没法替你把路走完。

Atum 著 — 源代码：github.com/A7um/ParallelDevelopmentBook

第 1 章：瓶颈只是转移，不会消失

论点：并行 AI 开发不是"开更多 Agent"。它是把人从那三个单个 Agent 也依然需要你守着的卡点里抽出来——在你做到这一点之前，加更多 Agent 只会让队伍变长。

每个人都在讲的故事

到了 2025 年底，"AI 能替你写代码"这件事已经不再是推测。Cursor、Claude Code、Codex、Devin 之类的工具，已经从"补全"跨过了"自主执行任务"这条线。任何在写这本书时工作过的工程师，都亲自体验过这种切换：你描述一个功能，Agent 写出来、跑测试、修 bug、开 PR。一个 Agent、一个任务、一个审查者——你。

接下来显而易见的问题是：如果同时开五个呢？

显而易见的答案——"那你就快五倍"——是错的。真正动手试过的人，基本都在第一周撞墙，然后悄悄退回到一个。他们其实发现了某件事但叫不出名字：AI 开发里真正的瓶颈从来不是 Agent。是你自己。

看一个内部数据。Boris Cherny——Anthropic 的 Claude Code 负责人——在 2025 年底在 X 上分享：他同时运行 10 到 15 个 Claude Code session，分散在编了号的终端标签页、web session 和手机上，一个月内合入 259 个 PR（全部代码都是 Agent 写的）。他的配置没什么魔法：编号 1–5 的终端标签、在 Agent 需要输入时弹出的系统通知、一个每当 Agent 犯一次可以避免的错误就追加一条的 CLAUDE.md 规则文件、以及像 /commit-push-pr 这样把重复性注意力打包起来的 slash 命令。看仔细就会发现那个形状：他并没有把人从回路里移除——他把人以前卡住的那些地方用机制替代了，所以他唯一的一份注意力可以在十到十五条工作流之间轮转而不再成为瓶颈。这本书讲的就是那次轮转背后的机制。

三个卡点

观察一个工程师和一个 Agent 一起工作，你会发现三个时刻反复出现——这几个时刻只有人能推动事情继续：

  1. 需求对齐。 你脑子里的东西是模糊的、带着隐含上下文的、在边缘处从未拍板过的。Agent 需要清晰、可执行的指令。填平中间的鸿沟意味着对话、澄清、反复。它啃掉的是你最深层的那份注意力。

  2. 正确性验证。 Agent 写出来的东西看起来对。真的对吗？现实里总得有人读 diff、跑一遍、抓出模型自己不会发现的 bug、把修正喂回去。过去，那个人就是你。

  3. 可维护性。 一个 Agent 放任不管，能写出今天能跑、三个月后崩塌的代码。得有人在架构层面掌舵——哪个模块、哪一层、什么模式——否则代码库就会变成一件百衲衣，以后不管是人还是 Agent 都在里面干不了活。

这三件事有一个共同的结构特征：它们都需要人类在回路中。而人的注意力是串行的。你没法把它摊到五个 Agent 上，你只能在它们之间一个一个切换。这三个卡点还由你亲自守着，你就算同时开五个 Agent，也得不到 5 倍的吞吐；你得到的是五个队列排在同一个人面前。

大多数人会得出"并行 AI 没用"的结论，原因不是 Agent 本身差，而是那三个卡点还站着人，多开 Agent 只是多开了几条队列。

示意图：多个 Agent 的产出汇入同一个人，这个人串行地守住需求对齐、正确性验证、可维护性三道门

这是本书最重要的第一个框架：瓶颈只是转移，不会消失。 光加 Agent 不能让 AI 开发变快。你得把人从那个队列形成的位置上挪走。

为什么这在以前做不到

2025 年大部分时间，对"AI 能不能接管这三个卡点"的诚实回答是"不能"。Agent 的自主调试能力还不足以保证正确性，也无法可靠地执行架构纪律，更没法驱动终端或浏览器去验证它自己的产出。

所以唯一可行的模式就是 copilot ——人开车，AI 副驾。Cursor 早期真正厉害的地方，是把这种协作打磨得很顺滑：一个更好的方向盘，而不是一辆自动驾驶车。Spec-first 类工具在需求侧努力，各种 code review 包装层在正确性侧努力；它们都在造更好的驾驶舱，没有把飞行员挪走。

在那个阶段，多开 Agent 机械上做得到，实际上没用。五个 copilot 还是需要一个 pilot。队列始终在你身上。

什么变了

在 2025 年下半年——可以叫它"Opus 4.5 / Claude Code / GPT-5 / Codex 这一波"——四个能力跃迁同时落地，让这笔账变了：

  1. 自主调试真正跑起来了。 给现代 Agent 一个 shell、日志、一个测试框架，它就能诊断并修掉日常开发里绝大多数 bug，不再需要人类指着栈帧说"这里"。

  2. "理解对 ≈ 实现对"变成了近似成立的。 对范围清晰的任务，如果 Agent 真的理解了需求、又有跑测试的能力，它产出的代码大概率是正确的。主要的失败模式不再是"代码写错了"，而是"对需求的理解走偏了"。

  3. Skill 成了稳定的注入机制。 你可以把"这个项目的命名规范、分层、提交规范"之类的工程纪律写进一个结构化的文档交给 Agent，它会按这个约束去做。以前 Agent 在一个 session 里会漂；现在漂是可控的。

  4. 通用电脑使用能力成熟了。 Agent 不再被困在文件树里。它能跑终端、驱动浏览器、点 GUI 完成配置任务、读为人写的文档。软件的安装文档正在悄悄重写成"给 Agent 看的"。

这四件事单拆出来都不够。合在一起就意味着：三个卡点终于可以被机制替代了——不是完美地、也不是普遍地，但足以让你在大多数任务上把人从实时回路里挪走。

这里要提前点一句，后面第 2 章会展开：即使模型具备了上述能力，你的配置也不会在第一天就自动获得这些能力。这中间的缝隙就是磨合期，跳过它是"读到这些能力介绍却在自己的工作里感受不到"的主要原因。

三把钥匙

如果说三个卡点是挡住并行开发的原因，那本书剩下的部分就是怎么把它们拆掉。结构是对称的：

  • 第 3 章 — 钥匙 #1 — 怎么把需求交得足够干净，让 Agent 在执行途中不再需要你。
  • 第 4 章 — 钥匙 #2 — 怎么把正确性当作一份在编码开始前就签好的契约，这样你就不用每份 diff 都读。
  • 第 5 章 — 钥匙 #3 — 怎么把你原本要在审查里执行的那套工程纪律，编码成 Agent 自己应用的 skill。

每一把钥匙做的事都一样：把"人在实时回路里"换成"人在起点和终点，机制在中间"。整个把戏就在这里。

示意图：三把钥匙（对齐、契约、纪律）分别对应并消解三个卡点

把 Cherny 公开的工作流拆开，他做的正是这件事：CLAUDE.md 是第 3 把钥匙的动态实现——把过去在审查里执行的项目规则变成不断增长的文档；slash 命令是在执行边界上把对齐和交接机制化；编号标签 + 通知只是"把注意力在各个中间环节之间轮转"的人体工学外壳。Geoffrey Huntley 公开记录的 Ralph Wiggum 循环 则是同一个动作的另一种形态：一个 bash 循环（while :; do cat PROMPT.md | claude-code ; done）每次用全新的上下文窗口去跑一个 PROMPT.md 加一个 specs/ 目录，测试作为反向压力——人只负责写 spec 和 prompt，中间一概没有。2026 年社区已经把这种模式固化成 Plan Mode 和 Spec-Driven Development（见第 3 章），这是更成熟的形态。早在 2025 年 2 月，Harper Reed 那份广泛传播的 三阶段 LLM codegen workflow 就是这个共识公认的祖先——它的 prompt 今天仍然在用，但按 2026 年标准，那套 pattern 没有显式的验收标准和接口契约，是不完整的。

三位独立的先驱、三种不同美学、一个结构性主张：在边界上用可持久的文档替代人的实时在场，中间就变得可以安全并行化。

一旦这三把钥匙到位，第 6 章和第 7 章就接着讲执行层——到底怎么调度多个 Agent，以及那个经济学的相变（廉价失败）如何让 best-of-N 变成默认动作。第 8 章讲执行并行之后重新冒出来的瓶颈：产出本身。第 9 章用别人不愿说的坦白收尾——这不会让你变得更轻松。

一句话总结

如果本章你只能记一件事：

只有在把自己从那三个实时卡点里移出来之后，再加 Agent 才会放大吞吐。做到这一点，就是后面四章的任务。

其它一切——调度模式、best-of-N、worktree、subagent——都是建立在这个地基上的机械装置。地基不稳，机械救不了你。

外部声音

  • 支持 — "code is not the bottleneck"：Claude Code 的创建者 Boris Cherny 把这句话当成他公开定位的旗帜；见 Boris Cherny: "code is not the bottleneck" 以及 Lenny's Newsletter 的访谈 Head of Claude Code: What happens after coding is solved。他自己的工作流——据报道同时跑 15+ 个 Claude Code session 加结构化人工监督（Educative 整理）——就是"把人从三个卡点里挪出去"的一个活样本。
  • 反驳 — 诚实的事故清单：Harper Foley 的 Ten AI Agents Destroyed Production. Zero Postmortems. 列了一堆事故：2025 年 7 月一个 Replit Agent 删掉生产库并伪造 4000 条假记录，2026 年 2 月一个 Claude Code Agent 在生产环境跑了 terraform destroy，2025 年 12 月一个 Cursor IDE Agent 在明确写着"不要运行任何东西"的情况下删了 70 个被 git 跟踪的文件。每一条都和本章的框架一致：机制还没建立的时候，人就从实时回路里退出来了。这些事故不是在反驳本章的论点——它们是在预言：如果你跳过机制化，会发生什么。
  • 反驳 — 是阶梯还是跳水：Marc Nuri 的 The Missing Levels of AI-Assisted Development: From Agent Chaos to Orchestration 是"加 Agent 感觉像跳水而不是爬楼"这个现象最漂亮的表述。第 2 章会把它当作磨合的第一阶段来处理，而不是当作"梯子不存在"的论据。

下一章

第 2 章描述磨合期：每个团队在并行 AI 开发真正回报之前必经的那条学习曲线，以及你会在其中认出自己的那四个阶段。

第 2 章：磨合——AI 协作的隐形学费

论点：本书的一切只在你和你的工作流相互适应之后才成立。多数得出"并行 AI 是炒作"的人，其实是卡在了一条四阶段曲线的第一阶段，不知道后面还有三个阶段。

什么叫"磨合"

把一双新皮靴穿上，第一周是磨脚的。一台新发动机要先低速跑一千英里才敢把转速拉到红区。招一个资深工程师进来，一般要三个月才能看出他真实水平。这三件事里，工具和环境都在相互适应——工具在适应任务，环境在摸清工具真正的边界。

AI Agent 工作流就是同一回事。你不是"安装"并行开发，你是磨合进它。磨合期留下来的结晶——你写的 skill、你打磨过的 prompt 模板、你练出的任务拆分习惯、你学到的回避套路——就是后面第 3、4、5 章那三把钥匙真正兑现回报的前提。没有这些结晶，那几章的机制就只是纸面上的字。

这也是多数 AI 开发书跳过的一章，因为它不好卖。大家都在写目的地，几乎没人写路。

四个阶段

磨合不是"平滑地变好"那种意义上的渐进。它有形状。四个阶段，每个阶段都有自己独有的体验，也都有表明你走出了这个阶段的信号。

示意图：磨合四阶段——混沌、觉察、模板化、杠杆

第一阶段：混沌

感觉上：你读了这本书或类似的东西，你一次性开了三个 Agent。一小时内，其中两个改动了重叠的文件，一个对需求的解读和你想的不一样，你手上有三个都需要大量返工的 PR。到了下班，你比自己写代码还累，产出还更差。

这时大多数人会下的结论：并行 AI 就是炒作，跑不通的。

为什么他们错了：这场灾难的每一步都可以预见。你没有搭好那个能让三个 Agent 保持一致的共享上下文底座（skill、AGENTS.md、架构约定）。你没有写能在早期抓住解读漂移的测试计划。你没有挑那种本来就不会撞车的正交任务。这不是工作流的错——是你在用第四阶段的工作流做第一阶段的事。

离开第一阶段的信号：你开始识别失败的类别，而不是一个一个 bug。"哦——又来了，Agent 又在明明已有工具函数的情况下自己发明一个。"一旦你能给一种失败模式命名，你就能为它写一条 skill。

第二阶段：觉察

感觉上：你大部分时间还在一次一个 Agent。但你不再对每个错误单点应对了。你开始注意到 Agent 总是在某一类地方犯同样的错，或者在某种架构选择上总是猜同一个方向，或者总是漏掉某一类边界情况。你的 AGENTS.md 开始长出来。你写了第一条真正的 skill——大概率是覆盖某一类在第一阶段坑过你的错误。

Mitchell Hashimoto 的 My AI Adoption Journey 是这段转变最清楚的公开记录。他描述前一段时期是"痛苦难熬的"和"一段效率低下的时期"——把转机归因于打磨自己的 harness：写 AGENTS.md 编码约束、用确定性的钩子阻止重复发生的错误，甚至刻意先手动做一遍再让 Agent 做，以此建立授权所需要的专业判断力。他对过渡的描述（"Agent 在架构任务、高性能数据结构、语言特异性很强的逻辑上失败，逼我手动重写或者跟它搏斗"）是教科书式的第一阶段报告。他的解法是教科书式的第二阶段动作。

这时工作的形态是：敲代码的时间在减少，写规则的时间在增加。你感觉自己"工程做得少了"，这种感觉让你别扭，但代码质量开始往上爬。

离开第二阶段的信号：你开始把同一条 skill 不做改动地复用到新任务上。某一天你在一个新功能里调用两周前写的那条 skill，它一次就跑通——你就已经迈出了第二阶段。

第三阶段：模板化

感觉上：你有了一份管用的 playbook。需求对齐有了你熟悉的形状。测试计划的结构大体相似。真的要审代码时，你检查的是那几件 skill 应该已经覆盖到的事。你现在经常同时跑两个 Agent——任务是你刻意挑的，因为它们不会撞车。

这时工作的形态是：新 skill 还在写，但速率在下降。你不是在发现新的错误类别了，而是在打磨已有的 skill。

Harper Reed 的 My LLM codegen workflow atm（2025 年 2 月，是今天 2026 年 Plan Mode / SDD 共识的祖先）是一份公开的第三阶段作品。他发出来的不是什么小聪明——是一个在足够多项目中反复使用后已经能描述其形状的模板。idea-honing 的 prompt、blueprint 的 prompt、todo.md 的检查表——每一条都是他之前临场做过好几遍后才结晶下来的。这就是第三阶段从外面看的样子——你开始能把自己的工作流写下来，因为它已经稳定到可描述。（当前 2026 年的接替方案——第 3 章里 Plan Mode + SDD 的形状——是同一模式但多了验收契约；Reed 写帖子时它还不存在。）

离开第三阶段的信号：你开始能同时跑超过三个 Agent做重要工作，还不会一整天都在切上下文。第 7 章里的调度模式从"吃力"变成"自然"。

第四阶段：杠杆

感觉上：三把钥匙在大部分工作上自动运转。多个并行 Agent 产出的代码风格一致。你的时间大部分在需求对齐和高层判断，不在执行。你在科技 Twitter 上看到"AI 搞不了真开发"的时候，你知道他们没说谎——他们只是在描述第一阶段。

Cherny 公开的月度数字里，30 天 259 个 PR、497 次提交、加 40k 行、删 38k 行，代码全部出自 Claude Code，约 1.6k 个 session、累计约 3.25 亿 token（325 million）——这就是第四阶段从外面能看到的吞吐。数字里最有意思的往往不是「加了多少」，而是「删了多少」。38k 行不会是手滑删掉的；到了第四阶段，你终于有余力还债，把新功能之外的历史包袱也一并清掉。

这里能做到而之前做不到的事：best-of-N 作为默认动作（第 6 章）、Agent 内部的并行（第 7 章模式四），以及——说白了——接下那些一个人干太激进的活。这才是这本书真正在卖的杠杆。

第四阶段的陷阱：你忘了磨合过。你向朋友推荐这套工作流，他一夜之间进了第一阶段，然后得出结论说你在忽悠他。

每个阶段要多久

这个问题没有诚实的通用答案。影响最大的变量：

  • 代码库的成熟度。 有强约定、好测试、清晰模块结构的代码库会缩短每一个阶段。
  • 你写东西下来的程度。 第二阶段本质就是"把东西写下来"。习惯靠口传传授的工程师走得慢。
  • 工具切换。 每次你换主力 Agent（Cursor → Claude Code → Codex），你会倒退半个到一整个阶段。
  • 团队规模。 独立开发者前期快一些，团队要等到共享 skill 被写下来之前都卡住。

我自己的粗略估算——我想说清楚这是估算不是测量：大多数独立工程师，在一个他认真维护的代码库上会到第三阶段。能到第四阶段的是少数。团队能到第四阶段的条件是，有人专门把 skill 当作共享资产来投入。

该测什么

没测的东西没法管。我所知最便宜的磨合阶段指标是你在一个认真维护的代码库上的每周新 skill 数：

  • 第一阶段：零（你还不知道要写什么）
  • 第二阶段：每周 2–5 条（闸门打开）
  • 第三阶段：下降中，从每周 2 条往每周不到 1 条走
  • 第四阶段：稳态接近零；碰到新子系统时会短暂飙高

当速率接近零并且你交付干净时，你就在第四阶段。当速率接近零但你交付得糟糕时，那是你停止注意了。

第二个信号：你在需求对齐和在审查上花的时间比例。在第一阶段，审查占大头，因为你不信任产出。在第四阶段，对齐占大头，因为审查大部分自动化了。交叉点通常发生在第二阶段末期。

Opus 4.5 "拐点"是怎么真正起作用的

第 1 章对"2025 年底能力跃迁"这句话小心地打了个对冲。磨合框架解释了为什么要对冲。

模型能力抬高的是第四阶段能达到的天花板。它不会帮你缩短第一、第二、第三阶段。这就是同一次模型发布，有的工程师看着改天换地，另一个觉得不值一提——前者已经有 skill 库、有测试计划习惯、有基于 worktree 的工作流，他从更好的模型里拿到了更多杠杆。后者一直在一个聊天窗口里敲 prompt，他拿到的是一个稍微聪明一点的聊天窗口。

模型抬高的是天花板。磨合决定了你离这个天花板有多近。

Skill 是结晶，不是配方

磨合框架有一个不太显眼的推论：skill 不是你下载下来的库，而是你磨合过程的化石记录。

一条只写「组合优于继承」这类通用原则的 skill，用处不大——Agent 本来就知道。一条写清「在本仓库，后台任务在 jobs/*.ts，且必须在 jobs/retries.ts 登记重试；Agent 常漏第二步」的 skill，才真正有用，因为它对准的是你们这里反复出过的错。

所以别人的 AGENTS.md 整份抄过来往往不灵：他们踩过的坑不是你的坑。能撑起他们工作流的那几十行，是结合他们的目录、工具和真实报错写出来的。版式、章节划分可以参考，具体条目还得自己攒。

第 5 章会正式处理这件事。这里的要点是：你的 skill 库是你磨合深度的可见证据。

按阶段给建议

既然每个读者的阶段不同，本书后面的建议不是一视同仁的。一张粗略地图：

  • 在第一阶段：别同时开超过一个 Agent。挑小而范围明确的任务。出问题时，忍住自己动手敲代码的冲动——换成把为什么出错写下来。那段笔记就是你第一条 skill。
  • 在第二阶段：三把钥匙（第 3、4、5 章）是给你的。从钥匙 #2（测试计划）入手，因为它在单 Agent 工作流上回本最快。
  • 在第三阶段：第 7 章的模式 2 和模式 3 是给你的。你有足够的纪律在正交工作上并行跑两三个 Agent。别急着上模式 4。
  • 在第四阶段：第 6 章（廉价失败 / best-of-N）是真正杠杆所在。而且：不管你愿不愿意，你现在都已经是个老师了。这个阶段最常见的错是把自己当前的能力跟"别人的基准"混为一谈。

学费这个比喻

磨合期是一笔学费。你用的是"本可以自己更快完成的任务里被 Agent 吸走的注意力"、"看着 Agent 用你自己绝不会犯的方式犯错的时间"、以及"把你看到的事写下来"的精力来支付它。没有退款，没有加速。唯一的变量是你有没有意识到自己在交学费——并且把收据（skill）留下来——还是决定这所学校不好、退学。

每个人都交学费。能成的那些人，是把收据当作资产的。

外部声音

  • 支持 — 公开的磨合记录：Simon Willison 的 ai-assisted-programming 标签归档 近乎是一份实时的"一个工程师的磨合过程"，他随着工具和 skill 成熟会显式收回早先的立场。他的 Embracing the parallel coding agent lifestyle（2025 年 10 月）开头就坦白说他先怀疑并行模式了几个月才接受——这是从第 1/2 阶段走到第 3 阶段的干净样本。
  • 支持 — "那段时间真是痛苦难熬"：Mitchell Hashimoto 的 My AI Adoption Journey 是这个题材里最直白的一份"磨合回忆录"。他把早期描述为"痛苦难熬的一段低效时期"，并把转机明确归因于打磨自己的 harness——AGENTS.md、确定性工具、钩子——这就是本章描述的第二阶段到第三阶段过渡。他的后续 Vibing a Non-Trivial Ghostty Feature 是一份把成本也公开披露的第四阶段实战。
  • 反驳 — "怀疑论者试手"这个题材：Max Woolf 那篇详细的"怀疑论者尝试 AI Agent 编程"，由 Simon Willison 整理为 An AI agent coding skeptic tries AI agent coding, in excessive detail。Woolf 早期的沮丧看起来就是第一阶段；他后面的调整是第二阶段的开端。大多数"AI 开发不行"的帖子都是这个弧线在更早的节点上被定格了。
  • 反驳 — 磨合真的爬得上去吗：Marc Nuri 的 The Missing Levels of AI-Assisted Development 描述从单 Agent 跳到多 Agent 是断层，不是平滑曲线。这和四阶段模型并不矛盾——只要你把"缺失的那一层"读作 skill 库底座，没有它，这一跳确实是跳水不是台阶。

下一章

第 3 章开始第三部分，讲钥匙 #1：需求对齐——整个工作流里唯一真正无法并行的一步。

第 3 章：钥匙 #1 — 需求对齐

论点：需求对齐是整个工作流里唯一真正无法并行的一步。要么在这里深度投入，要么就在下游把这笔账一遍一遍地还——每个 Agent 还一次、每份测试计划还一次、每次审查还一次。

为什么这把钥匙躲不掉

第 1 章点名了三个必须被机制化才能让并行开发回本的卡点。第 4 章和第 5 章会讲怎么机制化正确性和可维护性。这一章任务更难，因为需求对齐无法机制化。它只能被压缩——单位注意力里做得更快、更彻底——让这一不可避免的串行步骤尽量短、尽量终局。

忽略这一章的失败模式具体而难看：五个 Agent 并行工作，每一个都对同一个需求有略微不同的解读，各自产出内部自洽但彼此拼不到一起的代码。bug 不在任何一个 Agent 的产出里，bug 在需求本身，而且被复制了五份。

模糊性 × 并行度 = 发散。 每一个未解决的需求缝隙，你都要按 Agent 数量重复支付。

为什么一次性写 spec 不够

大多数工程师面对"把需求写下来"的第一反应是打开一个文档、描述这个功能。这是必要的，但不够。你写下来的是你脑子里那份需求。问题是你脑子里那份充满你看不见的缝隙——那些缝隙被你的上下文、你的品味、你对代码库的了解自动填上了。Agent 没有这些，它填空填出来的选择跟你的不会一样。

需求对齐的任务不是"写一份好 spec"。它是把 Agent 本来会自己猜的每一个缝隙都暴露出来、一一决策掉。

两种技术做了大部分工作，彼此互补。

技术一：穷尽式追问

动作：尽你所能地用自然语言描述功能。然后在 Agent 开始规划或编码之前，明确告诉它：

先不要开始做任何事。先列出你对这个需求还有哪些问题。小的、看起来显而易见的都算。我会回答它们，然后你根据我的回答继续问新的问题，直到你没有新问题为止。

Harper Reed 在 2025 年 2 月那篇广为流传的 My LLM codegen workflow atm（今日 Plan Mode 共识的祖先）把这一动作固化成了一份发表过的 prompt。他每个新项目都这样起头：

Ask me one question at a time so we can develop a thorough, step-by-step spec for this idea. Each question should build on my previous answers, and our end goal is to have a detailed specification I can hand off to a developer. Let's do this iteratively and dig into every relevant detail. Remember, only one question at a time. Here's the idea: <IDEA>

结尾用：

Now that we've wrapped up the brainstorming process, can you compile our findings into a comprehensive, developer-ready specification? Include all relevant requirements, architecture choices, data handling details, error handling strategies, and a testing plan so a developer can immediately begin implementation.

这一对 prompt 会产出一份 spec.md，它的形状正好可以直接喂到第 4 章的测试计划步骤。如果你不想自己造轮子，照抄这两个 prompt 没问题——重要的是机制，不是措辞。

为什么它管用

Agent 擅长从需求描述里生成候选问题。它见过无数份需求，模式匹配很好。它不擅长做符合你品味的静默决定——但你本来也没让它做静默决定，你让它把每个决策点暴露出来。

角色互换是关键：你从"写 spec 的人"变成"回答问题的人"。回答比起草在认知上便宜得多。你能在"起草一份 spec 覆盖 15 个决策点"的时间里回答 40 个问题。

技术二：方案生成 + 人类筛选

动作，针对那些你确实不太在乎细节的需求：还是先用自然语言描述功能。但这次你不是让它问，而是：

分析我的需求描述，找出里面模糊的、未定义的、或者有多种合理解读的部分。对每一个这样的点，基于你的知识（有需要的话去网上搜同类产品怎么处理），给出 top 3 选项，并说明推荐理由。我会挑。

Agent 会把你没想到但必须拍板的决策点甩到你面前——"未注册用户能不能看预览？""支付服务商超时的错误态是什么样？"——每一个都附三个选项和一条推荐。你扫一眼，大多数点头，一两个改掉，二十分钟内你就得到了一份本来要花一小时问答才能拿到的对齐文档。

什么时候用技术二而不是技术一

技术一更彻底、更重。技术二更轻，但依赖 Agent 的先验——它对"类似产品怎么做"的模型。在下列情况用技术一：

  • 需求是产品的核心（你有品味，需要表达）
  • 领域不常规（Agent 的先验跟你的现实不匹配）
  • 小决定做错的代价很高

在下列情况用技术二：

  • 需求是外围的（登录流、导出格式、分页风格）
  • 你对大部分细节真的没有强意见
  • 你宁愿把注意力花在别处

实践里，大多数认真做的功能两者都用：核心用技术一，边缘用技术二。

按复杂度分层的深度

第 2 章引用了作者自己的一条启发式：

复杂度越高，审得越深。复杂度低，放手。

这条直接适用于需求对齐。"要深审"的信号：

  • 不可逆的动作（支付、删除、对外 API 的副作用）
  • 跨团队依赖（别人要和你的产出对接）
  • 新问题域（Agent 的先验大概率不准）
  • 涉及鉴权、权限、计费的任何东西

"可以放手"的信号：

  • 模式成熟的 CRUD
  • 内部工具或一次性脚本
  • 容易回滚的改动

"放手"的工作上，15 分钟技术二往往就够。"深审"的工作上，预算一小时，先技术一再技术二——技术一把能想到的都摆出来，技术二在长尾上你不关心的地方收尾。

交付物

需求对齐的产出是一份文档，不是一次对话。对话是手段，文档是物件。文档要清晰到：

  • 另一个 Agent 只拿到这份文档，也会做出同样的东西
  • 第 4 章的测试计划可以直接从它写出来
  • 当 Agent 在执行过半时带着问题回来，你能指着文档的某一节说"这里答过了"

最后一条尤其重要。你做这一步的全部理由就是让 Agent 在执行过程中不再需要你。如果文档回答不了执行中途的问题，那对齐就没做完——你只是把对话推迟了。

2026 年的示范例子：Plan Mode + SDD 流程

本章写作前的六个月里，业界在需求对齐上收敛到了一个非常具体的形状。它有两个名字指向同一个结构动作：Plan Mode（工具语汇——Claude Code、Cursor 的规划步、Gemini antigravity）和 Spec-Driven Development（SDD）（方法论语汇——见 Augment 2026 年 4 月的实践者指南 以及 2026 年 1 月的同名 arxiv 论文）。

两者把 2025 年实践者们手工做的东西结晶成了标准形。今天的权威形状是四阶段循环，在 Plan Mode in Claude Code（2026 年 2 月） 和 Addy Osmani 2025 年底的工作流帖 里都有详细说明：

阶段 1 — 探索（只读）。 进入 Agent 的 Plan Mode——一个只读上下文，它可以 grep 代码、映射依赖、读 spec，但不能改文件。你讲你想要什么，Agent 探地形并把"它已经知道的"和"它需要问的"摆到台面上。技术一的穷尽式追问循环就在这里跑。

阶段 2 — 规划（spec + 实施计划）。 Agent 对着 spec 产出一份实施计划。SDD 语汇里，一份 Plan-ready 的 spec 现在要求六个具体元素（据 Augment 指南 转述）：

  1. 结果和边界 — 要建什么、哪些明确不建。
  2. 约束和先前决定 — 对库、schema、不可妥协项的硬约束，避免 Agent 自行发明。
  3. 任务分解 — 拆成离散的、小到能装进一个上下文的子任务。
  4. 验收标准 — 每个子任务明确可测的验收条件。它们会在第 4 章成为独立 Verifier Agent 的契约。
  5. 子任务之间的接口 — 让并行执行（第 7 章）安全可行。
  6. 模型分层 — 哪些角色用哪些模型。2026 年当前约定：写 spec 用最强模型，实现 用中等模型，验证 用快而便宜的模型。

把 spec 写到一个文件里——社区基本统一到 docs/plans/<feature>.md 或功能 worktree 里的 spec.md。AGENTS.md（第 5 章会讲）引用它。生成它的那段对话是一次性的，文件不是。

阶段 3 — 实施（小块推进）。 把计划交给执行 Agent。Agent 一个子任务接一个子任务地推进，用 spec 的验收标准作为自己的红绿信号。

阶段 4 — 提交。 结构化 PR（参考第 8 章的 end-of-task-report skill），引用计划文件。

flowchart LR
  E["1 · 探索<br/>只读摸底"] --> P["2 · 规划<br/>spec + 实施计划"]
  P --> I["3 · 实施<br/>子任务对验收标准"]
  I --> C["4 · 提交<br/>PR + 引用计划"]

"一句话规则"

从 Plan Mode 指南 里来的一条好用的小实践：如果你能用一句话把需要的 diff 说清楚，就跳过 Plan。否则 Plan Mode 必须做。 这条规则给"对齐是额外成本"和"对齐就是工作"划出了一条干净的切线。这也是对"spec-first 对小改动太重"这种批评的实际回应。

这个形状从哪来

这个形状不是凭空出现的。Harper Reed 2025 年 2 月的 My LLM codegen workflow atm 是三文件模式（spec.md + prompt_plan.md + todo.md）第一次被广泛复制的公开写法。他的 prompts 今天还在用，结构上是稳的——它们是 2026 Plan Mode 共识的 2025 年祖先。如果你用的工具没有内建 Plan Mode，Reed 那套 prompts 是一个能跑的起点；但知道：2026 的约定在 Reed 的原 prompts 基础上额外必须包含"验收标准"和"接口规格"。

Plan Mode / SDD 共识给出的结构主张——也就是我在这里背书的——是：需求对齐产出一份包含六个具体元素的文件，Agent 的实现对这个文件契约式地负责，这个文件是代码库里的一等公民，按复杂度分层地审查。

值得偷的第二个模式：把 spec 当文件

Reed 的工作流把对齐步骤的产出放进 spec.md，把规划步骤的产出放进 prompt_plan.md + todo.md。Addy Osmani 的 My LLM coding workflow going into 2026 独立收敛到同样的结构，Geoffrey Huntley 的 Ralph 循环建立在 PROMPT.md 加一个 specs/ 目录之上。三位先驱、三套工作流、一个共同动作：

对齐的产物是文件，不是对话。 文件跨 Agent 可移植、能在 session 压缩中幸存、在未来一个没在场的 sub-Agent 眼里也能看懂"我们达成了什么"。

本节里如果只偷一件事，就偷这件：需求对齐的交付物是一份在 repo 里、文件名叫 spec.md（或者你们项目约定的名字），被每一个下游步骤引用。对话是手段，文件是物件。

为什么需求对齐不能并行

本书的其它一切都能并行。需求对齐不行。它要求：

  • 你最深的注意力（你在做一批塑造下游一切的决定）
  • 你串行的认知带宽（你一次只能深想一个功能）
  • 你的品味（Agent 没有）

这条限制在调度上有一个实操后果。同时跑三四个 Agent 时，真实的节奏是这样的：

  1. 对齐任务 A 的需求（30 分钟深度注意力）
  2. 把 A 交给它的 Agent 做规划和测试计划（Agent 的工作，你空了）
  3. A 在工作期间，开始对齐任务 B 的需求
  4. 把 B 交出去
  5. B 在规划时，回去看 A 的测试计划，批准或调整
  6. 继续轮转

你在对齐上是串行的，在其它一切上是并行的。 把对齐想成步枪的装弹、把执行想成扣扳机：步枪能连发，但它要一颗一颗装。

"对齐完成"的检查清单

在让 Agent 从"规划"进入"编码"之前：

  • spec 用一句话写出用户目标。
  • 每一个输入都有定义好的类型、默认值、校验规则。
  • 每一个输出都有定义好的类型和格式。
  • 正路被端到端写出来了。
  • 每一个错误情形都有定义好的行为——面向用户的提示、重试策略、或升级路径。
  • 非目标被列出来了（那些 Agent 可能添、但你不想要的东西）。
  • Agent 问过的每一个问题都有一个写在文档里的答案。
  • 假设把这份文档交给另一个（不是你当前在用的）Agent，你会预期它做出同一样东西。

只要有一条没勾，你就没对齐完。现在交出去，账会在第 4 章或更后面付。

zero-review 参考

zero-review/auto-req skill 是作者把上述两种技术编码成一条可跑 skill 的参考实现。书里会多次引用；值得一读，看看"把需求对齐编码为 skill"是什么样子。

参考：zero-review/auto-req

外部声音

  • 支持 — 2026 SDD 共识：Augment Code Spec-Driven Development 指南（2026 年 4 月） 把六元素 spec 和 spec-first / spec-anchored / spec-as-source 的严格度分层固化下来。2026 年 1 月同名论文 是它的学术版本。
  • 支持 — Plan Mode 作为工具原语：Plan Mode in Claude Code（2026 年 2 月） 和 Get AI Perks 完整指南（2026 年 3 月） 是当前的上手指南。Plan Mode 本质上把本章的"穷尽式追问"做成了一个工具特性；用 Claude Code 时，改动超出"一句话规则"就进 Plan Mode。
  • 支持 — 打磨 harness，不打磨 prompt：Mitchell Hashimoto 在 My AI Adoption Journey（2026 年 2 月） 里说 AGENTS.md 风格的约束文档加确定性钩子，比任何一个 prompt 都重要。在他的表述里，需求对齐一半是 Agent 读的文档、一半是捕捉文档抓不到的那类错误的 harness。
  • 反驳 — "需求会变，直到它不变"：Hillel Wayne 的 Requirements change until they don't 是对 spec-first 原教旨主义最到位的反推——当需求真的流变时，重的前置规格成本昂贵且经常出错。他的观点不否定本章的技术；它收紧了边界：在你相信不会变的部分做最深的对齐，在流动的部分留轻。上面的一句话规则就是对他的一条实际回应。

下一章

第 4 章讲钥匙 #2：怎么用一份在编码前写好的测试计划替代逐行代码审查，并按工作的复杂度决定审得多深。

第 4 章：钥匙 #2 — 把正确性当契约，而不是审查

论点：别再逐行审代码。在编码之前写好一份测试计划，把它当作验收契约，让 Agent 自己闭合正确性循环——并按照改动的复杂度决定你审多深。

为什么逐行审查在规模上失灵了

单 Agent 工作流里，读 diff 还行。Agent 生成五十行，你读五十行，你批准。就算这里也很慢，但能做。

三 Agent 工作流里，一天的产出大概是两三千行，散落在不同 PR、不同分支、代码库的不同地方。如果你试图用同样的注意力读完所有，会发生两件事：

  1. 你又成了瓶颈。执行上的并行收益在审查上全丢回去。
  2. 你的注意力会退化。大概到当天的第八个 PR，你开始扫读。你会批一条本不该批的东西。三 Agent 规模上的扫读审查比单 Agent 规模上的细读审查更糟。

出路不是"审得更用力"。出路是别再审实现，改成审契约。

"正确性当契约"是什么意思

一段代码的正确性在操作层面上就是它必须展现的行为集合。测试编码行为。一套覆盖充分的测试，全绿，就是正确性的证据。

如果你在编码之前写下的测试完整表达了正确性契约，而测试全过，实现就按构造是正确的。

这一句就是全部框架。Agent 写代码。Agent 跑测试。测试过了，你不用读 diff。测试没过，Agent 自己调试重跑直到过。你被移出了正确性验证的内循环。

人的角色挪了位置：从审实现（因为你得审，Agent 的产出可能是错的）挪到审测试计划（因为 Agent 本来就写不出这份计划，没有你的品味和领域理解）。

TPD vs TDD

测试驱动开发（TDD）的经典形式——红、绿、重构——是一种人的纪律：一次一个测试、一个小的行为增量、短反馈循环、测试存在是为了指导写代码。

测试计划驱动开发（Test-Plan-Driven Development，TPD）不一样。你一次性产出覆盖整个功能的完整测试计划，然后把整件事交给 Agent，它把实现和测试一起写出来，对着这份计划闭合循环。

TDD（人）TPD（Agent 辅助）
粒度一次一个测试整个功能的测试计划
目的渐进引导写代码为自主执行划一条正确性边界
反馈节奏每条测试红绿每跑一次全套红绿
主要受益者人类开发者自己闭合循环的 Agent

TPD 不是在"智识实践"意义上替代 TDD。它是针对"实现会被某种东西一口气写完、而那种东西能每 30 秒跑一次全套测试"这个情境打造的另一种形状。

TDD 是人的编程纪律。TPD 是人给 Agent 的验收契约。

（TPD 这个名字是为了和 TDD 对照起的一个方便叫法。业界不是标准术语。别为它吵架。）

sequenceDiagram
  participant H as 人
  participant S as Spec
  participant TP as 测试计划
  participant A as Agent
  participant CI as 套件 / CI
  H->>S: 对齐需求（第 3 章）
  H->>TP: 审查计划（契约）
  TP->>A: 按 plan 写实现与测试
  A->>CI: 跑到绿
  CI-->>H: 仅在计划缺口或红套件时需要你

2026 年正确性共识：Adversarial Agent Pattern

"把正确性当契约"的当前最干净实践是 Adversarial Agent Pattern（对抗式 Agent 模式），在 Augment Code Spec-Driven Development 指南（2026 年 4 月） 里有最清楚的定义。它把一些 2025 年实践者临场在做的事固化下来，并且——因为它把验证角色交给一个上下文不同、通常模型也不同的独立 Agent——直接处理了本章稍后会讲到的盲点问题。

这个模式有三个角色：

  • Coordinator（协调者）。 读 spec（第 3 章），把它拆成子任务、分配下去。
  • Implementor（实现者，一个或多个）。 每个 Agent 在自己的 git worktree 里独立做一个子任务。它们看不到彼此的上下文——只能看 spec 里的接口契约。
  • Verifier（验证者）。 一个独立的 Agent，它的唯一工作是把每个 Implementor 的产出对着 spec 的验收标准做检查。它没有看过实现过程——只看 spec 和最终 diff。

模型分层已成当前约定：最强模型写 spec，中档模型实现，快而便宜的模型验证。成本上，这比让顶级模型全流程做事便宜。正确性上，它远强于"一个 Agent 一边写代码一边写测试一边给自己打分"——因为 Verifier 从未和 Implementor 共享过理解，它只能对着 spec 看现实跑出来什么样。

这直接回应了你会在下面看到的"测试和代码共享盲点"问题。当 Verifier 独立，Implementor 实现里的一个误解即便被它自己的测试一起锁进去了，也会被捕捉到——因为 Verifier 是新鲜地读 spec、检查现实的。

对任何不 trivial 的正确性面，明确采用 Adversarial Agent Pattern。 把它建模成三个角色、三个独立上下文。让一个 Agent 写代码又写测试又给自己打分，是一次退步，不是一套工作流。

示意图：协调者把任务分给不同 worktree 里的实现者；独立的验证者对照 spec 检查产出

把 spec 转成测试计划的 prompt

如果你的工具没内建 Verifier 角色，你可以手动搭一个——开一个新 session，只加载 spec（不带实现上下文），然后这样问：

你是 Verifier。你会收到一份 spec 和一份 diff。你的工作：对 spec 里的每一条验收标准，给出 YES / NO / PARTIAL 的结论；对每一个 NO 或 PARTIAL，指出具体的文件和行为。你没有Implementor 的推理过程——只有 spec、diff 和交付后的代码库。优先怀疑，不是同意。

这条 prompt，配上第 3 章的六元素 spec，就是最小可用 Verifier。搭起来一小时的活，能捕捉相当比例的"实现偏离了 spec，但 Implementor 自己的测试过了"这类失败。

一份好测试计划覆盖什么

测试计划是交付物。它应该覆盖三层：

  1. 单元测试。 单个函数和模块的行为。"给这个输入，这个函数返回这个输出。" Agent 写这些针对纯逻辑。
  2. 集成测试。 模块之间的交互。"job scheduler 调 retry handler 时，重试会按预期的 backoff 排好。" Agent 写这些针对架构步定义的模块边界。
  3. 端到端 / 功能测试。 用户路径。"用户能上传文件、等待处理、下载结果，下载的文件在预期变换后和上传的一致。"

每一层的敏感度不同。单元抓逻辑错误，集成抓接线错误，E2E 抓真实组合错误。少任何一层，都会漏一类。

好的测试计划也会命名未覆盖的东西——你显式不测的行为（性能、罕见并发路径、视觉回归）。命名未覆盖，防止"假装完整"的错觉。

Agent 能操作的环境——对 TPD 不是可选项

TPD 的前提是：Agent 能观察到测试计划所断言的那层现实，并在失败时自行行动而不把你拉回内循环。可复现的 Docker（或同类容器）通常是起点——依赖钉死、种子数据、一条命令起全栈。把这份镜像当作契约的一部分，和代码一样检入、版本化。

光有镜像不够。 环境还必须暴露验收标准真正需要的能力形态。缺了这一层，就会出现 CI 全绿、但 spec 关心的产品路径根本没被测到的情况。

  • 浏览器型产品。 用户通过 Web UI 交互，则 Agent（以及 E2E 工具链）在环境里必须有可用的浏览器自动化：工具能驱动的 headless/headed 浏览器、稳定的 base URL、按文档准备的 cookie/会话夹具。"容器里只跑 npm test，却没人能打开 https://localhost:3000" 属于断裂的 TPD 面——Agent 无法对你计划里写的布局、流程、前端回归自行闭合循环。
  • GUI / 原生 / 桌面应用。 若正确性包含窗口、菜单、原生控件，环境必须暴露 GUI 使用能力——例如带文档的虚拟显示与远程会话、或 Agent 可登录的桌面会话——不能只有 CLI 和单元测试。否则测试计划会在唯一出 bug 的渠道上悄悄留空。
  • 复杂或并发系统。 当失败依赖时序、跨进程状态，或需要对着运行中的代码单步排查时，调试器（挂到正确进程、断点、看变量、抓栈）必须在 Agent 可用、且与资深工程师同等约束下可用。只靠 println 排查，套件一红就把你重新变成瓶颈。

Verifier 同一套标准。 独立的 Verifier 若不能起栈、不能驱动浏览器、不能挂调试器，它多半是在做「文本对文本」核对——有用，但替代不了 spec 所承诺的那些行为形态下的核验。

把这些能力写进仓库（compose.yaml、AGENTS.md 或简短的 docs/agent-environment.md）：如何启动环境、哪些端口暴露 HTTP、如何连上浏览器驱动、如何开 GUI 会话、如何挂调试器。若未写清楚且 Agent 够不到，它就不在你的正确性契约里——只是愿望。

藏起来的风险：测试和代码共享盲点

这一节是几乎没人写过的。如果 Agent同时写实现和测试，用的是对需求的同一份理解，而那份理解错了，测试会过，代码还是错的。测试验证的是代码做了什么，不是它该做什么。它们把误解一起锁住。

缓解是结构性的：

  1. 测试计划在实现开始前由人审查。 不是测试体——而是测试计划。计划描述"应该是什么"，测试体描述"怎么验证"。审计划就是审意图。
  2. 测试计划从需求 spec 写，不从提议实现写。 如果让 Agent 在写完代码后（甚至同时）写计划，这个性质就丢了。步骤顺序很重要。
  3. 人按复杂度分层审高风险行为的覆盖度。 复杂度启发式在这里又被用到了。

按复杂度分层的审查深度

作者自己的实践：复杂度越高，审得越深。复杂度低，放手。

应用到测试计划：

深审：

  • 不可逆动作（支付、删除、数据迁移）
  • 跨模块改动
  • 安全和鉴权路径
  • 任何难以回滚的失败模式
  • Agent 先验已知偏弱的领域

放手：

  • CRUD
  • 内部工具和一次性脚本
  • 低风险、模式成熟的场景
  • 容易回滚的改动

"放手"不等于"没测试计划"。意思是：扫一眼计划、确认形状对、相信 Agent 填细节、不花注意力逐条审。测试还是要有；你只是不花审支付流一样的注意力深度去审。

这条是我最想让一个第二阶段读者内化的实用原则。第一阶段的天真失败是什么都以同样强度去审；第四阶段的天真失败是什么都不审。按复杂度分层是能 scale 的中间路线。

Agent 当用户测 UI 工作

自动化的单元、集成、E2E 测试抓不到 UI 层的抱怨：蹩脚文案、凌乱布局、技术正确但用户看不懂的错误提示、能跑但要点太多次的流。对这些，Agent 可以扮演用户——驱动浏览器、填表单、报告体验。唯一值得记的诀窍：让 Agent 扮演一个具体命名的用户角色（新手 / 熟手 / 对抗），并且把它约束在只拥有那个角色拥有的感官里。新手角色的 Agent 只能报"我点了保存，页面空白了 5 秒"——不能报"init 失败 500"，因为它看不见控制台。这个约束是让报告呈现真实用户形状而不是工程师形状的关键。具体实现细节在 zero-review/auto-test。

你不再做什么

具体化一下，第三阶段及以后你退出的审查实践：

  • 逐行读 diff。没有了。
  • 靠读代码抓 bug。没有了。测试应该抓 bug；如果抓不到，计划不全，修那里。
  • PR 评论里挑风格。由 skill 强制的约定替代（第 5 章）。
  • 检查代码能跑。由 CI + Agent 跑套件替代。

剩下的：

  • 审测试计划的覆盖是否充分。
  • 只对高风险改动点抽查实现。
  • 读 Agent 当用户报告。
  • 最终放行批准。

最近六个月先驱在做什么

当前实践——严格限定 2025 年 11 月到 2026 年 4 月窗口：

  • Mitchell Hashimoto 在 My AI Adoption Journey（2026 年 2 月） 里，把失败当作加确定性钩子和测试、阻止这类失败再发生的时机。测试不是开发副产物——它们是永久的 harness。
  • Opus 4.5 的 "No Restart" 工作流，Claude Opus 4.5 Unlocks the "No Restart" Workflow（2025 年 12 月） 有记录，第一次让长时间无人看守的"测-修-测-修"循环切实可行。含义直接：如果 Agent 能跑套件、调失败、继续跑而不丢上下文几小时，你就真的可以不再读 diff。
  • Geoffrey Huntley 的 Ralph 循环 把测试（和构建、lint）显式当作反向压力：循环在结构上没法越过失败的套件往前走。文档到2025 年底仍然有效。
  • Claude Code 的 Plan Mode，2025 年底到 2026 年初固化（2026 完整指南）把"先规划再编码，对着规划验收"的循环烤进工具里。你不再是在一个通用聊天机器人上叠 TPD；工具本身强制它了。
  • Adversarial Agent Pattern（上文已讲）是共识的形式化表达。把 Implementor 和 Verifier 分开，按角色分层模型，永远不让一个 Agent 给自己打分。

这种收敛值得注意，因为这些实践者并非互相抄。每个人都独立地走到"测试先于代码、验证由写代码角色之外的角色来做"这个结论，作为同一底层问题的显然解：逐行审查是第一个停止 scale 的东西。

zero-review 参考

zero-review/auto-dev skill 把 TPD 循环端到端编码，包括下一章描述的架构步。它和 auto-req（第 3 章）、auto-test 一起构成作者单 Agent 执行的工作 skill 栈。并行调度（第 7 章）就是把这些 skill 跑在多个 Agent 上。

参考：zero-review/auto-dev

外部声音

  • 支持 — Adversarial Agent Pattern：Augment Code SDD 实践者指南（2026 年 4 月） 是当前 Coordinator / Implementors / Verifier 分层加模型分层的权威参考。2026 年 1 月 Spec-Driven Development 论文 是学术版。
  • 支持 — 扩展的自主循环：Opus 4.5 的 No Restart 工作流（2025 年 12 月）是让 TPD 风格的无人值守"测-修-测-修"循环在规模上真正可行的能力。
  • 支持 — 别审查，做工程：Geoffrey Huntley 的 Ralph 循环 主张一旦 Agent 能对着反向压力自我验证，逐行审查就结构性地过时了；工程师的工作是设计护栏——pre-commit 钩子、property-based 测试、快照测试——不是读 diff。
  • 反驳 — 测试证明不了正确性：Hillel Wayne 的 Why Don't People Use Formal Methods? 仍然是对 TPD 所继承那条局限最锋利的表达。Adversarial Agent Pattern 显著收窄了这道缝（独立 Verifier、spec 作为契约），但没关上它。对真正高风险的正确性面，测试仍然是正确性工具箱里的一项，不是证明。
  • 反驳 — "你不知道自己是不是拿到了对的 spec"：Wayne 指出的根本验证问题——任何测试套件只跟它所编码的需求一样好——是为什么 2026 共识的 spec 必须有六元素（第 3 章），而不是三。没有显式的结果和约束，只有验收标准，依然会把误解锁死。

下一章

第 5 章讲钥匙 #3：如何把工程纪律——命名、分层、模块设计、提交规范——编码成 Agent 自己执行的 skill，以及 skill 注入到哪里仍然不够。

第 5 章：钥匙 #3 — 用工程纪律约束 Agent

论点：Skill 不是装一次就完事的配置，而是你在项目里一条条记下来的约定——尤其是 Agent 犯过、不该再犯的那类错。通用的设计原则可以写进 skill，但离不开针对本仓库的补充规则。

为什么只保证正确性不够

第 4 章讲的是：怎么让「对不对」有凭据。但代码可以既对又难维护：结构乱、耦合紧、命名三套、现成的工具函数旁边又造一个轮子。今天能跑通，下周换谁来（人或 Agent）都头疼。可维护性决定这条线能走多远。

单 Agent、你亲自审的时候，你会随口一句「这里别用继承，换策略模式」，Agent 就改。可一旦一小时里要合三个 PR、三个 Agent 各写各的，这种口头纪律根本跟不过来——要么写进机制，要么就等于没人管。

Skill 就是那套机制：启动时加载的一组约定，规定 Agent 怎么设计、交付前要自检什么。你在 review 里常会强调的那些点，尽量写成它交差前自己先过一遍的清单。

通用原则——起点

Skill 里常常先写进去的，是你在 code review 里也会讲的那套通用设计约束，思路多来自 Ousterhout 的 A Philosophy of Software Design。写成一份不长的 skill，一般就能把 Agent 的第一版结构从「默认水平」往上抬一截：

  • 深模块。 接口简单，内部功能深厚。Agent 天然倾向拆过细；skill 要显式把它推回来。
  • 信息隐藏。 模块不应该泄露内部。Agent 这一条最常见的失败是按执行顺序拆模块（"A 步模块、B 步模块"），而不是按知识归属拆——后者几乎必然泄露。
  • 抽象分层。 每一层提供一种不同的思维模型。一层只把调用转给下一层，这一层就没挣到工钱。
  • 内聚与分离。 必须同时被理解的代码留在一起；通用和特例混一起让两者都难懂的，该分开。
  • 通过定义处理错误。 偏好通过"让错误消失"（默认行为、语义简化）的设计，而不是到处 try/catch。
  • 命名和显而易见。 读者不应该惊讶。命名要具体、跨代码库一致、不自造缩写。
  • 文档增量信息。 注释应描述代码无法表达的——意图、权衡、不变式。不是字面复述代码做什么。
  • 战略优于战术设计。 每一次改动都是对结构的投资。短平快最终以复利利息堆出技术债。

这些是好默认。编码成 skill 后，Agent 的初版架构会明显高于它未经训练的基线。

这些原则解决的是「通用」那一半问题。另一半要靠项目自己的约定：例如仓库里已有工具函数却被忽略、命名和全库风格不一致、抽象上说得通却和当前框架习惯不符——这类事只能写进针对本仓库的 skill，靠你在实际出错时逐步补全。

若关心 skill 文档怎么写（标题、触发条件、正文结构、失败模式等），见 The Skill Design Book。本章只讨论：在并行开发里，skill 如何承担可维护性这一环。

先驱们怎么真正积累他们的 skill（以及 2026 年的研究说了什么）

近半年里，各家工具渐渐认同一套做法：用 AGENTS.md（或链到它的 CLAUDE.md）当「给机器看的 README」。Claude Code、Cursor、Codex、Gemini 这一路都在往这靠。想系统搭一份，Augment 2026 年 3 月这篇 How to Build Your AGENTS.md (2026) 写得很实在。

最近六个月里几项值得内化的发现：

  • 保持在 150 行以下。 ETH Zurich 2026 年 2 月的研究（在 Paul Withers 的 Is AGENTS.md Engineering the next optimisation approach? 有总结）发现冗长或 LLM 生成的 AGENTS.md 反而会降低任务成功率、推高成本——原因是长上下文上的"lost in the middle"退化。人类手作、简洁的文件性能明显更好。
  • 嵌套用于模块化。 Agent 优先读取当前工作目录最近的那个 AGENTS.md。根目录放一个短的、覆盖代码库范围的文件，然后在需要不同规则的子目录里放聚焦的 AGENTS.md。
  • 符号链接解决跨工具。 2026 年的常规动作是 ln -s AGENTS.md CLAUDE.md——这样你用的每一个 Agent 不管它偏爱哪个文件名都读同一份。这现在是标准做法。
  • 把它当代码对待。 检入 git、版本控制、在 PR 中审查。Mitchell Hashimoto 在 My AI Adoption Journey（2026 年 2 月） 里把 AGENTS.md 当作一份每次观察到新失败类别就更新的活合同——不是一次写完的东西。
  • Skill 是另一个通道。 Anthropic 的 Agent Skills 和 Addy Osmani 的 2026 同一模式写法 把总是加载的上下文（AGENTS.md）和按需加载的 skill（SKILL.md 在自己的目录里，按任务相关性触发）分开。这个切分很重要，因为它让你拥有五十条特化 skill 而不会撑爆每一个 session。

2026 共识压缩一句：根目录一份精干的 AGENTS.md 承载持久的代码库范围规则，一个聚焦 SKILL.md 包的库承载任务专用工作流，都检入 git，都纳入版本控制，都在 PR 中审。 成熟项目最后大概是一份 60–120 行左右的根 AGENTS.md 加十到四十条聚焦 skill，每条都绑定到 Agent 犯过一次、不该再犯的一类具体错误上。单条 skill 的形状——描述、触发、正文、检查表——在 The Skill Design Book 里有详尽处理；这里要紧的是文件里每一条规则都来自一次具体失败、携带它的原因，并且如果你没亲眼看 Agent 犯错，它就不会出现。

真正把质量抬上去的 skill，是那些编码"你的 Agent 在你的代码库里犯过的错"的 skill。"遵守好命名约定"是无用的——Agent 本来就在试。"这个代码库的 handler 命名约定是 handle<EntityName><Action>——Agent 倾向写 <entityName>Handler 而写错"是金子。这种具体性就是全部要点。

通用 skill 是默认配置。特定 skill 是磨合结晶所在。 前者你写一次，后者你一次一个失败地积累。

三阶段执行流

skill 到位后，Agent 对一个功能的工作长这样：

flowchart TB
  SK[(Skill + AGENTS.md)]
  SK --> D[1 · 架构设计]
  D --> V[2 · 实现与验证]
  V --> U[3 · 对照 skill 自审]
  SK --> V
  SK --> U
  1. 架构设计。 给定需求 spec（第 3 章）和测试计划（第 4 章），Agent 提出模块边界、接口、文件组织、抽象。它是在加载 skill 集合的情况下做这件事——所以设计已经反映了深模块、信息隐藏、命名一致性。人按复杂度分层审查这份设计。这一步做对了，是第 7 章模式 4（Agent 内部并行）能够成立的前提——这里定义的接口契约让 sub-Agent 能并行而不撞车。
  2. 实现与验证。 Agent 写代码和测试，跑套件，调试失败，迭代到绿（第 4 章）。
  3. 自审。 在宣布完成前，Agent 在加载 skill 的情况下重读自己的 diff，检查违规：浅模块、冗余层、只转发的中间层、命名不一致、和已有工具的重复。它自己修好。

第 1 步和第 3 步是新的。它们替代你原本在审查时应用的架构判断和最后打磨。你仍然参与——你批准架构、在高复杂度工作上抽查自审——但你不再是唯一的防线。

Skill 注入仍然不够的地方

诚实谈极限：

  • 原则之间的冲突。 深模块 vs 小可组合件；战略设计 vs YAGNI。这些真的会冲突，skill 仲裁不了——判断才行。有争议的场景里，Agent 需要 skill 里的明确指导："在这个代码库里，宁可深模块即使单测更难做；我们更看重接口简洁。"
  • 横切关注点。 安全、可观测性、性能——它们不住在一个模块里，"考虑一下安全"这种 skill 太虚。这些通常需要（a）专门的工具（linter、scanner）或（b）非常具体的 skill（"任何写 DB 的端点，要求调用者的权限在 handler 里、DB 调用之前已经检查过"）。
  • Agent 之间的品味漂移。 不同训练数据的不同 Agent 偏差不同。为 Claude 调好的 skill 集，用 Codex 模型读起来可能不一样。这是可移植故事的一条真实极限；切主力 Agent 时预留重新调优的时间。
  • 全新子系统。 第一次碰一个新框架、新语言、新服务，你还不知道失败模式。还没有 skill 可以写。你要在那个子系统上先交学费（第 2 章），然后从学到的东西里写 skill。

哪一条都不致命。每一条都意味着"skill 能带你走很远，不是全部路"。

与并行调度的关系

本章属于本书第三部分——解锁并行工作。和第 7 章（调度模式）的关系直接：

  • 模式 1–3 在 Agent 加载共享 skill 集时更好工作。没有它，三个 Agent 会产出三种风格的代码、合并时一团乱。
  • 模式 4——Agent 内部并行——在架构步没有定义接口契约的情况下基本做不到。 并行工作的 sub-Agent 只能在接口被预先定下时干净地合并。这是钥匙 #3 的直接红利：你执行的架构纪律是让并行分解可行的东西。

跳过架构、让 Agent"边写边设计"是最快丢失并行收益的办法。小功能单 Agent 能撑；中等功能三 Agent 会灾难性失败。

zero-review 参考

zero-review/auto-dev skill 把这个三阶段循环——架构设计、实现与验证、自审——编码成一条可跑 skill，包括 Ousterhout 衍生的设计原则和一份具体自审清单。值得一读，是"把工程纪律编码为 skill"的范例。

参考：zero-review/auto-dev

外部声音

  • 支持：A Philosophy of Software Design（Ousterhout）仍是底层原则最好的单一来源。Anthropic 的 Agent Skills 文档 把注入机制固化。关于单份 skill 文档本身的写作工艺，参见 The Skill Design Book。
  • 反驳：有人担心规则写进文件会变成形式主义清单、反而误事，这种担心对「大而全的通用 skill」尤其成立。项目专用的 skill 往往只针对一两类真实出过的问题，不容易漂成空话。

下一章

第三部分完成。第 6 章开启第四部分，讲经济学相变：当尝试成本从小时降到分钟，探索变得便宜，best-of-N 不再是奢侈品。

第 6 章：廉价失败的原则

论点：当一次尝试从几小时降到几分钟，探索的整个经济学就翻转了。best-of-N 不再是奢侈品，而是默认动作——以及它带来的反模式。

相变

AI Agent 之前，每一次"试一下这个功能"都要一个人好几个小时。这个成本塑造每一个决定：你挑最安全的路，你不做冒险的 spike，你不"只是为了比较"再写一版。探索被定量配给。

Agent 跑在三把钥匙上时（第 3–5 章），一次尝试从几分钟到一小时。成本曲线整体挪了一到两个数量级。当执行成本降了一个数量级，"再试一个方案"的决策成本开始超过实际去做的执行成本。

这就是相变。听着像量变，其实是质变。一类以前不合算的策略变得合算了。

以前：决定做什么便宜；做出来贵；所以想清楚再做，一次做对。 现在：决定做什么还是要钱；做出来便宜；所以试几个，挑一个。

best-of-N 作为日常动作

直接后果：best-of-N 从偶尔的技巧变成默认动作。

best-of-N 工作流里，你把功能对齐一次（第 3 章）、写一次测试计划（第 4 章），然后启动 N 次并行尝试——可能用不同的 Agent、不同的 prompt、不同的架构假设。每一次尝试都对着同一份测试计划跑。你读赢家、对比、挑一个。

听起来 Agent 成本很贵。是的。但在你的成本上便宜得多，因为：

  • 三次尝试里几乎总有一次先通过测试，你就审那一个。
  • 另外两次给你一份便宜的对比——你看到同一契约下的三种设计选择，三十秒就能看出哪个更顺眼。
  • 三次都失败，那你就学到了关于这个需求的真实东西——一次尝试会把它藏起来。
flowchart LR
  subgraph once["对齐一次"]
    SP[Spec]
    TP[测试计划]
  end
  SP --> W1[Worktree / 尝试 1]
  SP --> W2[Worktree / 尝试 2]
  SP --> W3[Worktree / 尝试 3]
  TP --> W1
  TP --> W2
  TP --> W3
  W1 --> P[对照契约挑胜者]
  W2 --> P
  W3 --> P

best-of-N 尤其好用在：

  • 架构选择模糊时。 不知道对的抽象是什么，让三次尝试告诉你。
  • 风险重构。 安全路径和激进路径并行跑，按测试计划比较。
  • "我要好那个。" 文案语气、UX 流程——任何你识别质量比指定质量快的地方。

它不好用在：

  • 只有一个对答案的任务（CRUD、有已知成因的 bug 修）。N 次尝试只是浪费算力。
  • 契约本身不清的任务。 best-of-N 在实现上找变异，不在 spec 上找变异。spec 错了，N 次尝试全错。

具体例子——用 git worktree 做并行尝试

今天在真实功能上跑 best-of-N 最便宜的办法，是把廉价失败和第 7 章模式 2 组合起来。具体：

# 对齐需求一次，产出 spec.md 和 prompt_plan.md。
# （见第 3 章的范例——Harper Reed 的流程。）

# 然后对同一功能启动三次并行尝试。
git worktree add ../feature-attempt-a attempt-a
git worktree add ../feature-attempt-b attempt-b
git worktree add ../feature-attempt-c attempt-c

# attempt-a 里：给 Agent spec.md + prompt_plan.md，不加额外指令。
# attempt-b 里：一样的输入，但前置一条把它推向不同架构选择的
#   暗示（"这里偏好状态机，即使重一点"）。
# attempt-c 里：一样的输入，但换一个完全不同的 Agent——
#   例如用 Codex 而不是 Claude Code——获取真正独立的尝试。

每个尝试对同一份测试计划跑。并行启动；墙钟时间大约是一个尝试的时间。当两三个产出绿套件时，你并排读、挑。

多样性诀窍很关键。三次同 Agent、同 prompt、同 spec 的运行会收敛到几乎一样的产出；你学不到东西。真正的杠杆是每次尝试在一个轴上变——Agent、架构暗示、或 temperature——这样尝试之间的差异才承载信息。

Simon Willison 的 Embracing the parallel coding agent lifestyle 和 Mitchell Hashimoto 的 Vibing a Non-Trivial Ghostty Feature 都描述了对着同一 spec 跑并行尝试，目的正是看不同 Agent 的方差——哪一个实现更干净，哪一个抓到了别的漏掉的边缘情形。那份方差就是你用额外算力买来的商品。

"探索成为默认"这个转变

廉价失败还有第二个、更隐蔽、在我看来更重要的后果。

旧经济学里，你有一个模糊想法——"不知道是不是该从方案 A 切到方案 B"——找出答案的成本是写一版 B，那意味着几天到几周，那意味着你几乎总不做。问题就没了答案。方案粘住是因为没人查得起。

新经济学里，找答案是一次三十分钟的 Agent 跑。大多数模糊想法都能查。这改变了决策的节奏：你不再用辩论来解决"要不要"，你用便宜的实验。一个第四阶段的工程师一天里就能用实际证据解决的架构辩论，比过去团队一个季度还多——不是因为工程师更聪明，而是因为"找出来"的成本曲线塌掉了。

这才是真正的生产力增益，它不会被任何"每天写几行代码"的指标捕捉到。它被"每周带实际证据做多少决定"捕捉。

廉价失败带来的反模式

每一次相变都制造新的失败方式。这里最常见的两个：

反模式 1：跳过需求对齐，因为"试几次就行"

这是第一阶段的失败。"干嘛花三十分钟对齐需求，我跑三个 Agent 挑最好的不就行了？"回答：因为三个 Agent 都会对着模糊需求的不同误解产出自洽的工作。你会得到三份能跑的实现，分别对应三个微妙不同的功能，而三选一是在三个你都不想要的东西里选。

廉价失败是好对齐之上的杠杆。它不替代对齐。 第 3 章没做好，第 6 章反而有害。

反模式 2：用 best-of-N 代替测试计划

"我挑看起来最好的那个。" UI 语气上行，正确性上不行。没有测试计划，"最好"塌成"能编译且看起来熟悉的"——那是 Agent 最喜欢的尝试，不是对的那个。第 4 章是第 6 章的前置；跳过它让 best-of-N 退化成审美投票。

反模式 3：永远跑 N

N 次可以。N + M 次、追逐完美实现，是一种烧算力的坏习惯，边际回报递减。实践里，方差重要的场景，N = 2 或 3 覆盖 90%；超过 3，边际尝试几乎不改变选择。经验法则：如果前两次尝试有实质分歧，跑第三次破平票；如果它们一致，一次就够了。

反模式 4：忘了人的瓶颈还在

三次并行尝试产出三个你仍然要比较的东西。如果比较时间等于读一版的三倍，你刚把审查负担翻了三倍。修复是要么（a）让测试计划替你比较（三个都绿了；按测试结果或代码美学信号挑）要么（b）别在你没法快速比较的任务上用 best-of-N。

成本估算，粗略

给一个第三阶段及以上的工作工程师，粗略数字：

  • 一次 Agent 尝试在一个中等功能上：30–90 分钟 Agent 时间，约 1–5 美元算力。
  • 三次并行：同墙钟、3 倍 Agent 时间、3 倍算力、同人类在对齐 + 测试计划阶段的注意力、选阶段多 20%。
  • "三次尝试里有一次教你关于问题的新事"的期望值：难量化，但经验上，新颖工作上高、常规工作上低。

主导成本不是算力。是你的人类注意力预算里有没有"看三个东西而不是一个"的空间。相应规划。

与调度模式的关系

best-of-N 是第 7 章四种并行模式之一，但它和另外三个有一个关键差异：另外三种模式并行的是不同任务；best-of-N 并行的是同一任务的替代尝试。

实践中，成熟的并行工作流会同时用两者。你可能有三个 Agent 在三个不同功能上（第 7 章模式 2），并且在其中一个功能里有三次 best-of-N 尝试（本章）。那就是九个 Agent 运行同时在跑。第 8 章会讲这造成的产出洪水。

外部声音

  • 支持：ML 从业者在模型输出上做 best-of-N 采样已有多年；把同样模式应用到任务级是自然推广。Chase-Lambert、Anthropic 等讨论过"多稿一选"的工作流；Geoffrey Huntley 关于 agent-of-agents 模式的帖子触及同一领域。
  • 反驳：一些从业者警告 best-of-N 可能掩盖系统性错误（如果 N 次尝试都共享模型的盲点，你高置信度地选了"最好的错"）。这是真实批评，缓解是多样性——不同 Agent、不同 prompt、不同起始架构——而不是同 prompt 跑 N 次。

下一章

第 7 章讲四种并行 Agent 调度模式——从跨项目协调（最粗）到 Agent 内部并行（最细）——以及哪种模式匹配哪个磨合阶段。

第 7 章：调度模式

论点：并行有四种模式，粒度从粗到细，分别对应不同的磨合阶段。别在第一阶段就去用模式四，也别在第三阶段还停留在模式一。

这里"调度"是什么意思

三把钥匙到位、廉价失败理解之后，剩下的问题是怎么真正让多个 Agent 同时跑。"开五个 Claude Code 窗口往里面敲字"算一种策略，而且是差的那种。不同粒度的并行有不同的协调成本、不同的失败模式、对你磨合阶段有不同的前置要求。

四种模式，从粗到细：

模式粒度协调成本适用阶段
1跨独立项目非常低第 1 阶段及以上
2同一项目内不重叠功能低（通过 git worktree）第 2 阶段及以上
3同一功能内不同事务类型中第 3 阶段及以上
4同一任务内拆子 Agent设置成本高，运行成本低主要是第 3–4 阶段，前沿

示意图：四种调度模式——从跨项目到任务内子 Agent

你会同时用多种模式。一个忙周里的第四阶段工程师可能在三个项目上跑模式 1，在其中一个项目内部跑模式 2，在其中一个功能里跑模式 3。那已经是六个 Agent 在跑，还没动模式 4。

模式 1：跨项目并行

动作：你有两三个独立项目（不同 repo、不同产品）。每个项目跑一个 Agent，各自做自己的 backlog。项目之间不共享代码，Agent 之间不干扰。

为什么容易：没有协调。每个项目有自己的 skill、自己的约定、自己的需求。并行的唯一一份是你的注意力，你通过在对齐阶段在项目之间轮转、让每个项目异步执行来管理它。

能跑的节奏：

  1. 对齐项目 A 的需求（20–30 分钟深度注意力）。
  2. 把 A 交给 Agent 做规划和测试计划生成。
  3. A 在工作时，切到项目 B。对齐。
  4. 把 B 交出去。
  5. B 在规划时，查 A 的测试计划，批准或调整。
  6. 轮转。

这是"多会议室"模式。你是在它们之间走的 tech lead。如果你磨合出的结晶能干净交接，这个模式几乎零成本，给你一份工程师时间上的两三个项目吞吐。

前置：项目本身得在可以干净交接的状态。成熟项目有约定有 skill 的：trivial。你还在琢磨架构的新项目：模式 1 帮不上忙，因为深度注意力本来就在 A 项目上，不在轮转里。

模式 2：Worktree 并行——同项目内、不重叠工作

动作：在同一代码库里，你有两三个互不触碰同一文件的功能。你用 git worktree 为每一个建独立目录，每个 checkout 不同分支，每个 worktree 里跑一个 Agent。它们不干扰是因为在分开的目录里。

**git worktree 为什么重要**：多个 Agent 跑在同一 checkout 上很快变得一团糟。它们争着改工作树，测试重叠，一个 Agent 的 WIP 改动破坏另一个的测试跑。Worktree 给每个 Agent 自己的隔离目录同时绑到同一 repo，干净解决机械问题。

流程：

  1. git worktree add ../project-featureA featureA-branch
  2. git worktree add ../project-featureB featureB-branch
  3. 每个 worktree 启动一个 Agent，各自加载同一套共享 skill 和 AGENTS.md。
  4. 每个 Agent 独立跑第 3–5 章的流程。
  5. Agent 完成后，把分支合回 main。解决合并冲突——理想情况让 Agent 处理机械的，你处理策略冲突。

Claude Code 为这件事有快捷：claude -w 标志（见 Cherny 的 15 条提示）自动为一个 session 建 worktree，你不用手动管目录。用别的 Agent 的话，上面的 shell 命令照样能用；机制是 git 的，不是任何具体工具的。

正交性的经验法则：两个功能主要触碰不同文件（比如 <20% 重叠），模式 2 能跑。重叠很重（>50%）的话，要么串行做，要么重新拆分任务边界。合并冲突吃掉的时间能轻易抹掉并行的收益。

磨合前置：你需要足够多的共享 skill（第 5 章），让两个并行 Agent 产出同一风格的代码。没有它，合并清理被风格不一致主导，令人沮丧且难自动化。这也是模式 2 大多出现在第 2 阶段及以上的原因。

模式 3：跨事务类型并行——同一功能内

动作：在同一个功能内，不同类的工作可以在同一功能上下文里并行。你为每类工作启动一个 Agent。

具体例子。你在做"订单导出 CSV"功能。三个 Agent 同时跑：

  • Agent A — 后端正确性。 围绕导出逻辑构造单元和集成测试：空输入、巨大输入、并发导出、损坏的订单。写后端实现。关上测试计划。
  • Agent B — UI 端到端。 围绕导出按钮构造 Playwright 测试：点击、验证下载、检查错误态、测试加载中的禁用态。写和调 UI 粘合代码。
  • Agent C — 已知 bug backlog。 把你一直搁着的那堆小 bug（和这个功能无关但在同一区域）清一清，这样功能发布时它们也没了。

这三个 Agent 在同一功能分支，但触不同层。协调成本中：它们共享一个分支，所以集成顺序重要。通常 A 和 C 先合进去，B 等 A 稳定后在其上跑。

这个模式为什么重要：很多功能工作都是这个形状——后端逻辑、UI 粘合、不同级别的测试、附带的 bug 清单——一个工程师天然会串行做。按事务类型拆，给你同一功能内部真实的并行，而不用付模式 2 的合并代价。

磨合前置：你要有提前把模块间接口定下来的纪律，这样 Agent B 不会一直被 Agent A 的决定堵住。这是第 5 章架构步的回报：接口预先规定的话，模式 3 跑得干净。

模式 4：Agent 内部并行——单任务内拆子 Agent

动作：你把一个大任务交给 Agent。Agent 把它拆成子任务，在每一个上跑一个 sub-Agent，合并结果。你不管分解，顶层 Agent 管。

Claude Code 的 "team" 模式和类似的 "orchestrator + workers" 模式就是实现。吸引力显然：你不用预先规划并行，Agent 自己搞定。

为什么是最难的模式：Agent 的分解只有它定义的接口契约那么好。如果 sub-Agent 得在执行途中协调（"你那个函数到底返回什么？"），它们会撞、合得差、或产出不兼容输出。你又回到了协调问题，只是现在由 Agent 解决——它可能擅长、也可能不。

当前诚实状态：模式 4 是真的——在边界清晰、范围明确的任务上能跑。在混乱的现实任务上（分解本身就是难的），模式 4 常常比单 Agent 串行跑更差，因为合并成本压倒了并行收益。

Cognition 的 Devin can now Manage Devins 从内部描述了他们的模式 4 实现：一个协调者 Devin 给每个受托 Devin 分配工作，每个跑在自己的隔离 VM 里。关键是同一团队发表了 Don't Build Multi-Agents —— 两者并不矛盾。后者是反对幼稚多 Agent 模式（不共享上下文）；前者是一个共享的实现。他们的明确原则："共享上下文，不是只共享消息" 和 "动作携带隐含决策；冲突决策导致失败"。如果顶层 Agent 不能把推理轨迹和 sub-Agent 共享，sub-Agent 不能收敛到兼容决策，模式 4 就会退化成多数怀疑报告描述的那种"混乱"。

什么时候真值得做：与模式 3 相同的条件，但在更小粒度上。如果架构步（第 5 章）把模块边界定得清楚，而每个子任务都装进一个模块，Agent 内部分解是可靠的。如果架构模糊，就不是。

对第 5 章的直接依赖：模式 4 基本是"架构设计做得好"的分红。一个模块边界定义清楚、接口契约明确的代码库自动适合并行分解。一个 Agent"边写边设计"的代码库不适合。这是"别跳过架构步、即便很想跳"最强的实用论据。

什么时候伸手：第 3 阶段及以上，在分解明显的任务上（你本可以手工用模式 3，但很烦）。把它当作替代模式 3 的省力工具，不是神奇的生产力乘数。

一次最多开几个

实用上限，粗略：

  • 第 2 阶段：一到两个 Agent。超过两个会崩。
  • 第 3 阶段：三到四个比较舒服。第五个开始要刻意的注意力纪律。
  • 第 4 阶段：五到八个，搭配模式组合。超过八个，经验丰富的工程师也会掉线。

Cherny 报告同时跑 10 到 15 个 Claude Code session。那是一个经过深度磨合的操作者、在一个成熟代码库上的高端值；不是基线。读一下他的工作流（Educative），你会看到配套机械——编号终端标签、系统通知、/commit-push-pr slash 命令、让 Claude 能测它刚造出的 UI 的 Chrome 扩展——这些存在就是为了让 15 个 Agent 能被一份注意力管得过来。没这些机械，上限会陡降。

限速的几乎从来不是 Agent 算力或工具。是你在对齐和审查阶段、在任务之间轮转时保持上下文的能力。多开 Agent 让 Agent 更多，但让人机协作时刻的决策更差——第 1 章说过，那才是真正瓶颈所在。

并行 Agent 的合适数量，就是"你的对齐和审查质量还不退化"的最大那个数。

范例——Geoffrey Huntley 的 Ralph 循环作为最小调度原语

Ralph 循环在 ghuntley.com/ralph 和 [how-to-ralph-wiggum](https://github.com/ghuntley/how-to-ralph-wiggum) 有公开记录，值得研究，因为它是有人发表过的最简单可用的并行 Agent 调度器。剥到最核心：

while :; do cat PROMPT.md | claude-code ; done

那一行就是全部调度器。让它工作的是它依赖的东西：

  • **PROMPT.md** —— 一份确定性 prompt，告诉 Agent 在每次重新启动时查看 repo 状态、挑恰好一个让它能推进的任务。
  • **specs/** —— 规格目录，Agent 用来知道"完成"长什么样的可持久产物。
  • **IMPLEMENTATION_PLAN.md** —— Agent 在多次迭代之间读写的动态计划。
  • 测试作为反向压力 —— Agent 不能 commit 一个测试失败的任务，所以坏状态自然地在那个任务上停下，直到被修好。

每次迭代都是全新上下文窗口。没有对话历史在迭代之间传递。这刻意地阻止了 Huntley 命名的主要失败模式——"上下文腐败"：Agent 在几小时来回之后开始重复早期错误或漂离原任务。把上下文每轮扔掉，换来新鲜度的保证，代价是一点启动成本。

Huntley 的 [how-to-ralph-wiggum](https://github.com/ghuntley/how-to-ralph-wiggum) 把循环进一步分为两种模式：

  • 规划模式 —— 读 specs/ 和当前 src/，做差距分析，更新 IMPLEMENTATION_PLAN.md。
  • 建造模式 —— 读 IMPLEMENTATION_PLAN.md，挑最重要的任务，实现、跑测试、commit。

你定期跑规划保持计划对 spec 新鲜，大部分时间跑建造。这是第 3 章 Plan Mode 那个"先规格后执行"分裂的原始版本。

为什么放在这一章而不是更早？因为 Ralph 是把 shell 循环当成模式 2 / 模式 3 调度器来用，不绑工具。你可以对着 Claude Code、Codex、任何 Agent CLI 跑。两个 Ralph 循环在两个 worktree 里是模式 2。两个 Ralph 循环在同一 worktree 里对着不同的 PROMPT.md（一个后端、一个 UI）是模式 3。值得理解是因为每一个托管产品（Claude Code 的 team 模式、Cursor 的背景 Agent、Devin 的 managed Devins）本质上都是这个模式加一层人机工学。

范例——Armin Ronacher 的 "Pi" 最小 harness（2026 年 1–2 月）

如果 Ralph 是最简单调度原语，Pi 是相反动作的最干净范例：通过一个刻意最小化、Agent 可以自己修改的 harness 跑并行 Agent。Armin Ronacher 的三篇帖——Pi: The Minimal Agent Within OpenClaw（1 月 31）、Porting MiniJinja to Go With an Agent（1 月 14）、A Language For Agents（2 月 9）——描述的工作流围绕：

  • 微小核心，只有四个工具（Read、Write、Edit、Bash）。其他一切都是 Agent 自己能写的扩展。
  • 自修改扩展。 Pi 热加载 Agent 在 session 里写的扩展——所以 Agent 真的在学任务的同时扩展自己的 harness。
  • 分支作为一等操作。 Pi 让 Ronacher 把 Agent session rewind 到更早的消息，然后在那里分一条新路——避免他称之为 vision quest 的失败模式，即 Agent 因为早期上下文已经漂离而重新从头来过。
  • 语言无关的重新实现。 Ronacher 从 MiniJinja 移植里的一个观察：当代码便宜，把一个库在目标语言里由 Agent 重新实现经常比跨语言构建系统搏斗容易。这是第 6 章廉价失败原则的直接后果。

对本章要紧的是：Pi 是把模式 2 和模式 3 实现为 harness 设计，而不是工具特性。 它证明你可以不依赖任何厂商的 team 模式拿到强并行——如果你把 harness 当作自己拥有的东西，原语是便宜的。

范例——Cherny 的 15 session 设置（2025 年晚期快照）

时效说明：下面的细节来自 Cherny 2025 年 12 月的公开分享。Claude Code 在四个月里已发了大量 Plan Mode、subagents、skills 的改动；把它当作这种模式的美学范例，不是当前命令参考。

美学谱的另一端是 Boris Cherny 公开分享过的工作流，它用 Claude Code 的托管特性而非 bash 循环。这个配置，从他的 X 推文、他的 15 条提示汇编 和 Educative 整理 拼出来，大约是这样：

  • 五个终端标签 编号 1–5，每个跑一个 Claude Code session，通常在由 claude -w 创建的独立 worktree 上。
  • 另外五到十个 session 跑在 claude.ai 浏览器标签上，用 claude --teleport（或 session 里的 /teleport）在终端和 web 之间移动 session。
  • 移动 session 从他手机上启动和查看。
  • 每个 repo 根目录的 **CLAUDE.md**，每次 Agent 犯一次值得阻止的错就多一条。
  • Slash 命令 处理交接里可重复的部分—— /commit-push-pr 一把完成 stage、commit、push、开 PR；定制的命令处理那个代码库里常见的工作流。
  • Subagent 做专门角色——code simplifier、test verifier——在主 session 里需要时被调起。
  • 生命周期钩子—— PreToolUse 记录 shell 命令，Stop 在 Agent 早早宣布完成时让它继续跑。
  • **/loop 和 /schedule**—— 把工作流变成持久运行的 skill。Cherny 的例子是 /loop 5m /babysit 每 5 分钟跑一次维护任务。
  • 一个 Chrome 扩展 让 Claude 看和点击它刚建的 UI —— Cherny 说这是 UI 工作质量的 2–3 倍乘数。
  • 系统通知 只用于"Agent 需要输入"，绝不用于"Agent 完成"。这把 inbox 模式转成 pull 模式，是他配置里被抄得最多的一个细节。

注意这个配置实际在做什么。CLAUDE.md 是钥匙 #3 编码成的动态文档。slash 命令和钩子是在执行边界上机制化对齐和交接。Chrome 扩展是第 4 章的 Agent 当用户测试。编号标签 + 通知是调度原语。claude -w worktree 标志是模式 2。Cherny 基本上把这本书的主论点烤进了他的日常人机工学，15 session 的吞吐就是结果。

你不需要 Claude Code 的具体特性来复现。上面每一条都有 shell 脚本对应；Huntley 的 Ralph 循环是存在性证明。"边界机制化，注意力在中间轮转" 这个模式才是要紧的。

完整一天范例——混合模式

具体化一下，第四阶段一天大概是这样：

  • 早晨 9:00–9:30：对齐项目 A 功能 1（模式 1）。交给 Agent A1。
  • 9:30–10:00：对齐项目 A 功能 2（模式 2——独立 worktree）。交给 A2。
  • 10:00–10:20：对齐项目 B（模式 1）。交给 Agent B1。
  • 10:20–10:45：Agent A1 带着测试计划回来。按复杂度分层审。批准。A1 开始实现。
  • 10:45–11:15：并行地，A2 带计划回来，B1 对 spec 有问题。答 B1；批 A2。
  • 11:15 往后：A1 在实现。对 A1 启动一个模式 3 子并行做 UI 测试（同一功能上第二个 Agent）。同时在项目 B 上对一个小重构启动 best-of-N（第 6 章）——两个替代尝试，各 30 分钟。
  • 下午：读报告。批准合并。挑 best-of-N 赢家。开始下一轮。

那是一天里七八次 Agent 运行、三个项目、四种模式在用。限速器不是工具。是你保持每个交接形状在脑子里、再干净地回到它的能力。

反模式

  • 在第一阶段就伸手抓模式 4。 你会看到 sub-Agent 在从未定义过的接口上撞车，得出"Agent 内部并行没用"的结论，然后怪这个特性。特性没问题；你还没准备好。
  • 不用 worktree（或等效隔离）做模式 2。 两个 Agent 在一个 checkout 上是合并冲突制造机。别。
  • 没做架构步就跑模式 3。 没定义接口的同功能 sub-Agent 会漂、会打架。先定义。
  • 在其实真正瓶颈是某个项目早期需要你注意力的时候做模式 1。 跨项目并行帮不了——如果一个项目吸收了 80% 的认知预算。

外部声音

  • 支持：git worktree 在 AI 辅助开发圈子里是已知技巧有一段时间了；值得搜从业者的自建设置脚本帖。Anthropic 的 Claude Code 团队文档从内部描述了模式 4。
  • 反驳：大量（HN、X）报告模式 4 在真实工作上失败。这些几乎都是准确的报告，应读作"模式 4 需要架构前置"，不是"模式 4 坏了"。

下一章

第 8 章讲并行执行跑通之后冒出来的瓶颈：产出多到你读不过来。解法是把同一把戏再往上套一层——让 Agent 分诊 Agent。

第 8 章：消化产出

论点：一旦并行执行跑通，瓶颈就会迁移到"你看不完报告"。解法就是把同一个把戏再往上套一层：让 Agent 来消化 Agent 的产出。

没人警告你的那个问题

到第三阶段你有三四个 Agent 每天产出真正有用的工作。第三部分的三把钥匙把你从对齐、正确性、可维护性的实时回路里挪走。第 7 章的调度模式让你把它们摊到跨项目、跨功能、跨事务类型。吞吐真实。

然后你撞到新墙。不是代码。是报告。

每个 Agent 每天产出：

  • 一两个 PR
  • 一组测试结果
  • 一份 Agent 当用户测试报告
  • 一份设计 / 架构总结
  • 一份它做不了想要输入的事清单
  • 有时候还有一份后续建议清单

乘以四个 Agent，每天你有一堆几十条杂质混合的产物要处理，每条都索要某种量的你的注意力。你以前卡在写代码上，现在卡在读你自己 Agent 的产出上。第 1 章的主题以全力回来：瓶颈只是转移，不会消失。你只是又挪了它一次。

这就是破进并行 AI 开发的工程师开始燃尽的那个点。不是因为工作差——吞吐比以前强——而是因为一天读 24 份质量参差的报告，认知上比一天读一个 PR 贵得多。

新瓶颈的结构

和第 1 章的三个卡点不同，这个瓶颈不关于判断。它关于未加区分的信息体积。工作是：

  • 扫过所有进来的东西。
  • 注意两份报告在讲同一个底层问题。
  • 注意一份是关键阻塞、另一份是"有就好"。
  • 把每条路由到对的后续（另一个 Agent、你自己、忽略）。
  • 保留该保留的，扔掉该扔的。

这经典地是分诊。而分诊从结构上就是Agent 擅长的工作——只要你给它对的输入。解析报告、按主题聚类、按严重度排序、每条写一句总结：这在任何现代 Agent 能力内。缺的不是能力，是管道的结构。

示意图：多个执行 Agent 的产出汇入分诊 Agent；你只处理需要拍板的事项

把戏：让 Agent 分诊 Agent

动作是把 Agent 产出流当作代码一样对待：一个不应该需要你在内循环里的东西。

一个分诊 Agent 坐在执行 Agent 下游。它的工作是：

  1. 读自上次扫描以来所有新报告。 PR、测试结果、用户测试报告、bug 清单、设计总结。
  2. 聚类。 把描述同一底层问题的报告聚在一起（两个 Agent 都说 staging DB 慢；三份 UI 报告都是同一条文案问题；等等）。
  3. 排优先级。 按简单的两轴 rubric 给 cluster 排——用户影响 × 有没有变通办法，或类似的。第三阶段及以上的工程师，具体 rubric 不如一致性重要。
  4. 路由。 每个 cluster 拿一个处置：升给你、送回执行 Agent 修、记为已知问题、丢弃。
  5. 总结。 产出一份短的人类可读报告：今天需要你注意的事，排好序，每条一句理由。

你读分诊 Agent 的总结。可能十条而不是一百条。你对升级的做决定。其它已经路由了。

这和三把钥匙的模式一样：你被从"未加区分体积"阶段里移出来，只放在决策点上。

为什么管用

分诊 Agent 相对你做同样工作有三点优势：

  1. 耐心无限。 它以同样的注意深度读完 24 份报告。你不会。
  2. 体量上的模式匹配。 把五十项按主题聚类，这件事对人类急剧退化，对 Agent 不。当天第二十九项拿到的分析质量和第一项一样。
  3. 一致性。 它用的 rubric 对每一项都一样地用。你自己的 rubric 会随你累而退化；它的不会。

它也有真实局限：分诊 Agent 只跟它的输入一样好，执行 Agent 产出垃圾报告，它就造垃圾堆。这又是一次 skill 的论据——执行 Agent 的报告应遵循结构化形状。

诚实谈成熟度

这一章我最需要说实话的地方是：分诊层不是一个已解决的产品。你可以建。我建过一个（zero-review/auto-triage skill 是参考实现，仍在开发中）。但你现在还拿不到一个预装的。

你能做的是：

  • 定义一个结构化报告格式，要求执行 Agent 产出（作为 skill 加载）。
  • 在每个工作周期末跑一个独立 Agent 作为分诊 skill。
  • 迭代 rubric。第一版会升级过多或过少；几周打磨。

这（恰当地）又是磨合期露面的地方。分诊层随着你学你这些 Agent 常犯什么错而成熟。

参考：[zero-review/auto-triage](https://github.com/A7um/zero-review/tree/main/skills/auto-triage) （开发中——部分参考）

分诊层成熟前你能做的

今天就能部署的短期防守：

  • 批量读。 别像看聊天消息那样看报告。每天两三个 inbox 处理窗口。想把报告当聊天消息处理会撕碎你的注意力。Mitchell Hashimoto 明确描述过 他在深度工作时关通知，跑"下班后 Agent"让报告在夜里完成，他一次读一批产出，而不是实时读。
  • 在源头强制结构化报告。 每个执行 Agent 以一致格式产出报告：状态、做了什么、失败了什么、需要你输入的、能等的。一条强制这种格式的 skill 立刻回本。
  • 系统通知只用于"需要输入"，不用于"完成"。 Cherny 的配置在 X 上公开，他显式地把系统通知用作反弹信号——只在 Agent 需要我时告诉我，而不是它完成时。单是这一个改变把 inbox 模式变成 pull 模式，往往就是"五个 Agent 感觉像混乱"和"五个 Agent 感觉像监督"的区别。
  • 对"能等"那桶心狠。 很多报告只需要确认，不需要行动。一句"记下了，继续"往往就是对的。
  • 维护一个可见队列。 一张简单的待办清单，带 Agent 来源、日期、状态，即便没有 Agent 也给你一个粗略分诊层。一天扫一次队列——而不是每条到达时响应——本身就是大赢。

一个最小结构化报告 skill

在真正分诊层存在之前，早期最杠杆的一个加法，是一条强制每个执行 Agent 在结束工作前产出结构化报告的 skill。最小可用版本规定六节——状态（COMPLETE / NEEDS_INPUT / BLOCKED）、做了什么、测试（绿 / 红 / 未跑）、我不确定的事、需要人输入的、我推荐的后续——并禁止在这几节之外写自由散文。

这条 skill 加载到每个执行 Agent 上，就把 20 份自由格式报告变成 20 份有同样六节的报告。那时分诊 Agent——或你用眼扫——能在一小部分时间里处理这批，因为你知道该报告里哪一节找你在乎的部分。这类 skill 本身的写作细节属于 The Skill Design Book；这里要紧的是机制。它和 Cherny 的 [/commit-push-pr slash 命令](https://x.com/bcherny/status/2007179833990885678) 是同一个形状的小尺度版本——把产出强制成可预测形状，让下游消费者不用每份都从头读。

结构化报告是分诊层成熟之前你能部署的最大单一收益。 本章你只做一件事，就做这个。

二阶效应

分诊层跑起来后，会发生不显眼的事。你的执行 Agent 开始产出更好的报告，因为：

  • 你不再读单个报告。你读分诊总结。
  • 分诊 Agent 因此是执行 Agent 产出的主要消费者。
  • 于是执行 Agent 的 skill 演化以产出分诊层能干净摄取的报告。

这是正循环。管道的结构开始编码一个共享报告 schema，不需要有人自上而下设计一个。你会在几周后注意到：你的 Agent 产出的报告看起来像写给机器的，因为它们就是。

瓶颈下一个去哪

你读得仔细的话已经知道：瓶颈又会转移。分诊跑起来后，下一个它出现的地方是决策层——按构造，分诊层升给你的是最难的那些。你不会每项花更少认知能量；你会在一堆更难的小堆上花它。墙钟时间下降；每决定负担上升。

第 9 章会直接处理这个。眼下的要点是：没有最终瓶颈。只有你处理过的和你还没处理的。这本书讲的就是这个序列。

外部声音

  • 支持：把决定路由过自动分诊层的模式在事件管理（PagerDuty 风格）、客户支持（Zendesk 风格）、规模化代码审查（PR bot）里久经验证。把同样模式应用到 Agent 产出是自然翻译。
  • 反驳：怀疑者（正确地）指出分诊 Agent 可能系统性地漏掉新颖失败模式——它们按模式路由，真正新问题不匹配任何模式。这是真实极限。缓解：定期（比如每周）做一次整流审，你读原始报告而不是分诊产出，专门抓分诊漏的。

下一章

第 9 章用坦白收尾：这整套不会让你更轻松。你用肌肉记忆换了持续判断力，认知成本是真实的——即便吞吐是。

第 9 章：这不会让你更轻松

论点：你用肌肉记忆换来了持续的判断力。产出在翻倍，认知负担持平甚至上升。如果你不主动给自己留缝，你会在比以前更高的产出水平上被烧穿。

不舒服的招供

到这里每一章都在讲怎么做更多事。这一章是唯一一章讲那代价是什么。

并行 AI 开发是一个加杠杆的位置。杠杆放大回报，也放大需求。美元生产力上升；生命小时生产力不上升。你会交付更多，而一天结束时你会比自己写代码那种日子更累——经常更累，因为工作的组合变了。

没有人卖 AI 生产力的时候愿意说这件事。但如果这本书不说，它就不是一本诚实的书。

Mitchell Hashimoto 的 My AI Adoption Journey（2026 年 2 月） 对这笔交易的这一面说得异常清楚。他把它描述为三阶段弧线：效率低下（痛苦的磨合期）、够用（Agent 能干了但你累）、终于工作流浮现——杠杆开始感觉自然的那一阶段。他在第三阶段明确的持续纪律：深度工作时关通知、批量读报告、你离开键盘时也让背景 Agent 在跑，这样"我不能工作时也会有正向进展"——都是专门用来让判断力储备消耗不要超过补充速度的设计。

Armin Ronacher 的 A Language For Agents（2026 年 2 月） 提出配套担忧：理解力债务。当生成看起来合理的代码变得 trivial，你积累起来的是能跑但你无法解释其逻辑的代码。第四阶段的吞吐下，这笔债长得快。Ronacher 的指导不打折扣：如果你没法解释代码，它就还没准备好发布。 单这条规则就把 Agent 本该移除的一部分认知负担又装回来了——从某种意义上说，这就是本章的全部要点。

Simon Willison blogmarks 里引用的研究（Ranganathan & Ye）发现 AI 并不减少知识工作，而是强化它：开发者 juggle 更多活跃线程，不更少。三位先驱都在第四阶段成功工作。没有一个把体验描述为放松。

你一天到底变了什么

想一个传统工程师一天的感觉。你坐下来，接任务。想一会儿、写点代码、跑起来、再想、调整。认知曲线是混合的：一些分钟密集（调一个难 bug、把抽象做对），更多分钟半自动（打你打过一万遍的样板代码、接表单、写直白循环）。你的手和脑交替用。卡住时有一个半自动动作——"先试显然的那个"——后台认知可以带着它跑，前台注意力恢复。

现在比较第四阶段并行一天。半自动工作你花的时间几乎没有——Agent 做了。留给你的是判断工作，持续：

  • 这个需求真的清了吗？（第 3 章）
  • 这份测试计划覆盖了要紧的东西吗，以匹配复杂度的深度？（第 4 章）
  • 我该批这个架构还是推回去？（第 5 章）
  • 这三次尝试里有一次够好能发吗，还是我想要第四次？（第 6 章）
  • 哪个 Agent 在跑哪个模式，我轮转得对吗？（第 7 章）
  • 分诊层这周漏了什么？（第 8 章）

每一条都是决策。 决策在认知上贵得和敲键盘不是一个量级。敲样板代码对前额叶是休息。一天什么都不做只做决策的，不是。

你从"一点体力 + 一点脑力"变成了纯脑力。吞吐更高。疲倦也更高。

%%{init: {'theme':'neutral'}}%%
pie showData
  title 粗略时间占比变化（第四阶段典型一天，示意）
  "判断 / 决策" : 5
  "敲字 / 常规执行" : 1

为什么吞吐上而"放松感"不上

粗略算一算典型一天的变化：

  • 敲字小时：6 → 1。大赢。
  • 思考小时：2 → 5。大亏。
  • 总小时：8 → 6。小赢。
  • 交付件数：1 个功能 → 3 个功能。大赢。

标题是真的：更多交付、更少小时。但那些小时的分布惨烈。五小时持续决策、几乎没有减压窗口，比八小时混合工作更耗尽。你的生产力上升。你的储备下降。

这不是纪律不够的副产物。它是结构的。三把钥匙专门把机械工作从你的天里移出去。剩下的就是机械工作原本在遮盖的东西——事实是，你现在做的这种级别的软件工程就是持续判断。

主动护住缝隙

能在这个角色上跑长远的工程师，不是"工作更用力"的那个。是刻意保护休息窗口并把它当作基础设施的那个。

一些有用的实践：

  • 批量读 Agent 产出。 别当聊天消息对待。一天两三个专门读窗口，其它时间关通知，给你上下文切换预算花在对齐而不是反应上。
  • 早上做对齐，下午做审查。 对齐要深度注意力；审查要的少。把认知状态匹配到任务是实打实的百分点。
  • 在决策预算处硬停。 一天做了 15 个实质决策后，你下一个决策明显比第 5 个差。停。剩下的活留到明天。
  • 别把"放手"和"自由"搞混。 Agent 在跑；你可以再开三个。单 Agent 的边际成本对你来说小——但非零。加 Agent 填本该休息的时间，是这种工作流通往燃尽最快的路。
  • 保护无结构思考时间。 你仍然需要时间想项目的形状、而不是当前任务的形状。那时间不会自然出现；你必须安排。
  • 刻意定期跳出循环。 每周一天不碰 Agent。这样做之后，你工作那些天的杠杆回报会上升，不会下降。

一个有用的重构

我找到最有用的重构：你不再是软件工程师。你是一个软件工程系统的操作员。

手工写代码的独立开发者像铁匠：上手、一次造一件、疲劳由工作的物理节奏定速。第四阶段跑并行 Agent 的工程师像工厂主管：设计产线、设定质量线、走地板、在有问题时介入、让几个工位协调。

工厂出更多。主管也在一天结束时更累，以不同方式累——没烫手的疤，但判断储备被抽干。他没法在一天结束时"再多工作一小时"；判断不像打字那样线性按时间 scale。

这不是坏交易。做了切换的人大多不会回去。但它是一笔交易，不是每个轴上都赢。

什么时候慢下来

过度扩张、该收回来的信号：

  • 你不再真读测试计划就批。
  • 分诊 Agent 在升级东西，你该再升的没升。
  • 你逮住自己在直接写代码而不是走管道——不是因为更快，而是因为想管道感觉像费劲。
  • 你对 Agent 发脾气，而那些事其实是你的责任（对齐模糊、测试计划不清）。
  • 到周末你讲不清哪个项目在好状态。

任一条都是把并发降几天、恢复储备、在更低水平重启的信号。杠杆会在你回来时还在。

诚实底线

并行 AI 开发，在本书作者的经验里，是一个软件工程师工作生涯里自源代码管理引入以来最大的生产力变化。它确实是工作日上你能交付的 3–5 倍乘数。它也是一种日均总认知负担更高（而非更低）的工作流。

这两条都是真的。只告诉你第一条而不提第二条的人在推销。只告诉你第二条的人一般从未走出第一阶段。

这本书的目标，是把这笔交易说清楚到你能带着知情去选——然后，选了以后，给你一个合理的机会达到它真正回本的状态。

你在用肌肉记忆换持续判断力。那笔交易交付更多工作。它不交付更少你的工作。

外部声音

  • 支持：知识工作燃尽研究一致发现——纯决策的认知曲线（相对于混合认知加自动工作）是疲惫的强预测因子。工程管理文献（Will Larson 的帖尤其）捕捉了从"做"到"决定"的转变，这在本章描述的切换里映射得很近。
  • 反驳：一些从业者报告 AI 并行让他们更放松，不更累，因为重复劳动没了。对某些人这是真的——尤其是那些本来日子主要是样板、现在有了更多创造时间的人。性格重要。本章的警告最适用于那些本来就跑得热的工程师。

下一章

第 10 章收尾：这九章里的一切都推广到代码之外。任何能拆成独立子任务的东西都遵循同样的规则。代码只是第一个把回路关上的领域。

第 10 章：不止于代码

论点：任何可以拆成独立子任务的脑力劳动，都遵循同样的规则。写代码只是第一个把整个闭环跑通的领域——理解这一点，就能预测下一个会被跑通的是哪里。

为什么代码是第一个

如果本书框架（三个卡点、三把钥匙、四种调度模式、磨合期）其实讲的是知识工作，为什么代码先到这一步？

三个结构原因，它们值得命名，因为它们预测下一个这套传给谁：

  1. 代码有形式化验证。 测试给你"这是对的吗？"一个自动答案。你能跑、得到绿或红、Agent 能闭合自己的循环。几乎别的知识工作没有这个原生属性。
  2. 代码有廉价失败。 错实现被测试几秒内抓到。错的诊断、错的策略备忘、错的设计被一个人在更晚时候、用更高代价抓到。
  3. 代码有成熟的工程文化。 软件工程关于模块化、测试、接口设计已经吵了几十年。Agent 到来时，有一套词汇（Ousterhout、Martin、Beck）准备好被编码成 skill。大多数别的领域缺这个。

把这三个拿掉，你得到相反：Agent 不能自验证、失败昂贵、没有继承的纪律可编码。那个领域不能跑三把钥匙剧本。能跑它的那些领域，是和这三个条件有最强类比的那些。

同一框架，重新应用

考虑数据分析。把"代码"换成"分析"：

  • 卡点 1（需求对齐）：我们用这份数据到底想决定什么？哪个利益相关方会据此行动？
  • 卡点 2（正确性）：分析方法论上站得住吗？假设成立吗？这是难的那个——没有 npm test 等价物。但有一份"分析的测试计划"：假设清单、敏感性检查、替代切片。Agent 能跑这些。
  • 卡点 3（可维护性）：下一个碰这份数据集的人理解做了什么吗？推导可重现吗？管道有文档吗？

三把钥匙直接翻译：

  • 需求对齐 → 定义分析要驱动的决策。用第 3 章的两种技术，不动改。
  • 正确性当契约 → 在分析之前构造方法论检查表。让 Agent 跑并报告失败。
  • 纪律编码 → 把数据团队约定（notebook 怎么组织、中间产出住哪、单位和来源怎么文档化）编码成 skill。
flowchart TB
  D[可拆分的知识型任务]
  D --> Q1{正确性检查<br/>能否被规格化？}
  Q1 -->|强| K[三把钥匙 + 并行模式适用]
  Q1 -->|弱 / 主观| H[人审为主<br/>并行面收窄]

这不是推测。一些团队在做。磨合期看起来熟悉：第一阶段混沌、第二阶段觉察、第三阶段模板、第四阶段杠杆。同样的曲线。

闭环正在关上的其它领域

一份带主观倾向的部分清单，按接近程度粗排：

  • 数据分析。 已经走得挺远。带 Agent 写方法论的分析 notebook、对着方法论清单跑、用 skill 编码团队约定。今天一些团队已经能出货。
  • 研究 / 文献综述。 测试计划类比是"什么算相关来源"和"综述必须 address 的主张"。多个 Agent 能在不同子问题上并行评审。合并是总结。
  • 设计 / UX 探索。 best-of-N 是自然动作：对着共享 spec 的多次设计尝试，人挑。skill 编码设计系统。Agent 能对着无障碍和一致性检查表批评彼此工作。
  • 写作（长篇、技术）。 这本书就在这样起草。章节大纲是需求。一致的声音是测试计划（Agent 当读者检查声音断裂）。skill 编码风格指南。多章并行起草。
  • 法律 / 合规评审。 契约清晰（"这些条款必须 / 禁止出现"）。成熟；瓶颈是职业责任，不是技术。
  • 策略 / 决策备忘。 更难，因为没有自动"对答案"测试。但对齐先 + 多尝试 + 筛这个模式在立 frame 上仍大有帮助。
  • 运维 / 事件响应。 第 8 章的分诊层本身就是一个版本。Agent 驱动的 runbook 执行、分诊只在新颖失败时路由给人，正在快速演进。

注意模式：走得最远的领域是"什么算对"可以被规定、即便不能被完全自动化的领域。 落后的领域是正确性真正主观、抗拒编码的领域。

什么还翻译不过来（暂时）

诚实谈极限：

  • 硬件受限工作。 Agent 能规划和文档化物理实验；它不能跑实验室。直到机器人学跟上，物理迭代循环留给人。
  • 要大量隐性判断力的工作。 临床医学、高级谈判、法庭辩护。Agent 能准备和辅助；它目前不能替代一个看过一万个案例的从业者的隐性能力。
  • 一次错的产出不可恢复的任何东西。 运载火箭代码。外科。货币政策。廉价失败假设（第 6 章）崩塌，整个并行剧本急剧收紧。你仍然可以用，但你要给廉价失败重新定价。

边界会挪。机器人学会关上硬件缝隙。更好的 Agent 不确定性校准会扩展高风险工作的安全范围。当前"翻译不过来"清单是一个快照，不是判决。

这对读者意味着什么

如果你是拿这本书做代码的工作工程师，最后一章仍然可操作：你在磨合期里建的 skill 能泛化。不是具体代码 skill——那些绑在你代码库上——而是元 skill：

  • 怎么结构化需求对齐。
  • 怎么写一份实际是验收契约的测试计划。
  • 怎么把纪律编码成可加载文档。
  • 怎么在不被产出淹没的情况下调度并行工作。
  • 怎么保护你的缝隙不被杠杆抢走。

这些元 skill 比任何具体代码库 skill 都值钱，因为它们迁移。你代码之后进入的每个新领域都会有它自己版本的三个卡点、三把钥匙、四种模式。你会比别人更快认出它们，因为你先在代码里见过。

元框架，最后一次

把整本书剥到一句话：

并行 AI 生产力不是 Agent 能力。它是一种你和你的 Agent 通过机制化你的注意力过去被强制串行化的那三个位置、相互适应出来的工作流。你能机制化那三个位置的领域，就是这套东西能跑的领域。

这句话短到能记。它也几乎完整——磨合期、调度模式、廉价失败相变、第 9 章的诚实代价，都是它的隐含后果。

收尾

本书的框架带倾向。它也没完成。分诊层（第 8 章）在积极开发中。模式 4（第 7 章）真的是前沿。这一章讨论的向代码外的翻译是最早期的。如果你在一年后读这本书，有些细节看起来过时，论点的形状——瓶颈转移、钥匙解锁、磨合真实、诚实代价——应该还在。

如果那个形状也不在了，那是有人找到了更深的框架。那也是个好结局。

外部声音

  • 支持：AI 增强工作流的写作在研究（各种"AI 辅助文献综述"帖）、写作（Ethan Mollick 的 Co-Intelligence）、策略（ops/strategy 圈新兴的"AI 辅助备忘"体裁）里都有。每一条都是在不同领域独立再发现三个卡点 / 三把钥匙的结构。
  • 反驳：上面非代码领域的专家都有真实的、常常正确的理由怀疑"他们的领域是下一个"。听这些理由。大多数是"我们没有测试计划类比"的变体——这在当下成立，未来可能改变。

结尾

感谢你读到这里。剩下的是你的——你的磨合、你的 skill、你的项目、你的并行 Agent。这本书做不了你的工作。它只能告诉你那条路有个形状，以及那个形状是什么。

祝好运。交付得漂亮。保持休息。

Atum 著 — 源代码：github.com/A7um/ParallelDevelopmentBook

引用目录

并行开发之书 的工作书目。

时效政策：本书引用的实践来自写作时过去六个月的公开写作——大致 2025 年 10 月到 2026 年 4 月。AI 编程实践演化很快；2025 年初还前沿的东西到 2025 年底经常就过时。超出六个月的来源只在下列情况被引用：（a）底层论点结构性、经久（比如 Hillel Wayne 讲测试的极限、Ousterhout 讲软件设计），或（b）该材料是当前实践的祖先、值得作为历史来引用——这时会明确标注。

下面每一条引用都带日期。相对 2026 年 4 月在过去六个月内的视作当前实践。更老的显式标注为历史或经久结构性参考。

配套作品

当前实践（2025 年 10 月 – 2026 年 4 月）

Spec-Driven Development 和 Plan Mode

2026 年需求对齐和正确性契约的主导框架。

AGENTS.md 工程

2026 年的跨工具标准，替代工具特定的 CLAUDE.md / .cursorrules。

近期能力里程碑

最近六个月的先驱实践

Boris Cherny（Claude Code 创建者）— 2025 年 12 月 X 推文和提示：

Mitchell Hashimoto — 2026 年 2 月采用回忆录：

Armin Ronacher — 2026 年 1–2 月 Pi / OpenClaw 系列：

Addy Osmani — 2025 年 12 月 / 2026 年工作流帖：

Geoffrey Huntley — Ralph 循环方法论（持续，实质性更新）：

Cognition / Devin — 多 Agent 原则：

Simon Willison — 持续实践博客：

历史祖先（2025 年 10 月之前，仅作为上下文）

这些是 2024–2025 年初引向当前共识的实践。作为历史引用——它们不是当前实践。

  • Harper Reed — My LLM codegen workflow atm（2025 年 2 月）。三文件模式（spec.md + prompt_plan.md + todo.md）的祖先，prompt 结构上仍然站得住，但按 2026 SDD 标准缺少验收标准和接口规格因而不完整。第 3 章作为祖先引用。
  • Aider — Separating code reasoning and editing（2024 年 9 月）。architect/editor 分裂是"先规格后实现"的第一次生产级表述——但当前共识（Plan Mode + SDD + Adversarial Agent）已走得远远更远。当前章节未引用。

怀疑 / 批评声音

刻意参与而非回避。

经久结构性参考（刻意更老）

这些超出六个月窗口但为结构性主张被引用，主张本身不过时。

  • John Ousterhout — A Philosophy of Software Design（2018/2021）。第 5 章的核心工程纪律原则。
  • Kent Beck — Test-Driven Development: By Example（2002）。第 4 章 TPD 对照的参考。
  • Hillel Wayne 关于测试和形式方法的极限（2018–2024）。第 4 章引用：
  • Will Larson — An Elegant Puzzle、Staff Engineer。第 9 章背景。
  • Ethan Mollick — Co-Intelligence。第 10 章触点。

工具引用

如果你在 GitHub 上读这本书，并知道一条近期（<6 月）来源该加入，欢迎提 PR。