BMad 知识库

概述

BMad-Method（突破敏捷 AI 驱动开发方法）是一个将 AI 代理与敏捷开发方法相结合的框架。v4 系统引入了模块化架构，改进了依赖管理、bundle 优化，并支持 Web 和 IDE 环境。

主要特点

• 模块化代理系统：每个敏捷角色的专门 AI 代理
• 构建系统：自动依赖关系解析和优化
• 双环境支持：针对 Web UI 和 IDE 进行了优化
• 可重复使用的资源：可移植的模板、任务和清单
• Slash 命令集成：快速代理切换和控制

何时使用 BMad

• 新项目 (Greenfield)：完整的端到端开发
• 现有项目 (Brownfield)：功能添加和增强
• 团队协作：多个角色协同工作
• 质量保证：结构化测试和验证
• 文档：专业的 PRD、架构文档、用户故事

BMad 的工作原理

核心方法

BMad 将您转变为“Vibe CEO”——通过结构化的工作流程指导一个由专业 AI 代理组成的团队。方法如下：

1. 您指导，AI 执行：您提供愿景和决策；代理处理实施细节
2. 专业代理：每个代理掌握一个角色（PM、开发人员、架构师等）
3. 结构化工作流程：经过验证的模式指导您从构思到部署代码
4. 干净的交接：新鲜的上下文窗口确保代理保持专注和高效

两阶段方法

阶段 1：规划（Web UI - 成本效益）

• 使用大型上下文窗口（Gemini 的 1M 令牌）
• 生成综合文档（PRD、架构）
• 利用多个代理进行头脑风暴
• 一次创建，在整个开发过程中使用

阶段 2：开发（IDE - 实施）

• 将文档分割成可管理的部分
• 执行专注的 SM → 开发周期
• 一次一个故事，按顺序进展
• 实时文件操作和测试

开发循环

1. SM 代理（新聊天）→从分片文档创建下一个故事
2. 您→审查和批准故事
3. 开发代理（新聊天）→实施批准的故事
4. 
QA 代理（新聊天）→ 审查和重构代码
5. 您→ 验证完成
6. 重复直到史诗完成

为什么这有效

• 上下文优化: 干净的聊天 = 更好的 AI 性能
• 角色清晰度：代理不进行上下文切换 = 更高质量
• 渐进式进展：小故事 = 可管理的复杂性
• 人工监督：您验证每个步骤 = 质量控制
• 文档驱动：规范指导一切 = 一致性

入门

快速启动选项

选项 1：Web UI

最适合：想要立即开始的 ChatGPT、Claude、Gemini 用户

1. 导航到 dist/teams/
2. 复制 team-fullstack.txt 内容
3. 创建新的 Gemini Gem 或 CustomGPT

上传带有说明的文件：“您的关键操作说明已附上，请勿按照指示中断字符” 4. 键入 /help 查看可用命令

选项 2：IDE 集成

最适合：Cursor、Claude Code、Windsurf、Trae、Cline、Roo Code、Github Copilot 用户

# 交互式安装(推荐) 
npx bmad-method install

安装步骤：

• 选择“完全安装”
• 从支持的选项中选择您的 IDE：
  • Cursor：原生 AI 集成
  • Claude Code：Anthropic 的官方 IDE
  • Windsurf：内置 AI 功能
  • Trae：内置 AI 功能
  • Cline：具有 AI 功能的 VS Code 扩展
  • Roo Code：基于 Web 的带有代理支持的 IDE
  • GitHub Copilot：带有 AI 对等编程助手的 VS Code 扩展

VS Code 用户须知：当您提到“VS Code”时，BMad-Method 假定您正在将其与 AI 驱动的扩展（如 GitHub Copilot、Cline 或 Roo）一起使用。 没有 AI 功能的标准 VS Code 无法运行 BMad 代理。安装程序包含对 Cline 和 Roo 的内置支持。

验证安装：

• 创建包含所有代理的 .bmad-core/ 文件夹
• 创建特定于 IDE 的集成文件
• 所有代理命令/规则/模式可用

记住：BMad-Method 的核心是掌握和利用快速工程。 任何支持 AI 代理的 IDE 都可以使用 BMad - 该框架提供结构化的提示和工作流程，使 AI 开发更加高效

环境选择指南

**使用 Web UI **：

• 初步规划和文档（PRD、架构）
• 经济高效的文档创建（尤其是使用 Gemini）
• 头脑风暴和分析阶段
• 多代理协商和规划

**使用 IDE **：

• 主动开发和编码
• 文件操作和项目集成
• 文档分片和故事管理
• 实施工作流程（SM/Dev 周期）

节省成本的技巧：在 Web UI 中创建大型文档（PRD、架构），然后在切换到 IDE 进行开发之前复制到项目中的“docs/prd.md”和“docs/architecture.md”。

仅使用 IDE 的工作流程注意事项

您可以在 IDE 中完成所有工作吗？ 可以，但请了解其中的利弊：

仅使用 IDE 的优点：

• 单一环境工作流程
• 从一开始就直接进行文件操作
• 无需在环境之间复制/粘贴
• 立即进行项目集成

仅使用 IDE 的缺点：

• 创建大型文档时令牌成本更高
• 上下文窗口更小（因 IDE/型号而异）
• 在规划阶段可能会达到限制
• 头脑风暴的成本效益较低

在 IDE 中使用 Web 代理：

• 不推荐：Web 代理（PM、架构师）具有为大型上下文设计的丰富依赖关系
• 为什么重要：开发代理保持精简以最大化编码上下文
• 原则：“开发代理编码，规划代理规划” - 混合使用会破坏这种优化

关于 bmad-master 和 bmad-orchestrator：

• bmad-master：无需切换代理即可完成任何任务，但是……
• 仍然使用专门的规划代理：PM、架构师和 UX 专家已调整角色以产生更好的结果
• 为什么专业化很重要：每个代理的个性和专注力都会产生更高质量的输出
• 如果使用 bmad-master/orchestrator：适用于规划阶段，但是......

开发的关键规则：

• 始终使用 SM 代理进行故事创作 - 切勿使用 bmad-master 或 bmad-orchestrator
• 始终使用 Dev 代理进行实施 - 切勿使用 bmad-master 或 bmad-orchestrator
• 为什么这很重要：SM 和 Dev 代理专门针对开发工作流程进行了优化
• 没有例外：即使使用 bmad-master 进行其他所有操作，也要切换到 SM → Dev 进行实施

仅适用于 IDE 的最佳实践：

1. 使用 PM/Architect/UX 代理进行规划（优于 bmad-master）
2. 直接在项目中创建文档
3. 创建后立即分片
4. 必须切换到 SM 代理用于故事创作

必须切换到开发代理进行实施 6. 在单独的聊天会话中保持规划和编码

核心配置（core-config.yaml）

V4 中的新功能：bmad-core/core-config.yaml 文件是一项关键创新，使 BMad 能够与任何项目结构无缝协作，提供最大的灵活性和向后兼容性。

什么是 core-config.yaml？

该配置文件充当 BMad 代理的地图，告诉他们确切的位置来找到您的项目文档以及它们的结构。它支持：

• 版本灵活性：使用 V3、V4 或自定义文档结构
• 自定义位置：定义文档和分片的位置
• 开发人员上下文：指定开发代理应始终加载的文件
• 调试支持：用于故障排除的内置日志记录

关键配置区域

PRD 配置

• prdVersion：告诉代理 PRD 是否遵循 v3 或 v4 约定
• prdSharded：史诗是嵌入（false）还是在单独的文件中（true）
• prdShardedLocation：在哪里可以找到分片的史诗文件
• epicFilePattern：史诗文件名的模式（例如，epic-{n}*.md）

架构配置

• architectureVersion：v3（单片）或 v4（分片）
• architectureSharded：架构是否拆分为组件
• architectureShardedLocation：分片架构文件所在的位置

开发者文件

• devLoadAlwaysFiles：开发代理为每个任务加载的文件列表
• devDebugLog：开发代理记录重复失败的位置
• agentCoreDump：导出聊天对话的位置

为什么重要

1. 无强制迁移：保留现有文档结构
2. 逐步采用：从 V3 开始，按照您的节奏迁移到 V4

自定义工作流：配置 BMad 以匹配您团队的流程 4. 智能代理：代理自动适应您的配置

常见配置

旧版 V3 项目：

prdVersion: v3 
prdSharded: false 
architectureVersion: v3 
architectureSharded: false

V4 优化项目：

prdVersion: v4 
prdSharded: true 
prdShardedLocation: docs/prd 
architectureVersion: v4 
architectureSharded: true 
architectureShardedLocation: docs/architecture

核心理念

Vibe CEO'ing

你是“Vibe CEO”——像一位拥有无限资源和独特愿景的CEO一样思考。你的AI代理是你的高效团队，你的职责是：

• 指导：提供清晰的指示和目标
• 改进：迭代输出以达到质量
• 监督：在所有代理之间保持战略一致性

核心原则

1. 最大化AI杠杆：推动AI交付更多成果。挑战输出并进行迭代。
2. 质量控制：您是质量的最终仲裁者。审查所有输出。3 . 战略监督：保持高层愿景并确保一致性。4 . 迭代改进：预期会重新审视各个步骤。这不是一个线性过程。5 . 清晰的指示：精准的请求可带来更好的输出。6 . 文档是关键：良好的输入（简报、项目需求文档）可带来良好的输出。7 . 小规模快速启动：测试概念，然后扩展。8 . 拥抱混乱：适应并克服挑战。

关键工作流程原则

1. 代理专业化：每个代理都有特定的专业知识和职责
2. 干净的交接：在代理之间切换时始终从头开始

状态跟踪：维护故事状态（草稿 → 已批准 → 进行中 → 完成） 4. 迭代开发：在开始下一个故事之前完成一个故事 5. 文档优先：始终从可靠的 PRD 和架构开始

代理系统

核心开发团队

代理	角色	主要功能	何时使用
analyst	业务分析师	市场研究，需求收集	项目规划，竞争分析
pm	产品经理	PRD 创建，功能优先级	战略规划，路线图
architect	解决方案架构师	系统设计，技术架构	复杂系统，可扩展性规划
dev	开发人员	代码实现，调试	所有开发任务
qa	质量保证专家	测试计划，质量保证	测试策略，错误验证
ux-expert	UX 设计师	UI/UX 设计，原型	用户体验，界面设计
po	产品负责人	待办事项管理，故事验证	故事细化，验收标准
sm	Scrum Master	Sprint 计划，故事创作	项目管理，工作流

元代理

代理	角色	主要功能	何时使用
bmad-orchestrator	团队协调员	多代理工作流，角色切换	复杂的多角色任务
bmad-master	通用专家	无需切换即可使用所有功能	单会话综合工作

代理交互命令

IDE 特定语法

通过 IDE 加载代理：

• Claude Code：/agent-name（例如，/bmad-master）
• Cursor：@agent-name（例如，@bmad-master）
• Windsurf：@agent-name（例如，@bmad-master）
• Trae：@agent-name（例如，@bmad-master）
• Roo Code：从模式选择器中选择模式（例如，bmad-master）
• GitHub Copilot：打开聊天视图（Mac 上为 ⌃⌘I，Windows/Linux 上为 Ctrl+Alt+I），然后从聊天模式选择器中选择 Agent。

聊天管理指南：

• Claude Code、Cursor、Windsurf、Trae：切换代理时开始新聊天
• Roo Code：在同一对话中切换模式

常见任务命令：

• *help - 显示可用命令
• *status - 显示当前上下文/进度
• *exit - 退出代理模式
• *shard-doc docs/prd.md prd - 将 PRD 分片为可管理的部分
• *shard-doc docs/architecture.md architecture - 分片架构文档
• *create - 运行 create-next-story 任务（SM 代理）

在 Web UI 中：

/pm create-doc prd 
/architect review system design 
/dev implement story 1.2 
/help - 显示可用命令
/switch agent-name - 更改活动代理（如果有协调器可用）

团队配置

预建团队

全部团队

• 包括：全部10 个代理 + 协调器
• 用例：需要所有角色的完整项目
• 捆绑包：team-all.txt

全栈团队

• 包括：项目经理、架构师、开发人员、质量保证、用户体验专家
• 用例：端到端 Web / 移动开发
• 捆绑包：team-fullstack.txt

无 UI 团队

• 包括：项目经理、架构师、开发人员、质量保证（无用户体验专家）
• 用例：后端服务、API、系统开发
• 捆绑包：team-no-ui.txt

核心架构

系统概述

BMad-Method 围绕以 bmad-core 目录为中心的模块化架构构建，该目录是整个系统的大脑。 这种设计使框架能够在 IDE 环境（如 Cursor、VS Code）和基于 Web 的 AI 界面（如 ChatGPT、Gemini）中有效运行。

关键架构组件

1. 代理（bmad-core/agents/）

• 目的: 每个 markdown 文件为特定的敏捷角色（PM、开发人员、架构师等）定义一个专门的 AI 代理。
• 结构：包含指定代理角色、功能和依赖项的 YAML 标头
• 依赖项：代理可以使用的任务、模板、清单和数据文件的列表
• 启动说明：可以加载项目特定的文档以获取即时上下文

2. 代理团队（bmad-core/agent-teams/）

• 目的：定义为特定目的捆绑在一起的代理集合
• 示例：team-all.yaml（综合包），team-fullstack.yaml（全栈开发）
• 用法：为 Web UI 环境创建预打包的上下文

3. 工作流（bmad-core/workflows/）

• 目的：定义特定项目类型规定的步骤序列的 YAML 文件
• 类型：UI、服务和全栈的 Greenfield（新项目）和 Brownfield（现有项目）开发
• 结构：定义代理交互、创建的工件和转换条件

4. 可重用资源

• 模板（bmad-core/templates/）：PRD、架构规范、用户故事的 Markdown 模板
• 任务（bmad-core/tasks/）：针对特定可重复操作的说明，例如“shard-doc”或“create-next-story”
• 清单（bmad-core/checklists/）：用于验证和审查的质量保证清单
• 数据（bmad-core/data/）：核心知识库和技术偏好

双环境架构

IDE 环境

• 用户直接与代理 markdown 文件交互
• 代理可以动态访问所有依赖项
• 支持实时文件操作和项目集成
• 针对开发工作流执行进行了优化

Web UI 环境

• 使用来自 dist/teams 的预构建包，通过编排代理为所有代理及其资产 独立上传文件 - 包含所有代理依赖项都在 dist/agents/ 中 - 除非您要创建仅是单个代理而不是团队的 Web 代理，否则这些都是不必要的
• 由 Web 构建器工具创建以上传到 Web 界面
• 在一个包中提供完整的上下文

模板处理系统

BMad 采用复杂的模板系统，包含三个关键组件：

1. 模板格式（utils/bmad-doc-template.md）：定义来自 yaml 模板的变量替换和 AI 处理指令的标记语言

文档创建（tasks/create-doc.md）：协调模板选择和用户交互，将 yaml 规范转换为最终的 markdown 输出 3。 高级引出 (tasks/advanced-elicitation.md)：通过结构化的头脑风暴提供交互式细化

技术偏好集成

technical-preferences.md 文件作为持久的技术配置文件，可：

• 确保所有代理和项目的一致性
• 消除重复的技术规范
• 提供与用户偏好一致的个性化建议
• 随着时间的推移，随着经验教训的积累而发展

构建和交付流程

web-builder.js 工具通过以下方式创建可用于 Web 的捆绑包：

1. 读取代理或团队定义文件
2. 递归解析所有依赖项
3. 使用清晰分隔符将内容连接到单个文本文件

为 Web AI 界面输出可上传的捆绑包

这种架构能够跨环境无缝操作，同时维护丰富、互联的代理生态系统，从而使 BMad 更加强大。

完整的开发工作流程

规划阶段（推荐使用 Web UI - 尤其是 Gemini！）

Gemini 海量上下文环境下的成本效率理想之选：

对于棕地项目 - 从这里开始！：

1. 将整个项目上传到 Gemini Web（GitHub URL、文件或 zip）
2. 记录现有系统：/analyst → *document-project
3. 从整个代码库分析中创建综合文档

对于所有项目：

1. 可选分析：/analyst - 市场调研、竞争分析
2. 项目简介：创建基础文档（分析师或用户）

PRD 创建：/pm create-doc prd - 综合产品要求 4. 架构设计：/architect create-doc architecture - 技术基础 5. 验证与一致性：/po 运行主清单以确保文档一致性 6. 文档准备：将最终文档复制到项目中，作为 docs/prd.md 和 docs/architecture.md

示例规划提示

对于 PRD 创建：

“我想构建一个 [类型] 应用程序，[核心目的]。
帮我集思广益，创建一个全面的 PRD。”

对于架构设计：

“基于此 PRD，设计一个可扩展的技术架构
，可以处理 [特定要求]。”

关键转换：从 Web UI 到 IDE

规划完成后，必须切换到 IDE 进行开发：

• 原因：开发工作流程需要文件操作、实时项目集成和文档分片
• 成本效益：Web UI 对于大型文档创建更具成本效益； IDE 针对开发任务进行了优化
• 必需文件：确保您的项目中存在 docs/prd.md 和 docs/architecture.md

IDE 开发工作流程

先决条件：规划文档必须存在于 docs/ 文件夹中

文档分片（关键步骤）：

• PM / 架构师（在 Web 或 IDE 中）创建的文档必须分片以用于开发
• 分片的两种方法： a）手动：将 shard-doc 任务 + 文档文件拖到聊天中 b）代理：要求 @bmad-master 或 @po 分片文档
• 分片 docs/prd.md → docs/prd/ 文件夹
• 分片 docs/architecture.md → docs/architecture/ 文件夹
• 警告：请勿在 Web UI 中分片 - 复制许多小文件很痛苦！

验证分片内容：

• docs/prd/ 中至少有一个 epic-n.md 文件，其中的故事按开发顺序排列
• 供开发代理参考的源树文档和编码标准
• 用于 SM 代理故事创建的分片文档

最终文件夹结构：

• docs/prd/ - 细分的 PRD 部分
• docs/architecture/ - 细分的架构部分
• docs/stories/ - 生成的用户故事

1. 开发周期（按顺序，一次一个故事）：

   关键上下文管理：

   • **上下文窗口很重要！**始终使用全新、干净的上下文窗口
   • **模型选择很重要！**使用最强大的思维模型进行 SM 故事创建
   • 始终在 SM、开发和 QA 工作之间开始新的聊天

   步骤 1 - 故事创建：

   • 新的干净聊天 → 选择强大的模型 → @sm → *create
   • SM执行创建下一个故事任务
   • 在 docs/stories/ 中审查生成的故事
   • 将状态从“草稿”更新为“已批准”

   步骤 2 - 故事实施：

   • NEW CLEAN CHAT → @dev
   • 代理询问要实施哪个故事
   • 包含故事文件内容以节省开发代理查找时间
   • 开发人员跟踪任务/子任务，标记完成
   • 开发人员维护所有更改的文件列表
   • 当所有测试通过后，开发人员将故事标记为“审查”

   步骤 3 - 高级 QA 审查：

   • NEW CLEAN CHAT → @qa → 执行审查故事任务
   • QA 执行高级开发人员代码审查
   • QA 可以直接重构和改进代码
   • QA 将结果附加到故事的 QA 结果部分
   • 如果获得批准：状态 → “完成”
   • 如果需要更改：状态保持“审核”，开发人员仍有未选中的项目

   步骤 4 - 重复：继续 SM → 开发 → QA 循环，直到所有史诗故事完成

重要：一次只进行 1 个故事，按顺序工作，直到所有史诗故事完成。

状态跟踪工作流

故事通过定义的状态进展：

• 草稿 → 已批准 → 进行中 → 完成

每个状态更改都需要用户验证和批准才能继续。

工作流类型

绿地开发

• 业务分析和市场研究
• 产品需求和功能定义
• 系统架构和设计
• 开发执行
• 测试和部署

棕地增强（现有项目）

关键概念：棕地开发需要对现有项目进行全面记录，以便 AI 代理了解背景、模式和约束。

完整的 Brownfield 工作流程选项：

选项 1：PRD-First（推荐用于大型代码库/Monorepos）：

1. 将项目上传到 Gemini Web（GitHub URL、文件或 zip）
2. 首先创建 PRD：@pm → *create-doc brownfield-prd

重点文档：@analyst → *document-project

• 如果未提供 PRD，分析师会要求关注
• 为 Web UI 选择“单文档”格式
• 使用 PRD 仅记录相关区域
• 创建一个综合的 markdown 文件
• 避免文档因未使用的代码而膨胀

选项 2：文档优先（适用于较小的项目）：

1. 将项目上传到 Gemini Web
2. 记录所有内容：@analyst → *document-project

然后创建 PRD：@pm → *create-doc brownfield-prd

• 更彻底，但可能会创建过多的文档

需求收集：

• 棕地 PRD：使用 PM 代理和 brownfield-prd-tmpl
• 分析：现有系统、约束、集成点
• 定义：增强范围、兼容性要求、风险评估
• 创建：变更的史诗和故事结构

架构规划：

• 棕地架构：使用架构师代理和 brownfield-architecture-tmpl
• 集成策略：新功能如何与现有系统集成
• 迁移规划：逐步推出和向后兼容
• 风险缓解：解决潜在的重大变化

棕地特定资源：

模板：

• brownfield-prd-tmpl.md：通过对现有系统进行分析来制定全面的增强计划
• brownfield-architecture-tmpl.md：针对现有系统的集成式架构

任务：

• document-project：从现有代码库生成全面的文档
• brownfield-create-epic：为重点增强创建单一史诗（当完整的 PRD 显得过度时）
• brownfield-create-story：为小的、孤立的更改创建单独的故事

何时使用每种方法：

完整的 Brownfield 工作流（推荐用于）：

• 主要功能添加
• 系统现代化
• 复杂的集成
• 多个相关更改

快速史诗/故事创建（使用情况）：

• 单一的、重点增强
• 孤立的错误修复
• 小功能添加
• 有据可查的现有系统

关键成功因素：

1. 文档优先：如果文档过时/缺失，请始终运行 document-project
2. 上下文事项：为代理提供相关代码部分的访问权限

集成重点：强调兼容性和非破坏性变化 4. 渐进式方法：计划逐步推出和测试

详细指南：请参阅 docs/working-in-the-brownfield.md

文档创建最佳实践

框架集成所需的文件命名

• docs/prd.md - 产品需求文档
• docs/architecture.md - 系统架构文档

为什么这些名称很重要：

• 代理在开发过程中自动引用这些文件
• 分片任务需要这些特定的文件名
• 工作流自动化依赖于标准命名

经济高效的文档创建工作流程

推荐用于大型文档（PRD、架构）：

1. 使用 Web UI：在 Web 界面中创建文档以提高成本效益
2. 复制最终输出：将完整的 markdown 保存到您的项目中

标准名称：另存为docs/prd.md 和 docs/architecture.md 4. 切换到 IDE：使用 IDE 代理进行开发并缩小文档大小

文档分

片 带有二级标题 (##) 的模板可以自动分片：

原始 PRD：

## 目标和背景上下文

## 要求

## 用户界面设计目标

## 成功指标

分片后：

• docs/prd/goals-and-background-context.md
• docs/prd/requirements.md
• docs/prd/user-interface-design-goals.md
• docs/prd/success-metrics.md

使用 shard-doc 任务或 @kayvan/markdown-tree-parser 工具进行自动分片。

使用模式和最佳实践

特定于环境的使用

Web UI 最适合：

• 初始规划和文档阶段
• 经济高效的大型文档创建
• 代理咨询和头脑风暴
• 带有协调器的多代理工作流

IDE 最适合：

• 主动开发和实施
• 文件操作和项目集成
• 故事管理和开发周期
• 代码审查和调试

质量保证

• 为专门任务使用适当的代理
• 遵循敏捷仪式和审查流程
• 使用 PO 代理保持文档一致性
• 使用清单和模板定期验证

性能优化

• 使用特定代理而不是 bmad-master 执行重点任务
• 根据项目需求选择合适的团队规模
• 利用技术偏好保持一致性
• 定期上下文管理和清除缓存

成功秘诀

• 使用 Gemini 进行全局规划 - team-fullstack bundle 提供协作专业知识
• 使用 bmad-master 进行文档组织 - 分片创建可管理的块
• 严格遵循 SM → Dev 周期 - 这可确保系统性进展
• 保持对话专注 - 每次对话一个代理，一个任务
• 审查所有内容 - 始终在标记完成之前进行审查和批准

为 BMad-Method 做出贡献

快速贡献指南

有关完整详细信息，请参阅CONTRIBUTING.md。要点：

Fork 工作流程：

1. Fork 存储库
2. 创建功能分支
3. 将 PR 提交到 next 分支（默认）或 main 仅进行关键修复
4. 保持 PR 较小：理想情况下 200-400 行，最多 800 行

每个 PR 一个功能/修复

PR 要求：

• 清晰的描述（最多 200 字），包括什么/为什么/如何/测试
• 使用常规提交（feat:、fix:、docs:）
• 原子提交 - 每次提交一个逻辑更改
• 必须符合指导原则

核心原则（来自 docs/GUIDING-PRINCIPLES.md）：

• 开发代理必须精益：最小化依赖关系，保存代码上下文
• 自然语言优先：所有内容都使用 markdown，核心中没有代码
• 核心与扩展包：核心用于通用需求，扩展包用于专门领域
• 设计理念：“开发代理代码，规划代理计划”

扩展包

什么是扩展包？

扩展包将 BMad-Method 从传统软件开发扩展到任何领域。 它们提供专业的代理团队、模板和工作流程，同时保持核心框架的精简并专注于开发。

为什么要使用扩展包？

1. 保持核心精简：开发代理维护编码的最大上下文
2. 领域专业知识：深厚的专业知识，而不会膨胀核心

社区创新：任何人都可以创建和共享包 4. 模块化设计：只安装您需要的

可用的扩展包

技术包：

• 基础设施/DevOps：云架构师、SRE 专家、安全专家
• 游戏开发：游戏设计师、关卡设计师、叙事作家
• 移动开发：iOS/Android 专家、移动 UX 专家
• 数据科学：机器学习工程师、数据科学家、可视化专家

非技术包：

• 商业战略：顾问、财务分析师、营销策略师
• 创意写作：情节架构师、角色开发者、世界构建者
• 健康与保健：健身教练、营养师、习惯工程师
• 教育：课程设计师、评估专家
• 法律支持：合同分析师、合规性检查员

专业包：

• 扩展创建者：构建您自己的扩展包的工具
• RPG 游戏大师：桌面游戏协助
• 人生大事策划：婚礼策划师、活动协调员
• 科学研究：文献综述员、方法设计师

使用扩展包

1. 浏览可用包：检查 expansion-packs/ 目录

2. 获取灵感：有关详细示例和想法，请参阅 docs/expansion-packs.md

3. 通过 CLI 安装：

   npx bmad-method install 
   # 选择“安装扩展包”选项

4. 在您的工作流程中使用：已安装的包与现有代理无缝集成

创建自定义扩展包

使用 expansion-creator 包构建您自己的：

1. 定义领域：您要捕捉哪些专业知识？
2. 设计代理：创建具有明确界限的专业角色
3. 构建资源：为您的领域创建任务、模板和清单

测试与分享：通过实际用例验证，并与社区分享

关键原则：扩展包通过 AI 代理提供专业知识，从而实现专业知识的民主化。

获取帮助

• 命令：在任何环境中使用 */*help 查看可用命令
• 代理切换：使用 */*switch agent-name 与协调器进行角色切换
• 文档：检查 docs/ 文件夹以获取特定于项目的上下文
• 社区：Discord 和 GitHub 资源可用于支持
• 贡献：有关完整指南，请参阅 CONTRIBUTING.md