title: "为什么解决方案设计很重要" description: 理解为什么解决方案设计阶段对于多 Epic 项目至关重要
第三阶段（解决方案设计）将构建什么（来自规划）转化为如何构建（技术设计）。此阶段通过在实施开始前记录架构决策，防止多 Epic 项目中的代理冲突。
没有解决方案设计的问题
Agent 1 使用 REST API 实施 Epic 1
Agent 2 使用 GraphQL 实施 Epic 2
Result: 不一致的 API 设计，集成噩梦当多个代理在没有共享架构指导的情况下实施系统的不同部分时，它们会做出可能冲突的独立技术决策。
有解决方案设计的解决方案
architecture workflow 决定: "所有 API 使用 GraphQL"
所有代理遵循架构决策
Result: 一致的实施，无冲突通过明确记录技术决策，所有代理都能一致实施，集成变得简单直接。
解决方案设计 vs 规划
| 方面 | 规划 (阶段 2) | 解决方案设计 (阶段 3) |
|---|---|---|
| 问题 | 什么和为什么？ | 如何？然后是什么工作单元？ |
| 输出 | FRs/NFRs (需求) | 架构 + Epics/Stories |
| 代理 | PM | Architect → PM |
| 受众 | 利益相关者 | 开发人员 |
| 文档 | PRD (FRs/NFRs) | Architecture + Epic Files |
| 级别 | 业务逻辑 | 技术设计 + 工作分解 |
关键原则
使技术决策显式且有记录，以便所有代理一致实施。
这可以防止：
- API 风格冲突 (REST vs GraphQL)
- 数据库设计不一致
- 状态管理分歧
- 命名约定不匹配
- 安全方法差异
何时需要解决方案设计
| 轨道 | 需要解决方案设计吗？ |
|---|---|
| 快速流程 | 否 - 完全跳过 |
| BMad 方法简单版 | 可选 |
| BMad 方法复杂版 | 是 |
| 企业版 | 是 |
:::tip[经验法则] 如果您有多个可能由不同代理实施的 Epic，您就需要解决方案设计。 :::
跳过的代价
在复杂项目中跳过解决方案设计会导致：
- 冲刺中期发现集成问题
- 由于实施冲突导致的返工
- 整体开发时间更长
- 来自不一致模式的技术债务
:::caution[成本乘数] 在解决方案设计中捕捉对齐问题的速度比在实施过程中发现它们快 10 倍。 :::