| name | arch-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 | Architect Skill Pack |
| 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 角色的业务解决方案架构设计与绘图 skill。
它不是单纯的“怎么把图画好看”，也不是纯技术架构图规范；它服务于软件架构设计生命周期中的解决方案设计阶段：
- 需求调研已完成并经相关方 review
- 需要把业务问题推进为可评审、可沟通、可进入后续技术设计的中层方案产物
- 产物通常包括：业务流程、领域模型、业务解决方案架构图、风险与治理说明、实施节奏说明
本 skill 的目标有两层，而且两层都必须保留：
-
完整保留业务解决方案架构图的绘图方法学细节
- 业务语境解析
- 架构模式识别
- 视角分层与叙事结构
- 业务域着色
- 语义节点映射
- 关系连线映射
- 布局编排与工具选择
- 一致性检查
-
叠加 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 之间 58px，Task 之间 1015px。
- 系统边界内边距：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: 一致性检查清单
3. 用户交互协议（Agent 行为）
3.1 输入解析
收到用户描述后，Agent 先进行「业务语境解析」，可主动向用户确认：
- 谁在用？（业务角色）
- 在什么场景下？（业务上下文）
- 现在怎么做的？卡在哪里？（痛点）
- 系统要帮他们达成什么？（解决目标）
- 这张图给谁看？（决定工具选择：给业务方看 → Excalidraw；给技术评审看 → Draw.io）
- 依赖哪些外部系统/上下游/第三方？异常怎么处理？
- 核心状态怎么闭环？有没有异常/回退/人工接管？
- 首版最小闭环是什么？哪些能力后置？
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
- 需求尚未澄清就开始画图。
- 把业务解决方案图画成业务流程图。
- 把技术实现细节塞进业务图。
- 外部依赖明明不可靠，却被画成理所当然的内部能力。
- 只画 happy path，不画异常闭环。
- 风险存在，但图里没有任何治理/控制位。
- 首版图把所有未来能力一次性塞满。
- 为了“完整”牺牲了一页纸与阅读顺序。
- 原有绘图词典、颜色、布局模式被无端简化或替换。
- 明明需要补状态图/流程图，却强行用一张总图承载全部信息。
- 用户已经要求的是“业务解决方案文档/方案设计文档”，而图又能显著提升理解，却只交付纯文字正文、把业务解决方案架构图留到下一轮再补。这会让方案文档在评审视角下显得未完成。
- 画了图但没有把图作为正式产物嵌回文档正文，导致图文脱节、后续阅读者只看到文字版方案。
- 方案口径已经变化，但图里仍残留旧入口、旧节点分层、旧 subtitle，或正文继续用“旧方案 vs 新方案”的过渡写法，导致后续阅读者误以为方案尚未收口。
7A. 文档同轮补图规则（新增）
当满足以下条件时，应在同一轮同时交付业务解决方案架构图，而不是先写纯文字文档、等用户追问再补：
- 产物本身就是解决方案设计文档 / 业务方案文档；
- 方案中存在 3 个以上分层、多个协作对象，或明显的“入口 → 协议/控制 → 执行 → 交付”结构；
- 图能够显著降低理解成本。
默认做法：
- 先完成文字方案主结构；
- 同轮生成业务解决方案架构图；
- 若文档载体支持嵌入式图文（例如 Markdown wiki、知识库或设计文档系统），把图作为正式资产嵌回正文，而不是只在聊天里口头说明“之后可再画图”；
- 对正式设计文档，优先使用 draw.io 这类可编辑产物，而不是一次性截图式示意。
- 如果本轮是在更新既有方案而不是首次成稿，图文都必须收口到最新口径
- 删除图中的旧入口、旧分层、旧 subtitle、旧示例和“旧方案说明”残留
- 文档正文也应直接采用当前定稿表述，而不是在主文里反复叙述“以前怎么想、后来怎么改”，除非用户明确要求保留决策演化史
- 当方案的核心控制主轴是 Harness 四象限 时，图应把 Guide × Computational / Guide × Inferential / Sensor × Computational / Sensor × Inferential 画成显式主结构，而不是只在角落里附带提一句
- 连线可读性优先于“信息都塞进一张图”
- 不要让关键标签压在线上
- 不要让说明文字被流程箭头穿过
- 如果四象限逻辑和外层数据流放在一张图中会互相遮挡，优先减少边标签、移动说明文字进框、或拆成“总览图 + 四象限细化图”
8. Verification Checklist
8. Verification Checklist
Provenance
Primary normative source classes:
- a local draft drawing skill captured during private iteration
- a private architecture-lifecycle note used during stage design work
Companion local references:
references/source-map.mdarch-lifecycle-deliveryarchitect/SOUL.md
