AI Agent并行开发实战：三钥匙突破多Agent协作瓶颈

三条规矩

我在团队里定了三条规矩：

• 禁止手写代码。
• 禁止盯着看 AI 写代码。
• 禁止在代码编辑器里 review AI 写的代码。

每一条第一次说出来，都会有人觉得我在开玩笑。为什么这三条不是胡闹，是本文接下来要讲的事。

引言

进入 2026 年，AI Coding 已经从"辅助补全"走向"自主开发"。真正让生产力产生质变的，不是单个 Agent 写代码的速度变快了，而是你可以同时启动多个 Agent，让它们并行地为你推进不同的任务。

值得一提的是，可以并行的远不只是写代码。随着 Agent 能做的事越来越多——查资料、做数据分析、写文档、跑测试、回邮件、做设计——几乎所有可以拆成独立子任务的脑力劳动，都存在并行化的可能。本文只聚焦于开发这个最成熟的场景；但如果你做的是别的工作，里面的思路可以迁移过去想一想。

回到开发。这篇文章要回答的核心问题是：怎样让多个 AI Agent 并行开发，同时保证产出质量不崩塌？要回答这个问题，我们先得搞清楚：是什么卡住了并行？

三个主要瓶颈

TL;DR：真正限制 AI 开发效率的不是 AI 写得慢，而是三个必须人类深度参与的环节——它们把人变成了单点瓶颈，Agent 再多也没用。

瓶颈一：如何把需求清晰地传递给 Agent？你脑子里的想法是模糊的、隐含的、充满上下文的，而 Agent 需要的是明确的、可执行的指令。这中间的鸿沟，往往要靠反复沟通来填平。

瓶颈二：如何确保 Agent 写出来的代码功能正确？Agent 生成的代码看起来像那么回事，但实际运行起来可能到处是 bug。过去我们依赖人类去审查每一行代码，发现问题、反馈修改，如此反复。

瓶颈三：如何确保代码的可维护性？一个 Agent 写的代码也许当下能跑，但如果没有合理的架构设计和工程规范，随着项目推进，代码库很快会变成一座屎山——结构混乱、职责不清、改一处崩三处。

这三个瓶颈有一个共同特征：它们都需要人类在回路中（human-in-the-loop）。而人类的注意力是串行的、有限的。这就是为什么在过去，即便你能同时启动五个 Agent，效率也不会提升五倍——因为你依然要逐一审查它们的产出、逐一沟通需求、逐一把控架构方向。并行 Agent 最终还是堵在了人类这个单点瓶颈上。

2025年及以前：人是驾驶员，AI 是副驾

TL;DR：Opus 4.5 之前的解法共同点是"让人和 AI 更好协作"而不是"让 AI 自己把事办完"——人是驾驶员，AI 是副驾，并行没意义，只是把排队变成同时排队。

2025 下半年之前，业界对这三个瓶颈的解法共同之处是一句话：让人和 AI 更好地协作，而不是让 AI 自己把事情办完——人是驾驶员，AI 是副驾（Copilot），并行开发根本还没到来。

在需求传递方面，主流有两条路径。一条是 Spec-based 的方式，即用形式化的文档把需求描述得尽可能精确，再交给 Agent 执行；另一条是通过多轮对话，与 Agent 反复拉扯，直到它真正搞清楚你要什么。两条路都离不开人的持续参与。

在正确性保障方面，基本靠人工 code review。人类逐段审读 Agent 生成的代码，发现逻辑漏洞或边界遗漏，再把 review 意见反馈给 Agent，经过几轮修改才形成可用的代码。

在可维护性保障方面，架构设计和代码组织仍然是人类主导的工作。你需要告诉 Agent 代码应该放在哪个模块、用什么设计模式、遵循什么分层原则，否则 Agent 会按自己的"即兴发挥"来，产出的代码结构五花八门。

在这个阶段，真正的"自动驾驶"尚未到来。因此，这一时期的 AI Coding 产品大多聚焦于优化人与 AI 的协作界面：帮你更高效地聊需求（比如早期的 CodeBuddy、各类 Spec-based 编程工具），或者帮你更方便地审查代码（比如 Cursor 等 IDE 产品）。并行开发在这个阶段没什么意义——你就算开五个 Agent 窗口，它们也都在等你审代码、答问题、确认方案。

2025下半年：一轮能力跃迁

TL;DR：2025 下半年前沿模型在调试、需求遵循、Skill 规则、Computer Use 四个方向集体跃迁，让前面三个瓶颈第一次可以用机制替代人；同时失败变便宜，"多路并试择优"成了基本玩法。

2025 下半年前沿模型在代码能力、指令遵循和长程任务完成度上集体向前迈了一大步——以 Opus 4.5 为代表的一批模型让前面三个瓶颈第一次可以用机制替代人的深度参与。也就是说，真正意义上的并行开发终于有了前提条件。

这轮跃迁具体体现在四个方向：

1. 自主调试能力大幅提升。只要给 Agent 一个可运行的调试环境（终端、日志、测试框架），它就能自主定位并修复大多数日常开发中遇到的 bug。过去需要人类指出"这里有个 off-by-one error"，现在 Agent 自己跑一遍测试、读一遍报错、翻几层调用栈，就能把问题解决。

2. "理解正确"更容易转化为"实现正确"。如果 Agent 对需求的理解没有偏差，并且给了它测试环境和明确的验收标准，那么它写出的代码在经过自主测试和修复之后，功能正确性在常见业务场景里基本可以得到保障。非功能性需求（并发、性能、安全）和架构权衡仍然是例外，后文会讲。

3. 工程规范可以通过 Skill 部分内化。把软件工程的实践纪律——命名、分层、模块边界、提交规范等——以结构化 Skill 文件提供给 Agent，它就能遵守绝大部分。注意是"绝大部分"：很多设计原则本质上相互拉扯，资深工程师都经常判断不稳，Agent 在这类权衡上也会出错。这一条后文会专门展开。

4. 通用 Computer Use 能力大幅增强。Agent 不再只能读写代码文件。它能与终端流畅交互、浏览网页查文档、操作 GUI 完成配置任务，甚至有人已经把 Agent 当作一个高级 shell 在用。一个直接的后果是，很多软件的安装和环境配置文档正在变成"给 Agent 看的"——一个 Markdown 文件，Agent 就能自动把环境搭好。

这四个变化叠加在一起，意味着：人类可以从回路中大幅退出。不是完全不参与，而是参与的方式从"逐行审查"变成了"设定规则 + 验收结果 + 关键节点抽查"。这为真正意义上的并行开发打开了大门。

额外的一条隐性变化：失败变得便宜了

除了上面四条"能力"的变化，还有一条策略层面的变化值得单独说：让 Agent 试一个方案的成本，比让人类试一个方案的成本低得多。

在 AI 出现之前，你不会轻易让一个工程师"先按 A 方案实现一版，然后再按 B 方案实现一版"——人力贵到承担不起。所以设计阶段必须把所有权衡想清楚，不想清楚就开干是奢侈。换成 Agent 之后，这个约束松了——"想不清楚？那就让几个 Agent 各写一种实现，跑完测试之后对比结果再做决定。"

这件事看起来只是量变，但实际上引发了策略的质变——"多路并试，择优而用"从少见的做法变成了一种日常可选项。这条原则贯穿本文后面几种并行模式：很多场景里你做并行不是因为任务能切干净，而是因为试一下比想清楚便宜。后面讲到的"模式二"里"让 Agent 各写一种实现、择优合并"就是它的直接体现。

降低人类参与度的三把钥匙

既然瓶颈在于人的参与，解法就是用机制替代人的实时介入。下面三节分别对应三个瓶颈，给出具体做法——它们合起来，就是并行开发的底座。

需要打个预防针：这三把钥匙没有一把是"装上就能用"的——都需要你和项目 Agent 一起磨合。磨合过程中沉淀下来的东西也不止一种——Skill 文件是最显性的一种，把踩过的坑、项目约定、Agent 容易出错的模式写下来；但还有很多东西只能作为直觉和感觉留在你这里：Agent 在什么类型的任务上靠谱、什么地方必须盯着、什么情况下它的自信值得打折扣。这些感觉在文档里很难表达，但对放手的程度起到决定性作用。磨合完成之前，你乐观不起来；磨合完成之后，你才真的可以放手。

关于工具：我把自己在这几条线上的实践沉淀到了一个叫 zero-review (https://github.com/A7um/zero-review) 的框架里，作为参考实现。下面每一把钥匙末尾会指向对应的 skill，需要细节的读者可以去看。但再次强调——这篇文章讲的是思路，不是这个框架；你完全可以用别的栈实现同样的效果。

第一把钥匙：需求对齐——让 Agent 自己搞清楚你要什么

TL;DR：让 Agent 自己把需求里的隐含假设找出来、按先验排序出几份完整方案让你选——你从"回答问题的人"变成"审方案的人"。

需求不清是 AI 开发中最常见的返工原因。你以为说清楚了，Agent 也以为听懂了，结果做出来的东西和你想的完全不一样。要解决这个问题，有两条互补的思路。

思路一：穷尽式追问——让 Agent 主动暴露盲区

具体操作是这样的：你先用自然语言尽你所能地描述清楚你想要什么，然后切换到 Plan mode（或者等价地，明确告诉 Agent 不要开始写代码），向它提出一个要求："在你开始做任何事情之前，先告诉我：关于这个需求，你还有哪些不确定的地方？把你的问题列出来。"

Agent 会给你一组问题。你逐一回答，但不要让它开始规划或编码——继续追问："根据我的回答，你还有新的不确定之处吗？继续问。" 就像一场需求评审会，你是产品经理，Agent 是那个不断追问细节的开发人员。

这个过程会持续 10 分钟到半小时不等，取决于需求的复杂度。当 Agent 提出的问题开始变得琐碎或者重复时，说明核心的模糊地带已经被覆盖了。这时候再让它输出一份结构化的需求文档，作为后续开发的依据。

具体实践可参考 zero-review/auto-req 技能。

思路二：方案生成 + 人类筛选——让 Agent 猜你的意思，你只管挑

穷尽式追问虽然彻底，但耗时较长，而且本质上还是人类在输出信息。第二种思路更省力：让 Agent 自己去填补需求中的空白。

操作方式是这样的：你同样先给出一段自然语言的需求描述，但这次你不去回答 Agent 的问题，而是给它一个不同的指令："分析我的需求描述，找出其中模糊的、未定义的、或者有多种合理解读的部分。然后对每一个这样的模糊点，基于你的世界知识（如果需要，去网上搜索同类产品是怎么处理的），给出你认为最合理的 Top N 方案，并说明推荐理由。"

打个比方：如果你说"做一个用户注册功能"，Agent 会识别出一系列你没提但必须决定的问题——用邮箱还是手机号注册？需不需要邮箱验证？密码复杂度要求是什么？注册失败的提示语是什么样的？然后它会参考主流产品的做法（比如"大多数 SaaS 产品使用邮箱注册 + 邮件验证链接"），为每个问题给出推荐方案。

这种方式的核心优势在于：你从"回答问题的人"变成了"审方案的人"。审方案比回答问题快得多——你只需要扫一眼，说"行，就按你推荐的来"或者"第三个换成这样"。大量的需求细节由 Agent 基于先验知识自动补全，人类只在关键决策点上做出选择。

两种思路可以结合使用。对于你心中已有明确想法的核心需求，用思路一充分沟通；对于你不太关心具体实现方式的外围需求，用思路二让 Agent 自主决策。最终的产出是一份完整的需求文档，覆盖所有必要的细节，可以直接交给 Agent 去执行，不再需要开发过程中的反复确认。

需要特别指出：需求对齐是整个流程里唯一不能真正并行的一步——它要吃掉你的深度注意力。这个约束在后面讨论并行调度时还会再提到。

第二把钥匙：功能正确性——测试计划驱动开发

TL;DR：开发之前先写覆盖单元/集成/E2E 的完整测试计划；测试计划必须由另一方（另一个 Agent 或你）独立审过，防止同一个 Agent 同时污染测试和实现。非功能性需求再写专门的 Skill。

人类不再逐行审查代码，那谁来保证代码是对的？答案是：测试。但不是随便写几个测试——而是在开发之前，先产出一份完整的测试计划。

做法如下：在 Agent 动手写任何业务代码之前，先让它根据需求文档输出一份测试计划。这份测试计划应该覆盖三个层次：单元测试，验证各个函数和模块的行为是否正确；集成测试，验证模块之间的协作是否符合预期；端到端的功能测试，模拟真实用户的操作路径，验证整个功能流程是否跑通。

这些测试用例代表的是"一个正确实现所必须满足的全部条件"。它们在开发开始之前就确定下来，成为 Agent 开发过程中的验收标准。Agent 完成代码编写后，自行运行这些测试。如果有测试未通过，Agent 会自动进入调试-修复循环，直到所有测试全部通过。

这种模式下，你不需要去读 Agent 写的每一行代码。你只需要审核测试计划本身是否合理、是否覆盖了关键场景。审核测试计划的认知成本远低于审核实现代码——因为测试计划描述的是"应该发生什么"，而实现代码描述的是"具体怎么做"。前者你作为需求的提出者天然有判断力，后者则需要深入理解代码细节。

前提：Agent 能动手，才谈得上测试

Agent 自己跑测试、自己 debug、自己做端到端——这一切建立在一个被频繁省略的前提上：它得有一个能真正操作这个系统的环境。很多团队交给 Agent 一个只有源代码的 docker，然后奇怪为什么 Agent 测不出问题。

"能操作"不只是"有一个能跑的 docker image"。你要根据应用类型，把对应的操作能力一起暴露给 Agent：

• 命令行 / API —— shell + 日志 + 测试框架，门槛最低。
• 网页应用 —— 除了让服务跑起来，必须暴露browser use 能力（Playwright 服务、带 CDP 端口的 headless Chrome、或者 VNC）。没有这一层，Agent 没法真的点按钮、没法看页面响应、没法做真正的端到端测试。
• 桌面 / GUI 应用 —— 必须暴露GUI use 能力（X11 forwarding、xdotool、截屏管道）。不然 Agent 只能"想象"用户操作的样子。
• 复杂系统（状态机、异步、并发、长时进程）—— 除了日志，必须暴露调试器（gdb / DAP / Chrome DevTools 协议 / 语言自带 debugger）。让它能挂断点、看变量、看调用栈，而不是在 bash 里堆 print 语句硬猜。

一个朴素的自测：想象一个只能用你提供的工具的新人工程师——他能不能复现一个线上 bug？如果他做不到，Agent 更做不到。

给 Agent 的能力要和给工程师的能力对齐。这是 TPDD 本身能成立的地基——配不到位，后面的测试计划、独立审核、角色扮演，全都是纸上谈兵。

为什么测试计划必须有一道独立的审核

这里有一个容易被忽视的陷阱：如果测试计划和实现都交给同一个Agent 完成，那么它对需求的理解偏差会同时污染测试和代码——测试和代码一起错，一起全绿，你还以为一切 OK。

这是 TPDD 范式最大的一个逻辑漏洞。解法是：测试计划必须有一道"独立"的审核，才能进入实现阶段。

"独立"至少有两种实现方式：

• 人类审。你作为需求的提出者、或一个资深同事，用业务视角去审。优点是带着领域常识和业务判断；缺点是占你的深度注意力、不能并行。
• 换一个 Agent 审。开一个全新会话的 Agent，只给它需求文档和测试计划（不给它实现上下文），让它挑毛病。本质上是多 Agent 交叉验证——一个 Agent 的理解偏差不太会和另一个新会话 Agent 的偏差完全重合，所以能抓住相当一部分由"理解偏差"造成的错误。优点是便宜、可并行、不会疲劳；缺点是它的业务视角仍然是二手的。

两种审核方式不是非此即彼，可以按项目复杂度搭配使用：

• 复杂度低、风险可控的项目（内部工具、原型、探索性实验）——让另一个 Agent 审一遍就够了；你扫一眼结论确认大方向没跑偏即可。
• 复杂度高、错了代价大的项目（线上关键路径、金融相关、多人协作的核心模块）——Agent 先审一遍过滤掉明显的坑，再由你做一轮业务视角的审核，特别关注三类盲区：(a) 边界条件是不是齐了；(b) 错误路径和异常分支覆盖到没；(c) 测试是不是真的在验证"应该发生什么"，而不是"已经发生了什么"（自我循环）。

换句话说，审核这一步不能省，但审的主体和深度要和项目复杂度匹配。最关键的是"独立"——审的那一方不能和写测试+写实现是同一个会话的同一个 Agent。只要这条守住了，污染就大概率能被挡掉。

功能测试覆盖不到的场景：再写专门的 Skill

基础的单元/集成/端到端测试解决的是"功能正确性"。但项目里还有几类需求不属于功能性，默认的测试计划覆盖不到它们：

• 非功能性需求——并发竞争、性能瓶颈、内存泄漏、安全边界。
• 长期演进后的行为——一段代码今天通过所有测试，但半年后十次迭代叠加之后可能就乱套了。

解决思路仍然是延续第二把钥匙的做法：把这些特定领域的测试范式写成专门的 Skill 文件，交给 Agent 自己执行。举几个例子：

• 压力测试 Skill：告诉 Agent 如何构造高并发负载、如何观测 p50/p99/p999、如何识别退化曲线、什么叫 SLA 破线。它能自己搭起 k6 / locust / wrk 环境，按预设的压力阶梯跑一遍，然后生成带图表的报告。
• 混沌测试 Skill：约定哪些依赖（数据库、下游服务、网络）要被随机故障注入，Agent 按规则模拟 kill、延迟、丢包等场景，验证系统的降级和恢复。
• 安全测试 Skill：常规漏洞类型（XSS、SQLi、权限越权、CSRF……）的自动化探测逻辑。Agent 像一个初级渗透测试员一样把常见攻击面扫一遍。
• 回归演进测试 Skill：在 CI 里定期对关键模块跑一轮"架构劣化自检"——文件是否变得太大、单函数复杂度是否超阈、模块间依赖是否变环。这个能抓到一部分"长期演进后才出问题"的苗头。

这些 Skill 的设计思路和前面的 TestPlan 是一致的：先把这个领域里"做对长什么样"用结构化的方式写清楚，再交给 Agent 自主执行。写 Skill 的过程本身就是一次把领域知识沉淀下来的机会。

还剩一类 Skill 解决不了的：架构级决策——同一个需求可以有好几种结构都"正确"，代价和权衡不同。测试能验证"能不能跑"，但验证不了"这是不是最好的拆法"。这本质上是业务语境下的价值判断，只能靠你自己（或者一个资深同事）做 spot-check。

换句话说，"人工必看"的范围比看起来小得多。大部分所谓"测试覆盖不到"的场景，其实是你还没为它写 Skill。真正非看不可的只剩架构级决策——TPDD 不是让人类彻底不看代码，而是把人类注意力从"每次都看"调整成"只看真正需要业务判断的时候"。

具体实践可参考 zero-review/auto-dev 技能。

小知识：测试驱动开发（TDD）vs 测试计划驱动开发（TPDD）

熟悉软件工程的读者可能会觉得这套思路似曾相识——它确实脱胎于经典的测试驱动开发（Test-Driven Development, TDD），但在 AI 协作的语境下有关键的不同。

TDD 的经典流程是"红-绿-重构"：先写一个会失败的测试（红），再写最少量的代码让它通过（绿），然后重构代码改善结构，如此循环。TDD 的粒度很细，每次只关注一个极小的行为增量，它假设的是人类开发者在编码过程中逐步推进，每一步都有即时反馈。

而测试计划驱动开发（Test-Plan-Driven Development, TPDD）则是先一次性产出覆盖整个需求的完整测试计划，然后将开发和测试执行整体交给 Agent。粒度更粗，但自动化程度更高。它的设计初衷不是指导人类一步步写代码，而是为 Agent 划定一个"正确性边界"——你不用盯着 Agent 怎么写，只要最终所有测试都绿了（而且测试本身是人类审过的），你就可以有相当高的信心认为功能是对的。

换一种方式理解：TDD 是人类开发者的编程纪律，TPDD 是人类给 AI Agent 设定的验收契约。TDD 的价值在于驱动设计和保持小步快跑的节奏；TPDD 的价值在于让人类可以放手，让 Agent 自主完成从编码到验证的完整闭环。

（说明：TPDD 是我们为了和 TDD 对照而起的简称，不是业界通用术语。）

更进一步：让 AI 模拟真实用户进行测试

除了基于代码的自动化测试，我们还可以利用 Agent 的 Computer Use 能力，让它以"用户"的身份实际操作软件界面。Agent 根据需求文档中的用户故事，自动生成真实的使用场景，然后通过浏览器或 GUI 操作逐步执行这些场景，验证软件在真实交互环境下的表现。这类测试特别适合捕捉那些自动化测试难以覆盖的问题——比如页面布局错乱、交互流程不流畅、错误提示不友好等。

让 AI 模拟用户做测试的一个关键技巧是：派它扮演不同类型的用户，每种用户有不同的盲点和耐心。

• 新手用户——只认屏幕上看得见的按钮和标签，看不懂技术术语，错两三次就放弃；他看不到浏览器控制台、看不到网络错误，响应时间只能形容为"感觉慢"。
• 熟手用户——会主动尝试绕路、找临时办法。
• 对抗性用户——故意试异常输入、灌超长字段、乱点顺序。

每种角色的"看不到"才是精髓——强制 Agent 用那个角色的眼睛去看、去写报告。新手角色下的 Agent 只能写"点了保存页面白了 5 秒"，它写不出"初始化失败了"——因为它根本看不到控制台。这保证反馈真的是 那类用户 会发出的反馈，而不是工程师视角下的二次翻译。不同角色会暴露完全不同的问题：新手暴露术语晦涩和主流程走不通，熟手暴露快捷路径缺失，对抗性用户暴露输入校验漏洞和异常崩溃。

具体实践可参考 zero-review/auto-test 技能。

第三把钥匙：可维护性——用工程纪律约束 Agent 的行为

TL;DR：把"好代码"的设计原则写进 Skill 文件，让 Agent 在编码和自审查时逐条对照；剩下架构级的权衡由你 spot-check。

正确性靠测试保障，但可维护性靠什么？靠规则。

软件设计领域有一套经过长期验证的核心原则（很大程度上受 John Ousterhout 的 A Philosophy of Software Design 影响），它们的共同目标只有一个：控制复杂度的增长。在 AI 开发的语境下，这些原则可以编码为 Skill 文件注入给 Agent，让它在编码和自审查时有据可依。以下是最关键的几条：

• 模块深度。好的模块对外接口简单、内部功能深厚。Agent 天然倾向于过度拆分——把类切得很小很细，形成一堆浅层模块。明确告诉它：不要为拆而拆，每个模块应该用简洁的 API 藏住足够多的复杂度。
• 信息隐藏。模块之间不应该共享各自的内部实现知识。一个常见的反模式是按时间顺序拆模块（"先做 A 再做 B，所以拆成两个"），这种拆法几乎必然导致信息泄露——拆分的依据应该是"谁拥有这个知识"，不是执行顺序。
• 抽象分层。每一层应该提供一种不同的思维模型。如果一层只是把调用原封不动地转给下一层，这一层就没有存在的意义。更重要的是，复杂度应该往下压——底层模块主动承担更多处理，让上层代码保持简洁。
• 内聚与分离。必须同时理解才有意义的代码应该在一起；把通用逻辑和特例逻辑混一起导致两者都难以理解的，就该分开。避免产出"不读完另一个函数就无法理解当前函数"的耦合代码。
• 错误处理。异常的泛滥是复杂度的隐形杀手。好的设计尽量"把错误定义掉"——通过调整语义或设计默认行为减少需要处理异常的位置，而不是到处 try-catch。
• 命名与显而易见性。代码应该让读者第一眼就能正确猜出它在做什么。命名要精确、整个代码库要一致、不要违背读者的直觉——任何新加入项目的开发者读到这段代码时都不应该"感到惊讶"。
• 文档与注释。注释应该描述代码本身无法表达的东西——设计意图、为什么选这种方案、接口的抽象语义。重复代码已经说过的是冗余，遗漏代码说不了的是缺失，两者都是坏注释。
• 战略式设计。每一次修改都是对整体设计的一次投资，而非战术性的快速补丁。抵制"先让它跑起来再说"的诱惑——走捷径省下来的时间最终会以几何级数的复杂度还回来。同时也要警惕过度设计：解决眼下的问题就行，不要为假想的未来需求构建用不到的抽象。

一个必须坦诚的事实：这些原则本身就相互拉扯

上面八条原则并不是一套可以机械套用的 checklist。它们之间存在内在的张力：

• 深模块说"功能深、接口简单"；小而组合说"一个模块只做一件事"。这两条在"一个类该多大"这件事上经常打架。
• 战略式设计说"这次多投入一点是为了未来"；警惕过度设计说"不要为假想需求构建抽象"。这两条的边界根本就没有标准答案。
• 信息隐藏说"不要泄露内部"；但过度的隐藏又会导致浅模块（接口看不出能做什么）。

连资深人类工程师在这些权衡上都会反复判断错——指望 Agent 仅凭一个 Skill 文件就能稳定做对，目前的证据还不够。现实是：Agent 在大部分常规情况下能做对；剩下那部分仍然需要你来 spot-check，特别是架构级决策和长期维护相关的选择。

哪些地方最容易出错、哪些原则在你的项目上特别重要——这是在磨合中一点点沉淀到 Skill 文件里的东西。一个例子：如果你发现 Agent 反复在某一类场景里选择了过度拆分（比如每次都为一个小功能起五个类），那就把这个反例写进 Skill——"在本项目里，X 类场景不要拆超过 N 个类"。Skill 库会随项目生长，这是一个持续的投资，不是一次性的工作。

实际操作的三阶段

Agent 拿到需求文档和测试计划之后，首先基于上述原则做代码结构和架构设计（模块划分、接口定义、抽象层次、文件组织）；然后执行开发和测试；最后对照这些原则进行一轮自审查和调整，检查是否存在浅模块、信息泄露、只转发不做事的中间层、命名不一致等问题，并自行修正。

你需要做的，是把这些设计原则编写成 Skill 文件，在 Agent 启动时加载；并在 Agent 的自审查结果出来之后，对架构级决策做一个 spot-check。随着磨合深入，spot-check 的次数会越来越少。

具体实践可参考 zero-review/auto-dev 技能。

并行开发的调度技巧

TL;DR：从粗到细三种能稳定用的模式——跨项目 / 同仓库不同方向（git worktree 隔离）/ 同任务不同关注点；还有一个前沿实验级的"Agent 自己拆任务并行跑"。不互斥，可嵌套。

三把钥匙解决的是"单个 Agent 能不能放手"的问题；到这一节，我们终于可以谈怎样同时放手好几个 Agent。

按并行的粒度不同，今天可以稳定使用的有三种模式（还有第四种模式目前处于前沿实验阶段，单独放在后面讨论）。

模式一：跨项目并行——不同的仓库，不同的 Agent

最粗粒度、也最省心的并行。手头几个独立的项目，每个项目启动一个 Agent，分别推进各自的开发任务。项目之间没有代码依赖，Agent 之间也不需要协调，你只需要为每个项目分别完成需求对齐，然后放手让它们各自执行。

这种模式几乎没有额外的管理成本。你唯一需要注意的是合理分配自己的注意力——在多个项目的需求对齐阶段进行轮转，而不是串行地一个做完再做下一个。一个实用的节奏是：给项目 A 的 Agent 提完需求，让它去生成测试计划；趁这个间隙切到项目 B 做需求对齐；等项目 B 的 Agent 开始工作了，回来审核项目 A 的测试计划。像一个在多个会议室之间穿梭的技术负责人。

模式二：同项目、不同方向——用 git worktree 隔离并行

同一个项目里，几个不重叠的方向同时推进，或者几个 Agent 用不同思路跑同一个需求然后择优合并——前者是"分开做不同的事"，后者正是前面说的"失败变便宜"的直接应用。

技术上，推荐使用 git worktree 来实现隔离。它允许你从同一个仓库创建多个独立工作目录，每个目录各自 checkout 到不同的分支——Agent 们互不干扰，完成后按优先级依次合并回主分支，合并冲突可以让 Agent 协助解决。

这种模式的关键注意事项是：并行的任务之间应该尽量选择代码耦合度低的方向。如果两个任务大量修改同一批文件，合并冲突的成本会吞掉并行节省的时间。一个简单的判断标准是：修改文件重叠度 < 20% 适合并行，> 50% 建议串行或重新拆分任务。

模式三：同工作项、不同事务类型——交叉并行

同一个功能内部，按事务类型把活拆开并行。即使是同一个功能的开发，其中也包含多种不同性质的事务（后端逻辑测试、UI 测试、已知 bug 修复……），它们之间往往可以并行进行。

举一个具体的例子。假设你正在开发一个"订单导出"功能，你可以同时启动三个 Agent：第一个 Agent 负责后端逻辑的测试——构造覆盖各种边界条件的后端测试计划（空订单、超大数据量、并发导出等），编写测试用例并执行。第二个 Agent 负责 UI 层面的测试——基于 Playwright 搭建端到端的 UI 测试，验证导出按钮的交互流程、文件下载行为、错误状态展示等。第三个 Agent 负责修复你在之前的开发中已经观察到的若干已知 bug。

这三个事务类型不同（后端测试、UI 测试、bug 修复），涉及的代码区域和工具链也不同，天然适合并行。

模式四（前沿实验）：单任务内部的并行——由 Agent 自己拆解和调度

这种模式目前处于早期探索阶段，行为还不够稳定——放在这里是让你对它有个预期，不是推荐今天就依赖它。

前三种模式的并行粒度都由你决定；模式四把控制权下放给 Agent 本身：一个任务扔过去，Agent 自己识别哪些子模块可以并行开发、自己拆几路并发跑。像 Claude Code 的 team 特性已经可以看到雏形——你不需要手动开 worktree、不需要手动指派任务，Agent 自己处理调度。但当前的限制也实在：跨子 Agent 的上下文共享仍然脆弱、边界不清时容易撞车、合并阶段仍需人工介入。

不过，让这种模式能跑起来的前提今天就可以开始建——模块边界、接口契约、数据流向必须在开发之前就定清楚。如果几个子 Agent 还要在写代码过程中反复对齐接口，它们很快就会撞车，合并比串行还糟。这其实正是第三把钥匙的直接回报：架构阶段做得扎实的项目，天然就具备由 Agent 自主并行的潜力；反过来，架构阶段偷懒，即使底层支持 team 模式也享受不到这个收益。

zero-review/auto-dev 的架构设计阶段已经把"模块化 + 接口契约"作为硬要求来执行，就是为了在这个能力稳定之后下游能立刻用上。

实际操作中，前三种模式不互斥——你可以在模式二的 worktree 框架里再嵌入模式三，或者在大型组织里用模式一做跨项目协调。粒度越细，对你的注意力切换能力要求越高，但收益也越大。

并行带来的新瓶颈：AI 产出你来不及消化

TL;DR：不是未来的瓶颈，是你开到第 3 个 Agent 就会立刻撞到——产出（代码、测试报告、反馈）堆到你这来，需要让 Agent 来消化；这条闭环目前还没跑通。

假设你已经按前面的做法开起了几个并行的 Agent，每个都在产出代码、测试报告、用户测试反馈、复盘总结。第一周你会觉得节奏棒极了。第二周就会发现——你的一天大半时间用来读 Agent 的各种报告，发现其中有不少其实是重复的、或者是低优先级的小问题被堆到你面前。你从"审代码"变成了"读各种报告"，瓶颈悄悄回到了你身上。

想象中的解法和前面拆瓶颈的思路一样——产出也得让 Agent 来消化：批量读完找规律和重复、合并同一件事的不同描述、按类型派给下一轮开发、按"影响多少用户 × 有没有临时办法"打优先级，每条附一句理由，只有真正需要你拍板的高优升级上来。打通之后，整个链路就变成了一个闭环：你下发需求 → Agent 并行开发 → 产出被 Agent 自动消化整理 → 新的工作项又派回去给 Agent。

但这个闭环，目前还没跑通。我在 zero-review 里为这条线留了一个位置（auto-triage 技能），但说实话，今天它还不能可靠地替代人类做这件事——分类容易失焦、合并容易漏真正独立的问题、优先级判断缺业务视角。这是目前整个协作链路里我觉得最靠不住、也最值得继续投入的一环。

在这个闭环跑通之前，你能做的是建立一些过渡期的缓冲：给每个 Agent 的产出强制一个结构化的"摘要 + 严重程度 + 建议动作"模板，让你每天只需要扫一眼就能做优先级决策；把高频的低优问题写进 Skill 让 Agent 自己忽略；固定一个"每天读产出"的时间块，别让它碎片化切割你的整个工作日。但这些都只是缓冲——真正的解法是整个闭环的第四块积木补完，而这件事今天还没到。

一些实操建议

• 从两个 Agent 开始，逐步增加。如果你还没有并行开发的经验，不要一上来就开五六个 Agent。先尝试同时管理两个，熟悉节奏之后再逐步增加。初学者的舒适上限通常是 3–4 个 Agent——再多的话，光是切换上下文和审核测试计划就会成为新的瓶颈。要突破这个上限，真正靠的不是意志力，而是更成熟的任务拆解技巧：把一个大任务预先切得足够独立、让每个 Agent 的产出不需要频繁打扰你、让审查的颗粒度从"每个产出"升到"一批产出"。这部分技巧是在磨合中逐渐长出来的——等你熟练之后，同时跑 6–8 个 Agent 也是可能的。

• 需求对齐不能并行。这是一个反直觉但重要的点。虽然开发执行可以并行，但需求对齐阶段需要你的深度思考，这部分很难真正并行。建议的做法是：串行地完成各任务的需求对齐（每个 10-30 分钟），然后并行地启动开发执行。把需求对齐想象成"装弹"，把开发执行想象成"射击"——装弹需要专注，射击可以齐发。

• 建立项目专属的 Skill 库并持续加载。工程规范、架构原则、测试要求、团队偏好——写进一份 Skill，每个 Agent 启动时统一加载，确保产出风格和质量标准一致。前面几节已经反复讲过这个库是怎么随磨合长出来的；这里只提醒一点：要让并行 Agent 的产出能无缝合并，前提是它们拿到的是同一份规范。否则三个 Agent 写出三种风格，合并起来像一件百衲衣。

• 把"审查粒度"和"项目复杂度"挂钩。复杂度低的项目（内部工具、原型）——let it go，扫一眼产出和测试计划就行；复杂度高的项目（线上关键路径、有安全性/性能要求的系统）——测试计划要逐条审，架构决策要 spot-check，关键模块仍然值得人类读一遍代码。这不是"懒"或"勤"的问题，是把有限的注意力投给真正需要它的地方。

但这不会让你更轻松

TL;DR：产出放大了，但你的单位时间脑力消耗也放大了——账是划算的，但不是免费的，得主动给自己留缝。

说完所有的美好，必须补一句坦白：这条路不会让你更轻松，事实上大概率更累。产出是放大了，但你付出的脑力也放大了——并且几乎没有缝隙。

敲代码是有节奏感的——写几行跑一下、改一点再跑——手和脑交替着用，卡壳时还能半自动地试一会儿。换成并行调度模式之后，你整天做的都是判断：要不要这份需求稿？挑哪种方案？哪个优先？这份复盘里看出什么？一个 Agent 几分钟判一次方向，五个 Agent 同时产出就是五个判断堆在你面前。时间未必更长，但单位时间内的脑力消耗显著上升。

换个说法，你从"体力加脑力"变成了"纯脑力"。账是划算的——产出放大好几倍——但总脑力投入并没减少，甚至更高。

所以得给自己主动留缝：状态报告分批读，别让 Agent 的输出像聊天消息一样把你的注意力切碎；专门留一段不被打扰的时间用来想方向、想流程；不要把"放手"错当成"我啥都不用做"的幻觉。AI 省下来的是你手上的活，省下来的时间不会自动变闲暇——得你主动给它留白。

你不再是敲键盘的人，你是设计并运行这整套协作系统的人。位置高了、杠杆大了，对判断力的要求也高了。累是累——但这种累，是真正可以创造价值的累。

总结

并行开发的本质，不是"同时开更多的 Agent"，而是"减少每个 Agent 需要人类介入的次数"。只有当每个 Agent 都能在较少的人类监督下独立完成高质量的工作，并行才谈得上有意义。

这背后三把钥匙：用结构化的需求对齐流程替代反复沟通（拆掉需求传递瓶颈），用测试计划驱动开发替代逐行代码审查（拆掉正确性瓶颈），用 Skill 注入的工程纪律替代人工架构把控（拆掉可维护性瓶颈）。再加一条策略层面的变化：失败变便宜之后，"多路并试、择优合并" 成了基本玩法。

这三个条件一旦磨合到位，你的角色就从"每个 Agent 的 pair programmer"变成了"多个 Agent 的技术负责人"——你负责定方向、定标准、审测试计划、在关键节点做 spot-check，具体的编码、测试、调试、大部分架构细节由 Agent 自主完成。

而且这份红利不止于开发——凡是可以拆成独立子任务的脑力劳动，同样适用这套思路。写代码只是第一个跑通的场景。