2026 最完整 AI 编程方法论：全面理解BMAD-METHOD一套可落地的AI敏捷开发工程方法

Prorise2026-01-142026-01-14

我用 AI 写代码翻车的那次

上个月我用 AI 做了个内部管理系统。

前两周爽得飞起：一个 CRUD 模块，以前要写两天，现在半小时就能跑。产品说要加个字段？改。要改个校验规则？改。要调整个布局？改。

到第三周开始崩：

产品说 “这个字段的校验规则好像不对”，我翻了 200 多条对话记录，才找到当时为什么这么写。结果发现，当时理解错了，前面改的 5 个地方全白费。

更崩的是，AI 前天说用 Redis 缓存，昨天又建议改成本地缓存，今天问它又说 “两种方案各有优劣，看你的场景”。我的场景？我的场景就是你前天给我写的那个啊！

测试发现一个 bug，改完发现另外三个模块也受影响。因为当时是在同一个对话里 “顺手改” 的，根本不记得改了哪些地方。

这不是 AI 的问题，是我的用法有问题：我把 AI 当成了 “万能对话框”，而不是 “有分工的团队”。

BMAD 是什么：一个让 AI “有组织” 的框架

BMAD-METHOD（Breakthrough Method of Agile AI-Driven Development）不是一个工具，是一套协作规则。

它解决的核心问题是：在只有一个人或小团队的情况下，怎么把 AI 组织成一套相对稳定的研发流程。

传统的 AI 编程方式是这样的：

你：帮我写个用户管理模块
AI：好的，这是代码...
你：再加个导出功能
AI：好的，已添加...
你：等等，刚才那个权限校验好像有问题
AI：我帮你改一下...
你：不对，这样改会影响其他模块
AI：那我们换个方案...

200 轮对话后，你已经不记得当时为什么这么设计了。

BMAD 的方式是这样的：

Analyst：先把需求说清楚，需要哪些字段、权限、接口
PM：写成PRD，定好优先级
Architect：定技术栈、画架构图、定接口规范
Scrum Master：拆成10个可执行的任务
Developer：按任务写代码，每个任务一个Patch
QA：验证功能，补充测试用例

每个角色只做自己的事，不跨界、不抢活。每个阶段结束后，产出一个工件（文档或代码），作为下一个阶段的输入。

就像公司里有 PM、架构师、开发、测试，BMAD 也有 21 个角色。区别是，这些角色都是 AI。

为什么需要这样做

对话式编程的三个问题

问题 1：上下文会丢

对话超过 50 轮后，AI 开始 “失忆”。

你前面说的约束条件，它后面就忘了。你让它用 Redis，它后面又建议你用本地缓存。你提醒它 “我们之前不是说好用 Redis 吗”，它会说 “抱歉，我理解错了”。

不是 AI 不行，是对话太长了。就像你跟一个人聊了 3 个小时，他也会忘记你一开始说了什么。

问题 2：需求和实现混在一起

在对话里，需求、设计、实现是混在一起推进的。

产品说要改个字段，你在对话里顺手就改了。改完发现，这个字段在另外三个地方也用到了，但你不记得了。因为当时是 “顺手改” 的，没有系统性地梳理影响范围。

三个月后，你完全不记得当时为什么这么设计。对话记录倒是有，但谁会去翻 200 条对话？

问题 3：返工成本越来越高

没有阶段性产出，改动的成本会越来越高。

需求变了，你得从头到尾重新梳理一遍对话，看哪些地方需要改。设计变了，你得重新生成代码，但 AI 可能会把之前的改动覆盖掉。

就像盖房子：如果边盖边改图纸，房子会塌。

BMAD 的思路：拆阶段、定角色、留工件

BMAD 的核心思路很简单：把一个长对话拆成四个短对话，每个对话只做一件事。

为什么要拆阶段

因为人脑和 AI 都有认知边界。

一个对话里同时处理需求、设计、实现，信息量太大，容易出错。拆成四个阶段后，每个阶段的信息量都很小，AI 能记住所有细节。

更重要的是，拆阶段后，改动的成本会大幅降低。

需求变了，只需要重新跑 Analysis 和 Planning，代码不用动。设计变了，只需要重新跑 Solutioning，需求文档不用改。

就像盖房子：图纸画错了，改图纸就行，不用拆房子重盖。

为什么要定角色

因为不同的事需要不同的思维方式。

分析需求的时候，你需要站在用户的角度思考。设计架构的时候，你需要站在技术的角度思考。写代码的时候，你需要站在实现的角度思考。

如果用同一个 AI 做所有事，它会在不同的思维方式之间切换，容易出错。

定角色后，每个 AI 只需要专注于一件事。Analyst 只需要分析需求，不需要考虑实现细节。Developer 只需要写代码，不需要质疑需求合理性。

就像公司里，PM 不会去写代码，开发不会去质疑需求。不是不能，是不应该。

为什么要留工件

因为对话是易失的，工件是持久的。

对话记录很难复盘，三个月后你不会去翻 200 条对话。但工件可以：PRD、架构文档、任务表、代码 Patch，每个都是一个独立的文件，可以随时查看。

更重要的是，工件是可以版本管理的。

需求变了，你可以对比新旧 PRD，看哪些地方变了。代码改了，你可以对比新旧 Patch，看影响范围。

就像 Git 管理代码一样，BMAD 用工件管理整个开发过程。

把仓库拉下来看看

BMAD 以一个 GitHub 仓库的形式存在。安装后，会在你的项目里生成一个 .bmad 目录。

安装和初始化

1	npx bmad-method@alpha install

安装完会问你几个问题：

项目类型？（Web 应用、CLI 工具、API 服务、移动应用…）
团队规模？（个人、小团队、企业）
开发节奏？（快速迭代、稳健交付、合规优先）

根据你的回答，它会推荐一个 Track：

Quick Flow：适合 Bug 修复、小功能，5 分钟起步
BMad Method：适合产品和平台，15 分钟起步
Enterprise：适合合规系统，30 分钟起步

我第一次选了 Quick Flow，因为想快速体验。后来发现，即使是 Quick Flow，也比我之前的 “对话式编程” 清晰太多。

目录结构：21 个角色都在哪

安装完后，项目里会多一个 .bmad 目录：

.bmad/
├── agents/           # 21个AI角色的定义文件
├── workflows/        # 50+工作流脚本
├── templates/        # 工件模板（PRD、架构文档、测试用例）
├── config/           # 项目配置
└── artifacts/        # 生成的工件存放处

agents 目录：21 个角色的定义

打开 agents 目录，你会看到 21 个文件：

agents/
├── analyst.md           # 需求分析师
├── product-manager.md   # 产品经理
├── architect.md         # 架构师
├── scrum-master.md      # 敏捷教练
├── developer.md         # 开发工程师
├── qa-specialist.md     # 测试工程师
├── ux-designer.md       # UX设计师
├── product-owner.md     # 产品负责人
├── tech-lead.md         # 技术负责人
├── devops-engineer.md   # DevOps工程师
├── security-expert.md   # 安全专家
├── data-engineer.md     # 数据工程师
├── ...                  # 还有9个

每个文件定义了一个角色的职责、工作方式、输出格式。

比如 analyst.md：

# Business Analyst

## Role
你是一个需求分析师，负责把模糊的想法变成清晰的需求。

## Responsibilities
- 收集和分析业务需求
- 识别关键约束和风险
- 定义成功标准
- 产出需求分析文档

## Working Style
- 多问"为什么"，少问"怎么做"
- 关注业务价值，不关注技术实现
- 用用户的语言描述需求，不用技术术语

## Output Format
- 需求分析文档（Markdown格式）
- 包含：背景、目标、约束、风险、成功标准

这些定义文件就是角色的 “人设”。

当你调用 /analyst 时，AI 会读取这个文件，按照这个 “人设” 工作。它会多问 “为什么”，会关注业务价值，会用用户的语言描述需求。

workflows 目录：50+工作流脚本

打开 workflows 目录，你会看到 50 多个工作流文件：

workflows/
├── analysis/
│   ├── requirement-analysis.md      # 需求分析流程
│   ├── stakeholder-interview.md     # 干系人访谈流程
│   └── risk-assessment.md           # 风险评估流程
├── planning/
│   ├── prd-creation.md              # PRD编写流程
│   ├── story-breakdown.md           # 用户故事拆解流程
│   └── sprint-planning.md           # 迭代规划流程
├── solutioning/
│   ├── architecture-design.md       # 架构设计流程
│   ├── tech-stack-selection.md      # 技术选型流程
│   └── api-contract-design.md       # 接口契约设计流程
├── implementation/
│   ├── feature-development.md       # 功能开发流程
│   ├── test-driven-development.md   # TDD流程
│   └── code-review.md               # 代码评审流程

每个工作流定义了一个具体任务的执行步骤。

比如 prd-creation.md：

# PRD Creation Workflow

## Input
- 需求分析文档

## Steps
1. 读取需求分析文档
2. 识别核心功能和优先级
3. 定义用户故事和验收标准
4. 补充非功能性需求（性能、安全、可用性）
5. 产出PRD文档

## Output
- PRD文档（Markdown格式）
- 包含：功能列表、用户故事、验收标准、非功能性需求

## Quality Gates
- 每个功能都有明确的验收标准
- 优先级清晰（P0/P1/P2）
- 非功能性需求可量化

这些工作流就是 “操作手册”。

当你调用 /pm 时，AI 会读取对应的工作流文件，按照步骤执行。它会先读取需求分析文档，然后识别核心功能，然后定义用户故事，最后产出 PRD。

templates 目录：工件模板

打开 templates 目录，你会看到各种工件的模板：

templates/
├── requirement-analysis.md    # 需求分析文档模板
├── prd.md                     # PRD模板
├── architecture.md            # 架构文档模板
├── user-story.md              # 用户故事模板
├── test-case.md               # 测试用例模板
├── patch.md                   # 代码Patch模板

比如 prd.md：

# Product Requirements Document

## 1. Overview
### 1.1 Background
[项目背景]

### 1.2 Goals
[项目目标]

### 1.3 Success Criteria
[成功标准]

## 2. Features
### 2.1 Feature 1
- **User Story**: As a [role], I want [feature], so that [benefit]
- **Acceptance Criteria**:
  - [ ] Criterion 1
  - [ ] Criterion 2
- **Priority**: P0/P1/P2

### 2.2 Feature 2
...

## 3. Non-Functional Requirements
### 3.1 Performance
[性能要求]

### 3.2 Security
[安全要求]

### 3.3 Usability
[可用性要求]

这些模板确保了工件的格式统一。

当 AI 产出 PRD 时，会按照这个模板填充内容。这样，所有项目的 PRD 格式都是一致的，方便复盘和对比。

artifacts 目录：生成的工件

这个目录是空的，用来存放生成的工件。

当你跑完一个完整流程后，这个目录会变成这样：

artifacts/
├── analysis/
│   └── requirement-analysis-20250115.md
├── planning/
│   ├── prd-20250115.md
│   └── stories-20250115.csv
├── solutioning/
│   ├── architecture-20250115.md
│   └── api-contract-20250115.yaml
├── implementation/
│   ├── patch-001-add-user-export.md
│   ├── patch-002-add-permission-check.md
│   └── test-report-20250115.md

每个工件都是一个独立的文件，可以随时查看、对比、回滚。

四个阶段在做什么

BMAD 把开发过程拆成四个阶段：Analysis → Planning → Solutioning → Implementation。

Analysis：把模糊想法变成清晰问题

这个阶段的目标是：把 “我想要个用户管理” 变成 “需要哪些字段、权限、接口”。

为什么需要这个阶段

因为大部分需求一开始都是模糊的。

产品说 “我想要个用户管理”，但他没说：

用户有哪些字段？姓名、邮箱、手机号？
用户有哪些权限？管理员、普通用户、访客？
用户怎么登录？账号密码、手机验证码、第三方登录？
用户数据怎么存储？MySQL、MongoDB、Redis？

如果直接开始写代码，这些问题会在实现过程中不断冒出来。每次冒出来，都要停下来讨论，然后改代码。

Analysis 阶段就是把这些问题提前问清楚。

这个阶段产出什么

一个需求分析文档，包含：

背景：为什么要做这个功能
目标：这个功能要解决什么问题
约束：有哪些限制条件（时间、预算、技术栈）
风险：可能遇到哪些问题
成功标准：怎么判断这个功能做成功了

对比：有 Analysis vs 没有 Analysis

没有 Analysis 的情况：

你：帮我写个用户管理模块
AI：好的，这是代码...
你：等等，用户需要有权限管理
AI：好的，我加上...
你：不对，权限应该是角色级别的，不是用户级别的
AI：好的，我改一下...
你：还有，用户需要支持第三方登录
AI：好的，我再改...

改了 5 次，每次都要重新生成代码。

有 Analysis 的情况：

Analyst：这个用户管理模块，需要支持哪些功能？
你：基本的增删改查，还有权限管理
Analyst：权限是用户级别的，还是角色级别的？
你：角色级别的
Analyst：需要支持第三方登录吗？
你：需要，微信和支付宝
Analyst：好的，我整理一下需求...

一次性把需求问清楚，后面不用反复改。

Planning：拆任务表和里程碑

这个阶段的目标是：把需求拆成 10 个可执行的任务，排好优先级。

为什么需要这个阶段

因为一个大需求直接开始写，很容易失控。

“用户管理模块” 听起来很简单，但实际上包含：

用户表设计
注册接口
登录接口
权限校验
角色管理
第三方登录
用户列表
用户详情
用户编辑
用户删除

如果不拆任务，你会在这 10 个功能之间跳来跳去，最后哪个都没做完。

Planning 阶段就是把大需求拆成小任务，一个一个做。

这个阶段产出什么

两个工件：

PRD 文档：详细描述每个功能的用户故事和验收标准
任务表：CSV 格式的任务列表，包含优先级、预估工时、依赖关系

比如任务表：

ID,Task,Priority,Estimate,Dependencies,Status
1,设计用户表结构,P0,2h,,TODO
2,实现注册接口,P0,4h,1,TODO
3,实现登录接口,P0,4h,1,TODO
4,实现权限校验中间件,P0,3h,1,TODO
5,实现角色管理接口,P1,6h,1,TODO
6,实现第三方登录,P1,8h,3,TODO
7,实现用户列表接口,P1,3h,4,TODO
8,实现用户详情接口,P2,2h,4,TODO
9,实现用户编辑接口,P2,3h,4,TODO
10,实现用户删除接口,P2,2h,4,TODO

对比：有 Planning vs 没有 Planning

没有 Planning 的情况：

你：帮我写个用户管理模块
AI：好的，我先写注册接口...
你：等等，先写用户表结构
AI：好的，这是用户表...
你：不对，还需要角色表
AI：好的，我加上...
你：还有，权限校验怎么做？
AI：我们可以用中间件...

没有计划，想到哪做到哪，最后发现很多地方需要返工。

有 Planning 的情况：

PM：根据需求分析，我拆了10个任务
你：看起来不错，但第三方登录优先级是不是太高了？
PM：你说得对，我调整一下优先级
Scrum Master：好的，我们先做P0的任务，P1的任务放到下个迭代

有计划，按优先级做，不会返工。

Solutioning：定技术方案和架构

这个阶段的目标是：定技术栈、画架构图、定接口规范。

为什么需要这个阶段

因为同一个需求，可以有多种实现方式。

“用户管理模块” 可以用：

技术栈：Node.js + Express + MySQL，或者 Python + Django + PostgreSQL
架构：单体应用，或者微服务
认证方式：JWT，或者 Session
缓存策略：Redis，或者本地缓存

如果不提前定方案，开发过程中会不断纠结 “用哪个更好”。

Solutioning 阶段就是把技术方案定下来，后面不用纠结。

这个阶段产出什么

两个工件：

架构文档：描述系统的整体架构、技术栈、关键设计决策
接口契约：定义所有接口的请求和响应格式（OpenAPI 格式）

比如架构文档：

# Architecture Document

## 1. Technology Stack
- **Backend**: Node.js + Express
- **Database**: MySQL
- **Cache**: Redis
- **Authentication**: JWT

## 2. System Architecture
[架构图]

## 3. Key Design Decisions
### 3.1 Why JWT instead of Session?
- 无状态，易于扩展
- 支持跨域
- 适合微服务架构

### 3.2 Why Redis for caching?
- 高性能
- 支持多种数据结构
- 易于集群部署

对比：有 Solutioning vs 没有 Solutioning

没有 Solutioning 的情况：

你：帮我写个注册接口
AI：好的，用JWT还是Session？
你：用JWT吧
AI：好的，这是代码...
你：等等，登录接口也要用JWT吗？
AI：是的，保持一致
你：那权限校验呢？
AI：也用JWT...

每次都要问一遍，浪费时间。

有 Solutioning 的情况：

1 2	Architect：我们用JWT做认证，所有接口都用这个方案 Developer：好的，我按这个方案写代码

方案定好了，后面不用问。

Implementation：写代码和测试

这个阶段的目标是：按任务写代码，每个任务一个 Patch。

为什么用 Patch 而不是直接修改文件

因为 Patch 是可追溯的。

一个 Patch 包含：

变更说明：为什么要改
影响范围：改了哪些文件
代码 diff：具体改动
测试用例：如何验证
回滚方案：出问题怎么办

如果直接修改文件，三个月后你不记得为什么这么改。但如果用 Patch，你可以随时查看这个 Patch 的变更说明。

这个阶段产出什么

每个任务产出一个 Patch 文件：

# Patch-001: Add User Registration API

## Change Description
实现用户注册接口，支持邮箱和手机号注册

## Affected Files
- src/routes/user.js
- src/controllers/user.controller.js
- src/services/user.service.js
- src/models/user.model.js
- tests/user.test.js

## Code Changes
[具体的代码diff]

## Test Cases
- 测试邮箱注册成功
- 测试手机号注册成功
- 测试重复注册失败
- 测试参数校验

## Rollback Plan
如果出现问题，执行：
git revert [commit-hash]

对比：Patch 式开发 vs 传统开发

传统开发：

你：帮我写个注册接口
AI：好的，这是代码...
你：改一下，邮箱格式校验不对
AI：好的，已修改...
你：再改一下，密码强度校验不对
AI：好的，已修改...

改了 3 次，但你不记得每次改了什么。

Patch 式开发：

Developer：这是Patch-001，实现注册接口
你：邮箱格式校验不对
Developer：好的，这是Patch-002，修复邮箱校验
你：密码强度校验不对
Developer：好的，这是Patch-003，修复密码校验

每次改动都是一个独立的 Patch，可以随时查看、对比、回滚。

polyv-live-cli：一个真实案例

polyv-live-cli 是一个完全按 BMAD 跑下来的 CLI 项目。

项目背景

这是一个保利威直播云的命令行工具，用来管理直播频道、控制直播流。

功能包括：

频道管理：创建、查看、更新、删除直播频道
流控制：获取推流密钥、开始/停止直播、实时状态监控
认证集成：完整的 PolyV OpenAPI 认证支持

技术栈：

TypeScript
Commander（CLI 框架）
PolyV API

为什么适合用 BMAD？

因为这个项目虽然不大，但涉及多个模块（频道管理、流控制、认证），需要清晰的架构设计和完整的测试覆盖。如果用对话式编程，很容易写着写着就乱了。

关键工件展示

需求分析文档

# Requirement Analysis: PolyV Live CLI

## Background
保利威直播云提供了Web控制台，但对于开发者来说，命令行工具更高效。

## Goals
- 提供命令行方式管理直播频道
- 支持自动化脚本集成
- 提供友好的错误提示

## Constraints
- 必须兼容PolyV OpenAPI v3
- 必须支持Node.js 20+
- 必须提供完整的TypeScript类型定义

## Success Criteria
- 所有核心功能可通过命令行完成
- 测试覆盖率达到80%+
- 错误提示清晰易懂

PRD 文档

# PRD: PolyV Live CLI

## Feature 1: Channel Management
**User Story**: As a developer, I want to manage channels via CLI, so that I can automate channel operations.

**Acceptance Criteria**:
- [ ] 支持创建频道（channel create）
- [ ] 支持查看频道列表（channel list）
- [ ] 支持查看频道详情（channel get）
- [ ] 支持更新频道（channel update）
- [ ] 支持删除频道（channel delete）

**Priority**: P0

## Feature 2: Stream Control
**User Story**: As a developer, I want to control live streams via CLI, so that I can automate streaming operations.

**Acceptance Criteria**:
- [ ] 支持获取推流密钥（stream get-key）
- [ ] 支持开始直播（stream start）
- [ ] 支持停止直播（stream stop）
- [ ] 支持查看流状态（stream status）

**Priority**: P0

架构文档

# Architecture: PolyV Live CLI

## Technology Stack
- **Language**: TypeScript
- **CLI Framework**: Commander
- **HTTP Client**: Axios
- **Testing**: Jest

## System Architecture

src/
├── commands/      # CLI命令定义
├── handlers/      # 业务逻辑处理器
├── services/      # API服务层
├── types/         # TypeScript类型定义
├── utils/         # 工具函数
└── config/        # 配置管理

## Key Design Decisions
### Why TypeScript?
- 类型安全，减少运行时错误
- 更好的IDE支持
- 更容易维护

### Why Commander?
- 成熟的CLI框架
- 支持子命令和选项
- 自动生成帮助文档

### Why 分层架构?
- 命令层：只负责参数解析和输出格式化
- 处理器层：负责业务逻辑编排
- 服务层：负责API调用
- 清晰的职责划分，易于测试和维护

任务表

ID	Task	Priority	Estimate	Dependencies	Status
1	搭建项目脚手架	P0	2h		DONE
2	实现 PolyV API 签名认证	P0	4h	1	DONE
3	实现频道创建命令	P0	3h	2	DONE
4	实现频道列表命令	P0	2h	2	DONE
5	实现频道详情命令	P0	2h	2	DONE
6	实现频道更新命令	P0	3h	2	DONE
7	实现频道删除命令	P0	2h	2	DONE
8	实现推流密钥获取命令	P0	3h	2	DONE
9	实现开始直播命令	P0	2h	2	DONE
10	实现停止直播命令	P0	2h	2	DONE
11	实现流状态查询命令	P0	3h	2	DONE
12	实现配置管理功能	P1	4h	1	DONE
13	实现错误处理和友好提示	P1	3h	1	DONE
14	编写单元测试	P1	8h	3-11	DONE
15	编写集成测试	P1	6h	14	DONE
16	编写文档	P2	4h	15	DONE

Patch 示例

# Patch-003: Implement Channel Create Command

## Change Description
实现频道创建命令，支持通过命令行创建直播频道

## Affected Files
- src/commands/channel.commands.ts (新增)
- src/handlers/channel.handler.ts (新增)
- src/services/channel.service.ts (新增)
- src/types/channel.ts (新增)
- tests/channel.test.ts (新增)

## Code Changes

src/commands/channel.commands.ts

import { Command } from 'commander';
import { ChannelHandler } from '../handlers/channel.handler';

export function registerChannelCommands(program: Command) {
  const channel = program.command('channel');

  channel
    .command('create')
    .description('创建直播频道')
    .requiredOption('--name <string>', '频道名称')
    .requiredOption('--scene <string>', '场景类型: topclass|ppt|pure')
    .option('--description <string>', '频道描述')
    .option('--publisher <string>', '主持人名称')
    .action(async (options) => {
      const handler = new ChannelHandler();
      await handler.createChannel(options);
    });
}

src/handlers/channel.handler.ts

export class ChannelHandler {
  private channelService: ChannelService;

  constructor() {
    this.channelService = new ChannelService();
  }

  async createChannel(options: CreateChannelOptions): Promise<void> {
    try {
      // 参数校验
      this.validateCreateOptions(options);

      // 调用服务层
      const result = await this.channelService.create(options);

      // 格式化输出
      console.log('频道创建成功:');
      console.log(`频道ID: ${result.channelId}`);
      console.log(`频道名称: ${result.name}`);
    } catch (error) {
      // 错误处理
      this.handleError(error);
    }
  }

  private validateCreateOptions(options: CreateChannelOptions): void {
    const validScenes = ['topclass', 'ppt', 'pure'];
    if (!validScenes.includes(options.scene)) {
      throw new Error(`无效的场景类型: ${options.scene}`);
    }
  }
}

src/services/channel.service.ts

export class ChannelService {
  private apiClient: PolyVApiClient;

  constructor() {
    this.apiClient = new PolyVApiClient();
  }

  async create(options: CreateChannelOptions): Promise<Channel> {
    const params = {
      name: options.name,
      scene: options.scene,
      description: options.description,
      publisher: options.publisher,
    };

    // 调用 PolyV API
    const response = await this.apiClient.post('/channel/create', params);

    return response.data;
  }
}

## Test Cases

### tests/channel.test.ts

describe('Channel Create Command', () => {
  it('should create channel successfully', async () => {
    const options = {
      name: '测试频道',
      scene: 'topclass',
      description: '这是一个测试频道',
    };

    const handler = new ChannelHandler();
    await handler.createChannel(options);

    // 验证频道创建成功
    expect(mockChannelService.create).toHaveBeenCalledWith(options);
  });

  it('should throw error for invalid scene', async () => {
    const options = {
      name: '测试频道',
      scene: 'invalid',
    };

    const handler = new ChannelHandler();

    // 验证参数校验
    await expect(handler.createChannel(options)).rejects.toThrow('无效的场景类型');
  });
});

## Rollback Plan
如果出现问题：
1. 回滚代码：`git revert [commit-hash]`
2. 删除相关文件
3. 恢复到Patch-002的状态

测试覆盖率报告

Test Suites: 15 passed, 15 total
Tests:       87 passed, 87 total
Snapshots:   0 total
Time:        12.456 s

Coverage:
--------------------|---------|----------|---------|---------|
File                | % Stmts | % Branch | % Funcs | % Lines |
--------------------|---------|----------|---------|---------|
All files           |   82.45 |    78.32 |   85.67 |   82.45 |
 commands/          |   95.23 |    90.12 |   100   |   95.23 |
 handlers/          |   88.76 |    82.45 |   92.34 |   88.76 |
 services/          |   78.34 |    72.56 |   80.12 |   78.34 |
 utils/             |   76.89 |    68.23 |   75.45 |   76.89 |
--------------------|---------|----------|---------|---------|

为什么能做到 80%测试覆盖率

不是因为我写测试写得好，是因为 BMAD 的流程让测试变得自然。

在 Implementation 阶段，每个 Patch 都要求同步补充测试用例。不是 “代码写完再补测试”，而是 “写代码的同时写测试”。

更重要的是，因为有清晰的 PRD 和架构文档，测试用例很容易写：

PRD 定义了验收标准：每个功能的验收标准就是测试用例
架构文档定义了边界：知道哪些地方需要测试，哪些地方不需要
Patch 定义了影响范围：知道这次改动影响了哪些模块，需要补充哪些测试

就像盖房子：图纸画好了，验收标准也就清楚了。

你该怎么开始

不要一次性用全部功能

BMAD 有 21 个角色、50+工作流，看起来很复杂。但你不需要一次性用全部功能。

我的建议是：从 Quick Flow 开始，用一个小需求试试。

Quick Flow 只用 4 个角色：

Analyst：分析需求
PM：写简化版 PRD
Developer：写代码
QA：验证功能

整个流程 15 分钟就能跑完。

等你熟悉了流程，再尝试完整的 BMad Method。那时候你会发现，21 个角色并不复杂，每个角色都有明确的职责，用起来很自然。

选一个合适的需求

不要选太简单的需求（比如 “写个 Hello World”），也不要选太复杂的需求（比如 “写个电商系统”）。

合适的需求是：

有一定复杂度：涉及 2-3 个模块，需要考虑架构设计
边界清晰：需求明确，不会频繁变动
可以独立完成：不依赖其他系统或团队

比如：

给现有系统增加 “用户导出 Excel” 功能
写一个 CLI 工具，调用某个 API
实现一个简单的权限管理模块

这种需求，用 BMAD 跑一遍，大概需要 1-2 小时。跑完后，你会发现：

需求分析文档帮你把需求想清楚了
PRD 和任务表帮你把工作拆清楚了
架构文档帮你把方案定清楚了
Patch 帮你把改动记清楚了

三个最容易踩的坑

坑 1：跳过 Planning 直接写代码

我第一次用 BMAD 的时候，觉得 Planning 阶段太慢了。需求都分析完了，为什么还要写 PRD、拆任务？直接写代码不是更快吗？

结果写到一半发现，有些功能的优先级搞错了。本来应该先做权限校验，我先做了用户列表。导致后面要返工，把权限校验逻辑加到所有接口里。

教训：Planning 阶段看起来慢，但能避免返工。前面慢一点，后面会快很多。

坑 2：工件不完整，后面无法复盘

我第二次用 BMAD 的时候，觉得工件太啰嗦了。需求分析文档、PRD、架构文档，写这么多有什么用？

结果三个月后，产品说要改一个功能。我完全不记得当时为什么这么设计，翻了半天代码才搞清楚。

教训：工件不是为了现在，是为了三个月后。当时觉得啰嗦，后面会感谢自己。

坑 3：对话和流程混用

我第三次用 BMAD 的时候，有时候会偷懒。小改动就不走流程了，直接在对话里让 AI 改。

结果改着改着，又回到了 “对话式编程” 的老路。改了 10 次，不记得每次改了什么，最后又乱了。

教训：要么用对话，要么用流程，不要混用。混用会让流程失效。

什么时候不需要 BMAD

BMAD 不是万能的，有些场景不适合用。

临时脚本和一次性任务

如果你只是想写个临时脚本，跑一次就扔，不需要用 BMAD。

比如：

批量处理一些数据
临时测试一个 API
写个 Demo 验证一个想法

这种场景，对话式编程更快。

探索性编程

如果你还不确定要做什么，需要先探索一下，不需要用 BMAD。

比如：

尝试一个新技术
验证一个技术方案的可行性
快速做一个原型

这种场景，对话式编程更灵活。

需求频繁变动的项目

如果需求每天都在变，用 BMAD 会很痛苦。

因为 BMAD 的核心是 “先定需求，再定方案，最后写代码”。如果需求天天变，你会不断重新跑 Analysis 和 Planning，反而更慢。

这种场景，建议先用对话式编程快速迭代，等需求稳定了，再用 BMAD 重构。

对比：三种编程方式

	对话式编程	BMAD Quick Flow	BMAD 完整流程
适合场景	临时脚本、探索性编程	小功能、Bug 修复	产品、平台、企业系统
起步时间	1 分钟	5 分钟	15-30 分钟
角色数量	1 个	4 个	21 个
工件数量	0 个	2-3 个	10+个
可追溯性	低	中	高
返工成本	高	中	低
学习曲线	平缓	中等	陡峭

我的建议：

刚开始学 AI 编程：用对话式编程，快速上手
项目开始失控：用 BMAD Quick Flow，体验流程化开发
需要长期维护：用 BMAD 完整流程，建立完整的工件体系

最后

真正用 BMAD 跑过几个需求之后，我最大的感受不是 “效率提升了多少”，而是：项目变得更容易继续往下做了。

你能清楚知道：

需求是怎么定的
为什么选这个方案
哪些地方改过
有没有测试和回滚

如果你已经在用 AI 写代码，但开始觉得项目节奏失控，BMAD 至少值得你挑一个不太复杂的需求，完整跑一遍。

不需要一次性照搬所有规则，只要走完一次 “Analysis → Planning → Solutioning → Implementation”，很多问题会自己浮现出来。

对我来说，BMAD 更像是一种：把节奏放慢一点，但能走得更远的做法。

参考资料

BMAD-METHOD GitHub 仓库：https://github.com/bmad-code-org/BMAD-METHOD
polyv-live-cli 项目：https://github.com/terryso/polyv-live-cli
BMAD 官方文档：https://docs.bmad-method.org

本文转自 https://zhuanlan.zhihu.com/p/1988548181668160633，如有侵权，请联系删除。

Prorise

2026 最完整 AI 编程方法论：全面理解BMAD-METHOD一套可落地的AI敏捷开发工程方法

我用 AI 写代码翻车的那次

BMAD 是什么：一个让 AI “有组织” 的框架

为什么需要这样做

对话式编程的三个问题

问题 1：上下文会丢

问题 2：需求和实现混在一起

问题 3：返工成本越来越高

BMAD 的思路：拆阶段、定角色、留工件

为什么要拆阶段

为什么要定角色

为什么要留工件

把仓库拉下来看看

安装和初始化

目录结构：21 个角色都在哪

agents 目录：21 个角色的定义

workflows 目录：50+工作流脚本

templates 目录：工件模板

artifacts 目录：生成的工件

四个阶段在做什么

Analysis：把模糊想法变成清晰问题

为什么需要这个阶段

这个阶段产出什么

对比：有 Analysis vs 没有 Analysis

Planning：拆任务表和里程碑

为什么需要这个阶段

这个阶段产出什么

对比：有 Planning vs 没有 Planning

Solutioning：定技术方案和架构

为什么需要这个阶段

这个阶段产出什么

对比：有 Solutioning vs 没有 Solutioning

Implementation：写代码和测试

为什么用 Patch 而不是直接修改文件

这个阶段产出什么

对比：Patch 式开发 vs 传统开发

polyv-live-cli：一个真实案例

项目背景

关键工件展示

需求分析文档

PRD 文档

架构文档

任务表

Patch 示例

src/commands/channel.commands.ts

src/handlers/channel.handler.ts

src/services/channel.service.ts

测试覆盖率报告

为什么能做到 80%测试覆盖率

你该怎么开始

不要一次性用全部功能

选一个合适的需求

三个最容易踩的坑

坑 1：跳过 Planning 直接写代码

坑 2：工件不完整，后面无法复盘

坑 3：对话和流程混用

什么时候不需要 BMAD

临时脚本和一次性任务

探索性编程

需求频繁变动的项目

对比：三种编程方式

最后

文章思维导图