图表设计这件事，我前前后后折腾了三四年。做过的图没有一千也有八百，从最初拿拖拽工具一朵一朵画箭头，到后来用文本描述直接生成整套架构图，中间经历了很多次“改图改到怀疑人生”的瞬间。这个项目标题“diagram-design”看着简单，但我越来越觉得，图表设计绝不是“把方块和箭头摆上去”这么简单，它背后是一套关于信息结构、视觉层次、可维护性和协作效率的综合工程。这篇文章就把我这些年踩过的坑、攒下来的经验，一次性拆开来讲清楚。

1. 先聊清楚：图表设计到底是做什么的

很多人在刚开始接触图表设计时，会把注意力全放在“用什么工具画得好看”上。但实际上，图表设计的核心从来不是工具，而是信息表达。一图胜千言这句话没毛病，但前提是这张图真的能把事情讲清楚，而不是把简单的事情搞得更复杂。

1.1 图表设计的本质是信息架构

我见过太多人画流程图，拿到需求就开始拖矩形、拉箭头，画到一半发现结构错了，又从头来一遍。这种“先画再想”的做法，其实是在用战术上的勤奋掩盖战略上的懒惰。图表的第一步不是画图，而是梳理信息结构。

所谓信息架构，就是搞清楚这张图要表达什么、读者是谁、信息节点之间是什么关系。就拿最常见的系统架构图来说，你面前摆着十几个服务组件，如果你一开始不明确它们之间的调用关系、依赖方向和部署边界，画出来的图一定是乱的。这个道理放在流程图、时序图、思维导图里也一样。

我个人的习惯是，先用纯文本或简单的列表把信息层级列出来，确认结构没问题，再考虑怎么画。这个过程就像写文章先写大纲，而不是拿笔就开始写正文。你画图之前想得越清楚，后面动手就越快，而且改动的成本会低得多。

从技术角度说，这种“先结构后视觉”的做法对应的是一个经典理论：人脑对视觉信息的处理是分层的，先感知整体轮廓，再聚焦局部细节。如果你的图层级混乱、连线交叉、节点随意摆放，读者会在“识别结构”这一步就卡住，根本没精力去理解内容。所以，图表设计的第一原则是结构优先，其次才是好看。

1.2 图表设计解决的是什么问题

展开来说，图表设计至少解决三类问题。

第一类是沟通问题。一个复杂的业务流程，如果靠文字描述，写满两页 A4 纸别人可能还是看不懂，但一张流程图放在那里，三十秒就能建立共识。跨岗位协作时尤其明显，开发、产品、运营看同一张图，理解偏差会大大降低，因为图形本身就是一种更接近共识的语言。

第二类是决策问题。架构评审、方案选型、性能瓶颈分析，这些场景里图表承担的是“把信息压缩成可决策的视野”的功能。当你把系统节点、调用关系、数据流向画在同一张图里，你更容易看出哪些环节是瓶颈、哪里存在单点故障、哪里链路过长。这就是为什么技术人员在开会时总喜欢在白板上画图——画出来才有讨论的基础。

第三类是知识沉淀问题。好的图表本身就是文档。一个新同学加入团队，与其给他一本厚厚的设计文档，不如给他一份清晰的架构图、一份时序图，他很快就能建立起对系统的心智模型。这也是为什么很多项目在交付时，文档里最关键的部分往往不是文字，而是那些图表。

2. 工具选型：代码化制图与拖拽式制图的取舍

工具选型这个章节，我觉得是这篇内容里最值得讲的。因为工具选错，后面全盘皆输。我两套流派都用过，各有各的好，也各有各的痛，这里做一个系统性的对比和分析。

2.1 两套主流方案的实战对比

目前主流的制图方式，大致可以分为两大流派：代码化制图（用文本描述生成图）和拖拽式制图（通过可视化画布操作元素）。

代码化制图的代表是Graphviz、PlantUML、Mermaid这类工具，它们本质上是通过一种结构化描述语言，将文字转化为图形。拖拽式制图的代表则更多，像各种白板类的、绘图类的、设计类的工具，操作方式符合直觉，所见即所得。

我拿一个真实的使用场景来对比。当时我在维护一套老系统的架构文档，系统有二十多个服务模块，需要根据不同时期的需求画好几版架构图。用代码化制图时，维护成本很低：改一个服务的名称，改一行文字，重新生成一下，图就更新了。用拖拽式制图时，我需要在画布上找到那个矩形，双击改文字，如果布局被自动调整破坏了，还得手动重新拖一遍。

从协作角度看，代码化制图天然适合放在版本管理工具里做差异对比。这周架构图改了哪一块，用查看文件变更的功能就能看到，拉一个请求就能评审，非常符合研发团队的协作习惯。拖拽式制图在这方面的体验就比较弱，它虽然也支持协作，可以多人同时编辑，也可以导出各种格式，但版本对比和精细评审一直是痛点。

不过拖拽式制图也有它不可替代的优势，它表达自由度极高，交互感强，适合脑暴、即兴讨论、快速示意。你可以在画布上自由地贴便签、画圈、连线，根本不需要考虑任何语法，拿起就用。而代码化制图有明显的“描述门槛”：你脑子里想的东西要先转化成文本语法，语法不熟练的时候，光是解决格式报错就能耗掉不少时间。

我分享一个自己的判断逻辑。如果这张图是一个人一次性画完然后就不再改动，比如给汇报用的临时流程图，拖拽式制图更爽快。如果这张图要长期维护、频繁更新、多人协作、放进版本管理里，代码化制图是更省心的选择，因为它把图形变成了有版本痕迹的纯文本资产。如果团队里大部分人不熟悉任何一门制图语言，那就先考虑拖拽式，用起来顺畅度优先。

2.2 从实际项目看选型的心路历程

举一个我印象比较深的例子吧。大概是两年前，某团队在规划一个跨平台系统的架构设计，需要产出多张图：系统总览图、模块交互时序图、数据库关系图、部署拓扑图。最开始大家用的都是拖拽式画图工具，各画各的，画得确实挺好看，配色统一、图标精美。但问题出现在需求变更之后，需求方说要加一个中间层模块，这一加，八张图的联动都要变。每张图都得手动找到相关位置重新连线、调整布局，光改图就花了大半天，还漏改了其中两张。

后来我们做了一个决定，把所有图表改用代码化制图重写。起初有阻力，因为几个同学对这些工具不熟悉。但当他们把每张图的描述文本维护起来之后，第二次需求变更时效果就出来了：改了描述文件里的三个动词，重新生成图，所有关联图表同步更新，前后用时十分钟。

我总结一下这次选型复盘的核心结论：重逻辑的图用代码化制图，重表达的图用拖拽式制图。什么叫重逻辑？系统架构、流程图、时序图、状态图、数据关系图，这些图的结构性强，信息之间有严格的逻辑关系，用代码描述反而清晰。什么叫重表达？甘特图配色想自定义、营销活动流程图想画得活泼一点、产品示意需要手绘质感，这些图追求的是表现力，拖拽式制图更合适。

工具选型还涉及一个重要的隐性成本：学习曲线。代码化制图确实需要学语法，但好在主流语法都不难，基本的节点和连线用法，一个下午就能上手，后面就是边用边查。而拖拽式制图看似没有学习门槛，但你对它越依赖，图表资产沉淀反而越弱，因为最终产出的只是一张静态图片，很难追溯它的演进过程。从这个角度看，代码化制图对技术团队和需要长期维护图表的团队更友好。

3. 图表设计的核心原则：从一块白板到一张好图

工具选完，真正拉开差距的是设计能力本身。同样的信息，有的人画出来的图干净清楚一目了然，有的人画出来就是一团乱麻。这里面的门道有些是通用的设计原理，有些是图这个载体特有的细节规范。

3.1 分层：一张图画不下的时候就不要硬画

我见过的最常见的图表设计错误，就是试图在一张图里塞下所有信息。有一次一个同学把他负责的系统架构画成一张图，里面包含了十几个服务、几十条连线，还额外标上了每个服务的端口号、数据库名、负责人名字。出发点是好的，信息全面，但效果是灾难性的。那张图缩放之后根本看不清楚，放大之后又看不到全局，完全没有可用性。

这里我强烈建议一个做法：分层制图。把信息按照阅读层级拆成多张图。第一层是系统全局视图，只画核心模块和最粗粒度的关系；第二层是模块内部视图，展开某一两个关键模块的细节；第三层是专项视图，专门画网络拓扑、数据流转或者部署结构。每一层服务不同的读者和场景，全局视图给决策者看，专项视图给执行者看。

这个思路其实和地图的分级很像。你去一个城市，先用城市地图确定区域方位，再用街道地图找具体路线，很少会需要一张图同时精确到城市边界和某栋楼门牌号。信息量大了之后强行放在同一张图里，本质上是让读者替你做筛选的工作，这不合理。所以我在做设计时经常会问自己一个问题：这张图的核心读者是谁，他最关心哪一层的信息？想清楚之后，做图反而更轻松。

经过分层处理以后，还有一个好处值得单独说一说：它直接提升了图的演进能力。当你把大图拆成互相独立又通过命名关联的小图，系统的某个部分变化时，只需要更新对应那一张图层，前端总览图只需调整关键边界文本，其他图完全不受影响。这一点，对于长期活着的项目而言非常重要。

3.2 布局：连线的走向决定了图的“气质”

除了分层，布局是图表设计里最需要下功夫的地方。我观察到一个规律：混乱的图几乎都是连线造成的。节点乱可以拖正，但连线交叉、绕路、跨越一堆无关节点，图的阅读体验直接就毁了。所以在画图时，我一般会刻意遵守几个布局规则：

第一，主流程从左到右或从上到下。大多数看图习惯是从左往右读，少数从上到下（比如时序图）。不要在同一个流程里一会儿从左向右流动，一会儿又从下往上回流，那会让读者非常难受。遇到必须要回传的流程，宁可拆成子流程，或者把回传线画在整张图的下方，不干扰主流程的阅读。

第二，连线尽量少交叉，甚至不交叉。一个简单实用的检查标准是：看着草图，数一下交叉点数。3 个以内的交叉属于可接受范围，超过 5 个交叉，建议重新排列节点顺序。很多拖拽制图工具都有自动布局功能，但自动布局并不总是最优，它经常为了减少交叉把节点排得很畸形。所以我会把自动布局当成初稿参考，手动微调终版。

第三，保持节点之间的对齐与间距。我习惯把同层节点设置为相同尺寸，设置为统一的行间距和列间距，整张图看起来会非常整洁。这就像Excel表格里的单元格，你对齐了，阅读感立刻不一样。很多代码化制图工具天然支持这类对齐，因为加入了布局算法的支持。

我举个实际例子。画一个订单处理流程图，流程经过“提交订单、校验库存、扣减金额、生成物流单、通知用户”五个节点。最简单的画法就是五个节点排一条线，箭头依次指向下一个，干净利落。但有人就是会把校验库存画成回到提交订单的循环，扣减金额失败时也画一条长线回到开头，最后整张图全是交叉线。更好的做法是：主流程保持一条直线，异常分支统一画到图下方一个“异常处理”子流程区域，主流程的清晰度完全不受影响。

3.3 统一：配色、字体、图形语言的一致性

图表设计还有一个很影响专业度的细节：视觉语言的一致性。这里的“一致”包含三层含义：同样的语义用同样的形状，同样的层级的节点用同样的配色，同样的文字用同样的字体和字号。

我一直对“用形状表达语义”这一条比较较真。流程图里矩形表示处理、菱形表示判断、圆角矩形表示起止状态，这东西虽然看起来很基础，但真的有很多人不遵守。一旦大家在同一张图里肆意换形状，读者必须在脑子里不停做映射和判断“这个圆角矩形和那个圆角矩形是不是一个意思”，阅读效率极低。我在做图时尽量画出风格统一的图形库，或者用代码化制图的能力统一形状规则，这就是把人力和规则都前置。

配色方面，有一个常用的做法是单色系+少量强调色。基础节点全部用同一种浅色调填充，边框稍深一点；关键节点、告警节点、当前焦点节点用强调色标出来。全图不超过三种主要颜色，每个颜色都有明确的语义。你画出五彩斑斓的图，读者会迷失在颜色里，完全无视结构。这里需要注意背景对比度，浅色填充用深色文字，深色填充用浅色文字，标题字号不小于正文的两级，保证从远处或缩略图上都能看结构。

另外，字体选中时别忘了一个细节：在中文场景下要让字体支持中文显示，否则渲染出来就是一片方块乱码。这个问题我在后面“常见问题”部分会详细讲。但“字体是否统一、是否支持中文”如果在设计初始阶段就设好，后面会省掉很多返工。

整体上，我会把统一性理解为“职业感”的来源。同样内容的两张图，一张形状统一、配色克制、间距舒适，另一张随手画、形状乱用、颜色刺眼，相信你也会瞬间对第一张图的作者更放心。图表不只是一份说明材料，它也是你工作质量的露出窗口。

4. 实操全流程：从需求到成图的完整过程

前面铺垫了很多原则和思考，这一节我们把一套完整的流程走一遍。这里我以“某个系统订单模块的异常处理流程图”为例，从接到需求到最终交付，一步一步来。为了让内容可参考，我会先说明设计输入，然后给出每一步的思考过程和具体操作。

4.1 第一步：确认边界与核心事件

画图之前我先确认几个问题：这张图描述的是正常流程还是异常流程，还是整合流程？读者是谁，开发同学需要看到的具体判断是什么，还是测试同学需要看到的异常分支有哪些？图需要涵盖多大的范围，只画到系统内部，还是含外部接口调用？

回到例子。我要画“订单支付的异常处理流程”。确认后的范围是：从用户提交支付开始，到支付结果返回给用户为止。包括渠道超时、余额不足、重复支付、风控拦截这几类典型异常，每类异常对应的处理动作和用户提示。读者主要是开发同学，因此图中每个判断点都要能对应上代码逻辑里的分支条件。

范围明确之后，我开始列文本草稿。用最简单的文字描述把流程写出来，类似：

1. 用户提交支付请求
2. 系统创建支付单
3. 调用支付渠道
4. 支付渠道返回结果
5. 结果判断，无非“成功”进入下一步，“失败”“处理中”走异常分支
6. 成功则更新订单状态、通知用户
7. 失败则根据失败原因细分处理（余额不足、风控拦截、渠道超时等）
8. 渠道超时则发起主动查单，再根据查单结果决定最终状态

这一步完全不碰工具，就在文本编辑器里写。为什么这么做？因为我发现文字推演是发现问题成本最低的手段。你会发现有些分支缺失、有些环节语义重复、有些判断条件没写全，这些在文本阶段就能暴露出来，不需要等图画到一半才去返工。

4.2 第二步：设计节点清单与关系表

文本草稿确认之后，我把它整理成结构化的节点清单。这一步我会打开一个表格，列出每一行的节点名称、节点类型、指向。这是最关键的一步，它把“图”还原成“数据”，后面无论用什么工具，你都只是在渲染这张关系表。

我给这个例子给出简化版的关系表（只列一部分）：

做这张表的另一个好处是，它可以给后续编码实现提供最直接的对照。开发同学看到这张关系表，几乎可以直接对着写伪代码和测试用例了。我画图这么多年，最深的体会是：图表的终点不一定是漂亮的视觉，而是精确的信息关系表。表做清楚了，图就是水到渠成的事情。

4.3 第三步：用代码化制图产出初稿

关系表整理好，第三步就是把它翻译成制图语言的描述文本。我以目前用得最多的标记语言为例，因为它生态广，渲染方式多样，能嵌入各种文档系统，对新手也比较友好。上面这个流程，翻译成代码大致是这样（这是示例，具体语法版本会有差异，但核心结构一致）：

flowchart TD A[提交支付请求] --> B[创建支付单] B --> C[调用支付渠道] C --> D[渠道返回结果] D --> E{结果是否成功?} E -- 是 --> F[更新订单状态并通知] --> F1[结束] E -- 否 --> G{失败原因分类} G -- 余额不足 --> H[返回余额不足提示] --> H1[结束] G -- 风控拦截 --> I[返回风控拦截提示] --> I1[结束] G -- 渠道超时 --> J[发起主动查单] J --> K{查单结果是否成功?} K -- 是 --> F K -- 否 --> L[标记订单异常并告警] --> L1[结束]

这段描述文本一渲染，就能得到一张结构基本正确的流程图初稿。虽然视觉上可能还不够精致，但骨架已经完全对了。接下来的环节是优化视觉细节，我把标题添加进图节点的注释区，把判断条件的文本语义理顺，确保动词一致：“提交、创建、调用、返回、更新、通知、标记、告警”，全局一致。

4.4 第四步：参数调优和视觉打磨

初稿出来之后，进入视觉打磨阶段。这个阶段，很多人会改得比较随意，但我建议把“视觉参数”也当成代码或文本的一部分来对待，记录下你调整过的那些关键值，形成属于自己团队的一套风格基线。下面分享几个我常用的指标数值。

节点内边距：我会给节点内部的文字留足呼吸空间，上下至少 8px，左右至少 16px。拿到的感觉是节点不至于“顶着字”，也不会显得空。

节点圆角：圆角值会影响图的整体气质。直角锐利，偏工程感；大圆角圆润，偏产品感。普通业务图，我一般取 6px 到 8px；状态机的节点我会用 10px 到 12px，看起来柔和一些。

连线风格：普通执行流我习惯用实线箭头，默认箭头样式是单向；异常流或回调用虚线。虚实的区别本身就携带语义：实线是确定性路径，虚线是可能发生或备用路径。一条虚线画出来，读者就能读懂“这是个兜底逻辑”，理解成本非常低。

字体字号：标题我一般用 16px 加粗，节点内文字用 14px，辅助注释用 12px。这套阶梯在大多数展示场景下表现稳定。

对于布局方向，这个流程考虑纵向结构，从上往下。但你们团队如果习惯横向阅读，我会把开头几个节点排成一行，让主路径横向，判断分支放在主路径下方。这里也常遇到有同学问，为什么代码化制图生成的布局看起来不够“紧凑”？原因其实是布局算法优先保证的是“无重叠”和“连通清晰”，它不考虑“紧凑”。你在调布局时，适当地使用分组，把相关子流程包在一起，用子图来组织归属，视觉“紧密度”会提升非常明显。

4.5 第五步：检查、导出与归档

图最终完成后，我会执行几个固定的检查动作。第一个动作，查孤立节点：有没有一些节点没有连入任何路径，那通常意味着遗漏了关系。第二个动作，查语义歧义：例如“结束”节点的含义是否一致，是流程正常结束，还是异常终止，最好用不同形状或不同标记区分开。第三个动作，查文字可读性：放大到实际展示比例，确认文字没有溢出节点边界，缩放到 80% 确认缩略状态仍能看清主要分支。

检查通过后就是导出环节。绝大多数场景下我会导出两种格式：矢量格式用于后续印刷或高清展示，因为矢量图无限缩放不模糊；PNG 格式用于嵌入文档和即时沟通。如果你会用一些代码化制图工具，它们通常都支持直接嵌入到文档或网页，把代码块放在文档里，预览自动更新，这种“文档即图源”的方式，对长期维护非常友好。我个人现在做图时会尽保留源文件，而不是只保留一张渲染后的图片。源文件就是那套文本描述，它可以再次编辑、对比、回溯。“图比源文件活得久”这件事，踩过坑的都知道有多痛。

最后归档时，我会给文件命名加上版本号和日期。比如“订单支付异常流程_v2_20241130.txt”，里面记录修改时间和修改人。这不是画蛇添足，因为图表维护最怕的就是“神秘更新”：一张图谁改过、基于什么需求改的、为什么改，全都不清楚，时间久了这张图的可信度就会归零。

5. 常见问题与排查手记：我踩过的坑和补救办法

理论聊了很多，这章我们落地到实际问题。这几年在图表设计上踩过的坑还挺多，我把最典型的几个归纳出来，附上我的解决思路，希望帮大家少走弯路。

5.1 中文内容渲染出现乱码

代码化制图工具对中文的支持参差不齐。刚开始我用某个工具渲染包含中文的图时，导出的图片里中文全部变成了方框，当时直接把所有中文字体方案试了一遍，才明白问题出在字体配置上。解决方案是显式指定一个支持中文的字体，例如在代码里通过 fontFamily 参数，或修改环境级配置文件来指定“Microsoft YaHei”“PingFang SC”“Noto Sans CJK SC”这类中文字体。如果你是在远程环境里生成图，还可以在系统层面安装中文字体包，这一步经常被忽略。

这个问题的排查速度有一个比较有效的方法：先在终端里执行一次字体检测，看看系统中是否已经安装了目标中文字体；没有的话就安装；再渲染，问题基本就消失了。这事听起来很基础，但确实会浪费新同学一个下午。

5.2 布局失衡，图“一团乱麻”

用代码化制图时，自动布局偶尔会给你生成一张不是预期的图。比如你想要树形展开，结果发现节点全挤成一团，连线交叉严重。此时我先检查有没有使用分组与层级折叠，很多排版混乱是因为节点没有层级，所有节点在同一个层级里横向铺开，宽度直接失控。把同一层级的节点用子图分组包裹，再在每个分组内部单独排列，导出的图会清晰很多。

如果还是乱，我会手动调整节点之间的相对位置参数，给核心节点一个确定的坐标，让其他节点围绕它布局。这里想提醒的是：别为了追求自动布局的最优解反复重试上百次，手动指定少数几个锚点反而是最快路径。

5.3 图太大，一张 A4 纸根本装不下

图大是另一个高频问题。几十个节点的架构图，全部打印到一张A4纸上，字变得比蚂蚁还小，这个方案不适合阅读。我的习惯是：如果图的主要内容超过 30 个节点，先做分层，把非核心细节放进二级图；如果单张图节点数在 10 到 25 个之间，可以用 A4 横向版式，保持字号 12px 以上，留出页边距；超过这个规模，该拆分就拆分，硬塞只会两头不讨好。在某些工具里还可以通过调整“页面尺寸”参数直接控制画布的大小，我建议直接设置一比一输出，而不是强行缩放，免得字体被拉伸变形。

5.4 多人维护同一张图，改来改去改崩了

这个坑最惨痛。多人一起用拖拽式画图工具维护架构图时，经常出现某一次编辑把别人精心调整的布局全部打乱，或者保存冲突覆盖了最新修改。代码化制图配合版本管理就能自然避开这个问题，因为文本合并比图形合并容易得多。使用这个方案时，我给大家一个规范：每张图单独一个文本文件，文件名带上图名，每次修改通过提交说明来备注“改了什么、为什么改”。这样就算有人改崩了，也能通过版本回滚找回上一版，不会造成不可逆的损失。

另外建议在文件头部把这些图表的维护说明写清楚。比如定义好节点命名规则、子图命名规范、是否允许其他人改动布局参数等。别看这些规矩简单，它们能让多人协作的图表资产稳定很多。

5.5 图表设计问题排查速查表

为了方便查阅，我把上面几个高频问题做成一张速查表，情况描述、排查方向、解决建议放在同一行里。

这张表不只是排查问题，它其实也是在提醒我们：图表设计本质上是一个需要“预留维护入口”的工作。你设计的不是一张静态图，而是一个能持续反映系统真实状态的动态资产。一个小技巧是，每次改完图，在提交说明里写清楚这次修改的关联需求编号，三个月后再回来审这张图时，你还能想起来它为什么长这样。

6. 设计之外：图表资产的管理方法与工作流建议

图表本身很重要，但图表资产的管理方式直接决定了它能否持续发挥作用。最后一节我聊一聊图表怎么和日常工作流配合。

6.1 把图表塞进已有的文档系统

技术团队的日常产出通常依赖文档系统，比如知识库、项目文档、Wiki 等。如果你是使用代码化制图，我强烈建议直接把制图代码块内嵌到文档里，而不是贴一张静态图。这样做的好处是当源码更新时，预览可以跟着一起变，不需要手动替换图片。很多主流工具链都支持这种嵌入，使用起来就像写代码一样，渲染结果自动展示在文档对应位置。

我也建议给每类图设定固定的“存放位置”。比如架构相关图表统一放在某个固定目录下，流程相关图表又放另一个位置，不要随意丢在个人空间。固定位置意味着团队能形成习惯：要看系统结构，知道去哪里；要更新业务流程图，也知道去哪里。不要小看这种组织习惯，它积累下来，图表资产就从“一次性产出”变成了“团队共同维护的知识库”。

6.2 用“图章”机制保证图表的可信度

图表一旦进入维护流程，它就可能过时。一个过我时的架构图，比没有图更危险，因为它会误导人。我通常会在图里显示文档的最近一次更新日期，并加一个“状态图章”，比如“已评审”“开发中”“已过时待更新”。在图表未及时更新时，读者只要看一眼状态就会提高警惕，不会盲目照单全收。

状态标记可以是一个小小的文本标签，放在图标题旁边即可。我用一个约定：主标题始终保持当前图的真实状态，避免含糊的词。如果确实是旧图，我会第一时间在日期旁打上“请以最新代码为准”的注释，宁可粗暴也不能误导。有些团队甚至会把过期图直接标记为红色边框，就是想把“这张图还不一定对”的信号传递得更明显。

6.3 制图前两分钟快速评估法

最后分享一个我自己平时用的小方法，每次要画图时先花两分钟做快速评估，回答三个问题：

第一，这张图你想让读者做什么？是了解全貌、定位当前位置、追踪一个流程，还是理解一个数据结构。需求不同，图的结构设计就不同。

第二，这张图的更新频率高不高？如果是一个每周都要随需求变化的流程图，代码化文本才是长寿之道；如果是一次性汇报示意图，拖拽式画清楚就好。

第三，你希望这张图和别的图产生关联吗？系统架构图常常被其他文档引用，如果你需要跨图引用，给每个节点定义好全局唯一标识，以后引用时直接按标识关联，变更时不需要全文搜索替换。

把这三个问题想清楚，你基本就能决定采用什么工具、什么布局策略、什么维护方式。这个方法不算复杂，但它逼着你在动手之前先想清楚，长期坚持下来，制图效率和图表质量都会有质的提升。

图表设计这个东西，表面看是一门“画图”的技术，深了看是一门“组织信息”的学问。画了这么多年图，画得越久越觉得，真正厉害的设计不是堆满信息，而是知道该删掉什么；能让人一眼看懂，比画得精致漂亮重要得多。希望这篇内容能帮你在下一次画图时找到更顺手的方式，让你和你的图表共事得轻松一些。