企业官网建设流程全解析

BMAD-METHOD 默认 BMM 智能体完全指南：Skill ID、菜单触发器与工作流调用机制

【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD

本文以 BMAD-METHOD 仓库的 docs/ko-kr/reference/agents.md 为核心，系统梳理 BMad Method（BMM，Agile 套件）随安装提供的五个默认智能体——分析家 Mary、产品经理 John、架构师 Winston、开发者 Amelia、UX 设计师 Sally 的 Skill ID、菜单触发器与主要 workflow。读完本文，你将掌握每个智能体的身份设定、底层激活流程、全部触发码与对应技能的关系，并能通过customize.toml三层覆盖机制自定义智能体行为，在实际项目中直接上手调用。

一、背景：BMad Method 中的"智能体即技能"

BMad Method（BMM）将软件交付过程划分为四个阶段：可选探索（分析）→ 规划 → 解决方案设计 → 实现，各阶段以"只补充当前工作所需的最小上下文"为原则推进，详见 工作流地图。

在 BMM 中，每个默认智能体并不是独立运行的程序，而是由安装程序（installer）生成的一个"技能（skill）"。因此调用智能体的方式，就是使用它的 Skill ID 直接调用对应技能。例如需要开发者 Amelia 时，调用bmad-agent-dev技能即可。

仓库中这五个智能体的技能实体位于skills/目录，每个目录都包含一份SKILL.md（定义人设与激活流程）和一份customize.toml（定义角色、原则、菜单等可配置内容）：

二、五个默认智能体速查表

原文档给出了核心速查表，五个智能体的 Skill ID、触发器与主要 workflow 对应关系如下：

注意：QA 测试生成由bmad-qa-generate-e2e-tests这个 workflow 技能负责，通过开发者智能体运行；完整的 TEA（测试架构师）能力位于独立模块中，详见后文第五节。

三、逐个解读五个默认智能体

3.1 Analyst (Mary) —— 业务分析家

Mary 的技能描述为"业务分析家，负责市场调研、竞争分析与需求提炼"，擅长把模糊需求转化为可执行的规格，并坚持基于证据的分析。她的role定位是：在 BMAD-METHOD 的分析阶段，帮助用户在投入项目之前进行构思、调研与分析。

从 customize.toml 可以看出 Mary 的完整菜单配置：

可以看到，文档速查表中列出的BP、MR、DR、TR、CB、WB、PC是 Mary 的核心菜单；而从源码看，完整菜单还包含TS、CR、UV三个追加的调研入口，它们全部以prompt形式转发到bmad-deep-recon技能并预选调研类型。

Mary 的principles（价值准则）包括：每项发现都锚定可验证的证据、需求表述绝对精确、每个干系人的声音都被代表。

3.2 Product Manager (John) —— 产品经理

John 负责通过用户访谈、需求发现与干系人对齐来驱动 PRD 创建，把产品愿景转化为开发可以交付的小步验证增量。其role定位在 BMAD-METHOD 的规划阶段：把产品愿景转化为可执行的 PRD、Epics 与 Stories。

John 的菜单（customize.toml）：

John 的原则强调了"PRD 来自用户访谈而非模板填空""交付能验证假设的最小事物""用户价值优先，技术可行性是约束"。

3.3 Architect (Winston) —— 系统架构师

Winston 负责把产品需求与 UX 转化为能成功交付的技术架构，偏好"无聊的技术（boring technology）"、开发者生产力，并以权衡取舍（trade-offs）而非裁决（verdicts）作答。其role定位在 BMAD-METHOD 的解决方案设计阶段：把 PRD 与 UX 转化为让实现保持在正轨上的技术架构决策。

Winston 的菜单（customize.toml）非常精简：

Winston 的原则：抽象之前先遵循"三原则（Rule of Three）"、为了稳定性采用无聊的技术、开发者生产力本身就是架构。

3.4 Developer (Amelia) —— 高级软件工程师

Amelia 以测试先行纪律（red, green, refactor）执行已批准的 Stories，交付满足每一条验收标准的、经验证的代码。她的沟通风格被设定为"极度简洁，用文件路径和验收标准 ID 说话，每句话都可溯源"。其role定位在 BMAD-METHOD 的实现阶段。

Amelia 的菜单（customize.toml）：

值得一提的是 Amelia 的principles包含一条工程规范：禁止在源码中写入 Epic/Story 引用注释（如# Epic: X、# Story: PROJ-42），代码注释只解释"为什么"而非"是什么"，生成的代码必须是生产就绪、干净、无 AI 噪声的。这与仓库中bmad-retrospective、bmad-build等实现技能的工程质量取向一致。

3.5 UX Designer (Sally) —— UX 设计师

Sally 负责把用户需求与 PRD 转化为 UX 设计规格，进而指导架构与实现。她的role定位在 BMAD-METHOD 的规划阶段：把用户需求与 PRD 转化为能指导架构与实现的 UX 设计规格。

Sally 只有一个菜单项（customize.toml）：

Sally 的原则：每个决策都服务于真实的用户需求、从简单开始并随反馈演进、数据知情但始终保持创造性。

四、触发器（Trigger）机制：输入短码即可启动结构化 Workflow

原文档明确指出触发器的本质：

智能体菜单触发器会加载结构化 workflow 文件。输入触发码后，智能体启动对应 workflow，并在每个步骤请求输入。

也就是说，PRD、CA、BD这类触发码并不是简单的宏命令，而是把对应 workflow 技能（如bmad-prd、bmad-architecture、bmad-build）接入当前智能体会话的入口。例如：

• 输入PRD→ 进入 PRD 创建/更新/验证流程，由bmad-prd技能分步提问细化需求；
• 输入CA→ 启动架构创建流程，产出ARCHITECTURE-SPINE.md核心文档（见 工作流地图 阶段 3）；
• 输入BD→ 启动 Build 流程，由 Amelia 按测试先行纪律实现一个 Story。

菜单项的两种底层动作

从各customize.toml的注释可以看到，菜单项[[agent.menu]]的每个条目恰好包含skill或prompt二者之一：

• skill型：按名称直接调用已注册技能，例如BP→skill = "bmad-brainstorming"；
• prompt型：直接执行 prompt 文本，例如MR→ 用预设调研类型调用bmad-deep-recon并"跳过类型推断"。

菜单的合并与覆盖规则

customize.toml顶部注释明确了菜单合并规则：

• 标量（scalars）：覆盖方优先；
• 数组（persistent_facts、principles、activation_steps_*）：追加；
• 带code/id键的表数组：匹配项原位替换，新条目追加。

这意味着团队或个人覆盖文件可以按触发码精准增删改某个菜单项，而不影响其他人设。

五、智能体激活流程：从 SKILL.md 到实际对话

每个默认智能体的SKILL.md都定义了标准的八步激活流程（以 bmad-agent-analyst/SKILL.md 为例，其余四个智能体结构一致）：

1. 解析 Agent 块：运行resolve_customization.py --skill {skill-root} --project-root {project-root} --key agent；若脚本失败，则按 base → team → user 顺序手动读取三个覆盖文件合并；
2. 执行 Prepend 步骤：按activation_steps_prepend依次执行（可用于预加载、合规检查）；
3. 采纳人设：以 Overview 中的身份为基底，叠加role、identity、communication_style、principles的自定义层；
4. 加载持久事实：persistent_facts中的条目视为整个会话的基础上下文；file:前缀条目按路径/glob 加载文件内容作为事实；
5. 加载配置：运行resolve_config.py --project-root {project-root} --key modules.bmm.planning_artifacts --key modules.bmm.project_knowledge，分别用于定位输出/扫描规划产物与扫描项目知识；
6. 问候用户：以{agent.icon}前缀开头（如 Mary 的📊、John 的📋、Winston 的🏗️、Amelia 的💻、Sally 的🎨），并提示可随时调用bmad-help；
7. 执行 Append 步骤：按activation_steps_append依次执行；
8. 分发或呈现菜单：若用户首条消息已明确映射到某个菜单项（如"嘿 Mary，我们来头脑风暴"），跳过菜单直接分发；否则将{agent.menu}渲染为编号表格（Code/Description/Action），接受数字、菜单码或模糊描述匹配。

三层覆盖（base → team → user）与底层合并实现

激活流程第 1 步提及的合并规则，其实现位于 skills/bmad/scripts/resolve_customization.py。该脚本从项目根目录的_bmad/custom/下读取覆盖文件，合并顺序为：

1. {skill-root}/customize.toml—— 默认值（base）；
2. {project-root}/_bmad/custom/{skill-name}.toml—— 团队覆盖（team）；
3. {project-root}/_bmad/custom/{skill-name}.user.toml—— 个人覆盖（user）。

缺失的文件直接跳过；合并规则为：标量覆盖、表深合并、带code/id键的表数组匹配替换并追加新条目、其余数组追加。

从源码还可确认两个实现细节：

• Python 版本要求：脚本头部requires-python = ">=3.11"，因为依赖标准库tomllib；低于 3.11 会报错退出（exit code 3）。
• 项目根定位：find_project_root会向上查找最近的包含_bmad/的祖先目录，优先于.git——这是为了避免子模块/嵌套仓库中.git干扰根目录判定，确保_bmad/custom/归正确的项目所有。

六、QA 测试生成与 TEA 的边界

原文档特别提醒：QA 测试生成由bmad-qa-generate-e2e-testsworkflow 技能处理，可通过开发者智能体运行（Amelia 菜单中的QA触发码，底层即调用该技能）；而完整的 TEA（测试架构师）能力位于独立模块，不在默认五智能体之内。仓库中 skills/bmad-qa-generate-e2e-tests/SKILL.md 即为该 workflow 技能的实现载体。

七、关于 Paige：项目上下文能力不受影响

原文档中的说明框指出：技术写作者Paige 正在休整，未来将以更强的能力回归。在此期间，项目上下文（Project Context）功能依然可用：

• 通过分析家 Mary 的PC（Project Context）触发器调用；
• 或直接调用bmad-project-context技能（仓库中 skills/bmad-project-context/SKILL.md 即其载体）。

八、实战调用建议

综合原文档与仓库实现，在实际项目中调用默认智能体的推荐路径是：

1. 按 Skill ID 直接调用：如需要产品经理，直接调用bmad-agent-pm；需要开发者，调用bmad-agent-dev。这是最确定、最可复现的方式。
2. 进入会话后使用触发码：激活智能体后，直接输入PRD、CA、BD等短码，即可启动对应结构化 workflow，按流程提示逐步提供信息。
3. 自然语言直达：首条消息直接表达意图（如"嘿 Winston，帮我把这个架构定下来"），智能体将跳过菜单直接分发到对应 workflow。
4. 不确定时使用bmad-help：在任何智能体会话中均可调用bmad-help技能获取建议。

九、相关参考

• 工作流地图（워크플로 맵）：BMM 四阶段、全部 workflow 技能与产出物一览
• 技能参考（Commands）：技能调用方式说明
• 核心工具参考（Core Tools）：激活流程中涉及的解析脚本与工具
• 各智能体 customize.toml：人设与菜单的完整可配置项
• resolve_customization.py：三层覆盖合并的底层实现

以上速查表与源码路径可直接作为你团队内部接入 BMM 默认智能体的操作手册：先记住五个 Skill ID，再按场景选用触发码，最后通过customize.toml三层覆盖按团队规范定制菜单与人设。

【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD