Software Design Lifecycle Solution Design Biz Arch Diagramming

---
name: software-design-lifecycle-solution-design-biz-arch-diagramming
description: "Use when an architect in the solution-design stage must produce or review the 业务解决方案架构图 and needs the fully merged specialist method directly inside the new lifecycle family instead of via a legacy wrapper skill."
version: 1.1.0
author: Hermes Agent
license: MIT
metadata:
  hermes:
    tags: [architect, lifecycle, solution-design, business-architecture, diagramming]
    related_skills: [arch-lifecycle-solution-design-methodology, arch-lifecycle-solution-design-biz-flow-diagramming, arch-lifecycle-solution-design-domain-modeling]
---

# Solution Design Business Architecture Diagramming

## Overview

This skill now directly contains the merged specialist doctrine that previously lived in the legacy business-solution architecture skill. Valuable content is preserved and relocated here rather than being wrapped indirectly.

## Integrated Legacy Specialist Doctrine (Preserved and Merged)

# Business Solution Architecture Lifecycle

## Overview

这是 architect profile 私域下的**业务解决方案架构设计与绘图 skill**。

它不是单纯的“怎么把图画好看”，也不是纯技术架构图规范；它服务于**软件架构设计生命周期中的解决方案设计阶段**：
- 需求调研已完成并经相关方 review
- 需要把业务问题推进为可评审、可沟通、可进入后续技术设计的中层方案产物
- 产物通常包括：业务流程、领域模型、业务解决方案架构图、风险与治理说明、实施节奏说明

本 skill 的目标有两层，而且两层都必须保留：

1. **完整保留业务解决方案架构图的绘图方法学细节**
   - 业务语境解析
   - 架构模式识别
   - 视角分层与叙事结构
   - 业务域着色
   - 语义节点映射
   - 关系连线映射
   - 布局编排与工具选择
   - 一致性检查

2. **叠加 architect 角色在解决方案设计阶段必须做的架构审查门**
   - 生命周期进入条件
   - 方案调研与复用判断
   - 外部依赖可靠性 / 降级 / 兜底 / 隔离
   - 核心业务状态闭环
   - 风险与治理控制点
   - 实施节奏与最小闭环里程碑

核心原则：
**业务解决方案架构图不是装饰性插图，而是把“已确认的业务问题”压缩成“可进入后续技术设计的中层方案结构”的正式架构产物。**

---

## 0. 生命周期定位（architect 增强，不替代绘图细节）

### 0.1 所处阶段
本 skill 用于：
- 业务需求调研文档与相关反馈已确认后
- 技术方案设计（概要设计 / 详细设计）之前

它属于：
- **解决方案设计文档**的一部分

而不是：
- 技术架构图
- 模块内部详细设计
- 部署拓扑图
- 运维手册

### 0.2 前置输入（缺一不可）
在正式画图前，至少应已有：
- 已确认的需求背景
- 系统现状 / 当前痛点
- 目标效果 / 业务收益
- 成功指标或 ROI 信号
- 非目标 / 边界约束
- 若适用，已完成的成熟方案调研与复用判断

如果这些输入缺失，不要直接画图，应退回问题澄清。

### 0.3 该图必须额外回答的 architect 问题
除了“怎么画”，还必须回答：
- 这个方案依赖哪些外部系统、上下游系统或第三方能力？
- 哪些依赖必须按不可靠依赖处理？异常时如何降级、兜底或隔离？
- 核心业务状态是否形成闭环？正常、异常、回退路径是否明确？
- 哪些高风险点必须在图中显式出现治理 / 控制位？
- 最小可交付闭环是什么？哪些能力属于后续阶段？

---

## 1. 能力边界（Agent 自检）

本 Skill 产出的是**业务解决方案架构图**——回答的问题是：  
**「为了支撑这个业务场景，系统方案长什么样？谁参与、什么流程、数据如何流转、解决了什么痛点？」**

### 1.1 适用场景
- 需求评审会上对齐业务与技术的全局理解
- 项目启动会上展示系统方案轮廓
- 招投标/立项材料中的架构插图
- 业务方理解系统如何支撑其操作流程
- 解决方案设计文档中的中层方案图
- 在进入技术方案设计前，对业务方案进行结构化澄清与 review

### 1.2 不适用场景（必须拒绝并提示用户）
- 纯技术实现细节图（微服务调用链、类图、ER图、部署拓扑）
- 纯业务组织图（部门分工、RACI、汇报线）
- 纯商业模式图（价值链、盈利模型）
- 模块内部详细设计图（字段级 schema、adapter 级执行路径、连接/认证编排）
- 物理架构 / 网络拓扑 / 运维部署图

### 1.3 图种职责边界（architect 必须显式区分）
- **业务流程图**：说明角色、步骤与处理顺序
- **领域模型图**：说明业务对象、边界与语义关系
- **业务解决方案架构图**：说明用户入口、中间处理环节、外部系统与输出结果之间的整体方案关系
- **系统架构图**：说明内部子系统、外部依赖、通信关系与边界条件
- **技术架构图**：说明具体技术栈、引擎、中间件、数据存储与执行路径
- **状态机 / 流程 / 时序补图**：说明状态闭环、异常路径、回退路径与运行分支

**硬规则：** 如果一张图同时承担了业务解决方案图、系统架构图、技术架构图、状态图的职责，就必须拆图。

---

## 2. 核心工作流（原绘图细节完整保留 + architect 增强门）

### Step 0: 业务语境解析
提取「业务故事五要素」：

| 要素 | 提取目标 | 示例 |
|------|---------|------|
| **Who** 业务角色 | 谁在用？谁受影响？ | 门店店长、财务审核员、供应商 |
| **When/Where** 场景 | 在什么上下文操作？ | 每日打烊对账、月度结算、大促备货 |
| **What** 操作 | 现在怎么做的？具体动作？ | 手动汇总 Excel → 微信发给财务 → 等 3 天反馈 |
| **Pain** 痛点 | 卡在哪里？有多痛？ | 格式不统一返工、人工慢易出错、进度不可见 |
| **Gain** 目标 | 解决后要达成什么业务价值？ | 自动对账、T+1 结算、全程可视 |

**输出要求：** Agent 用 1 句话向用户确认业务故事：  
> 「这张图将回答：【角色】在【场景】中，通过【操作】解决【痛点】，方案将带来【价值】。」

#### Step 0A: architect 增强提问（新增，不得跳过）
除五要素外，必须再补齐：
- **Why now**：为什么要现在做？不做会怎样？
- **Metric**：项目产出/衡量指标是什么？
- **External**：依赖哪些外部系统、上下游系统、第三方能力？
- **Reliability**：哪些依赖不可靠？异常时如何降级、兜底、隔离？
- **State closure**：核心业务状态是否形成闭环？正常、异常、回退流程分别是什么？
- **Risk**：风险来自业务规则、外部依赖、权限安全、单点故障、审计缺失还是容量瓶颈？
- **Milestone**：最小闭环版本是什么？哪些能力是后续里程碑？

#### Step 0B: 方案调研与复用判断（architect 增强）
在提出定制化方案前，先判断是否：
- 直接采用成熟方案
- 改造复用成熟方案
- 只借鉴接口层 / 交互层模式
- 有理由地不采用外部成熟方案

如果复用判断会影响方案结构，应在后续图中反映，不要只写在文字里。

### Step 1: 架构模式识别
基于业务流特征匹配布局：

| 业务流特征 | 匹配模式 | 默认布局 |
|-----------|---------|---------|
| 有明确的"接收 → 处理 → 交付" 闭环 | 数据流型 (DataFlow) | Layered Sandwich |
| 多方互相调用，存在中枢/网关 | 服务网型 (ServiceMesh) | Honeycomb/网状 |
| 事件触发、状态推送、实时通知 | 事件管道型 (EventPipe) | Horizontal Pipeline |
| 多环境/集群/部署单元 | 部署巢状型 (DeploymentNest) | Nested Boxes |
| 审批、权限、风控、合规 | 治理树型 (GovernanceTree) | Tree Radiation |
| 混合或无法归类 | 自由关联型 (FreeForm) | Semantic Clustering |

**决策规则：** 若存在多种特征，按「数据流 > 事件管道 > 服务网 > 部署巢状 > 治理树」优先级选择。

#### Step 1A: architect 图种 gate（新增）
在确定模式之前，先确认当前图真的还是“业务解决方案架构图”而不是：
- 纯业务流程图
- 技术架构图
- 部署图
- 模块详细设计图
- 状态图 / 时序图

如不是，应改换图种或拆成多图。

### Step 2: 视角分层与叙事结构
架构图必须采用 **「从左到右、业务优先」** 的三层叙事。图的阅读顺序必须能连成一句通顺的业务话。

| 图层 | 位置 | 内容 | 视觉处理 |
|------|------|------|---------|
| **L0 业务操作层** | 最左 | 业务角色（Actor）及其动作 | `Actor` + 自然语言箭头标签（如"提交月度账单"） |
| **L1 痛点-方案层** | 中左 | 将痛点映射为治理/自动化/控制点 | `Governance` 虚线框或 `ConfigGroup`，标注"解决：XX 痛点" |
| **L2 解决方案层** | 视觉中心 | 系统提供的业务能力 | `Module`/`Task`，按业务域着色 |
| **L3 结果/基础设施层** | 最右 | 业务结果、外部方、存储 | `Endpoint`、`Database`、`FileServer` |

**阶段标记：**  
在主链路关键节点上方或左侧，放置圆形数字徽章 `①②③④⑤`，明确业务主链路的阅读顺序。

**价值标注：**  
在 L2 关键节点旁，用小型标签（无边框，灰色斜体）标注业务价值：  
如：`（省去 2 天人工核对）`、`（错误率从 5% 降到 0.1%）`、`（实时可见，无需催办）`

**连线叙事规则：**
- 箭头标签 = **业务语言（主）+ 技术语义（括号补充）**  
  正确：`提交对账单 (Excel上传)`、`获取结果 (自动推送)`  
  错误：`put file`、`trigger job`、`RPC call`

#### Step 2A: architect 闭环增强（新增）
在主链路之外，必须检查图中是否足够表达：
- 外部依赖失败后的处理位置
- 异常待处理/人工接管节点
- 状态反馈 / 结果可视 / 责任归属节点

如果无法在主图清楚表达，应补状态图 / 异常流程图，不要强塞在一张图中。

### Step 3: 业务域着色
识别独立业务域（按数据主权、业务线或操作方向划分）：

- **单域系统**：`neutral_infra` 为主，`highlight_path` 仅强调 1 条关键链路。
- **双域系统**（如：接入 + 分发；办理 + 运营）：`primary_domain` + `secondary_domain`。
- **三域系统**（如：用户端 + 平台端 + 监管端）：增加 `tertiary_domain`。
- **≥4 域系统**：强制合并为「核心业务域 + 外部协同域」两级，或改用 `neutral_infra` + 文字标签。

**默认色值映射：**
- `primary_domain`: `#E6E0EC`（低饱和紫灰，冷色）
- `secondary_domain`: `#FFF8DC`（低饱和米黄，暖色）
- `tertiary_domain`: `#E0F0EC`（低饱和青灰）
- `neutral_infra`: `#F5F5F5`（灰白）
- `external_boundary`: 无填充 + `#999999` 虚线边框
- `highlight_path`: `#FF6B6B`（仅 1 条关键链路）

#### Step 3A: architect 风险着色提醒（新增）
不要把“风险域”画成一个新业务域来滥用颜色。
风险/治理优先通过以下方式体现：
- `Governance` 控制框
- 监控/审计/审批节点
- 旁注标签
- 阶段性补图

而不是新增第四、第五种域色把图搞乱。

### Step 4: 语义节点映射
将业务实体映射为视觉节点。必须按词典选择，禁止自创形状：

| 业务语义 | 视觉节点 | 形状 | 填充规则 |
|---------|---------|------|---------|
| 业务角色/用户/外部机构 | `Actor` | 简笔画人形 | 无填充，黑色线条 |
| 系统边界/上下文范围 | `SystemBoundary` | 大矩形，细实线边框 | 无填充或极浅灰 |
| 业务模块/服务/应用 | `Module` | 圆角矩形 | 所属域填充色 |
| 业务任务/作业/流水线节点 | `Task` | 紧凑圆角矩形（高 30~40px） | 所属域填充色 |
| 业务规则/配置/参数/策略 | `Config` | 小型矩形/文本条（高 22~28px） | 白色或浅色 |
| 规则组（多参数聚合） | `ConfigGroup` | 细线矩形框，内部紧凑排列 | 无填充 |
| 执行引擎/运行时/Worker | `Engine` | 虚线边框矩形 | 无填充 |
| 业务处理步骤/阶段 | `Step` | 小圆角矩形 | 白色填充 |
| 持久化数据库/存储 | `Database` | 圆柱体 | 灰白填充 |
| 缓存/高速存储 | `Cache` | 圆柱体 + 斜线纹理 | 灰白填充 |
| 消息队列/事件总线 | `Queue` | 管状或栈状 | 所属域填充色 |
| 文件/对象/协议网关 | `FileServer` | 等角立体方块 | 浅灰填充 |
| API 网关/入口/负载均衡 | `Gateway` | 梯形或盾牌形 | 所属域填充色 |
| 业务规范/接口契约/标准文档 | `Document` | 矩形带波浪底边（卷轴） | 所属域填充色 |
| 外部系统/终端/合作方 | `Endpoint` | 纯色填充矩形 | 所属域填充色 |
| 治理/控制/审批/调度/风控 | `Governance` | 虚线圆角矩形 | 无填充 |
| 监控/告警/大盘/看板 | `Monitor` | 竖向窄条或仪表盘形 | 无填充或浅灰 |
| 移动端/小程序/App | `Mobile` | 竖向圆角矩形 | 所属域填充色 |
| Web 端/浏览器 | `Browser` | 横向圆角矩形 | 所属域填充色 |
| 网络/CDN/云/可用区 | `Network` | 云形或 globe | 中性色 |

**映射规则：**
- 本系统内的「XX 系统/平台/中心」→ `Module`
- 本系统外的「XX 机构/银行/合作方」→ `Endpoint`（填充对应域色）或 `Governance`（虚线框）
- 「XX 任务/作业」→ `Task`
- 「配置/参数/规则/策略」→ `Config` 或 `ConfigGroup`
- 「引擎/执行器/调度器」→ `Engine`

#### Step 4A: architect 依赖可靠性增强（新增）
涉及外部依赖时，节点映射还要表达其**边界地位**：
- 外部但可控协作方 → `Endpoint`
- 外部但强监管/审批/合规影响方 → `Governance` / `Endpoint + Governance`
- 外部文件/协议入口 → `FileServer` / `Gateway`
- 外部不可靠依赖不要伪装成本系统内 `Module`

### Step 5: 关系连线映射
将业务交互关系映射为连线，标签必须用**业务语言为主**：

| 关系语义 | 连线样式 | 颜色 | 箭头 | 标签规范 |
|---------|---------|------|------|---------|
| 主业务流/数据请求 | 实线 | 跟随源节点域色 | 单向三角 | 业务动作（如：提交账单、获取结果、分发文件） |
| 反向业务流/响应 | 实线 | 跟随源节点域色 | 单向三角 | 业务动作+回（如：返回报表、回调状态） |
| 双向交互/查询反馈 | 实线 | 黑色或深灰 | 双向三角 | 左标签（去）、右标签（回） |
| 业务控制/审批/调度/配置 | 实线 | 黑色 `#333` | 单向三角 | 「审批」「自动调度」「策略配置」 |
| 异步/事件/消息/弱依赖 | 虚线 | 跟随源节点域色或黑色 | 单向三角 | 「异步通知」「事件触发」 |
| 状态同步/心跳/探活 | 虚线 | 黑色 `#999` | 双向或单向 | 「状态同步」 |
| 规范/契约/标准下发 | 实线 | 黑色 | 单向三角 | 「规范下发」「接口契约」 |

#### Step 5A: architect 例外连线规则（新增）
当存在异常、降级、人工兜底、审计回流时：
- 优先使用**虚线**或单独补图表达弱依赖 / 异常路径
- 不要让异常路径与主链路等视觉权重，除非异常本身就是核心业务
- 如果 fallback 路径会改变责任归属，要在标签中明确：
  - `异常转人工复核`
  - `依赖失败后延迟重试`
  - `生成失败告警并待运营处理`

### Step 6: 布局编排与工具选择

#### 6.1 布局编排（按选定模式）

**模式 A: Layered Sandwich（数据流型）**
- 纵向 4 层：L0 业务操作 → L1 痛点方案 → L2 核心方案 → L3 结果/设施。
- **必须从左侧 Actor 开始**，向右展开。
- 核心层与引擎层**并排、等高、顶部对齐**，间距 40~60px。
- 核心层内采用「左任务、右配置」双栏，左栏 `Task` 与右栏 `Config` **顶部严格对齐**，间距 30~40px。
- 若双域并存，核心层**上下分域**（上域 A + 下域 B），引擎层**左右分腔**。

**模式 B: Honeycomb（服务网型）**
- 中心为 `Gateway`，周围环绕 `Module`，呈蜂窝状或星状分布。
- **必须从调用方 Actor 开始**，表示谁调用了服务网。
- 连线表示业务调用方向。

**模式 C: Horizontal Pipeline（事件管道型）**
- 从左到右排列 `Step` 或 `Module`，表示业务处理阶段。
- **最左侧必须是触发事件的 Actor 或业务动作**（如"用户下单"、"文件到达"）。
- 阶段之间用单向实线连接，上方可并行 `Queue` 作为缓冲。

**模式 D: Nested Boxes（部署巢状型）**
- 外层 `SystemBoundary` 表示环境/云/集群，内层嵌套服务。
- **外层标注业务环境名**（如"生产环境"、"监管专区"），而非纯技术名。

**模式 E: Tree Radiation（治理树型）**
- 根节点在顶部（`Governance` 或业务入口）。
- **根节点必须关联业务角色**（如"风控专员发起复核"）。
- 向下辐射分支，叶子为业务终端或系统模块。

**模式 F: Semantic Clustering（自由关联型）**
- 按语义将节点分组，组名用**业务语言**（如"客户触达域"、"结算核心域"）。
- **每组必须能回答一个业务问题**（如"如何解决对账慢？"）。

#### 6.2 全局排版常量
- 画布背景：纯白 `#FFFFFF`。
- 主线条：1px 实线 `#333333`；虚线仅用于 `Engine`、`Governance`、`External`。
- 字体：无衬线 12~14px，常规字重；模块标题可 14px 加粗；**价值标注 11px 灰色斜体**。
- 同级节点间距：20~40px。
- 父子层间距：50~80px。
- 紧凑间距：`Config` 之间 5~8px，`Task` 之间 10~15px。
- 系统边界内边距：15~20px。
- **一页纸铁律：节点 ≤ 15**（业务理解场景）；超过时必须合并或拆分子图。

#### 6.3 技术细节黑名单（业务图中禁止出现）
**以下元素禁止出现在业务解决方案架构图中：**
- 具体中间件名（Redis、Kafka、Nginx、Zookeeper、Elasticsearch）
- 端口号、IP 地址、域名、具体服务器名
- 具体框架名（Spring Cloud、Dubbo、Vue、React）
- 数据库表名、字段名、索引名（可用"对账数据库"代替"reconcile_order"）
- 微服务内部调用链细节（服务 A 调服务 B 调服务 C）
- 部署细节（Pod 数量、CPU 限制、副本集、K8s 命名空间）

**允许出现的技术元素（必须包裹业务语义）：**
- 「文件网关」而非「SFTP 192.168.x.x」
- 「消息通知」而非「Kafka Topic」
- 「数据仓库」而非「MySQL Cluster」
- 「缓存加速」而非「Redis Cluster」

#### 6.4 工具选择策略
Agent 根据使用场景主动推荐：

| 用户场景/意图 | 推荐主工具 | 备选工具 | 核心理由 |
|--------------|-----------|---------|---------|
| 给业务方/管理层快速对齐、非正式分享、需要手绘感 | **Excalidraw** | Draw.io | 手绘风格降低技术压迫感，支持实时协作，修改零成本 |
| 正式设计评审、精确对齐、复杂连线、企业级输出 | **Draw.io** | SVG | 形状库丰富，网格对齐精确，支持图层，输出矢量图 |
| 技术文档沉淀、Git 版本控制、需要保留可编辑源文件与稳定导出 | **Draw.io** | SVG/HTML | `.drawio` 源文件可版本化留存，导出 PNG/SVG/PDF 稳定，复杂布局与配色能力更强 |
| 网页嵌入、品牌定制、交互式演示、像素级控制 | **SVG/HTML** | Draw.io | 可动画/交互，完全可控，但编写成本高 |
| 幻灯片汇报、邮件插图、打印材料 | **Draw.io/Excalidraw 导出 PNG/SVG** | — | 先绘制再导出高清位图/矢量图 |

**输出时必须声明：**  
> 「基于【场景描述】，推荐使用【工具名】绘制，理由是【理由】。若您需要【备选场景】，可改用【备选工具】。」

#### 6.5 architect 里程碑与治理可视化增强（新增）
在不破坏原绘图结构的前提下，可增加：
- `P0 / P1 / P2` 小标签表示阶段性交付边界
- `Governance` 旁注表示治理目的：如“解决：审计缺失”“解决：权限滥用”
- 对外部不可靠依赖加灰色说明：如“失败时转人工处理”“失败后异步补偿”

但**不得**因此破坏：
- 原有布局模式
- 原有节点词典
- 原有颜色规则
- 原有黑名单边界

### Step 7: 一致性检查清单
- [ ] **业务叙事完整**：从 L0 Actor 出发，沿主链路能读出完整业务句子（谁→做什么→解决什么）。
- [ ] **有阶段标记**：主链路关键节点有 `①②③④⑤` 数字徽章，阅读顺序明确。
- [ ] **有价值标注**：关键节点旁有业务价值标签（如"省去 X 天人工"、"错误率降低"）。
- [ ] **无技术黑话**：图中无黑名单中的技术细节。
- [ ] **一页纸**：节点 ≤ 15；超过则合并同类项或拆分子图。
- [ ] **形状一致**：同类语义节点使用同种形状。
- [ ] **颜色一致**：同一域的节点填充色、关联箭头色一致；域色种类 ≤ 3。
- [ ] **对齐一致**：同一层级顶部对齐；同一分组左对齐。
- [ ] **流向一致**：主业务流符合阅读顺序（左→右或上→下）。
- [ ] **无悬空节点**：每个非边界节点至少有一条入线或出线。
- [ ] **交叉最小化**：连线交叉不超过 3 处；超过则调整布局。
- [ ] **标签可读**：所有标签使用业务语言，不与节点/其它标签重叠。
- [ ] **工具适配**：输出格式符合所选工具的语法/规范。
- [ ] **外部依赖显式**：关键外部系统/第三方能力明确出现，且未被误画为内部模块。
- [ ] **依赖可靠性有交代**：关键依赖失败时的降级/兜底/隔离路径已在图或补充说明中交代。
- [ ] **状态闭环明确**：正常、异常、回退至少在主图或补图之一中说清。
- [ ] **风险治理可见**：重要权限、安全、合规、审计、单点故障、容量风险已经映射到治理/控制点或里程碑约束。
- [ ] **实施节奏可讲清**：能够说清最小闭环版本与延后范围。

---

## 3. 用户交互协议（Agent 行为）

### 3.1 输入解析
收到用户描述后，Agent 先进行「业务语境解析」，可主动向用户确认：

1. **谁在用？**（业务角色）
2. **在什么场景下？**（业务上下文）
3. **现在怎么做的？卡在哪里？**（痛点）
4. **系统要帮他们达成什么？**（解决目标）
5. **这张图给谁看？**（决定工具选择：给业务方看 → Excalidraw；给技术评审看 → Draw.io）
6. **依赖哪些外部系统/上下游/第三方？异常怎么处理？**
7. **核心状态怎么闭环？有没有异常/回退/人工接管？**
8. **首版最小闭环是什么？哪些能力后置？**

### 3.2 输出格式（三段式，原始绘图协议逐字保留）

**第一段：业务叙事摘要**
用业务语言重述这张图的故事：  
> 「本方案解决【角色】在【场景】中的【痛点】。从左到右：用户通过【操作】接入，经【治理】校验后，由【引擎】自动处理，最终向【合作方】交付【结果】，全程通过【监控】实时可视。」

**第二段：设计决策声明**
- 识别的架构模式及理由
- 视角分层设计（L0~L3 分别承载什么）
- 主题色语义分配（哪个域用什么颜色）
- 节点映射摘要（业务名 → 视觉节点类型）
- 工具选择及理由

**第三段：可执行绘制指令**
- 明确指定工具（Excalidraw / Draw.io / SVG）。
- 提供该工具下的**可直接运行的代码或结构化描述**：
  - **Draw.io**：提供 XML 结构描述或元素清单。
  - **Excalidraw**：提供场景描述（元素坐标、类型、文本、颜色、阶段标记位置）。
  - **SVG**：提供 SVG 结构描述（viewBox、rect、circle、path、text）。
- 若工具为 Draw.io，应提供可编辑源文件结构（XML / 元素清单）、布局意图、颜色语义与导出格式；不要只给无法复用的截图说明。

### 3.2A architect 增强补段（附加，不替代原三段式）

若当前任务属于 architect 视角下的解决方案设计 review，可在原三段式之后补充这一段：

**第四段（可选）：风险 / 闭环 / 里程碑声明（architect overlay）**
- 哪些外部依赖最关键，哪些不可靠
- 降级/兜底/隔离/人工接管思路
- 核心业务状态是否形成闭环
- 主要风险点及其治理方式
- 最小可交付闭环、延后范围与后续阶段

### 3.3 拒绝与澄清
若用户描述属于不适用场景，Agent 必须拒绝：  
> 「当前描述更适合流程图/UML/物理拓扑图，而非业务解决方案架构图。请补充：业务角色、操作流程、当前痛点、以及系统要达成的业务目标。或改用其他 Skill。」

若用户要求的其实是：
- 技术栈选型、模块拆分、接口细节 → 转技术方案设计
- 领域边界/上下文映射/聚合 → 转 DDD/domain modeling
- 部署拓扑/运维 → 转部署运维设计

---

## 4. 快速参考卡（Agent 内部调用）

### 4A. 原始绘图速查卡（逐字保留）

### 4.1 布局速选
```
IF 描述含 ["上传","下发","接入","导出","同步","对账","文件","入库","出仓"] 
   → Layered Sandwich（从左侧 Actor 开始）
ELIF 描述含 ["调用","服务","网关","RPC","中台","微服务"] 
   → Honeycomb（从调用方 Actor 开始）
ELIF 描述含 ["事件","触发","通知","监听","流","消息"] 
   → Horizontal Pipeline（从触发事件的业务动作开始）
ELIF 描述含 ["部署","集群","环境","云","容器"] 
   → Nested Boxes（从业务环境名开始）
ELIF 描述含 ["审批","权限","角色","风控","复核"] 
   → Tree Radiation（从业务角色发起开始）
ELSE → Semantic Clustering（按业务问题分组）
```

### 4.2 颜色速配
```
单域 → neutral_infra + highlight_path(可选)
双域 → primary_domain + secondary_domain
三域 → primary_domain + secondary_domain + tertiary_domain
≥4域 → 强制合并为核心域 + 外部域，或改用文字标签
```

### 4.3 工具速选
```
给业务方/管理层/快速对齐 → Excalidraw
给技术评审/精确文档 → Draw.io
给文档沉淀/Git/后续编辑 → Draw.io
给网页/交互/品牌 → SVG
```

### 4.4 标签语言检查
```
错误（纯技术）：put file, trigger job, RPC, Redis, Kafka, 192.168.x.x
正确（业务+技术）：提交对账文件 (自动上传), 触发结算 (调度执行), 实时通知 (消息推送)
```

### 4B. architect 增强速查卡

### 4.5 architect review gate 速查
```
必须补问：
- 为什么现在做 / 不做的影响？
- 成功指标 / ROI 是什么？
- 依赖哪些外部系统？谁不可靠？
- 失败后怎么降级/兜底/隔离/人工接管？
- 核心业务状态是否形成闭环？
- 首版最小闭环是什么？哪些后置？
```

---

## 5. 示例片段

### 5.0 原 draft 示例（逐字保留）

**用户输入：**  
"运营团队每天收到十几家合作机构的 Excel 对账单，格式不统一，人工核对慢且出错。希望做自动对账平台，上传后自动校验、入库、匹配订单、生成差异报表，运营和机构都能实时看进度。"

**Agent 业务叙事：**  
> 「本方案解决运营与合作机构在「日终对账」中的「人工慢、格式乱、不可视」痛点。从左到右：机构上传账单 → 自动格式校验 → 标准化入库 → 订单匹配 → 生成差异报表 → 双方实时监控，全程零人工干预。」

**Agent 设计决策：**
- 模式：DataFlow → Layered Sandwich
- 视角：L0 机构运营/内部运营 → L1 格式混乱→自动校验 → L2 接入/处理/导出 → L3 机构端/数据库/监控
- 域：双域（接入=primary_domain 紫灰，导出=secondary_domain 米黄）
- 工具：Excalidraw（业务对齐场景）

**Agent 绘制指令（Excalidraw 场景描述）：**
```
画布：横向宽幅，纯白。

L0 业务操作层（最左）：
- Actor "合作机构运营" (x=60, y=280)
  → ① 单向实线箭头（标签："上传原始对账单"）指向 Gateway "文件入口"
- Actor "内部运营" (x=60, y=480)
  → 双向实线箭头（标签："查看进度 / 接收告警"）指向 Monitor "对账看板"

L1 痛点-方案层：
- Governance "格式标准化治理" (虚线框, x=220, y=180)
  旁注标签："解决：格式混乱、人工返工"
  → 向下单向箭头（标签："自动校验规则"）指向 L2

L2 解决方案层（中心，SystemBoundary，宽 700px）：
- 上域 primary_domain（接入处理）：
  - Task ① "原始账单接入" (x=280, y=260, 旁注："省去人工收取")
  - Task ② "格式自动校验" (x=280, y=310, 旁注："错误率从 5%→0.1%")
  - Task ③ "标准数据入库" (x=280, y=360)
  - 右侧 ConfigGroup "校验规则" (x=430, y=260, 内含：字段映射、编码检查、重复检测)
- 下域 secondary_domain（导出匹配）：
  - Task ④ "订单自动匹配" (x=280, y=460, 旁注："省去 2 天人工核对")
  - Task ⑤ "差异报表生成" (x=280, y=510, 旁注："T+1 自动出表")
  - 右侧 ConfigGroup "匹配策略" (x=430, y=460, 内含：订单号关联、金额容差)

L3 结果/设施层（最右）：
- Endpoint "机构自助平台" (x=720, y=260, secondary_domain)
  → 单向箭头（标签："下载差异报表"）从 Task ⑤ 指向此处
- Database "对账数据库" (x=720, y=380, 圆柱体)
  → 与 L2 双向黑色箭头（标签："状态同步"）
- Monitor "对账看板" (x=720, y=480, 竖条)
  → 双向箭头连接内部运营 Actor

阶段标记（圆形数字徽章，位于主链路节点上方 20px）：
- ① 在"原始账单接入"上方
- ② 在"格式自动校验"上方
- ③ 在"标准数据入库"上方
- ④ 在"订单自动匹配"上方
- ⑤ 在"差异报表生成"上方

颜色：
- 接入域箭头/填充：#E6E0EC
- 导出域箭头/填充：#FFF8DC
- 治理/监控/数据库连线：黑色
```

### 5.1 architect 增强版示例（附加，不替代原示例）

**用户输入：**  
"运营团队每天收到十几家合作机构的 Excel 对账单，格式不统一，人工核对慢且出错。希望做自动对账平台，上传后自动校验、入库、匹配订单、生成差异报表，运营和机构都能实时看进度。"

**Agent 业务叙事：**  
> 「本方案解决运营与合作机构在「日终对账」中的「人工慢、格式乱、不可视」痛点。从左到右：机构上传账单 → 自动格式校验 → 标准化入库 → 订单匹配 → 生成差异报表 → 双方实时监控，全程零人工干预。」

**Agent 设计决策：**
- 模式：DataFlow → Layered Sandwich
- 视角：L0 机构运营/内部运营 → L1 格式混乱→自动校验 → L2 接入/处理/导出 → L3 机构端/数据库/监控
- 域：双域（接入=primary_domain 紫灰，导出=secondary_domain 米黄）
- 工具：Excalidraw（业务对齐场景）

**Agent architect 补充判断：**
- 外部依赖：合作机构上传质量不可控，按不可靠输入处理
- 闭环：失败单需进入人工复核，不可停留在“校验失败但无人接手”状态
- 风险：格式混乱、匹配误判、进度不可视、人工催办
- 里程碑：P0 先打通上传→校验→入库→差异报表；P1 再补异常复核与机构自助查看增强

**Agent 绘制指令（Excalidraw 场景描述）：**
```
画布：横向宽幅，纯白。

L0 业务操作层（最左）：
- Actor "合作机构运营" (x=60, y=280)
  → ① 单向实线箭头（标签："上传原始对账单"）指向 Gateway "文件入口"
- Actor "内部运营" (x=60, y=480)
  → 双向实线箭头（标签："查看进度 / 接收告警"）指向 Monitor "对账看板"

L1 痛点-方案层：
- Governance "格式标准化治理" (虚线框, x=220, y=180)
  旁注标签："解决：格式混乱、人工返工"
  → 向下单向箭头（标签："自动校验规则"）指向 L2
- Governance "异常单人工复核" (虚线框, x=220, y=520)
  旁注标签："兜底：校验失败 / 匹配异常时人工接管"

L2 解决方案层（中心，SystemBoundary，宽 700px）：
- 上域 primary_domain（接入处理）：
  - Task ① "原始账单接入" (x=280, y=260, 旁注："省去人工收取")
  - Task ② "格式自动校验" (x=280, y=310, 旁注："错误率从 5%→0.1%")
  - Task ③ "标准数据入库" (x=280, y=360)
  - 右侧 ConfigGroup "校验规则" (x=430, y=260, 内含：字段映射、编码检查、重复检测)
- 下域 secondary_domain（导出匹配）：
  - Task ④ "订单自动匹配" (x=280, y=460, 旁注："省去 2 天人工核对")
  - Task ⑤ "差异报表生成" (x=280, y=510, 旁注："T+1 自动出表")
  - 右侧 ConfigGroup "匹配策略" (x=430, y=460, 内含：订单号关联、金额容差)
- 异常路径：
  - Task "异常单归集" (x=520, y=540)
  - 虚线箭头从 Task ② / Task ④ 指向此处，标签："校验失败 / 匹配异常"
  - 再由此指向 Governance "异常单人工复核"

L3 结果/设施层（最右）：
- Endpoint "机构自助平台" (x=720, y=260, secondary_domain)
  → 单向箭头（标签："下载差异报表"）从 Task ⑤ 指向此处
- Database "对账数据库" (x=720, y=380, 圆柱体)
  → 与 L2 双向黑色箭头（标签："状态同步"）
- Monitor "对账看板" (x=720, y=480, 竖条)
  → 双向箭头连接内部运营 Actor

阶段标记（圆形数字徽章，位于主链路节点上方 20px）：
- ① 在"原始账单接入"上方
- ② 在"格式自动校验"上方
- ③ 在"标准数据入库"上方
- ④ 在"订单自动匹配"上方
- ⑤ 在"差异报表生成"上方

颜色：
- 接入域箭头/填充：#E6E0EC
- 导出域箭头/填充：#FFF8DC
- 治理/监控/数据库连线：黑色
```

---

## 6. architect 专属 review gates（对原绘图 skill 的补强，不得替代原方法学）

### Gate 1：Lifecycle Gate
若以下缺失，停止画图：
- 当前现状
- 目标结果
- 为什么现在做 / 不做的影响
- 成功指标 / ROI
- 非目标 / 范围边界

### Gate 2：Unreliable Dependency Gate
必须明确：
- 哪些外部系统/第三方是关键依赖
- 哪些按不可靠依赖处理
- 失败时如何降级、兜底、隔离、人工接管

### Gate 3：State Closure Gate
必须明确：
- 核心业务对象/状态是什么
- 正常流程、异常流程、回退流程分别是什么
- 是否有 silent limbo 状态

### Gate 4：Risk / Governance Gate
必须明确：
- 风险来自哪里
- 哪些风险必须改变结构，而不是只写备注
- 是否需要显式 Governance / Monitor / 审批 / 审计节点

### Gate 5：Milestone Gate
必须明确：
- 最小可交付闭环
- 哪些先做
- 哪些后做
- 哪些能力现在不应塞进首版图

### Gate 6：Abstraction Gate
业务解决方案图中禁止下沉到：
- schema 字段级
- enum 级
- adapter 级
- handler / class / package 级
- 容器/Pod/服务器/端口/IP 级

如果这些细节已经成为主问题，说明图种错了，应该切到技术方案设计。

---

## 7. Common Pitfalls

1. 需求尚未澄清就开始画图。
2. 把业务解决方案图画成业务流程图。
3. 把技术实现细节塞进业务图。
4. 外部依赖明明不可靠，却被画成理所当然的内部能力。
5. 只画 happy path，不画异常闭环。
6. 风险存在，但图里没有任何治理/控制位。
7. 首版图把所有未来能力一次性塞满。
8. 为了“完整”牺牲了一页纸与阅读顺序。
9. 原有绘图词典、颜色、布局模式被无端简化或替换。
10. 明明需要补状态图/流程图，却强行用一张总图承载全部信息。
11. 用户已经要求的是“业务解决方案文档/方案设计文档”，而图又能显著提升理解，却只交付纯文字正文、把业务解决方案架构图留到下一轮再补。这会让方案文档在评审视角下显得未完成。
12. 画了图但没有把图作为正式产物嵌回文档正文，导致图文脱节、后续阅读者只看到文字版方案。
13. 方案口径已经变化，但图里仍残留旧入口、旧节点分层、旧 subtitle，或正文继续用“旧方案 vs 新方案”的过渡写法，导致后续阅读者误以为方案尚未收口。

### 7A. 文档同轮补图规则（新增）

当满足以下条件时，应在**同一轮**同时交付业务解决方案架构图，而不是先写纯文字文档、等用户追问再补：

- 产物本身就是解决方案设计文档 / 业务方案文档；
- 方案中存在 3 个以上分层、多个协作对象，或明显的“入口 → 协议/控制 → 执行 → 交付”结构；
- 图能够显著降低理解成本。

默认做法：

1. 先完成文字方案主结构；
2. 同轮生成业务解决方案架构图；
3. 若文档载体是 Obsidian 等可嵌入场景，把图作为正式资产嵌回正文，而不是只在聊天里口头说明“之后可再画图”；
4. 对正式设计文档，优先使用 draw.io 这类可编辑产物，而不是一次性截图式示意。
5. 如果本轮是在**更新**既有方案而不是首次成稿，图文都必须收口到**最新口径**
   - 删除图中的旧入口、旧分层、旧 subtitle、旧示例和“旧方案说明”残留
   - 文档正文也应直接采用当前定稿表述，而不是在主文里反复叙述“以前怎么想、后来怎么改”，除非用户明确要求保留决策演化史
6. 当方案的核心控制主轴是 **Harness 四象限** 时，图应把 **Guide × Computational / Guide × Inferential / Sensor × Computational / Sensor × Inferential** 画成显式主结构，而不是只在角落里附带提一句
7. 连线可读性优先于“信息都塞进一张图”
   - 不要让关键标签压在线上
   - 不要让说明文字被流程箭头穿过
   - 如果四象限逻辑和外层数据流放在一张图中会互相遮挡，优先减少边标签、移动说明文字进框、或拆成“总览图 + 四象限细化图”

---

## 8. Verification Checklist

---

## 8. Verification Checklist

- [ ] 生命周期位置明确：这是 solution-design 阶段产物，不是 technical-design 产物
- [ ] 原始绘图细节完整保留：业务语境、布局模式、色彩、节点词典、连线规则、排版常量、黑名单、工具策略均未丢失
- [ ] 业务叙事可以从 Actor 一直读到业务结果
- [ ] 外部依赖显式出现，且可靠性判断已完成
- [ ] 正常/异常/回退闭环已在主图或补图中交代
- [ ] 风险已经映射为治理 / 控制 / 审批 / 监控 / 里程碑约束
- [ ] 最小闭环版本与延后范围可被说明
- [ ] 图的抽象层级仍停留在业务解决方案层
- [ ] 若需要多图，已经明确拆分职责，而非强行一图包打天下
- [ ] 下游技术设计者能据此继续展开，而不会因图过度抽象或过度技术化而失真

---

## Provenance

Primary normative sources:
- business solution architecture drawing methodology
- software architecture lifecycle methodology

Companion references:
- `references/source-map.md`
- `software-design-lifecycle-delivery`