先看：四个零件怎么拼在一起
读完整篇你只需要记住这张图。Subagent 解决「人怎么分」，Agent Team 解决「他们怎么协作」，Git Worktree 解决「他们在哪工作」，工作流模板解决「按什么顺序走」。四件缺一不可：缺一个，效率立刻打折；缺两个，并行就名存实亡。
Subagent
主控派出去的独立工人，独立上下文，错误隔离
Agent Team
对等 Agent 互相协作，减少主控调度开销
Git Worktree
每个 Agent 一个独立工作间，文件互不打架
工作流模板
分析→拆解→分配→执行→审查→合并，六步标准动作
被忽视的瓶颈：不是模型，是使用方式
Claude Code 这类工具落地后，单兵效率确实翻倍了——但团队整体的交付节奏没有跟着翻倍。原因不是模型不够强，而是大家把它用成了「更聪明的自动补全」，一个任务完了再开下一个。
这相当于把一台多核 CPU 当单核跑：模型再聪明，也是按顺序答完一个问题再答下一个。真正能拉开差距的，是把它当成一条产线来编排——多 Agent 各干一段，主线只管拆解、汇合、收结果。
先看「串行 vs 并行」差在哪
同样是一次中型重构，串行是把活儿堆给一个超级个体，并行是把活儿摊到一条产线。看一组典型对照：
串行：一个人做完再做下一个
≈ 7h- 分析 order 包的结构和依赖
- 改 Service 业务逻辑
- 改 Controller 接口
- 迁移数据库表结构
- 补单元测试 + 集成测试
- 更新 OpenAPI 文档
- 跑回归、修复
并行：四条线同时出活
≈ 2h- 线 A · 数据库：迁移表结构、加索引、回滚脚本
- 线 B · Service：重写业务逻辑、保持接口稳定
- 线 C · 接口：调整 Controller、补 OpenAPI
- 线 D · 测试：基于契约铺单元/集成/边界用例
- 主线 · 审查与合并：定接口契约、跑回归、合并分支
实际节奏：串行串糖葫芦 · 并行是四条产线同时出活
串行版本里，每一步都要等上一步跑完才能开始；并行版本里，接口契约一旦定好，四条线可以同时开工。主线的价值不是写代码，是定契约、做编排、收结果。这是后面所有零件要服务的目标。
什么时候该并行、什么时候别折腾
并不是所有任务都值得拆成并行。下面这张表给一个粗略的判断门槛，任务越独立、越能写契约，越值得并行；越是要改一个核心、越依赖个人手感，越别强行拆。
✓ 适合并行
- 改动跨 ≥2 个模块、子任务彼此不重叠
- 有现成的接口契约（OpenAPI / protobuf / 类型文件）
- 每条子线都能独立跑测试、独立 merge
- 经验上需要 1 个工程师做一整天的活
✕ 别强行并行
- 只是单文件 bug 修复或小重构
- 没有可写的契约文件，只能边写边对齐
- 每条线都要改同一个核心类，合并一定打架
- 需要大量上下文调研，并行反而拖慢主线
零件一 · Subagent —— 给主控派出去的工人
Subagent 是 Claude Code 提供的最基础并行能力。一个主控 Agent 可以分派出多个 Subagent，每个 Subagent 拿到独立的上下文和文件工作区，自己写代码、自己跑测试，完成后把结果交回来。
它的几个关键特性，决定了为什么可以放心地把活儿交给它：
| 特性 | 意味着什么 |
|---|---|
| 独立上下文 | 每个 Subagent 有自己的对话历史和工具状态，不会污染主线视野，也不被主线污染 |
| 可嵌套 | Subagent 还能再分派自己的 Subagent，可以拼出多层级树状结构 |
| 错误隔离 | 一个 Subagent 跑挂了，其他继续；主线拿到的是结果，不是噪声 |
| 自动汇报 | 完成或卡住时会主动通知主线，省去「我去看一下进度」的反问 |
一个典型的用法，是把多块互相独立的子任务同时交给 Claude Code：
请用 Subagent 并行完成下面三件事，互相之间不要重复劳动：
1. 重构 UserService 的缓存逻辑，写完跑一次单测
2. 给 PaymentController 补一组集成测试
3. 更新 OpenAPI 规范里所有和支付相关的接口
每条线自己开分支、跑完测试、通过后再交回主线。主控不会自己去写这三块代码，而是负责拆任务、设边界、收结果。这和传统软件项目里「技术 Lead 拆活 + 工程师并行实现 + Lead 集成」的节奏，是完全对应的——只是工人换成了 Subagent。读到这里，可以先记一下这张对应关系：后面讲组装图和真实例子时，箭头方向都按这个走。
零件二 · Agent Team —— 让对等角色互相协作
Subagent 解决的是「主控派活、工人执行」的关系。但当子任务之间的依赖变得复杂时——比如 A 要等 B 的接口定下来、C 又要基于 A 的数据模型做查询——光靠主控一层层转达，会把主控变成瓶颈。
Agent Team 把这个模型再推一步：让多个对等的 Agent 直接互相发消息、互相评审，绕开主控的中转。常见的三种协作模式：
接力型
A 跑完把产物直接递给 B，不用回到主线。适合「数据迁移 → 服务改写 → 接口适配」这种链式工作。
适用 · 链式流水线
评审型
实现 Agent 写完后，测试 Agent 主动拉分支做 code review，意见直接回写到实现 Agent 的工作区。
适用 · 质量兜底
契约型
几个 Agent 共享一份接口契约文件，各自基于契约实现，互不打扰。契约文件是唯一的同步锚点。
适用 · 大型重构
Team 模式带来的实际收益，是主控 Agent 的认知开销被显著降低。一个原本要主控记得「A 在等 B、B 还没交付、C 又卡在 D 上」的协调问题，被分散到 Agent 之间的消息通道里。这是它和 Subagent 最本质的区别——不只是并行，更是去中心化的协调。
零件三 · Git Worktree —— 让每个 Agent 一个独立工作间
前面两个零件解决了「人怎么分」，但并行开发最容易翻车的地方，其实是文件打架。两个 Agent 改同一个目录下的同一个文件，文件锁、状态错乱、互相覆盖——这些坑在串行开发里几乎不存在，到了并行模式却会一个接一个冒出来。
Git Worktree 就是用来解决这件事的。它允许你在同一个仓库的不同目录下，分别 checkout 出不同的分支。每个目录都是一份独立的文件系统视图，每个 Agent 改自己的那份，在它的视角里，自己就是唯一的修改者。
# 为主仓库创建四个并行工作间
git worktree add ../erp-feat-collect feat/erp-collect
git worktree add ../erp-feat-clean feat/erp-clean
git worktree add ../erp-feat-engine feat/erp-engine
git worktree add ../erp-feat-portal feat/erp-portal
# 此时四个目录互不干扰，可以分别交给四个 Subagent
# cd ../erp-feat-collect → Agent A 写数据采集
# cd ../erp-feat-clean → Agent B 写数据清洗
# cd ../erp-feat-engine → Agent C 写利润引擎
# cd ../erp-feat-portal → Agent D 写报表前端有一个常见的疑问：为什么不直接用 git checkout 切分支？原因是切换分支会改变工作目录里的文件，正在写代码的 Agent 会突然发现上下文里的文件不见了、状态乱了、工具读到的路径也变了。Worktree 的好处是把「分支切换」变成「开新的工作间」，原来的工作区丝毫不受影响。
四个 worktree 的样子
四间房各开各的门、各走各的路线，最后由主线把门牌号对上、把成果合进主分支。
零件四 · 工作流编排 —— 把以上三件套串成一条产线
到这里，三个零件已经能用了，但还散着。真正决定一个团队能跑多远、跑得多稳的，是把它们按固定动作串起来——这正是前面文章里讲过的「Skill 化」思路在开发场景的落地。一条可复用的并行工作流，可以压成六步标准动作：
组装图：四件套拼成一条产线的样子
上面四个零件单独看都是工具，真正发挥作用是它们拼在一起。把主控、Subagent、Worktree、工作流四层叠加起来，得到的不是「更强的自动补全」，而是一条可以并行出活的产线：
把它写进 CLAUDE.md，让它成为默认动作
六步跑过一次不难，难的是每次都这么跑。最稳的做法，是把工作流模板直接写进项目根目录的 CLAUDE.md，作为默认规则：
## 并行开发默认工作流
凡是涉及 ≥2 个模块的改动，按以下流程处理：
1. 先做影响面分析，列出可并行的子任务和依赖关系
2. 定义好接口契约（OpenAPI / protobuf / 类型文件）
3. 为每个子任务开一条 worktree 分支，分派 Subagent
4. 多个 Subagent 并行执行，各自在自己的 worktree 工作
5. 由主控或评审 Agent 做 code review
6. 按依赖顺序合并，跑全量测试后再合入主分支
子任务之间的依赖必须显式写出，缺契约的子任务推迟到下一轮。写完之后，下次再遇到「开发多平台看板」这种需求，你只需要说「按并行工作流处理」，Claude Code 就会自动按这六步推进，不用你一步步指挥。
走一遍真实例子：跨境 ERP 的「多平台利润看板」
把订单那种通用例子放一边，换一个更近近道场景的：为一家做多平台运营的跨境企业，开发一个「多平台利润看板」——能在同一个界面里看到 Amazon、TikTok Shop、独立站三端的毛利、净利、广告分摊、库存风险和异常预警。这件事串行做要 1-2 天，并行做呢？
主线准备（主控单独做）
- 扫一遍 ERP 现有模块，识别出四个可并行的子域：采集 / 清洗 / 引擎 / 门户
- 写一份接口契约文件
openapi/profit-board.yaml，包含 6 个核心接口 - 开四条 worktree 分支：
feat/erp-collect、feat/erp-clean、feat/erp-engine、feat/erp-portal - 把契约文件作为每个工作间的入口文档，再分派给四个 Subagent
并行执行（四条线同时跑）
- 采集线：对接 Amazon SP-API、TikTok Shop Partner、独立站订单 webhook，落库到原始订单表
- 清洗线：统一三端的订单、费用、退货口径，写字段映射表，输出标准订单事实表
- 引擎线：写利润计算服务，覆盖商品毛利、净利、广告花费分摊、退款扣减、汇损折算
- 门户线：搭报表前端 + 权限控制，按平台 / 类目 / 时间多维度切换
四条线各自改各自的目录，主线只在背景等完成通知
主线收口（回到主线）
- 按依赖顺序合并：先合 collect → 再合 clean → 再合 engine → 最后合 portal
- 跑全量回归 + 跨平台利润对账脚本，确认三端数据能拼到同一张表
- 让评审 Agent 对照 CLAUDE.md 做一轮结构性 review
- 把这次新发现的「跨平台成本分摊规则」「退款扣减时序」「广告花费归因窗口」回写到
.claude/references/erp/
总耗时约 2.5 小时，其中 80 分钟是真正的并行执行
整个过程从拆任务到合并完成，压缩到了 2.5 小时——其中还包括冲突解决、跨平台对账、code review 与知识库回写。这不是某个特别强的模型带来的奇迹，而是把原来堆给一个人的活，摊给了四条产线。下一次遇到类似需求，整条产线可以照模板再跑一遍，因为六步工作流已经写进 CLAUDE.md 了。
六条带队经验
四个零件都齐了，但用得不好照样翻车。下面这六条是踩过几次坑之后沉淀下来的判断点，按"约束条件 → 操作动作"的顺序排：
把依赖拆薄
两条线如果都要改同一个核心类，合并时一定打架。宁可先合一次再拆，不要硬并行。
契约先于实现
没有契约的并行 = 各自写各自的、最后发现拼不上。把接口文件当成装配图纸。
数量控制在 3-5 个
不是越多越快。三个改代码 + 一个跑测试，是性价比最高的搭配，再多边际收益归零。
合并顺序要显式
哪条线先合、哪条线后合、冲突时回退到哪个版本——分派任务时就写清。
工作流写进 CLAUDE.md
写进文档不算数，写进根目录的 CLAUDE.md 才有约束力。AI 每次开 session 都自动遵循。
用指标替代直觉
不要只问"快不快"。盯首稿可用率、任务可托管度、跨线冲突解决时间，才是产线是否健康的信号。
最后：模型只是引擎，产线是底盘
Claude Code 这类工具带来的真正机会，不是「让一个人更快地写代码」，而是「让一个人拥有了一支能并行出活的开发组」。但模型只是引擎，能不能跑成产线，看的是底盘——Subagent 解决了人力的平行扩展，Agent Team 解决了协调的去中心化，Git Worktree 解决了文件系统的隔离，工作流模板解决了组织纪律。
四件套一起用，一个人就是一个交付组；分开用任何一个，效率都打不到尽头。下次接到一个跨多个模块的需求时，先花五分钟问自己：这件事能不能拆成几条独立产线？如果能，就别再串行一个一个做了。