上周末我盯着项目的需求列表发呆——42个用户故事6大模块ddl还有两周。用 BMAD 方法论规划得很漂亮Epic 拆成 StoryStory 有验收标准一切井井有条。但问题来了每完成一个 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-dev2-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--summarydev- 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--agentdev-b ✅ 可开始: 打卡同步、手动同步... 被阻塞: 退款功能 └─ 等待: 支付回调完成(dev-a负责)➡️ 下一步:3-1-zsxq-sdk-integration问题3任务完成后怎么更新$ python3 check-blockers. py -- complete2-5-payment-webhook ✅ 已标记完成 同步点触发解锁任务: 退款功能、会员列表一句话总结随时掌握谁在等谁完成任务自动解锁下游。3、组件3多终端启动器parallel-dev.sh这是整个系统的一键开工按钮。传统方式开3个终端分别 cd 到项目目录分别启动 claude…现在只需要一条命令$ ./scripts/parallel-dev.sh start ✅ dev-a已启动(支付系统专家)✅ dev-b 已启动(打卡与退款专家)✅ dev-c 已启动(基础与运营专家)提示 tmux attach-tparallel-dev# 查看所有窗口Ctrlb n# 切换下一个窗口3个 Claude Code 实例在3个 tmux 窗口里并行运行。一句话总结一条命令启动你的AI开发团队。4、组件4自定义命令/parallel-epic这是整个系统的工作说明书。每个 AI Agent 启动后只需要执行一条命令/parallel-epic dev-aClaude 就会自动读取自己负责的任务列表检查哪些任务被阻塞从第一个可执行的任务开始干活完成后自动更新状态一句话总结告诉 AI “你是谁”它就知道该干什么。三、深度辨析为什么 BMAD 需要这个扩展1、BMAD 的优点BMAD 是我用过最好的 AI 开发框架Epic → Story 的拆解逻辑清晰每个 Story 有标准的验收标准状态流转规范backlog → drafted → in-progress → done2、BMAD 的盲区但 BMAD 有一个隐含假设单人开发。它的流程是为一个开发者设计的SM你自己规划 SprintDev还是你逐个实现 Story每完成一个手动改状态再看下一个当需求量大、时间紧的时候这个流程就崩了3、我的扩展解决了什么BMAD 原生 → BMAD 并行扩展 ───────────────────────────────────────── 单人顺序开发 → 多Agent并行开发 手动状态管理 → 自动阻塞检查 无协调机制 → 同步点自动触发 只支持Claude → 支持Claude/Codex不是替代 BMAD是补全它缺失的那块拼图。四、决策框架什么时候用哪种方式我设计了 5 种使用方式适合不同场景1、方式1看文档手动开发适合需求少10个不赶时间做法参考分配表自己一个个做2、方式2多终端并行适合需求中等10-30个想提速做法./parallel-dev.sh start 启动3个Claude3、方式3单Claude多Subagent适合想在一个窗口里控制多个Agent做法让Claude启动多个Task子任务4、方式4Orchestrator全自动适合需求多30想全自动做法python3 orchestrator.py run5、方式5混合人类AI适合团队协作部分人用AI部分人手写做法人类开发者也遵循同一套状态管理选择建议五、实战案例我是怎么用这套系统的回到开头的场景42个需求2周deadline。1、第一步分析依赖划分模块我用 Claude 分析了所有 Story 的依赖关系发现EP02支付是核心很多功能依赖它EP03打卡和 EP04退款有强关联适合一个人做EP01/05/06 相对独立可以并行2、第二步配置分配表在 sprint-status.yaml 里定义了3个Agent3、第三步定义同步点4、第四步启动并行开发一条命令启动 ./scripts/parallel-dev.sh start 三个窗口分别执行 / parallel-epicdev-a / parallel-epicdev-b / parallel-epicdev-c5、第五步监控进度每隔几小时看一眼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才是正确的打开方式。