1. 从"diagram-design"这个标题能读出什么第一次看到"diagram-design"这个标题，我的直觉是：这大概率不是一个单纯的"画图工具推荐"或者"设计规范文档"，而是一个把图表设计这件事当成一个完整工程问题来对待的项目。为什么这么说？因为如果只是教人怎么画流程图，标题通常会写成"flowchart-tutorial"或者"diagram-guide"；而"design"这个词放在后面，意味着它强调的是设计决策——也就是"为什么这张图要这样画""什么场景该用什么图""怎么让图真正传达信息而不是制造噪音"。图表设计这件事，看起来门槛很低，实际上坑极多。我见过太多团队，技术能力很强，但一画架构图就变成"方框加箭头大乱炖"，读者看三秒就放弃。也见过不少人在做技术分享时，PPT里的图信息密度过高，讲的时候自己都找不到重点在哪。这些问题的根源，都不是"不会用工具"，而是没有把图表当成一种需要设计的信息产品。所以这篇内容，我想围绕"diagram-design"这个核心，把图表设计从认知层、选型层、执行层到维护层完整拆一遍。适合谁看？三类人：一是需要频繁输出架构图、流程图、时序图的技术从业者；二是要做汇报、写文档、做知识沉淀的职场人；三是对信息可视化有兴趣、想让自己的图"一眼就懂"的创作者。不管你用的是哪款工具，这套思路都能直接迁移。我自己的经验是，图表设计能力带来的回报被严重低估了。一张好的架构图，能让新人在半小时内理解一个跑了三年的系统；一张糟糕的图，能让一个小时的评审会变成互相猜谜。下面我就按我实际做项目时踩过的顺序，一层层展开。2. 图表设计的第一性问题：图到底为谁而画2.1 先定读者，再定画法很多人画图的第一步是打开工具，第二步是拖方框。这个顺序是反的。正确的第一步应该是问自己：这张图给谁看，他看完要做什么决策？我举个真实场景。同一个后端服务，如果给运维看，重点是部署拓扑、实例数量、依赖的外部组件；如果给新入职的开发看，重点是模块划分、调用关系、数据流向；如果给管理层看，重点是业务价值链路和关键节点。这三种读者，画出来的图完全不一样，甚至用的图形语言都不同。我踩过的一个坑是：早期做系统设计文档时，我画了一张"全能图"，既想展示部署，又想展示调用，还想展示数据模型。结果评审时，运维问"实例在哪"，开发问"这个箭头是同步还是异步"，谁都没得到答案。后来我改成一图一目的，同一套系统画三张不同视角的图，反而所有人都看懂了。所以这里有个硬性原则：一张图只回答一个问题。如果一张图需要配一大段文字解释才能看懂，那这张图本身就是失败的。2.2 信息层级：什么该画，什么必须删图表设计的本质是信息取舍。新手最容易犯的错是"什么都想画上去"，因为怕漏掉信息。但读者的注意力是有限资源，你画得越多，重点越模糊。我的做法是给每个元素打一个"必要性标签"：元素类型判断标准处理方式核心节点去掉后图就讲不通必须保留，视觉加重支撑节点解释核心节点如何工作保留，视觉弱化背景信息只是"顺便提一下"移到图注或正文实现细节只有特定角色关心单独出图这个表格我几乎每次画图前都会在脑子里过一遍。实测下来，一张图里核心节点控制在5 到 9 个是比较舒服的区间，超过这个数量，人眼就开始"扫读"而不是"理解"了。这不是玄学，是认知负荷的基本规律——工作记忆能同时处理的组块数量就那么多。提示：如果你发现核心节点超过 9 个，通常说明这张图承担了太多职责，应该拆图，而不是硬塞。2.3 图表不是装饰，是论证工具这一点我想特别强调。很多人把图当成"文档的配图"，觉得文字是主角，图是点缀。但在技术沟通里，图往往是论证的主体。一张好的架构图，本身就在论证"这个设计是合理的"——它通过清晰的边界、合理的分层、明确的依赖方向，让读者自己得出结论。反过来，一张糟糕的图会暴露设计的混乱。我有个习惯：画图的过程就是检验设计的过程。如果我发现某个模块的箭头怎么连都别扭，那大概率不是画法问题，而是设计本身有问题。图是设计的镜子，画不顺，说明想不清。3. 图表类型选型：别用流程图硬套所有场景3.1 常见图表类型与适用边界选错图表类型，是比画得丑更严重的问题。我整理了一张对照表，覆盖技术场景里最常用的几类：图表类型核心表达典型场景常见误用流程图步骤与分支业务流程、算法逻辑用来表达系统结构架构图模块与依赖系统分层、组件关系混入过多时序信息时序图交互与顺序接口调用、协议流程用来表达静态结构状态机图状态与迁移订单状态、连接生命周期用来表达流程步骤ER 图实体与关系数据建模用来表达服务依赖思维导图层级与发散知识梳理、方案拆解用来表达有环依赖这张表我建议存下来。每次画图前对一下，能避免 80% 的"图不对题"问题。我印象很深的一次，某团队用流程图去画一个微服务的调用关系，结果因为服务之间有循环依赖，流程图里出现了回环箭头，看起来像"流程倒退"，评审时被反复追问。其实那个场景应该用架构图表达依赖，用时序图表达调用顺序，两张图各司其职，问题就没了。3.2 什么时候该用"组合图"现实场景里，单一图表类型往往不够用。比如描述一个完整的支付流程，既需要时序图表达"谁先调用谁"，又需要状态机图表达"订单状态怎么变"。这时候我的建议是拆成多张图，用统一的视觉语言串联，而不是硬塞进一张图。统一视觉语言的意思是：颜色含义一致、图形语义一致、命名风格一致。比如蓝色永远代表"外部系统"，圆角矩形永远代表"服务"，虚线永远代表"异步"。这样读者看完第一张图，看第二张时认知成本就大幅降低。3.3 选型的一个实用判断法我自己总结了一个快速判断法，叫"动词测试"：如果图的核心是"先做什么、再做什么"，用流程图或时序图；如果图的核心是"谁依赖谁、谁属于谁"，用架构图或 ER 图；如果图的核心是"在什么条件下变成什么"，用状态机图；如果图的核心是"有哪些、分几类"，用思维导图或树形图。这个测试的关键是找到图里最重要的那个动词或关系词，然后匹配图表类型。听起来简单，但能挡掉大量选型错误。4. 视觉编码：让图"自己会说话"的细节4.1 颜色不是用来好看的颜色在图表里承担的是语义编码功能，不是审美功能。我见过太多图，颜色用得五彩斑斓，但没有任何含义，读者反而被干扰。我的配色原则是：颜色数量控制在 3 到 4 种，每种颜色绑定一个固定语义。比如：主色（如深蓝）：核心系统或主流程；辅色（如浅蓝）：支撑组件；警示色（如橙）：外部依赖或风险点；中性色（如灰）：背景或次要信息。这样读者不需要看图例就能猜出大概含义。如果颜色超过 5 种，基本可以判定这张图的语义编码失控了。另外提醒一点：考虑色盲友好。红绿搭配是最常见的坑，大约每 12 个男性里就有 1 个红绿色觉异常。如果必须区分正反状态，用蓝橙搭配比红绿安全得多。4.2 箭头方向与线型的信息量箭头是图表里信息密度最高的元素之一，但很多人用得极其随意。我的规范是：实线箭头：同步调用、强依赖、主流程；虚线箭头：异步消息、弱依赖、可选路径；双向箭头：双向通信，但要谨慎使用，容易造成"循环依赖"的误读；无箭头连线：仅表示关联，不表示方向。线型一旦定义，全图甚至全文档都要一致。我踩过的坑是：同一份文档里，第一张图虚线表示异步，第二张图虚线表示"已废弃"，读者直接懵了。后来我强制自己维护一份"视觉规范小抄"，每张图都对照检查。4.3 布局：从左到右还是从上到下布局方向看似小事，其实影响阅读效率。我的经验是：流程类：从左到右，符合阅读习惯，也方便横向排版；层级类：从上到下，上层是抽象，下层是具体；循环类：环形布局，但要注意别让箭头交叉太多。还有一个细节：对齐。手画的图最容易出现的问题就是方框大小不一、间距不均，视觉上显得很"业余"。其实只要做到"同层同高、同列同宽、间距一致"，图的专业度立刻上一个台阶。这个不需要什么设计天赋，纯粹是纪律问题。4.4 文字：少即是多图里的文字，我的原则是能用一个词就不用一句话，能用名词就不用动词短语。因为图是快速扫描的媒介，长句子会打断扫描节奏。具体做法：节点名称用名词短语，如"订单服务"而不是"处理订单的服务"；箭头标签用动词或简短说明，如"创建"而不是"调用创建接口"；图注放在图外，不要塞进图里。如果某个节点确实需要详细说明，用编号加图注的方式，而不是把说明文字硬塞进方框。这样图保持清爽，细节也不丢失。5. 工具链与工作流：从手绘到版本管理5.1 工具选型的三个维度图表工具五花八门，我不推荐具体品牌，但可以给三个选型维度：表达力：能不能画出你需要的图表类型，支不支持自定义样式；协作性：能不能多人编辑、评论、版本对比；可维护性：改一个节点，相关连线会不会自动调整；能不能用文本描述生成图。第三点特别重要。我早期用纯图形工具画架构图，系统一改，图就得大改，维护成本极高。后来转向**"图即代码"**的思路，用文本描述图表结构，改起来就是改几行文本，效率天差地别。5.2 "图即代码"为什么值得投入"图即代码"的核心价值是可版本管理。图变成了文本，就能进代码仓库，就能 diff，就能 review。这对技术团队意义重大——架构图的变更可以和代码变更一起评审，图和实现不容易脱节。我实际用下来，收益主要有三点：改图成本从"重画"降到"改几行"；图的历史变更可追溯，能回答"这个模块是什么时候加的"；多人协作时冲突可合并，不像二进制文件那样只能二选一。当然，它也有代价：学习成本、样式精细度不如专业设计工具。所以我的建议是技术图用代码化工具，汇报图用设计工具，各取所长。5.3 一个可复用的画图工作流我把自己的画图流程固化成了五步，分享出来：写一句话目的：这张图要回答什么问题，写在最上面；列元素清单：把所有想画的节点列出来，然后按必要性删减；定视觉规范：颜色、线型、形状的语义先定好；画草图：先用最粗糙的方式摆位置，确认逻辑通顺；精修与自检：对齐、间距、文字精简，最后用"陌生人视角"看一遍。第五步的"陌生人视角"很关键。我经常把图发给不熟悉这个系统的同事，问他"你看完这张图，能说出这个系统大概怎么工作吗"。如果他说不出来，说明图还有问题。6. 那些年我在图表设计上踩过的坑6.1 信息过载：一张图塞进一个系统这是我最早也最严重的坑。当时做一个跨平台系统的设计文档，我想"一张图搞定所有事"，结果画出来密密麻麻，自己看着都头疼。评审会上，有人直接说"这图我看不懂"。后来我复盘，根本原因是我把图当成了文档的替代品，想用一张图承载所有信息。但图的优势是"快速传达结构"，不是"完整记录细节"。正确做法是：图负责结构和关系，文字负责细节和边界条件，两者配合，而不是互相替代。6.2 语义不一致：同一个形状两种含义第二个坑是语义漂移。同一份文档里，我一会儿用圆角矩形表示服务，一会儿又用它表示数据库，读者根本分不清。这个问题在多人协作时更严重，每个人有自己的习惯。解决办法就是前面说的视觉规范小抄。我现在做任何多图文档，第一步就是定一份规范，贴在文档开头，所有人对照执行。规范不用复杂，一张表就够：视觉元素固定含义圆角矩形服务/应用直角矩形外部系统圆柱数据存储实线箭头同步调用虚线箭头异步消息6.3 忽视读者：用自己熟悉的缩写第三个坑很隐蔽：我在图里用了大量团队内部缩写，自己看着很顺，但跨团队评审时，别人完全看不懂。比如某个内部代号，我们叫惯了，外部人根本不知道是什么。这个坑的教训是：图的读者范围决定了你能用多少"内部语言"。如果图只给本团队看，缩写没问题；如果要跨团队、跨层级，就必须用通用词汇，或者加图例说明。6.4 只画不改：图与实现脱节最后一个坑是维护问题。图一旦画完就没人管，系统改了图没改，半年后图就成了"历史文物"，谁也不敢信。这个问题的根源是图没有纳入变更流程。我的解法是把图放进代码仓库，和代码一起 review。架构变更的 PR 里，如果涉及结构变化，必须同时更新图。这样图就有了"保鲜机制"，不会腐烂。7. 让图表设计能力真正沉淀下来7.1 建立自己的图表素材库图表设计能力不是靠看教程看出来的，是靠反复画、反复改练出来的。我的建议是建一个自己的素材库，把画过的图分类存起来：架构图、时序图、状态图各一组，标注好场景和当时的取舍理由。这个库的价值在于：下次遇到类似场景，你可以直接复用结构和视觉规范，而不是从零开始。我现在的很多图，都是在旧图基础上改的，效率高很多，风格也统一。7.2 用"图评"代替"图看"什么叫"图评"？就是像代码 review 一样，对图做结构化评审。评审的问题清单可以是：这张图回答了什么核心问题？核心节点是否一眼可见？视觉编码是否一致？有没有可以删掉而不影响理解的元素？一个不了解背景的人能看懂多少？我带着团队做过几次"图评"，效果很好。因为画图的人往往有"知识诅咒"，觉得自己懂的别人也懂，而图评能强制打破这个假设。7.3 把图表设计当成沟通能力的一部分最后我想说一个认知层面的东西。很多人把图表设计当成"工具技能"，觉得学会某个软件就行了。但我的体会是，图表设计本质上是沟通能力——它是把复杂信息压缩成可快速理解的形式的能力。这种能力，在写文档、做汇报、带新人、做评审时都会用到。它和写作能力、口头表达能力是一体的。你图画的清楚，说明你想的清楚；你想的清楚，图自然画的清楚。所以别把画图当成负担，把它当成训练自己结构化思考的方式。每次画图，都是一次把混乱想法整理成清晰结构的机会。这个能力练出来，受益的不只是图，而是你处理所有复杂问题的方式。我在实际项目里最深的一个体会是：图的质量，往往反映的是团队对系统的理解深度。一个团队如果连一张清晰的架构图都画不出来，大概率对系统的边界和依赖也没有想清楚。反过来，能把图画的干净利落的团队，通常设计也不会太差。这大概就是"diagram-design"这件事最值得投入的原因——它不只是让图好看，而是让思考更清晰。
1. 从"diagram-design"这个标题能读出什么第一次看到"diagram-design"这个标题，我的直觉是：这大概率不是一个单纯的"画图工具推荐"或者"设计规范文档"，而是一个把图表设计这件事当成一个完整工程问题来对待的项目。为什么这么说？因为如果只是教人怎么画流程图，标题通常会写成"flowchart-tutorial"或者"diagram-guide"；而"design"这个词放在后面，意味着它强调的是设计决策——也就是"为什么这张图要这样画""什么场景该用什么图""怎么让图真正传达信息而不是制造噪音"。图表设计这件事，看起来门槛很低，实际上坑极多。我见过太多团队，技术能力很强，但一画架构图就变成"方框加箭头大乱炖"，读者看三秒就放弃。也见过不少人在做技术分享时，PPT里的图信息密度过高，讲的时候自己都找不到重点在哪。这些问题的根源，都不是"不会用工具"，而是没有把图表当成一种需要设计的信息产品。所以这篇内容，我想围绕"diagram-design"这个核心，把图表设计从认知层、选型层、执行层到维护层完整拆一遍。适合谁看？三类人：一是需要频繁输出架构图、流程图、时序图的技术从业者；二是要做汇报、写文档、做知识沉淀的职场人；三是对信息可视化有兴趣、想让自己的图"一眼就懂"的创作者。不管你用的是哪款工具，这套思路都能直接迁移。我自己的经验是，图表设计能力带来的回报被严重低估了。一张好的架构图，能让新人在半小时内理解一个跑了三年的系统；一张糟糕的图，能让一个小时的评审会变成互相猜谜。下面我就按我实际做项目时踩过的顺序，一层层展开。2. 图表设计的第一性问题：图到底为谁而画2.1 先定读者，再定画法很多人画图的第一步是打开工具，第二步是拖方框。这个顺序是反的。正确的第一步应该是问自己：这张图给谁看，他看完要做什么决策？我举个真实场景。同一个后端服务，如果给运维看，重点是部署拓扑、实例数量、依赖的外部组件；如果给新入职的开发看，重点是模块划分、调用关系、数据流向；如果给管理层看，重点是业务价值链路和关键节点。这三种读者，画出来的图完全不一样，甚至用的图形语言都不同。我踩过的一个坑是：早期做系统设计文档时，我画了一张"全能图"，既想展示部署，又想展示调用，还想展示数据模型。结果评审时，运维问"实例在哪"，开发问"这个箭头是同步还是异步"，谁都没得到答案。后来我改成一图一目的，同一套系统画三张不同视角的图，反而所有人都看懂了。所以这里有个硬性原则：一张图只回答一个问题。如果一张图需要配一大段文字解释才能看懂，那这张图本身就是失败的。2.2 信息层级：什么该画，什么必须删图表设计的本质是信息取舍。新手最容易犯的错是"什么都想画上去"，因为怕漏掉信息。但读者的注意力是有限资源，你画得越多，重点越模糊。我的做法是给每个元素打一个"必要性标签"：元素类型判断标准处理方式核心节点去掉后图就讲不通必须保留，视觉加重支撑节点解释核心节点如何工作保留，视觉弱化背景信息只是"顺便提一下"移到图注或正文实现细节只有特定角色关心单独出图这个表格我几乎每次画图前都会在脑子里过一遍。实测下来，一张图里核心节点控制在5 到 9 个是比较舒服的区间，超过这个数量，人眼就开始"扫读"而不是"理解"了。这不是玄学，是认知负荷的基本规律——工作记忆能同时处理的组块数量就那么多。提示：如果你发现核心节点超过 9 个，通常说明这张图承担了太多职责，应该拆图，而不是硬塞。2.3 图表不是装饰，是论证工具这一点我想特别强调。很多人把图当成"文档的配图"，觉得文字是主角，图是点缀。但在技术沟通里，图往往是论证的主体。一张好的架构图，本身就在论证"这个设计是合理的"——它通过清晰的边界、合理的分层、明确的依赖方向，让读者自己得出结论。反过来，一张糟糕的图会暴露设计的混乱。我有个习惯：画图的过程就是检验设计的过程。如果我发现某个模块的箭头怎么连都别扭，那大概率不是画法问题，而是设计本身有问题。图是设计的镜子，画不顺，说明想不清。3. 图表类型选型：别用流程图硬套所有场景3.1 常见图表类型与适用边界选错图表类型，是比画得丑更严重的问题。我整理了一张对照表，覆盖技术场景里最常用的几类：图表类型核心表达典型场景常见误用流程图步骤与分支业务流程、算法逻辑用来表达系统结构架构图模块与依赖系统分层、组件关系混入过多时序信息时序图交互与顺序接口调用、协议流程用来表达静态结构状态机图状态与迁移订单状态、连接生命周期用来表达流程步骤ER 图实体与关系数据建模用来表达服务依赖思维导图层级与发散知识梳理、方案拆解用来表达有环依赖这张表我建议存下来。每次画图前对一下，能避免 80% 的"图不对题"问题。我印象很深的一次，某团队用流程图去画一个微服务的调用关系，结果因为服务之间有循环依赖，流程图里出现了回环箭头，看起来像"流程倒退"，评审时被反复追问。其实那个场景应该用架构图表达依赖，用时序图表达调用顺序，两张图各司其职，问题就没了。3.2 什么时候该用"组合图"现实场景里，单一图表类型往往不够用。比如描述一个完整的支付流程，既需要时序图表达"谁先调用谁"，又需要状态机图表达"订单状态怎么变"。这时候我的建议是拆成多张图，用统一的视觉语言串联，而不是硬塞进一张图。统一视觉语言的意思是：颜色含义一致、图形语义一致、命名风格一致。比如蓝色永远代表"外部系统"，圆角矩形永远代表"服务"，虚线永远代表"异步"。这样读者看完第一张图，看第二张时认知成本就大幅降低。3.3 选型的一个实用判断法我自己总结了一个快速判断法，叫"动词测试"：如果图的核心是"先做什么、再做什么"，用流程图或时序图；如果图的核心是"谁依赖谁、谁属于谁"，用架构图或 ER 图；如果图的核心是"在什么条件下变成什么"，用状态机图；如果图的核心是"有哪些、分几类"，用思维导图或树形图。这个测试的关键是找到图里最重要的那个动词或关系词，然后匹配图表类型。听起来简单，但能挡掉大量选型错误。4. 视觉编码：让图"自己会说话"的细节4.1 颜色不是用来好看的颜色在图表里承担的是语义编码功能，不是审美功能。我见过太多图，颜色用得五彩斑斓，但没有任何含义，读者反而被干扰。我的配色原则是：颜色数量控制在 3 到 4 种，每种颜色绑定一个固定语义。比如：主色（如深蓝）：核心系统或主流程；辅色（如浅蓝）：支撑组件；警示色（如橙）：外部依赖或风险点；中性色（如灰）：背景或次要信息。这样读者不需要看图例就能猜出大概含义。如果颜色超过 5 种，基本可以判定这张图的语义编码失控了。另外提醒一点：考虑色盲友好。红绿搭配是最常见的坑，大约每 12 个男性里就有 1 个红绿色觉异常。如果必须区分正反状态，用蓝橙搭配比红绿安全得多。4.2 箭头方向与线型的信息量箭头是图表里信息密度最高的元素之一，但很多人用得极其随意。我的规范是：实线箭头：同步调用、强依赖、主流程；虚线箭头：异步消息、弱依赖、可选路径；双向箭头：双向通信，但要谨慎使用，容易造成"循环依赖"的误读；无箭头连线：仅表示关联，不表示方向。线型一旦定义，全图甚至全文档都要一致。我踩过的坑是：同一份文档里，第一张图虚线表示异步，第二张图虚线表示"已废弃"，读者直接懵了。后来我强制自己维护一份"视觉规范小抄"，每张图都对照检查。4.3 布局：从左到右还是从上到下布局方向看似小事，其实影响阅读效率。我的经验是：流程类：从左到右，符合阅读习惯，也方便横向排版；层级类：从上到下，上层是抽象，下层是具体；循环类：环形布局，但要注意别让箭头交叉太多。还有一个细节：对齐。手画的图最容易出现的问题就是方框大小不一、间距不均，视觉上显得很"业余"。其实只要做到"同层同高、同列同宽、间距一致"，图的专业度立刻上一个台阶。这个不需要什么设计天赋，纯粹是纪律问题。4.4 文字：少即是多图里的文字，我的原则是能用一个词就不用一句话，能用名词就不用动词短语。因为图是快速扫描的媒介，长句子会打断扫描节奏。具体做法：节点名称用名词短语，如"订单服务"而不是"处理订单的服务"；箭头标签用动词或简短说明，如"创建"而不是"调用创建接口"；图注放在图外，不要塞进图里。如果某个节点确实需要详细说明，用编号加图注的方式，而不是把说明文字硬塞进方框。这样图保持清爽，细节也不丢失。5. 工具链与工作流：从手绘到版本管理5.1 工具选型的三个维度图表工具五花八门，我不推荐具体品牌，但可以给三个选型维度：表达力：能不能画出你需要的图表类型，支不支持自定义样式；协作性：能不能多人编辑、评论、版本对比；可维护性：改一个节点，相关连线会不会自动调整；能不能用文本描述生成图。第三点特别重要。我早期用纯图形工具画架构图，系统一改，图就得大改，维护成本极高。后来转向**"图即代码"**的思路，用文本描述图表结构，改起来就是改几行文本，效率天差地别。5.2 "图即代码"为什么值得投入"图即代码"的核心价值是可版本管理。图变成了文本，就能进代码仓库，就能 diff，就能 review。这对技术团队意义重大——架构图的变更可以和代码变更一起评审，图和实现不容易脱节。我实际用下来，收益主要有三点：改图成本从"重画"降到"改几行"；图的历史变更可追溯，能回答"这个模块是什么时候加的"；多人协作时冲突可合并，不像二进制文件那样只能二选一。当然，它也有代价：学习成本、样式精细度不如专业设计工具。所以我的建议是技术图用代码化工具，汇报图用设计工具，各取所长。5.3 一个可复用的画图工作流我把自己的画图流程固化成了五步，分享出来：写一句话目的：这张图要回答什么问题，写在最上面；列元素清单：把所有想画的节点列出来，然后按必要性删减；定视觉规范：颜色、线型、形状的语义先定好；画草图：先用最粗糙的方式摆位置，确认逻辑通顺；精修与自检：对齐、间距、文字精简，最后用"陌生人视角"看一遍。第五步的"陌生人视角"很关键。我经常把图发给不熟悉这个系统的同事，问他"你看完这张图，能说出这个系统大概怎么工作吗"。如果他说不出来，说明图还有问题。6. 那些年我在图表设计上踩过的坑6.1 信息过载：一张图塞进一个系统这是我最早也最严重的坑。当时做一个跨平台系统的设计文档，我想"一张图搞定所有事"，结果画出来密密麻麻，自己看着都头疼。评审会上，有人直接说"这图我看不懂"。后来我复盘，根本原因是我把图当成了文档的替代品，想用一张图承载所有信息。但图的优势是"快速传达结构"，不是"完整记录细节"。正确做法是：图负责结构和关系，文字负责细节和边界条件，两者配合，而不是互相替代。6.2 语义不一致：同一个形状两种含义第二个坑是语义漂移。同一份文档里，我一会儿用圆角矩形表示服务，一会儿又用它表示数据库，读者根本分不清。这个问题在多人协作时更严重，每个人有自己的习惯。解决办法就是前面说的视觉规范小抄。我现在做任何多图文档，第一步就是定一份规范，贴在文档开头，所有人对照执行。规范不用复杂，一张表就够：视觉元素固定含义圆角矩形服务/应用直角矩形外部系统圆柱数据存储实线箭头同步调用虚线箭头异步消息6.3 忽视读者：用自己熟悉的缩写第三个坑很隐蔽：我在图里用了大量团队内部缩写，自己看着很顺，但跨团队评审时，别人完全看不懂。比如某个内部代号，我们叫惯了，外部人根本不知道是什么。这个坑的教训是：图的读者范围决定了你能用多少"内部语言"。如果图只给本团队看，缩写没问题；如果要跨团队、跨层级，就必须用通用词汇，或者加图例说明。6.4 只画不改：图与实现脱节最后一个坑是维护问题。图一旦画完就没人管，系统改了图没改，半年后图就成了"历史文物"，谁也不敢信。这个问题的根源是图没有纳入变更流程。我的解法是把图放进代码仓库，和代码一起 review。架构变更的 PR 里，如果涉及结构变化，必须同时更新图。这样图就有了"保鲜机制"，不会腐烂。7. 让图表设计能力真正沉淀下来7.1 建立自己的图表素材库图表设计能力不是靠看教程看出来的，是靠反复画、反复改练出来的。我的建议是建一个自己的素材库，把画过的图分类存起来：架构图、时序图、状态图各一组，标注好场景和当时的取舍理由。这个库的价值在于：下次遇到类似场景，你可以直接复用结构和视觉规范，而不是从零开始。我现在的很多图，都是在旧图基础上改的，效率高很多，风格也统一。7.2 用"图评"代替"图看"什么叫"图评"？就是像代码 review 一样，对图做结构化评审。评审的问题清单可以是：这张图回答了什么核心问题？核心节点是否一眼可见？视觉编码是否一致？有没有可以删掉而不影响理解的元素？一个不了解背景的人能看懂多少？我带着团队做过几次"图评"，效果很好。因为画图的人往往有"知识诅咒"，觉得自己懂的别人也懂，而图评能强制打破这个假设。7.3 把图表设计当成沟通能力的一部分最后我想说一个认知层面的东西。很多人把图表设计当成"工具技能"，觉得学会某个软件就行了。但我的体会是，图表设计本质上是沟通能力——它是把复杂信息压缩成可快速理解的形式的能力。这种能力，在写文档、做汇报、带新人、做评审时都会用到。它和写作能力、口头表达能力是一体的。你图画的清楚，说明你想的清楚；你想的清楚，图自然画的清楚。所以别把画图当成负担，把它当成训练自己结构化思考的方式。每次画图，都是一次把混乱想法整理成清晰结构的机会。这个能力练出来，受益的不只是图，而是你处理所有复杂问题的方式。我在实际项目里最深的一个体会是：图的质量，往往反映的是团队对系统的理解深度。一个团队如果连一张清晰的架构图都画不出来，大概率对系统的边界和依赖也没有想清楚。反过来，能把图画的干净利落的团队，通常设计也不会太差。这大概就是"diagram-design"这件事最值得投入的原因——它不只是让图好看，而是让思考更清晰。