1. 从"diagram-design"这个标题能读出什么第一次看到"diagram-design"这个标题，我的直觉是：这大概率不是一个单纯的"画图工具推荐"，而是一个关于图表设计方法论的项目。为什么这么说？因为如果只是推荐某个绘图软件，标题通常会带上具体工具名，比如"用XX画架构图"；而"diagram-design"这种命名方式，更像是在讨论"图表设计"这件事本身——怎么把复杂的信息用图表达清楚，怎么让一张图在没人讲解的情况下也能自解释。我在过去几年里做过不少技术文档、方案汇报和知识整理的工作，踩过最多的坑不是"不会用工具"，而是"图画出来了，但别人看不懂"。一张架构图发给同事，对方第一句话是"这个箭头是什么意思"；一张流程图放进文档，读者反馈"看了三遍还是不知道从哪开始"。这些问题的根源都不在工具，而在设计思路。所以这篇内容我想聊的，就是围绕"diagram-design"这个主题，把图表设计从"能画出来"到"画得让人一看就懂"之间的那层窗户纸捅破。这篇内容适合几类人看：一是经常需要画架构图、流程图、时序图的技术同学；二是要做方案汇报、需要把复杂逻辑可视化的产品和管理岗；三是做知识整理、笔记输出的内容创作者。不管你用的是哪款工具，下面这些设计原则和实操方法都是通用的。我会尽量把每个决策背后的"为什么"讲清楚，而不是只丢一堆步骤让你照抄。2. 图表设计的第一性问题：图是给谁看的2.1 先定读者，再定画法很多人画图的第一步是打开工具、拖一个方框出来，这是典型的"工具先行"。正确的顺序应该是：先想清楚这张图给谁看、在什么场景下看、看完要做什么决策。这三个问题的答案，直接决定了图的复杂度、配色、标注密度甚至尺寸。举个具体的对比。同样是描述一个系统的数据流，如果读者是同组工程师，他们熟悉业务背景，你可以用简写、可以省略中间步骤、可以直接上专业术语，图可以画得紧凑；但如果读者是跨部门的产品或管理层，他们不关心具体用了什么中间件，只关心"数据从哪来、经过什么处理、最终产出什么价值"，这时候你就得把技术细节折叠掉，用业务语言重新标注。我自己的习惯是，在动手之前先在纸上写一句话："这张图要让[谁]在[什么场景]下看懂[什么结论]"。这句话写不出来，说明你还没想清楚，这时候画出来的图大概率要返工。2.2 一张图只讲一件事新手最容易犯的错，是想用一张图把所有信息都塞进去。结果就是图越来越大、箭头越来越密、颜色越来越多，最后变成一张"什么都说了但什么都没说清"的蜘蛛网。我的经验是：一张图只承载一个核心信息。如果发现一张图里有两个并列的重点，那就拆成两张。比如"系统整体架构"和"某次请求的调用链路"就是两件事，前者讲静态结构，后者讲动态过程，硬画在一起只会互相干扰。这里有个判断标准：如果你需要用"另外""同时""顺便说一下"这类词来介绍图里的某部分内容，那部分内容就该独立成图。图不是文档，它没有"顺便"的空间，读者的视线是跳跃的，任何非主线信息都是干扰。2.3 信息层级比美观更重要我见过太多"好看但难读"的图——配色很高级、圆角很精致、阴影很柔和，但你就是找不到重点在哪。问题出在没有建立信息层级。信息层级说白了就是：哪些是主角，哪些是配角，哪些是背景。在视觉上，主角应该最大、最醒目、位置最居中；配角次之；背景最弱，甚至可以不画。具体到操作层面，我通常用三个维度来拉开层级：尺寸：核心模块的方框明显大于辅助模块颜色饱和度：重点用高饱和或深色，次要的用浅灰、浅蓝线条粗细：主流程的箭头粗，辅助关系的箭头细或虚线这三个维度不需要同时用满，通常用两个就足够拉开差距了。用满反而会显得花哨。3. 选工具之前，先搞清楚你要画的是哪类图3.1 四类常见图表的设计诉求完全不同"diagram"这个词太宽了，架构图、流程图、时序图、状态图，它们的设计逻辑差别很大。选错图类型，后面怎么优化都是白费。我整理了一个对照表，方便你快速定位：图类型核心表达关键元素常见误用架构图静态结构、模块关系方框、分组、连接线把调用时序也画进去流程图步骤顺序、分支判断流程节点、判断菱形、箭头分支过多导致线交叉时序图对象间的交互顺序生命线、消息箭头、激活条对象太多导致横向溢出状态图状态迁移与触发条件状态圆角框、迁移箭头、条件标注把动作和状态混为一谈这张表看着简单，但每一条"常见误用"背后都是真实的返工。比如架构图里画时序，最典型的症状就是箭头带上了"第1步、第2步"的编号，这时候图就不再是结构图，而是流程和结构的混合体，读者会困惑"这到底是静态的还是动态的"。3.2 工具选型的三个实际考量工具这块我不做具体品牌推荐，因为工具迭代太快，而且每个人的团队协作环境不同。但选型时有三个维度是通用的，你可以拿它去套任何一款工具：第一，文本化还是拖拽式。文本化工具（用代码描述图）的好处是能进版本控制、能diff、改起来快，适合工程师；拖拽式工具上手快、所见即所得，适合非技术岗。如果你的图需要频繁修改、需要和代码一起维护，优先选文本化的；如果是一次性汇报用，拖拽式更省时间。第二，布局是自动还是手动。自动布局省心，但复杂图容易乱；手动布局可控，但调整费时。我的折中做法是：结构简单的图用自动布局，结构复杂的图先自动生成再手动微调关键节点位置。第三，导出格式是否满足场景。放进文档要矢量图（SVG/PDF），放进PPT可能要PNG，嵌进网页可能要交互式。选工具前先确认它能不能导出你需要的格式，别画完了发现导不出来。提示：不要因为某个工具"流行"就选它。工具是为你服务的，先明确你的图类型、修改频率、协作方式，再去匹配工具，而不是反过来。3.3 一个被低估的准备工作：先列元素清单我现在的习惯是，画图之前先列一个"元素清单"：这张图里有哪些方框、哪些连线、哪些标注。清单列完，图的骨架就出来了，剩下的只是摆放问题。这个习惯的好处是，它强迫你在动手前把逻辑理清楚。很多时候列清单的过程中就会发现"这个模块其实不该出现在这张图里"或者"这两个模块的关系我还没想明白"。如果直接开画，这些问题会在画到一半时暴露，那时候改起来成本就高了。4. 让图表"自解释"的五个设计手法4.1 命名要具体，不要用"模块A""系统B"这是我最想强调的一点。很多图里全是"模块A""模块B""服务1""服务2"，读者看完根本不知道每个框是干什么的。方框里的文字应该是这个模块的职责描述，而不是它的代号。对比一下：差：模块A→模块B好：用户鉴权→订单处理如果名字太长放不下，可以用"主标题+副标题"的形式，主标题是简称，副标题用小字补充说明。比如主标题"鉴权服务"，副标题"校验token与权限"。这样即使读者不了解你的系统，也能大致猜到每个框的作用。4.2 箭头要有语义，不能只是"连着"箭头是图表里信息密度最高的元素，但也是最容易被滥用的。我见过很多图，箭头就是单纯表示"这两个东西有关系"，但到底是什么关系，全靠讲解。正确的做法是给箭头赋予明确的语义，常见的有几类：数据流：A把数据传给B，箭头方向就是数据方向依赖：A依赖B，通常用虚线或特定样式区分调用：A调用B的接口，可以标注调用的方法或协议继承/实现：用空心三角箭头，这是UML的通用约定如果一张图里同时存在多种关系，一定要用不同的线型或颜色区分，并在图例里说明。图例不是可有可无的装饰，它是读者理解图的钥匙。4.3 用分组框表达"边界"当图里的元素超过七八个，读者就开始迷失了。这时候分组是救命的。分组框（通常是一个虚线大框）能告诉读者"这几个东西是一伙的"，它们可能属于同一个服务、同一个层、同一个团队。分组的边界怎么定？我通常按这几个维度：按部署单元分（同一个服务里的模块放一起）、按职责层分（接入层、逻辑层、存储层）、按数据流向分（输入侧、处理侧、输出侧）。选一个维度贯穿始终，不要混用。4.4 关键路径加粗，次要路径弱化一张图里，真正的主流程往往只占少数，但很多图把所有线画得一样粗，读者分不清主次。把主流程的箭头加粗、颜色加深，把异常分支、补偿逻辑、监控链路用细线或浅色处理，读者的视线自然会被引导到主线上。这个手法在时序图里尤其有效。正常流程用实线粗箭头，异常或重试用虚线，读者一眼就能看出"哦，这是主路径，那些是兜底逻辑"。4.5 标注要克制，能省则省新手喜欢在图上加大量文字标注，生怕别人看不懂。但标注太多，图就变成了"带框的文章"，失去了可视化的意义。我的原则是：能在图里用视觉表达的，就不要用文字；必须用文字的，尽量短。比如"这个模块处理失败会重试三次"，与其写一行字，不如在箭头上标个"重试×3"。再比如"这两个模块是异步通信"，与其写说明，不如用虚线箭头加个"async"标签。文字是最后的手段，不是首选。5. 配色与排版：那些没人明说但很致命的细节5.1 配色不超过三种主色配色是图表设计里最容易翻车的地方。我的经验是：主色不超过三种，其余用中性灰。三种主色分别对应"重点""次重点""辅助"，中性灰用于背景、边框、非关键元素。为什么是三种？因为人眼在快速扫视时，能稳定区分的色相数量有限，超过三种就会显得杂乱，读者需要花精力去分辨"这个蓝色和那个蓝色有什么区别"，而不是关注内容本身。另外，避免用纯红和纯绿同时出现，色觉障碍人群无法区分。如果必须表达"正/负"或"通过/失败"，用蓝色和橙色替代，或者加上形状差异（比如对勾和叉号）。5.2 对齐是专业感的第一来源一张图看起来"专不专业"，很多时候不取决于配色多高级，而取决于对齐。方框的左边缘是否在一条线上、同一层的方框高度是否一致、箭头是否水平或垂直——这些细节决定了图的整洁度。手动拖拽的时候，一定要打开工具的网格和对齐辅助线。如果工具支持，尽量用"等间距分布"功能，让同一行的方框间距一致。这些操作花不了几分钟，但效果立竿见影。5.3 留白不是浪费空间新手总想把画布填满，觉得空白就是浪费。但留白是让图"呼吸"的关键。方框之间、分组之间、图和画布边缘之间，都要留出足够的间距。间距太小，图会显得拥挤压抑，读者的视线也没有休息的地方。我的经验值是：同级元素之间的间距，至少是元素高度的三分之一；分组框和内部元素之间，至少留出元素高度的二分之一。具体数值不用死记，视觉上"不挤"就行。5.4 字号要有层级，但别太多字号层级和颜色层级是一个道理，用来区分信息重要性。通常三级就够了：标题字号、正文字号、注释字号。标题最大，正文适中，注释最小。三级之外再加字号，读者反而会困惑"这个字号到底代表什么"。还有一个细节：同一层级的元素，字号必须一致。我见过有的图里，同样是模块名，有的用14号有的用12号，看起来就像没对齐一样别扭。画完之后统一检查一遍字号，这个习惯能省掉很多返工。6. 从草图到成图：我实际的工作流6.1 第一步永远是纸笔或白板不管最后用什么工具，我的第一版永远是手绘的。纸笔或白板的好处是没有工具的限制，你可以随便涂改、随便连线，专注于逻辑本身而不是"这个框怎么拖"。手绘阶段我只关心三件事：有哪些元素、它们怎么连、主流程是什么。配色、对齐、字号这些统统不管。这个阶段的目标是"逻辑正确"，不是"好看"。6.2 第二版用工具快速搭骨架手绘确认逻辑没问题后，转到工具里搭骨架。这一版也不追求美观，就是把方框和连线摆上去，确认布局合理、没有明显的线交叉。如果发现某个区域特别拥挤，回到手绘阶段重新调整布局思路。这个阶段我通常会刻意用最朴素的样式——黑白灰、直角框、细线。因为一旦开始调颜色和样式，注意力就从逻辑转移到外观上了，容易忽略结构问题。6.3 第三版才做视觉优化骨架确认后，才开始上色、调字号、加分组、优化箭头样式。这时候逻辑已经稳定了，视觉调整不会影响结构。顺序反过来——先美化再调逻辑——会导致你反复修改样式，效率极低。视觉优化我一般按这个顺序：先分组（确定边界），再配色（确定层级），再调字号（确定主次），最后微调对齐和间距。每一步只做一件事，做完检查一遍再进入下一步。6.4 最后一步：找个不了解背景的人看一眼这是我最推荐的一个习惯。图做完之后，找一个不了解这个项目的人（同事、朋友都行），让他看图，然后问他"你觉得这张图在讲什么"。如果他能说出个大概，说明图是自解释的；如果他一脸茫然，说明还有信息没表达清楚。这个"外人测试"能发现很多你自己看不见的问题，因为你太熟悉内容了，会自动脑补缺失的信息。外人的困惑点，就是你需要补充或简化的地方。7. 几个高频翻车场景与应对7.1 线交叉太多怎么办线交叉是复杂图的通病。应对方法有几个，按优先级排：第一，调整元素位置。把关联紧密的元素放近一点，交叉自然就少了。这是最有效的方法，但需要反复尝试。第二，用分组隔离。把相互之间连线多的元素放进同一个分组，分组内部的线就不会和外部交叉。第三，用连接点。如果工具支持，让连线从方框的特定边（上、下、左、右）出发，而不是从中心出发，能减少很多交叉。第四，拆图。如果以上都试过还是乱，说明信息量超了，该拆成两张图了。7.2 图太大放不进文档怎么办图太大通常有两个原因：元素太多，或者间距太大。如果是元素太多，考虑拆图或折叠次要信息；如果是间距太大，压缩间距和字号。还有一个技巧：把图旋转90度。横向的图在文档里往往受限于页宽，纵向的图受限于页高，哪个方向空间多用哪个。架构图通常横向展开，但如果文档是竖版，纵向布局可能更合适。7.3 改了需求要重画怎么办这是文本化工具的最大优势——改一行代码就能重新生成。如果你用的是拖拽式工具，建议在画的时候就保持结构清晰：同一层的元素用同样的样式、命名规范统一、分组边界明确。这样改的时候只需要动局部，不用推倒重来。另外，养成保存中间版本的习惯。有时候改着改着发现还是上一版好，没有版本记录就只能重画了。8. 关于图表设计，我踩过的最大的一个坑说了这么多方法，最后分享一个我自己的教训。早期我做图表设计，总想着"一次做到完美"，结果就是在一张图上反复打磨，配色调了又调、对齐改了又改，花了几个小时，最后发现逻辑本身就有问题，整张图推倒重来。后来我想明白了一件事：图表设计的本质是沟通，不是艺术创作。一张图好不好，不取决于它多精致，而取决于读者能不能快速准确地获取信息。配色、对齐、留白这些手法，都是为"沟通效率"服务的，不是目的本身。所以现在的我，画图时会不断问自己："这个设计决策，是让读者更容易理解，还是只是让我自己觉得好看？"如果是后者，果断砍掉。这个习惯帮我省下了大量时间，也让我的图真正变得"有用"而不是"好看"。如果你也在做图表设计相关的工作，我的建议是：先把逻辑理清楚，再用最朴素的方式画出来，最后才考虑美化。顺序对了，效率和质量都会上来。至于工具，够用就行，别在选工具上花太多时间，那是最容易本末倒置的地方。
1. 从"diagram-design"这个标题能读出什么第一次看到"diagram-design"这个标题，我的直觉是：这大概率不是一个单纯的"画图工具推荐"，而是一个关于图表设计方法论的项目。为什么这么说？因为如果只是推荐某个绘图软件，标题通常会带上具体工具名，比如"用XX画架构图"；而"diagram-design"这种命名方式，更像是在讨论"图表设计"这件事本身——怎么把复杂的信息用图表达清楚，怎么让一张图在没人讲解的情况下也能自解释。我在过去几年里做过不少技术文档、方案汇报和知识整理的工作，踩过最多的坑不是"不会用工具"，而是"图画出来了，但别人看不懂"。一张架构图发给同事，对方第一句话是"这个箭头是什么意思"；一张流程图放进文档，读者反馈"看了三遍还是不知道从哪开始"。这些问题的根源都不在工具，而在设计思路。所以这篇内容我想聊的，就是围绕"diagram-design"这个主题，把图表设计从"能画出来"到"画得让人一看就懂"之间的那层窗户纸捅破。这篇内容适合几类人看：一是经常需要画架构图、流程图、时序图的技术同学；二是要做方案汇报、需要把复杂逻辑可视化的产品和管理岗；三是做知识整理、笔记输出的内容创作者。不管你用的是哪款工具，下面这些设计原则和实操方法都是通用的。我会尽量把每个决策背后的"为什么"讲清楚，而不是只丢一堆步骤让你照抄。2. 图表设计的第一性问题：图是给谁看的2.1 先定读者，再定画法很多人画图的第一步是打开工具、拖一个方框出来，这是典型的"工具先行"。正确的顺序应该是：先想清楚这张图给谁看、在什么场景下看、看完要做什么决策。这三个问题的答案，直接决定了图的复杂度、配色、标注密度甚至尺寸。举个具体的对比。同样是描述一个系统的数据流，如果读者是同组工程师，他们熟悉业务背景，你可以用简写、可以省略中间步骤、可以直接上专业术语，图可以画得紧凑；但如果读者是跨部门的产品或管理层，他们不关心具体用了什么中间件，只关心"数据从哪来、经过什么处理、最终产出什么价值"，这时候你就得把技术细节折叠掉，用业务语言重新标注。我自己的习惯是，在动手之前先在纸上写一句话："这张图要让[谁]在[什么场景]下看懂[什么结论]"。这句话写不出来，说明你还没想清楚，这时候画出来的图大概率要返工。2.2 一张图只讲一件事新手最容易犯的错，是想用一张图把所有信息都塞进去。结果就是图越来越大、箭头越来越密、颜色越来越多，最后变成一张"什么都说了但什么都没说清"的蜘蛛网。我的经验是：一张图只承载一个核心信息。如果发现一张图里有两个并列的重点，那就拆成两张。比如"系统整体架构"和"某次请求的调用链路"就是两件事，前者讲静态结构，后者讲动态过程，硬画在一起只会互相干扰。这里有个判断标准：如果你需要用"另外""同时""顺便说一下"这类词来介绍图里的某部分内容，那部分内容就该独立成图。图不是文档，它没有"顺便"的空间，读者的视线是跳跃的，任何非主线信息都是干扰。2.3 信息层级比美观更重要我见过太多"好看但难读"的图——配色很高级、圆角很精致、阴影很柔和，但你就是找不到重点在哪。问题出在没有建立信息层级。信息层级说白了就是：哪些是主角，哪些是配角，哪些是背景。在视觉上，主角应该最大、最醒目、位置最居中；配角次之；背景最弱，甚至可以不画。具体到操作层面，我通常用三个维度来拉开层级：尺寸：核心模块的方框明显大于辅助模块颜色饱和度：重点用高饱和或深色，次要的用浅灰、浅蓝线条粗细：主流程的箭头粗，辅助关系的箭头细或虚线这三个维度不需要同时用满，通常用两个就足够拉开差距了。用满反而会显得花哨。3. 选工具之前，先搞清楚你要画的是哪类图3.1 四类常见图表的设计诉求完全不同"diagram"这个词太宽了，架构图、流程图、时序图、状态图，它们的设计逻辑差别很大。选错图类型，后面怎么优化都是白费。我整理了一个对照表，方便你快速定位：图类型核心表达关键元素常见误用架构图静态结构、模块关系方框、分组、连接线把调用时序也画进去流程图步骤顺序、分支判断流程节点、判断菱形、箭头分支过多导致线交叉时序图对象间的交互顺序生命线、消息箭头、激活条对象太多导致横向溢出状态图状态迁移与触发条件状态圆角框、迁移箭头、条件标注把动作和状态混为一谈这张表看着简单，但每一条"常见误用"背后都是真实的返工。比如架构图里画时序，最典型的症状就是箭头带上了"第1步、第2步"的编号，这时候图就不再是结构图，而是流程和结构的混合体，读者会困惑"这到底是静态的还是动态的"。3.2 工具选型的三个实际考量工具这块我不做具体品牌推荐，因为工具迭代太快，而且每个人的团队协作环境不同。但选型时有三个维度是通用的，你可以拿它去套任何一款工具：第一，文本化还是拖拽式。文本化工具（用代码描述图）的好处是能进版本控制、能diff、改起来快，适合工程师；拖拽式工具上手快、所见即所得，适合非技术岗。如果你的图需要频繁修改、需要和代码一起维护，优先选文本化的；如果是一次性汇报用，拖拽式更省时间。第二，布局是自动还是手动。自动布局省心，但复杂图容易乱；手动布局可控，但调整费时。我的折中做法是：结构简单的图用自动布局，结构复杂的图先自动生成再手动微调关键节点位置。第三，导出格式是否满足场景。放进文档要矢量图（SVG/PDF），放进PPT可能要PNG，嵌进网页可能要交互式。选工具前先确认它能不能导出你需要的格式，别画完了发现导不出来。提示：不要因为某个工具"流行"就选它。工具是为你服务的，先明确你的图类型、修改频率、协作方式，再去匹配工具，而不是反过来。3.3 一个被低估的准备工作：先列元素清单我现在的习惯是，画图之前先列一个"元素清单"：这张图里有哪些方框、哪些连线、哪些标注。清单列完，图的骨架就出来了，剩下的只是摆放问题。这个习惯的好处是，它强迫你在动手前把逻辑理清楚。很多时候列清单的过程中就会发现"这个模块其实不该出现在这张图里"或者"这两个模块的关系我还没想明白"。如果直接开画，这些问题会在画到一半时暴露，那时候改起来成本就高了。4. 让图表"自解释"的五个设计手法4.1 命名要具体，不要用"模块A""系统B"这是我最想强调的一点。很多图里全是"模块A""模块B""服务1""服务2"，读者看完根本不知道每个框是干什么的。方框里的文字应该是这个模块的职责描述，而不是它的代号。对比一下：差：模块A→模块B好：用户鉴权→订单处理如果名字太长放不下，可以用"主标题+副标题"的形式，主标题是简称，副标题用小字补充说明。比如主标题"鉴权服务"，副标题"校验token与权限"。这样即使读者不了解你的系统，也能大致猜到每个框的作用。4.2 箭头要有语义，不能只是"连着"箭头是图表里信息密度最高的元素，但也是最容易被滥用的。我见过很多图，箭头就是单纯表示"这两个东西有关系"，但到底是什么关系，全靠讲解。正确的做法是给箭头赋予明确的语义，常见的有几类：数据流：A把数据传给B，箭头方向就是数据方向依赖：A依赖B，通常用虚线或特定样式区分调用：A调用B的接口，可以标注调用的方法或协议继承/实现：用空心三角箭头，这是UML的通用约定如果一张图里同时存在多种关系，一定要用不同的线型或颜色区分，并在图例里说明。图例不是可有可无的装饰，它是读者理解图的钥匙。4.3 用分组框表达"边界"当图里的元素超过七八个，读者就开始迷失了。这时候分组是救命的。分组框（通常是一个虚线大框）能告诉读者"这几个东西是一伙的"，它们可能属于同一个服务、同一个层、同一个团队。分组的边界怎么定？我通常按这几个维度：按部署单元分（同一个服务里的模块放一起）、按职责层分（接入层、逻辑层、存储层）、按数据流向分（输入侧、处理侧、输出侧）。选一个维度贯穿始终，不要混用。4.4 关键路径加粗，次要路径弱化一张图里，真正的主流程往往只占少数，但很多图把所有线画得一样粗，读者分不清主次。把主流程的箭头加粗、颜色加深，把异常分支、补偿逻辑、监控链路用细线或浅色处理，读者的视线自然会被引导到主线上。这个手法在时序图里尤其有效。正常流程用实线粗箭头，异常或重试用虚线，读者一眼就能看出"哦，这是主路径，那些是兜底逻辑"。4.5 标注要克制，能省则省新手喜欢在图上加大量文字标注，生怕别人看不懂。但标注太多，图就变成了"带框的文章"，失去了可视化的意义。我的原则是：能在图里用视觉表达的，就不要用文字；必须用文字的，尽量短。比如"这个模块处理失败会重试三次"，与其写一行字，不如在箭头上标个"重试×3"。再比如"这两个模块是异步通信"，与其写说明，不如用虚线箭头加个"async"标签。文字是最后的手段，不是首选。5. 配色与排版：那些没人明说但很致命的细节5.1 配色不超过三种主色配色是图表设计里最容易翻车的地方。我的经验是：主色不超过三种，其余用中性灰。三种主色分别对应"重点""次重点""辅助"，中性灰用于背景、边框、非关键元素。为什么是三种？因为人眼在快速扫视时，能稳定区分的色相数量有限，超过三种就会显得杂乱，读者需要花精力去分辨"这个蓝色和那个蓝色有什么区别"，而不是关注内容本身。另外，避免用纯红和纯绿同时出现，色觉障碍人群无法区分。如果必须表达"正/负"或"通过/失败"，用蓝色和橙色替代，或者加上形状差异（比如对勾和叉号）。5.2 对齐是专业感的第一来源一张图看起来"专不专业"，很多时候不取决于配色多高级，而取决于对齐。方框的左边缘是否在一条线上、同一层的方框高度是否一致、箭头是否水平或垂直——这些细节决定了图的整洁度。手动拖拽的时候，一定要打开工具的网格和对齐辅助线。如果工具支持，尽量用"等间距分布"功能，让同一行的方框间距一致。这些操作花不了几分钟，但效果立竿见影。5.3 留白不是浪费空间新手总想把画布填满，觉得空白就是浪费。但留白是让图"呼吸"的关键。方框之间、分组之间、图和画布边缘之间，都要留出足够的间距。间距太小，图会显得拥挤压抑，读者的视线也没有休息的地方。我的经验值是：同级元素之间的间距，至少是元素高度的三分之一；分组框和内部元素之间，至少留出元素高度的二分之一。具体数值不用死记，视觉上"不挤"就行。5.4 字号要有层级，但别太多字号层级和颜色层级是一个道理，用来区分信息重要性。通常三级就够了：标题字号、正文字号、注释字号。标题最大，正文适中，注释最小。三级之外再加字号，读者反而会困惑"这个字号到底代表什么"。还有一个细节：同一层级的元素，字号必须一致。我见过有的图里，同样是模块名，有的用14号有的用12号，看起来就像没对齐一样别扭。画完之后统一检查一遍字号，这个习惯能省掉很多返工。6. 从草图到成图：我实际的工作流6.1 第一步永远是纸笔或白板不管最后用什么工具，我的第一版永远是手绘的。纸笔或白板的好处是没有工具的限制，你可以随便涂改、随便连线，专注于逻辑本身而不是"这个框怎么拖"。手绘阶段我只关心三件事：有哪些元素、它们怎么连、主流程是什么。配色、对齐、字号这些统统不管。这个阶段的目标是"逻辑正确"，不是"好看"。6.2 第二版用工具快速搭骨架手绘确认逻辑没问题后，转到工具里搭骨架。这一版也不追求美观，就是把方框和连线摆上去，确认布局合理、没有明显的线交叉。如果发现某个区域特别拥挤，回到手绘阶段重新调整布局思路。这个阶段我通常会刻意用最朴素的样式——黑白灰、直角框、细线。因为一旦开始调颜色和样式，注意力就从逻辑转移到外观上了，容易忽略结构问题。6.3 第三版才做视觉优化骨架确认后，才开始上色、调字号、加分组、优化箭头样式。这时候逻辑已经稳定了，视觉调整不会影响结构。顺序反过来——先美化再调逻辑——会导致你反复修改样式，效率极低。视觉优化我一般按这个顺序：先分组（确定边界），再配色（确定层级），再调字号（确定主次），最后微调对齐和间距。每一步只做一件事，做完检查一遍再进入下一步。6.4 最后一步：找个不了解背景的人看一眼这是我最推荐的一个习惯。图做完之后，找一个不了解这个项目的人（同事、朋友都行），让他看图，然后问他"你觉得这张图在讲什么"。如果他能说出个大概，说明图是自解释的；如果他一脸茫然，说明还有信息没表达清楚。这个"外人测试"能发现很多你自己看不见的问题，因为你太熟悉内容了，会自动脑补缺失的信息。外人的困惑点，就是你需要补充或简化的地方。7. 几个高频翻车场景与应对7.1 线交叉太多怎么办线交叉是复杂图的通病。应对方法有几个，按优先级排：第一，调整元素位置。把关联紧密的元素放近一点，交叉自然就少了。这是最有效的方法，但需要反复尝试。第二，用分组隔离。把相互之间连线多的元素放进同一个分组，分组内部的线就不会和外部交叉。第三，用连接点。如果工具支持，让连线从方框的特定边（上、下、左、右）出发，而不是从中心出发，能减少很多交叉。第四，拆图。如果以上都试过还是乱，说明信息量超了，该拆成两张图了。7.2 图太大放不进文档怎么办图太大通常有两个原因：元素太多，或者间距太大。如果是元素太多，考虑拆图或折叠次要信息；如果是间距太大，压缩间距和字号。还有一个技巧：把图旋转90度。横向的图在文档里往往受限于页宽，纵向的图受限于页高，哪个方向空间多用哪个。架构图通常横向展开，但如果文档是竖版，纵向布局可能更合适。7.3 改了需求要重画怎么办这是文本化工具的最大优势——改一行代码就能重新生成。如果你用的是拖拽式工具，建议在画的时候就保持结构清晰：同一层的元素用同样的样式、命名规范统一、分组边界明确。这样改的时候只需要动局部，不用推倒重来。另外，养成保存中间版本的习惯。有时候改着改着发现还是上一版好，没有版本记录就只能重画了。8. 关于图表设计，我踩过的最大的一个坑说了这么多方法，最后分享一个我自己的教训。早期我做图表设计，总想着"一次做到完美"，结果就是在一张图上反复打磨，配色调了又调、对齐改了又改，花了几个小时，最后发现逻辑本身就有问题，整张图推倒重来。后来我想明白了一件事：图表设计的本质是沟通，不是艺术创作。一张图好不好，不取决于它多精致，而取决于读者能不能快速准确地获取信息。配色、对齐、留白这些手法，都是为"沟通效率"服务的，不是目的本身。所以现在的我，画图时会不断问自己："这个设计决策，是让读者更容易理解，还是只是让我自己觉得好看？"如果是后者，果断砍掉。这个习惯帮我省下了大量时间，也让我的图真正变得"有用"而不是"好看"。如果你也在做图表设计相关的工作，我的建议是：先把逻辑理清楚，再用最朴素的方式画出来，最后才考虑美化。顺序对了，效率和质量都会上来。至于工具，够用就行，别在选工具上花太多时间，那是最容易本末倒置的地方。