1. 从“diagram-design”这个标题说起：它到底在解决什么问题
第一次看到“diagram-design”这个标题，很多人会下意识觉得它是个画图工具，或者某个设计系统的代号。但如果你真正在工程、产品、咨询或者技术写作场景里待过，就会明白这个标题背后藏着的是一类非常具体且高频的痛点：如何把脑子里那些模糊的、线性的、碎片化的逻辑关系，快速、准确、美观地转化成一张别人一眼能看懂的图。
这件事听起来简单，做起来极其折磨人。我见过太多团队在评审会上因为一张架构图吵得不可开交，原因不是技术方案有分歧，而是图画得太烂——箭头指向不明、层级混乱、颜色乱用、图例缺失。最后大家花在“解释这张图到底想表达什么”上的时间，比讨论方案本身还多。diagram-design 这个主题，本质上就是在回答一个问题：图不是画给自己看的，是画给读者看的，而读者的耐心通常只有三秒。
所以这篇文章不打算跟你聊什么“设计美学”或者“视觉传达理论”，那些东西太虚。我想从实际从业者的角度，把 diagram-design 这件事拆成几个真正能落地的层面：为什么大多数技术图让人看不懂、画图之前应该先确定什么、不同类型的图分别该怎么处理、有哪些工具和技巧能让你少走弯路、以及我在实际项目中踩过的那些坑。无论你是刚入行的工程师，还是需要频繁做汇报的产品经理，或者只是想把 PPT 里的流程图改得稍微像样一点，这些内容都能直接拿去用。
提示：本文讨论的 diagram-design 不局限于某一种工具或某一种图。流程图、架构图、时序图、状态机图、思维导图、甚至手绘草图，只要涉及“用图形表达逻辑关系”，都在讨论范围内。
2. 为什么你画的图别人看不懂：三个根深蒂固的认知误区
2.1 误区一：把“画完”当成“画好”
这是最普遍的问题。很多人画图的流程是这样的：打开工具，想到什么画什么，连线，加文字，导出，发送。整个过程没有任何“读者视角”的介入。结果就是，画的人觉得自己表达清楚了，看的人却一头雾水。
我做过一个粗略的统计：在一个中等规模的研发团队里，随机抽取十张架构图给不同角色的人看，能在一分钟内准确说出“这张图想表达的核心信息”的人，通常不超过三个。这意味着大部分图的信息传递效率低于 30%。问题出在哪？出在画图的人默认“读者和我拥有相同的背景知识”。但现实是，看你图的人可能根本不了解你的模块划分、不知道你的命名习惯、甚至不清楚你用的那些缩写是什么意思。
解决这个问题的办法很简单，但需要刻意练习：画完图之后，先别发出去，找一个完全不了解这个项目的人，让他看图说一遍他理解的内容。如果他说出来的和你想要表达的有偏差，那就改。这个动作我称之为“图的可读性测试”，成本极低，效果极好。
2.2 误区二：信息密度越高越好
很多人有一种执念，觉得一张图里塞的信息越多，显得自己越专业、越全面。于是你会看到那种密密麻麻、连线像蜘蛛网一样的“巨型架构图”，上面有几十个模块、上百条连线、各种颜色和图标。这种图唯一的用途就是放在文档里当装饰，证明“我们系统很复杂”，但它几乎不具备任何解释功能。
真正好的 diagram-design 遵循一个原则：一张图只讲一件事。如果你想表达系统的整体架构，那就只画模块和层级关系，不要在里面塞数据流向；如果你想表达某个请求的完整链路，那就只画时序和调用关系，不要在里面展示部署拓扑。把不同维度的信息拆到不同的图里，每张图都保持“一眼能看懂”的清晰度。
我自己的习惯是，如果一个图需要超过三种颜色、超过二十个节点、或者需要看图的人花超过十秒才能找到起点，那就说明这张图该拆了。
2.3 误区三：工具决定质量
这是新手最容易掉进去的坑。总觉得换了更高级的工具，图就会变好看。于是花大量时间研究各种绘图软件的快捷键、主题、插件，却忽略了最核心的东西：图的逻辑结构。
工具当然重要，但它只影响“颜值”，不影响“可读性”。一张用记事本画的 ASCII 流程图，如果逻辑清晰，照样能让人秒懂；一张用专业工具画的花里胡哨的图，如果逻辑混乱，照样让人抓狂。我见过用纯文本 mermaid 写的时序图，比某些用商业软件画的还清楚，原因就是作者把逻辑理顺了。
所以我的建议是：先用最顺手的工具把逻辑画出来，确认结构没问题之后，再考虑美化。不要本末倒置。
3. 画图之前的必修课：先想清楚这四件事再动手
3.1 确定图的“读者”和“场景”
这是所有 diagram-design 的起点。同一套系统，给不同的人看，需要完全不同的画法。
| 读者类型 | 关注重点 | 推荐图类型 | 信息密度 |
|---|---|---|---|
| 高层管理者 | 整体结构、关键模块、风险点 | 简化的架构图 | 低，不超过10个节点 |
| 同组工程师 | 接口定义、数据流向、边界条件 | 详细的时序图/流程图 | 中高，可到30个节点 |
| 运维人员 | 部署拓扑、网络分区、依赖关系 | 部署图/网络图 | 中，强调连接关系 |
| 新入职同事 | 模块职责、调用关系、核心链路 | 分层架构图+核心时序图 | 中，需要图例和注释 |
| 外部合作方 | 系统边界、交互方式、数据格式 | 上下文图/接口图 | 低，只画交互部分 |
这个表格不是死规矩，但它能帮你快速定位“这张图该画到什么程度”。我见过太多人给老板汇报时用工程师视角的详细图，结果老板看了三分钟只问了一句“所以我们的核心优势是什么”。这就是读者错配。
3.2 确定图的“核心信息”
在动手之前，用一句话写下这张图要表达的核心信息。比如：
- “用户请求从网关进入后，经过鉴权、路由、业务处理、数据存储四个阶段”
- “系统分为接入层、服务层、数据层三层，每层包含哪些模块”
- “订单状态在创建、支付、发货、完成、取消五个状态之间的流转条件”
这句话就是你的“图眼”。画完之后，检查一遍：如果读者看完图之后能复述出这句话，说明图成功了；如果读者看完之后说了一堆无关的细节，说明图失败了。
3.3 确定图的“视觉层级”
任何一张好图都有明确的视觉层级。什么是视觉层级？就是读者眼睛应该先看哪里、再看哪里、最后看哪里。
常见的视觉层级设计手法包括：
- 大小对比：核心模块画大一点，辅助模块画小一点
- 颜色对比：关键路径用高亮色，次要路径用灰色
- 位置对比：主要流程从左到右或从上到下，辅助信息放在边缘
- 粗细对比：主流程连线加粗，次要连线变细
我个人的习惯是，在画图之前先用纸笔勾一个草图，标出“第一眼应该看到什么”。这个草图不需要好看，只需要把层级关系确定下来。很多图之所以乱，就是因为所有元素都在“抢眼球”，没有主次之分。
3.4 确定图的“边界”
一张图必须明确画出“什么在范围内，什么在范围外”。这个边界可以是系统边界、团队边界、时间边界、或者职责边界。
比如画架构图时，我会用虚线框把“本次讨论的范围”框出来，框外的部分用灰色表示“不在本次讨论中”。这样做的好处是，读者不会问“为什么没有画 XX 模块”这种问题，因为图上已经明确说了“XX 不在范围内”。
边界不清是导致图越画越大的主要原因。每次有人问“要不要把 XX 也加进去”，你就得重新调整整张图的布局。提前画好边界，能省掉大量返工时间。
4. 不同类型图的实战画法：从流程图到架构图的具体套路
4.1 流程图：重点是“判断条件”和“异常分支”
流程图是最常见的图类型，也是最容易画烂的。大多数人画流程图只画“正常路径”，把异常分支全部省略，结果就是图看起来很简洁，但实际使用时发现“这个情况没覆盖到”。
我的做法是：先画正常路径，再用不同颜色补上异常分支。正常路径用黑色或深蓝色，异常分支用橙色或红色。这样读者一眼就能看出“主流程是什么”和“哪些地方可能出问题”。
另一个关键点是判断条件的标注。很多人画菱形判断框时只写“是否满足条件”，但不写具体条件是什么。这是大忌。正确的做法是把条件写清楚，比如“库存 > 0？”而不是“库存检查”。条件越具体，图的可执行性越强。
还有一个细节：流程图的连线尽量避免交叉。如果实在避不开，用“跳线”符号表示交叉但不连接。我见过一张流程图有十几处连线交叉，读者根本分不清哪条线连到哪里。这种图还不如不画。
4.2 时序图：生命线和激活框的取舍
时序图是表达“谁在什么时候调用了谁”的最佳工具，但它也是最容易画得过于复杂的图类型。一张时序图如果有超过五个参与者，基本上就很难在一屏内看清了。
我的经验是：时序图只画核心链路，把非核心的调用折叠成注释。比如一个请求经过网关、鉴权、业务服务、缓存、数据库五个环节，如果每个环节内部还有十几个子调用，那就只画到“业务服务”这一层，内部细节用文字注释说明。
另一个技巧是合理使用“激活框”。激活框表示对象在处理请求的时间段，但很多人画时序图时把所有对象的激活框都画得很长，导致图看起来像一堆重叠的矩形。正确的做法是：只给“当前正在处理”的对象画激活框，其他对象保持静默。
还有一点：时序图的返回值不要省略。很多人只画请求箭头，不画返回箭头，导致读者不知道这个调用是同步还是异步、有没有返回值。返回箭头用虚线表示，并在上面标注返回内容。
4.3 架构图：分层是王道，但别硬分
架构图的核心是“分层”。常见的分层方式包括：
- 按职责分：接入层、业务层、数据层
- 按部署分：客户端、网关、服务端、存储
- 按团队分：前端团队、后端团队、算法团队、基础设施团队
但分层不是越多越好。我见过有人把系统分成七层，结果每层只有一两个模块，图看起来又高又瘦，信息密度极低。一般来说，三到五层是比较舒服的范围。
分层之后，层与层之间的连线要尽量简洁。如果两层之间有大量交叉调用，说明分层可能不合理，需要考虑调整模块归属。架构图的美感很大程度上来自于“层内聚合、层间清晰”。
另外，架构图一定要有图例。颜色代表什么、形状代表什么、连线样式代表什么，都要在图例里说清楚。我见过太多架构图用了一堆颜色但没有任何说明，读者只能靠猜。
4.4 状态机图：状态命名和转移条件是关键
状态机图在业务系统里非常实用，尤其是订单、工单、审批流这类有明确状态流转的场景。但很多人画状态机图时，状态命名很随意，比如“处理中”“待处理”“已处理”，读者根本分不清这几个状态的区别。
我的建议是：状态命名要具体、互斥、可判定。比如“待支付”“已支付待发货”“已发货待收货”“已完成”“已取消”，每个状态都有明确的进入条件和退出条件。转移条件也要写清楚，比如“支付成功”触发“待支付→已支付待发货”，“超时未支付”触发“待支付→已取消”。
状态机图还有一个容易忽略的点：初始状态和终止状态要明确标注。初始状态用实心圆表示，终止状态用带圈的实心圆表示。这样读者一眼就能看出流程的起点和终点。
5. 工具选型：从手绘到代码化绘图，什么场景用什么工具
5.1 手绘草图：被低估的沟通利器
很多人觉得手绘草图“不专业”，但实际上，在早期讨论和快速迭代阶段，手绘草图是最有效的沟通工具。原因很简单：草图传递的信号是“这个想法还不成熟，欢迎修改”，而精美的电子图传递的信号是“这个方案已经定了，你只需要理解”。
我在做方案评审时，经常先在白板上画草图，边画边讲，让参与者随时打断和修改。等讨论得差不多了，再拍照存档，后续用工具重新画成正式图。这个流程比直接画电子图效率高得多，因为电子图的修改成本高，会让人不自觉地“护图”，不愿意接受修改意见。
如果你需要远程协作，可以用简单的绘图工具模拟手绘效果，比如 Excalidraw 这类工具，它的默认风格就是手绘风，非常适合早期讨论。
5.2 代码化绘图：可维护性的终极方案
如果你的图需要频繁修改、需要版本管理、需要嵌入文档，那么代码化绘图是唯一正确的选择。所谓代码化绘图，就是用文本描述图的结构，然后由工具渲染成图。常见的方案包括：
- Mermaid：语法简单，支持流程图、时序图、状态图、类图等，适合嵌入 Markdown 文档
- PlantUML：功能更强大，支持更多图类型，但语法相对复杂
- Graphviz：基于 DOT 语言，适合画复杂的依赖关系图
- Diagrams：用 Python 代码画架构图，适合有编程背景的工程师
代码化绘图的最大优势是可维护性。当你需要修改一个模块名称时，只需要改一行文本，所有相关的图都会自动更新。而用传统绘图工具，你需要手动找到所有出现这个名称的地方逐一修改，费时费力还容易漏。
我自己的文档里大量使用 Mermaid，因为它的语法足够简单，而且大多数 Markdown 编辑器都支持渲染。下面是一个简单的时序图示例：
sequenceDiagram participant C as 客户端 participant G as 网关 participant S as 业务服务 participant D as 数据库 C->>G: 发起请求 G->>G: 鉴权校验 G->>S: 转发请求 S->>D: 查询数据 D-->>S: 返回结果 S-->>G: 返回响应 G-->>C: 返回响应注意：虽然 Mermaid 很方便，但它对复杂布局的控制能力有限。如果你的图需要精确的布局控制，还是得用传统绘图工具。
5.3 传统绘图工具：什么时候必须用
传统绘图工具（如各种在线绘图平台和桌面绘图软件）的优势在于布局自由度高、视觉效果可控。以下场景建议使用传统工具：
- 需要精确控制每个元素的位置和大小
- 需要复杂的视觉效果（阴影、渐变、图标）
- 需要导出高分辨率图片用于印刷或大屏展示
- 需要与不熟悉代码化绘图的同事协作
但传统工具也有明显的劣势：版本管理困难、修改成本高、难以嵌入文档。所以我的建议是：代码化绘图为主，传统工具为辅。日常文档用代码化绘图，重要汇报和对外材料用传统工具精修。
5.4 工具选型对比表
| 工具类型 | 代表方案 | 适合场景 | 学习成本 | 可维护性 |
|---|---|---|---|---|
| 手绘草图 | 白板、纸笔、手绘风工具 | 早期讨论、快速迭代 | 极低 | 低 |
| 代码化绘图 | Mermaid、PlantUML | 技术文档、版本管理 | 中 | 极高 |
| 传统绘图 | 在线绘图平台、桌面软件 | 正式汇报、对外材料 | 中高 | 中 |
| 专业建模 | 建模工具 | 复杂系统建模 | 高 | 中 |
6. 让图“好看”的五个细节：颜色、字体、对齐、留白、图例
6.1 颜色：不超过三种主色，且要有语义
颜色是 diagram-design 里最容易滥用的元素。很多人觉得颜色越多越好看，结果画出来的图像彩虹一样，读者根本不知道每种颜色代表什么。
我的原则是：主色不超过三种，且每种颜色都要有明确的语义。比如：
- 蓝色：核心模块或主流程
- 绿色：成功路径或正常状态
- 红色：异常路径或风险点
- 灰色：辅助信息或不在范围内的内容
颜色一旦赋予语义，就要在全图中保持一致。不能这张图里蓝色代表“前端”，那张图里蓝色代表“数据库”。一致性是图可读性的基础。
另外，注意颜色的对比度。浅色背景上用深色文字，深色背景上用浅色文字。我见过有人在深蓝色背景上用深蓝色文字标注，根本看不清。这种低级错误在实际项目中并不少见。
6.2 字体：统一字号，层级分明
字体的问题主要有两个：字号不统一和字体类型不统一。一张图里如果出现了三种以上的字号，读者会感到混乱。我的建议是：
- 标题字号：最大，加粗
- 模块名称字号：中等，常规
- 注释字号：最小，可斜体
字体类型也要统一。要么全用无衬线字体（如黑体），要么全用衬线字体（如宋体），不要混用。混用字体会让图看起来像拼凑出来的。
还有一个细节：文字不要压在连线上。我见过很多图，连线穿过文字，导致文字难以辨认。正确的做法是调整文字位置或连线路径，让两者互不干扰。
6.3 对齐：网格化布局是专业感的来源
对齐是区分“业余图”和“专业图”的最明显标志。业余图里的元素东一个西一个，大小不一、间距不等；专业图里的元素整齐排列，间距均匀。
实现对齐最简单的方法是使用网格。大多数绘图工具都支持网格吸附功能，开启之后，元素会自动对齐到网格线上。如果没有网格功能，可以手动拉辅助线。
对齐的另一个层面是间距一致。同一层级的模块之间，间距应该相同；不同层级之间，间距可以不同，但也要有规律。我通常用“8 的倍数”作为间距单位，比如模块间距 16px、层级间距 32px。这样图看起来会有节奏感。
6.4 留白：图不是越满越好
留白是很多新手忽略的元素。他们觉得图里空白太多是“浪费空间”，于是把每个角落都塞满内容。结果就是图看起来拥挤、压抑，读者找不到视觉休息的地方。
留白的作用是引导视线和划分区域。模块之间的留白表示“这两个模块是独立的”，层级之间的留白表示“这是两个不同的层级”。留白越充分，图的层次感越强。
我的经验是：图的边缘至少留出 10% 的空白，模块之间的间距至少是模块高度的 20%。如果图看起来太挤，宁可拆成两张图，也不要硬塞。
6.5 图例：别让读者猜
图例是图的“说明书”。颜色代表什么、形状代表什么、连线样式代表什么，都应该在图例里说清楚。但很多人觉得图例“占地方”，于是省略不画，结果读者只能靠猜。
图例的位置通常在图的右下角或左下角，不要放在图的中央干扰视线。图例的样式要简洁，每个条目只需要“符号 + 简短说明”即可。
如果图里用到的视觉元素很少（比如只有两种颜色），图例可以简化成一行文字说明，比如“蓝色：读操作；橙色：写操作”。但如果视觉元素超过三种，就必须画完整的图例。
7. 我在实际项目中踩过的坑：五个真实教训
7.1 教训一：图太大，导出后根本看不清
早期做架构图时，我总想把所有模块都画进去，结果图越画越大，导出成 PNG 之后，在文档里缩放到合适大小，文字根本看不清。读者需要放大到 200% 才能阅读，体验极差。
后来我学乖了：先确定图的最终展示尺寸，再决定画多少内容。如果图最终要放在 A4 文档里，宽度不超过 800px，那么图里的文字至少要有 12px，模块数量不超过 15 个。超过这个限制，就拆图。
7.2 教训二：连线交叉太多，读者直接放弃
有一次画一个调用关系图，模块之间有大量交叉调用，我硬是把所有连线都画上了，结果图看起来像一团乱麻。评审时有人直接说“这张图我看不懂”，然后整个讨论就卡住了。
后来我改用“分层 + 分组”的方式重画：把相互调用密集的模块放在同一层，层间只画少量跨层连线。虽然丢失了一些细节，但图的可读性大幅提升。读者先理解整体结构，再根据需要深入细节。
7.3 教训三：颜色语义不一致，造成误解
有一次我在两张图里用了同一种颜色表示不同的含义。第一张图里蓝色表示“前端模块”，第二张图里蓝色表示“数据库”。结果有人在评审时问“为什么前端模块直接连到了数据库”，我才发现是颜色语义不一致造成的误解。
从那以后，我给自己定了一条规矩：同一个项目里的所有图，颜色语义必须统一。如果实在需要不同的颜色方案，就在图例里明确说明，并且尽量避免在同一份文档里混用。
7.4 教训四：忘记更新图，导致文档过期
这是最隐蔽的坑。代码改了，文档里的图没改，结果新同事按照过期的图去理解系统，踩了一堆坑。这种问题在快速迭代的项目里尤其常见。
解决方法是把图纳入版本管理。如果用代码化绘图，图就和代码一起提交，改代码时顺手改图。如果用传统工具，就在文档里标注图的更新日期和对应版本，并在代码变更时检查是否需要更新图。
7.5 教训五：过度美化，反而降低可读性
有一段时间我迷上了给图加各种视觉效果：阴影、渐变、3D 效果、图标。结果图看起来确实“高级”了，但可读性反而下降了。因为那些视觉效果分散了读者的注意力，让读者花更多时间在“欣赏”上，而不是“理解”上。
后来我回归极简风格：白底、黑字、少量颜色、无阴影、无渐变。图看起来朴素了，但信息传递效率大幅提升。读者能在一秒内找到核心信息，这才是 diagram-design 的终极目标。
8. 从“能看”到“好用”：建立自己的绘图规范和检查清单
8.1 建立个人绘图规范
如果你经常需要画图，建议建立一套自己的绘图规范。规范不需要很复杂，但至少要包含以下内容：
- 颜色规范：每种颜色代表什么含义
- 字体规范：标题、正文、注释分别用什么字号和字体
- 布局规范：模块间距、层级间距、边缘留白
- 命名规范：模块名称的命名风格（中文/英文、驼峰/下划线）
- 图例规范：图例的位置和样式
这套规范一旦建立，你画图的速度会大幅提升，因为不需要每次重新做决策。而且图与图之间的一致性会更好，读者看起来更舒服。
8.2 发布前的检查清单
每次发布图之前，花两分钟过一遍这个检查清单：
- 这张图的核心信息是什么？读者能在一句话内复述出来吗？
- 图里的文字在最终展示尺寸下能看清吗？
- 颜色语义是否一致？是否有图例说明？
- 连线是否有交叉？交叉处是否有跳线标识？
- 是否有明确的起点和终点？读者知道从哪里开始看吗？
- 是否有不在范围内但容易引起疑问的内容？是否需要标注“不在范围内”？
- 图是否与当前代码/文档版本一致？
这个清单看起来简单，但能帮你避免 90% 的常见问题。我自己的经验是，每次发布前过一遍清单，能省掉大量后续解释和返工的时间。
8.3 持续迭代：图是活的
最后想说一点：图不是画完就完了，它是活的。系统在变，图也要跟着变。我见过太多项目，文档里的图还是两年前的版本，早就和实际系统对不上了。
所以我的建议是：把图当成代码来维护。每次系统变更时，检查相关图是否需要更新。如果图太多维护不过来，就只维护核心图，把次要图标记为“历史版本，仅供参考”。
图的价值在于“准确”，不在于“多”。一张准确的简图，胜过十张过期的详图。这个道理，我在踩了无数次坑之后才真正明白。希望这些经验能帮你少走一些弯路，画出真正“好用”的图。
