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 章中泄漏的技术术语
• 并行生成会导致依赖断裂、术语漂移、工期估算无依据

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

生成每章时，参考 @references/writing.md 中对应的受众表达规范：

• 第 1、5 章、附录参考"一、受众表达规范-业务方"
• 第 2 章参考"一、受众表达规范-业务方" + "二、量化规范"
• 第 3、4 章参考"一、受众表达规范-技术架构师" + "三、论证结构规范" + "四、实现思路表达规范"

Step 7 — 一致性自查

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

内联快速判断表

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

【功能类型快速识别表】

【图形格式判断表】

【域归并原则】

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

【受众判断规则】

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

参考文档索引