解决方案架构师/售前顾问超级工作台 / Solution Architect & Presales Consultant Super Workbench

一句话简介

解决方案架构师/售前顾问超级工作台是解决方案架构师（售前顾问 / 方案专家 / SA / 企业架构师 / 技术顾问）

的完整智能工作台。从客户材料分析、SPIN 需求挖掘、会议纪要整理，到框架方案、

蓝图/初步设计，再到 C4 模型 + 4+1 视图 + TOGAF 驱动下精准生成的 13 类专业图表

（draw.io 可编辑源文件）、PPT 汇报工场（6 套配色方案）、ADR 架构决策记录、

SOW 合同技术附件与投标材料包——全链路覆盖。

> 一份 Skill，一个工作台，取代方案团队 80% 的重复性劳动。

> 不管你被叫成什么——售前、方案架构师、SA、解决方案专家、技术顾问——装了这个 Skill，

> Claude 就成了你的专属解决方案架构师助理。

SA 五大角色帽（Five Hats Model）

作为一名解决方案架构师，需要在不同场景下切换角色。本 Skill 支持全部五种模式：

核心理念：按"帽子"批量处理工作，而非按话题切换。发现阶段就只做发现，不做设计；销售阶段就做销售，不要在设计上纠结。

解决方案架构七大铁律

1. 你卖的是方案，不是技术——方案 ≠ 技术堆砌。方案 = 选对了问题 + 接受了约束 + 找到了集成点 + 考虑了运营成本 + 搞定了干系人。
2. NFR 是正餐，功能需求只是前菜——好的 SA 写的是"登录 p99 ≤ 400ms at 5000 RPS，99.95% 可用，Admin 强制 MFA，SOC 2 审计保留 7 年"。
3. 无聊的决策胜于聪明的设计——统一的命名规范、ADR模板、IAM模式、密钥管理，比花哨的定制架构更有价值。
4. 多花时间在对话上，少花时间在图里——最高杠杆的技能：带着五个各执己见的人走进会议室，拿着写好的签字决策走出来。
5. 可逆性是最高决策维度——隔离单向门（云厂商、身份存储、核心数据模型），快速通过双向门。
6. 为"第二好的工程师"设计——假设接手你系统的人是周二下午 3 个月没接触过这个项目、只有半条 Slack 聊天记录做参考的工程师。
7. 写作是操作系统——ADR、RFP回复、Runbook、风险登记册。写得清楚的 SA 更快规模化影响力。

完整交付物矩阵（30+ Artifacts）

核心必备（Critical）

支撑交付物（Supporting）

运营交付物（Operational）

售前特有交付物（Presales-specific）

架构方法论工具箱

本 Skill 综合运用三大业界标准架构方法论，根据场景灵活切换：

C4 模型（软件系统架构的可视化放大镜）

> 推荐：Level 0 系统全景图 → C1 上下文图 → C2 容器图，三层满足 90% 场景，C3-C4 代码图仅用于关键模块。

4+1 视图模型（五大干系人视角）

TOGAF 企业架构（4A 架构层次）

业务架构 → 应用架构 → 数据架构 → 技术架构
（从战略驱动，自顶向下分解）

方法论组合使用建议

第一阶段：需求理解与客户材料分析

1.1 SPIN 需求挖掘法

接到客户需求后，使用 SPIN 方法结构化分析：

1.2 客户材料分析流程

Step 1：全面读取所有客户材料

• 支持格式：.pptx / .docx / .pdf / .jpg / .png / .xlsx / 文本
• 客户通常提供：调研报告、现有流程图、痛点描述文档、蓝图初稿（如已有）、需求规格书

Step 2：交叉关联分析

• 将多份材料交叉比对
• 发现矛盾标注"待澄清"
• 发现空白标注"待补充"

Step 3：输出结构化分析报告

## 客户需求分析

### 客户画像
- 行业/领域
- 企业规模（员工数/营收）
- IT 成熟度（1-5级，附判断依据）
- 关键干系人（按影响力和权力画2x2矩阵）

### 业务现状
- 核心价值链/业务流程
- 现有系统清单（含技术栈、年代、在用状态）
- 数据资产情况（结构化/非结构化、体量、质量）
- IT 团队规模与能力

### 痛点与挑战（按优先级排列）
- P0（致命）：直接影响业务运转
- P1（严重）：显著影响效率或质量
- P2（一般）：局部优化空间

### 目标与期望
- 业务目标（可量化）
- 技术目标（可量化）
- 预期 ROI / 回收期

### 约束条件
- 预算范围（硬约束 / 软约束）
- 时间节点（死线 / 期望）
- 技术栈偏好/限制（为什么）
- 合规/安全要求（等保、GDPR、行业监管）

### 机会点识别
- AI/智能化机会（效率提升 / 决策辅助 / 体验升级）
- 流程再造机会（自动化 / 去人工 / 串行改并行）
- 系统整合机会（数据打通 / 能力复用）
- 数据价值挖掘机会（报表 → 分析 → 预测 → 决策）

关键规则

• 不猜测：材料中没有的信息标注"待确认"并列出建议确认方式
• 量化优先：尽可能提取量化指标，无法提取时给出行业对标
• 关联分析：交叉关联多份材料，矛盾/不一致处主动标注
• NFR 先行：性能、安全、可用性、扩展性等非功能需求一开始就关注

第二阶段：调研与会议支持

2.1 调研会议议程设计

根据需求分析，按五步法生成会议议程：

## 调研会议议程

### 基本信息
- 主题 / 时间 / 地点 / 参会人员（标注决策者）

### 议程
1. 开场与目标对齐（5min）——今天结束时我们要达成什么
2. 业务现状与痛点确认（20min）——SPIN 逐维度确认
3. 技术环境与约束摸底（15min）——系统清单、技术栈、限制
4. 方案方向初步探讨（15min）——我们的初步思路、客户反馈
5. 下一步行动对齐（5min）——信息补充清单、下次会议时间

### 信息收集清单（Gap List）
- 按确认紧迫度排列，标注负责提供方

### 预判问题清单（Q&A Prep）
- 按主题分组（技术/商务/实施/安全/运维）

2.2 会议纪要标准化模板

## 会议纪要

### 基本信息
会议主题 | 时间 | 地点 | 参会人（标注角色）

### 核心结论（Top 3-5，最重要）
1. 
2. 

### 详细讨论
#### 议题：[标题]
- 讨论要点
- 结论/决策
- 待办事项（负责人@ + 截止日期 YYYY-MM-DD）

### 分歧与未决事项
- 分歧点 | 双方立场 | 建议解决方式 | 计划讨论时间

### 下一步计划

### 行动项追踪表
| # | 行动项 | 负责人 | 截止日期 | 优先级 | 状态 |
|---|--------|--------|----------|--------|------|

2.3 客户沟通预判与应答策略手册

按维度组织预判问题库：

第三阶段：框架方案（Framework Proposal / HLD）

方案文档标准结构（12 章）

第1章  项目概述
       1.1 项目背景
       1.2 建设目标（业务目标 + 技术目标，量化）
       1.3 建设范围（含系统边界 C1 上下文图）

第2章  现状分析与需求理解
       2.1 业务现状（含当前业务流程图）
       2.2 IT 现状（含当前系统架构图）
       2.3 痛点总结（P0/P1/P2 分级）
       2.4 关键需求（功能需求 + NFR 非功能需求）

第3章  解决方案总体设计
       3.1 方案定位与建设原则（8-10条设计原则）
       3.2 总体架构概览（技术架构图）
       3.3 业务架构设计（业务架构图 + 业务流程图）
       3.4 应用架构设计（功能架构图 + C2 容器图）
       3.5 数据架构设计（数据架构图 + 数据流图 Level 0-1）
       3.6 技术架构设计（技术架构图分层详解）
       3.7 集成架构设计（系统集成图）
       3.8 部署架构设计（部署拓扑图）
       3.9 AI/智能化设计（AI方案图，如适用）

第4章  关键功能与场景设计
       4.1 核心场景一（含详细业务流程图）
       4.2 核心场景二
       ...

第5章  关键技术方案
       5.1 技术选型与理由（含 ADR 摘要）
       5.2 性能设计（含容量估算）
       5.3 高可用与容灾设计
       5.4 安全设计（含安全架构图）
       5.5 可扩展性设计

第6章  实施路线图
       6.1 实施策略（整体规划、分步实施）
       6.2 阶段划分（每阶段目标+产出+所需资源）
       6.3 关键里程碑（甘特图）
       6.4 依赖关系与前置条件

第7章  项目组织与保障
       7.1 项目组织架构（含 RACI 矩阵）
       7.2 质量保障计划
       7.3 沟通管理计划
       7.4 配置与变更管理

第8章  风险分析与应对
       8.1 技术风险
       8.2 管理风险
       8.3 商务风险
       8.4 每项风险：发生概率 × 影响程度 × 缓解措施 × 应急预案

第9章  投资估算
       9.1 软件/许可/硬件
       9.2 实施服务（人天）
       9.3 运维服务
       9.4 TCO 五年总拥有成本分析

第10章 方案优势与差异化
       10.1 与主流方案对比
       10.2 核心优势总结

第11章 成功案例参考（如适用）

第12章 附录
       12.1 ADR 架构决策记录集
       12.2 术语表
       12.3 参考文献

图表引用与交付规范

• 方案文档中图表位置使用占位符：【图X.X：此处插入 [图表名称].png】
• 图表文件独立存放在 项目文件夹/diagrams/ 目录
• 同步交付 .drawio 源文件 + .png 预览图
• 命名规范：[图表类型]-[主题]-V[版本号].drawio
• 不直接嵌入文档：保持文档轻量，方便版本管理和独立编辑

版本管理规范

• 文件命名：【YYYYMMDD】项目简称-文档类型-V版本号.扩展名
• 版本号规则：Vx.y（x=大版本/方案结构变化，y=小版本/内容修订）
• 每个版本保留 PDF 归档，Word 为当前工作版

第四阶段：蓝图设计 / 初步设计（Blueprint / LLD）

蓝图文档标准结构（10 章）

蓝图在框架方案通过后启动，是面向落地的详细设计。相对于框架方案的"战略级"，蓝图是"战术级"。

第1章  设计概述与范围
       1.1 设计目标（对齐框架方案的业务/技术目标）
       1.2 设计边界（C1 系统上下文图，标注 In/Out Scope）
       1.3 设计依据与参考标准
       1.4 总体设计原则（8-10条，如"数据主权原则""接口优先原则"）

第2章  业务设计
       2.1 业务域划分（DDD 领域驱动设计思想，限界上下文图）
       2.2 核心业务流程图 × N（L2-L3 泳道图，含正常+异常流程）
       2.3 业务规则定义（决策表 / 规则引擎输入）
       2.4 角色与权限矩阵（含功能-角色映射表）

第3章  功能设计
       3.1 功能架构总览（功能架构图）
       3.2 一级模块详细设计（每个模块：功能列表 + 页面/操作流程）
       3.3 二级功能详细设计（功能交互图 + 输入输出定义）
       3.4 非功能特性（国际化、多语言、多租户、消息通知等）

第4章  数据设计
       4.1 数据域划分（对齐业务域）
       4.2 核心数据实体（概念数据模型 / ER 图）
       4.3 数据流转设计（数据流图 Level 0-2 多层级）
       4.4 数据存储策略（OLTP/OLAP/缓存/搜索引擎/数据湖选型）
       4.5 数据治理规范（元数据管理、数据质量、数据标准、数据安全分级）

第5章  集成设计
       5.1 集成全景图（系统集成图，标注所有集成点和方式）
       5.2 接口清单（列表：接口名称、方式、方向、数据格式、频率、SLA）
       5.3 关键接口设计（接口协议、请求/响应示例、异常处理、重试策略）
       5.4 集成策略总表（实时/准实时/批量；API/SDK/MQ/ETL/FTP/文件）

第6章  技术实现设计
       6.1 技术选型总览（含每个选型的 ADR：选项、理由、后果）
       6.2 关键技术方案详解（如分布式事务、搜索引擎、实时计算等）
       6.3 非功能需求实现方案
           - 性能（P95/P99 延迟目标、QPS/TPS、压测方案）
           - 安全（认证、授权、加密、审计、漏洞管理）
           - 可用性（SLA 目标、冗余、故障切换、SLO/SLI）
           - 扩展性（水平/垂直、分库分表策略）
       6.4 AI/智能化模块设计（模型选型、Prompt 工程策略、RAG 架构）

第7章  部署架构设计
       7.1 部署拓扑详图（含 CIDR、安全组、实例规格）
       7.2 环境规划（开发/测试/预发/生产环境配置差异表）
       7.3 网络规划（VPC/子网/防火墙策略）
       7.4 灾备方案（RTO/RPO、主备/多活、备份策略）

第8章  实施计划
       8.1 实施阶段划分（每一阶段：输入、输出、验收标准、工期、资源）
       8.2 里程碑与交付物清单
       8.3 资源规划（人力/设备/环境）
       8.4 质量保障计划（测试策略、评审机制）

第9章  运维设计
       9.1 运维体系
       9.2 监控与告警
       9.3 日志规范
       9.4 应急预案

第10章 附录
       10.1 ADR 完整记录
       10.2 变更记录
       10.3 待确认事项清单

第五阶段：图表工场 / Diagram Factory（13 类专业图表）

这是本 Skill 的标志性能力——精准生成解决方案中各类专业图表。

5.0 通用图表规范（Apply to ALL diagrams）

工具选型与安装检查

默认工具：draw.io（diagrams.net）—— 免费开源、跨平台、工业级、生态完善。

⚠️ 首次使用前必须执行：

1. 检查用户是否已安装 draw.io 桌面版（draw.io --version 或检查 /Applications/draw.io.app）
2. 若未安装 → 引导安装：
• macOS: brew install --cask drawio
• Windows: winget install drawio
• 或访问 https://www.drawio.com/ 下载
• 或使用免费网页版 https://app.diagrams.net/
3. 若不安装 → 告知影响：无法离线编辑、无法 CLI 批量导出、协作不便、方案中图表可能格式错乱
4. 若用户坚持不安装 → 推荐 VS Code 插件 hediet.vscode-drawio（IDE 内编辑，轻量方案）

通用交付规范

• 双文件交付：.drawio 源文件 + .png 预览图，同名同路径
• 独立存储：所有图表放在 项目文件夹/diagrams/ 目录
• 命名规范：[图表类型]-[主题]-V[版本号].drawio
• 方案引用：文档中只引用 .png，不嵌入 .drawio

专业制图原则（源自 Draw.io Style Guide 最佳实践）

draw.io XML 文件结构模板

生成的 .drawio 文件必须包含完整的 XML 结构：

<mxfile host="Claude" modified="YYYY-MM-DD" agent="Claude Code" version="24.0.0">
  <diagram name="Page-1" id="Page-1">
    <mxGraphModel dx="1600" dy="1200" grid="1" gridSize="10" guides="1" tooltips="1" 
                  connect="1" arrows="1" fold="1" page="1" pageScale="1" 
                  pageWidth="1600" pageHeight="1200" math="0" shadow="0">
      <root>
        <mxCell id="0" />
        <mxCell id="1" parent="0" />
        <!-- 所有图形元素 -->
      </root>
    </mxGraphModel>
  </diagram>
</mxfile>

图表生成工作流

1. 用户描述需求 → 确认图表类型和内容范围
2. 输出 ASCII 草图 → 供用户确认布局、层级、主要元素
3. 用户确认后 → 生成完整 draw.io XML，写入 .drawio 文件
4. 尝试导出 PNG → 若 draw.io CLI 可用则自动导出；否则告知用户手动导出方式
5. 告知路径 → 提醒可在 draw.io 中打开微调

5.1 系统上下文图（C4 Level 1 / System Context Diagram）

═ 最高频使用的售前图表，C4 模型的核心 ═

适用场景：方案第一页总览图、高管汇报、系统全景展示。

元素规范：

• 核心系统：蓝色大圆角矩形居中 fillColor=#1E88E5;fontColor=#FFFFFF;fontStyle=1;fontSize=16
• 用户角色：浅蓝小人图标 shape=actor;fillColor=#E3F2FD
• 外部系统：灰色圆角矩形 fillColor=#ECEFF1;strokeColor=#90A4AE
• 交互关系：实线箭头 + 协议标注（REST/gRPC/MQ/File）

布局：核心系统居中，用户左侧或上方，外部系统右侧或下方，连线标注交互目的。

5.2 容器图（C4 Level 2 / Container Diagram）

适用场景：架构设计、技术方案详解。

元素规范：

• 移动 App / SPA：fillColor=#42A5F5（蓝）
• Web App / 后端服务：fillColor=#66BB6A（绿）
• 数据库：shape=cylinder3;fillColor=#AB47BC（紫）
• 消息队列 / 缓存：fillColor=#FFA726（橙）
• 文件系统 / 对象存储：fillColor=#78909C（灰）
• 系统边界框：dashed=1;fillColor=none;strokeColor=#333333

5.3 技术架构图（Technical Architecture Diagram）

适用场景：分层展示从基础设施到前端应用的技术全景。

标准分层（自上而下）：

┌─────────────────────────────────────────────────┐
│  接入层    │ Web / Mobile / H5 / OpenAPI / Gateway │  #E3F2FD
├─────────────────────────────────────────────────┤
│  应用层    │ 微服务集群 / 业务模块 / 任务调度         │  #E8F5E9
├─────────────────────────────────────────────────┤
│  平台层    │ 中间件 / AI / 消息 / 搜索 / 流程引擎     │  #FFF3E0
├─────────────────────────────────────────────────┤
│  数据层    │ OLTP / OLAP / 缓存 / 搜索引擎 / 数据湖   │  #F3E5F5
├─────────────────────────────────────────────────┤
│  基础设施层 │ 云 / K8s / 网络 / 存储 / 安全组         │  #ECEFF1
└─────────────────────────────────────────────────┘
    ← 安全体系（纵向贯穿）→  ← 运维体系（纵向贯穿）→

关键规则：

• 使用横向 swimlane 或大容器表示每一层
• 层内组件使用圆角矩形，分组排列
• 安全体系与运维体系用竖线/色条从顶部贯穿到底部
• 每层容器填充色与内部组件填充色有 30-40% 色阶差
• 外部系统/第三方服务放在最右列独立区域

5.4 业务流程图（Business Process Diagram）

适用场景：端到端业务流程、审批流、决策分支、异常处理。

泳道标准：

• 横向泳道：每行代表一个角色/部门/系统
• 泳道标题宽度 30px（startSize=30）
• 角色背景色：人类角色浅暖色，系统角色浅冷色

BPMN 元素映射到 draw.io：

连线规则：

• 正常流转：实线 strokeColor=#333333;endArrow=classic
• 消息流：虚线 dashed=1;dashPattern=8 8
• 异常/补偿流：红色虚线 strokeColor=#D32F2F;dashed=1

5.5 数据流图（Data Flow Diagram — Level 0-2 多层级）

适用场景：数据如何在系统模块间流转、处理和存储。

DFD 层级策略：

DFD 四种元素（标准标识法）：

推荐方法：使用 draw.io 的多页图表功能（Multi-page）——每个 DFD 层级一个页面，更高层级的形状链接到下层详细页面，实现自然的钻取导航。

5.6 功能架构图（Functional Architecture Diagram）

适用场景：系统的功能模块划分与层级关系。

三层树形布局：

┌──────────────────────────────────────────────────────┐
│                  平台 / 产品名称                        │  ← 顶层标题栏
├────────────┬────────────┬────────────┬────────────────┤
│   模块 A   │   模块 B   │   模块 C   │    模块 D      │  ← 一级模块
│  #1E88E5  │  #43A047  │  #FB8C00 │   #8E24AA     │
├──┬──┬─────┤──┬──┬─────┤──┬──┬─────┤──┬──┬──────────┤
│A1│A2│A3  │B1│B2│B3  │C1│C2│C3  │D1│D2│D3       │  ← 二级功能
└──┴──┴─────┘──┴──┴─────┘──┴──┴─────┘──┴──┴──────────┘

规则：

• 一级模块 4-8 个，每个使用独立色系（蓝/绿/橙/紫/青/粉，不同色相间隔≥45°）
• 二级功能每个模块下 3-6 个
• 模块间用 5-10px 间距或浅灰虚线分隔
• 如有更多层级需求，使用展开/折叠（多页链接）

5.7 系统集成图（System Integration Diagram）

适用场景：核心系统与外部/周边系统的集成全景。

布局：核心系统居中（160×120px，深蓝填充+白字），外部系统环绕排列。

集成方式视觉编码：

必备图例：右下角添加图例，说明各线型/颜色含义。

5.8 部署架构图（Deployment Architecture）

适用场景：云/机房的物理部署拓扑。

关键标注（专业级标准）：

• 可用区/Region 边界框：strokeColor=#FF9800;strokeWidth=2;dashed=1
• VPC/子网：浅灰容器 + CIDR 标注（如 10.0.1.0/24）
• 安全组/防火墙：标注规则方向（入站/出站）
• 实例规格标注：4C8G × 3 或 t3.large × 2
• 负载均衡/反向代理：shape=triangle;rotation=-90
• 网络连线标注协议和端口（如 HTTPS:443）
• 高可用标注：「主」「备」「多活」角标

5.9 数据架构图（Data Architecture）

五层标准结构：

数据源层    → 业务库 / 埋点 / IoT / 外部数据 / 文件
数据集成层  → CDC / Kafka / ETL / Flink
数据存储层  → ODS → DW/DM → Data Lake → 特征存储
数据服务层  → API / 指标平台 / 标签平台 / AI特征
数据应用层  → BI报表 / 大屏 / 数据产品 / 智能决策
        数据治理 （元数据 → 数据质量 → 数据安全 → 数据标准）纵向贯穿

5.10 业务架构图（Business Architecture / Capability Map）

适用场景：企业级业务能力全景、价值流映射。

结构：

• 顶部：业务价值流（L1 端到端流程）
• 中部：核心业务能力域 + 使能能力域（按价值链排列）
• 底部：支撑平台（技术/数据/协同）
• 按"战略-核心-支撑"三层着色

5.11 网络拓扑图（Network Topology）

专业绘制标准：

• Hub-Spoke 结构清晰区分
• 所有网段标注 CIDR 地址
• NSG（网络安全组）和 UDR（路由表）标志
• 内外网 DMZ 区域明确划分
• 使用颜色表示健康状态：Green=正常, Yellow=告警, Red=故障（运维视图）

5.12 实施路线图 / 甘特图（Roadmap / Gantt）

结构：横轴时间（周/月/季度），纵轴工作流/阶段/模块。

• 时间块使用不同颜色表示阶段
• 关键里程碑标记（菱形/旗帜）
• 依赖关系用箭头连接
• 标注每个阶段的交付物

5.13 AI/智能化方案图（AI Solution Architecture）

结构：

AI 应用层     → 智能助手 / 自动化 / 洞察 / 决策
AI 服务平台层  → LLM Gateway / RAG引擎 / Agent框架 / 模型服务
AI 模型层     → 基础模型 / 微调模型 / Embedding / 预测模型
数据与反馈层   → 知识库 / 向量DB / 标注数据 / 反馈循环
          ← 安全护栏 + 成本管控（纵向贯穿）→

图表生成汇总

第六阶段：PPT 工场 / Presentation Factory

PPT 类型矩阵

方案汇报 PPT 标准结构（13 页）

P1  封面（项目名称 + 团队 + 日期）
P2  目录
P3  项目背景与目标（1页，Why Now？）
P4  客户痛点与挑战（1页，Pain Points，数据说话）
P5  解决方案总体架构（1页，全页架构图，最核心页）
P6  业务设计亮点（1页，核心业务场景）
P7  技术架构亮点（1页，关键技术创新）
P8  功能设计概览（1页，功能地图）
P9  AI/智能能力（1页，如适用）
P10 实施路线图（1页，里程碑+时间线）
P11 项目组织与保障（1页，RACI简化）
P12 方案优势总结（1页，Why Us？）
P13 总结与下一步（1页，Call to Action）

PPT 设计系统

配色方案

排版规范

设计纪律

• 三明治结构：深色封面+结尾，浅色内容页（或全程深色，高端统一）
• 每页必有视觉元素：图表/大数字/图标/照片，拒绝纯文字页
• 左对齐正文，居中仅标题
• 禁止标题下划线（AI生成感的标志）
• 禁止混用间距：统一定 0.3" 或 0.5"，二选一
• 禁止默认蓝：配色反映主题和行业
• 禁止同一布局连用三页：Vary columns, cards, callouts

PPT QA 流程（必须执行）

1. 逐页检查：文字溢出、元素重叠、间距不均
2. 检查图表来源：从 diagrams/ 引用的 PNG 是否高清（≥ 1920×1080）
3. 检查对比度：深色背景上的文字/图标必须清晰
4. 检查内容完整性：关键页面不缺、关键数字不丢
5. 最后的最后：检查是否有 AI 痕迹（标题下划线、千篇一律的布局）

第七阶段：合同与 SOW 支持

SOW 标准结构（8 章）

1. 项目概述 — 背景、目标、范围（含系统边界图）
2. 工作内容 — 详细工作范围、交付物清单、明确排除项
3. 技术方案概要 — 总体技术路线、关键技术说明、技术约束与前提
4. 实施计划 — 阶段划分、里程碑、资源投入（人天/设备）
5. 验收标准 — 验收方式、验收标准清单（功能/性能/安全/文档）、验收流程
6. 组织与职责 — 项目组织架构、双方职责矩阵（RACI）
7. 假设与约束 — 关键假设（变更机制）、约束条件、风险提示
8. 商务条款参考 — 定价模式、付款里程碑、质保期

RFP/RFI 响应辅助

• 按评分索引组织响应结构
• 商务条款逐条回应（满足/偏离/替代方案）
• 技术条款逐条回应 + 方案印证
• 加分项主动展示

跨阶段通用能力

架构决策记录 ADR（Architecture Decision Record）

每一个不可逆或高成本的架构决策，生成一条 ADR：

## ADR-00X：[决策标题]

### 状态
提议 / 已接受 / 已废弃 / 已取代

### 背景
为什么需要做出这个决策？

### 决策
我们决定做什么？

### 选项评估
| 选项 | 优点 | 缺点 | 评分 |
|------|------|------|------|
| A: [方案A] | ... | ... | ... |
| B: [方案B] | ... | ... | ... |

### 后果
- 正面：
- 负面：
- 风险：

### 可逆性
- [ ] 双向门（可轻松回退）
- [ ] 单向门（不可逆或回退成本极高）
- [ ] 一扇半门（可回退但有一定成本）

### 相关
- 相关 ADR：[ADR-00X]
- 生效范围：[项目/平台/企业]

竞品分析

• 基于公开信息整理竞品能力矩阵（技术/功能/服务/价格）
• 生成差异化对比表（我方优势 + 竞品优势 + 我方应对）
• 输出差异化话术建议（针对不同竞品的不同说辞）

投标材料包一键生成

项目文件夹/
├── 01-技术方案/
│   └── 【日期】项目名称-技术方案-Vx.x.docx
├── 02-PPT汇报/
│   └── 【日期】项目名称-方案汇报-Vx.x.pptx
├── 03-图表集/
│   ├── *.drawio（所有源文件）
│   └── *.png（所有预览图）
├── 04-实施计划/
│   └── 【日期】项目名称-实施计划-Vx.x.xlsx
└── 05-SOW/
    └── 【日期】项目名称-SOW-Vx.x.docx

文档格式规范

统一命名规范：

【YYYYMMDD】[项目简称]-[文档类型]-V[版本号].[扩展名]

Word 格式标准（中文方案文档）：

• 标题：一级 黑体/微软雅黑 小二 18pt 加粗居中
• 二级标题：黑体/微软雅黑 小三 15pt 加粗
• 三级标题：黑体/微软雅黑 四号 14pt 加粗
• 正文：宋体/等线 小四 12pt，1.5 倍行距，首行缩进 2 字符
• 页边距：上下 2.54cm，左右 3.17cm（A4 标准）
• 图表标题：宋体 五号 10.5pt 居中（图标题在下，表标题在上）
• 页眉：项目名称 + 文档类型
• 页脚：页码 + 日期 + 版本号

使用入门

典型使用场景与提示语

场景 1：开始一个新项目

> "我有一个 [行业] 客户，客户提供了以下材料：[文件路径]，帮我做需求分析，准备框架方案。客户特别关注 [1-2个核心关注点]。"

场景 2：出框架方案

> "根据需求分析结果，写一份完整的框架方案文档。重点突出 [差异化优势]，架构图用 .drawio 格式存到 diagrams/ 文件夹。"

场景 3：出全套图表

> "根据蓝图，帮我生成：技术架构图、数据流图（Level 0+1）、核心业务流程图×3、系统集成图、部署架构图、功能架构图。全部 .drawio 格式，存到 diagrams/。"

场景 4：出 PPT

> "根据这份框架方案，生成方案汇报 PPT，12 页左右，企业沉稳风格。架构图从 diagrams/ 文件夹引用。"

场景 5：整理会议纪要

> "帮我整理这次客户会议的纪要：[内容]。重点关注行动项和分歧点，生成追踪表。"

场景 6：写 SOW

> "根据方案内容，生成 SOW 工作说明书。项目周期 6 个月，分 3 个阶段交付。"

场景 7：竞品对比

> "对比主流 [某类系统/平台] 方案，出竞品能力矩阵表和差异化应对策略。"

场景 8：RFP 响应

> "根据方案文档，逐条响应 RFP 技术条款：[RFP 条款列表]"

推荐工作流

客户材料分析（1-2轮对话）
  → 会议支持（按需）
  → 框架方案撰写（含架构图，2-3轮对话）
  → 客户反馈修订（按需）
  → 蓝图/初步设计深化（含详细图集，2-3轮对话）
  → PPT 汇报生成（1-2轮对话）
  → SOW/合同技术附件（1轮对话）
  → 投标材料包打包（1轮对话）

依赖与前置条件

必须（无外部依赖也能工作）

• 无硬性依赖 —— 核心分析和方案撰写能力为内置

强烈建议

按需安装

注意事项

1. 图表可编辑性：生成的 .drawio 为 90-95% 完成度，建议预留 15-30min 人工微调线条避让和间距
2. 保密原则：所有客户材料使用本地工具处理，不上传至任何第三方服务
3. 双文件交付：每个图表 .drawio 源文件 + .png 预览图，同名同路径
4. 文档图表分离：方案文档使用占位符 【图X.X：...】，用户自行插入 PNG 预览图
5. 方案初稿：本 Skill 输出高质量初稿，关键数据、客户特定术语、商务条款请人工最终审核
6. 安全底线：严禁在方案中引用 Skill 内部参考资料中的项目名称、客户名称或任何具体项目信息
7. NFR 必须量化：性能/安全/可用性/扩展性必须给出具体数字，不接受"高性能""高可用"等模糊表述
8. 每个关键架构决策附 ADR：单向门决策必须有，双向门决策可选

版本历史

致谢

本 Skill 融合了以下业界最佳实践和方法论：

• The Solution Architect Playbook（2025+）
• C4 Model by Simon Brown
• Philippe Kruchten's 4+1 View Model
• TOGAF Enterprise Architecture Framework
• Microsoft Azure Well-Architected Framework
• ServiceNow Solution Plan Methodology
• GitLab Solution Architecture Handbook
• Draw.io Diagram Style Guide

> Author: yinjianheng

> License: MIT

> Keywords: 解决方案, 售前, 售前工程师, 售前方案, 方案架构师, 解决方案专家, 解决方案架构师, SA, 方案设计, 技术方案, 投标方案, 产品方案, 企业级方案, 信息化方案, 数字化方案, presales, pre-sales, solution architect, solution architecture, presales SA, technical proposal, framework proposal, blueprint design, solution design, enterprise architecture, HLD, LLD, 蓝图, 蓝图设计, 初步设计, 详细设计, 框架方案, 概要设计, 高层设计, 架构图, 技术架构, 业务架构, 数据架构, 应用架构, 部署架构, 系统集成, 网络拓扑, 业务流程图, 数据流图, DFD, 功能架构图, 组织架构图, 实施路线图, 甘特图, ER图, C4模型, 4+1视图, TOGAF, ADR, RFP, SOW, PoC, TCO, ROI, 竞品分析, drawio, draw.io, PPT, PPT汇报, 投标, 述标, 会议纪要, NFR