# Bmad Method

> AI驱动敏捷开发方法论：一人顶一个团队的虚拟AI开发团队协作框架。当用户说'帮我开发一个产品'、'从零开始做一个项目'、'用AI团队协作开发'、'BMAD'、'敏捷AI开发'、'AI代理团队'、'虚拟开发团队'、'产品全流程开发'时触发。核心特点：多AI角色协作（PM/架构师/Dev/QA）、规划与执行分离、文档分片、上下文工程化开发。

- Skill: `gaoqiongxie/bmad-method` (Agent Skill)
- Install (CLI): `npx skillmds@latest add gaoqiongxie/bmad-method`
- Raw SKILL.md: https://api.skillmd.com/api/skills/gaoqiongxie/bmad-method/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: gaoqiongxie (https://skillmd.com/u/gaoqiongxie)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/gaoqiongxie/bmad-method

---


> **来源**: [bmad-code-org/BMAD-METHOD](https://github.com/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`

```markdown
# {产品名} 产品简报

## 问题
用户遇到什么痛点？

## 解决方案
我们要做什么？

## 目标用户
谁会用这个产品？

## 成功指标
怎么衡量做得好？

## 范围
- 包含：...
- 不包含：...

## 竞品参考
- 对标产品：...
- 差异化点：...
```

---

#### 阶段 2：PRD 文档（Product Requirements Document）

**负责人**：PM

**输出**：`prd.md`

```markdown
# {功能名} PRD

## 背景
...

## 目标
...

## 用户故事
作为 [角色]，我想要 [功能]，以便 [价值]

## 功能规格
### 功能 1：...
- 输入：...
- 处理：...
- 输出：...
- 边界情况：...

## 非功能需求
- 性能：...
- 安全：...
- 兼容性：...

## 验收标准
- [ ] 标准 1
- [ ] 标准 2
```

---

#### 阶段 3：架构设计（Architecture）

**负责人**：架构师

**输出**：`architecture.md`

```markdown
# {系统名} 架构设计

## 技术栈
- 前端：...
- 后端：...
- 数据库：...
- 部署：...

## 系统架构图
[文字描述或 ASCII 图]

## 数据模型
```
User {
  id: UUID
  name: String
  email: String
}
```

## 接口定义
### API 1: POST /api/users
- 请求：...
- 响应：...
- 错误码：...

## 关键决策
- 决策 1：选择 XX 而不是 YY，原因...
- 决策 2：...

## 安全考量
- 认证：...
- 授权：...
- 数据保护：...
```

---

#### 阶段 4：Epic 拆分

**负责人**：PO + Scrum Master

**输出**：`epics/` 目录下的多个 epic 文件

```markdown
# 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`

```markdown
# 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` |

### 引用机制

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

```markdown
# 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 从'助手'变成'团队'。"