企业官网建设流程全解析

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

第一次看到 “diagram-design” 这个标题，很多人会以为它只是教你怎么画流程图、时序图或者架构图。但真正做过技术方案、写过设计文档、给团队做过架构评审的人都知道，画图这件事从来不是“画得好看”这么简单。它背后牵扯的是一整套信息表达系统：你要把脑子里模糊的结构变成别人能看懂的图形，要把复杂的调用链路压缩成一张不丢关键信息的拓扑，还要让不同角色——开发、产品、运维、管理层——在同一张图上各取所需。

diagram-design 这个项目，核心就是围绕“图的设计”做文章。它不是某个具体绘图工具的教程，也不是单纯的设计规范合集，而是一套从需求拆解、图形选型、布局规划到最终落地的完整方法论。你可以把它理解成“技术图表的交互设计指南 + 信息架构方法论 + 实操工具箱”的三合一。它解决的问题很具体：为什么你画的架构图别人看不懂？为什么评审会上大家对着同一张图各说各话？为什么图越画越多，但真正能沉淀下来复用的几乎没有？

这套内容适合谁看？如果你是需要输出技术方案的后端开发、需要画业务流程图的产品经理、需要做系统拓扑的运维工程师，或者只是想在汇报里把复杂逻辑讲清楚的职场人，diagram-design 的思路都能直接套用。它不要求你会用 Visio、Draw.io 或者 Figma，甚至不要求你有设计基础，但它要求你具备一种能力：把“想清楚”和“画明白”之间的鸿沟填平。

我见过太多团队在 diagram-design 这件事上踩坑。有人花两小时调对齐线，结果图是漂亮了，但关键的数据流向标反了；有人把二十个微服务塞进一张图，密密麻麻像电路板，评审时没人愿意看第二眼；还有人用同一套图应付所有场景，给老板看的是技术细节，给开发看的是业务愿景，最后两边都不满意。这些问题的根源，都不是工具不熟练，而是没有建立“图的设计思维”。

diagram-design 的价值就在于，它把“画图”这件事从审美问题拉回到了信息传达问题。它告诉你：一张好的技术图，第一目标是准确，第二目标是高效，第三目标才是好看。顺序错了，后面全错。接下来的内容，我会从整体设计思路、核心细节、实操过程、常见问题四个维度，把这套方法论拆开揉碎，结合我自己的踩坑经验，给你一套可以直接抄作业的方案。

2. 整体设计思路：为什么你的图总是“差点意思”

2.1 图的本质是信息压缩，不是美术创作

很多人画图时第一反应是打开工具，然后开始拖拽图形。这个顺序本身就错了。diagram-design 的核心思路是：先确定这张图要回答什么问题，再决定用什么图形去承载答案。图不是装饰品，它是信息的压缩包。一张架构图如果不能让读者在 30 秒内找到“请求从哪进、经过谁、到哪去”，那它再好看也是失败的。

我习惯把图分成三类：解释型、探索型和记录型。解释型图用于汇报和评审，目标是让外行也能看懂主干逻辑；探索型图用于自己梳理思路，允许混乱和迭代；记录型图用于文档沉淀，要求精确和可追溯。这三类图的设计策略完全不同。解释型图要牺牲细节换清晰度，探索型图要保留所有可能性，记录型图要标注版本和边界条件。很多人的问题在于，用探索型的方式画了解释型的图，结果就是信息过载，读者直接放弃。

注意：在动手画任何一张图之前，先用一句话写下这张图的“核心结论”。如果写不出来，说明你还没想清楚，这时候画图只会把混乱可视化。

2.2 图形选型背后的认知逻辑

为什么架构图用方块和箭头，流程图用菱形判断框，时序图用竖线和横向箭头？这不是约定俗成，而是因为每种图形元素对应着特定的认知负担。方块代表“边界明确的实体”，箭头代表“有方向的关系”，菱形代表“分支决策”，竖线代表“时间轴上的参与者”。当你用错图形，读者的认知成本就会飙升。

diagram-design 里有一个很实用的原则：图形复杂度与信息密度成反比。也就是说，一张图里如果图形种类超过四种，读者的理解速度会断崖式下降。我见过有人在一张图里同时用了圆角矩形、直角矩形、菱形、圆形、圆柱体、云朵形状，还加了虚线、点划线、双线箭头。这种图的信息密度确实高，但认知成本更高，最后没人愿意看。

我的建议是，任何一张图里，图形种类控制在三种以内。实体用矩形，关系用箭头，分组用背景框，足够了。颜色也一样，主色不超过三种，分别代表“正常”“异常”“待定”就够了。不要用颜色去区分十个不同的服务，那是图例该干的事，不是颜色该干的事。

2.3 布局决定阅读顺序，阅读顺序决定理解效率

布局是 diagram-design 里最容易被忽视，但影响最大的环节。同样的节点和连线，横着排和竖着排，读者的理解路径完全不同。人眼天然习惯从左到右、从上到下的阅读顺序，所以图的布局应该顺应这个习惯，而不是对抗它。

对于请求链路类的图，我强烈建议用从左到右的横向布局，因为“请求发起→处理→返回”天然是一个时间序列。对于层级结构类的图，用从上到下的纵向布局更合适，因为“上层依赖下层”是一个空间隐喻。对于状态流转类的图，用环形布局或者从左到右的线性布局都可以，关键是把“初始状态”放在最左边或最上方。

还有一个细节：连线尽量不要交叉。如果交叉不可避免，用“跳线”符号标注，或者把交叉点放在图的边缘区域。我见过一张微服务调用图，连线交叉了三十多次，读者需要用手指顺着线走才能找到目标服务。这种图的信息传达效率几乎为零。

2.4 为什么我坚持“一图一结论”

diagram-design 里有一个硬性规则：一张图只回答一个问题。如果你想同时展示系统架构、数据流向、部署拓扑和权限模型，那就画四张图，而不是把四张图叠在一起。这个规则听起来简单，但执行起来很难，因为大家都想“省事”，觉得一张图能搞定的事没必要画四张。

但实测下来，一张图塞多个结论的后果是：读者只能记住最后一个结论，前面的全忘了。认知心理学里有个“注意力残留”效应，当你在多个信息源之间切换时，前一个信息会残留在大脑里，干扰后一个信息的处理。图越复杂，这种干扰越严重。所以，与其画一张“全能图”，不如画四张“单点图”，每张图只回答一个问题，读者看完四张图，四个结论都记住了。

3. 核心细节解析：从需求到成图的六个关键环节

3.1 需求拆解：先写提纲，再画图

画图之前，先用文字把要表达的内容写下来。这个步骤听起来很笨，但效果极好。我通常会用三级提纲：第一级是“这张图要回答的核心问题”，第二级是“回答这个问题需要哪些信息块”，第三级是“每个信息块包含哪些具体节点和关系”。写完提纲，图的骨架就出来了。

举个例子，如果要画一张“用户登录流程”的图，提纲可能是这样的：核心问题是“用户从输入账号密码到登录成功，经过了哪些系统，每个系统做了什么”。信息块包括“前端交互”“网关鉴权”“用户服务”“会话管理”。每个信息块下面再列具体节点，比如“前端交互”下面有“输入框校验”“加密传输”“错误提示”。提纲写完，你只需要把文字翻译成图形，而不是对着空白画布发呆。

提示：提纲里的每个节点，都应该是一个“名词”或“名词短语”，而不是一个句子。如果某个节点写成了句子，说明它应该被拆成多个节点，或者它根本不该出现在这张图里。

3.2 图形语义的标准化

diagram-design 强调图形语义的一致性。什么意思？就是同一张图里，同样的图形必须代表同样的含义。如果你用矩形代表服务，那所有服务都必须是矩形，不能有的服务用矩形，有的用圆角矩形。如果你用实线箭头代表同步调用，那所有同步调用都必须是实线箭头，不能混用虚线和实线。

这个规则听起来是废话，但我见过太多图违反它。有人用虚线箭头表示“异步消息”，又用虚线箭头表示“可选依赖”，还用虚线箭头表示“历史遗留”。读者看到虚线箭头，根本不知道它代表什么。正确的做法是：每种关系类型只对应一种线型。同步调用用实线，异步消息用虚线，数据流用粗线，控制流用细线。如果关系类型超过四种，说明这张图太复杂了，应该拆图。

3.3 节点命名的信息密度控制

节点命名是 diagram-design 里最考验功力的地方。名字太短，读者看不懂；名字太长，图面拥挤。我的经验是：节点名称控制在 2 到 6 个汉字之间，英文控制在 1 到 3 个单词之间。如果名称超过这个长度，用缩写或者编号，然后在图例里解释。

比如“用户身份认证与授权服务”这个名字太长了，可以缩写成“认证服务”，然后在图例里写“认证服务：负责用户身份认证与权限校验”。再比如“订单创建事件消息队列”可以缩写成“订单MQ”，图例里解释“订单MQ：接收订单创建事件，异步通知下游系统”。

还有一个技巧：用动词短语命名动作节点，用名词短语命名实体节点。比如“校验参数”是动作节点，“订单服务”是实体节点。这样读者一眼就能区分哪些是“东西”，哪些是“事情”。

3.4 连线标注的取舍

连线上的标注，是图里信息密度最高的地方。标注太多，图面混乱；标注太少，读者看不懂关系。我的原则是：只标注“不标注就会产生歧义”的信息。比如两个服务之间的调用，如果协议是 HTTP，可以不标；但如果一个是 HTTP，一个是 gRPC，就必须标。再比如数据流向，如果箭头方向已经明确了，就不需要再标“数据流向”；但如果箭头方向有歧义，就必须标。

标注的格式也要统一。我习惯用“协议 + 动作”的格式，比如“HTTP 调用”“gRPC 调用”“MQ 推送”“DB 查询”。如果标注太长，可以用编号，然后在图例里解释。比如连线旁边标“①”，图例里写“①：HTTP 调用，超时 3 秒，重试 2 次”。

3.5 图例与注释的规范

图例是图的“字典”，读者遇到不认识的图形或标注时，会去图例里找答案。所以图例必须完整、准确、易查。我见过很多图没有图例，或者图例只写了一半，读者只能靠猜。diagram-design 的建议是：任何非标准图形、非标准线型、缩写、编号，都必须在图例里解释。

注释和图例不同，注释是对图中某个特定节点的补充说明。比如某个服务旁边加一个注释框，写“该服务正在迁移中，预计下月下线”。注释的位置要尽量靠近被注释的节点，用虚线连接，避免读者找不到对应关系。注释的文字要简短，超过两行的注释应该考虑放到图外的文档里。

3.6 版本管理与变更记录

图是会变的。系统迭代了，图也要跟着更新。但很多人画完图就扔在文档里，再也不管了。结果半年后有人来看图，发现图上的服务和实际系统完全对不上。diagram-design 强调：每张图都要有版本号和变更记录。版本号可以简单用日期，比如“2025-01-15”，变更记录写在图的下方或单独的表格里，说明“本次更新：新增支付服务，移除旧版鉴权模块”。

如果图是嵌入在文档里的，变更记录可以写在文档的修订历史里。如果图是独立文件，建议在文件末尾加一个“变更记录”表格。这个习惯看起来麻烦，但当你需要回溯“为什么当时这么设计”时，它会救你的命。

4. 实操过程：一张架构图的完整诞生记录

4.1 场景设定与目标明确

假设我们要画一张“某电商系统订单创建流程”的架构图。目标读者是开发团队和新加入的运维人员，核心问题是“用户点击下单后，系统内部发生了什么”。这张图需要回答三个子问题：请求经过了哪些服务？每个服务做了什么？异常情况怎么处理？

先写提纲。核心问题：订单创建流程。信息块：前端交互、网关层、订单服务、库存服务、支付服务、消息队列、数据库。每个信息块下面列节点：前端交互包括“提交订单”“参数校验”“加密传输”；网关层包括“路由转发”“限流”“鉴权”；订单服务包括“创建订单”“扣减库存”“生成支付单”；库存服务包括“库存查询”“库存锁定”；支付服务包括“支付单创建”“支付回调”；消息队列包括“订单创建事件”“库存锁定事件”；数据库包括“订单库”“库存库”“支付库”。

提纲写完，图的信息块和节点就确定了。接下来是图形选型：实体用矩形，动作不用单独图形，而是写在实体内部的文字里。关系用箭头，同步调用用实线，异步消息用虚线。分组用背景框，前端、网关、服务层、数据层各一个背景框。

4.2 布局规划与草图绘制

布局采用从左到右的横向布局，因为订单创建是一个时间序列。最左边是“用户”，然后是“前端”，接着是“网关”，再是“订单服务”“库存服务”“支付服务”，最右边是“数据库”和“消息队列”。消息队列放在下方，因为它是异步的，不占用主流程的横向空间。

草图用纸笔或者白板工具画，不要一上来就用专业绘图软件。草图阶段的目标是确定节点位置和连线走向，不追求美观。我通常会用便利贴代表节点，在墙上或桌子上摆位置，摆到满意为止。这个阶段可以大胆试错，移动节点的成本几乎为零。

草图确定后，用手机拍下来，作为后续绘制的参考。拍照时注意光线和角度，确保所有节点和连线都清晰可见。如果草图太乱，可以用不同颜色的笔标注不同类型的节点和连线，方便后续识别。

4.3 工具选型与参数配置

工具选型没有绝对的好坏，关键看场景。如果是个人梳理思路，纸笔或白板工具最快；如果是团队协作，Draw.io 或 Figma 更合适；如果是文档嵌入，Mermaid 或 PlantUML 更方便版本管理。我个人的习惯是：探索型图用纸笔，解释型图用 Draw.io，记录型图用 Mermaid。

以 Draw.io 为例，配置参数如下：画布大小设为 A3 横向，网格间距 10px，开启对齐网格和参考线。图形库选择“网络”和“软件”两个分类，够用了。颜色方案用默认的蓝色系，主色 #DAE8FC，边框色 #6C8EBF，文字色 #000000。箭头样式用“经典”箭头，线宽 1.5pt，实线用于同步调用，虚线用于异步消息。

注意：不要花太多时间在工具配置上。我见过有人花一个小时调字体和颜色，结果图的内容还没画完。工具是服务于内容的，内容没想清楚，工具再熟练也没用。

4.4 节点绘制与连线标注

先画背景框，把前端、网关、服务层、数据层四个区域框出来，每个背景框左上角标注区域名称。然后在背景框内放置节点，节点大小统一为 120x60px，圆角半径 5px。节点名称用 14px 字体，居中显示。如果节点名称超过 6 个汉字，缩小字体到 12px，或者换行显示。

连线从“用户”开始，依次连接“前端”“网关”“订单服务”“库存服务”“支付服务”“数据库”。同步调用用实线箭头，箭头指向被调用方。异步消息用虚线箭头，从“订单服务”指向“消息队列”，再从“消息队列”指向“库存服务”和“支付服务”。连线上的标注用 10px 字体，放在连线中间偏上位置，避免遮挡箭头。

连线交叉的处理：如果两条连线必须交叉，用“跳线”符号，即一条线在交叉处画一个小弧线，表示“跨过”另一条线。跳线符号在 Draw.io 里有现成的，直接拖拽即可。如果交叉太多，考虑调整节点位置，或者拆成两张图。

4.5 图例、注释与版本信息

图例放在图的右下角，包含以下内容：矩形代表服务，实线箭头代表同步调用，虚线箭头代表异步消息，背景框代表分层。如果有缩写，比如“MQ”代表消息队列，也在图例里解释。注释放在相关节点旁边，用虚线连接，文字用 10px 字体，颜色用灰色，区别于正文。

版本信息放在图的左下角，格式为“版本：2025-01-15 | 作者：某开发者 | 变更：初始版本”。如果图有更新，在版本信息下方加一行“变更记录”，列出每次更新的内容。比如“2025-02-01：新增支付服务，调整库存服务位置”。

4.6 评审与迭代

图画完后，不要直接发布。先找两三个目标读者（比如开发同事和运维同事）看一眼，问他们三个问题：这张图回答了你的问题吗？有没有看不懂的地方？有没有多余的信息？根据反馈迭代，通常需要改两到三轮。

评审时要注意：不要问“你觉得好看吗”，要问“你能看懂吗”。好看是主观的，看懂是客观的。如果读者需要超过 30 秒才能找到核心信息，说明图的设计有问题。如果读者问“这个箭头是什么意思”，说明图例不完整。如果读者说“信息太多了”，说明图需要拆分。

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

5.1 图太复杂，读者看不懂怎么办

这是最常见的问题。排查思路：先数节点数量，如果超过 15 个，考虑拆图；再数图形种类，如果超过 4 种，统一图形；再数连线交叉次数，如果超过 5 次，调整布局；最后检查图例，如果图例不完整，补全图例。

拆图的策略：按时间阶段拆，比如“下单阶段”“支付阶段”“履约阶段”各一张图；按系统层级拆，比如“接入层”“服务层”“数据层”各一张图；按读者角色拆，比如“给开发看的图”“给运维看的图”“给产品看的图”。拆图后，用一张“总览图”串联，总览图只画主干流程，不画细节。

5.2 连线交叉太多，怎么优化

连线交叉的根源是节点位置不合理。优化方法：把关联紧密的节点放在一起，减少跨区域连线；把高频调用的服务放在同一层，减少上下穿插；把异步消息的节点放在图的边缘，避免穿过主流程。

如果交叉不可避免，用跳线符号标注，或者用不同颜色的连线区分。但颜色不要超过三种，否则图面会花。还有一个技巧：把连线交叉点集中在一个区域，用“交叉区域”标注，读者知道那里是交叉密集区，会放慢阅读速度。

5.3 节点命名太长，图面拥挤怎么办

节点命名超过 6 个汉字，图面就会拥挤。解决方法：用缩写，比如“用户身份认证服务”缩写成“认证服务”；用编号，比如“服务 A”“服务 B”，图例里解释；用图标代替文字，比如用数据库图标代替“数据库”三个字。

如果缩写后读者看不懂，说明缩写不够通用。通用的缩写包括“MQ”“DB”“API”“UI”“LB”等。非通用缩写必须在图例里解释。如果图例解释太长，考虑把节点名称放到图外的文档里，图上只放编号。

5.4 图例不完整，读者靠猜怎么办

图例不完整的表现：读者问“这个图形是什么意思”“这个箭头代表什么”“这个缩写是什么”。解决方法：画完图后，自己先看一遍，把所有非标准元素列出来，逐一在图例里解释。非标准元素包括：非矩形图形、非实线线型、非黑色文字、缩写、编号、特殊符号。

图例的位置要显眼，通常放在图的右下角或左下角。图例的字体可以比正文小一号，但不能太小，建议 10px 以上。图例的排列要整齐，按图形、线型、缩写、编号的顺序排列，方便读者查找。

5.5 图更新后，旧图还在流传怎么办

这是版本管理的问题。解决方法：每张图都有版本号和日期，旧图在文件名或标题里标注“已废弃”；新图发布时，在团队群里通知，说明变更内容；如果旧图嵌入在文档里，更新文档里的图，并在修订历史里记录。

还有一个技巧：在图的下方加一行“最新版本请访问 [链接]”，但链接不要用真实网址，用“内部文档系统”代替。如果图是打印出来贴在墙上的，旧图撕掉，换上新图。不要新旧图同时存在，否则读者会混淆。

5.6 常见问题速查表

5.7 独家避坑技巧

第一个技巧：画图前先写“图的目标”。用一句话写清楚这张图要回答什么问题，贴在画布旁边。画图过程中如果偏离目标，及时拉回来。这个习惯能节省大量返工时间。

第二个技巧：用灰度模式检查图的可读性。把图转成灰度，如果还能看懂，说明图形和线型的区分度足够；如果灰度下看不懂，说明你过度依赖颜色，需要加强图形和线型的区分。

第三个技巧：找非技术人员试读。如果非技术人员能在 30 秒内说出图的核心结论，说明图的设计合格；如果说不出来，说明图太复杂或者太专业。这个测试比找同行评审更有效，因为同行会“脑补”缺失的信息，非技术人员不会。

第四个技巧：图的文件名包含版本号和日期。比如“订单流程架构图_v2_20250115.drawio”，这样即使图被转发多次，也能追溯版本。不要用“最终版”“最终版2”“真正最终版”这种命名，那是自找麻烦。

第五个技巧：定期清理旧图。每季度检查一次文档里的图，把过期的图归档或删除。图不是越多越好，过期的图会误导读者，增加认知负担。保留最新版本和关键历史版本就够了，中间版本可以清理。

6. 从单张图到图体系：diagram-design 的进阶思路

6.1 建立图的分类体系

当你画的图超过十张，就需要建立分类体系了。我习惯按“读者角色”和“抽象层级”两个维度分类。读者角色分为“管理层”“产品”“开发”“运维”，抽象层级分为“业务级”“系统级”“组件级”“代码级”。每个角色关注不同的层级，比如管理层关注业务级，开发关注系统级和组件级，运维关注组件级和代码级。

分类体系建立后，每张图都有明确的归属。比如“订单业务流程”属于“业务级-产品”， “订单服务架构”属于“系统级-开发”，“订单服务部署图”属于“组件级-运维”。这样当有人问“有没有订单相关的图”时，你可以快速定位到对应的图，而不是翻遍所有文档。

6.2 图的复用与模板化

高频出现的图类型，可以做成模板。比如“微服务调用图”模板、“数据流图”模板、“状态机图”模板。模板包含固定的图形库、颜色方案、图例格式、版本信息格式。画新图时，直接套模板，只需要替换节点和连线，节省大量时间。

模板的维护也很重要。当团队的设计规范更新时，模板要同步更新。比如颜色方案从蓝色系改成绿色系，所有模板都要改。模板的版本号也要管理，避免有人用旧模板画新图，导致风格不一致。

6.3 图与文档的联动

图不是孤立的，它通常嵌入在文档里。图与文档的联动包括：图里的节点名称与文档里的术语一致；图里的版本号与文档的修订历史一致；图里的注释与文档的详细说明互补。如果图里用了缩写，文档里要有全称解释；如果文档里提到了某个流程，图里要有对应的可视化。

联动的关键是“单一信息源”。同一个信息不要在图和文档里重复维护，而是选择一处作为主信息源，另一处引用。比如节点名称以图为准，文档里引用图的节点名称；详细说明以文档为准，图里只放注释和链接。

6.4 图的评审机制

图的评审应该像代码评审一样，有固定的流程和标准。评审标准包括：目标是否明确、信息是否准确、布局是否合理、图例是否完整、版本是否标注。评审流程包括：作者自检、同行评审、目标读者试读、发布通知。

评审时要注意：不要评审“好看不好看”，要评审“看懂没看懂”。不要评审“信息全不全”，要评审“信息准不准”。不要评审“风格统一不统一”，要评审“语义一致不一致”。评审意见要具体，比如“这个箭头指向不明确，建议加标注”，而不是“这张图不行，重画”。

6.5 图的工具链整合

如果团队规模较大，图的工具链需要整合。比如用 Draw.io 画图，用 Git 管理版本，用 CI 自动生成 Mermaid 图，用文档系统嵌入图。工具链整合的目标是：图的创建、评审、发布、更新全流程可追溯、可协作、可自动化。

工具链整合的难点是“格式兼容”。Draw.io 的源文件是 XML，Mermaid 是文本，Figma 是专有格式。不同格式之间转换会丢失信息。所以，选择工具时要考虑团队的实际需求，不要盲目追求“全自动”。有时候，手动更新图比自动生成更可靠，因为手动更新时你会重新审视图的内容，自动生成可能会产生“垃圾图”。

6.6 图的长期维护策略

图是需要长期维护的资产，不是一次性消耗品。维护策略包括：指定图的负责人，负责图的更新和评审；建立图的更新触发机制，比如系统架构变更时自动触发图更新；定期审计图的准确性，比如每季度检查一次图与实际系统的一致性。

长期维护的关键是“降低更新成本”。如果更新一张图需要半小时，大家就不愿意更新；如果更新一张图只需要五分钟，大家就愿意更新。降低更新成本的方法包括：用模板、用自动化工具、用版本管理、用协作平台。我见过最有效的做法是：把图的源文件放在代码仓库里，和代码一起版本管理，代码变更时顺手更新图。

7. 我个人的实操体会

画了这么多年图，我最大的体会是：图的质量不取决于你用了什么工具，而取决于你想清楚了没有。想清楚了，用纸笔画草图也能传达核心信息；没想清楚，用再贵的工具画出来的图也是垃圾。diagram-design 这套方法论的核心，就是逼你在动手之前先动脑，把“画图”这件事从“美术创作”拉回到“信息设计”。

另一个体会是：图是给人看的，不是给机器看的。很多人画图时追求“完整”“精确”“规范”，结果图变得像电路图一样复杂，读者根本看不懂。好的图应该像好的演讲，有重点、有节奏、有留白。该省略的省略，该强调的强调，该拆分的拆分。一张图能回答一个问题，就是好图；一张图能回答三个问题，就是灾难。

最后分享一个小技巧：每次画完图，隔一天再看一遍。隔一天你的大脑会“重置”，你会像第一次看到这张图一样去阅读它。这时候你最容易发现“看不懂”“信息太多”“重点不突出”的问题。如果隔一天你还觉得这张图很好，那它大概率是真的好。如果隔一天你看不懂了，那就改，改到看懂为止。这个习惯我坚持了很多年，帮我避免了很多“自嗨型”的图。