为什么解决方案阶段很重要
阶段 3（解决方案）将构建什么（来自规划）转化为如何构建（技术设计）。该阶段通过在实施开始前记录架构决策，防止多史诗项目中的智能体冲突。
没有解决方案阶段的问题
Section titled “没有解决方案阶段的问题”智能体 1 使用 REST API 实现史诗 1智能体 2 使用 GraphQL 实现史诗 2结果：API 设计不一致，集成噩梦当多个智能体在没有共享架构指导的情况下实现系统的不同部分时，它们会做出可能冲突的独立技术决策。
有解决方案阶段的解决方案
Section titled “有解决方案阶段的解决方案”架构工作流决定："所有 API 使用 GraphQL"所有智能体遵循架构决策结果：实现一致，无冲突通过明确记录技术决策，所有智能体都能一致地实现，集成变得简单直接。
解决方案阶段 vs 规划阶段
Section titled “解决方案阶段 vs 规划阶段”| 方面 | 规划（阶段 2） | 解决方案（阶段 3） |
|---|---|---|
| 问题 | 做什么和为什么？ | 如何做？然后是什么工作单元？ |
| 输出 | FRs/NFRs（需求） | 架构 + 史诗/用户故事 |
| 智能体 | PM | 架构师 → PM |
| 受众 | 利益相关者 | 开发人员 |
| 文档 | PRD（FRs/NFRs） | 架构 + 史诗文件 |
| 层级 | 业务逻辑 | 技术设计 + 工作分解 |
使技术决策明确且有文档记录，以便所有智能体一致地实现。
这可以防止：
- API 风格冲突（REST vs GraphQL）
- 数据库设计不一致
- 状态管理分歧
- 命名约定不匹配
- 安全方法差异
何时需要解决方案阶段
Section titled “何时需要解决方案阶段”| 流程 | 需要解决方案阶段？ |
|---|---|
| Quick Flow | 否 - 完全跳过 |
| BMad Method Simple | 可选 |
| BMad Method Complex | 是 |
| Enterprise | 是 |
在复杂项目中跳过解决方案阶段会导致：
- 集成问题在冲刺中期发现
- 返工由于实现冲突
- 开发时间更长整体
- 技术债务来自不一致模式
- agent：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
- epic：史诗。在敏捷开发中，指一个大型的工作项，可分解为多个用户故事。
- REST API：表述性状态传递应用程序接口。一种基于 HTTP 协议的 Web API 设计风格。
- GraphQL：一种用于 API 的查询语言和运行时环境。
- FRs/NFRs：功能需求/非功能需求。Functional Requirements/Non-Functional Requirements 的缩写。
- PRD：产品需求文档。Product Requirements Document 的缩写。
- PM：产品经理。Product Manager 的缩写。
- sprint：冲刺。敏捷开发中的固定时间周期，通常为 1-4 周。
- technical debt：技术债务。指为了短期目标而选择的不完美技术方案，未来需要付出额外成本来修复。