| name | bmad-method |
| description | AI驱动敏捷开发方法论：一人顶一个团队的虚拟AI开发团队协作框架。当用户说'帮我开发一个产品'、'从零开始做一个项目'、'用AI团队协作开发'、'BMAD'、'敏捷AI开发'、'AI代理团队'、'虚拟开发团队'、'产品全流程开发'时触发。核心特点：多AI角色协作（PM/架构师/Dev/QA）、规划与执行分离、文档分片、上下文工程化开发。 |
来源: bmad-code-org/BMAD-METHOD — Breakthrough Method for Agile AI-Driven Development
发布时间: 2026-04-29
理念: "一个人 + AI = 一支敏捷团队。规划与执行分离，让AI不再失忆。"
🚀 BMAD Method — AI 驱动敏捷开发
用一支虚拟 AI 开发团队，完成从需求到上线的全流程。
🎯 核心概念
BMAD（Breakthrough Method for Agile AI-Driven Development）不是新编程语言，而是一套让 AI 像敏捷团队一样协作的工程化方法。
传统 AI 编程的问题：
- 单轮对话，上下文容易丢失
- 想到哪写到哪，代码难以维护
- AI 忘记了 10 分钟前做的架构决策
BMAD 的解决方案：
- 多角色协作 — 分析师、PM、架构师、Dev、QA 各负其责
- 规划与执行分离 — 先写清楚文档，再动手编码
- 文档分片 — 大文档切小片，每个任务只加载相关上下文
- 上下文工程 — 开发时自动注入"为什么这样设计"
👥 虚拟 AI 团队角色
| 角色 | 职责 | 输出物 |
|---|
| 分析师 (Analyst) | 市场调研、竞品分析、用户画像 | 产品简报 (Product Brief) |
| 产品经理 (PM) | 需求梳理、功能定义、PRD 撰写 | PRD 文档 |
| 架构师 (Architect) | 技术选型、系统设计、接口定义 | Architecture.md |
| 产品负责人 (PO) | 文档分片、对齐检查、验收标准 | Epic 清单、Story 文件 |
| Scrum Master | 任务拆分、排期、进度跟踪 | Sprint 计划、Story 队列 |
| 开发工程师 (Dev) | 代码实现、单元测试 | 代码 + 测试 |
| QA 工程师 | 代码审查、测试用例、质量把关 | Review 报告 |
| UX 设计师 | 交互设计、界面原型 | 设计稿/原型 |
🛤️ 两条工作路径
路径一：快速路径（Quick Path）
适用场景：Bug 修复、小功能、单点优化（< 1 周）
需求描述 → 快速规格 → 开发实现 → 代码审查
操作步骤：
- 用户描述需求
- PM 代理输出 1 页快速规格（Quick Spec）
- Dev 代理直接实现
- QA 代理快速审查
路径二：完整路径（Full Path）
适用场景：新产品、复杂功能、系统级重构（> 1 周）
产品简报 → PRD 文档 → 架构设计 → Epic 拆分
→ Sprint 计划 → Story 开发 → 代码审查 → 合并发布
七阶段详解：
阶段 1：产品简报（Product Brief）
负责人：分析师 + PM
输出：product-brief.md
# {产品名} 产品简报
## 问题
用户遇到什么痛点？
## 解决方案
我们要做什么？
## 目标用户
谁会用这个产品？
## 成功指标
怎么衡量做得好？
## 范围
- 包含：...
- 不包含：...
## 竞品参考
- 对标产品：...
- 差异化点：...
阶段 2：PRD 文档（Product Requirements Document）
负责人：PM
输出：prd.md
# {功能名} PRD
## 背景
...
## 目标
...
## 用户故事
作为 [角色]，我想要 [功能]，以便 [价值]
## 功能规格
### 功能 1：...
- 输入：...
- 处理：...
- 输出：...
- 边界情况：...
## 非功能需求
- 性能：...
- 安全：...
- 兼容性：...
## 验收标准
- [ ] 标准 1
- [ ] 标准 2
阶段 3：架构设计（Architecture）
负责人：架构师
输出：architecture.md
# {系统名} 架构设计
## 技术栈
- 前端：...
- 后端：...
- 数据库：...
- 部署：...
## 系统架构图
[文字描述或 ASCII 图]
## 数据模型
User {
id: UUID
name: String
email: String
}
## 接口定义
### API 1: POST /api/users
- 请求：...
- 响应：...
- 错误码：...
## 关键决策
- 决策 1：选择 XX 而不是 YY，原因...
- 决策 2：...
## 安全考量
- 认证：...
- 授权：...
- 数据保护：...
阶段 4：Epic 拆分
负责人：PO + Scrum Master
输出：epics/ 目录下的多个 epic 文件
# Epic 1: 用户认证模块
## 范围
- 注册/登录/登出
- 密码重置
- JWT Token 管理
## 包含的 Stories
- [ ] Story 1.1: 用户注册接口
- [ ] Story 1.2: 用户登录接口
- [ ] Story 1.3: JWT Token 生成与验证
## 依赖
- 需要数据库用户表（Epic 2）
## 验收标准
- [ ] 单元测试覆盖率 > 80%
- [ ] 接口响应时间 < 200ms
阶段 5：Sprint 计划
负责人：Scrum Master
输出：sprint-1.md
# Sprint 1 计划
## 周期
2026-05-01 ~ 2026-05-07
## 目标
完成用户认证模块核心功能
## Story 队列
| 优先级 | Story | 估点 | 负责人 |
|--------|-------|------|--------|
| P0 | Story 1.1: 用户注册 | 3 | Dev |
| P0 | Story 1.2: 用户登录 | 3 | Dev |
| P1 | Story 1.3: JWT 实现 | 2 | Dev |
## 验收标准
- [ ] 所有 Story 通过单元测试
- [ ] 代码审查通过
- [ ] 集成测试通过
阶段 6：Story 开发
负责人：Dev
核心机制 — 文档分片 + 上下文工程：
每个 Story 开发时，只加载相关上下文：
Story 1.1: 用户注册接口
├── 加载：PRD 中"用户注册"章节
├── 加载：Architecture.md 中"接口定义"+"数据模型"
├── 加载：coding-standards.md（编码规范）
└── 加载：security-requirements.md（安全要求）
不加载：其他 Epic 的文档、UI 设计稿（除非相关）
这样 Dev 代理既有足够上下文，又不会被无关信息干扰。
阶段 7：代码审查
负责人：QA + 架构师
审查清单：
| 维度 | 检查点 |
|---|
| 功能正确性 | 是否满足 Story 验收标准 |
| 架构一致性 | 是否符合 Architecture.md 中的决策 |
| 代码规范 | 是否遵循 coding-standards.md |
| 安全性 | 是否有 SQL 注入、XSS 等风险 |
| 性能 | 是否有 N+1 查询、死循环等 |
| 测试覆盖 | 单元测试是否完整 |
| 文档 | 关键函数是否有注释 |
审查意见格式：
[BLOCK] 必须修改：...
[NIT] 建议优化：...
[LGTM] 通过
🧩 关键技术：文档分片
为什么需要分片？
大型项目的 PRD + 架构文档可能超过 5000 字，超过 AI 上下文窗口。文档分片解决"AI 看不过来"的问题。
分片原则
| 文档类型 | 分片方式 | 示例 |
|---|
| PRD | 按功能模块分片 | prd-auth.md, prd-payment.md |
| 架构 | 按层次分片 | arch-backend.md, arch-frontend.md |
| 规范 | 按主题分片 | coding-standards.md, api-standards.md |
| Story | 每个 Story 独立文件 | story-1.1-register.md |
引用机制
文档之间通过引用链接，避免重复：
# story-1.1-register.md
## 相关文档
- [PRD: 用户注册](../prd.md#用户注册)
- [架构: 数据模型](../architecture.md#数据模型)
- [规范: API 设计](../standards/api-standards.md)
🧠 关键技术：上下文工程
什么是上下文工程？
在 Dev 代理写代码前，自动组装"最小必要上下文包"：
上下文包 = {
"story": "当前 Story 文件",
"relevant_prd": "PRD 中相关章节",
"relevant_architecture": "架构中相关设计",
"coding_standards": "编码规范",
"previous_similar": "已实现的类似代码（可选）"
}
为什么有效？
- 减少噪音：Dev 只看到相关信息
- 保持一致性：自动注入架构决策，避免偏离
- 可追溯性：每个代码决策都能追溯到文档依据
💡 使用示例
示例1：快速修复 Bug
用户：登录接口偶尔返回 500 错误
BMAD 快速路径：
1. 分析师：收集错误日志，确认复现条件
2. PM：输出快速规格（1页）
3. Dev：定位问题（数据库连接池耗尽），修复代码
4. QA：验证修复，补充测试用例
示例2：从零开发新产品
用户：帮我做一个任务管理工具
BMAD 完整路径：
1. 分析师：调研竞品（Todoist、Notion、Trello）
2. PM：输出 PRD（用户、功能、验收标准）
3. 架构师：设计技术栈（React + Node + PostgreSQL）
4. PO：拆分为 3 个 Epic（认证/任务/通知）
5. Scrum Master：规划 Sprint 1（认证模块）
6. Dev：分片开发 Story 1.1 → 1.2 → 1.3
7. QA：代码审查 → 合并 → 部署
示例3：系统重构
用户：把单体应用拆成微服务
BMAD 完整路径：
1. 分析师：梳理现有模块依赖关系
2. PM：定义拆分范围和优先级
3. 架构师：设计服务边界、通信方式、数据一致性方案
4. PO：按服务拆分 Epic
5. Scrum Master：制定渐进式迁移计划
6. Dev：逐个服务迁移，保持兼容性
7. QA：集成测试、回归测试
🆚 与其他开发方法论的关系
| BMAD Method | TDD | OpenSpec-SDD | Agile |
|---|
| 核心 | AI 多角色协作 | 测试先行 | 规范先行 | 迭代交付 |
| 适用 | AI 辅助开发 | 代码质量 | 需求对齐 | 团队管理 |
| 文档 | 分片化、工程化 | 测试即文档 | Spec 即文档 | 看板/文档 |
| 效率提升 | 10-50x | 2-3x | 2-3x | 依赖团队 |
最佳实践：
- BMAD 提供整体框架和角色协作
- TDD 嵌入 BMAD 的 Dev 阶段
- OpenSpec-SDD 嵌入 BMAD 的 PRD 阶段
- Agile 的 Sprint 概念融入 BMAD 的计划阶段
🔗 相关 Skill
| Skill | 关系 |
|---|
| openspec-sdd | BMAD 的 PRD 阶段可调用 OpenSpec-SDD 进行规范驱动设计 |
| test-driven-development | BMAD 的 Dev 阶段可调用 TDD 进行测试驱动开发 |
| systematic-debugging | BMAD 的 QA 阶段可调用系统调试方法排查问题 |
| writing-plans | BMAD 的 Sprint 计划可调用详细实施计划生成 |
| skill-creator | 用 skill-creator 创建自定义的 BMAD 角色 Skill |
🚀 快速开始
用户：我想用 BMAD 方法开发一个 [产品名称]
AI：
1. 启动 BMAD 快速路径/完整路径
2. 确认产品简报
3. 按七阶段推进
4. 每阶段产出文档，用户确认后继续
"AI 编程的下一步不是更大的模型，而是更好的协作方式。BMAD 让 AI 从'助手'变成'团队'。"
