用 BMAD Method 把编码智能体变成规范驱动开发团队：安装、规划轨道与 Quick Dev 实操

在项目根目录打开终端，运行官方安装器：

# 项目根目录执行
npx bmad-method install
# 预发布通道（可选）
npx bmad-method@next install
# 拿到过期 beta 时，显式锁定版本
npx [email protected] install
# CI / 非交互安装（跳过所有提问）
npx bmad-method install --directory /path/to/project --modules bmm --tools claude-code --yes

安装器是交互式的：按提示选择项目目录、要装的模块（选 BMad Method，这是核心模块）和你在用的 AI IDE。装完项目里多出两个目录：_bmad/ 放智能体定义、工作流、任务与配置；_bmad-output/ 目前是空的，它是后续所有规划工件的落盘处。

your-project/
├── _bmad/
│   ├── bmm/
│   │   ├── agents/      # PM、架构、开发、QA 等角色定义
│   │   ├── workflows/   # 全部工作流指令
│   │   └── config.yaml  # 模块配置
│   └── core/
│       └── tasks/
└── _bmad-output/        # 规划工件落盘处

不用背工作流清单。在项目文件夹里打开你的 AI IDE，直接运行：

/bmad-help

bmad-help 会检查项目当前状态、列出已装模块下可用的智能体与工作流、并推荐下一步该做什么。你也可以用自然语言问它：「我有一个 SaaS 想法，该从哪里开始」「我刚做完架构，下一步是什么」「我卡在工作流 X 了怎么办」。每个工作流跑完它还会自动提示下一步——这套引导就是官方文档说的「不必背工作流，问就行」。

调用方式有两种：工作流技能直接点名（比如 /bmad-prd），或点名角色智能体做通用对话（比如 PM 角色的 bmad-agent-pm）。新手记住一条：想推进流程就用 bmad-* 技能名。

BMad 不是一套固定流程，官方按「实现前需要多少上下文」分了三条轨道，按项目复杂度选：

# 三条规划轨道（官方口径：故事数为指引，不是定义）
直接           -> 清晰的修复、功能、issue（tech-spec 就够）
产品规划       -> 产品、平台、复杂功能（PRD + 可选 UX）
完整方案设计   -> 跨系统、高风险项目（PRD + 架构 + epics/stories）

对应的四阶段是：分析（头脑风暴、研究、产品简报，可选）、规划（PRD 或技术规范）、方案设计（按需做架构）、实现（按 epic 和 story 逐批施工）。关键认知：这三条轨道不是三套独立流程，它们最终都汇入同一条实现路径——轨道只决定实现之前铺垫多少上下文。选轨的判断动作放在动手前做：先估计这个需求会拆成多少个 story、要不要跨系统改动、验收标准能不能一句话说清，三个答案自然把你带到正确的轨道上。小修小补别硬上完整轨道，过度规划本身就是浪费。

给小而清晰的任务用 Quick Dev 轨道，流程在 Solo Dev 角色手里五步走完。在 IDE 里直接说「用 BMAD Solo Dev 工作流，给任务管理器做一个简单 REST API」，或点名技能调起。五步分别是：

# Quick Dev 五步（对 Solo Dev 角色把话说清楚即可）
1. 意图压缩：说清要什么、解决什么问题、「完成」长什么样
2. 智能路由：简单任务直接实现，复杂含糊的先转规划
3. 扩展自治实现：边界内连续施工，少打断你
4. 人工检查点：需要你判断的决策点、完工点停下来
5. 代码审查：角色切到审查模式，对照原始意图挑偏差

意图压缩是质量分水岭：它会把「做个任务管理 API」逼问你到「四个端点（建任务/列任务/完成/删除）、无鉴权无数据库、内存存储、完成标准是四端点全通且带基本错误处理」。你觉得啰嗦的那几问，正是后面代码审查能自动对照的验收基线。

产品级、平台级的活走 Full Method：按阶段调规划技能，产出全部入库。

# 规划技能按阶段调用，产出全部入库
/bmad-brief   -> 产品简报（阶段 1 分析）
/bmad-prd     -> 需求文档 PRD（阶段 2 规划）
/bmad-ux      -> UX 骨架（阶段 2 可选）
/bmad-spec    -> 技术规范（阶段 2/3）
# 之后按 epic -> story 分批进入实现（阶段 4）

这套资产的价值在于复利：PRD 与架构文档一旦入库，后续每个开发会话都带着它们开工，新功能申请、返工争议、新人接手都有据可查。实现收尾前，review agent 会对照计划与你的标准做审查——注意最终批准合并的永远是你，这是官方设计里固定的最后一道闸门。

三组关系一次说清：AGENTS.md 是给智能体的静态说明（本站教程 366 有专篇），BMad 是带流程的动态规划引擎，两者互补——AGENTS.md 告诉智能体「在这个仓库怎么做事」，BMad 负责「先想清楚再做事」。Claude Skills（教程 425）是能力封装，BMad v6 的 bmad-* 技能本身就是以 Skills 形态挂进 IDE 的。多角色同台讨论复杂决策时，官方的 party-mode 可以把多个智能体拉进一个对话——但日常任务别用，多角色对话又贵又慢。

适用边界同样清楚：清晰的小修复直接修，别过规划轨道；跨系统、多方协作、合规压力大的项目才是它的主场。判断标准很简单——如果这个需求「做错了要返工一周」，规范先行就是刚需；如果「做错了改两行」，直接让编码智能体上。