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
当以下任一条件成立时，追加外部权威资料校验：
- 需要说明某个行业的通行做法、监管要求、合规约束
- 需要判断竞品或标杆产品的能力边界
- 需要确认技术选型、接口规范、标准协议、云服务限制
- 需要给出市场规模、行业趋势、成熟度判断
- 需要把“应该如何设计”建立在“现实世界已经如何运作”之上
执行顺序：
- 先列出待验证主张，不超过 5 条
- 为每条主张匹配至少 1 个一手来源
- 如主张影响重大，再补 1 个独立权威来源交叉验证
- 记录来源名称、日期、链接、支持的结论、仍未解决的不确定性
- 用证据修正 4A 图中的假设、能力边界或技术约束
最低门槛：
- 一般主张：至少 1 条一手来源
- 关键架构判断：至少 2 条独立来源，其中 1 条必须是一手来源
- 高风险领域：优先只使用官方、监管、标准组织或正式披露文件
9. Produce the Deliverable
默认输出以下内容：
- 背景与建模边界
- 关键假设与待确认项
- 主图 XML 代码块
- 业务架构图 XML 代码块
- 应用架构图 XML 代码块
- 数据架构图 XML 代码块
- 技术架构图 XML 代码块
- 四层说明文档
- 4A 映射矩阵
- 外部资料校验记录
- 风险、缺口与下一步建议
Question Strategy
优先使用高杠杆问题。选择下一问时，按以下顺序判断：
- 哪个不确定性会导致整张图重画
- 哪个不确定性会影响最多层
- 哪个问题用户最容易回答
- 是否可以用二选一或三选一降低答题成本
可用的提问句式：
- “如果这个产品只能优先服务一类核心用户，最优先的是谁？”
- “这项业务能力目前是由一个系统承接，还是由多个系统协同完成？”
- “这份关键数据最早在哪里产生，谁对它的准确性负责？”
- “这里最先会卡住的是性能、合规，还是跨系统集成？”
不要把问题堆成问卷。保持对话节奏。
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/deliverable-template.md。
外部权威资料校验规则见 references/authority-validation.md。
4A 分层图设计规范见 references/layered-architecture-spec.md。
draw.io XML 结构约束见 references/drawio-xml-template.md。
Failure Modes
遇到以下情况，不要直接硬画：
- 用户只给了功能列表，没有目标和边界
- 把组织架构、系统架构、流程架构混在一起
- 只描述“要上 AI”，但没有业务触发点和数据闭环
- 把技术选型当成 4A 的起点
- 把阶段路线图、审批链或操作步骤图当成 4A 分层架构图
此时先回到边界、目标用户和核心场景。
Final Response Style
交付时保持结构清晰、可复用：
- 先给结论，再给图，再给解释
- 先给主图，再给分图，再给文档
- 明确区分“已确认”“假设”“待确认”
- 明确区分“外部证据支持”和“基于经验的建议”
- 如果信息仍不完整，给出可讨论初稿，而不是空白模板
- 对不确定项给出建议选项，而不是只说“信息不足”
