1. 使用 Claude Code 打造你的 AI 团队（类似 Devin）

先把话说明白：这篇是踩坑复盘，不是"技术白皮书"。我从 Kiro 的 spec/space 到把它们拼成 workflow，又一路换成 requirements-pilot，最后落在 bmad-pilot。中间爽点和雷点都写在这——不兜圈子。

[!info] 阅读导览
1 路线回顾 → 2 requirements-pilot（先确认后开干） → 3 bmad-pilot（团队化） → 4 为什么 workflow 不行 → 5 怎么用 → 6 一天跑通 → 7 规范原则 → 8 两条链怎么选 → 9 落地检查清单 → 10 配置 → 11 最后想说

flowchart LR
    A[Kiro space/spec<br>一句话生成"专业"文档] --> B[拼成 workflow<br>线性长闭环]
    B -->|不好用| C[requirements-pilot<br>先确认，后开干]
    C -->|缺专业文档| D[bmad-pilot<br>角色分工 + 专业文档]

2. 路线回顾：从 Kiro space 到"流水线梦碎"

• 起点：我先是用 Kiro 的 space/spec，把一句话生成"很专业"的文档，看起来气势很足。
• 升级：我把这些文档拼到一个 workflow 上，想要"一键流转：requirements → design → tasks → code"。
• 现实：好看，不好用。线性长闭环，问题都在后面才爆。为了让文档看起来完整，工程被撕成一地碎片——这和我在《SPEC 别再装了…》里说的是一回事：专业废纸 + 缝合怪。

3. 转向：requirements-pilot = vibe coding pipeline

• 我把路子改成**“先确认，后开干”**。
• 流程：AI 总结 → 打分 → 问你是否开始 → 你说"上" → 它自动 generate → code → review → testing。
• 体验：顺滑。确认过口径，直接上手，短闭环，不内耗。
• 痛点：文档不够"专业"。可以交付，但当项目变复杂（跨模块、多人协作、需要约束与兼容性），就会缺统一口径与可追溯的"专业文档"。

4. 升级：bmad-pilot = 让"一个团队"为你工作

于是我基于 BMAD-METHOD[1] 做了 bmad-pilot：把"确认后开干"的顺滑，和"专业文档与角色分工"的秩序，合在一条流水线上。

• 角色不是摆设：Architect / Dev / QA 各司其职、真实干活，不是流程里的装饰品。
• 产物不是 PPT：每一步产出可用的 PRD、架构约束、代码与测试记录，而不是好看的演示文档。
• 体验用一句话形容：一个默契的"小团队"在替你干活，节奏是稳的，结果是可见的。

5. 为什么 workflow 不行，而 bmad-pilot 行？

• workflow 求"自动"，把不确定性藏在后面；
• bmad-pilot 求**“确定”**，把决策前置，然后自动化可自动化的那段；
• 一个假装自动化，一个是真正减少返工。

6. 怎么用

• 复杂事（跨模块/有集成/多人协作）：/bmad-pilot "实现企业级用户管理系统，支持 RBAC 权限控制和 LDAP 集成"
• 小需求与修复：/requirements-pilot "新增登录失败的节流与告警"
• 指定只要几位"队友"：/bmad-pilot "创建认证中间件" --agents=architect,dev,qa

[!tip] 提示
别一次性把所有角色全开。先跑最短链路，把第一条用户路径打通，再扩。

7. 一天跑通：从 0 到第一条可用功能

1. 目标对齐

• bmad-po 产出精简 PRD：3–5 个 Goals，5–10 个 FR/NFR，1 个 Epic + 3–6 个顺序故事，列清楚 OUT OF SCOPE。

2. 技术约束

• bmad-architect 把"能跑通"的约束写前面：运行时、数据源、集成边界、鉴权、日志、测试策略。

3. 切故事

• 垂直切片：从入口走到结果，有可见产物（API/页面/日志/脚本）。

4. 执行

• /bmad-pilot --direct-dev 或 /requirements-pilot 进入 SM→Dev→QA；
• Dev 给变更清单 + 测试全绿；QA 以"高级开发者"的标准把它改到顺眼再标 Done。

5. 复盘

• 看三件事：Lead Time、返工率、缺陷密度；
• 把无用的话删掉，文档只留"对下一条故事有用"的信息。

8. 规范，但只服务"能落地"

• PRD 不是背景论文：保留 Goals/FR/NFR/Epic/Story/AC，删赘述；
• 架构不是画图比赛：写 约束/依赖/兼容/迁移回滚/观测；
• 故事不是 TODO：每条都要有可验证产物。

9. 什么时候用哪条链

10. 落地检查清单（临上之前过一遍）

• [ ] PRD 只保留"对实现有用"的内容，OUT OF SCOPE 清楚；
• [ ] 架构包含约束、兼容、迁移/回滚、观测；
• [ ] 每个故事都有可见产物（API/页面/日志/脚本）；
• [ ] Dev 有变更清单与测试记录；
• [ ] QA 作为高级开发者完成最后的"抛光"；
• [ ] 看板可见 Lead Time / 返工率 / 缺陷密度；
• [ ] 下一条故事开始前，清空上下文，保持轻。

11. 配置

git clone https://github.com/cexll/myclaude
mkdir -p ~/.claude/{commands,agents}
cp -R myclaude/commands/* ~/.claude/commands/
cp -R myclaude/agents/* ~/.claude/agents/

12. 最后想说

我试过把东西"自动化到飞起"，也试过**“先把话说清楚再干”**。后者更诚实，也更稳。requirements-pilot 让人顺手，bmad-pilot 让人安心。前者像一把趁手的小刀，后者是一整套手术器械——对得上场景，才是真的爽。

注：在 IDE 阶段把 docs/prd.md 与 docs/architecture.md 分片到 docs/prd/ 与 docs/architecture/，方便 SM/Dev/QA 用小上下文跑活。

12.1. 参考资料

[1] BMAD-METHOD：https://github.com/bmadcode/BMAD-METHOD

[!success] 核心要点

• 演进路线：Kiro 文档 → workflow 长闭环（失败）→ requirements-pilot（顺滑但缺文档）→ bmad-pilot（角色分工 + 专业文档）
• 核心理念：把决策前置，先确认口径再开干；自动化可自动化的那段，而不是假装自动化
• 两条链：小需求用 /requirements-pilot，复杂事用 /bmad-pilot（可按需指定 agents）
• 落地原则：故事要有可见产物、文档只服务"能落地"、每步都有检查清单、下一条故事前清空上下文