1. 引言

昨天听了 Qoder 团队在工具开发上的分享，聊到了 BMAD-Method 开发方法。

面向真实工程的 AI 协作方法论：从「AI 编程助手」进化为「AI 开发团队」，以可计划、可追踪、可交付的方式持续提升研发效率。

2. 认识 BMAD-METHOD

2.1. 核心概念

BMAD 并不是把 AI 拉进开发工具那么简单，它把「人—AI—流程—工件」统一到一个工程语境里：先把问题说清楚，再把计划立起来，随后以补丁为最小交付单元持续推进，实现期间每一步都有验证与可观察性兜底。

它强调最小权限和只读优先，尽可能把风险挡在门外；同时通过任务表、报告和指标把工作变成「可量化、可复盘」的事实。

2.1.1. 定义

BMAD-METHOD 是一套将多代理（Multi-Agent）与工程化「门禁/工件/度量」结合的研发方法论。目标是让 AI 不再只是单一助手，而是可被编排的「虚拟研发团队」。

2.1.2. 目标

• 以「计划—实现—验证—交付」的闭环形成稳定产能
• 通过标准工件（计划、任务、补丁、测试、报告）实现可追溯与复盘
• 以最小权限和只读优先，降低风险与副作用

2.1.3. 适用场景

• 中大型功能开发、跨端集成与联调、规范化交付
• 有明确质量门槛（性能、安全、合规、可维护性）的工程任务

2.1.4. 关键特性

• 人工智能驱动的协作：以 AI 代理模拟完整敏捷团队，使个人或小团队获得「全栈团队」的能力，而不必承担对应成本与复杂度。
• 多智能体框架：涵盖产品经理、架构师、开发人员、Scrum 主管等专业角色，每个角色由一个 AI 代理负责，确保从规划到执行的各环节被覆盖。
• 分阶段开发流程：划分为规划阶段（使用 Web/协作界面）与执行阶段（使用 IDE/工程环境），在项目全生命周期保持清晰、有条理。
• 上下文保留：通过「文档碎片化」技术把大文档拆分成任务相关的小片段，确保 AI 始终能访问到正确的上下文，降低信息丢失风险。
• 人类能力放大：以引导式的反思工作流增强人类创造力与判断力，让使用者更容易发现更优方案并优化想法，而非替代人的投入。

BMAD 不是「又一个工具」，而是一套让人与 AI 在工程语境下协作的规则、工件与度量的组合。先从理解它的目标与边界开始，确保后续所有实践都围绕「稳定产出、可追溯、可复盘」的核心展开。

3. 基本原理

3.1. 方法论框架

BMAD 的核心是把研发活动拆解成可被管理的角色与工件，并用清晰的门禁与度量来约束改动。

谁负责定义目标、谁产出补丁与测试、谁进行审核与验收，都要在一开始说清楚；同时，每一次改动都以补丁和契约落地，避免「口头改需求」带来的漂移。

计划模式保证动作之前先研究，最小权限降低风险，度量让质量不再停留在感觉层面。

3.1.1. 角色分工（可由人和 AI 共同承担）

• Owner/Tech Lead：目标定义、方案把关、门禁规则与风险控制
• Specialist Agents：搜索/分析/生成/测试等专长代理
• Reviewer/QA：代码与工件审核、测试与验收

3.1.2. 体系

3.1.2.1. 计划工件

• 需求分析
• 范围说明
• 里程碑
• 任务拆解（CSV/表格）

3.1.2.2. 实现工件

• 补丁（Patch）
• 接口契约
• 配置与脚手架

3.1.2.3. 验证工件

• 测试用例
• 压测与安全检查
• 联调记录

3.1.2.4. 交付工件

• 上线清单
• 回滚预案
• 监控与告警配置

3.1.3. 治理机制

• 计划模式（Plan Mode）：先研究与规划，再执行修改
• 最小权限与只读优先：减少不可控改动与安全风险
• 门禁与度量：完成标准、质量红线、性能与缺陷指标

原理的关键在于「可分工、可落地、可度量」。把角色职责、工件类型和门禁标准说清楚，团队才能用一致的语言推进工作，AI 才能被稳健地编排进流程，减少失控与返工。

4. 使用方法（SOP）

4.1. 标准操作流程

标准作业流程把「想明白、做正确、交付稳」变成一条可执行的路径。

先把需求与边界建模清楚，再给出可比较的方案与计划；实现阶段以补丁推进，并且每次改动都要配测试和可观察性；联调阶段不只看功能，更要过接口、兼容、性能与安全四关；最后在灰度与监控下发布，并把复盘写入团队的共同知识。

4.1.1. 输入与建模

• 收集用户需求与约束，形成高层目标（Problem Statement）
• 进行语义解构：范围、边界、风险与成功标准

4.1.2. 方案与计划

• 输出架构与方案备选，明确取舍与依赖
• 生成里程碑与任务表（CSV），可直接导入任务系统

4.1.3. 执行与工件产出

• 以补丁（Patch）为基本单元推进实现，同步产生接口契约与配置
• 对关键改动配套测试与可观察性（埋点/日志/告警）

4.1.4. 联调与验证

• 按「功能/接口/兼容/性能/安全」五类测试闭环
• 缺陷追踪与回归，达成验收标准

4.1.5. 上线与复盘

• 灰度发布与回滚演练，监控指标稳定
• 复盘效率与缺陷，迭代 SOP 与组件库

SOP 是一条从「想清楚」到「交付好」的流水线。把补丁作为最小交付单元、把测试与可观察性前置、把复盘变成常态，你会看到产能稳定提升而非偶然爆发。

5. 实操落地步骤

5.1. 实施指南

把 BMAD 落地到团队需要先把「谁能做什么」与「做完要留什么痕迹」说清楚。

权限边界划定后，工件模板统一起来，大家就能用同一种语言协作。流程上坚持只读先行、计划在前，改动以补丁推进，验证与度量贯穿始终，这样才有可能把「规范」变成「习惯」。

5.1.1. 准备阶段

• 定义角色与权限边界（谁能写、谁只读、谁审核）
• 约定工件模板：计划、任务 CSV、补丁、测试、报告格式

5.1.2. 工具与流程

• 建立「只读→计划→编辑→验证」的流水线
• 接入口径：搜索、阅读、表格导入、补丁应用与测试执行

5.1.3. 质量门禁

• 完成定义（DoD）：功能闭环、测试通过、性能达标、安全合规
• 度量看板：缺陷趋势、交付周期、回滚率、告警稳定性

落地不在于多复杂的工具，而在于把权限、模板和门禁立起来。标准化的工件与度量，让协作从「口头约定」变成「可检查的事实」。

6. 项目示例：抖音小程序工程

在一个已经具备核心能力的小程序项目上，BMAD 的作用是把「剩余集成与上线」做得更稳更快。

用里程碑与任务表明确推进节奏；以补丁和契约落地账号授权、支付回调、分享与消息；通过系统化的测试与灰度发布降低风险。

最终，不只是把功能做完，更是让交付过程可被度量与持续改进。

6.1. 现状

三模态展示与试衣功能已就绪；需完成账号授权、支付/订单、分享与消息、联调测试与上线。

6.2. 应用 BMAD

6.2.1. 计划

• 输出里程碑与任务 CSV（需求→架构→前后端→AI/3D→测试→上线）

6.2.2. 实现

• 以补丁推进页面与接口
• tt.pay 支付接入、消息订阅、分享路径与风控落地

6.2.3. 验证

• 功能/接口/兼容/性能/安全综合测试
• 灰度与回滚预案

6.3. 效率提升点

• 明确分工与工件标准，减少沟通成本
• 通过计划模式与最小权限降低返工与风险
• 用任务表与度量驱动交付节奏与质量

示例的价值在于可复用。把 BMAD 套进抖音小程序这样具象的工程，你会更容易看到它在「计划清晰、接口稳健、上线有序」上的实效，而不仅是理念。

7. 优势与度量

7.1. 价值评估指标

BMAD 的优势体现在「过程透明、结果可量」。

当任务被拆解并以补丁推进，效率自然提高；当测试与门禁前置，质量与回滚率会有直观改善；当所有改动都有工件记录与监控支撑，问题定位更快，复盘也不再空泛。

用一套指标看板把这些变化量化，团队才能形成稳态进步。

7.1.1. 效率

• 任务拆解与并行推进，提高吞吐量与响应速度

7.1.2. 质量

• 门禁与测试前置，缺陷率下降、回滚更少

7.1.3. 可追溯

• 工件齐备，复盘与知识沉淀更容易

7.1.4. 风险控制

• 只读优先与权限隔离，安全与合规可控

7.1.5. 可观察

• 监控与告警贯穿始终，问题定位快速

优势不是「说出来」的，而是「量出来」的。以效率、质量、风险和可观察性四类指标衡量改进，让决策更理性，也让团队对持续投入更有信心。

8. 最佳实践与常见陷阱

8.1. 实践指南与注意事项

把 BMAD 做好，关键不在于「懂不懂」，而在于「做不做」。

计划先行、改动必测、先备回滚、任务粒度恰当，这些朴素的纪律决定了长期的交付质量。同样地，最常见的失败都源于违背这些纪律：无计划、无工件、无门禁，最终让项目滑向不可控。

8.1.1. 最佳实践

• 先计划后执行，严格遵守门禁与完成定义
• 任务粒度适中，避免割裂或过粗
• 关键改动必须配套测试与回滚方案
• 维护度量看板，定期复盘 SOP

8.1.2. 常见陷阱

• 无计划直接改代码，导致返工与风险扩散
• 工件缺失（无任务表/无测试/无报告）难以复盘
• 权限过宽或无最小化，造成安全隐患

方法论真正的挑战在于「纪律」。先计划后执行、改动必配测试和回滚、权限最小化，这些听起来朴素，但正是长期稳定交付的根基。

8.2. 快速上手指南

上手 BMAD 不需要大动干戈。

把角色与权限先画出来，把工件模板整理好，然后坚持「只读→计划→编辑→验证→交付」的顺序。

挑一个真实但不复杂的需求，走完整个闭环，你就会感受到「规范带来的速度」。

8.2.1. 交付清单

1. 定义角色与权限边界
2. 准备工件模板（计划/任务 CSV/补丁/测试/报告）
3. 建立只读→计划→编辑→验证→交付的流水线
4. 设定度量指标与看板（缺陷、效率、风险）
5. 从一个真实需求开始练习，按 SOP 完成闭环交付

清单不是形式主义，而是把复杂事情拆成可完成的小步伐。从一个小需求开始，完成一条「研究→计划→补丁→验证→交付」的闭环，建立团队的肌肉记忆。

9. 资源与参考

9.1. 学习资料与工具

学习 BMAD 最快的方式是结合官方仓库与社区文章，边读边做，尽快形成自己的模板与 SOP。

把可用的图示、任务表、补丁格式与测试清单沉淀到项目仓库里，让团队有现成可复用的「工程语言」。

9.1.1. 官方仓库

• github.com/bmad-code-org/BMAD-METHOD

9.1.2. 文章

• www.cnblogs.com/NickYao/p/18984826
• www.echovic.com/blog/AI/from-ai-programming-assistant-to-ai-development-team-bmad-method
• jieyibu.net/htmlpages/bmad.html

参考不是装饰，是实践的捷径。结合官方仓库与社区文章，形成你自己的 SOP 与模板库，让团队少踩坑、快起步。