本文不是 BMAD 实战记录（实战放下一篇），是为什么 BMAD 比 SDD 更适合复杂 AI 辅助开发的入门解读。
适用读者：用过 Cursor / Claude Code 写过代码，但遇到"AI 写出来跟我想的不一样 / 上下文丢失 / 多人协作混乱"问题的工程师。
💡 背景
最近 18 个月，AI Coding 工具的爆发速度远超预期：
- Cursor / Claude Code / Windsurf —— 1 个人的代码产出效率提升 3-5 倍
- Devin / Codex Agent —— 整个 issue 自动闭环
- v0 / Bolt / Lovable —— 自然语言直接生成完整应用
但作为有 十几年经验的工程师，我亲手踩过这些坑：
- AI 写出来跟我想的不一样 —— 不是工具不行，是"我想的"根本没被结构化记录
- 上下文丢失 —— 第 3 轮对话后，AI 已经忘了第 1 轮我说的业务约束
- 多人协作混乱 —— A 写的代码 B 接不住，文档永远滞后于代码
- 复杂项目失控 —— 简单功能能搞定，超过 5 个 story 的功能就开始跑偏
这些问题的根因，不是 LLM 能力不够，是「缺少一套让 AI 和人都能遵守的工程纪律」。
行业给出了两条主流答案：
- SDD（Spec-Driven Development） —— GitHub Spec Kit、AWS Kiro 是代表，强调"先写规格再写代码"
- BMAD-METHOD —— 21 个专业 agent + 50+ 工作流，强调"多 artifact 体系 + 3 阶段闭环 + 多 persona 协作"
我深入读了 BMAD 仓库（2088 commits / 57MB），跑通了本地 install，对比了 SDD 和 BMAD 的设计哲学——我的结论是：BMAD 比 SDD 更系统化、工程化，更适合"超级个体"或小型团队。
本文就是这次学习的精华整理。
...大约 15 分钟