Bmad Method

来源: 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 团队角色

🛤️ 两条工作路径

路径一：快速路径（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 + 架构师

审查清单：

审查意见格式：

[BLOCK] 必须修改：...
[NIT] 建议优化：...
[LGTM] 通过

🧩 关键技术：文档分片

为什么需要分片？

大型项目的 PRD + 架构文档可能超过 5000 字，超过 AI 上下文窗口。文档分片解决"AI 看不过来"的问题。

分片原则

引用机制

文档之间通过引用链接，避免重复：

# 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 提供整体框架和角色协作
• TDD 嵌入 BMAD 的 Dev 阶段
• OpenSpec-SDD 嵌入 BMAD 的 PRD 阶段
• Agile 的 Sprint 概念融入 BMAD 的计划阶段

🔗 相关 Skill

🚀 快速开始

用户：我想用 BMAD 方法开发一个 [产品名称]

AI：
1. 启动 BMAD 快速路径/完整路径
2. 确认产品简报
3. 按七阶段推进
4. 每阶段产出文档，用户确认后继续

"AI 编程的下一步不是更大的模型，而是更好的协作方式。BMAD 让 AI 从'助手'变成'团队'。"