---
name: rd-solution
description: >-
  把已批准需求或可研输入转化为技术方案、概要设计、解决方案架构或建设方案。
  当软件、基础设施、网络或 AI 系统需要比较真实候选方案、形成架构决策、明确运行边界
  并给出可供详细设计使用的推荐结论时使用。可研、详细设计、独立评审、解释性写作和执行分别路由到其责任工作流。
---

# rd-solution

产出可支撑决策的**技术方案、概要设计、解决方案架构和建设方案**。

## 交付物

- 技术方案文档 / 概要设计 / 解决方案架构文档
- 建设方案或设计导向的项目建设计划
- 候选方案比较矩阵
- 推荐方案及风险说明
- 重大决策的架构决策记录输入

## 执行步骤

### 1. 目标与约束确认

- 明确文档类型（技术方案 / 概要设计 / 解决方案架构 / 建设方案）
- 确认读者（决策层 / 技术团队 / 甲方评审）
- 确认约束条件：时间、预算、技术栈、合规要求
- 检查是否有已有需求文档（`rd-requirement` 产出）
- 项目有立项审批阶段时，检查可研输入（`rd-feasibility` 产出）
- 从项目材料中核实可查事实，只向用户确认仍未决定且会实质影响方案的事项
- 使用既有领域术语；发现冲突时显式指出，不静默创建同义词

**完成标准：** 目标文档、受众、已批准输入、约束、未决决策和术语依据均已明确到足以生成真实候选方案。

### 2. 方案研究与候选生成

- 存在真实架构或技术选择时，至少生成 **2 个候选方案**
- 每个方案包含：架构概览、核心组件、数据/接口边界、技术选型、部署或运行假设
- 影响决策的成熟度、兼容性、政策、成本或当前版本主张路由到 `rd-research`；候选生成不得演变为无边界搜索阶段
- 基础设施、网络、代理、VPN、VPS 或 AI 工具方案应明确建模信任边界、控制流/数据流、凭据归属、平台/版本约束、可观测性、恢复和退出路径

**完成标准：** 每项真实决策至少有两个可行候选方案，或记录只剩一个方案的原因；各候选方案声明同一组重要边界和假设。

### 3. 多维度交叉检查

对每个候选方案从以下维度评估：

| 维度 | 检查内容 |
|------|---------|
| 功能完整性 | 是否覆盖全部 P0/P1 需求 |
| 性能 | 容量规划、瓶颈预判、扩展路径 |
| 可靠性 | 容错、灾备、数据一致性策略 |
| 安全性 | 认证授权、输入校验、数据保护、审计 |
| 可维护性 | 组件责任、可观测性、运维复杂度 |
| 成本 | 开发成本、运维成本、许可费用 |
| 风险 | 技术风险、人员风险、进度风险、外部依赖风险 |
| 退出路径 | 推荐方案验证失败或被否决时的替代路径 |
| 可验证性 | 承诺投入前所需证据、原型、兼容性检查或验收方法 |

**完成标准：** 所有候选方案均按同一组与决策相关的维度比较，缺失证据和不可直接比较的准则保持可见。

### 4. 推荐与决策建议

- 基于量化或半量化比较给出推荐
- 明确推荐理由和放弃其他方案的理由
- 标注推荐的置信度（高 / 中 / 低）及依据
- 说明遗留风险和后续需确认事项

**完成标准：** 推荐、被否决方案、置信度、剩余风险，以及选定并投入方案前必须完成的核验动作，均可追踪到比较结果。

### 5. 文档结构化输出

根据文档类型选择对应模板：

#### 技术方案 / 概要设计

```
1. 背景与目标
2. 需求概述（引用需求文档）
3. 约束条件
4. 候选方案
   4.1 方案 A
   4.2 方案 B
5. 方案比较
6. 推荐方案
7. 架构设计（推荐方案详述）
8. 关键风险与缓解措施
9. 实施计划（里程碑）
10. 遗留问题
```

#### 建设方案（设计导向）

```
1. 背景与目标
2. 需求概述
3. 约束条件
4. 候选方案与比较
5. 推荐方案
6. 系统架构设计
7. 部署架构设计
   7.1 基础设施拓扑（网络、计算、存储）
   7.2 环境规划
   7.3 设计层面的部署策略
   7.4 容量规划与资源预估
   7.5 高可用与灾备设计
8. 安全设计
9. 关键风险与缓解措施
10. 实施计划与里程碑
11. 遗留问题
```

> 边界：本 Skill 可在建设方案或概要设计中定义部署架构，但不产出部署操作手册、发布命令、回滚执行步骤或运维变更记录。

**完成标准：** 所选结构覆盖全部影响决策的章节，保持方案或概要设计深度，并为下游设计提供可评审的建议边界、决策依据和明确的批准状态。除非批准属于本次明确成功标准或阶段退出门禁，否则等待干系人批准不阻塞方案交付完成；推荐意见不构成下游执行或基线化授权。

## 上下文与基线检查

执行前检查：
- 项目是否有技术方案模板或格式要求
- 是否有架构决策记录（ADR）的规范
- 已有的技术栈约束和选型原则
- 已有术语表或领域模型；只有决策难以逆转、缺少背景会令人意外且确有真实权衡时才记录 ADR

## 工具选择

- 当前文档、成熟度、兼容性、成本、政策或行业证据会实质影响推荐时，使用 `rd-research`
- 优先一手来源和最窄的已配置检索能力
- 仅在核实当前框架、库、SDK 或 API 事实时使用 Context7 或同类文档检索能力
- 参考架构只能作为示例，不能证明其适合本项目约束

## 质量门禁

交付前核查：

- [ ] 存在真实选择时已比较候选方案
- [ ] 推荐依据明确，置信度已标注
- [ ] 安全性维度已覆盖（认证、校验、保护、审计）
- [ ] 风险已识别，每项风险有缓解措施
- [ ] 高影响决策已有退出或替代路径
- [ ] 关键数据有来源标注，推断与事实已区分
- [ ] 文档结构完整，读者可独立理解
- [ ] 文档保持在方案/概要设计深度，没有滑向代码实现
- [ ] 易变的技术结论和配置假设已经核实或明确限定证据边界

## 不做

- 不只给一个方案说"这是最优解"
- 不编造基准测试数据或性能数字
- 不把推断说成已验证事实
- 不写代码、测试、部署操作手册或执行流程
- 主要难点是面向受众组织叙事而非架构选型的技术文章、白皮书、研究报告或决策简报，使用 `rd-writing`