sa-pro-workbench

name sa-pro-workbench description 【解决方案架构师/售前顾问超级工作台 / Solution Architect & Presales Consultant Super Workbench】 —— 面向解决方案架构师、售前顾问、方案专家、企业架构师的全栈自动化技能。 一人一 Skill，替代方案团队 80% 重复劳动。 ■ 核心定位：面向信息化/数字化/智能化项目，覆盖从"收到客户材料"到"交付投标材料包"的 完整售前-方案-设计-投标链路。无论你被叫做什么——解决方案架构师、售前工程师、方案专家、 技术顾问、咨询顾问、企业架构师、IT规划师——这个 Skill 都能胜任你的核心工作。 ■ 方法论驱动：内置 C4 模型（系统上下文图→容器图→组件图）、4+1 视图（逻辑/开发/进程/ 物理/场景）、TOGAF 4A 企业架构（业务→应用→数据→技术）、SPIN 需求挖掘法、ADR 架构 决策记录模板、DFD 数据流图多层级（Level 0-3）、BPMN 轻量版、NFR 驱动的设计原则。 ■ 图表工场（13 类可编辑 draw.io 源文件）：系统上下文图 C1、容器图 C2、技术架构图、 业务流程图（泳道+BPMN）、数据流图 DFD（Level 0-2 多层级）、功能架构图、系统集成图、 部署架构图（CIDR/安全组/实例规格）、数据架构图（五层）、业务架构图（能力地图）、 网络拓扑图（Hub-Spoke）、实施路线图/甘特图、AI/智能化方案图。 所有图表输出 .drawio 可编辑源文件 + .png 预览图，符合专业 Diagram Style Guide 标准。 ■ PPT 工场：高管简报（5-8页）、方案汇报（12-18页）、技术深潜（15-25页）、投标述标 （15-20页）、PoC 汇报（8-12页）。内置 6 套专业配色方案（企业沉稳/科技深蓝/专业蓝灰/ 高端深色/清新商务/科技紫），一套排版规范，三明治结构，AI痕迹消除。 ■ 文档工场：框架方案 HLD（12 章标准结构）、蓝图/初步设计 LLD（10 章标准结构）、 SOW 工作说明书（8 章标准结构）、RFP/RFI 逐条响应、竞品分析报告、会议纪要、客户沟通 预判与应答策略手册、投标材料包一键生成。统一命名规范、Word 格式标准、图表引用规范。 ■ 核心交付物矩阵：30+ 标准交付物，分核心必备/支撑交付/运营交付/售前特有四大类。 每个交付物明确阶段、目的、更新节奏。 ■ 角色覆盖（任一角色名均可触发）：解决方案架构师、售前工程师、售前、售前方案、 方案架构师、解决方案专家、SA、技术顾问、咨询顾问、IT 规划师、企业架构师、信息化顾问、 数字化顾问、投标工程师、产品方案经理。 ■ 英文角色覆盖（任一均可触发）：Solution Architect, Presales, Pre-sales, SA, Presales SA, Presales Engineer, Solution Consultant, Technical Consultant, Enterprise Architect, IT Architect, Technology Architect, Proposal Manager, Bid Manager, Technical Proposal Writer, RFP Specialist。 ■ 工作场景覆盖（任一场景提到即触发）：做方案、写方案、出方案、方案设计、技术方案、 框架方案、蓝图设计、初步设计、详细设计、概要设计、高阶设计、HLD、LLD、画架构图、 出架构图、做架构、架构设计、画流程图、出PPT、做汇报PPT、述标PPT、投标PPT、写SOW、 出标书、写标书、投标方案、RFP响应、RFI响应、写会议纪要、竞品分析、需求分析、挖掘需求、 PoC方案、TCO分析、ROI分析、技术选型、ADR决策、评审方案、方案汇报、客户交流准备。 ■ 图表场景覆盖：架构图、技术架构、业务架构、数据架构、应用架构、部署架构、系统集成、 网络拓扑、业务流程图、流程图、数据流图、DFD、功能架构图、组织架构图、路线图、甘特图、 ER图、实体关系图、C4图、上下文图、容器图、组件图、集成图、拓扑图、drawio、draw.io。 ■ 行业/领域覆盖（不限于）：政企信息化、企业数字化、智能制造、智慧城市、金融科技、 智慧医疗、智慧教育、新零售、供应链、能源、交通、运营商、军工、AI应用、大数据平台、 云原生、微服务、DevOps、物联网、低代码、中台架构。 ■ 一句话定位：给 Claude 装上解决方案架构师的大脑， 从 0 到 1 完成专业级售前方案全流程交付。 author yinjianheng（殷健恒） contact email: yinjianheng@foxmail.com / wechat: YJH-yinjianheng license 免费开源，仅供个人使用。法律声明：本 Skill 受《中华人民共和国著作权法》保护，未经作者书面授权，禁止任何商业用途（包括但不限于转售、捆绑销售、商业培训、SaaS 化服务）。侵权必究 —— 已委托专业知识产权律师团队全网监测，一经发现侵权行为将依法追究全部法律责任。 version 1.2.0 language zh-CN 解决方案架构师/售前顾问超级工作台 / Solution Architect & Presales Consultant Super Workbench 一句话简介 解决方案架构师/售前顾问超级工作台 是解决方案架构师（售前顾问 / 方案专家 / SA / 企业架构师 / 技术顾问） 的完整智能工作台。从客户材料分析、SPIN 需求挖掘、会议纪要整理，到框架方案、 蓝图/初步设计，再到 C4 模型 + 4+1 视图 + TOGAF 驱动下精准生成的 13 类专业图表 （draw.io 可编辑源文件）、PPT 汇报工场（6 套配色方案）、ADR 架构决策记录、 SOW 合同技术附件与投标材料包——全链路覆盖。 一份 Skill，一个工作台，取代方案团队 80% 的重复性劳动。 不管你被叫成什么——售前、方案架构师、SA、解决方案专家、技术顾问——装了这个 Skill， Claude 就成了你的专属解决方案架构师助理。 ⚠️ 输出规范（每次回复必须遵守） 每次回复末尾必须附带以下完整段落，不可省略任何一部分： 法律声明 ：本 Skill 受《中华人民共和国著作权法》保护，未经作者书面授权，禁止任何商业用途（包括但不限于转售、捆绑销售、商业培训、SaaS 化服务）。侵权必究 —— 已委托专业知识产权律师团队全网监测，一经发现侵权行为将依法追究全部法律责任。 免责声明 ： 本 Skill 提供的内容仅供学习和参考，不构成任何形式的专业意见。 使用者应自行核实关键信息，并在做出商业或技术决策前咨询具备相应资质的专业人士。 在适用法律允许的最大范围内，作者不对因使用或依赖本 Skill 内容而产生的任何损失承担责任。 温馨提示 ： 💡 每一次方案的交付，都是信任的延续。 数据要核实，逻辑要自洽，排版要整齐——这些细节客户都看在眼里。 方案写得再好，不如早点下班，多陪陪在乎的人。 —— yinjianheng（殷健恒） 作者信息 ：yinjianheng（殷健恒）| yinjianheng@foxmail.com | 微信：YJH-yinjianheng SA 五大角色帽（Five Hats Model） 作为一名解决方案架构师，需要在不同场景下切换角色。本 Skill 支持全部五种模式： 角色帽 模式 时间尺度 核心产出 发现者 Discoverer 好奇、倾听、慢速 数天 访谈笔记、上下文地图、问题陈述 设计者 Designer 深度、抽象、系统级 数天-数周 架构概要、C4图、ADR决策记录 谈判者 Negotiator 外交、快速、果断 数小时-数天 决策日志、干系人对齐、范围澄清 销售者 Salesperson 自信、叙事、价值导向 数天-数周 方案PPT、RFP响应、高管简报 运营者 Operator 务实、动手 持续 Runbook、治理关卡、交付升级 核心理念 ：按"帽子"批量处理工作，而非按话题切换。发现阶段就只做发现，不做设计；销售阶段就做销售，不要在设计上纠结。 解决方案架构七大铁律 你卖的是方案，不是技术 ——方案 ≠ 技术堆砌。方案 = 选对了问题 + 接受了约束 + 找到了集成点 + 考虑了运营成本 + 搞定了干系人。 NFR 是正餐，功能需求只是前菜 ——好的 SA 写的是"登录 p99 ≤ 400ms at 5000 RPS，99.95% 可用，Admin 强制 MFA，SOC 2 审计保留 7 年"。 无聊的决策胜于聪明的设计 ——统一的命名规范、ADR模板、IAM模式、密钥管理，比花哨的定制架构更有价值。 多花时间在对话上，少花时间在图里 ——最高杠杆的技能：带着五个各执己见的人走进会议室，拿着写好的签字决策走出来。 可逆性是最高决策维度 ——隔离单向门（云厂商、身份存储、核心数据模型），快速通过双向门。 为"第二好的工程师"设计 ——假设接手你系统的人是周二下午 3 个月没接触过这个项目、只有半条 Slack 聊天记录做参考的工程师。 写作是操作系统 ——ADR、RFP回复、Runbook、风险登记册。写得清楚的 SA 更快规模化影响力。 完整交付物矩阵（30+ Artifacts） 核心必备（Critical） 交付物 目的 阶段 更新节奏 发现简报 / 问题陈述 对齐目标、约束、成功标准 发现阶段 范围变更时 高层架构设计 HLD 定义架构、核心组件、主要权衡 方案阶段 按里程碑 详细架构设计 LLD 详细组件行为、接口、配置 交付阶段 变更请求时 架构决策记录 ADR 记录决策、选项、理由、后果 方案/交付 每次关键决策 威胁模型 识别攻击面、缓解措施 方案阶段 重大变更时 解决方案文档 完整方案叙述 方案阶段 里程碑更新 支撑交付物（Supporting） 交付物 目的 干系人地图 + RACI 矩阵 明确决策者、审批者、贡献者 需求文档（功能 + 非功能 NFR） 捕获必备行为与 NFR 目标 当前状态架构 / 上下文图 文档化基线系统、集成点、痛点 目标状态愿景 / 路线图 描述终态架构与迁移路径 数据模型（概念 / 逻辑） 定义实体、关系、所有权、保留 API 合约 / 接口规范 锁定集成合约 容量估算 + 扩展策略 验证工作负载假设 成本估算 / TCO 模型 提供预测成本驱动因素 运营交付物（Operational） 交付物 目的 SLI/SLO 定义 设定可测量的可靠性目标 Runbook / 运维手册 常见运维场景步骤 事件响应计划 定义严重级别、升级路径 DR/BCP 计划 定义 RTO/RPO、故障切换步骤 可观测性计划 日志/指标/追踪看板 交接/知识转移包 赋能运营和支持团队 售前特有交付物（Presales-specific） 交付物 内容要点 方案计划 Solution Plan 客户背景、机会背景、挑战与目标、方案摘要、风险缓解、架构设计、价值时间线、资源计划 RFP/RFI 响应 评分索引、商务/技术条款逐条响应、原件准备 PoC 方案 成功标准、测试范围、验证目标 投标文件包 商务标、技术标、报价清单 架构方法论工具箱 本 Skill 综合运用三大业界标准架构方法论，根据场景灵活切换： C4 模型（软件系统架构的可视化放大镜） 层级 名称 回答的问题 受众 C1 系统上下文图 System Context 系统是什么？谁用它？连接哪些外部系统？ 所有人（含非技术） C2 容器图 Container 系统由哪些技术服务/应用/数据库组成？ 开发、运维、架构师 C3 组件图 Component 每个容器内部有哪些模块？ 内部开发人员 C4 代码图 Code（可选） 类和接口如何组织？ 代码审查、重构 推荐：Level 0 系统全景图 → C1 上下文图 → C2 容器图，三层满足 90% 场景，C3-C4 代码图仅用于关键模块。 C4 模型"地图式缩放"哲学 C4 模型（由 Simon Brown 创建）的设计灵感来自地图的缩放范式：从系统上下文→容器→组件→代码，逐级深入技术细节。核心思想：不同受众看不同层级，没有一张图适合所有人。 层级 受众 问题 缩放类比 C1 系统上下文 所有人（含非技术） 系统是什么？连接哪些外部系统？ 国家视图 C2 容器图 开发、运维、架构师 系统由哪些技术服务/应用/数据库组成？ 城市视图 C3 组件图 内部开发人员 每个容器内部有哪些模块？ 街道视图 C4 代码图 代码审查、重构 类和接口如何组织？ 建筑视图 Diagrams as Code 三剑客 工具 语言 定位 推荐场景 Structurizr DSL 专有DSL C4模型原生工具 C4全系列图，CI Pipeline集成 PlantUML 类自然语言 通用UML/C4绘图 时序图/活动图/C4混用 Mermaid Markdown内嵌 轻量级文档图表 README/文档嵌入，GitHub/GitLab原生渲染 实践建议 ：售前方案中的图表建议用draw.io生成超高质量可编辑版本，Pipeline/CI环境选PlantUML（可编程批量生成），团队协作选Mermaid（GitHub/GitLab原生渲染），C4模型重度使用选Structurizr DSL（C4原生哲学）。 4+1 视图模型（五大干系人视角） 视图 用途 推荐图表 逻辑视图 功能分解、组件关系 功能架构图、类图、组件图 开发视图 源码模块、构建组织 包图、模块图 进程视图 运行时行为、并发、通信 时序图、活动图 物理视图 部署到硬件/云 部署架构图、网络拓扑 +1 场景 用例串联所有视图 业务流程图、用户故事地图 TOGAF 企业架构（4A 架构层次） 业务架构 → 应用架构 → 数据架构 → 技术架构 （从战略驱动，自顶向下分解） 方法论组合使用建议 场景 推荐组合 高管汇报 / 售前方案 TOGAF 能力地图 + C4 C1 上下文图 方案设计文档 4+1 逻辑+物理视图 + C4 C2 容器图 开发者交接 C4 C2+C3 组件图 + 时序图 迭代规划 C4 C3 组件图 + 轻量 ADR 企业级信息化规划 TOGAF 4A 全栈 + C4 Level 0 系统全景 TOGAF ADM 9 阶段完整生命周期 TOGAF 架构开发方法（Architecture Development Method, ADM）是整个 TOGAF 框架的核心，提供经过验证的可重复架构开发流程。 ADM 阶段全景 ┌─────────────────────────────────┐ │ 预备阶段 (Preliminary) │ │ 启动架构团队、定义原则、裁剪框架 │ └───────────────┬─────────────────┘ ▼ ┌────────────────────────────────────────────────────┐ │ 架构愿景 (Phase A) │ │ 业务场景、干系人地图、架构愿景声明、范围界定 │ └───────────┬────────────────────────────────────────┘ ▼ ┌────────────────────┐ │ 需求管理 (中央过程) │ ◄── 驱动全部阶段 └────────────────────┘ │ ┌───────┴───────┬───────────┬──────────┐ ▼ ▼ ▼ ▼ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │Phase B │ │Phase C │ │Phase D │ │Phase E │ │业务架构│ │信息系统 │ │技术架构│ │机会与 │ │ │ │架构 │ │ │ │解决方案│ └───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘ │ │ │ │ └────────────┴────────────┴────────────┘ │ ▼ ┌──────────────┐ │Phase F 迁移规划│ └───────┬──────┘ ▼ ┌──────────────┐ │Phase G 实施治理│ └───────┬──────┘ ▼ ┌──────────────┐ │Phase H 架构变更│ │ 管理 │ └──────────────┘ 各阶段关键产出 阶段 核心产出 关键干系人 预备阶段 架构原则、团队组建、TOGAF框架裁剪、治理模型 CIO, Chief Architect Phase A 架构愿景、范围声明、干系人地图、业务场景 CIO, CTO, 业务VP Phase B 业务架构（能力地图、价值流、业务流程模型） 业务VP, Process Owner Phase C 应用架构 + 数据架构（应用组合、数据模型、接口规范） CTO, 数据负责人 Phase D 技术架构（平台选型、基础设施、部署模型） CTO, 基础设施负责人 Phase E 解决方案组合、ROI分析、差距分析 CIO, PMO Phase F 迁移路线图、工作包分解、资源计划 PMO, 实施团队 Phase G 合规审查、架构合同、实施监控 Architecture Board Phase H 变更请求评估、架构更新、治理调整 Architecture Board 架构治理三阶段模型 Develop ──► Implement ──► Deploy (架构开发) (实施监督) (部署验证) │ │ │ ▼ ▼ ▼ Architecture Architecture Architecture Contract Compliance Conformance 治理阶段 核心活动 责任角色 关键交付物 Develop 架构开发、审查、批准 Chief Architect 架构定义文档、ADR Implement 监督实施、处理变更、合规审查 Architecture Board 架构合规报告、变更评估 Deploy 部署验证、迁移确认、正式上线 PMO + Board 部署确认、上线审批 治理角色矩阵 角色 核心职责 决策权限 会议频率 CIO IT战略一致性、投资优先级、资源分配 批准架构原则和重大投资 季度 CTO 技术战略、平台选型、技术债务管理 批准技术标准和技术选型 月度 Chief Architect 架构完整性、架构治理、标准制定 批准架构决策和架构合同 周度 Architecture Board 合规审查、变更评估、标准维护 批准例外请求 双周 Solution Architect 具体方案架构设计、ADR编写 批准组件级决策 周度 Domain Architect 领域架构（数据/应用/安全） 批准领域标准 按需 ADM 迭代三层次 迭代层次 范围 对象 典型周期 全过程迭代 重新执行整个ADM周期 架构重大转型 1-3年 阶段间迭代 前后阶段反馈循环 架构增量交付 3-6个月 阶段内迭代 单阶段内多次细化 架构细节打磨 1-4周 实践建议 ：对于售前方案，通常只需走"预备→Phase A→Phase B（概要）→Phase C/D（概要）→Phase E"的轻量路径，不需要完整的8阶段落地。但理解完整生命周期有助于在高层级方案中准确把握架构边界。 ArchiMate 3.2 建模语言集成 ArchiMate 是 The Open Group 发布的企业架构建模标准（与 TOGAF 同一组织），提供统一的建模语言描述企业架构各层及其关系。ArchiMate 3.2 是最新版本。 六层建模体系 ┌─────────────────────────────────────────────────────────────┐ │ 战略层 (Strategy) │ │ 能力 (Capability) / 资源 (Resource) / 行动路线 (Course of Action) │ ├─────────────────────────────────────────────────────────────┤ │ 业务层 (Business) │ │ 业务角色 (Business Actor/Role) / 业务流程 (Business Process) / │ │ 业务服务 (Business Service) / 业务对象 (Business Object) │ ├──────────────┬──────────────────────────────────────────────┤ │ 应用层 │ 技术层 │ │ (Application)│ (Technology) │ │ 应用组件 │ 节点 (Node) / 设备 (Device) / │ │ 应用服务 │ 系统软件 (System Software) / │ │ 数据对象 │ 技术服务 (Technology Service) / │ │ │ 通信路径 (Communication Path) │ ├──────────────┴──────────────────────────────────────────────┤ │ 动机层 (Motivation) — 横跨所有层 │ │ 干系人 (Stakeholder) / 驱动因素 (Driver) / 目标 (Goal) / │ │ 评估 (Assessment) / 约束 (Constraint) / 原则 (Principle) │ ├─────────────────────────────────────────────────────────────┤ │ 实施与迁移层 (Implementation & Migration) │ │ 工作包 (Work Package) / 交付物 (Deliverable) / │ │ 差距 (Gap) / 高原 (Plateau) / 事件 (Event) │ └─────────────────────────────────────────────────────────────┘ TOGAF ADM 阶段 × ArchiMate 层映射表 ADM 阶段 主要 ArchiMate 层 次要层 关键 ArchiMate 元素 预备阶段 动机层 — 驱动因素、目标、约束、原则 Phase A 动机层、战略层 业务层 干系人、目标、能力、行动路线 Phase B 业务层 动机层 业务角色、业务流程、业务服务 Phase C 应用层 业务层 应用组件、应用服务、数据对象 Phase D 技术层 — 节点、设备、系统软件、技术服务 Phase E 战略层、实施层 — 工作包、差距、高原 Phase F 实施层 — 工作包、交付物、高原 Phase G 实施层 动机层 交付物、评估、约束 Phase H 动机层、战略层 — 驱动因素、目标、评估 ArchiMate 与 C4 模型的互补使用 维度 ArchiMate C4 模型 覆盖范围 战略→业务→应用→技术全栈 软件系统架构（Context→Code） 抽象层级 企业级/架构级宏观视图 系统级/模块级微观视图 强项 跨层次关系建模、动机分析 开发人员视角、部署清晰 弱项 对代码级细节表达力弱 缺少战略层和动机层 最佳场景 企业架构规划、TCO分析、能力规划 方案设计、技术选型、Dev交接 组合策略 ArchiMate做"Why + What" C4做"How + Where" 实践建议 ：高管汇报用ArchiMate Motivation Viewpoint讲清"为什么做"和"值不值得做"；技术方案用C4 C1-C2讲清"怎么做"和"部署在哪"。推荐工具：Archi®（免费开源，The Open Group官方推荐）—— https://www.archimatetool.com/ Wardley Mapping 战略决策框架 Wardley Mapping（由 Simon Wardley 创建）是一种战略决策框架，通过可视化价值链上各组件的位置和演变阶段，帮助企业做出自建/采购/外包/标准化等关键决策。 价值链可视化 Wardley Map 的基本结构：纵轴为"对用户可见度"（Visibility），横轴为"演变阶段"（Evolution），组件按价值链从左到右排列，从用户需求到基础设施组件。 四阶段演变模型 阶段 特征 竞争维度 实践含义 决策建议 创生期 (Genesis) 全新，无人理解，极度稀缺 探索与验证 市场尚不存在 自研或与学术界合作