要用 AI 创建架构图，先各选定一个受众、问题、范围和视图层级，再从获批代码、部署配置、契约和运行证据整理元素与有向关系台账。只让 AI 起草能引用台账的节点和边，再由系统负责人审核标题、范围、图例、元素类型、关系方向、标签、未知项和敏感细节。

模型能加快提取和排版，但除非你提供核实过的观察结果，它看不到运行时真相。安全输入边界见AI 使用总指南。若只想理解一条代码路径，请用代码讲解流程；架构图回答的是面向特定受众、限定范围的系统问题。

关键要点

先定架构图要回答的问题，再收集方框。

系统、容器、组件和部署视图分开。

每个元素和关系都有证据引用。

用带方向和标签的关系，不用装饰性连线。

标出未知项和冲突，不画看似合理的连接。

分享前移除敏感细节，并经负责人批准。

架构图给谁看、支持什么决策？

管理层、值班工程师和修改单个服务的开发者需要不同的图。先写简要说明：读者是谁、支持哪项决策或任务、读者已知道什么。例如：

向新成员说明系统边界和外部参与方；
为安全评估审查信任边界；
为运维交接展示可部署单元和基础设施；
找出拟议迁移影响的依赖；
为事故复盘解释一次请求或事件流。

C4 模型用一组抽象层级描述软件架构，并强调按受众选择合适的沟通层级。［1］它是好用的词汇，不要求画出所有可能的图。若问题是“每个可部署单元运行在哪里？”，部署视图比源码级组件图更有用。

写清非目标。高层系统上下文图不应再塞进每个队列主题、数据库表、类和云资源。受众需要两个层级时，就画两张有标题的图，用稳定元素 ID 关联。

该选哪个视图层级和范围？

C4 的图类型说明区分了系统上下文、容器、组件、动态和部署等视图。［2］每张图只保留一个主抽象层级：

视图	核心问题	常见元素
系统上下文	谁使用这个系统，它周围有什么？	人、软件系统
容器	系统由哪些可部署或可运行单元组成？	网页应用、服务、数据存储
组件	某个容器内部有哪些主要组件？	模块、适配器、服务
动态	某个场景中各元素如何协作？	编号交互
部署	各实例运行在哪里？	节点、环境、容器实例

设定边界，例如“类生产参考环境中的公开订单系统及直接依赖”，并记录排除的区域、管理工具、分析系统或灾备资源。边界是图含义的一部分，应写进标题或副标题。

哪些证据可以安全交给模型？

可用证据包括仓库结构、依赖清单、路由定义、依赖注入、API 与事件契约、部署清单、基础设施配置、网络策略、数据库迁移、监控面板、运维手册和服务目录条目。冻结精确版本，只收集获准给目标受众看的资料。

删除密钥、凭据、私钥、客户数据、内部 IP 地址、敏感主机名、安全控制细节和未公开漏洞。公开图通常用“身份提供方”这类逻辑名称代替私有端点。脱敏清单够用时，不要让公共 AI 服务检查整个私有仓库。

区分证据类别：

声明： 配置或契约说明某个元素或关系应当存在；
实现： 代码中有相关路径；
部署： 有版本的部署产物把它放到了某个位置；
观察： 经授权的运行时证据显示了流量或状态；
未知/冲突： 来源互相矛盾，或不足以证明该说法。

导入语句只证明可能的代码依赖，不证明请求在运行时经过它；部署清单证明期望配置，不一定是当前生产状态。保留这些区别。

建立元素台账

给每个元素稳定 ID，改名时证据链接不会断。记录类型、职责、技术（仅在相关时）、范围、来源、负责人和可信度。

元素 ID	类型	名称	职责	技术	证据	状态
C-WEB	容器	网页端	接收用户操作	获批运行环境	网页端部署配置和路由	已确认
C-API	容器	API 服务	校验命令	获批运行环境	API 部署配置和契约	已确认
C-WORK	容器	处理器	处理队列中的任务	未知	队列配置	待审核

不要把每个库都变成组件，只放能帮助回答所选问题的元素。若职责无法用一句短话说明，可能范围过大，或需要在另一视图中拆解。

建立有向关系台账

C4 标记法建议写明元素类型、简短描述，以及带方向和标签的关系。［3］没有动词的连线含义不明。记录起点、终点、用途，有证据时写协议或数据，并附来源引用。

关系 ID	起点	终点	方向与用途	协议或数据	证据	状态
R-01	C-WEB	C-API	发送已校验的命令	HTTPS/JSON	客户端和 API 契约	已确认
R-02	C-API	C-QUEUE	将已批准任务入队	事件数据结构	生产者配置	已确认
R-03	C-WORK	C-DB	写入处理后的状态	未知	仅有代码路径	待审核

不要因为网页端和数据库都提到同一实体，就推断两者直连。也不要因响应沿请求通道返回就把边反过来；按该视图关心的消息或控制方向标注交互。双向交互确实重要时，用两条带标签的关系，或标记法支持的精确标签。

别名、冲突和缺失证据该怎么处理？

仓库和部署系统常用不同名称指代同一逻辑元素。建立别名表，每次合并都要有证据；名称相似不是证据。反过来，同一名称也可能指不同实例或环境。

让 AI 返回候选匹配及理由和引用，由负责人批准。以下情况保留冲突记录：

代码调用了某个服务，但部署配置没有声明它；
配置声明了一个队列，却找不到生产者或消费者；
运维手册提到一个已退役、但仍留在部署清单中的组件；
监控观察到一条文档契约中没有的路径；
负责人或所属环境不清楚。

若某个未知元素对回答问题必不可少，可用刻意区分的样式画出“未知”元素，但绝不能为了版面对称把它画成普通的已确认方框。

先定义图示契约，再做排版

先规定视觉语义，免得读者猜测：

每种允许的元素类型对应一种矩形样式；
已确认有向关系统一用一种箭头；
候选或未知项用明显不同、无障碍可辨的样式；
箭头上或旁边写简短关系动词；
图例解释元素类型和证据状态；
标题写明视图、系统、范围和相关环境；
需要追溯时，在标签或附表中保留稳定 ID。

颜色不能是唯一区分，要配合文字标签、边框或图案。不要用暗示未经证实的厂商、数据库或安全控制的图标。除非技术正是受众的问题核心，技术名称应次于职责。

用 AI 创建架构图的受约束草稿

根据附带的台账生成一份架构图规格。

受众：[受众]
问题：[问题]
视图层级：[一个层级]
范围与环境：[范围]

只使用“已确认”的元素和关系，保留稳定 ID。每条边都必须有方向、
简短动词短语和证据 ID。“未知”和“冲突”行放进单独的审核清单，
不要画成已确认。包含标题、范围副标题、元素类型图例和证据状态图例。
不要添加台账中没有的供应商、协议、数据库、安全边界、区域或运行路径。

先让模型输出文本中间表示，如节点与边表格或获批的图表语言，再渲染成图。文本更易比对差异、审核和重新生成。排版指令只是呈现，不是架构事实。

合成证据图示例

下面的确定性示意图使用完全合成的网页端、API 服务、任务队列、处理器和数据库拓扑，演示图示契约：带类型的矩形节点、笔直有向箭头、关系标签、范围标题和图例。它不代表任何真实项目、客户、账户、部署或实测运行路径。

配套台账会记录：网页端到 API 服务是命令，API 服务到任务队列是入队任务，任务队列到处理器是投递，处理器到数据库是状态写入。不能只为画面紧凑就补画网页端到数据库的边。

为什么要先审结构再调美观？

按以下顺序做语义审核：

问题： 图是否回答了写明的受众问题？
边界： 范围内、外部和被排除的系统是否清楚？
层级： 每个元素是否都属于所选的抽象层级？
元素： 每个节点能否追溯到一条获批的台账记录？
关系： 每个箭头是否都有方向、用途和证据？
未知项： 冲突是否在审核记录中可见，而不是被藏起来？
敏感性： 这张图是否适合预定的分享范围？
可读性： 标题、标签、图例和阅读顺序是否清楚？

之后再调间距、对齐、颜色、交叉线和标签位置。带错误连线的漂亮图比朴素的正确图更糟。

部署图为什么要单独处理？

C4 部署图把软件系统或容器实例映射到特定环境的部署节点。［4］开发、预发布和类生产环境布局可能不同，要写明环境和快照，并区分逻辑容器、实例和基础设施节点。

只有获批证据支持且受众有权查看时，才加入区域、集群、节点、网络分区、扩容数量、故障转移或存储。不要无谓暴露公开攻击面或内部控制。数量动态变化时，仅在部署契约支持下使用 1..N 这类有文档依据的多重性，不要把某一刻观察到的数量当作架构照抄。

如何让架构图保持可维护？

政策允许时，把证据台账和文本图源放在持续维护的文档旁，记录仓库或产物版本、审核日期、负责人和重新生成触发条件。有用的触发条件包括路由、契约、部署清单、服务目录、队列、数据库或负责人变化。

尽量自动检测漂移，但不要自动发布架构变更。路由改名可能只是机械变化；新的外部数据流则可能需要安全和隐私审核。自动生成的差异应小到负责人能看懂。

退出条件：每个可见节点和边都能追溯到获批证据；未解决事项已列出；层级一致；敏感信息已移除；标签和图例可读；负责的系统负责人批准了确切源文件和渲染结果。

可复制的架构证据模板

# 架构图说明卡
- 受众：
- 问题/决策：
- 视图层级：
- 系统与范围：
- 环境/快照：
- 排除项：
- 分享级别：

## 元素
- 元素 ID：
- 类型：
- 名称：
- 职责：
- 技术（如相关）：
- 证据与版本：
- 负责人：
- 状态：

## 关系
- 关系 ID：
- 起点/终点：
- 方向与动词：
- 协议或数据（如有证据）：
- 证据与版本：
- 状态：

## 审核
- 冲突和未知项：
- 已移除的敏感细节：
- 图例与标题已核对：
- 系统负责人批准：
- 安全/领域批准（如需要）：

若图用于支持迁移决策，应链接到另行批准的代码迁移蓝图。不要让图片悄悄变成修改系统的授权。

常见问题

AI 能直接从代码发现架构吗？

它能提取候选元素和静态依赖；运行时路径、部署、数据归属和外部关系还需额外证据和负责人审核。

应该先画哪种架构视图？

从能回答受众问题的最小视图开始。系统上下文图或容器图通常比混杂一切的大图更易核验。

一张图应该展示所有层级吗？

不应该。混合系统、容器、组件、类和部署节点会让含义模糊，应使用有标题、共享稳定 ID 的独立视图。

两个来源对某条连接说法不一致怎么办？

把该关系留在冲突登记表，由负责人解决，不要画成已确认。

架构图能自动更新吗？

可以自动提取和生成漂移报告，但发布前须审核，尤其是外部数据流、信任边界、数据存储和负责人变更。

如何避免架构图变得难以阅读？

缩小范围，只用一个抽象层级，删掉不回答问题的细节，把不同场景或环境拆成独立视图。

应移除哪些敏感信息？

凭据、私有地址、客户数据、未公开漏洞、不必要的安全控制细节，以及受众无权查看的任何拓扑。

架构图什么时候算完成？

每个可见说法都可追溯、未知项已记录、视图一致可读、分享安全，且具名负责人批准源文件和渲染结果时，才算完成。

来源

Sources checked 2026 年 8 月 29 日。

C4 Model, “Visualising software architecture” — https://c4model.com/
C4 Model, “Diagrams” — https://c4model.com/diagrams
C4 Model, “Notation” — https://c4model.com/diagrams/notation
C4 Model, “Deployment diagram” — https://c4model.com/diagrams/deployment

如何用 AI 创建架构图：没有证据支撑的连线一律不画