# Solution Expert

> 生成软件项目的【总体技术方案文档】（5 章 + 附录）。适用场景：立项、启动会、技术交底、交付内审、售前预沟通（客户给出初步需求，乙方提供方案以决策是否合作）。 必触发词：技术交底书、交付方案、总体方案、整体解决方案、项目方案、立项方案、启动方案、售前方案、可行性方案；或用户描述"客户给了初步需求，让出方案判断要不要做"。 不适用： - 单功能/单接口/单模块设计 → product-manager 或 java-backend-dev - bug 修复、性能优化、技术选型对比 → 直接做技术分析 - 代码级设计、分布式微服务架构 → 不在固定栈范围内 - 投标书主体（商务报价/资质/案例/团队） → 本 skill 仅产技术部分 歧义判断：用户说"技术方案/解决方案"先确认是项目级还是单点，不要默认触发。

- Skill: `wangwenyao/solution-expert` (Agent Skill, multi-file: 19 files)
- Install (CLI): `npx skillmds@latest add wangwenyao/solution-expert`
- Raw SKILL.md: https://api.skillmd.com/api/skills/wangwenyao/solution-expert/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: wangwenyao (https://skillmd.com/u/wangwenyao)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/wangwenyao/solution-expert

---


# 软件交付总体技术解决方案 Skill

## 定位与边界

**适用场景**：项目立项、启动会、技术交底、交付内审、**售前预沟通**（客户给出初步需求、要求乙方提供方案以决策是否合作）等"乙方内部对齐 + 甲方技术线确认 + 合作决策评估"场景。

**输出性质**：合格初稿。能保障技术设计自洽、结构规范、常见需求不遗漏；不能保障设计完全符合客户真实业务逻辑（需人工验证）。

**能力边界（明确不做）**：
- 不输出商务方案（人月单价、硬件清单、License 报价、付款节点、知识产权归属）
- 不输出"我方"章节（公司资质、类似案例、团队履历、方法论沉淀）
- 不输出行业合规深度内容（等保 2.0 三级测评条款、个保法/数安法落地、国密、信创栈替换）只在附录留待确认占位
- 不评估业务 ROI/TCO/回收期等财务收益指标
- 不替代售前/解决方案经理在投标场景的全套交付物——本 skill 产出物在投标场景仅作"技术分册"使用

---

## 执行工作流

严格按顺序执行，每步明确指定读取的文件。**每步必须显式产出"输出物"**（用 `<step-N-output>` 块标注），供后续 Step 引用，避免隐性动作。

### Step 1 — 解析输入
**输入**：用户原始需求描述
**读取**：无（使用下方【功能类型快速识别表】）
**动作**：识别输入类型（场景描述型 / 功能清单型 / 混合型），提取信息。
**功能点粒度规则**：一个独立的业务对象 + 一组操作 = 一个功能点（如"采购申请的提交/审批/查询"是一个功能点而非三个）。
**输出物**（必须显式产出）：

```
<step-1-output>
输入类型: {场景描述型/功能清单型/混合型}
显性功能点列表（带类型标签）:
- {功能点1}（类型: 数据管理/流程审批/统计报表/权限控制/系统集成）
- {功能点2}（类型: ...）
业务领域和行业背景: {领域}
已明确的约束条件: {约束列表}
外部系统集成需求: {集成清单 或 "无"}
</step-1-output>
```

### Step 2 — 输入质量检查
**输入**：Step 1 输出
**读取**：`@references/input-validation.md`
**动作**：识别 A/B/C 三类问题。
**异常处理**：A 类非空时，停止后续 Step，按 input-validation.md 提问格式一次性提出所有问题，等待回复后从 Step 2 重新开始。
**输出物**：

```
<step-2-output>
A 类（致命缺失，需澄清）: {问题列表 或 "无"}
B 类（推断缺失，记录默认值）: {缺失项 → 默认值}
C 类（歧义，做出选择）: {歧义点 → 选择 + 备选差异}
</step-2-output>
```

### Step 3 — 需求补全
**输入**：Step 1 输出 + Step 2 输出
**读取**：`@references/implicit-inference.md`
**按需读取**：`@references/nfr-defaults.md`（仅当客户未明确非功能需求时）
**动作**：按功能类型逐项补全隐性需求；按行业 + 规模填充 NFR。

**多源值合并规则（关键，避免行业默认值覆盖客户明确值）**：
- 优先级：**客户明确值 > 行业叠加值 > 规模默认值**（高位覆盖低位）
- 例 1：客户说"等保三级"，nfr-defaults 政务行业默认"二级起步"，按客户取三级
- 例 2：规模默认 99% 可用性，客户说 99.9%，按客户值
- 客户值与默认值冲突时，方案中明确标注"按客户要求 X，覆盖行业默认 Y"

**输出物**：

```
<step-3-output>
完整需求全景:
- 显性需求: {Step 1 提取的功能点}
- 隐性需求（按功能类型补全）: {补全清单}
- 共有隐性需求: 认证/RBAC/审计/错误提示/防重提交
- 交付类隐性需求: 数据迁移/培训/运维交付物
NFR 指标（标注来源 = 客户/行业/规模默认）:
- 性能: {QPS/响应时间} （来源: ...）
- 可用性: {%} （来源: ...）
- 数据留存: {期限} （来源: ...）
- 安全: {等级/合规要求} （来源: ...）
</step-3-output>
```

### Step 4 — 建立域模型
**输入**：Step 3 输出
**读取**：`@references/complexity-detection.md`
**动作**：按下方【域归并原则】将功能点归并为业务域；用 complexity-detection 5 条标准识别复杂模块。
**输出物**（按 complexity-detection.md 末尾输出格式）：

```
<step-4-output>
业务域划分:
- {域1名}: 负责管理 {一句话职责}
  - 模块: {模块清单}
- {域2名}: ...
- 系统管理域: 用户、角色、组织、字典、日志（独立）
- 分析报表域: {如有}（独立，只读依赖各业务域）

[核心复杂模块] （第 4 章详细说明）:
- {模块名}（原因: 状态流转/数据权限/性能/外部集成/定时任务）

[标准实现模块]:
- {模块名列表}
</step-4-output>
```

### Step 5 — 确认受众
**输入**：Step 1 输出（业务领域）+ 客户类型
**读取**：无（使用下方【受众判断规则】）
**动作**：按客户行业和受众层级，确定各章节技术深度。
**输出物**：

```
<step-5-output>
客户类型: {政府/企业/事业单位/...}
混合受众标记: {是/否}
各章节表达策略:
- 第 1、5 章、附录: 业务方语言，不出现技术术语
- 第 2 章: 业务语言（功能描述）+ 量化指标（非功能需求）
- 第 3、4 章: 技术语言 + SCQA + 三要素
</step-5-output>
```

### Step 6 — 逐章生成
**输入**：Step 3 + Step 4 + Step 5 全部输出物
**读取**：每章按需读取对应章节指南（不提前全量加载，章节生成完毕后释放上下文）。
**动作**：**严格按 ch1 → ch2 → ch3 → ch4 → ch5 → 附录 顺序生成，禁止并行**。

**为什么必须串行**（依赖关系）：
- 第 5 章工期估算依赖第 2 章功能架构表（模块数 + 复杂模块数）
- 附录 A 待确认事项依赖第 1 章假设 + 第 5 章风险表
- 附录 B 术语表需扫描第 1、5 章中泄漏的技术术语
- 并行生成会导致依赖断裂、术语漂移、工期估算无依据

所有设计描述基于以下固定栈，不做选型决策：

| 层次 | 约束 |
|---|---|
| 前端 | Vue3 + Ant Design |
| 后端 | Spring Boot 单体（分层架构） |
| 数据库 | MySQL |
| 缓存 | Redis（按需引入） |
| 任务调度 | Quartz（按需引入）|

| 章节 | 标题 | 主要受众 | 读取文件 |
|---|---|---|---|
| 第 1 章 | 项目概述与价值定位 | 业务决策层 | `@references/chapter-guides/ch1.md` |
| 第 2 章 | 需求分析与功能范围 | 业务方 + 技术方 | `@references/chapter-guides/ch2.md` + `@references/diagram-guides.md` |
| 第 3 章 | 技术架构与部署方案 | 技术架构师 | `@references/chapter-guides/ch3.md` + `@references/backend-constraint.md` + `@references/middleware-constraints.md` + `@references/diagram-guides.md` |
| 第 4 章 | 核心模块设计 | 技术架构师 | `@references/chapter-guides/ch4.md` + `@references/frontend-constraint.md` + `@references/backend-constraint.md` |
| 第 5 章 | 项目实施与交付计划 | 业务决策层 + 项目管理 | `@references/chapter-guides/ch5.md` |
| 附录 | 待确认事项与术语表 | 全部受众 | `@references/chapter-guides/appendix.md` |

生成每章时，参考 `@references/writing.md` 中对应的受众表达规范：
- 第 1、5 章、附录参考"一、受众表达规范-业务方"
- 第 2 章参考"一、受众表达规范-业务方" + "二、量化规范"
- 第 3、4 章参考"一、受众表达规范-技术架构师" + "三、论证结构规范" + "四、实现思路表达规范"

### Step 7 — 一致性自查
**输入**：Step 6 全部章节输出
**读取**：`@references/validation.md`
**动作**：执行 9 项跨章节检查 + 5 类自查清单，发现问题直接修正，不暴露自查过程。
**修正失败兜底**：如某项检查反复修正后仍不达标（例如功能模块覆盖不全且无法补充），在文档末尾"生成说明"中显式标注"未通过自查项: {项目} - 原因: {原因} - 建议人工补充方向: {方向}"，不强行掩盖。
**输出物**：完整 5 章 + 附录文档，文档末尾附"生成说明"段，标注所有默认假设、推断来源、未通过自查项。

---

## 内联快速判断表

以下规则直接在工作流中使用，无需读取外部文件。

### 【功能类型快速识别表】

| 关键词 / 特征 | 功能类型 | 技术含义 |
|---|---|---|
| 台账、档案、清单、维护、配置 | 数据管理类 | 标准 CRUD，重点在数据模型 |
| 申请、审批、工单、流程、驳回 | 流程审批类 | 状态机、通知、事务边界 |
| 统计、报表、看板、分析、导出 | 统计报表类 | 查询性能、数据权限、导出格式 |
| 用户、角色、权限、组织、登录 | 权限控制类 | RBAC、动态路由、Session 管理 |
| 对接、同步、推送、第三方 | 系统集成类 | 协议、容错、数据映射 |

### 【图形格式判断表】

| 图类型 | 输出格式 | 原因 |
|---|---|---|
| 功能架构图 | Markdown 表格 | 层次归属关系，表格更清晰 |
| 核心业务流程图 | Mermaid flowchart | 分支和流转必须用图形表达 |
| 系统架构图 | Mermaid 示意 + 组件表格 | 拓扑 Mermaid 近似，细节表格补充 |
| 技术架构图 | Markdown 表格 | 分层对应关系，表格更清晰 |

### 【域归并原则】

1. 按业务对象聚合，不按技术功能聚合
2. 系统管理域独立（用户、角色、组织、字典、日志）
3. 分析报表域独立（跨域的统计报表统一归入）
4. 每个域用一句话能说清楚"负责管理什么"
5. 依赖方向：系统管理域 ← 所有域依赖；分析报表域 → 依赖所有域（只读）

### 【受众判断规则】

| 章节 | 主要受众 | 表达策略 |
|---|---|---|
| 第 1、5 章、附录 | 业务决策层 | 业务语言，不出现技术术语 |
| 第 2 章 | 业务方 + 技术方 | 功能描述用业务语言，非功能需求用量化指标 |
| 第 3、4 章 | 技术架构师 | 技术语言，每个设计决策给出理由 |

混合受众场景：先给业务语言结论，再展开技术细节。

---

## 参考文档索引

| 文档 | 用途 | 由哪些 Step / 章节加载 |
|------|------|----------------------|
| `references/input-validation.md` | A/B/C 三类输入问题判定与处理 | Step 2 |
| `references/implicit-inference.md` | 按功能类型补全隐性需求 | Step 3 |
| `references/nfr-defaults.md` | 非功能需求按规模 + 行业的默认值 | Step 3（按需）|
| `references/complexity-detection.md` | 5 条复杂模块识别标准 + 输出格式 | Step 4 |
| `references/validation.md` | 跨章节一致性 9 项 + 5 类自查清单 | Step 7 |
| `references/writing.md` | 受众表达规范 + SCQA + 量化 + 三要素 | Step 6 各章节 |
| `references/chapter-guides/ch1.md` | 第 1 章结构与写作规则 | Step 6 第 1 章 |
| `references/chapter-guides/ch2.md` | 第 2 章结构与写作规则 | Step 6 第 2 章 |
| `references/chapter-guides/ch3.md` | 第 3 章结构与写作规则 | Step 6 第 3 章 |
| `references/chapter-guides/ch4.md` | 第 4 章结构与写作规则 | Step 6 第 4 章 |
| `references/chapter-guides/ch5.md` | 第 5 章结构与写作规则 | Step 6 第 5 章 |
| `references/chapter-guides/appendix.md` | 附录 A/B/C 生成规则 | Step 6 附录 |
| `references/frontend-constraint.md` | 前端 6 种标准页面模式 + 接口约定 + 能力边界 | Step 6 第 4 章 |
| `references/backend-constraint.md` | 分层职责 + 域边界 + 横切关注点 + 单体演进 | Step 6 第 3、4 章 |
| `references/middleware-constraints.md` | MySQL/ES/Redis/Quartz 的引入条件与边界 | Step 6 第 3 章 |
| `references/integration-patterns.md` | 外部系统集成模式（同步/异步/降级/对账）| Step 3 + Step 6 第 3、4 章（按需）|
| `references/diagram-guides.md` | 4 类图表生成规范 + Mermaid 语法 | Step 6 第 2、3 章 |