上周末，我盯着项目的需求列表发呆——42个用户故事，6大模块，ddl还有两周。
用 BMAD 方法论规划得很漂亮：Epic 拆成 Story，Story 有验收标准，一切井井有条。
但问题来了：
每完成一个 Story，我要：
-
把状态从 drafted 改成 in-progress
-
写完代码，改成 review
-
自己审核通过，再改成 done
-
然后看下一个 Story 是否被前置任务阻塞...
一个人，42个需求，每个需求改3次状态，外加依赖检查。
我算了一下：光是"状态管理"这件事，就要操作 126次。
更崩溃的是——现实中的开发从来都是多人协作的。产品经理催进度的时候，不会问你"BMAD流程走完没"，只会问"什么时候能上线"。
BMAD 是个好框架，但它缺了一块拼图：并行开发。
今天我要分享的，就是我如何用 Claude Code 搭建了一套"AI开发团队"，让 3 个 AI Agent 并行干活，效率直接翻倍。
一、全景类比：把 AI 想象成你的远程开发团队
在讲具体方案之前，我想先打个比方。想象你是一个技术负责人，手下有 3 个成员开发：
你作为负责人，需要做什么？
-
分工：把需求按模块分给不同的人
-
协调：小B的退款功能要等小A的支付完成才能开始
-
追踪：随时知道每个人做到哪了
-
同步：某个人完成关键节点后，通知其他人可以继续
这套逻辑，放到 AI Agent 上完全适用。
我搭建的系统，本质上就是一个"AI团队管理工具"：
二、逐一拆解：这套系统的4个核心组件
1、组件1：任务分配表（sprint-status.yaml）
这是整个系统的"人员分工表"。
传统 BMAD 只记录任务状态：
2
-
1
-h5-camp-lis
t:
ready-
for
-dev
2
-
2
-wechat-oauth: ready-
for
-dev
我扩展后，增加了"谁负责"和"谁等谁"：
parallel_assignments
:
dev-a
:
name
:
"支付系统专家"
负责: [EP02 支付模块]
工作量:
31
点
dev-b
:
name
:
"打卡与退款专家"
负责: [EP03 打卡, EP04 退款]
被阻塞:
退款功能 → 等待 dev-a 的支付完成
一句话总结：让每个 AI Agent 知道"我该干什么"和"我要等谁"。
2、组件2：阻塞检查器（check-blockers.py）
这是整个系统的"项目进度看板"。
它能回答三个问题：
问题1：现在整体进度怎么样？
$
python3
check-blockers.
py
--summary
dev-
a:
0
/
9
(下一个:
2
-
1
-h5-camp-
list
)
dev-
b:
0
/
12
(下一个:
3
-
1
-zsxq-sdk)
dev-
c
:
0
/
13
(下一个:
1
-
7
-settlement)
总进度:
0
/
34
问题2：某个 Agent 被什么卡住了？
$ python3
check
-blockers.py
--agent dev-b
✅ 可开始: 打卡同步、手动同步...
🚫 被阻塞: 退款功能
└─ 等待: 支付回调完成 (dev-a负责)
➡️ 下一步:
3
-1
-zsxq-sdk-integration
问题3：任务完成后怎么更新？
$
python3
check-blockers.
py
--
complete
2
-
5
-payment-webhook
✅ 已标记完成
🎉 同步点触发！解锁任务: 退款功能、会员列表
一句话总结：随时掌握"谁在等谁"，完成任务自动解锁下游。
3、组件3：多终端启动器（parallel-dev.sh）
这是整个系统的"一键开工按钮"。
传统方式：开3个终端，分别 cd 到项目目录，分别启动 claude...
现在只需要一条命令：
$ ./scripts/parallel-dev.sh start
✅ dev
-a
已启动 (支付系统专家)
✅ dev-b 已启动 (打卡与退款专家)
✅ dev-c 已启动 (基础与运营专家)
提示：
tmux attach -t parallel-dev
# 查看所有窗口
Ctrl+b n
# 切换下一个窗口
3个 Claude Code 实例，在3个 tmux 窗口里并行运行。
一句话总结：一条命令，启动你的"AI开发团队"。
4、组件4：自定义命令（/parallel-epic）
这是整个系统的"工作说明书"。
每个 AI Agent 启动后，只需要执行一条命令：
/parallel-epic dev
-a
Claude 就会自动：
-
读取自己负责的任务列表
-
检查哪些任务被阻塞
-
从第一个可执行的任务开始干活
-
完成后自动更新状态
一句话总结：告诉 AI "你是谁"，它就知道"该干什么"。
三、深度辨析：为什么 BMAD 需要这个扩展？
1、BMAD 的优点
BMAD 是我用过最好的 AI 开发框架：
-
Epic → Story 的拆解逻辑清晰
-
每个 Story 有标准的验收标准
-
状态流转规范（backlog → drafted → in-progress → done）
2、BMAD 的盲区
但 BMAD 有一个隐含假设：单人开发。
它的流程是为一个开发者设计的：
-
SM（你自己）规划 Sprint
-
Dev（还是你）逐个实现 Story
-
每完成一个，手动改状态，再看下一个
当需求量大、时间紧的时候，这个流程就崩了：
3、我的扩展解决了什么
BMAD
原生 → BMAD + 并行扩展
─────────────────────────────────────────
单人顺序开发 → 多Agent并行开发
手动状态管理 → 自动阻塞检查
无协调机制 → 同步点自动触发
只支持Claude → 支持Claude/Codex
不是替代 BMAD，是补全它缺失的那块拼图。
四、决策框架：什么时候用哪种方式？
我设计了 5 种使用方式，适合不同场景：
1、方式1：看文档手动开发
适合：需求少（<10个），不赶时间做法：参考分配表，自己一个个做
2、方式2：多终端并行
适合：需求中等（10-30个），想提速做法：./parallel-dev.sh start 启动3个Claude
3、方式3：单Claude多Subagent
适合：想在一个窗口里控制多个Agent做法：让Claude启动多个Task子任务
4、方式4：Orchestrator全自动
适合：需求多（30+），想全自动做法：python3 orchestrator.py run
5、方式5：混合人类+AI
适合：团队协作，部分人用AI部分人手写做法：人类开发者也遵循同一套状态管理
选择建议：
五、实战案例：我是怎么用这套系统的
回到开头的场景：42个需求，2周deadline。
1、第一步：分析依赖，划分模块
我用 Claude 分析了所有 Story 的依赖关系，发现：
-
EP02（支付）是核心，很多功能依赖它
-
EP03（打卡）和 EP04（退款）有强关联，适合一个人做
-
EP01/05/06 相对独立，可以并行
2、第二步：配置分配表
在 sprint-status.yaml 里定义了3个Agent：
3、第三步：定义同步点
4、第四步：启动并行开发
一条命令启动
./scripts/parallel-dev.sh
start
三个窗口分别执行
/
parallel
-epic dev-a
/
parallel
-epic dev-b
/
parallel
-epic dev-c
5、第五步：监控进度
每隔几小时看一眼：
python3
check
-blockers.py
--summary
当 dev-a 完成支付回调时，系统自动提示：
🎉 同步点 S1 触发！
🔓 已解锁: 退款功能、会员列表
dev-b 和 dev-c 就可以继续往下做了。
6、结果
原本预估2周的工作量，实际用了1周多完成。
不是因为 AI 写代码快了多少，而是因为：
-
3个Agent并行，吞吐量×3
-
自动阻塞检查，不用我手动盯
-
同步点机制，协调成本接近零
六、总结记忆：3个要点
1、BMAD 很好，但缺并行支持
单人开发40+需求，状态管理就要操作100+次。BMAD 的流程是为单人设计的，多人/多AI协作需要扩展。
2、把 AI Agent 当远程团队管理
核心就4件事：
-
分工：谁负责什么模块
-
协调：谁要等谁完成
-
追踪：随时知道进度
-
同步：关键节点自动通知
3、选对工具，事半功倍
需求少 → 别折腾，手动做
需求中等 → 多开几个终端
需求多 → 上Orchestrator全自动
最后说一句：AI 编程的价值不只是"帮你写代码"，更是"帮你管理复杂度"。
当需求多到你管不过来的时候，让 AI 来管 AI，才是正确的打开方式。
