在深入探索 BMAD-METHOD 代码库时，我发现了一个非常精妙的设计：correct-course 工作流本质上是一个为 AI 驱动开发构建的结构化事故响应系统。

工作流的核心功能

当实现过程中发现根本性问题（技术限制、新需求、失败的方案）时，BMAD 不会简单地说”修复它”，而是运行一个系统化的 6 步变更导航流程。

6 步变更导航流程

步骤 1：初始化

• 收集问题描述
• 验证文档访问权限（PRD、Epics、Architecture、UX）
• 让用户选择模式：
  • 增量模式：协作式精炼每个编辑（推荐）
  • 批处理模式：一次性展示所有变更

步骤 2：执行检查清单

通过 6 个部分的系统化分析：

1. 触发器与上下文（发生了什么？）
2. Epic 影响评估（其他 epic 是否受影响？）
3. 工件冲突分析（PRD、Architecture、UX - 有什么冲突？）
4. 前进路径评估（3 个选项排序）
5. Sprint 变更提案组件
6. 最终审查与交接

步骤 3：起草编辑提案

创建明确的前后对比：

Story: [STORY-123] 用户认证
Section: 验收标准

OLD:
- 用户可以使用邮箱/密码登录

NEW:
- 用户可以使用邮箱/密码登录
- 用户可以通过认证器应用启用 2FA

Rationale: 实现过程中发现的安全需求

步骤 4：生成 Sprint 变更提案

编译包含以下部分的综合性文档：

• 问题摘要（问题陈述 + 证据）
• 影响分析（Epic、Story、工件冲突）
• 推荐方案（包含工作量/风险评估）
• 详细变更提案（每个工件的前后对比）
• 实现交接（谁做什么）

步骤 5：定稿并路由

获取用户批准，然后分类范围：

• 轻微：开发团队直接实现
• 中等：需要产品负责人/Scrum Master 重组待办事项
• 重大：需要产品经理/架构师重新规划

步骤 6：完成

确认交付物和成功标准。

三种前进路径

当问题出现时，工作流会评估三条路径：

1. 直接调整 - 修改现有故事，在当前 epic 结构中添加新故事
2. 潜在回滚 - 恢复已完成的故事以简化解决方案
3. PRD MVP 评审 - 减少/重新定义范围，推迟到 MVP 后

每条路径都按工作量（高/中/低）和风险（高/中/低）排序。

为什么这很重要

大多数 AI 编码助手只会说”让我修复它”。BMAD 认识到如果不系统化处理，Sprint 中期的变更可能会使整个项目脱轨。

检查清单会问一些具体问题，例如：

• 问题是否与核心 PRD 目标冲突？
• 哪些架构部分需要更新？（系统组件、模式、技术栈、数据模型、API 合约、集成点）
• 恢复最近完成的故事是否可以简化解决方案？

文件引用

位置：src/bmm/workflows/4-implementation/correct-course/

• instructions.md - 完整的 6 步工作流规范
• checklist.md - 6 部分系统化分析（23+ 检查项）
• workflow.yaml - 工作流引擎配置

Agent 触发器：John (PM) 或 Bob (SM) → CC 或 correct-course

关键设计理念

这个工作流体现了 BMAD 的几个核心设计原则：

1. 结构化决策：不是临时修复，而是有文档记录的影响分析
2. 明确交接：根据范围自动路由到正确的角色
3. 可追溯性：所有变更都有明确的前后对比和理由
4. 协作模式：支持增量和批处理两种协作方式
5. 风险评估：每个选项都评估工作量和风险级别

与传统 AI 编码助手的对比

实际应用场景

这个工作流特别适用于：

1. 技术限制发现：实现时发现选定的技术栈无法满足需求
2. 新需求涌现：利益相关者在开发中期添加关键功能
3. 需求误解：开发过程中发现对原始需求的理解有误
4. 战略转型：市场变化或产品方向调整
5. 方案失败：当前方案行不通，需要不同方法

总结

BMAD 的 Correct Course 工作流展示了 AI 驱动开发中变更管理的最佳实践。它将变更管理从”临时修复”提升到”结构化工程”，确保每次变更都经过充分的影响分析和明确的责任交接。

这正是 AI 辅助软件开发所需要的：不仅帮助写代码，更要帮助管理软件开发的复杂性和不确定性。

参考资源：

• BMAD-METHOD GitHub 仓库
• 文件：src/bmm/workflows/4-implementation/correct-course/
• Agent：John (PM)、Bob (Scrum Master)