并行开发 6 纪律

并行开发 6 纪律

会一个一个排队用 Claude，是入门；会同时开多个 Claude 并行干活，是进阶。但并行不是「多开几个窗口」那么简单——两个 agent 抢同一个文件、改崩彼此的进度、上下文串台，这些坑每个都吃过才知道疼。

社区有一篇「6 条并行纪律」的文章，把踩过的坑总结成了 6 条铁律。这一篇就把这 6 条一次讲透——它们不是建议，是并行能不能跑起来的前提。

为什么并行这么香

先说为什么值得费劲搞并行。单 Claude 串行干活，你的吞吐量上限就是「一个 agent 的速度」。开 3 个并行，理论吞吐量 ×3。一个下午干完一周的活，这不是修辞，是真实发生的事。

社区复盘里有一句分量很重的话：

并行 worktree 是对吞吐量提升最大的单一改动。

不是更贵的订阅、不是更花哨的 prompt，是 worktree 并行。但红利不是免费午餐——它有 6 条纪律要守，少一条都会让并行变成「3 个 agent 互相打架，比串行还慢」。

纪律 1：只拆「真能拆」的活

并行不是把任何任务都拆成几份。能并行的活必须满足两个条件：

1. 互不依赖——A 不等 B 的结果，B 也不等 A。
2. 不碰同一批文件——两个 agent 改同一个文件，必然冲突。

社区给了一个特别好用的判断题：

问自己：「这事如果招三个人来干，会不会天天找我协调？」

如果答案是「会」——他们要等彼此、要商量接口、要解决冲突——那这活不能拆，串行更稳。如果答案是「不会，三个人各干各的」——那就能并行。

典型的「真能拆」：前端组件 + 后端接口 + 文档，互不依赖、各改各的文件。典型的「不能拆」：一个函数的重构，逻辑纠缠在一起，没法分。

纪律 2：每开一个立刻改名

开一个并行 session，第一件事不是给任务，是 /rename。

（spawn 出来那一秒）
/rename feature-auth-frontend

社区强调一个细节：spawn 那一秒就改，别等。为什么这么急？因为并行场景下你同时盯着好几个会话，每个都有个默认名 session-xxx，三分钟你就分不清谁是谁了。等到要恢复、要回溯、要交接，名字就是你的导航。

命名规则建议：<任务>-<子系统>，比如 feature-auth-frontend、fix-payment-bug、refactor-user-model。一眼看出在干什么、属于哪块。

纪律 3：worktree 隔离永远开

这是 6 条里最重要的一条。

worktree（-w flag）给每个并行 agent 一个独立 checkout——独立的工作目录、独立的分支。两个 agent 在各自的 worktree 里改代码，永远不抢同一个文件，物理上不可能冲突。

claude -w feature-auth

不用 worktree 会怎样？两个 agent 在同一个工作目录里改文件，A 刚写完 auth.js，B 把它覆盖了，A 回过头来发现自己的改动没了。这种冲突解决起来极痛苦，比串行还慢。

社区复盘的原话：

并行 worktree 是对吞吐量提升最大的改动。

注意「worktree」这个限定词——是 worktree 让并行成立，不是「多开窗口」让并行成立。没有 worktree 的并行不是并行，是「多个 agent 互相踩脚」。

纪律 4：别撒手不管，每个 agent 都要「压」一遍

并行不等于甩手。开出去的每个 agent，你都要在关键节点压一遍——这是质量的保证。

社区给的「压」的清单是六步：

1. Scope——把任务范围圈清楚，别让它越界改不该改的。
2. Grill——拷问它的方案，问「为什么这么做、边界想过没」。
3. Check alignment——对齐目标，确认它理解的「做完」和你一致。
4. Check approach——看它的实现路径，方向对不对。
5. Run——让它真正跑起来执行。
6. Review——审查产出，挑问题。

关键洞察是：真正花心思在前四步，Run 最轻松。新手把精力全压在 Run 和 Review 上——前面不闻不问，等做完了才发现方向错了，全部返工。高手相反，前四步（Scope、Grill、Check alignment、Check approach）花足时间对齐，Run 阶段基本放手，Review 只是验收。

这六步像漏斗：前面的口子收得越紧，后面越省事。

纪律 5：通知当优先中断

并行场景下，agent 卡住了怎么办？

新手的本能反应是「等会儿再看，可能它自己就过去了」。社区明确反对：

不要「等会儿再看」。agent 卡住时它在烧上下文——每多卡一分钟，就多浪费一份 token 和注意力。

正确做法：通知一来、发现卡住，立刻中断。打断它，问它「卡在哪了」，给指引或者重新规划方向，别让它在死胡同里转。

并行 agent 是烧着你的资源在跑的，串行时你可以容忍它「想一会儿」，并行时每个卡住的 agent 都是正在漏的水。早发现、早中断、早纠偏。

纪律 6：3-5 个是甜区

并行的数量有上限。社区的经验：

3-5 个 agent 是甜区。再往上加，合并总结的时间会超过并行省下的。

为什么？因为并行有个隐性成本——合并和总结。5 个 agent 各干各的，最后你要把这 5 份产出拼回一个整体，理顺接口冲突、对齐风格、补回归测试。这个合并成本随数量非线性增长：

• 3 个：合并还能顾得过来。
• 5 个：合并要花点心思，但能做。
• 8 个以上：合并的时间可能比并行省下的还多，得不偿失。

所以并行不是越多越好。3-5 个是甜区，过了这条线，再增 agent 是负收益。

worktree vs subagent 分工表

并行场景下，到底用 worktree+并行 session，还是 subagent？这俩不是一回事，分工不同：

维度	worktree + 并行 session	subagent
隔离	独立目录+分支	同一个工作目录
文件冲突	不可能	可能
上下文	各自独立	共享父上下文
适合	长的独立任务（小时级）	短的并行查询（分钟级）

记法很简单：活长、改文件多、互相独立 → worktree；活短、要共享结果 → subagent。

• 重构 auth 模块（要改几十个文件，跑几小时）→ worktree。
• 通读 3 个目录各出一份摘要（10 分钟，结论要汇总）→ subagent。

（Worktree vs Subagent 选型 单开一篇讲透这个选择。）

别让 Claude 擅自 spin up 探索性 subagent

最后一条容易被忽略的纪律：别让 Claude 自己擅自启动探索性 subagent。

什么意思？Claude 有时候会「自作主张」——遇到不确定的事情，它可能自己 spawn 一个 subagent 去探索。听起来挺贴心，但在并行场景下这是灾难：

• 你不知道它开了几个 subagent，上下文消耗失控。
• 探索性 subagent 的结果未必有用，白烧 token。
• 你失去对并行 agent 数量的掌控，纪律 6 的「3-5 个」形同虚设。

社区的建议：探索性 subagent 的启动权握在你手里。要派子代理探索，你显式指令派，别让 Claude 自己决定什么时候 spin up。这样并行的数量、上下文消耗你才心里有数。

一套典型的并行工作流

把 6 条纪律串成一个真实流程：

1. 挑一个「真能拆」的活（纪律 1）
   比如一个功能拆成：前端组件 + 后端接口 + 文档

2. 开 3 个 worktree session，每个 spawn 那一秒就改名（纪律 2、3）
   claude -w feature-frontend  →  /rename feature-frontend
   claude -w feature-backend   →  /rename feature-backend
   claude -w feature-docs      →  /rename feature-docs

3. 每个 agent 开干前先压一遍：Scope/Grill/Check（纪律 4）
   - 圈清楚各自范围
   - 拷问方案
   - 对齐「做完」的定义

4. 跑起来，通知一来发现卡住立刻中断（纪律 5）

5. 各自完成后，合并 3 份产出，理顺接口（控制在 3-5 个，纪律 6）

6. 合并后整体过一遍 /ship 流水线（接回 9 步循环）

整个过程你始终盯着 3-5 个会话，名字清晰、互不踩脚、卡住就断。这就是社区说的「对吞吐量提升最大的单一改动」的真实样子。

一句话总结

并行 6 纪律：只拆真能拆的活（招三个人会不会天天协调）、spawn 那一秒就改名、worktree 永远开（对吞吐量提升最大）、每个 agent 压一遍（前四步花心思 Run 最轻松）、通知当优先中断（卡住在烧上下文）、3-5 个是甜区（再多合并成本超并行收益）。别让 Claude 擅自 spin up 探索性 subagent。

---

下一步，去看 Worktree vs Subagent 选型——并行场景下到底该用哪个。🚀