技术图绘制指南：从读者分析到文本化设计

1. 先想清楚一件事：这张图要替谁说话

做了这么多年技术方案和产品设计，我给自己的一个硬性要求是：任何一张图，如果不写标题、不加说明，也能让目标读者在三十秒内抓住重点，才算合格。听起来有点苛刻，但大多数“画出来没人看”的图，问题恰恰出在动笔之前——压根没想清楚图要替谁说话。

先说个常见场景。某个模块要联调，我让团队成员把调用关系画一下，收到的是一张把所有服务、数据库、消息队列、缓存全塞进来的大图，密得像电路板。问他想表达什么，他说“这就是我们的架构啊”。问题是，这张图的读者是谁？如果是新入职的同事，他需要的是“请求从入口进来之后先经过谁、再经过谁”；如果是运维同学，他需要的是“哪个服务挂在哪个端口、依赖哪些中间件”；如果是在做技术选型评审，他需要的是“关键链路的取舍和瓶颈在哪”。读者不同，信息密度完全不同。把三层需求揉进一张图，结果就是谁都没看懂。

1.1 图的读者决定信息密度

我习惯在动手之前先给图分个类：给外行看的、给同组看的、给自己看的。

给自己看的图，怎么随意都行，那是思考草稿；给同组看的图，要能支撑技术讨论，节点粒度到模块和关键接口就够了；给外行或跨团队看的图，必须隐去大量实现细节，只保留角色、事件和结果。举个例子，同一个用户下单流程，给产品经理看的版本是“用户点击提交订单、风控校验、创建订单、支付、通知仓储”；给后端开发的版本则要画出“订单服务调用风控 SDK、异步发送领域事件、库存服务消费事件后锁定库存”这样的粒度。你不可能用同一张图满足两类人。

有个很实用的判断方法：画完之后，想象读者会提什么问题。如果他问的第一句话是“这个框是什么意思”，说明抽象层级选错了；如果他问的是“为什么这里要经过这个服务”，说明你的图其实已经合格了，讨论开始进入正题。

1.2 抽象层级的选择

抽象层级这个词听起来玄，本质上就是“你站在哪一层画图”。

我通常用三层层级来对标：业务层、逻辑层、物理层。业务层关注角色和流程，不出现服务名和端口；逻辑层关注模块、接口、数据流，不出现服务器 IP 和部署方式；物理层关注节点、网络、依赖关系，不出现业务术语。很多图画乱，就是因为在这三层之间来回横跳——一个框里是“用户注册”，另一个框里是“Redis 集群”，层级不统一，读者的大脑就得不停切换上下文，自然累。

我的建议是：一张图只能选定一层为主视图，其他层的信息用注释或子图补充，不要混在同一层。比如画系统架构图，主视图用逻辑层，把部署信息放在节点下方的小字备注里；画部署拓扑图，主视图用物理层，把业务模块名写在节点标题里。层级定了，连线语义就清晰了：逻辑层的线表示调用/依赖，物理层的线表示网络连接/数据流转，两者不能混画。

1.3 一张图画不完就拆图

还有一个特别常见的心理误区：总觉得一张图画得越全越显得系统完整。实际上，信息量超过七个节点左右，人的短期记忆就开始失效。你画三十个节点上去，读者看完这一片忘了那一片。

我在评审方案时有个习惯：如果一张图需要读者上下左右来回扫视超过三屏，就判定为不合格，强制拆图。拆法有两种，一种是按层级拆，把总览图只画一级节点，细节图再展开二级、三级节点；另一种是按视角拆，比如把“数据链路图”和“服务依赖图”分开，各自独立成图，再通过编号互相引用。总览图保持清爽，细节图保持完整，两者通过统一的节点命名关联起来，这样整套图才真正具有了文档价值。

2. 选型比画图更花功夫：先决定这张图属于哪种类型

我见过太多人一打开画布就拖方块，画到一半发现结构不对再推翻重来。这是效率最低的做法。正确顺序应该是：先想清楚你要表达的信息结构，再决定图表类型，最后才动手。

图表类型的选择，本质上是对信息结构进行分类。我自己的经验是，绝大多数技术图都可以归到三大类里：表达路径的、表达结构的、表达状态的。

2.1 流程型图表：表达路径与决策

只要信息里有“先后顺序”“条件分支”“循环重试”，就属于流程型图表。典型代表是业务流程图、算法流程图、审批流程图、跨部门协作流程图。

画流程型图表的重点不是画箭头，而是找对起点和终点。起点是外部触发的那个动作，终点是价值交付的那个结果。中间每一个节点，要么是一个动作，要么是一个决策，不要混用。我见过不少人把一个“判断是否通过”的决策框画成普通动作框，结果整个流程的语义就变了——读者看不出哪里可能产生分支。

分支要控制在两级以内。超过五六个分支的流程，正确的做法不是把分支画得更密，而是把主路径抽出来，把分支拆成子流程。否则那张图就会变成一张蜘蛛网，没人看得清主干道在哪里。

2.2 结构型图表：表达层级与归属

当信息里出现“谁包含谁”“谁依赖谁”“谁属于哪个大类”时，应该用结构型图表。典型代表是系统架构图、组织架构图、模块依赖图、ER 图。

结构型图表最大的坑是层级混乱。我画架构图时会强制规定：从上往下是调用方向，从下往上是依赖方向；左侧是外部入口，右侧是公共支撑。这样规定不是为了好看，而是为了让读者能靠直觉定位。如果既存在自上而下的调用，又存在自下而上的依赖，我会把这两类关系分开画成两张图，或者用不同线型明确区分，不能混在一组连线里。

另一个常见问题是把层级画成拓扑。比如画模块依赖图，有人把各个服务围成一圈，连线互相交叉，视觉上是拓扑图，但语义上是结构图。两者的阅读逻辑完全不同——结构图需要清晰的父子层级，拓扑图强调节点的网络关系。动手前先确定好，别画成四不像。

2.3 时序与状态型图表：表达交互与变化

涉及时间顺序、消息传递、状态迁移的内容，需要用时序图或状态图。时序图表达的是“谁在什么时间点调用了谁”，适合梳理接口交互、事件驱动流程；状态图表达的是“一个对象在不同条件下怎么变化”，适合梳理订单状态、任务生命周期。

画时序图时，我最看重的是时间轴和消息顺序的一致性。很多新手画时序图喜欢把消息线画成上下乱跳，或者把异步回调画成同步调用的实线，读者根本分不清等待关系。我的约定是：同步调用用实线箭头，异步消息用虚线箭头，返回结果用更浅的线往回画。这样一张图不用任何文字，读者也能从线型上读出交互语义。

状态图容易出问题的地方是漏画起点和结束态。所有状态必须能从一个明确的初始状态开始，并且至少要有一个终止条件。如果状态没有终点，说明你没想清楚这个对象的生命周期边界。

2.4 用一张判断表快速完成选型

这张表不是标准答案，只是一个快速定位工具。真正动笔前，我还会问自己一个问题：如果这张图只能用一句话向别人介绍，那句话是什么？答不上来，说明你还没理解自己画的东西。

3. 布局与视觉规范：让图摆脱“需要解释才能看懂”

内容选型对了，只是第一步。很多内容正确的图依然难读，问题出在布局、配色和文字标注这几件“看起来不够技术”的事上。恰恰是这些事，决定了一张图是被反复引用，还是被看了一眼就关掉。

3.1 布局主方向与阅读顺序

人类阅读任何视觉材料都有默认顺序，图表设计必须顺应这个习惯。我画流程和时序图默认从上到下，画架构图和模块图默认从下到上或从左到右，并且全篇保持同一个主方向。主方向一旦确定，所有连线都要尽量沿着这个方向走，实在需要回头的情况，要通过折线和旁路绕行，避免直接拉一根反向长线横穿整张画布。

反向线和交叉线是布局的头号杀手。每出现一次交叉，读者的视线就要被迫中断一次。我给自己定了个规则：如果一张图里面交叉点超过五个，必须回到布局阶段调整节点位置，而不是用“曲线连线”掩盖问题。大部分时候，只要改变某些节点的排列顺序，交叉就能消除。

节点之间的距离也要均匀。花了很多时间排出来的好图，往往没有特别夸张的长线和紧贴在一起的节点，每个相邻节点之间的距离大致相等，整个画面看起来呼吸感均匀。这个细节不需要刻意测量，只要画完后缩小到 50% 比例看一眼，哪里挤成一团，哪里扯出一条长线，一目了然。

3.2 颜色是分类工具，不是装饰工具

配色这件事，我强调两个词：克制和一致。

我见过不少图，恨不得每个框一个颜色，看起来像彩虹，信息量却一点没增加。颜色在图表里的唯一作用，是帮读者快速分组。同一个逻辑分组的节点用一种颜色，不同层级或不同性质的分组用不同色系，如此而已。一张图里，主色加辅助色控制在三个色系以内，我会用灰度做背景容器，高饱和色只用来强调异常路径或关键节点，效果反而非常突出。

还有一个容易忽略的点：颜色必须是语义化的，而不是装饰性的。红色如果代表“异常/失败”，那全图所有失败路径都要用红色，不能这里表示失败、那里表示告警；蓝色如果代表“外部系统”，那所有外部节点都要保持一致，不能因为好看换一换。颜色系统一旦建立，就必须贯穿整组图表，任何地方破坏规则，都会让读者产生困惑。

3.3 文字标注的动宾结构原则

图里的文字是最容易被敷衍的部分。很多人写完标题就把框里的文字随便堆几个名词，比如“用户管理”“订单处理”。但名词只能说明“这是什么”，说明不了“发生了什么”，读者还得靠上下文去猜。

我要求自己写节点文字时尽量用动宾短语，比如“创建订单”“校验库存”“发送通知”。一个节点是什么不重要，重要的是它在这个流程里做了什么。动宾短语让动作和对象都明确，读者不需要在脑子里做二次解析。判断框里的条件也要写完整，比如“库存是否充足”，而不是“库存？”。少几个字不一定高效，可能只是在省属于读者的认知负担。

连线上的标注同样重要。我见过太多图，节点之间就一根光秃秃的箭头，没有说明这是什么关系。如果连线没有文字也能看懂，那可以不加；一旦可能出现歧义，比如“调用”“依赖”“引用”“下发”，就必须写清楚是哪种关系。连线的文字建议直接放在线中间，并且沿线的方向书写，保证阅读连续性。

3.4 图例和统一命名

当一张图使用了自定义图标、特殊线型或分层配色时，图例不是可选项，而是必选项。即便读者是你的同事，也不保证他能记住你的每个视觉约定的含义。图例要放在图的右下角或左上角，面积不要太大，几行文字加几个小样例就够了。

统一命名则是一个更隐蔽的问题。同一套系统里，有人在图里写“用户服务”，有人在另一张图里写“user-service”，还有人写“用户中心”，三张图对不上，协作时就只能靠人肉翻译。我在画任何图之前，会先定一份名词表，把系统里的核心服务名、模块名、数据实体名各自的规范名称列出来，整套图必须一致。这个动作在单人项目里看不出多大价值，一旦团队协作，节省的时间非常可观。在一套多图文档里，我还习惯给每个节点加唯一编号，比如 S1、S2、D1，用来在不同图之间互相引用，这样“图三的 S2”就能准确指代某一张图里的某个节点。

4. 一张图从草稿到长期资产的完整流程

图纸画得好不好，除了技术，还跟工作方法直接相关。我这些年沉淀了一套自己的流程，从需求、草稿、评审到归档，每一步都有明确产出物。一开始觉得慢，习惯了以后反而比“想到哪画到哪”快得多。

4.1 第一步：列元素清单，而不是直接拖图元

打开画布之前，我先在文档里列一个清单：角色或节点有哪些，它们之间的关键关系有哪些，哪些信息属于背景备注。这个步骤花了不到十分钟，但避免了 90% 的返工。

清单写着写着，结构就会浮现出来。比如要画一个登录模块的时序图，我列出“用户、前端页面、登录接口、认证服务、用户数据库”这几个角色，然后列出“提交凭证、校验凭证、签发令牌、返回令牌、加载用户信息”这些消息。列完以后，图的骨架其实已经出来了，剩下的事情就是把这些元素按时间顺序摆在画布上，鼠标操作被压缩到了最小。

清单里还有一个必填项：图外背景。包括这张图的版本、适用场景、相关文档链接。这些信息放进图里会显得啰嗦，但不放的话，三个月后再看这张图，你很可能已经忘了当时画的是什么环境下的方案。

4.2 第二步：快速出 v0.1 草稿，再进入雕琢

第一次画出来的图永远是丑的，这是常态，没必要追求一步到位。我通常先出一版只表达结构、不注重美观的草稿，节点随便摆，连线只管语义对。草稿的用途是验证信息结构是否成立，而不是展示。

结构验证通过之后，我才会进入布局调整阶段。这一阶段我只看三件事：主方向是否统一、交叉线能否减少、节点是否对齐。记住，先结构调整，后配色加标注。顺序反过来的话，经常会出现辛辛苦苦配好色才发现某条线要重画，白白浪费时间。

排版到七八分满意的时候，我会把图放到 100% 比例过一遍细节，把文字大小统一、框距调匀、线条端点修正。值得注意的是，很多绘图工具的默认网格对齐是开启的，但对齐方式不一定是“中心对齐”，导致两个框明明视觉上在一条线上，实际差了几个像素。我习惯手动打开对齐辅助线，再逐个检查关键节点。

4.3 第三步：评审清单，五类问题逐项过

我给自己总结了一份评审清单，每次画完图都过一遍，很管用：

• 第一类：读者问题。找一个没参与过这个项目的人来看图，问他图里哪个部分最看不懂。他卡住的地方，就是信息密度太高或抽象层级混乱的地方。
• 第二类：语义问题。检查每个节点是“名词”还是“动宾短语”，每条连线是否有明确的关系语义，是否出现只有你自己懂的缩写。
• 第三类：结构问题。主方向是否统一，层级是否清晰，有没有交叉线超过五个的局部，是否需要拆图。
• 第四类：视觉问题。颜色是否克制、字体是否一致、对齐是否整齐、图例是否齐全。
• 第五类：维护问题。图源文件是否保存，是否容易修改，节点是否编号，配套文档是否备注了更新时间和作者。

这五类问题看着多，熟练了以后十分钟就能过完。我把它写成一个固定动作，也是因为人一旦对某张图熟悉了，就会对它变得迟钝，很多明显的问题反而看不见。找个人重新看一遍或者强制按清单过一遍，是打破这种惯性的好办法。

4.4 第四步：归档时保存“图源文件+导出图+说明文字”三件套

很多人画完图，只导出一张 PNG 发到群里，图源文件随手丢弃。三个月后需求变了，别人只能对着截图叹气，或者照着截图用方块重新拼一张。

我现在的强制规范是，每张图发布时必须同时保留三件套：可编辑的源文件、高清导出的图片、一段说明文字。说明文字里写清楚这张图解决什么问题、当前版本有什么已知限制、下次改动最可能从哪里入手。如果工具支持版本管理，我会把图源文件打上版本标签，和代码提交记录关联起来。

这套习惯看起来琐碎，但真到接手别人项目时，或者三个月后回看自己项目时，你会感谢当初留下图源文件的自己。一张只靠图片存活的图，称不上文档，只能算临时沟通材料。

5. 我踩过的那些坑和对应的排查思路

再好的理论，不踩几个坑都很难内化。这些年我也画废过很多张图，下面挑几个印象最深的，把当时的排查过程写出来，供你借鉴。

5.1 坑一：连线错位，节点位置和连接点脱节

有次画一张系统架构图，几十个节点，连线都是我手工拉的。画完从整体看效果还行，但放大细节时发现，好几条连线明明指向 A 服务，箭头却落在 B 服务的边框上。排查后发现，问题出在节点的连接锚点上——我移动了节点位置，但连线还依附在旧的锚点坐标上，手工拉线时对得不准，一缩放就偏差。

这种问题靠肉眼很难彻底避免，后来我总结出两个办法。一是尽量使用工具自带的弹性连线，让连线自动吸附到节点边缘，不要手动微调每根线的端点；二是画完之后专门做一次“连线归属检查”，用鼠标点一遍所有连线，看选中以后高亮的节点是哪几个。这个过程虽然机械，但能很快找到指向模糊的线。还有一个更彻底的办法：拥抱文本化设计，用代码表达节点和边，由布局引擎统一计算坐标，从根上消灭手工错位。

5.2 坑二：循环依赖把布局引擎搞乱

用自动布局工具画模块依赖图时，有一阵子我发现输出的图里总有几个节点被排到很远的地方，连线绕来绕去，像一团乱麻。排查时无意中发现，循环依赖是罪魁祸首——A 依赖 B，B 依赖 C，C 又依赖 A。自动布局引擎遇到环状依赖时会尝试把整个环最小化，结果几个节点被硬生生拉到一起，其他节点被迫挤到边缘。

从那以后，我在画依赖图之前会先做一步静态检查：把依赖关系列成清单，找出所有循环依赖。环状依赖在工程上本来就是一个需要重点关注的隐患，它不只会让图变乱，本身也暗示着设计上有循环调用的味道。发现环之后，先把环打破或者明确标注，再交给布局引擎排出整齐的图。这样既解决了图的显示问题，也顺手暴露了系统里的架构坏味道。

5.3 坑三：长文本节点把整张图撑变形

有一版流程图表，我在某个节点里写了一整段描述文字，结果那个框变得巨大，周围节点全被挤开，整体布局瞬间全毁。这是很多文本类图表工具最让人头疼的地方，节点尺寸一旦由内容决定，长文本就会成为布局的不可控变量。

排查过后，我立了三条规矩：节点文字最多不超过十个字，超过的拆成标题和备注，备注放在图下方而不是框里；实在要放长文的，给节点设置固定宽度，超出部分用省略号。更本质的解决思路是，图表达的是关系，不是详情，详情文字该放进配套文档而不是塞进图里。

5.4 坑四：多图协作时同一概念多种画法

团队协作中还有一个坑，比单个图画错更隐形：同一个“订单”实体，一张图里叫“订单”，另一张里叫“order”，还有一张里画成一个圆角矩形，另一张里画成圆柱体。东西是一回事，表达方式五花八门，读者对不上号。

后来我在项目里推行统一图例规范，核心实体怎么画、失败路径用什么色、外部系统用什么形状，都提前定好，并且沉淀成一份模板。新画图的人直接基于模板创建，不要从空白画布开始。从那以后，整套文档的阅读成本直线下降。现在这已经是我的默认工作方式了：任何成体系的图表文档，先定规范，再画第一张图。

6. 文本化设计：我用下来最推荐的工程化方案

如果你问我现在画图首选什么方式，我会毫不犹豫推荐文本化设计。特别是系统架构图、时序图、ER 图这类信息结构明确的图，用文本描述节点和边，让布局引擎去计算坐标，效率和可维护性都远高于纯手工拖拽。

6.1 拖拽式与文本化的取舍

拖拽式工具的优势是上手快，即时看到效果，适合画草图和自由结构很强的图。但它的劣势同样明显：手工对齐耗时、图源文件通常不是文本、团队协作时难以代码评审、无法自动生成和批量修改。

文本化设计用代码描述图结构，天然具备几个好处：源文件可以放进代码仓库做版本管理；改图就是在改文字，适合做代码评审；可以接入自动化流程批量生成；布局交给引擎，基本不会出现手工错位和交叉线过多的问题。缺点也有，比如自由度有限、复杂自定义布局不如拖拽式灵活、学习曲线稍微陡一点。对技术类图表来说，文本化带来的收益远远大于损失，我现在的默认方案就是文本化。

6.2 一个最小可读的文本图示例

任何文本绘图语言都逃不开几个核心概念：节点声明、连线方向、子图分组、样式分类。下面用一段极简示例说明，语法本身很容易理解，具体命令以你手上工具为准。

// 节点声明：方括号表示普通节点，圆角表示决策节点 A[收到用户请求] B[校验参数] C{参数合法} D[调用核心服务] E[返回错误提示] // 连线方向：从上到下的主阅读顺序 A --> B B --> C C -- 是 --> D C -- 否 --> E

这段示例表达了一个最简单的分支流程。关键不在于语法，而在于它证明了文本化设计的核心逻辑：你只描述“谁是谁、谁连谁、怎么连”，剩下的坐标和布局全部交给引擎。对动辄几十个节点的系统架构图，这种写法的维护成本比拖拽低一个量级。

6.3 让图表跟随代码和文档一起演化的实践

文本化设计真正发力的地方，是把它接入到工程的日常流程里。

我现在的工作习惯是：把图源文件和代码放在同一个仓库，文档更新和代码提交绑定在一起。设计评审时，大家 review 的是图源文件的变更记录，而不是对着导出的截图猜改动。接口有变动，顺手在图源文件里把消息线改掉，提交记录里就同时留下了代码和图纸的变化痕迹。这比“代码改完了再回头更新文档”要自然得多，也不容易遗忘。

还有一步进阶操作：自动生成图。从数据库表结构、接口定义、容器部署清单这类机器可读的元数据里，用脚本批量生成对应的 ER 图、接口调用图、部署拓扑图。图不再是人工维护的第二份文档，而是元数据的一个视图。元数据一更新，重新跑一遍脚本，图就自动更新了。到了这个程度，图表的维护成本被压到最低，你画图的心思可以全部花在信息设计和结构设计上，而不是花在鼠标对齐线条上。

我自己现在画任何正式图纸，都会先问三个问题：读者是谁、表达什么结构、能不能用文本描述。三个问题想清楚了，再难画的技术图也只是一个执行问题。别人看我的图说“挺规整的”，其实我只是把大部分踩过的坑都提前堵上了而已。