# 03 - BMAD-METHOD 模块详解

## 1. BMad-CORE 核心框架

### 1.1 核心定位

**BMad-CORE** 是所有模块的基础框架，提供：
- 代理编排能力
- 工作流引擎
- 配置管理
- 多代理协作（Party Mode）

### 1.2 核心组件

#### BMad Master 代理

**角色定义**:
```yaml
name: "BMad Master"
title: "Master Executor, Knowledge Custodian, Workflow Orchestrator"
icon: "🧙"
role: "Master Task Executor + BMad Expert + Guiding Facilitator"
```

**职责**:
- 任务执行协调
- 资源管理
- 工作流编排
- 知识库守护

**菜单功能**:
- `list-tasks` - 列出所有可用任务
- `list-workflows` - 列出所有工作流
- `party-mode` - 启动多代理协作

#### Party Mode 工作流

**功能**: 多代理群组讨论模式

**特点**:
- 召集所有已安装的代理
- 实时群组对话
- 适用于战略决策和复杂问题
- 跨模块代理混合（BMM + CIS + BMB + 自定义）

**使用场景**:
- 战略规划讨论
- 创意头脑风暴
- 架构决策评审
- 跨职能问题解决

#### Brainstorming 工作流

**功能**: 结构化头脑风暴引导

**包含技术**: 30+ 种创意技术
- 发散思维：脑写、SCAMPER、随机输入
- 收敛思维：亲和图、投票、优先级矩阵
- 视觉技术：思维导图、概念图

**数据文件**:
```csv
brainstorming-techniques.csv
├── 技术名称
├── 分类（发散/收敛/视觉/角色/分析）
├── 描述
└── 最佳用途
```

### 1.3 核心任务系统

#### workflow.xml
通用工作流任务，提供：
- 工作流状态跟踪
- 文档读取和写入
- 路径解析
- 配置加载

#### adv-elicit.xml
高级引导任务，提供：
- 战略性提问
- 36 种引导方法
- 上下文感知对话
- 深度需求挖掘

**引导方法示例**:
```csv
adv-elicit-methods.csv
- Socratic Questioning (苏格拉底式提问)
- Five Whys (5个为什么)
- Lateral Thinking (横向思维)
- Devil's Advocate (魔鬼代言人)
- SWOT Analysis (SWOT 分析)
...36 种方法
```

---

## 2. BMad Method (BMM) - 主模块

### 2.1 模块概览

**规模**: 2.3 MB，最大模块
**用途**: AI 驱动的敏捷软件和游戏开发
**包含**: 12 个代理，34 个工作流，18 个文档

### 2.2 规模自适应系统（核心创新）

#### 3 轨道系统

**设计理念**: 根据项目复杂度自动调整流程深度

```
┌────────────────────────────────────────┐
│  Quick Flow Track (快速轨)             │
│  ────────────────────────────          │
│  适用: Bug 修复、小功能、清晰范围       │
│  时间: 1-3 小时规划                    │
│  输出: Tech Spec                       │
│  代理: 5 个精简团队                    │
│  流程: Tech Spec → 实现 → 测试         │
└────────────────────────────────────────┘

┌────────────────────────────────────────┐
│  BMad Method Track (标准轨) ⭐         │
│  ────────────────────────────          │
│  适用: 产品、平台、复杂功能            │
│  时间: 1-2 周规划                      │
│  输出: PRD + Architecture + UX         │
│  代理: 8 个完整团队                    │
│  流程: 完整 4 相方法                   │
│  使用率: 最常见（80%）                 │
└────────────────────────────────────────┘

┌────────────────────────────────────────┐
│  Enterprise Method Track (企业轨)      │
│  ────────────────────────────          │
│  适用: 企业系统、合规要求、大型项目    │
│  时间: 2-4 周规划                      │
│  输出: BMad + Security/DevOps/Test     │
│  代理: 12 个专业团队                   │
│  流程: 扩展规划和实现                  │
│  使用率: 少数（<5%）                   │
└────────────────────────────────────────┘
```

**轨道选择逻辑**:
- 不是基于 Story 数量（这是结果）
- 而是基于规划需求（这是输入）
- workflow-init 自动分析并推荐
- 用户可以覆盖选择

### 2.3 12 个专业代理详解

#### PM - Product Manager (John)
**角色**: Investigative Product Strategist
**专业知识**: 市场研究、竞争分析、用户行为
**工作流**: 8 个
- workflow-init, workflow-status
- create-prd, validate-prd
- tech-spec, validate-tech-spec
- create-epics-and-stories
- correct-course

**特点**: 善于提问，发掘深层需求

#### Analyst (Mary)
**角色**: Business Requirements Analyst
**专业知识**: 需求分析、业务逻辑、流程建模
**工作流**: 6 个
- workflow-init, workflow-status
- brainstorm-project, product-brief
- user-research, competitive-analysis

**特点**: 系统性思维，关注业务价值

#### Architect (Winston)
**角色**: Technical Architect
**专业知识**: 系统设计、架构模式、技术选型
**工作流**: 7 个
- create-architecture, validate-architecture
- solutioning-gate-check
- brownfield-document

**特点**: 注重可扩展性和技术债务管理

#### Scrum Master (Bob)
**角色**: Agile Facilitator + Sprint Coordinator
**专业知识**: Scrum 流程、团队协调、交付管理
**工作流**: 10 个
- sprint-planning, sprint-status
- epic-tech-context, epic-progress
- create-story, story-ready, story-context
- story-in-progress, story-done
- sprint-retrospective

**特点**: 流程守护者，确保敏捷实践

#### Developer (Amelia)
**角色**: Full-Stack Developer
**专业知识**: 编码、实现、重构、调试
**工作流**: 12 个
- dev-story (核心实现)
- story-review (代码审查)
- story-testing
- 以及所有 SM 的 Story 管理工作流

**特点**: Story 驱动开发，测试先行

#### Test Architect (Murat / TEA)
**角色**: Quality Engineering Architect
**专业知识**: 测试策略、自动化、质量保证
**工作流**: 9 个
- test-design, test-review
- nfr-assess (非功能需求)
- ci, framework
- test-healing
- risk-assessment

**特点**: 质量门禁，预防而非修复

#### UX Designer (Sally)
**角色**: User Experience Designer
**专业知识**: 交互设计、用户研究、设计系统
**工作流**: 3 个
- create-ux-design
- validate-ux-design
- design-system

**特点**: 用户中心，视觉和交互并重

#### Tech Writer (paige)
**角色**: Technical Documentation Specialist
**专业知识**: 技术写作、API 文档、用户指南
**工作流**: 4 个
- create-docs
- api-docs
- user-guide
- knowledge-transfer

**特点**: 清晰准确，面向不同受众

#### Game Designer (Samus Shepard) - BMGD
**角色**: Creative Visionary + Gameplay Architect
**专业知识**: 游戏机制、GDD、叙述设计
**工作流**: 游戏特定工作流
- brainstorm-game, game-brief
- gdd (Game Design Document)
- narrative

#### Game Developer - BMGD
**角色**: Game Implementation Specialist
**专业知识**: Unity/Unreal、游戏编程
**工作流**: 使用 BMM 的 dev-story 工作流

#### Game Architect - BMGD
**角色**: Game Systems Architect
**专业知识**: 游戏引擎架构、性能优化
**工作流**: game-architecture

#### Game Scrum Master - BMGD
**角色**: Game Development Coordinator
**工作流**: 使用 BMM 的 Sprint 工作流

### 2.4 4相方法论详解

#### Phase 1: Analysis (可选探索)

**目的**: 战略探索和市场验证

**工作流** (5个):
```
brainstorm-project      # 项目头脑风暴
├── 代理: Analyst
├── 输出: 初步想法和方向
└── 时间: 1-2 小时

product-brief          # 产品简报
├── 代理: Analyst
├── 输出: product-brief.md
└── 时间: 2-4 小时

market-research        # 市场研究
├── 代理: Analyst
├── 输出: market-research.md
└── 时间: 4-8 小时

competitive-analysis   # 竞争分析
├── 代理: Analyst
├── 输出: competitive-analysis.md
└── 时间: 4-8 小时

user-research         # 用户研究
├── 代理: Analyst
├── 输出: user-research.md
└── 时间: 4-8 小时
```

**何时使用**:
- ✅ 新产品或不确定的想法
- ✅ 需要市场验证
- ✅ 复杂的用户需求
- ❌ 清晰的 Bug 修复
- ❌ 明确的功能需求

#### Phase 2: Planning (必需)

**目的**: 定义"做什么"和"为什么"

**轨道差异**:

**Quick Flow Track**:
```
tech-spec
├── 代理: PM
├── 输出: tech-spec.md (简化的 PRD)
├── 内容:
│   ├── 问题描述
│   ├── 解决方案
│   ├── 技术要求
│   └── Story 列表 (1-15 个)
└── 时间: 1-3 小时
```

**BMad Method / Enterprise Track**:
```
prd (Product Requirements Document)
├── 代理: PM
├── 输出: PRD.md
├── 内容:
│   ├── 产品愿景
│   ├── 用户角色和场景
│   ├── 功能需求（Epic 级别）
│   ├── 非功能需求
│   ├── 约束和假设
│   └── 成功指标
└── 时间: 8-16 小时

create-epics-and-stories (子工作流)
├── 自动调用或手动执行
├── 输出: Epics.md 或 Epics/ 目录
├── 内容:
│   ├── Epic 分解
│   ├── Story 定义
│   ├── 接受条件
│   └── 依赖关系
└── 时间: 4-8 小时

create-ux-design (可选)
├── 代理: UX Designer
├── 输出: ux-design.md
├── 何时使用: UI 密集型项目
└── 时间: 8-16 小时
```

**Brownfield (现有代码)**:
```
brownfield-document
├── 代理: Architect
├── 输出: docs/ 目录（代码文档）
├── 目的: 记录现有系统
└── 时间: 视项目规模（1-40 小时）
```

#### Phase 3: Solutioning (轨道依赖)

**目的**: 定义"怎么做"

**Quick Flow**: 跳过此阶段 ❌

**BMad Method / Enterprise**:
```
architecture
├── 代理: Architect
├── 输出: architecture.md
├── 内容:
│   ├── 系统架构图
│   ├── 技术栈选择
│   ├── 模块划分
│   ├── API 设计
│   ├── 数据模型
│   ├── 部署架构
│   └── ADR (Architecture Decision Records)
└── 时间: 8-24 小时

solutioning-gate-check
├── 代理: Architect
├── 目的: 验证规划文档一致性
├── 检查:
│   ├── PRD ↔ Architecture 对齐
│   ├── UX ↔ PRD 一致
│   ├── Epics ↔ Architecture 映射
│   └── 技术可行性
└── 时间: 2-4 小时
```

**Enterprise 额外内容** (未来):
- Security Strategy (安全策略)
- DevOps Pipeline (DevOps 流程)
- Test Strategy (测试策略)

#### Phase 4: Implementation (迭代执行)

**目的**: Story 驱动的增量交付

**工作流程循环**:

```
Sprint 级别:
  sprint-planning
  ├── 代理: Scrum Master
  ├── 输出: sprint-status.yaml
  ├── 内容: 选择本 Sprint 的 Epic
  └── 时间: 1-2 小时

Epic 级别 (每个 Epic):
  epic-tech-context
  ├── 代理: Scrum Master
  ├── 输出: Epic-{name}-context.md
  ├── 目的: 技术实现指导
  └── 时间: 2-4 小时

Story 级别 (每个 Story):
  1. create-story
     ├── 代理: Scrum Master
     ├── 输出: Story-{id}.md
     ├── 状态: drafted
     └── 时间: 30 分钟

  2. story-ready (人工审查)
     ├── 代理: Scrum Master
     ├── 目的: 验证 Story 可实现
     ├── 状态: drafted → ready
     └── 时间: 15 分钟

  3. story-context (可选)
     ├── 代理: Scrum Master
     ├── 输出: Story-{id}-context.md
     ├── 目的: 实现细节指导
     └── 时间: 30-60 分钟

  4. dev-story (核心实现)
     ├── 代理: Developer
     ├── 活动: 编码、测试、文档
     ├── 状态: ready → in-progress → done
     └── 时间: 2-8 小时

  5. story-review (可选)
     ├── 代理: Developer
     ├── 目的: Code Review 和质量检查
     ├── 状态: done → reviewed
     └── 时间: 30-60 分钟

Sprint 结束:
  sprint-retrospective
  ├── 代理: Scrum Master
  ├── 输出: retrospective.md
  ├── 内容: 做得好、需改进、行动项
  └── 时间: 1-2 小时
```

**Story 生命周期状态**:
```
backlog → drafted → ready → in-progress → done → reviewed
```

**Just-in-Time Context 原则**:
- 实现 Story 时只加载：
  - Story 描述
  - Epic 技术上下文
  - Story 上下文
  - 相关架构决策
- 不加载整个 PRD 或架构文档（节省 token）

### 2.5 测试架构工作流

**Test Architect (TEA) 专项**:

```
test-design
├── 测试策略和计划
├── 测试用例设计
└── 测试数据准备

test-review
├── 测试覆盖率分析
├── 测试质量评审
└── 改进建议

nfr-assess (非功能需求)
├── 性能测试
├── 安全测试
├── 可用性测试
└── 兼容性测试

ci (持续集成)
├── CI/CD 流程设计
├── 自动化测试集成
└── 部署流程

framework (测试框架)
├── 测试框架选型
├── 测试基础设施
└── 测试工具集成

test-healing
├── 失败测试分析
├── 自动修复建议
└── 测试维护
```

---

## 3. BMad Builder (BMB) - 扩展工具

### 3.1 模块概览

**规模**: 463 KB
**用途**: 创建自定义代理、工作流和模块
**包含**: 1 个代理，7 个工作流

### 3.2 BMad Builder 代理

**职责**: 引导用户创建 BMAD 兼容的组件

**特点**:
- 交互式创建向导
- 遵循 BMAD 最佳实践
- 自动生成样板代码
- 验证 Schema 合规性

### 3.3 核心工作流

#### create-agent
**用途**: 创建自定义 AI 代理

**引导流程**:
```
1. 代理类型选择
   ├── Full Module Agent (完整模块代理)
   ├── Hybrid Agent (混合代理)
   └── Standalone Agent (独立代理)

2. 角色定义
   ├── 名称和图标
   ├── 角色描述
   ├── 专业知识领域
   └── 沟通风格

3. 菜单配置
   ├── 工作流列表
   ├── 快捷命令
   └── 描述文本

4. 生成和验证
   ├── YAML 生成
   ├── Schema 验证
   └── 编译测试
```

#### create-workflow
**用途**: 设计引导式多步骤工作流

**引导流程**:
```
1. 工作流元数据
   ├── 名称和描述
   ├── 作者信息
   └── 版本

2. 配置变量
   ├── 输入变量
   ├── 输出文件
   └── 依赖资源

3. 指令设计
   ├── 步骤定义
   ├── 提问策略
   └── 模板文件

4. Web Bundle 配置
   ├── 依赖文件列表
   ├── 子工作流
   └── 打包测试
```

#### create-module
**用途**: 打包完整的解决方案模块

**引导流程**:
```
1. 模块规划
   ├── 领域分析
   ├── 代理规划
   └── 工作流规划

2. 代理创建
   ├── 使用 create-agent
   └── 多个代理

3. 工作流创建
   ├── 使用 create-workflow
   └── 多个工作流

4. 模块打包
   ├── 安装配置
   ├── 文档编写
   └── 测试验证
```

#### module-brief
**用途**: 战略规划新模块

**输出**: 完整的模块设计文档

#### edit-agent / edit-workflow / edit-module
**用途**: 维护和改进现有组件

**功能**:
- 保持 v6 标准合规
- 自动备份
- 验证更改

#### audit-workflow
**用途**: 工作流质量审计

**检查项**:
- 结构完整性
- 配置标准
- 变量使用
- Web Bundle 完整性
- BMAD v6 标准合规

#### redoc
**用途**: 自动文档维护

**特点**:
- 反向树方法（叶节点优先）
- 理解 BMAD 约定
- 技术写作质量
- 自动更新

---

## 4. Creative Intelligence Suite (CIS)

### 4.1 模块概览

**规模**: 154 KB
**用途**: AI 驱动的创意促进和创新思维
**包含**: 5 个代理，5 个工作流

### 4.2 核心理念

**促进而非生成**:
- ❌ 不是：AI 生成创意
- ✅ 而是：AI 引导人类发现创意

**能量感知**:
- 根据用户参与度调整
- 识别疲劳和停滞
- 适时转换技术

### 4.3 5 个创意代理

#### Carson - Brainstorming Coach
**风格**: 充满活力的引导者
**专长**: 36 种头脑风暴技术
**工作流**: brainstorming

#### Maya - Design Thinking Coach
**风格**: 同理心驱动的设计师
**专长**: 5 相设计思维
**工作流**: design-thinking

#### Dr. Quinn - Creative Problem Solver
**风格**: 分析性突破专家
**专长**: 根因分析，系统性思考
**工作流**: problem-solving

#### Victor - Innovation Strategist
**风格**: 商业模式创新者
**专长**: 破坏性创新，蓝海战略
**工作流**: innovation-strategy

#### Sophia - Storyteller
**风格**: 叙述架构师
**专长**: 25 种故事框架
**工作流**: storytelling

### 4.4 5 个创意工作流

#### Brainstorming
**36 种技术**，分 7 类：
```
发散思维 (8种):
├── 脑写 (Brainwriting)
├── SCAMPER
├── 随机输入
└── ...

收敛思维 (6种):
├── 亲和图
├── 投票
└── 优先级矩阵

视觉技术 (5种):
├── 思维导图
├── 概念图
└── 故事板

角色扮演 (4种):
├── 六顶思考帽
├── 利益相关者视角
└── 极端用户

分析技术 (5种):
├── SWOT
├── 力场分析
└── 决策矩阵

协作技术 (4种):
├── 世界咖啡
├── 开放空间
└── 鱼缸对话

创新技术 (4种):
├── TRIZ
├── 生物启发
└── 技术预见
```

#### Design Thinking
**5 相方法**:
```
1. Empathize (同理心)
   └── 理解用户需求

2. Define (定义)
   └── 明确问题陈述

3. Ideate (构思)
   └── 生成解决方案

4. Prototype (原型)
   └── 快速原型制作

5. Test (测试)
   └── 用户测试和迭代
```

#### Problem Solving
**系统性方法**:
- 根因分析（5 Whys, 鱼骨图）
- 问题分解
- 解决方案生成
- 方案评估

#### Innovation Strategy
**商业模式创新**:
- 蓝海战略
- 破坏性创新
- 商业模式画布
- 价值主张设计

#### Storytelling
**25 种叙述框架**:
- 英雄之旅
- 三幕结构
- STAR 方法
- Before-After-Bridge
- ...

---

## 5. BMad Game Development (BMGD)

### 5.1 模块概览

**规模**: 556 KB
**用途**: 游戏开发完整生命周期
**包含**: 4 个专业代理 + BMM 集成

### 5.2 游戏专项代理

#### Game Designer (Samus Shepard)
**角色**: Creative Visionary + Gameplay Architect
**输出**: GDD, 游戏机制，叙述设计

#### Game Developer
**角色**: Game Implementation Specialist
**技能**: Unity/Unreal, C#/C++, 游戏编程

#### Game Architect
**角色**: Game Systems Architect
**专长**: 引擎架构，性能优化，网络同步

#### Game Scrum Master
**角色**: Game Development Coordinator
**职责**: Sprint 协调，游戏特定流程

### 5.3 游戏开发流程

```
Phase 1: Preproduction (前期制作)
├── brainstorm-game
├── game-brief
└── 概念验证

Phase 2: Design (设计)
├── gdd (Game Design Document)
├── narrative (叙述设计)
└── level-design

Phase 3: Technical (技术)
├── game-architecture
├── engine-selection
└── pipeline-design

Phase 4: Production (生产)
└── 使用 BMM Sprint 工作流
    ├── Epic: 游戏系统（移动、战斗、UI）
    ├── Story: 具体功能实现
    └── Sprint: 迭代开发
```

### 5.4 与 BMM 集成

**优势**:
- 复用成熟的 Sprint 工作流
- Story 驱动的游戏开发
- 敏捷实践应用于游戏
- 跨领域最佳实践

---

## 6. 模块间协作

### 6.1 依赖关系

```
BMM → CIS
└── BMM 的 brainstorm-project 调用 CIS 的 brainstorming

BMM → BMGD
└── BMGD 使用 BMM 的 Sprint 工作流

BMB → 所有模块
└── 创建新代理和工作流扩展任何模块
```

### 6.2 Party Mode 跨模块协作

**场景**: 游戏产品战略规划

**参与代理**:
- PM (BMM) - 产品策略
- Game Designer (BMGD) - 游戏设计
- Carson (CIS) - 创意头脑风暴
- Architect (BMM) - 技术架构
- Victor (CIS) - 商业创新

**流程**:
1. 启动 Party Mode
2. 所有代理加入讨论
3. 多角度分析问题
4. 综合建议输出

---

## 7. 小结

BMAD 的模块化设计：

✅ **核心稳定** - BMad-CORE 提供统一基础
✅ **模块独立** - 各模块可单独安装使用
✅ **深度集成** - 模块间无缝协作
✅ **可扩展** - BMB 支持创建新模块
✅ **领域适应** - 已覆盖开发、游戏、创意

**下一步**: 阅读 [04-工作流程.md](./04-工作流程.md) 了解工作流执行细节