夜雨聆风嗨，我是辉哥，一个致力于使用 AI 技术搞副业的超级个体
BMAD-METHOD（Breakthrough Method for Agile AI Driven Development）是一个 48K+ Stars 的开源框架，定位很明确：让 AI 作为专家协作者引导你做决策，而不是替你思考。
本文从源码层面拆解 BMAD 的 Skill 文件，回答：
1. BMAD 解决什么问题——AI 角色模糊和流程覆盖不完整？ 2. 四阶段生命周期如何组织——从 Analysis 到 Implementation？ 3. Agent + Workflow 双层架构怎么协同？ 4. 底层机制是什么——多模式激活、JIT微文件协议、子 Agent 分发？ 5. 什么场景适合——何时该用、何时不该用？ 6. 从源码中能学到什么——可复用的设计经验？
一、BMAD 一句话：让 AI 当协作者
几乎所有用 AI 做完整项目的开发者都遇到过：AI 一会儿像产品经理，一会儿像架构师，一会儿像开发者，角色切换没有边界，输出风格和深度不一致。同时，规格驱动只覆盖了"想清楚再动手"这一段，但完整项目还需要市场调研、UX 设计、代码审查、迭代管理等环节。
BMAD 针对这两个痛点给出了解法：用命名 Agent 定义角色人格，用分阶段 Workflow 定义流程覆盖。
"Traditional AI tools do the thinking for you, producing average results. BMad agents and facilitated workflows act as expert collaborators who guide you through a structured process to bring out your best thinking in partnership with the AI."
可以这样理解 BMAD 的定位：它是一个"敏捷教练团队"，每个教练有自己的专长，陪你走完从市场调研到代码交付的全程。
术语解释：制品(Artifact)每个制品是一个独立的 Markdown 文件，记录项目的某个维度（PRD、架构、故事等）。制品由 AI 自动生成，人和 AI 都可以读取和修改。
理解了这一点，来看 BMAD 四阶段生命周期的运转方式：
每个阶段包含若干 Workflow，由对应 Agent 的菜单入口触发。
二、快速上手：四个阶段怎么用
BMAD 把开发过程分成四个阶段——从"想清楚做什么"到"做出来交付"，每一步都有专门的角色负责：
四个阶段之间有一条因果链：没搞清市场和用户需求，就写不出正确的 PRD；没有正确的 PRD，就做不出正确的架构设计；没有正确的架构，AI 实现时就会产生不一致的代码。
重要提示：四个阶段可以独立进入，不必从头走完。如果你已经有了产品文档，可以直接从 Plan 阶段开始。
2.1 三种运行模式：AI 陪你商量还是先跑一轮
每个 Workflow 支持三种模式，区别是"人和 AI 谁控制得多"：
这是"交互控制权"的分配——不是让 AI 自动判断"用户想清楚了没有"，而是让用户自己声明。
2.2 触发命令速查：记住这些就能启动
BMAD 有 6 个 Agent 和 34+ 个 Workflow，没人能记住所有名字。实际使用中，你只需要知道对应的 Skill 名称。
入口：通过 Skill 名称直接触发
BMAD 安装后，每个 Agent 和 Workflow 都会注册为一个独立的 Skill。在 Claude Code 中输入 / 后搜索 bmad 即可看到所有可用命令：
/bmad-analyst → Mary（分析师）的菜单入口/bmad-pm → John（产品经理）的菜单入口/bmad-ux-designer → Sally（UX 设计师）的菜单入口/bmad-architect → Winston（架构师）的菜单入口/bmad-developer → Amelia（开发者）的菜单入口/bmad-debugger → Dexter（调试专家）的菜单入口/bmad-help → 导航助手（"我现在到哪一步了？"）常用 Workflow 直接触发（跳过 Agent 菜单）
如果你知道要做什么，可以直接触发对应的 Workflow skill，无需经过 Agent 菜单：
/bmad-brainstorming → 头脑风暴（Analysis）/bmad-perform-research → 市场/领域/技术调研（Analysis）/bmad-create-prd → 创建 PRD（Plan）/bmad-create-epics → 创建 Epic 和用户故事（Plan）/bmad-ux-design → 创建 UX 设计（Plan）/bmad-architecture → 架构设计（Solutioning）/bmad-readiness-check → 实现就绪检查（Solutioning）/bmad-develop-story → 开发用户故事（Implementation）/bmad-code-review → 对抗式代码审查（Implementation）/bmad-sprint-planning → 冲刺规划（Implementation）/bmad-checkpoint → 检查点（Implementation）/bmad-system-debug → 系统调试（Implementation）初学者可以从 Agent 菜单入口开始探索（/bmad-analyst 看看有什么功能），熟练后直接触发 Workflow（/bmad-create-prd）更高效。
三、从源码看 BMAD 文件结构
BMAD 的 Skill 不是一堆独立的 Markdown 文件，而是一套有层次的组织体系。先看懂宏观结构，后面讲具体机制就不容易迷路。
3.1 Skill 系统的三层体系
BMAD 的 Skill 文件以 ~/.claude/skills/bmad-*/ 目录形式存在，但它们不是孤立的——整个系统由三层 Skill 体系组成：
三层的设计意图：
• Agent 层是"导航"——用户从这里进入，看到自己有哪些选择 • Workflow 层是"执行"——每个 Skill 是一个完整的、可独立运行的流程 • 子 Agent 层是"协作"——Workflow 在执行时可以分发任务给定义好的子 Agent
三层全貌清晰了。接下来拆解单个 Workflow 内部的文件组织。
3.2 单个 Workflow 的目录结构
以 bmad-create-prd 为例：
bmad-create-prd/ SKILL.md ← 主入口，定义概述和激活流程 customize.toml ← 默认配置（Agent 人格、菜单选项等） steps-c/ ← 步骤文件序列（按需加载） step-01-init.md step-02-discovery.md ... step-12-complete.md templates/ prd-template.md ← 制品模板 data/ domain-complexity.csv project-types.csv agents/ ← 子 Agent 定义 bmad-manifest.json ← 元注册（阶段位置、依赖关系）3.3 一个 Workflow 由什么组成
3.2 节的目录树看起来文件很多。但如果按"谁在修改、什么时候用到"重新归类，其实只有四种角色：
流程控制：AI 怎么走的路线图
一个 Workflow 的执行分两步——先加载 SKILL.md（入口），然后按顺序加载 steps-c/ 中的步骤文件。SKILL.md 告诉 AI"你是谁、做什么事、用什么模式"，steps-c/ 告诉 AI"第一步做什么、第二步做什么"。
AI 每次只加载一个步骤文件（详见 3.4 节 JIT 机制）。12 步的 PRD 流程如果写成单文件会超过 600 行，微文件让 AI "只看眼前这一步"，不会被后面的内容干扰。
制品：AI 产出什么
templates/ 放的是"空模板"——PRD 模板、架构设计模板、用户故事模板。AI 在执行流程时，根据步骤引导往模板里填内容，最终生成项目文档。制品不是写死的——AI 在流程中自动生成，人和 AI 都可以后续修改。
数据：AI 读什么做判断
customize.toml 是"人格配置"——Agent 叫什么名字、说话风格、有哪些原则。data/ 是"决策数据"——项目类型分类表、领域复杂度评估表。AI 在流程中遇到分支选择时（比如"这是个简单项目还是复杂项目"），会读取这些 CSV 来做判断。
customize.toml 还有更深的用途——用户可以通过两层覆盖文件修改它，实现"团队统一风格"或"个人偏好"的定制化。
导航：这个 Workflow 在整个开发流程中在哪
bmad-manifest.json 告诉系统"我属于 Analysis 阶段，排在 brainstorming 之后、create-prd 之前"。这让 bmad-help 能回答"你现在到哪一步了、缺什么、下一步该做什么"。
四种角色的划分理清了"谁在修改、什么时候用到"的问题。接下来看 3.4 节的 JIT 加载机制——它正是建立在"步骤文件独立"这个设计之上的。
3.4 微文件 JIT 加载：让 AI 只看眼前这一步
JIT（Just-In-Time，即时加载）：源自编译器的概念——只在需要时才加载代码，而不是一次性把全部文件读入内存。BMAD 把它用到了 AI 上下文管理上。
BMAD 把长流程的步骤拆成独立文件。AI 只读取当前步骤文件，不一次加载全部——这对于 12 步的 PRD workflow 尤其重要。
它是怎么做到的？三层纯指令式机制
BMAD 没有依赖任何代码层面的拦截或文件系统钩子，而是通过三层指令配合来实现 JIT：
第一层示例：SKILL.md 只引第一步
## Execution Flow1. Load and execute: steps-c/step-01-init.md2. After step 1 completes, the step file will tell you what to load next3. NEVER load multiple steps at once — follow the chain one at a timeSKILL.md 不列出 step-02 到 step-12 的路径。AI 看不到后续步骤的文件名，自然就不会去加载。
第二层示例：步骤文件的链式引导
每个 step-XX-xxx.md 的末尾有一段明确的下一步指令：
---## Next StepYou have completed step 01. Now load and execute: steps-c/step-02-discovery.mdDo NOT load any other steps yet. Do NOT skip ahead.这是链式推进——步骤 A 的末尾告诉你去读步骤 B，步骤 B 的末尾告诉你去读步骤 C。AI 没有机会"提前看到"步骤 D。
第三层：兜底约束
这就是 5.4 节"NO EXCEPTIONS"规则的来源——它针对 AI 可能出现的两种倾向：
• 主动预读：AI 读完 step-01 后，可能会想"让我看看 step-02 到 step-12 都有什么"，提前把全部文件读进来 • 跳跃执行：AI 看到 steps-c/ 目录下有 12 个文件，可能会想"我可以并行处理"或"这一步太简单，直接跳到 step-05"
5.5 节会详细分析为什么这些约束是必要的。
总结：纯指令式 JIT 的优势与局限
这种设计把"上下文管理"这个本来需要框架支持的能力，通过精心设计的指令链降维到了纯文本层面——用协议代替框架。
3.5 Manifest 元注册：给 Workflow 贴位置标签
每个 Workflow 有一个 bmad-manifest.json，定义了它在生命周期中的位置：
{ "capabilities": [{ "phase-name": "1-analysis", "after": ["brainstorming", "perform-research"], "before": ["create-prd"], "is-required":true, "supports-headless":true }]}这让 bmad-help skill 能告诉用户"你现在处于什么阶段、缺少什么制品、下一步该做什么"。
四、四阶段生命周期：从理解用户到交付代码
上一节看了 BMAD 的结构——三层 Skill、七种文件、四种角色。但这些都是"零件"，真正让它们转起来的，是四个阶段的流转顺序。
4.1 为什么是这四个阶段
BMAD 的阶段划分基于一条因果链：
不理解市场和用户 → 写不出正确的 PRD → 做不出正确的架构 → 实现出不一致的代码
每一步都是下一步的前提。AI 写代码出问题的根因，往往不在代码本身，而在前面的步骤跳过了。
这也是为什么 BMAD 设计了六个角色——分析师、PM、UX、架构师、开发者、调试专家——每个角色只负责自己擅长的领域。不同专业领域需要不同的人格，才能产出高质量的输出。（六个 Agent 的完整定义见 5.1 节）
BMAD 是一个"教练团队"，每个教练有自己的专长，陪你走完全程。
4.2 每个阶段的亮点设计
阶段一：Analysis——先理解，再动手
Mary 的人格设计很有意思——她不是冷冰冰的"数据收集器"，而是有"寻宝者的模式发现热情 + 麦肯锡备忘录的结构化输出"。这意味着她在调研时会主动发现模式、提出洞察，而不是机械地罗列信息。
这个阶段有一个独特设计叫 capture-don't-interrupt：当用户在创意流中分享信息时，AI 静默捕获而非引导纠正。保护创意流不被打断——交互的流畅性比流程的规范性更重要。
阶段二：Plan——把分析变成可执行的东西
John（PM）负责把 Mary 的调研变成 PRD，Sally（UX）负责把 PRD 变成具体的设计。这个阶段的产出是 Epic 和用户故事——它们是后续开发和审查的依据。
一句话串一下前两个阶段的逻辑：Analysis 解决"做什么"，Plan 解决"具体做成什么样"。后两个阶段聚焦"怎么实现"。
阶段三：Solutioning——技术架构师上场
Winston（架构师）拿到 PRD 后，负责设计技术方案和做实现就绪检查。这个阶段容易被跳过——很多开发者拿到 PRD 直接就开始写了。但 BMAD 认为，没有经过架构设计的需求，AI 实现时很容易产生不一致的代码风格和技术选型。
阶段四：Implementation——写代码 + 互相挑刺
Amelia（开发者）负责把技术方案变成代码。这个阶段最值得关注的是它的代码审查设计——
4.3 对抗式代码审查：三个审查者互相刁难
code-review 是 BMAD 最有意思的设计。它不是让一个 AI 审查代码，而是启动三个审查角色并行工作，每个角色有不同的信息权限：
Blind Hunter（盲眼猎人）——只给代码 diff，不给任何项目背景。没有上下文意味着没有借口——它只能从代码本身发现问题，不会被"这是为了满足 X 规格"的理由说服。
Edge Case Hunter（边界猎手）——给 diff 加上整个项目代码库。专门找"单看代码没问题，但放到项目中会出问题"的缺陷：命名冲突、API 签名不兼容、资源泄漏等。
Acceptance Auditor（验收审计员）——给 diff 加上规格文件。它只关心"做对了没有"——覆盖了需求但未实现、实现了需求但行为不一致、添加了规格之外的功能等问题。
关键设计：信息权限的不对称是有意为之的。不同的信息视角能发现不同类型的缺陷。最少信息的审查者提供最纯粹的代码视角，最完整上下文的审查者验证功能完整性。
三个角色并行启动，结果合并——审查覆盖"代码本身"、"项目集成"和"规格合规"三个维度。
五、底层机制：三层行为控制架构
BMAD 用三层架构实现行为控制——Agent 层定义角色人格，Workflow 层定义流程步骤，子 Agent 分发层定义运行时协作。
5.1 Agent 与 Workflow 的双层架构
BMAD 双层架构
Agent 层：6 个命名 Agent，每个有完整的 identity（角色身份）、communication_style（沟通风格）、principles（行为原则）定义。Agent 是 Workflow 的入口和导航层——用户通过调用 Agent 进入特定角色，Agent 展示菜单，菜单选项映射到具体的 Workflow skill。
6 个 Agent 的完整角色定义：
Workflow 层：34+ 个 Workflow，每个有 SKILL.md、steps/、templates/、customize.toml 等文件。每个 Workflow 绑定到一个 Agent 角色，继承其人格。
子 Agent 分发层：每个 Workflow 在执行时可以分发任务给定义在 agents/ 目录下的子 Agent。子 Agent 有自己的身份定义、权限约束和审查维度——它们不是主 Agent 的简单分身，而是有独立职责的审查者。
5.2 三层定制化引擎：从基础配置到个人偏好
每个 skill 都有一个 customize.toml 作为默认配置，用户可以通过两层覆盖文件修改行为：
Layer 1: Base（默认配置） → {skill-root}/customize.tomlLayer 2: Team（团队覆盖） → {project-root}/_bmad/custom/{skill-name}.tomlLayer 3: User（个人覆盖） → {project-root}/_bmad/custom/{skill-name}.user.toml合并规则: - 标量值: 上层覆盖下层 - 表格: 深度合并（递归合并嵌套字段） - 数组表格(按 code/id 匹配): 替换匹配项 + 追加新项 - 其他数组: 追加（不替换）5.3 多模式激活：三种模式决定跳过哪些阶段
三种运行模式（guided/yolo/autonomous）的交互体验见 2.1 节。这里补充一个容易被忽视的细节——
三种模式最大的影响不在"快慢"，而在阶段路由——它们决定跳过哪些阶段：
• guided 模式：完整阶段链，每个检查点 HALT（暂停）等待用户输入 • yolo 模式：跳过 Guided Elicitation，直接出初稿后修正 • autonomous 模式：零交互全自动，跳过问候和所有检查点
这是"交互控制权"的分配——autonomous 把控制权完全交给 AI，yolo 让 AI 先跑一轮再交还控制权，guided 则是人和 AI 共享控制权。
5.4 微文件执行协议：为什么需要 "NO EXCEPTIONS"
3.4 节介绍了 JIT 的三层实现机制，其中第三层是兜底约束。这里分析为什么纯指令式 JIT 需要这些强硬措辞。
BMAD 用 "NEVER 同时加载多个步骤文件"、"ALWAYS 先完整读取步骤文件再执行"、"NEVER 跳过步骤或优化顺序" 这样的规则来约束执行顺序。
这些规则针对三个 AI 行为倾向：
• 上下文贪婪：AI 倾向于尽可能多加载信息，导致后续步骤指令泄漏到当前步骤执行中 • 预判式执行：AI 只读一半就开始做，执行到一半发现后面有重要规则没读到 • 顺序弹性化：AI 倾向于"优化执行顺序"，破坏了步骤的隔离性
5.5 Workflow 运行机制：从激活到终态
一个完整的 Workflow 从用户选择菜单选项开始，经过 Agent 加载、Workflow 激活、步骤循环，最终生成制品并返回菜单。
JIT 加载体现在"Workflow 激活"这一步——只加载 step-01，后续步骤由前一步的末尾指令链式引导。终态声明确保步骤知道什么时候该结束。
5.6 子 Agent 分发机制：为什么需要独立定义
BMAD 不是"把子任务交给同一个 AI 实例用不同人格去执行"——它是在 Workflow 中显式定义了独立的子 Agent，每个子 Agent 有自己的人格文件、信息权限和审查维度。
子 Agent 的独立性体现在三个层面：
信息权限隔离：每个子 Agent 只能看到自己需要的上下文——这是有意为之的信息不对称。（code-review 的三个角色就是典型，详见 4.3 节。）不同的信息视角能发现不同类型的缺陷。
人格独立性：子 Agent 不是主 Agent 的"分身"，它们有自己独立的 identity 和 principles 定义。同一个 code-review workflow，在不同的项目配置下可以有不同的子 Agent 人格（更严格或更宽容）。
可组合性：子 Agent 是 Workflow 的可组合组件。不同的 Workflow 可以引用相同的子 Agent 定义，也可以为特定场景定制新的子 Agent——比如某个项目的 code-review 可能需要增加一个"性能审查员"角色。
六、适用场景：什么时候该用 BMAD
适合的场景
• 中等以上规模的项目：需要完整的角色分工，从市场调研到代码交付 • 团队协作开发：团队共享定制配置（team-level customize.toml），统一 Agent 行为风格 • 需要多专业领域协作的场景：产品分析、架构设计、UX 设计、代码实现各有不同人格要求 • 需要对抗性审查的场景：code-review 的三层并行审查设计
不适合的场景
• 简单的个人项目或 bugfix：34+ workflow、6 个 Agent 的流程覆盖反而显得过度 • 快速原型验证：需要快速试错，安装 Node.js + Python + uv 的开销太大 • 不需要角色分工的场景：如果只是"写代码+归档规格"，轻量级的需求管理工具更合适
BMAD 的代价：需要 Node.js 20+、Python 3.10+、uv 包管理器；34+ workflows 的学习曲线陡峭；三层配置合并需要理解 TOML（一种简洁的配置文件格式，类似 ini 但支持嵌套结构）格式。
七、从 BMAD 学到什么
角色设计
Agent 人格层解决输出风格不一致的问题。6 个命名 Agent 各有完整的 identity、communication_style、principles 定义。Mary 用"寻宝者的热情"做市场分析，Amelia 用"极简精确"做代码实现——不同专业领域需要不同的人格才能产出高质量的输出。
当流程涉及不同专业领域时，用角色人格约束输出风格比"通用 AI"更有效。
流程控制
微文件 JIT 加载控制长流程的 token 消耗（实现机制见 3.4 节）。12 步的 PRD workflow 如果写成单文件会超过 600 行，微文件让 AI 在执行长流程时保持专注当前步骤。用"协议代替框架"的思路——通过入口控制 + 链式引导 + 兜底约束三层文本指令，就能在不依赖任何代码拦截的情况下实现 JIT 加载。
Manifest 导航系统提升复杂框架的可发现性。每个 Workflow 通过 manifest 声明其阶段位置、前置后置关系、必要性。这让 bmad-help skill 能构建完整的导航指引——对于 34+ workflow 的框架，导航几乎是必须的。框架规模增长到 10+ 模块时，导航系统从"可有可无"变成"基础设施"。
多模式激活适配不同使用场景。autonomous/yolo/guided 三种模式改变阶段路由和检查点行为，让用户根据需求清晰度自行选择交互密度。让用户选择交互模式比让 AI 自动判断更可靠——AI 很难准确评估用户的"想清楚程度"。
质量保障
对抗性审查的多视角交叉验证。Blind Hunter、Edge Case Hunter、Acceptance Auditor 三个审查角色有不同的信息权限——最少信息的审查者提供最纯粹的代码视角，最完整上下文的审查者验证功能完整性。好代码需要被"刁难"，最高效的刁难方式是让不同视角的审查者互相质疑，而非同一审查者承担所有角色。
capture-don't-interrupt 保护用户创意流（详见 4.2 节）。交互的流畅性不是锦上添花，而是高质量协作的前提。保护创意流比"流程的规范性"更重要。
定制化
三层配置合并（base → team → user）。每个 skill 的 Agent 人格、菜单选项、持久事实都可在运行时被覆盖。标量值上层覆盖下层，表格深度合并，数组追加。区分"团队共享偏好"和"个人偏好"的分层覆盖机制，让定制化既有灵活性又不会丢失基础配置。
总结
BMAD 是一套完整的 AI 辅助敏捷开发方法论，不是简单的文档模板或角色定义。6 个命名 Agent、34+ Workflow、四阶段生命周期和三层配置引擎，把模糊的开发需求转化为结构化的协作过程。
本文从源码层面拆解了 BMAD 的架构和机制——多模式激活、微文件协议、子 Agent 分发、人格持久化等底层设计。学会了使用 BMAD，更重要的是理解它为什么这样设计：用协议代替框架，用信息不对称代替统一审查，用角色人格代替通用 AI。
