diagram-design：用工程化思维设计技术图表，让图替你把话说明白

1. 从一张草图到一套系统：diagram-design 到底在解决什么问题

第一次看到 “diagram-design” 这个标题，我脑子里蹦出来的不是某个具体工具，而是一类非常典型的困境：手里有一堆零散的信息——业务流程、系统架构、数据流向、组织关系——想把它画成一张图，但打开画图软件之后，面对空白画布愣了十分钟，最后画出来的东西自己都不想看第二眼。

这不是审美问题，是方法问题。

diagram-design 这个主题，本质上讨论的是如何用工程化的思路去设计一张图，而不是随手拖几个框、连几根线就完事。它覆盖的范围很广：流程图、架构图、时序图、状态机图、思维导图、ER 图，甚至包括 PPT 里那种用来讲清楚一件事的示意图。核心诉求只有一个——让图替你把话说明白。

我做了十多年技术方案和产品设计，画过的图少说也有大几百张。早期我也走过弯路：追求好看，配色花哨，阴影拉满，结果评审的时候没人看懂；后来走向另一个极端，全部用最朴素的黑白框，结果信息层级完全糊在一起，重点找不到。真正让我开窍的，是有一次要把一个跨系统调用链路讲给非技术背景的同事听，我画了整整一页的架构图，对方看了三秒问我：“所以数据是从哪到哪？”

那一刻我意识到，图不是画给自己看的，是画给读图的人看的。diagram-design 的核心，就是站在读图者的角度，反向设计信息的呈现方式。

这篇文章适合谁看？如果你是开发者、产品经理、技术写作者、咨询顾问，或者任何需要频繁用图来表达复杂信息的人，那这篇内容基本就是为你准备的。我会从设计思路、工具选型、实操步骤、常见坑四个维度，把 diagram-design 这件事拆开揉碎讲清楚。不需要你有设计基础，但需要你愿意在画图之前先想清楚三件事：给谁看、说什么、怎么分层。

下面进入正题。

2. 画图之前先想清楚：diagram-design 的底层设计逻辑

2.1 图的本质是信息压缩，不是信息堆砌

很多人画图有个误区：觉得图里信息越多越显得专业。实际上恰恰相反。一张好的图，是把 10 页文档的内容压缩成 1 页，而不是把 10 页文档原封不动搬到画布上。

我习惯用一个简单的判断标准：如果一张图需要配 500 字以上的文字说明才能看懂，那这张图本身就是失败的。图的价值在于，它利用人类视觉系统对空间关系、层级关系、连接关系的天然敏感度，把抽象逻辑变成可以直接“看”到的东西。

所以 diagram-design 的第一步不是打开工具，而是做信息筛选。具体怎么筛？我通常用“三层过滤法”：

• 第一层：这张图要回答的核心问题是什么？比如“订单从创建到履约经过了哪些系统”，那所有跟这个链路无关的模块全部砍掉。
• 第二层：哪些信息是必须出现的？核心节点、关键判断分支、数据流向。这些是骨架，不能少。
• 第三层：哪些信息是锦上添花的？比如某个节点的技术栈标注、某个接口的协议类型。这些可以放在图注或者附注里，不要塞进主图。

经过这三层过滤，一张图的信息量通常会缩减到原始素材的 30% 左右。剩下的 70% 不是丢了，而是转移到了你的口头讲解或者配套文档里。图负责建立框架，文字负责填充细节，这才是合理的分工。

2.2 读图者的认知路径决定图的布局方式

同一个系统，画给不同的人看，布局应该完全不同。这不是玄学，是认知心理学的基本规律。

给技术负责人看的架构图，他关心的是模块边界、依赖关系、扩展性瓶颈。所以布局应该以分层为主：接入层、逻辑层、存储层，从上到下或者从左到右，清晰展示每一层的职责和层间调用关系。

给产品经理看的业务流程图，他关心的是状态流转、异常分支、用户可感知的环节。所以布局应该以泳道为主：不同角色放在不同泳道里，流程从左到右推进，分支用菱形判断节点展开。

给管理层看的全局概览图，他关心的是系统整体规模、核心模块、关键外部依赖。所以布局应该以中心辐射为主：核心系统放中间，周边系统环绕，用粗细不同的连线表示交互频率或重要性。

我见过太多人用同一张图应付所有场合，结果就是谁都不满意。diagram-design 的关键决策之一，就是在动手之前先确定读图者是谁，然后选择对应的布局范式。这个决策花你五分钟，但能省掉后面两小时的反复修改。

2.3 视觉层级比配色方案重要一百倍

新手最容易掉进的坑，就是把大量精力花在选配色上。什么莫兰迪色系、赛博朋克风、渐变填充，折腾半天，图还是看不懂。

真正决定一张图可读性的，是视觉层级。什么叫视觉层级？就是读图者的眼睛应该先看什么、再看什么、最后看什么。这个顺序必须由你的设计来引导，而不是让读图者自己猜。

建立视觉层级的手段有很多，按优先级排序大概是这样的：

我的习惯是：先用大小和位置把层级拉开，再用粗细和颜色做微调，阴影和立体效果基本不用。这样画出来的图，哪怕打印成黑白，层级依然清晰。

注意：如果你发现自己在一张图里用了超过 5 种颜色，大概率是信息分类没做好。颜色是分类工具，不是装饰工具。

3. 工具选型：不同场景下用什么画图最顺手

3.1 代码驱动型工具：适合需要版本管理的技术图

如果你画的图需要进代码仓库、需要跟代码一起迭代、需要多人协作评审，那代码驱动型工具是首选。这类工具的核心逻辑是：你用文本描述图的结构，工具负责渲染成图。

典型代表是 Mermaid 和 PlantUML。Mermaid 的语法更接近自然语言，上手快，适合流程图、时序图、状态图、ER 图这些常见类型。PlantUML 功能更强大，支持的类型更多，但语法相对复杂一些。

我自己的使用习惯是这样的：跟代码强相关的图用 Mermaid 写在 Markdown 里，跟代码弱相关的图用专业绘图工具。比如一个微服务的调用时序，我会直接写在接口文档的 Markdown 里，用 Mermaid 渲染；但一个完整的系统部署架构，我会用 draw.io 或者类似工具画，因为需要更自由的布局控制。

代码驱动型工具的优势很明显：

• 版本可控，diff 清晰，谁改了哪根线一目了然
• 不需要手动对齐，工具自动布局
• 可以嵌入文档系统，随文档一起发布

但劣势也很明显：

• 布局自由度低，复杂图容易乱
• 样式定制能力有限，很难做出精细的视觉效果
• 学习成本存在，团队需要统一约定

3.2 拖拽式工具：适合需要精细控制布局的场景

拖拽式工具的代表是 draw.io、Excalidraw、Figma 这类。它们的核心优势是布局完全由你控制，想放哪就放哪，想怎么对齐就怎么对齐。

这类工具适合画什么图？我总结了几类：

• 系统架构图：需要精确控制模块位置和连线走向
• 业务全景图：需要在一个画布上展示多个维度的信息
• 汇报用图：需要精细调整视觉效果，适配 PPT 或文档排版
• 手绘风格示意图：Excalidraw 这类工具自带手绘感，适合非正式场合

draw.io 是我用得最多的，免费、跨平台、支持导出多种格式、可以存本地也可以存云端。Excalidraw 适合快速画草图，那种“随手一画”的感觉反而能让读者放松，适合头脑风暴和早期讨论。

3.3 专业图表工具：适合数据可视化和标准化图形

如果你的图涉及大量数据、需要精确的坐标轴、需要符合某种行业标准（比如 UML 规范），那可能需要更专业的工具。比如：

• UML 建模：StarUML、Visual Paradigm
• 数据可视化：Tableau、Power BI、ECharts
• 网络拓扑：亿图、Visio

这类工具的学习曲线更陡，但胜在专业性和标准化。我的建议是：除非你的工作长期需要画某一类标准图，否则不需要专门学。大部分场景下，draw.io 加 Mermaid 的组合已经能覆盖 90% 的需求。

3.4 工具选型的决策清单

为了让你更快做决定，我整理了一个简单的决策清单：

提示：工具不是越高级越好。我见过有人用 Figma 画架构图，花了三小时调像素，结果评审时被问“这个模块为什么放在这里”，完全答不上来。工具服务于表达，不要本末倒置。

4. 实操全流程：从零画出一张能用的图

4.1 第一步：用一句话定义图的主题

这一步听起来简单，但很多人跳过。我要求自己每次画图之前，先写一句话：“这张图要让 [谁] 在 [什么场景] 下看懂 [什么事]。”

举个例子：“这张图要让新入职的开发在 onboarding 时看懂订单系统的核心链路。”有了这句话，后面所有决策都有了依据：新入职开发不需要看历史包袱，所以老系统可以简化；onboarding 场景需要快速理解，所以细节可以砍掉；核心链路意味着异常分支可以暂时不展开。

如果这句话写不出来，说明你还没想清楚为什么要画这张图。那就先别画，回去把需求想明白。

4.2 第二步：列出所有节点和连线，先做加法

定义清楚主题之后，开始做信息收集。这一步不要考虑布局，不要考虑美观，就是把所有可能相关的节点和连线全部列出来。

我通常用纸笔或者一个简单的文本列表来做这件事。比如画一个订单系统链路图，我会先列：

• 用户端
• 网关
• 订单服务
• 库存服务
• 支付服务
• 履约服务
• 消息队列
• 数据库
• 缓存

然后标注它们之间的调用关系：用户端调网关，网关调订单服务，订单服务调库存和支付，支付成功后发消息到队列，履约服务消费消息，等等。

这一步的关键是宁多勿少。先把所有可能性列出来，后面再做减法。如果一开始就做减法，很容易漏掉关键节点。

4.3 第三步：做减法，砍掉非核心信息

现在你有了一个完整的节点列表，接下来是最重要的一步：砍。

砍的标准还是回到第一步那句话。如果某个节点跟“让新入职开发看懂核心链路”这个目标无关，就砍掉。比如：

• 监控系统？砍掉，onboarding 不需要关心监控。
• 日志收集？砍掉，同上。
• 配置中心？可以保留但简化，因为新开发需要知道配置从哪来。
• 缓存？保留，因为影响链路理解。

砍完之后，节点数量通常能减少 30% 到 50%。这时候图才开始变得清晰。

4.4 第四步：选择布局范式并排列节点

根据读图者的认知路径，选择布局范式。对于订单系统链路图，我选择从左到右的泳道式布局：

• 最左边是用户端
• 第二列是网关
• 第三列是核心服务（订单、库存、支付）
• 第四列是异步处理（消息队列、履约服务）
• 最右边是数据存储（数据库、缓存）

每一列内部，按调用顺序从上到下排列。这样读图者的眼睛自然从左到右移动，跟数据流动方向一致。

排列节点的时候，有几个细节要注意：

• 对齐：同一层级的节点必须对齐，否则视觉上会显得混乱
• 间距：节点之间的间距要均匀，不要有的挤在一起有的隔很远
• 连线：尽量用直线或简单的折线，避免交叉。如果交叉不可避免，用“跳线”或者不同颜色区分

4.5 第五步：建立视觉层级

节点排好之后，开始建立视觉层级。我的操作顺序是：

1. 放大核心节点：订单服务是核心，放大到 1.5 倍
2. 加粗主链路：用户到订单到支付这条线加粗
3. 弱化辅助节点：缓存和数据库用浅色填充
4. 统一配色：同一层级的节点用同一种颜色，不同层级用不同色系
5. 添加标注：关键节点旁边用小字标注技术栈或协议

这一步做完，图的基本骨架就出来了。

4.6 第六步：检查可读性并做最终调整

最后一步是检查。我通常会把图缩小到 50% 看一遍，再放大到 150% 看一遍。

• 缩小看：检查整体层级是否清晰，核心节点是否突出，有没有明显的视觉失衡
• 放大看：检查文字是否清晰，连线是否准确，标注是否到位

如果缩小之后发现核心节点不够突出，回去加大对比。如果放大之后发现连线交叉太多，回去调整节点位置。

实操心得：我习惯在最终导出之前，把图发给一个没参与设计的同事看一眼，问他“你第一眼看到了什么”。如果他的回答跟我的设计意图一致，说明图合格了；如果不一致，说明视觉层级没做好。

5. 常见问题与排查技巧实录

5.1 图太乱怎么办？先做减法，再做分层

图乱是最高频的问题。很多人第一反应是调整布局，但其实大部分情况下，乱的根本原因是信息太多。

我的排查顺序是这样的：

1. 数节点：如果节点超过 15 个，先砍到 10 个以内
2. 数连线：如果连线超过 20 条，先合并同类连线
3. 看层级：如果所有节点大小差不多，先拉开大小对比
4. 看颜色：如果颜色超过 5 种，先统一色系

经过这四步，大部分图都能变得清晰。如果还是乱，那可能是布局范式选错了，需要换一种布局方式重新排。

5.2 连线交叉太多怎么处理？

连线交叉是技术图的老大难问题。我的处理技巧有几个：

• 调整节点顺序：把关联紧密的节点放在相邻位置
• 使用跳线：在交叉处画一个小弧线，表示“这里不相连”
• 分层画：如果一张图实在画不下，拆成两张，一张画主链路，一张画异常分支
• 用颜色区分：不同链路的连线用不同颜色，交叉时也能区分

注意：不要为了减少交叉而把节点摆得乱七八糟。有时候适度的交叉是可以接受的，只要整体逻辑清晰就行。

5.3 文字太多放不下怎么办？

节点里的文字要精简到极致。我的原则是：节点里只放名词，不放动词，不放形容词。

比如“订单服务调用库存服务进行库存扣减”这句话，节点里只写“订单服务”和“库存服务”，连线上的标注写“扣减库存”。这样既节省空间，又保持信息完整。

如果实在需要更多说明，用图注或者编号，在图的下方统一解释。

5.4 不同工具导出的图风格不统一怎么办？

团队协作中经常遇到这个问题：有人用 draw.io，有人用 Mermaid，有人用 Figma，导出来的图风格五花八门。

我的建议是：团队统一一套视觉规范，包括：

• 统一字体（比如都用思源黑体）
• 统一配色（定义 3 到 5 个标准色）
• 统一节点样式（圆角矩形、直角矩形、圆形分别代表什么）
• 统一连线样式（实线、虚线、粗细分别代表什么）

这套规范不需要很复杂，一页文档就能写完。但有了它，不管谁画图，风格都是一致的。

5.5 常见问题速查表

6. 进阶技巧：让图从“能用”变成“好用”

6.1 用图讲故事，而不是列清单

一张真正好的图，应该像一篇好文章一样有起承转合。我画架构图的时候，会刻意设计一条“视觉动线”：读图者的眼睛从左上角进入，沿着主链路移动，在关键节点停留，最后在右下角结束。

这条动线上，我会安排三个层次的节奏：

• 起点：用一个明显的视觉元素吸引注意力，比如一个加粗的入口节点
• 高潮：核心模块放大、加色、加粗，让读图者知道这是重点
• 终点：用总结性的节点或标注收尾，比如“数据落库”或“返回结果”

这样读图的过程就变成了一次有引导的浏览，而不是漫无目的地扫视。

6.2 善用留白，不要填满画布

新手画图喜欢把画布填满，觉得空白是浪费。但实际上，留白是建立层级最有效的手段之一。

我通常会在核心模块周围留出至少 2 倍于节点间距的空白，让它在视觉上“浮”出来。不同层级之间也会留出明显的间隔，形成自然的视觉分组。

留白还有一个好处：方便后续修改。如果画布填得太满，加一个新节点就要重新调整全局布局；如果留了白，直接插进去就行。

6.3 为不同媒介做适配

同一张图，放在文档里、放在 PPT 里、放在大屏上，要求是不一样的。

• 文档里：字号可以小一些，因为读者可以放大看；颜色可以淡一些，因为背景是白色
• PPT 里：字号要大，因为投影后可能看不清；对比度要高，因为环境光可能很亮
• 大屏上：要考虑远距离观看，节点和文字都要放大，颜色要鲜艳

我的做法是：先画一张主图，然后根据媒介导出不同版本。draw.io 和 Figma 都支持这种操作，调整一下字号和颜色就行，不需要重新画。

6.4 建立自己的图库

画了几年图之后，我积累了一套自己的“图库”：常用的节点样式、配色方案、布局模板。每次画新图的时候，直接复用这些素材，效率能提升一倍以上。

图库不需要很复杂，我用的就是一个简单的 draw.io 文件，里面存了：

• 常用节点（服务、数据库、队列、网关等）
• 常用配色（核心色、辅助色、警告色）
• 常用布局模板（三层架构、泳道流程、中心辐射）

每次画新图，从这个文件复制粘贴，改改文字就行。

7. 我踩过的坑和总结的经验

画了这么多年图，踩过的坑不少，挑几个最有代表性的说说。

第一个坑：追求完美，迟迟不动手。早期我总想把布局想得完美无缺再开始画，结果想了半小时还没打开工具。后来我强迫自己“先画出来再优化”，用 Excalidraw 快速画个草图，然后再用 draw.io 精修。效率反而高了很多。

第二个坑：忽略读图者的背景。有一次给非技术同事画系统图，我用了大量技术术语和缩写，结果对方完全看不懂。后来我学会了“翻译”：把“消息队列”写成“异步通知”，把“负载均衡”写成“流量分配”。图还是那张图，但读图者能看懂了。

第三个坑：不保存源文件。有次导出了 PNG 之后把源文件删了，结果第二天要改一个文字，只能重新画。从那以后，我所有图都保留源文件，并且按项目分类存档。

第四个坑：配色太随意。早期我画图喜欢用各种鲜艳的颜色，觉得好看。后来发现打印成黑白之后完全分不清层级。现在我基本只用 3 到 4 种颜色，并且确保它们在灰度模式下也能区分。

第五个坑：不写图注。有些图放了一段时间之后，自己都忘了某个缩写是什么意思。现在我养成了习惯：所有缩写和特殊标记都在图注里解释清楚，哪怕当时觉得“这还用说吗”。

最后分享一个小技巧：如果你觉得一张图画得不错，把它存下来，下次遇到类似场景直接复用。我现在的图库里大概有 20 多张“模板图”，覆盖了架构、流程、时序、状态机等常见类型。每次画新图，先翻图库，能找到相似的就改，找不到再从零画。这个习惯让我画图的时间至少缩短了一半。

这个内容后续还可以这样扩展：针对特定领域（比如数据流图、网络拓扑图、组织架构图）做更深入的专题拆解，或者整理一套完整的绘图规范文档，方便团队内部统一使用。