---
title: "为什么解决方案阶段很重要"
description: 理解为什么解决方案阶段对于多史诗项目至关重要
sidebar:
  order: 3
---


阶段 3（解决方案）将构建**什么**（来自规划）转化为**如何**构建（技术设计）。该阶段通过在实施开始前记录架构决策，防止多史诗项目中的智能体冲突。

## 没有解决方案阶段的问题

```text
智能体 1 使用 REST API 实现史诗 1
智能体 2 使用 GraphQL 实现史诗 2
结果：API 设计不一致，集成噩梦
```

当多个智能体在没有共享架构指导的情况下实现系统的不同部分时，它们会做出可能冲突的独立技术决策。

## 有解决方案阶段的解决方案

```text
架构工作流决定："所有 API 使用 GraphQL"
所有智能体遵循架构决策
结果：实现一致，无冲突
```

通过明确记录技术决策，所有智能体都能一致地实现，集成变得简单直接。

## 解决方案阶段 vs 规划阶段

| 方面 | 规划（阶段 2） | 解决方案（阶段 3） |
| -------- | ----------------------- | --------------------------------- |
| 问题 | 做什么和为什么？ | 如何做？然后是什么工作单元？ |
| 输出 | FRs/NFRs（需求） | 架构 + 史诗/用户故事 |
| 智能体 | PM | 架构师 → PM |
| 受众 | 利益相关者 | 开发人员 |
| 文档 | PRD（FRs/NFRs） | 架构 + 史诗文件 |
| 层级 | 业务逻辑 | 技术设计 + 工作分解 |

## 核心原则

**使技术决策明确且有文档记录**，以便所有智能体一致地实现。

这可以防止：
- API 风格冲突（REST vs GraphQL）
- 数据库设计不一致
- 状态管理分歧
- 命名约定不匹配
- 安全方法差异

## 何时需要解决方案阶段

| 流程 | 需要解决方案阶段？ |
|-------|----------------------|
| Quick Flow | 否 - 完全跳过 |
| BMad Method Simple | 可选 |
| BMad Method Complex | 是 |
| Enterprise | 是 |

:::tip[经验法则]
如果你有多个可能由不同智能体实现的史诗，你需要解决方案阶段。
:::

## 跳过的代价

在复杂项目中跳过解决方案阶段会导致：

- **集成问题**在冲刺中期发现
- **返工**由于实现冲突
- **开发时间更长**整体
- **技术债务**来自不一致模式

:::caution[成本倍增]
在解决方案阶段发现对齐问题比在实施期间发现要快 10 倍。
:::

---
## 术语说明

- **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**：技术债务。指为了短期目标而选择的不完美技术方案，未来需要付出额外成本来修复。