评审会上投出一张架构图，四十多个方框，连线交叉成网，讲了十分钟，听众还在找入口在哪。图的问题通常不在画得丑。它想同时回答五个问题，于是哪一个都没答清。让 AI 帮忙画图之前，先把这张图要回答的那一个问题写下来，后面所有取舍都围绕它。
先写一句话，写不出来就先别画
这句话的格式是「这张图说明 X 经过哪些环节」。可以是「一次下单请求经过哪些服务」，可以是「数据从采集到入库怎么流」，也可以是「故障时哪几个组件会一起挂」。三种问题对应三张完全不同的图，元素、连线、层级都不一样。
写不出这句话，说明系统本身还没想清，这时候画图只是把混乱搬到画布上。先把调用关系列成文字清单，往往比直接开画更快。
五步画完一张图
五步的产出物一层比一层具体，前两步决定骨架，后三步决定它能不能被读懂：
| 步骤 | 产出物 | 常见坑 |
|---|---|---|
| 定问题 | 一句话：这张图要回答什么 | 标题写成「系统架构图」，画到一半开始往里加东西 |
| 列元素 | 组件清单，每个标类型：服务、存储、外部依赖、人 | 部署单元和逻辑模块混在一层，同一个东西出现两次 |
| 分层 | 调用方 → 接入 → 业务 → 数据 → 依赖，每层不超过五六个框 | 层内元素不同质，数据库和定时任务并排摆 |
| 连线 | 每条线带方向、协议、同步或异步 | 一条线代表「调用了好几个服务」，读者无从追 |
| 裁剪与标注 | 图例、关键路径加粗、一行说明哪些细节不在本图 | 没有图例，读者靠猜形状含义；该省的细节全画上 |
元素类型没定，分层就分不干净；分层不干净，连线必然交叉。框数超过五六个的那一层，通常该拆成两张图，一张讲流程，一张讲部署。服务之间的边界按接口契约画，团队归属留给组织图，API 的边界怎么定决定了框该切多细。
交给 AI 的输入，要包含边界
模型的输出质量取决于你交代了多少上下文。至少要给：图的类型、读者是谁、要回答的那个问题、组件清单及各自类型、已知的调用关系、哪些信息必须标注、哪些可以省略。缺一项，它就会用常识补齐，补出来的往往是通用架构而不是你的系统。
提示词可以照这个结构写：「我要画一张{类型}，读者是{谁}，要说明{问题}。组件有{清单}，关系是{描述}。请先给分层方案和每层该放什么，确认后再输出图；只使用我列出的组件，缺的信息标为待确认。」要求它先给方案再出图，比直接要成品有效得多，提示词里哪些约束真正起作用值得先看一眼。
文本描述还是拖拽画布
长期维护的架构文档，优先选能用文本描述的格式。Mermaid、PlantUML、D2 这类写法把图变成代码，能进版本管理，改动体现为 diff，评审时看得见改了什么。拖拽工具胜在快，适合会议里临时讲一版，但文件是二进制的，两个人同时改就要靠人合并。
还有一层实际差别：模型生成文本语法的成功率，明显高于生成一张布局合理的图片。语法错了会报错，改起来有明确方向；图片布局乱了，只能重来。
它画不出来的那部分
你的系统实际怎么调用，它看不到。它按常见架构推断，会把消息队列放在「合理」的位置，把缓存加在「通常」加的地方，这些推断看着专业，和真实链路常常对不上。让它画之前，组件和关系必须由你给全；给不全的地方它会编，模型补上不存在的组件时很难从图上看出来。
布局也一样。节点超过十五个，自动布局开始出现交叉和长线，读图的人要花时间顺着线找。业务语义更是它拿不到的：哪条是主链路、哪条是旁路、哪个环节是瓶颈，只有维护这套系统的人知道。把截图丢给多模态模型让它改图也不靠谱，模型读图能读出文字，读不出对齐关系，它改出来的位置关系经常是错的。
图会过期，所以要有归属
架构图最常见的死法不是画错，是画对之后没人更新。半年后代码改了三个服务，图还是原样，新来的人照着图排查，越查越乱。
约束可以只留三条：图放在代码仓库里，和代码同一次提交更新；每张图标最后核对日期和负责人；超过三个月没人动过的图，评审时先当成可疑材料。这三条不需要工具支持，靠约定就能执行。
速查：画图这件事
- 一张图只回答一个问题，答不清就拆图
- 每层不超过五六个框，超了就换张图
- 连线必须标方向、协议、同步或异步
- 提示词里写明「只用我给的组件，缺的标待确认」
- 能进版本管理的文本格式优先于拖拽画布
