ldy26098
/
BMAD-METHOD
mirror of https://github.com/bmad-code-org/BMAD-METHOD.git
1
0
Fork 0
Code Packages Projects Releases Wiki Activity
BMAD-METHOD/bmad-core/data/bmad-kb.md

28 KiB
Raw Blame History

BMAD™ 知识库

概述

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

主要特性

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

何时使用BMad

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

BMad如何工作

核心方法

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

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

两阶段方法

阶段1：规划 (Web UI - 经济高效)

  • 使用大上下文窗口 (Gemini的1M令牌)
  • 生成全面的文档 (PRD, 架构)
  • 利用多个代理进行头脑风暴
  • 一次创建，贯穿整个开发过程

阶段2：开发 (IDE - 实施)

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

开发循环

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. 上传文件并附上说明：“您的关键操作说明已附上，请按指示不要脱离角色”
  5. 输入 /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用户注意: BMAD-METHOD™ 假设当您提到“VS Code”时，您正在使用它与一个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, 架构)，然后复制到您项目中的 docs/prd.md 和 docs/architecture.md，再切换到IDE进行开发。

仅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/架构师/UX代理进行规划 (比bmad-master更好)
  2. 直接在项目中创建文档
  3. 创建后立即分片
  4. 必须切换到SM代理创建故事
  5. 必须切换到Dev代理进行实施
  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
  3. 自定义工作流: 配置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. 文档是关键: 好的输入 (简报, PRD) 会带来好的输出。
  7. 从小处着手，快速扩展: 测试概念，然后扩展。
  8. 拥抱混乱: 适应并克服挑战。

关键工作流原则

  1. 代理专业化: 每个代理都有特定的专业知识和职责
  2. 清晰的交接: 在代理之间切换时始终重新开始
  3. 状态跟踪: 维护故事状态 (草稿 → 已批准 → 进行中 → 完成)
  4. 迭代开发: 在开始下一个故事之前完成一个故事
  5. 文档优先: 始终从坚实的PRD和架构开始

代理系统

核心开发团队

代理 角色 主要功能 何时使用
analyst 业务分析师 市场研究，需求收集 项目规划，竞争分析
pm 产品经理 PRD创建，功能优先级排序 战略规划，路线图
architect 解决方案架构师 系统设计，技术架构 复杂系统，可扩展性规划
dev 开发人员 代码实现，调试 所有开发任务
qa 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: 打开聊天视图 (⌃⌘I on Mac, Ctrl+Alt+I on Windows/Linux) 并从聊天模式选择器中选择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

全栈团队

  • 包括: PM, 架构师, 开发人员, QA, UX专家
  • 用例: 端到端的Web/移动开发
  • 包: team-fullstack.txt

无UI团队

  • 包括: PM, 架构师, 开发人员, QA (无UX专家)
  • 用例: 后端服务, API, 系统开发
  • 包: team-no-ui.txt

核心架构

系统概述

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

关键架构组件

1. 代理 (bmad-core/agents/)

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

2. 代理团队 (bmad-core/agent-teams/)

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

3. 工作流 (bmad-core/workflows/)

  • 目的: 为特定项目类型定义规定步骤序列的YAML文件
  • 类型: 绿地 (新项目) 和棕地 (现有项目) 的UI、服务和全栈开发
  • 结构: 定义代理交互、创建的工件和转换条件

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-builder工具创建，用于上传到Web界面
  • 在一个包中提供完整的上下文

模板处理系统

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

  1. 模板格式 (utils/bmad-doc-template.md): 定义用于变量替换和来自yaml模板的AI处理指令的标记语言
  2. 文档创建 (tasks/create-doc.md): 协调模板选择和用户交互，将yaml规范转换为最终的markdown输出
  3. 高级启发 (tasks/advanced-elicitation.md): 通过结构化的头脑风暴提供交互式完善

技术偏好集成

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

  • 确保所有代理和项目的一致性
  • 消除重复的技术规范
  • 提供符合用户偏好的个性化建议
  • 随着经验教训的积累而不断演进

构建和交付过程

web-builder.js 工具通过以下方式创建Web就绪的包：

  1. 读取代理或团队定义文件
  2. 递归解析所有依赖项
  3. 将内容连接成带有清晰分隔符的单个文本文件
  4. 输出可供上传到Web AI界面的就绪包

这种架构实现了跨环境的无缝操作，同时保持了使BMad强大的丰富、互联的代理生态系统。

完整开发工作流

规划阶段 (推荐Web UI - 特别是Gemini！)

对于使用Gemini巨大上下文的成本效益是理想的：

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

  1. 将整个项目上传到Gemini Web (GitHub URL, 文件, 或zip)
  2. 记录现有系统: /analyst → *document-project
  3. 从整个代码库分析中创建全面的文档

对于所有项目:

  1. 可选分析: /analyst - 市场研究, 竞争分析
  2. 项目简报: 创建基础文档 (分析师或用户)
  3. 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/ 文件夹中

  1. 文档分片 (关键步骤):

    • 由PM/架构师创建的文档 (在Web或IDE中) 必须为开发进行分片
    • 分片有两种方法： a) 手动: 将 shard-doc 任务 + 文档文件拖入聊天 b) 代理: 要求 @bmad-master 或 @po 分片文档
    • 将 docs/prd.md 分片到 docs/prd/ 文件夹
    • 将 docs/architecture.md 分片到 docs/architecture/ 文件夹
    • 警告: 不要在Web UI中分片 - 复制许多小文件很痛苦！

  2. 验证分片内容:

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

生成的文件夹结构：

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

  1. 开发周期 (顺序进行，一次一个故事):

    关键上下文管理:

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

    步骤1 - 故事创建:

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

    步骤2 - 故事实施:

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

    步骤3 - 高级QA审查:

    • 新的干净聊天 → @qa → 执行review-story任务
    • QA执行高级开发人员代码审查
    • QA可以直接重构和改进代码
    • QA将结果附加到故事的QA结果部分
    • 如果批准：状态 → “完成”
    • 如果需要更改：状态保持“待审查”，并为开发人员提供未检查的项目

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

重要提示: 一次只有一个故事在进行中，按顺序工作，直到所有史诗故事完成。

状态跟踪工作流

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

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

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

工作流类型

绿地开发

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

棕地增强 (现有项目)

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

完整的棕地工作流选项:

选项1：PRD优先 (推荐用于大型代码库/单体仓库):

  1. 将项目上传到Gemini Web (GitHub URL, 文件, 或zip)
  2. 首先创建PRD: @pm → *create-doc brownfield-prd
  3. 专注文档: @analyst → *document-project
    • 如果未提供PRD，分析师会要求提供焦点
    • 为Web UI选择“单一文档”格式
    • 使用PRD仅记录相关区域
    • 创建一个全面的markdown文件
    • 避免用未使用的代码使文档膨胀

选项2：文档优先 (适用于较小项目):

  1. 将项目上传到Gemini Web

  2. 记录所有内容: @analyst → *document-project

  3. 然后创建PRD: @pm → *create-doc brownfield-prd

    • 更彻底，但可能产生过多文档

  4. 需求收集:

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

  5. 架构规划:

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

棕地特定资源:

模板:

  • brownfield-prd-tmpl.md: 带有现有系统分析的全面增强规划
  • brownfield-architecture-tmpl.md: 用于现有系统的以集成为重点的架构

任务:

  • document-project: 从现有代码库生成全面的文档
  • brownfield-create-epic: 为专注的增强创建单个史诗 (当完整的PRD过于冗长时)
  • brownfield-create-story: 为小的、孤立的更改创建单个故事

何时使用每种方法:

完整棕地工作流 (推荐用于):

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

快速史诗/故事创建 (用于):

  • 单一、专注的增强
  • 孤立的错误修复
  • 小的功能添加
  • 文档齐全的现有系统

关键成功因素:

  1. 文档优先: 如果文档过时/缺失，请始终运行 document-project
  2. 上下文很重要: 为代理提供对相关代码部分的访问权限
  3. 关注集成: 强调兼容性和非破坏性更改
  4. 增量方法: 计划逐步推出和测试

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

文档创建最佳实践

框架集成的必需文件命名

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

为何这些名称很重要:

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

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

推荐用于大型文档 (PRD, 架构):

  1. 使用Web UI: 在Web界面中创建文档以提高成本效益
  2. 复制最终输出: 将完整的markdown保存到您的项目中
  3. 标准名称: 另存为 docs/prd.md 和 docs/architecture.md
  4. 切换到IDE: 使用IDE代理进行开发和处理较小的文档

文档分片

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

原始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包提供协作专业知识
  • 使用bmad-master进行文档组织 - 分片创建可管理的块
  • 严格遵循SM → Dev周期 - 这确保了系统的进展
  • 保持对话专注 - 每个对话一个代理，一个任务
  • 审查一切 - 在标记完成前始终审查和批准

为BMAD-METHOD™做贡献

快速贡献指南

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

Fork工作流:

  1. Fork仓库
  2. 创建功能分支
  3. 向 next 分支提交PR (默认) 或仅为关键修复提交到 main
  4. 保持PR小：200-400行是理想的，最多800行
  5. 每个PR一个功能/修复

PR要求:

  • 清晰的描述 (最多200字)，包括什么/为什么/如何/测试
  • 使用常规提交 (feat:, fix:, docs:)
  • 原子提交 - 每个提交一个逻辑更改
  • 必须与指导原则保持一致

核心原则 (来自 docs/GUIDING-PRINCIPLES.md):

  • 开发代理必须精简: 最小化依赖项，为代码节省上下文
  • 自然语言优先: 所有内容都在markdown中，核心中没有代码
  • 核心与扩展包: 核心用于通用需求，包用于专业领域
  • 设计理念: “开发代理编码，规划代理规划”

扩展包

什么是扩展包？

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

为何使用扩展包？

  1. 保持核心精简: 开发代理为编码保持最大的上下文
  2. 领域专业知识: 深入的、专业的知识，而不会使核心膨胀
  3. 社区创新: 任何人都可以创建和共享包
  4. 模块化设计: 只安装您需要的东西

可用扩展包

技术包:

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

非技术包:

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

专业包:

  • 扩展创建者: 用于构建您自己的扩展包的工具
  • RPG游戏大师: 桌游辅助
  • 生活事件规划: 婚礼策划师, 活动协调员
  • 科学研究: 文献综述员, 方法论设计师

使用扩展包

  1. 浏览可用包: 查看 expansion-packs/ 目录
  2. 获取灵感: 查看 docs/expansion-packs.md 获取详细示例和想法
  3. 通过CLI安装:
npx bmad-method install
# 选择 "安装扩展包" 选项
  1. 在您的工作流中使用: 安装的包与现有代理无缝集成

创建自定义扩展包

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

  1. 定义领域: 您要捕获什么专业知识？
  2. 设计代理: 创建具有清晰边界的专业角色
  3. 构建资源: 为您的领域创建任务、模板、清单
  4. 测试与分享: 用真实用例验证，与社区分享

关键原则: 扩展包通过AI代理使专业知识变得可访问，从而使专业知识民主化。

获取帮助

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