做了这么多年方案评审、技术文档和需求对接，我越来越觉得“一张好图”的杀伤力被严重低估了。不少开发者和产品经理都跟我说：“图比字管用”，但真拿到他们自己画的架构图、流程图一看，方框套方框、箭头满天飞、颜色五颜六色，评审会讲到一半，连作者本人都得顺着线条找半天才能续上逻辑。diagram-design 这个名字听起来像美术活，其实本质跟绘画关系不大——它是把复杂关系压缩成一张能被快速理解的信息图的过程。这篇内容就是把这几年我在画图这件事上摸出来的门道完整拆开，适合要画架构图、流程图、状态图、业务时序图的人，不管是研发、产品、运维还是做技术写作的，都能找到可以直接抄走的经验。
我先把话说透：好的 diagram design，不是把形状拖得好看，而是让读者在五秒内找到重点，三十秒内看懂主流程，三分钟内能提出问题。下面我会按“先想清楚、再定布局、再规范视觉、最后落地工具”的顺序，把整套方法摊开来写。
1. 先别急着开画：把图当成一页压缩过的文档
1.1 图为什么会越画越乱
很多人画图翻车，不是因为工具不熟，而是因为一开始就没想清楚这幅图到底要回答什么问题。我见过太多这样的场景：拿到一个“画一下系统架构”的需求，下意识打开画布，把服务名一个接一个拖出来，然后凭印象连线，角标和服务间调用的顺序全看心情。画到一半发现漏了模块，又往角落里塞了几个盒子，最后整张图的视觉重心完全被偶然因素支配——哪个模块先被拖出来，哪个就占了大位置。
这种画法的问题在于，把“信息罗列”当成了“信息设计”。罗列是把所有元素堆上去，而设计是先确定哪些元素必须出现、哪些关系必须强调、哪些内容可以暂时舍弃。一张图如果读完以后说不清主要矛盾，那它就不是图，是一张带箭头的通讯录。
我自己的经验是，动手以前先在脑子里把这张图“跑”一遍：读者看到的第一眼落在哪里，视线接着往哪走，最后在哪一个节点停下来得出结论。如果这个流程在你脑海里都走不通，那画到画布上只会更乱。
1.2 动手前必须回答的三个问题
在打开任何绘图工具之前，我会逼自己回答下面三个问题，答不上来就不动笔。
第一个问题是“给谁看”。同一套系统给老板看、给新入职的同事看、给运维团队看，画法完全不同。给老板看要突出业务价值和模块边界；给新人看要突出上下游顺序和依赖方向；给运维看要突出部署拓扑和故障链路。读者决定了你要保留多少细节、抹掉多少细节。对着技术负责人画一张解释“什么是微服务”的图，是对双方时间的浪费。
第二个问题是“解决什么疑问”。图是拿来回答问题的工具。这张图是要说明“数据怎么流动的”，还是“系统分哪些层”，还是“某个流程在异常分支下怎么处理”？同一个系统，为了回答不同问题，需要完全不同的构图。如果你把三个问题塞进一张图，几乎必然失控。宁可拆成三张图，也不要硬挤一张。
第三个问题是“在哪里被看”。评审会投影幕布上的图，和文档里被放大缩小看的图，字号、线宽、密度要求都不一样。投影场景要考虑后排能不能看清；文档场景要考虑截图后放到 PPT 里是否依然可读；白板场景则要接受手写体的不完美，别在讲的时候才现画复杂结构。
这三个问题花不了五分钟，但能替你省掉后面两个小时的重画时间。
1.3 先画“丑图”，再谈“好不好看”
我发现一个特别反直觉的规律：越早开始美化，图越容易废。正确顺序是先画出只包含矩形和文字的逻辑草图，把结构确认下来，再做配色和样式。
这里的道理跟写代码很像。你绝不会先给变量起一个漂亮名字、调整缩进，再考虑功能怎么实现；一定是先把逻辑跑通，再做重构。画图也一样，刚开始的草图丑一点没关系，它存在的唯一目的是让关系和顺序暴露出来。我会用最朴素的框和线，把节点、分组、连线铺一遍，然后盯着它问自己：主流程顺不顺？有没有节点放在一个别扭的位置？哪个地方读起来会卡住？
草图阶段修改布局的成本几乎为零，等上完色、加上投影阴影再改位置，那才叫心疼。所以我给团队定的规矩是：第一版图只准用黑、白、灰三种颜色，谁先开彩笔谁请下午茶。
2. 布局设计要塑造“阅读动线”
2.1 主流程方向决定了图的骨架
布局是一张图的骨架，而骨架的核心是方向。读者的视线天然有惯性，你得顺着这个惯性安排元素，而不是让他反复折返。
从上往下的布局适合表达层级关系和时序推进，比如调用链、审批流、数据同步任务；从左往右的布局适合表达管道式的数据流动和阶段递进，比如数据从采集到清洗到存储到应用；由中心向四周的发散布局适合表达主从关系和辐射结构，比如一个核心服务挂了哪些周边依赖。我见过不少图，把明明是从左到右的数据管道画成了上下结构，结果读者得不断抬头低头来回确认，阅读体验非常糟糕。
确定方向之后，主流程上的节点要尽量对齐在同一条轴线上。流程的中间环节不要突然拐弯，如果整张图的主路径呈现出一个明显的“Z”字形或“S”形，那通常说明布局需要调整，而不是读者需要适应。
2.2 分组与留白：把元素收进“视觉容器”
一个很常见的画图误区，是把相关节点摆得近一点就当作分组了。距离确实能传达亲疏关系，但更可靠的做法是给同一层级的元素加一个明确的边界，我用虚线框、底色块或者统一的外框把一组节点圈起来，这个框架在信息设计里叫“视觉容器”。
视觉容器最大的好处是让读者先在宏观上建立分组认知，再进入细节。“先看全貌、再看局部”是人的阅读习惯，容器就是在帮人省掉自己归纳分组的那一步。比如画系统架构时，把接入层、业务层、数据层分别框起来，比单纯靠物理距离暗示层级要直观得多。
同时，留白不是浪费空间，而是必要的信息分隔符。两个分组之间我建议至少留出一个标准节点的二分之一宽度作为空白。留白太窄，分组之间的边界就会糊掉；留白太大，图又会显得松散。实际操盘时，我会把留白当作一种设计资源来规划，而不是画完以后剩下的垃圾空间。
2.3 对齐、间距与网格：最廉价的美化手段
如果只想做一件事让图变好看，我的建议是打开网格对齐和吸附功能，然后统一所有节点的宽度。很多图看起来“脏”，并不是配色问题，而是每根线都差几个像素的歪斜带来的廉价感。人对不齐是非常敏感的，哪怕只是两三个像素的偏移，大脑也会自动判定这张图“不专业”。
实操里我习惯用统一的间距单位。所有相邻节点之间的间距保持同一个数值，比如都是 24 像素；嵌套容器内的间距再把数值对半，变成 12 像素。这样整个图的疏密节奏是一致的，视觉上会非常安静。节点尺寸方面，同一层级的节点尽量等高或等宽，特殊形状的节点另说，但也要成组统一。
这个规则看似细节，影响却很大。评审会上我经常发现，读者对一张图的信任感，很大程度上来自这些微妙的一致性——人脑会把这种一致性解读为“作者是认真思考过的”。
3. 视觉语言：让颜色、线条和文字都有明确语义
3.1 用色克制，颜色越少越高级
我看见过一整张图上用出十二种颜色的。画的人觉得每块都标了不同颜色很清晰，但读者眼里，所有颜色都在抢注意力，结果就是没有重点。颜色在 diagram 里的正确角色是“语义标记”，不是“装饰”。
我个人在一张图里严格限制三种主色，外加一组灰色做底。三种主色分别承担固定语义：核心链路用一种，辅助链路用一种，异常或警告路径用一种。其余元素全部用灰色。这样一眼扫过去，哪些是重点、哪些是背景，清清楚楚。
还有一点容易被人忽略：不要单独依赖颜色传达信息。有些读者是色弱，颜色差异在他们眼里会糊成一片。所以任何用颜色标记的语义，都必须再叠加一个非颜色标记，比如线型变化、形状变化、文字标注。深色线条加“请求”，与浅色虚线加“异步通知”，即使抛开颜色，单靠线型和标签也能区分。
3.2 线型和箭头各有各的命，别混着用
连线是 diagram 的语法，线型和箭头就是语法里的词法。我见过太多人实线虚线随便点，箭头方向随手拖，最后语义全乱套。
固定一套线型语义，并且整套图坚持用下去：实线表示强依赖、同步调用、确定路径；虚线表示弱依赖、异步事件、可选分支、逻辑分组；粗线表示主干链路或高频路径；细线表示分支或低频路径。箭头方向表示依赖方向，这一点要特别注意——很多人画调用关系时，箭头指向了被调用的服务，然后在旁边标注一个“调用”就草草了事，导致读者分不清到底谁依赖谁。我的习惯是箭头始终从调用方指向被调用方，从依赖方指向被依赖方，并且箭头上写明动作名词或动词短语，比如“发起请求”“订阅事件”“写入数据”。
另外，双向箭头要慎用。除非两个模块之间的数据确实是强双向同步，否则优先拆成两条单向连线，或者用一条直线加两个箭头并配上双向说明，而不是用一根掰来掰去的双头曲线。
3.3 字号、标签和注释：信息要能“扫读”
图上的文字不是文档，它是给人扫读的索引。文字太多、太小、太密，都会破坏扫读效率。
我有几个经验数值可以分享：图中的主标题字号控制在 20 到 24 磅，节点内标签用 14 到 16 磅，注释说明用 12 磅左右，并且注释要跟被注释对象保持足够近的距离，明确归属关系；所有标签文字尽量精简到 4 到 8 个字，超过这个长度就该考虑拆成多行，或者缩写成术语再配上图例。连线上直接写字也要控制数量，如果一条连线上要写超过八个字，那这条线承载的信息就太复杂了，说明这段关系需要被拆成更细的节点。
我还有一个坚持多年的习惯：图上所有文字方向统一。能横排就横排，不要为了迁就布局把标签竖着写。竖排文字极大降低阅读速度，除非是画布物理尺寸实在放不下，否则坚决不做。
4. 工具选型与五步出图实操
4.1 四种工具路线，按场景选而不是按名气选
很多人在工具上反复横跳，今天看别人推荐什么就换什么，最后画图水平没涨，学习成本花了一大堆。工具选型这件事，我一直认为要按使用场景来定，而不是追新。
第一类是大型在线协作画布工具，适合多人评审、实时修改、跨部门沟通的场景。它的优势是天然支持多人同时编辑，评论和版本历史也完善；劣势是复杂大图做到后期会卡顿，样式自由度太高反而容易让团队风格失控。第二类是开源桌面绘图软件，适合离线环境、大图绘制和本地文件管理，性能通常比浏览器工具稳，插件生态也丰富，缺点是协作能力弱，多人同步修改要靠文件版本管理。第三类是手绘风格的白板类及快捷绘图工具，适合快速记录想法、头脑风暴、早期草案，画出来的图自带“未完成感”，能鼓励讨论而不是被成品图吓退，但并不适合做最终交付物。第四类是代码驱动出图的 DSL 工具，适合把图纳入代码仓库做版本管理，文档随代码更新，特别契合技术架构图和基础设施拓扑图的维护需求，用一段描述文本就能生成图：
配置中心 -> 服务注册中心 : 上报实例 服务注册中心 --> 网关 : 推送变更 网关 -> 服务A : 路由请求 服务A --> 缓存集群 : 回写命中你可以把这段描述理解成用“文本写图”：节点关系和箭头方向都写得很明确，任何人拿到源码都知道这张图表达什么，也方便评审时做 diff。
最终我建议普通团队准备两套工具：一套协作类工具用于日常方案讨论，一套代码 DSL 工具用于进仓库的正式架构文档。两套工具的产物要记得同步，否则很快就版本分叉。
4.2 五步出图法：从节点清单到终稿
把上面所有原则落成操作，我总结了一套五步出图法。每一步做完再进入下一步，不要跳。
第一步，列出全部节点。只列名字和类型，先不画。节点要具体到你不能在画的时候才现想，比如“订单服务”“支付服务”“订单表”“支付流水表”而不是“业务服务”“存储”。第二步，定义关系。把节点之间的连线都描述出来，每条连线写清方向、类型、动作语义，这一步实际上是在写逻辑说明书。第三步，分层布局。按主流程方向把所有节点摆到画布上，先摆主干，再摆支线，最后摆附属组件，同时打开网格对齐。第四步，连线与标注。按线型规范把所有关系连上，然后在关键连线上写动作短语，注意让线交叉最少。第五步，上色与检查。给主链路上主色，给辅助路径上辅色，灰色的部分压下去，最后按自查清单过一遍。
这五步每一步都对应一个决策点：列节点是定范围，定义关系是定逻辑，布局是定结构，连线是定细节，上色是定重点。我见过很多人想跳过第二步直接画，结果布局阶段反复返工——因为关系都没理清楚，布局必然站不住脚。
4.3 建立自己的图例规范
有一次评审，我发现团队里三张图分别用三种不同的符号表达“数据库”，有人用圆柱体，有人用圆角矩形加表名，有人用云朵图标。单张都说得通，放在一起做跨系统对比时就非常混乱。从那以后我强制自己和团队沉淀一份“图例规范”，把常用语义固定下来。
这份规范通常包括：节点形状语义，比如圆角矩形表示服务、直角矩形表示存储、菱形表示判断、椭圆表示开始结束；边框和填充的样式规则，比如实线边框表示当前系统内组件，虚线边框表示外部依赖；线型语义，比如实线表示同步请求、虚线表示异步消息、带点虚线表示事件订阅；还有配色语义、字号级别和间距数值。这些规则不需要多复杂，两张 A4 纸就能写完，关键是所有人都遵守。
有了图例规范以后，团队的图才开始真正“同一种语言”，换人接手、跨组评审、归档维护的成本都会显著下降。图例规范本身也应该被当作文档纳入版本管理，每次修订都有记录。
5. 踩过的坑，和一张自查清单
5.1 图太密：人类一次能消化的信息有限
人的工作记忆一次大约能处理 5 到 9 个概念块，超过这个量就得靠重复阅读来补。很多架构图把三十多个服务堆在同一张画布里，头上还压着密密麻麻的依赖线，读者第一眼就失去兴趣了。
解决办法不是硬缩小字号来塞更多内容，而是拆图。把一张巨型图按“运行时视角”“部署视角”“数据视角”拆成若干张子图，每张只回答一个层面的问题。主图保留全貌和高层关系，细节放到子图里，用图号互相引用。这种“拆开但不分裂”的做法，既保住了宏观概览，又不会让读者窒息。
我在很多代码仓库里见过那种动辄 4000 乘 3000 像素的巨型架构图，好看是好看，但没有人会去读它。信息设计的本质是取舍，敢于不画哪些内容，跟敢于画哪些内容一样重要。
5.2 连线绕成蜘蛛网：布线也有方法论
连线交叉是画图最常见的痛点。节点一多，线条互相跨越，图看起来就像一团乱线。最典型的场景是数据流经过了十个中间节点，来源和目标分别在画布的两端，线段被拉得又长又弯。
我处理交叉的方法是：先画主干，把主干上的节点排成一条主轴，让主干连线尽量短、尽量直；次要节点和边缘依赖往两侧挂。如果出现两条长线难以避免地交叉，尝试调整一侧节点的排列顺序，或者把交叉的两条线其中一条改成“总线制式”——用一条粗线代表共享通道，各个节点像接入总线一样挂上去，这比在图上画十几条交叉线干净得多。如果交叉依然存在，就把交叉点的关系拆成一张子图单独表达，主图上仅保留引用入口。
5.3 协作时风格失控：让模板管住审美
多人协作画同一套图，最大的灾难是各自为政。有人喜欢冷色，有人喜欢暖色，有人边框画得特别粗，有人连阴影都不放过，最后拼到一起就像一张拼贴画。风格失控的根因不是审美差，而是没有约束。
我的做法是，在协作工具里建一个团队模板，把页面尺寸、网格间距、配色方案、默认字体、线宽、箭头样式全部预设好。任何人新建图都从模板开始，锁死页面属性和默认样式，只允许修改内容。这样即使十个人各画各的，最后视觉语言也会非常统一。代码 DSL 工具更省心，因为样式由全局主题统一控制，写脚本的人根本没有机会在局部乱调样式。
如果你的团队还没有模板，建议立刻去建一个。这件事一次投入，长期受益，比反复在评审会上跟人强调“能不能统一一下配色”有用得多。
5.4 出图前的十条自查清单
每次准备交付一张图之前，我会快速过一遍下面的清单，全通过了才敢把图发出去：
- 是否只有一个视觉重心，读者第一眼能感知到主流程方向？
- 节点数量是否控制在可消化范围，超过是否需要拆图？
- 所有连线的方向是否语义一致，箭头是否指对了方向？
- 实线虚线粗线是否全程统一，是否有多余的装饰性边框？
- 颜色是否不超过三种主色，重点是否真的被强调出来？
- 标签字号是否在 14 磅以上，注释与归属对象是否清晰对应？
- 所有节点是否对齐，间距是否遵循统一的数值单位？
- 图上文字能否在 30 秒内全部扫读完毕？
- 图的图例规范是否生效，新读者能否不靠讲解就看懂图例？
- 是否保存了一份源文件，并在文档中标注了修改时间和版本？
前四条管逻辑和结构，中三条管视觉，后三条管交付质量。每次检查都不需要花很多时间，但能拦住绝大多数低级问题。
我只是把画图这件日常小事当成一门正经手艺来对待了。这几年下来最深的体会是，图的瓶颈从来不在工具，而在画图人有没有想清楚“这张图到底替读者做了什么决定”。如果你现在手头正有一张画到一半就想放弃的图，不妨停下来，重新回答一遍开头那三个问题；答案清晰了，图也就清晰了。最后再分享一个小技巧：每次画完核心那张主图，我都习惯在旁边留一块空白区，写上这张图“一看就懂”的那句话。如果你自己都想不出一句这样的话，那说明图还没到位，别急着发出去。
