809 lines
28 KiB
Markdown
809 lines
28 KiB
Markdown
<!-- 由 BMAD™ Core 驱动 -->
|
||
|
||
# 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周期
|
||
- 一次一个故事，顺序进展
|
||
- 实时文件操作和测试
|
||
|
||
### 开发循环
|
||
|
||
```text
|
||
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用户
|
||
|
||
```bash
|
||
# 交互式安装 (推荐)
|
||
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项目**:
|
||
|
||
```yaml
|
||
prdVersion: v3
|
||
prdSharded: false
|
||
architectureVersion: v3
|
||
architectureSharded: false
|
||
```
|
||
|
||
**V4优化项目**:
|
||
|
||
```yaml
|
||
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中**:
|
||
|
||
```text
|
||
/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创建**:
|
||
|
||
```text
|
||
"我想构建一个[类型]应用程序，其[核心目的]。
|
||
帮我头脑风暴功能并创建一个全面的PRD。"
|
||
```
|
||
|
||
**用于架构设计**:
|
||
|
||
```text
|
||
"基于此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**:
|
||
|
||
```markdown
|
||
## 目标和背景上下文
|
||
|
||
## 需求
|
||
|
||
## 用户界面设计目标
|
||
|
||
## 成功指标
|
||
```
|
||
|
||
**分片后**:
|
||
|
||
- `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安装**:
|
||
|
||
```bash
|
||
npx bmad-method install
|
||
# 选择 "安装扩展包" 选项
|
||
```
|
||
|
||
4. **在您的工作流中使用**: 安装的包与现有代理无缝集成
|
||
|
||
### 创建自定义扩展包
|
||
|
||
使用 **expansion-creator** 包构建您自己的：
|
||
|
||
1. **定义领域**: 您要捕获什么专业知识？
|
||
2. **设计代理**: 创建具有清晰边界的专业角色
|
||
3. **构建资源**: 为您的领域创建任务、模板、清单
|
||
4. **测试与分享**: 用真实用例验证，与社区分享
|
||
|
||
**关键原则**: 扩展包通过AI代理使专业知识变得可访问，从而使专业知识民主化。
|
||
|
||
## 获取帮助
|
||
|
||
- **命令**: 在任何环境中使用 `*/*help` 查看可用命令
|
||
- **代理切换**: 使用 `*/*switch agent-name` 与协调器进行角色更改
|
||
- **文档**: 查看 `docs/` 文件夹以获取特定于项目的上下文
|
||
- **社区**: 可通过Discord和GitHub获取支持资源
|
||
- **贡献**: 有关完整指南，请参阅 `CONTRIBUTING.md`
|