Skill: doertiger/4architecher (version 1.0.0)

--- name: product-4a-architecture description: 基于产品需求，先生成一张完整的 4A 分层主图，再采用苏格拉底追问法逐步澄清业务架构、应用架构、数据架构与技术架构，最终输出 1 张 4A 总览分层主图、4 张分层架构图以及相关文档，并结合外部权威资料校验增强质量。所有架构图默认输出为可导入 draw.io 的 XML 代码块。Use when the user asks to 梳理产品架构、业务架构、应用架构、数据架构、技术架构，或希望按“埃森哲 4A / 四横五纵”思路，从 0 到 1 访谈式产出结构化架构蓝图，并希望以 draw.io XML 形式沉淀完整的分层架构图和配套文档。 --- # Product 4A Architecture ## Overview 使用中文企业架构语境下常见的 4A 工作模型：业务架构、应用架构、数据架构、技术架构。如果用户给出不同的 4A 定义，先复述差异，再以用户定义为准。 把任务视为“从模糊需求到结构化架构资产”的澄清工作，不是单纯画图。默认先基于有限信息快速生成一张 4A 分层主图，再通过苏格拉底追问逐步扩展成四张分层图和相关文档。 ## Core Rules - 一次只问一个问题。每个问题都要瞄准当前最大不确定性。 - 先定边界，再快速出主图，再逐层细化；不要等所有信息都齐全才开始画图。 - 默认采用产品级范围；若需求跨多个业务域，先拆出本次要聚焦的产品或能力域。 - 默认产出中文；若用户混用中英术语，保留关键英文缩写。 - 在任何时刻都维护一份“当前架构画布”，每收集 3-5 个关键信息点就摘要一次。 - 如果用户明确要求“直接给初稿”，可以带假设先出稿，但必须把假设与待确认项单列。 - 第一轮默认先输出 1 张 4A 分层主图草稿，用于快速对齐范围、角色、核心能力、关键系统、核心数据域和技术支撑关系。 - 之后每完成一层追问，就补 1 张该层分图，并同步更新主图与相关说明文档。 - 默认不输出 Mermaid 图；所有图都以可导入 draw.io 的 XML 代码块输出。 - 4A 图必须是“分层架构图”，不是简单流程图、时间线、任务链或操作步骤图。 - 主图必须显式包含 4 个层级容器：业务架构层、应用架构层、数据架构层、技术架构层。 - 阶段规划、实施路线、审批链、用户操作步骤可以单列为补充说明，但不能替代 4A 主图或分图。 - 只要输出中涉及行业事实、竞品能力、监管要求、技术标准、接口约束、产品现状或市场数据，就执行外部权威资料校验。 - 外部校验优先使用一手来源；若引用二手研究，至少要有一条一手来源共同支撑关键判断。 - 明确区分“用户提供信息”“外部证据”“模型推断”；不要把推断写成事实。 ## Workflow ### 1. Define the Boundary 先确认： - 产品名称、阶段、业务目标 - 目标用户或角色 - 本次建模边界：单产品、单能力域、平台，还是企业级 - 成功标准：用于汇报、方案设计、研发对齐、招投标，还是路线图讨论 如果边界不清，优先问边界问题，而不是功能细节。 ### 2. Generate the Master Diagram First 在边界信息足够支撑初步建模后，立即先生成一张主图草稿。 主图只承载高层信息： - 目标用户或关键角色 - 核心业务场景 - 主要业务能力 - 关键应用或平台 - 关键数据域 - 关键技术支撑 主图的目的不是一次性画全，而是为后续追问提供可视化锚点。主图必须是一张完整的 4A 总览分层架构图，并以 draw.io XML 代码块输出。 主图要求： - 必须有 4 个清晰分层容器 - 每层至少放入 2-4 个关键元素，而不是只放标题 - 跨层连线必须表达映射关系，不要用一条线串成流程图 - 如果用户给出了阶段规划，阶段信息放在图外说明，不放进主图主结构 ### 3. Probe the Business Layer 围绕“为什么存在、为谁创造价值、靠什么能力完成”追问： - 核心场景与触发条件 - 用户旅程中的关键节点 - 业务能力、流程、规则、KPI - 参与角色、上下游协同、外部约束 完成该层追问后： - 生成或更新“业务架构图” XML 代码块 - 回写业务架构说明文档 - 视需要修正主图中业务层容器内的角色、场景、能力和规则元素 ### 4. Probe the Application Layer 围绕“哪些系统或模块承接业务能力”追问： - 渠道与入口 - 核心应用、服务、模块、第三方系统 - 模块边界、系统交互、集成方式 - 哪些能力共用，哪些能力专属 完成该层追问后： - 生成或更新“应用架构图” XML 代码块 - 回写应用架构说明文档 - 视需要修正主图中应用层容器内的渠道、系统、模块、外部系统和系统边界 ### 5. Probe the Data Layer 围绕“什么数据被创建、流转、消费和治理”追问： - 核心数据域与主实体 - 数据来源、所有者、消费者 - 主数据、交易数据、分析数据之间的关系 - 数据质量、安全、权限、留存与生命周期 完成该层追问后： - 生成或更新“数据架构图” XML 代码块 - 回写数据架构说明文档 - 视需要修正主图中数据层容器内的数据域、主实体、流向、所有权和治理约束 ### 6. Probe the Technology Layer 围绕“技术如何支撑应用与非功能要求”追问： - 部署形态、运行环境、云或本地 - 接口与集成、中间件、消息、同步异步 - 存储、算力、AI 或算法、可观测性 - 安全、合规、性能、容灾、扩展性 完成该层追问后： - 生成或更新“技术架构图” XML 代码块 - 回写技术架构说明文档 - 视需要修正主图中技术层容器内的运行平台、集成方式、中间件、安全与观测能力 ### 7. Map and Validate 完成初步信息收集后，强制做四类校验： - 每个核心业务能力是否至少有一个应用承接 - 每个核心应用是否读写明确的数据对象 - 每个关键技术组件是否服务于具体应用或质量属性 - 是否存在孤立元素、重复模块、缺失依赖 必要时回到上一个层次继续追问。 ### 8. Validate with External Authority 当以下任一条件成立时，追加外部权威资料校验： - 需要说明某个行业的通行做法、监管要求、合规约束 - 需要判断竞品或标杆产品的能力边界 - 需要确认技术选型、接口规范、标准协议、云服务限制 - 需要给出市场规模、行业趋势、成熟度判断 - 需要把“应该如何设计”建立在“现实世界已经如何运作”之上 执行顺序： 1. 先列出待验证主张，不超过 5 条 2. 为每条主张匹配至少 1 个一手来源 3. 如主张影响重大，再补 1 个独立权威来源交叉验证 4. 记录来源名称、日期、链接、支持的结论、仍未解决的不确定性 5. 用证据修正 4A 图中的假设、能力边界或技术约束 最低门槛： - 一般主张：至少 1 条一手来源 - 关键架构判断：至少 2 条独立来源，其中 1 条必须是一手来源 - 高风险领域：优先只使用官方、监管、标准组织或正式披露文件 ### 9. Produce the Deliverable 默认输出以下内容： 1. 背景与建模边界 2. 关键假设与待确认项 3. 主图 XML 代码块 4. 业务架构图 XML 代码块 5. 应用架构图 XML 代码块 6. 数据架构图 XML 代码块 7. 技术架构图 XML 代码块 8. 四层说明文档 9. 4A 映射矩阵 10. 外部资料校验记录 11. 风险、缺口与下一步建议 ## Question Strategy 优先使用高杠杆问题。选择下一问时，按以下顺序判断： 1. 哪个不确定性会导致整张图重画 2. 哪个不确定性会影响最多层 3. 哪个问题用户最容易回答 4. 是否可以用二选一或三选一降低答题成本 可用的提问句式： - “如果这个产品只能优先服务一类核心用户，最优先的是谁？” - “这项业务能力目前是由一个系统承接，还是由多个系统协同完成？” - “这份关键数据最早在哪里产生，谁对它的准确性负责？” - “这里最先会卡住的是性能、合规，还是跨系统集成？” 不要把问题堆成问卷。保持对话节奏。 ## Deliverable Standard 默认使用 1 张主图、4 张分层图和 3 类文档。先输出主图，再按追问进度补齐四张分图和说明。 draw.io XML 输出要求： - 每张图单独输出一个 `xml` fenced code block - 代码块内容必须是可直接导入 draw.io 的完整 XML，而不是伪代码 - 每张图都要包含 `mxfile > diagram > mxGraphModel > root` 的基本结构 - `root` 下至少包含 `mxCell id="0"` 和 `mxCell id="1" parent="0"` - 所有节点与连线都必须提供明确的 id、parent、style 和 geometry - 图名称固定为：`主图`、`业务架构图`、`应用架构图`、`数据架构图`、`技术架构图` - 如果信息尚不完整，也要输出可导入的初稿 XML，并在文档中标记假设 - 除非用户显式要求，不再以 Mermaid 作为默认图格式 - 主图必须采用 4 层容器式布局，不得用单行节点串联来冒充 4A 主图 - 业务架构图应以角色、场景、能力域、业务规则、KPI 等业务对象为主，不应画成纯操作流程 - 应用架构图应以渠道、应用、服务、外部系统、接口边界为主，不应画成页面点击路径 - 数据架构图应以数据域、实体、来源、消费者、流转与治理为主，不应画成单次数据处理流水线 - 技术架构图应以运行环境、集成、中间件、基础设施、安全、可观测性为主，不应画成部署脚本或调用时序 详细定义、问题库与检查清单见 [references/4a-framework.md](references/4a-framework.md)。 详细输出骨架见 [references/deliverable-template.md](references/deliverable-template.md)。 外部权威资料校验规则见 [references/authority-validation.md](references/authority-validation.md)。 4A 分层图设计规范见 [references/layered-architecture-spec.md](references/layered-architecture-spec.md)。 draw.io XML 结构约束见 [references/drawio-xml-template.md](references/drawio-xml-template.md)。 ## Failure Modes 遇到以下情况，不要直接硬画： - 用户只给了功能列表，没有目标和边界 - 把组织架构、系统架构、流程架构混在一起 - 只描述“要上 AI”，但没有业务触发点和数据闭环 - 把技术选型当成 4A 的起点 - 把阶段路线图、审批链或操作步骤图当成 4A 分层架构图 此时先回到边界、目标用户和核心场景。 ## Final Response Style 交付时保持结构清晰、可复用： - 先给结论，再给图，再给解释 - 先给主图，再给分图，再给文档 - 明确区分“已确认”“假设”“待确认” - 明确区分“外部证据支持”和“基于经验的建议” - 如果信息仍不完整，给出可讨论初稿，而不是空白模板 - 对不确定项给出建议选项，而不是只说“信息不足”

path: agents/openai.yaml
content: interface:
  display_name: "产品4A架构图"
  short_description: "生成完整分层的 draw.io XML 产品4A架构图而非简单流程图"
  default_prompt: "Use $product-4a-architecture to 先生成一张完整的 4A 分层主图，再通过苏格拉底追问逐步产出四张 draw.io XML 格式的分层架构图和相关文档。"


path: references/authority-validation.md
content: # Authority Validation Reference

## 目录

- 使用原则
- 来源分级
- 常用权威源样例
- 检索与校验流程
- 不同问题的证据门槛
- 记录格式
- 禁止事项

## 使用原则

把外部资料校验视为架构输出的质量闸门，而不是附加装饰。

目标不是堆砌链接，而是验证以下内容：

- 关键业务假设是否符合行业现实
- 关键应用能力是否符合已知产品与生态边界
- 关键数据要求是否符合监管、合规或治理常识
- 关键技术方案是否符合官方能力、标准规范或部署约束

只校验会显著影响架构结论的主张，不要为了“看起来有引用”而做无意义搜索。

## 来源分级

### A 级：优先级最高的一手来源

- 官方产品文档、官方 API 文档、官方白皮书
- 法律法规、监管机构公告、官方标准文本
- 标准组织文档，如 ISO、NIST、W3C、IETF、CNCF、行业协会标准
- 公司正式披露文件，如年报、招股书、财报电话会纪要、官网方案页

适用于：

- 产品能力确认
- 技术限制确认
- 合规要求确认
- 标准协议确认

### B 级：高可信二手来源

- Gartner、Forrester、IDC、G2 等研究或分析
- Accenture、McKinsey、BCG、Deloitte、IBM 等头部机构研究
- 高质量行业报告、官方合作伙伴解决方案说明

适用于：

- 行业趋势
- 成熟度判断
- 标杆案例和能力分层

### C 级：仅作补充背景

- 主流媒体报道
- 技术博客
- 社区讨论
- 个人文章

只用于补充语境，不单独支撑关键结论。

## 常用权威源样例

按问题类型优先选择：

### 架构描述与视角组织

- ISO/IEC/IEEE 42010:2022
  https://www.iso.org/standard/74393.html
- The Open Group TOGAF Standards
  https://publications.opengroup.org/standards/togaf
- The Open Group 关于 TOGAF 与 ArchiMate 互补关系的官方说明
  https://help.opengroup.org/hc/en-us/articles/32115987894930-How-the-ArchiMate-Language-and-the-TOGAF-Standard-Complement-Each-Other

### 业务架构

- Business Architecture Guild
  https://www.businessarchitectureguild.org/
- Business Architecture Guild 行业参考模型
  https://www.businessarchitectureguild.org/page/INDREF

### 数据架构与治理

- DAMA-DMBOK 官方介绍
  https://dama.org/learning-resources/dama-data-management-body-of-knowledge-dmbok/
- DAMA 官方站点
  https://dama.org/

### AI、风险与安全架构

- NIST AI RMF
  https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10
- NIST Zero Trust Architecture
  https://www.nist.gov/publications/zero-trust-architecture
- NIST Cybersecurity Framework
  https://www.nist.gov/cyberframework

### 行业或地区监管

- 优先使用适用地区的法律法规、监管机构官网、行业主管机关公告
- 如果是中国语境，优先国务院部门、国家标准全文公开系统、网信、工信、金融监管等官方渠道

## 检索与校验流程

1. 先把待验证内容改写成“主张”。
2. 判断主张类型：监管、产品能力、标准、市场、竞品、实施案例。
3. 先搜 A 级来源；找不到时再搜 B 级来源。
4. 记录每条来源对应支持或反驳了什么。
5. 如果来源之间冲突，优先使用日期更近、权威级别更高、与本地区或本行业更匹配的来源。
6. 最终把“证据支持结论”和“仍属推断的建议”分开写。

## 不同问题的证据门槛

### 监管 / 合规 / 法律

- 只用 A 级来源
- 必须写明适用地区和日期

### 技术标准 / 云服务能力 / API 约束

- 至少 1 条 A 级来源
- 涉及重要架构决策时，再补 1 条独立来源

### 竞品能力 / 市场格局 / 行业趋势

- 至少 1 条 A 级或官方产品页
- 最好补 1 条 B 级研究报告交叉验证

### 咨询式最佳实践

- 至少 1 条 A 级或 B 级来源
- 必须标记哪些是“证据支持”，哪些是“架构建议”

## 记录格式

在最终交付里增加一张证据表：

| 待验证主张 | 来源级别 | 来源名称 | 日期 | 支持结论 | 对架构的影响 |
| --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |

必要时再补：

- 仍未解决的不确定性
- 本次未能获取的一手资料
- 需要用户补充的内部材料

## 禁止事项

- 不要用单一博客支撑关键架构结论
- 不要把过时资料当成当前事实
- 不要把“常见做法”写成“官方要求”
- 不要把咨询经验包装成外部权威结论
- 不要只列链接而不说明这些链接支持了什么


path: references/4a-framework.md
content: # 4A Framework Reference

## 目录

- 工作定义
- 主图先行的交付节奏
- 分层图而非流程图
- 四层关注点
- 横向审视维度
- 苏格拉底追问库
- 外部权威资料校验触发点
- 一致性检查清单
- 常见误区

## 工作定义

本技能默认采用中文企业架构实践中常见的 4A 口径：

- Business Architecture：业务架构，回答“为什么做、为谁做、靠什么业务能力完成”
- Application Architecture：应用架构，回答“哪些系统或模块承接业务能力”
- Data Architecture：数据架构，回答“什么数据被创建、流转、消费和治理”
- Technology Architecture：技术架构，回答“技术如何支撑系统运行与非功能要求”

当用户提到“埃森哲 4A / 四横五纵”但没有给出自定义口径时，可默认把 4A 作为四个纵向视图来建模，并补充横向的策略、管理、设计、实施四种审视维度。若用户所在组织有自己的 4A 定义，优先服从用户定义。

架构治理不是单独的 4A 之一，而是跨层校验与落地约束。

## 主图先行的交付节奏

默认按以下顺序推进：

1. 用最少必要信息先画一张主图
2. 通过苏格拉底追问逐层细化业务、应用、数据、技术
3. 每完成一层，就补齐该层分图和说明文档
4. 在每一轮细化后回写主图，使主图始终保持最新

主图用于对齐范围和主干结构，四张分图用于承载细节。不要等到所有信息齐备才开始画图。

## 分层图而非流程图

4A 产出默认应是分层架构图，而不是流程图。

判断标准：

- 如果图的主要信息是“谁在第几步做了什么”，那是流程图
- 如果图的主要信息是“哪些对象属于哪一层、边界在哪里、层间如何映射”，那才是架构图

可以在分层图内部保留少量方向性连线，但这些连线只能辅助表达关系，不能把整张图退化成操作步骤链。

## 四层关注点

### 业务架构

优先识别：

- 目标用户与角色
- 价值主张
- 关键业务场景
- 业务能力
- 流程与规则
- KPI 与约束

### 应用架构

优先识别：

- 渠道与触点
- 领域应用与平台
- 服务、模块、子系统
- 第三方依赖
- 系统边界与交互

### 数据架构

优先识别：

- 数据域
- 核心实体
- 数据源与归属
- 数据流与同步方式
- 数据质量与权限
- 生命周期与留存

### 技术架构

优先识别：

- 部署拓扑
- 运行时与平台
- 集成方式
- 存储与计算
- 安全与合规
- 性能、弹性、容灾、可观测性

## 横向审视维度

如果用户希望更贴近咨询交付表达，可在每一层补充四个横向视角：

- 策略：为什么建设、目标状态是什么
- 管理：谁负责、如何治理、如何考核
- 设计：目标架构、关键原则、边界和接口
- 实施：分期路线、依赖、落地约束

这四个横向视角用于补齐叙事，不替代 4A 分层本身。

## 苏格拉底追问库

按优先级从高到低选择，不要一次性全部抛给用户。

### 定义边界

- 这次架构图是为了汇报、设计、招投标，还是研发对齐？
- 如果只能聚焦一个核心产品或能力域，本次最应该聚焦哪一个？
- 当前阶段更接近从 0 到 1、快速放量，还是平台化整合？

### 业务架构

- 如果只保留一个最关键场景，哪个场景最能代表产品价值？
- 这个场景里最关键的角色是谁，谁是次级角色？
- 哪些业务能力是必须自建的，哪些能力可以依赖外部生态？

### 应用架构

- 用户是从一个入口进入，还是多渠道进入同一能力域？
- 哪个系统是真正的业务编排者，哪个系统只是配套支撑？
- 是否存在被多个场景重复调用的共性能力？

### 数据架构

- 哪类数据最早产生，在哪个环节第一次被结构化记录？
- 哪些数据必须实时流转，哪些数据允许批处理？
- 谁对主数据口径负责，谁消费分析结果？

### 技术架构

- 当前最敏感的非功能约束是性能、稳定性、合规，还是交付速度？
- 系统之间更适合同步调用、异步事件，还是混合模式？
- 哪些技术能力是平台级共享，哪些是产品专属？

## 外部权威资料校验触发点

出现以下情况时，应在出图前追加外部检索：

- 行业有明显监管或合规门槛
- 方案依赖某家云、模型、平台或第三方接口的真实能力边界
- 需要对竞品、标杆或最佳实践作出判断
- 需要引用行业数据、成熟度或市场趋势
- 用户明确要求“参考外部权威资料”

## 一致性检查清单

出图前至少检查以下问题：

- 主图是否能概括四张分图的主干关系
- 主图是否显式体现 4 个层级容器
- 每个核心业务能力是否映射到至少一个应用能力
- 每个核心应用是否拥有明确的数据输入与输出
- 每个数据域是否有来源、所有者、主要消费者
- 每个关键技术组件是否支撑某个应用或非功能目标
- 是否存在没有业务价值支撑的技术堆叠
- 是否存在没有系统承接的业务能力
- 是否存在没有数据对象的核心流程
- 关键外部主张是否有证据来源与日期
- 高风险判断是否经过至少一次独立来源交叉验证

## 常见误区

- 把组织部门图误当成业务架构图
- 把功能清单直接当成应用架构
- 只画系统框，不画数据与约束
- 一开始就深挖技术选型，导致业务层失真
- 输出图过于漂亮但缺少假设、边界和落地说明
- 引用了外部资料，但没有把证据真正映射回架构判断
- 主图、分图和说明文档之间无法相互对应
- 把时间轴、阶段路线或审批步骤误当成 4A 主图


path: references/layered-architecture-spec.md
content: # Layered Architecture Spec

## 目录

- 设计目标
- 主图规范
- 业务架构图规范
- 应用架构图规范
- 数据架构图规范
- 技术架构图规范
- 跨层映射规则
- 反模式

## 设计目标

4A 架构图的核心不是“把信息连起来”，而是“把信息放在正确层级，再表达层间映射关系”。

输出时优先追求：

- 层次清晰
- 边界明确
- 跨层可追踪
- 同层元素类型一致

不要用简单流程图替代分层架构图。

## 主图规范

主图是 4A 总览分层架构图，必须显式包含 4 个容器：

- 业务架构层
- 应用架构层
- 数据架构层
- 技术架构层

推荐布局：

- 上下四层，业务在上、技术在下
- 或左右四栏，但必须顺序固定且有清晰层标题

每层至少包含：

- 业务层：角色、场景、能力域、业务规则中的关键项
- 应用层：渠道、核心应用、共享服务、外部系统中的关键项
- 数据层：数据域、主实体、数据流/所有权中的关键项
- 技术层：运行平台、集成方式、中间件、安全/观测中的关键项

主图里的连线应该表达：

- 业务能力由哪些应用承接
- 应用读写哪些数据域
- 应用由哪些技术能力支撑

不要让主图变成一条从左到右的步骤链。

## 业务架构图规范

业务架构图关注业务对象，不关注技术调用顺序。

优先包含：

- 关键角色
- 关键场景
- 业务能力域
- 业务规则 / KPI / 风险约束

推荐布局：

- 角色区
- 场景区
- 能力区
- 规则/KPI 区

## 应用架构图规范

应用架构图关注系统边界、应用分工和接口协作。

优先包含：

- 渠道入口
- 核心应用/Skill
- 共享服务
- 第三方系统 / 外部系统
- 系统间接口关系

推荐布局：

- 渠道层
- 业务应用层
- 共享平台层
- 外部系统层

## 数据架构图规范

数据架构图关注数据对象与治理边界，不只关注单次处理流程。

优先包含：

- 数据域
- 主实体
- 数据来源
- 数据消费者
- 数据所有权 / 主数据口径
- 治理与合规约束

推荐布局：

- 来源区
- 核心数据区
- 治理区
- 消费区

## 技术架构图规范

技术架构图关注技术支撑层次，不关注业务步骤。

优先包含：

- 运行环境
- 接入层 / 网关 / 集成层
- 中间件 / 执行引擎
- 基础设施
- 安全、审计、可观测性

推荐布局：

- 接入层
- 服务与编排层
- 执行与集成层
- 基础设施与共性能力层

## 跨层映射规则

至少要满足以下三条：

- 每个核心业务能力都能映射到一个或多个应用承接点
- 每个核心应用都能映射到一个或多个关键数据对象
- 每个关键应用或共性服务都能映射到技术支撑

在主图中，跨层连线只表达映射，不表达完整时序。

## 反模式

- 把 4A 主图画成阶段路线图
- 把业务架构图画成用户点击步骤
- 把应用架构图画成 API 调用时序图
- 把数据架构图画成单次 ETL 流程
- 把技术架构图画成部署命令或操作手册


path: references/deliverable-template.md
content: # Deliverable Template

按以下顺序输出，缺失信息用“假设”或“待确认”标记，不要留空白标题。

## 1. 背景与边界

- 产品名称：
- 建模目标：
- 范围边界：
- 目标用户：
- 当前阶段：

## 2. 已确认 / 假设 / 待确认

### 已确认

- 

### 假设

- 

### 待确认

- 

## 3. 主图 draw.io XML

使用 `xml` fenced code block 输出主图。主图必须是一张 4A 总览分层架构图，而不是流程图。

主图至少包含：

- 业务架构层容器
- 应用架构层容器
- 数据架构层容器
- 技术架构层容器
- 至少 2 条跨层映射关系

```xml
<mxfile host="app.diagrams.net">
  <diagram name="主图">
    <mxGraphModel>
      <root>
        <mxCell id="0"/>
        <mxCell id="1" parent="0"/>
      </root>
    </mxGraphModel>
  </diagram>
</mxfile>
```

## 4. 4A 总览表

| 维度 | 核心内容 | 本次重点 |
| --- | --- | --- |
| 业务架构 |  |  |
| 应用架构 |  |  |
| 数据架构 |  |  |
| 技术架构 |  |  |

## 5. 业务架构图 draw.io XML

业务架构图至少包含：

- 关键角色
- 核心场景
- 业务能力域
- 关键规则 / KPI / 风险约束

```xml
<mxfile host="app.diagrams.net">
  <diagram name="业务架构图">
    <mxGraphModel>
      <root>
        <mxCell id="0"/>
        <mxCell id="1" parent="0"/>
      </root>
    </mxGraphModel>
  </diagram>
</mxfile>
```

## 6. 应用架构图 draw.io XML

应用架构图至少包含：

- 渠道与入口
- 核心应用 / Skill
- 共享服务
- 外部系统
- 接口或边界关系

```xml
<mxfile host="app.diagrams.net">
  <diagram name="应用架构图">
    <mxGraphModel>
      <root>
        <mxCell id="0"/>
        <mxCell id="1" parent="0"/>
      </root>
    </mxGraphModel>
  </diagram>
</mxfile>
```

## 7. 数据架构图 draw.io XML

数据架构图至少包含：

- 数据来源
- 数据域 / 主实体
- 数据消费者
- 数据流或所有权
- 治理约束

```xml
<mxfile host="app.diagrams.net">
  <diagram name="数据架构图">
    <mxGraphModel>
      <root>
        <mxCell id="0"/>
        <mxCell id="1" parent="0"/>
      </root>
    </mxGraphModel>
  </diagram>
</mxfile>
```

## 8. 技术架构图 draw.io XML

技术架构图至少包含：

- 接入层
- 服务 / 编排层
- 执行 / 集成层
- 安全 / 审计 / 可观测性
- 基础设施或运行环境

```xml
<mxfile host="app.diagrams.net">
  <diagram name="技术架构图">
    <mxGraphModel>
      <root>
        <mxCell id="0"/>
        <mxCell id="1" parent="0"/>
      </root>
    </mxGraphModel>
  </diagram>
</mxfile>
```

## 9. 分层说明文档

### 业务架构

- 核心场景：
- 关键角色：
- 业务能力：
- 关键规则 / KPI：

### 应用架构

- 渠道与入口：
- 核心系统 / 模块：
- 系统边界：
- 外部依赖：

### 数据架构

- 数据域：
- 核心实体：
- 数据来源与消费者：
- 治理要求：

### 技术架构

- 部署与运行环境：
- 集成方式：
- 平台与中间件：
- 非功能设计：

## 10. 4A 映射矩阵

| 业务能力 | 承接应用 | 关键数据 | 技术支撑 | 关键约束 |
| --- | --- | --- | --- | --- |
|  |  |  |  |  |

## 11. 外部资料校验记录

| 待验证主张 | 来源级别 | 来源名称 | 日期 | 支持结论 | 对架构的影响 |
| --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |

### 证据支持的结论

- 

### 基于经验的建议

- 

### 仍待确认

- 

## 12. 风险、缺口与建议

### 主要风险

- 

### 当前缺口

- 

### 下一步建议

- 


path: references/drawio-xml-template.md
content: # Draw.io XML Template

## 目录

- 基本原则
- 必备结构
- 分层容器规范
- 节点与连线规范
- 各图最小元素集
- 输出顺序
- 最小模板

## 基本原则

所有架构图默认输出为可直接导入 draw.io 的 XML 代码块。

- 不要输出伪 XML
- 不要省略根节点
- 不要把多个图混在同一个代码块里
- 即使是初稿，也必须保证 XML 可导入
- 不要用单条链路的流程图替代 4A 分层图

## 必备结构

每张图都至少包含：

- `<mxfile host="app.diagrams.net">`
- `<diagram name="图名称">`
- `<mxGraphModel>`
- `<root>`
- `<mxCell id="0"/>`
- `<mxCell id="1" parent="0"/>`

## 分层容器规范

主图必须包含 4 个容器节点，推荐使用 `swimlane` 或带标题的容器形状。

固定顺序：

1. 业务架构层
2. 应用架构层
3. 数据架构层
4. 技术架构层

要求：

- 容器必须覆盖整层元素
- 层标题必须可见
- 每层容器内至少放入 2 个业务对象
- 跨层映射线连接具体对象，不连接层标题本身

## 节点与连线规范

- 节点使用 `mxCell`，并设置 `vertex="1"`
- 连线使用 `mxCell`，并设置 `edge="1"`
- 节点必须有 `value`、`style`、`parent`
- 节点必须带 `mxGeometry`，至少包含 `x`、`y`、`width`、`height`
- 连线必须带 `source`、`target` 和相应 `mxGeometry`
- 同一张图内 id 不重复
- 图名固定使用：`主图`、`业务架构图`、`应用架构图`、`数据架构图`、`技术架构图`
- 主图中的连线默认表达“映射”而不是“时序”

## 各图最小元素集

- 主图：4 个层容器 + 每层至少 2 个元素 + 至少 2 条跨层映射线
- 业务架构图：角色、场景、能力、规则/KPI
- 应用架构图：渠道、应用、共享服务、外部系统
- 数据架构图：来源、核心数据、消费者、治理/所有权
- 技术架构图：接入、编排、执行/集成、安全/审计、基础设施

## 输出顺序

1. 主图
2. 业务架构图
3. 应用架构图
4. 数据架构图
5. 技术架构图

如果用户要求分阶段产出，就先交主图，后续每一轮追问只补新增或更新的分图。

## 最小模板

```xml
<mxfile host="app.diagrams.net">
  <diagram name="主图">
    <mxGraphModel dx="1200" dy="800" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="1800" pageHeight="1400" math="0" shadow="0">
      <root>
        <mxCell id="0"/>
        <mxCell id="1" parent="0"/>
        <mxCell id="layer-business" value="业务架构层" style="swimlane;rounded=0;html=1;fillColor=#fef6e7;strokeColor=#d6b656;fontStyle=1;" vertex="1" parent="1">
          <mxGeometry x="40" y="40" width="1680" height="220" as="geometry"/>
        </mxCell>
        <mxCell id="layer-application" value="应用架构层" style="swimlane;rounded=0;html=1;fillColor=#edf7ed;strokeColor=#82b366;fontStyle=1;" vertex="1" parent="1">
          <mxGeometry x="40" y="300" width="1680" height="220" as="geometry"/>
        </mxCell>
        <mxCell id="layer-data" value="数据架构层" style="swimlane;rounded=0;html=1;fillColor=#eef3fc;strokeColor=#6c8ebf;fontStyle=1;" vertex="1" parent="1">
          <mxGeometry x="40" y="560" width="1680" height="220" as="geometry"/>
        </mxCell>
        <mxCell id="layer-technology" value="技术架构层" style="swimlane;rounded=0;html=1;fillColor=#f3edf7;strokeColor=#9673a6;fontStyle=1;" vertex="1" parent="1">
          <mxGeometry x="40" y="820" width="1680" height="220" as="geometry"/>
        </mxCell>
        <mxCell id="business-role" value="关键角色" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;" vertex="1" parent="1">
          <mxGeometry x="120" y="120" width="140" height="60" as="geometry"/>
        </mxCell>
        <mxCell id="business-capability" value="核心能力" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;" vertex="1" parent="1">
          <mxGeometry x="380" y="120" width="160" height="60" as="geometry"/>
        </mxCell>
        <mxCell id="application-app" value="核心应用" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" vertex="1" parent="1">
          <mxGeometry x="380" y="390" width="160" height="60" as="geometry"/>
        </mxCell>
        <mxCell id="data-domain" value="核心数据域" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;" vertex="1" parent="1">
          <mxGeometry x="380" y="650" width="160" height="60" as="geometry"/>
        </mxCell>
        <mxCell id="technology-platform" value="技术支撑" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#e1d5e7;strokeColor=#9673a6;" vertex="1" parent="1">
          <mxGeometry x="380" y="910" width="160" height="60" as="geometry"/>
        </mxCell>
        <mxCell id="map-ba-aa" style="edgeStyle=orthogonalEdgeStyle;html=1;endArrow=block;" edge="1" parent="1" source="business-capability" target="application-app">
          <mxGeometry relative="1" as="geometry"/>
        </mxCell>
        <mxCell id="map-aa-da" style="edgeStyle=orthogonalEdgeStyle;html=1;endArrow=block;" edge="1" parent="1" source="application-app" target="data-domain">
          <mxGeometry relative="1" as="geometry"/>
        </mxCell>
        <mxCell id="map-aa-ta" style="edgeStyle=orthogonalEdgeStyle;html=1;endArrow=block;" edge="1" parent="1" source="application-app" target="technology-platform">
          <mxGeometry relative="1" as="geometry"/>
        </mxCell>
      </root>
    </mxGraphModel>
  </diagram>
</mxfile>
```


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)