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