BMAD-METHOD 说明文档
1. 什么是 BMAD-METHOD
- BMAD-METHOD,全称 Breakthrough Method for Agile AI-Driven Development,是一种“AI 代理 + 敏捷开发”结合的开源开发方法论/框架。通过预设的多个 AI “角色”(agent),它模拟传统开发团队中的 PM、分析师、架构师、开发者、QA 等角色,将从需求到交付的流程交给 AI agent 协作完成。 (CSDN)
- BMAD-METHOD 背后的组织是 bmad-code-org,其 GitHub 仓库地址为
bmad-code-org/BMAD-METHOD。 (GitHub) - 它不仅是一个简单的“AI 辅助工具”,而是一个完整的流程系统/方法论 — 从需求/设计/架构/开发/测试/交付 —— 全阶段覆盖。 (博客园)
- BMAD-METHOD 的目标之一是:让单个开发者也能够借助 AI 具备“一个完整敏捷团队”的能力。 (博客园)
简而言之,BMAD-METHOD 是一种「AI 团队 + 敏捷流程」的组合,把软件开发抽象成 agent 协作 + 流程驱动 + 文档/结构化管理。
2. 核心理念与设计哲学
BMAD-METHOD 的设计理念和哲学包括以下几个关键点:
- AI 即团队(Agent-as-Team)
与传统把 AI 当作“代码帮手 / 补全工具”的使用方式不同,BMAD-METHOD 将 AI 视为多个角色:例如分析师 (Analyst)、产品经理 (PM)、架构师 (Architect)、Scrum Master、开发者 (Dev)、QA 等。每个角色有明确职责与分工,通过协作完成整个开发流程。 (Kevin Holland) - 结构化、规范化的开发流程
BMAD-METHOD 把开发过程拆为多个阶段 (workflow stages),每个阶段有明确输入/输出与交接点,agent 之间通过“合同 (contract) / 文档 / 持久 context”传递信息,而不是零散对话。这样可以保证上下文持续、任务清晰、流程有序。 (Medium) - 与传统敏捷结合
虽然 BMAD-METHOD 是 AI 驱动,但它保留了敏捷 (Agile) 的原则、周期 (iteration)、角色分工 (PM, Scrum Master, Dev, QA…)。适合以敏捷方式管理软件项目,只不过“团队成员”变为 AI agents。 (note(ノート)) - 工具无关、平台兼容
BMAD-METHOD 的设计不依赖某一种特定 AI,只要能支持 agent / LLM + scripting + context 管理,就可以集成。文档与流程是通用的。 (DevPress) - 从灵感到落地的全生命周期覆盖
它不仅适用于构思 / 需求阶段,也覆盖架构设计、实现、测试、交付、回归、迭代等全过程 — 与传统软件工程流程类似,但由 AI agent 驱动。 (博客园)
总的来说,BMAD-METHOD 试图让 “AI 编程 / AI 助手” 从零散帮忙变为 “整体开发团队 + 流程引擎”。
3. BMAD-METHOD 的组成与结构
根据官方仓库和社区资料,BMAD-METHOD 的典型项目结构 / 组成如下: (CSDN)
1 | /(项目根目录) |
ai/:存放 agent 定义、逻辑、状态管理脚本等custom-modes/:允许扩展自定义 agent 模式,适合特定项目或团队需求docs/:长期保存设计文档、规范、决策记录 (decision log) 等,有利于追溯与审计prompts/:维护 agent 提示词 (prompts),定义每个角色在不同阶段应如何回应/输出
BMAD-METHOD 由一个更基础的核心框架 ( BMAD‑CORE ) 支撑。BMAD-METHOD 是构建在 BMAD-CORE 上的一层“敏捷工作流模块 (Method module)”。也就是说:BMAD-CORE 提供基础 agent 调度 / context 管理 / 通用能力,BMAD-METHOD 在其基础上定义具体流程与角色分工。 (GitHub)
此外,有相关扩展 / 构建工具 (如 BMAD‑BoMB‑Factory),允许用户构建自定义 agent、扩展 workflow、定制模块。 (GitHub)
4. 工作流程 (Workflow) 与角色模型
BMAD-METHOD 通过定义清晰的 workflow + agent 角色,实现 AI 团队协作。主要流程与角色模型特征如下:
4.1 典型 Workflow
- 工作流通常采用类似 YAML/结构化 blueprint (脚本/配置) 定义。该 blueprint 描述任务依赖、阶段顺序、agent 分工、交接点 (handoff) 等。 (Medium)
- 从最初的 “构思/需求收集 → 分析 → 设计 → 实现 → 测试 → 交付” 都在同一 workflow 中串联 — 类似传统敏捷,但执行主体为 AI agents。 (博客园)
- 每个阶段结束时有明确的输出 (文档、规格、代码、测试结果等),供下一个 agent / 阶段使用。流程透明、清晰、可追踪。 (青雲的博客)
4.2 典型角色 (Agents)
常见 agent 角色包括 (但不限于):
| 角色 | 职责 / 功能 |
|---|---|
| Analyst | 做深度研究、需求分析、市场/用户/竞争分析 |
| PM (Product Manager) | 定义产品方向、功能列表、优先级、里程碑 (milestone) |
| Architect | 设计系统架构、模块划分、技术选型、接口契约 (contract) |
| Scrum Master / Workflow Controller | 协调 agent 间任务执行、依赖管理、版本控制、质量保证 |
| Developer (Dev) | 编写具体实现 (代码)、单元测试、集成 |
| QA / Tester | 编写测试用例、执行测试、验证功能与质量 |
| (可扩展) UX / UI / Designer | 如果项目涉及前端/界面,则这些角色也可由 agent 扮演 |
这种分工使得 AI 不再做“孤立补全”,而是承担“团队角色 + 流程责任”。 (Kevin Holland)
5. 特点与优势
使用 BMAD-METHOD,相较于传统手动开发或“单 AI + 对话 + 补全”的方式,有以下明显优势:
- 完整团队能力 — 单人即可拥有完整敏捷团队
对于个人开发者、小型团队,甚至 solo 开发者,BMAD-METHOD 可以减少对多角色人员的依赖。 (博客园) - 流程规范 + 可追踪 + 可审计
所有阶段 (需求/分析/设计/实现/测试) 都留下文档/输出,整个过程透明、可回溯。适合需要质量保证、可维护性的项目。 (CSDN) - 上下文持续 + 多 agent 协作
不同 agent 之间共享 context 与产出,避免“上下文丢失/断裂”。相比传统的 “对话 + 生成代码” 模式,更稳定、更可靠、更适合复杂系统开发。 (青雲的博客) - 适合从 0 → 1 构建,也适合小团队快速迭代
无需招募完整团队,也可以从 idea → 原型 → 产品,快速推进。适合 startup、小项目、side-project。 (博客园) - 工具 / 平台无关
BMAD-METHOD 本身不绑定具体 AI 服务、IDE、编译器等;你可以选用自己熟悉的工具。只要能支持 agent / script / context 就能用。 (DevPress)
6. 使用 BMAD-METHOD 的典型流程 (Greenfield)
下面是一个典型“从零开始 (Greenfield)”用 BMAD-METHOD 构建项目的流程 (high-level):
- 初始化项目 — 在项目根目录创建 BMAD 所需结构 (ai/, prompts/, docs/ …) (Luka Huang)
- 定义需求 / 构思 (由 Analyst + PM agent 执行) — 通过 agent 协作,生成初步 PRD / 产品定义 / 功能清单。 (note(ノート))
- 系统 / 架构设计 (由 Architect agent 执行) — 根据需求,设计系统架构、模块划分、接口 / 合约 (contract)、数据模型 / API 规范等。 (GMOインターネットグループ株式会社採用情報)
- 任务拆解与排期 (Scrum Master / Workflow Controller agent) — 将设计拆成具体任务 (story、epic、ticket 等),安排顺序 / 并行 /依赖。 (Luka Huang)
- 实现 + 测试 (Developer + QA agents) — 编写代码、单元测试、集成测试,输出可运行产品。 (知乎专栏)
- 交付 / 验证 / 持续迭代 — 产出文档、部署、用户反馈 / bug 修复 / 功能扩展,以敏捷方式持续迭代。整个过程依旧由 agents 协作管理。
这一流程让从 “想法 → 产品” 的路径变得可结构化、可自动化、可管理。
7. 适用场景 与 限制 / 注意事项
7.1 适用场景
- 个人开发者 / 小团队 — 想快速从 idea 做原型到 MVP / 产品
- 初创 / side-project — 人力有限,需要 AI 辅助完成多角色任务
- 希望以结构化 / 文档化 / 可追踪方式管理项目
- 对流程规范、代码质量、可维护性有一定要求
- 探索 AI-driven 的敏捷开发实践
7.2 潜在限制与注意事项
- AI agent 质量 / prompt 设计依赖较高 — agent 能力与 prompt 设定会决定输出质量
- 适合 Greenfield (新项目);对于 Brownfield / 遗留项目可能较复杂 — 尽管理论上支持,但已有项目 context 复杂,迁移成本可能高 (Luka Huang)
- 仍需人类监督 / 审校 — AI 虽然承担多角色,但关键决策、复杂设计、Edge Case 处理等,仍建议有人工审查
- 学习 / 配置成本 — 初次使用需要理解 BMAD 的结构与流程,以及配置 agent / prompts / 项目结构
- 适合中小项目 / MVP / 快速迭代;对于极大型、复杂系统可能仍需人工架构师 / 资深工程师介入
8. 与其他 “规范驱动 / AI-驱动开发” 方法对比
BMAD-METHOD 属于较为激进 / 完整的一种 AI-driven 开发方法,与其他方法/工具相比有以下不同与特点:
- 与传统 “AI 编码助手 (如 code-completion / Copilot)”不同 — BMAD-METHOD 提供 多 agent 协作 + 流程 + 文档 + 整体管理,远超单一补全能做的事情。
- 与 “简单脚本生成 + 手动整合”相比 — BMAD-METHOD 更系统、更结构化、适合团队/项目协作与维护。
- 与仅专注 “规范驱动 / Spec-Driven 开发 (SDD)” 的方案相近 — 但 BMAD-METHOD 不仅有规范/文档/规划,还结合 AI agent 执行,实现从规范到实现的闭环。
- 与需要完整团队而难以启动的传统敏捷开发相比 — BMAD-METHOD 将 “团队角色” 转变为 “AI agent + 脚本 + 流程”,大幅降低团队门槛。
因此,如果你想用 AI 来做“真正的软件开发 (不仅仅是 snippet / prototype)”,BMAD-METHOD 是目前较为成熟、系统化的解决方案之一。
9. 如何开始使用 BMAD-METHOD
- 克隆官方仓库
bmad-code-org/BMAD-METHOD,将其作为项目起点。 (GitHub) - 在项目根目录构建 BMAD 所需结构 (ai/ custom-modes/ docs/ prompts/ 等) 。 (CSDN)
- 根据项目目标 / 需求,选择或定义合适的 agent (Analyst / PM / Architect / Dev / QA …),并准备相应 prompts。
- 使用 BMAD 的 workflow blueprint (YAML 或配置脚本) 定义项目阶段、角色交接、任务依赖与输出内容。 (Medium)
- 启动 agent 流程 — 从需求分析 → 设计 → 任务拆解 → 实现 → 测试 → 交付。每一步输出文档 + 代码 + 测试,形成完整产品 / MVP。
- 在开发过程中不断维护 docs/ 和 configuration,适时调整 agent / 模板 / workflow,以适应项目实际需求。
实践中,一些用户已尝试将 BMAD 与流行 AI 编码助手 (如 Cursor, Claude Code 等) 集成,以实现 “AI 团队 + IDE 开发” 的真实体验。 (Kevin Holland)
10. 总结
BMAD-METHOD 是目前较为系统、成熟的 “AI-driven + Agentic + Agile” 软件开发方法论 / 框架。它将 AI 工具从“助手 / 补全”升级为“完整开发团队 + 流程引擎 + 协作平台”,让单个开发者 / 小团队也可能拥有大型项目开发 / 交付能力。
在适合的场景中 (新项目、MVP、小型团队、创业项目等),BMAD-METHOD 提供了一条可行、结构化、高效率的路径。从需求 → 设计 → 实现 → 测试 → 交付,全链路由 AI agent 驱动,输出文档 + 代码 + 可运行产品。与此同时,流程透明、文档规范、易于维护。
如果你愿意,我可以帮你基于 BMAD-METHOD 为你现有/未来项目 生成一个 starter 模板 (project scaffold + agent config + workflow blueprint),从 0 到可运行项目一步到位。