bmad-method

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 周）

需求描述 → 快速规格 → 开发实现 → 代码审查

操作步骤：

1. 用户描述需求
2. PM 代理输出 1 页快速规格（Quick Spec）
3. Dev 代理直接实现
4. 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 从'助手'变成'团队'。"