1. 从"diagram-design"这个标题里能读出什么

第一次看到"diagram-design"这个标题，我脑子里蹦出来的第一个念头是：这大概率不是一个单纯的"画图工具"项目，而是一套关于"如何把复杂信息用图形语言表达清楚"的方法论或者工具集。为什么这么说？因为如果只是画流程图，标题通常会写成"flowchart-tool"或者"diagram-maker"；而"design"这个词的出现，意味着它关注的不只是"画出来"，而是"设计出来"——这两者之间的差距，做过技术方案汇报、写过架构文档、画过业务流程图的人都懂。

画出来，是把脑子里的东西搬到屏幕上；设计出来，是让看图的人能在三秒内抓住重点、理解关系、做出判断。前者是操作技能，后者是信息设计能力。这个标题的核心价值，恰恰在于它指向的是后者。

我见过太多团队在"画图"这件事上翻车的案例。某公司的技术方案评审会上，一位工程师花了四十分钟讲他的系统架构，PPT上密密麻麻画了三十多个方框、上百条连线，颜色用了七八种，箭头方向来回穿插。讲完之后，会议室里一片沉默，然后有人问了一句："所以数据到底是从哪流到哪的？"这就是典型的"画了但没设计"——信息都在图上，但没有人能读出来。

"diagram-design"这个标题所指向的，就是解决这类问题的能力。它适合所有需要跟"图"打交道的人：写技术文档的工程师、做方案汇报的产品经理、整理业务流程的运营人员、画论文插图的科研工作者，甚至做PPT汇报的职场人。不管你用什么工具——Visio、Draw.io、Figma、Excalidraw、Mermaid、PlantUML——底层的信息设计逻辑是相通的。

接下来我会从信息架构、视觉层次、工具选型、实操流程、常见坑这几个维度，把"diagram-design"这件事拆开讲透。不是泛泛而谈"要画得好看"，而是给出可以直接抄作业的判断标准和操作步骤。

2. 图的信息架构：先想清楚"谁看、看什么、看完干什么"

2.1 图的本质是信息压缩，不是信息搬运

很多人画图的时候，习惯把脑子里所有的信息都倒到画布上，觉得"画得越全越专业"。这是一个根深蒂固的误解。图的本质是信息压缩——它把线性的、冗长的文字描述，压缩成二维空间中的位置关系和连接关系，让读者用视觉并行处理的方式快速理解。

举个例子。一段文字描述："用户在前端提交订单，前端调用订单服务，订单服务先查库存服务确认库存，库存充足则调用支付服务，支付成功后通知物流服务，同时更新订单状态。"这段话大概80个字，读起来需要十几秒。但如果画成图：左边一个"用户"，箭头指向"订单服务"，订单服务分出两条线，一条到"库存服务"，一条到"支付服务"，支付服务再指向"物流服务"。读者扫一眼，两秒钟就能理解整个流程。

这就是信息压缩的价值。但压缩的前提是"有损"——你必须舍弃掉那些不影响核心理解的细节。比如"订单服务用的是Spring Boot还是Go"、"库存服务的数据库是MySQL还是Redis"，这些在流程图中完全不重要，放上去只会干扰阅读。

所以画图的第一步，不是打开工具，而是问自己：这张图要回答的核心问题是什么？是"数据怎么流转"？是"模块怎么依赖"？是"状态怎么变化"？还是"时间线上谁先谁后"？核心问题决定了图的类型，也决定了哪些信息该保留、哪些该舍弃。

2.2 三种最常见的图类型及其适用场景

在实际工作中，90%的技术图可以归为三类：流程图、架构图、时序图。每一类都有它最适合回答的问题，选错了类型，信息设计就失败了一半。

流程图（Flowchart）回答的是"步骤和分支"的问题。它适合描述业务流程、算法逻辑、审批链路。核心元素是"节点"和"判断分支"。画流程图最容易犯的错误是把"谁来做"和"做什么"混在一起。我的建议是：如果一张流程图里出现了超过三个角色（比如用户、前端、后端、数据库），就应该考虑拆成多张图，或者改用泳道图（Swimlane）来区分角色。

架构图（Architecture Diagram）回答的是"模块和依赖"的问题。它适合描述系统组成、服务调用关系、部署拓扑。核心元素是"模块"和"连接线"。架构图最大的坑是"层次不清"——把数据库、缓存、消息队列、业务服务、网关全画在一个平面上，读者根本分不清哪些是同一层的东西。正确的做法是用分组框（Group/Container）把同一层级的模块框在一起，用不同的边框样式区分"内部服务"和"外部依赖"。

时序图（Sequence Diagram）回答的是"时间线上谁先谁后"的问题。它适合描述接口调用链、协议交互、事件顺序。核心元素是"参与者"和"消息箭头"。时序图的价值在于它能清晰表达"同步调用"和"异步消息"的区别——实线箭头通常表示同步请求，虚线箭头表示异步返回或事件通知。很多人画时序图时把所有箭头都画成实线，导致读者分不清哪些调用是阻塞的、哪些是非阻塞的。

2.3 一张图只讲一件事

这是我在实际工作中反复验证过的一条铁律：一张图只讲一件事。如果你发现一张图里既要表达业务流程、又要表达系统架构、还要表达数据流向，那这张图一定会失败。

原因很简单：人的工作记忆容量有限。认知心理学里有个经典结论，人一次只能处理大约4到7个信息组块。当一张图里同时存在多种信息维度时，读者的注意力会被分散，最终什么都记不住。

我自己的做法是：如果一个复杂系统需要多张图来表达，我会先画一张"总览图"，只画最顶层的三到五个模块和它们之间的关系，然后针对每个模块再画"详细图"。总览图的作用是给读者一个"地图"，详细图的作用是让读者深入某个区域。这就像地图软件——你先看到城市全貌，再放大到某条街道。

提示：如果你画完一张图之后，发现自己需要用一段话去解释"这张图里其实有三部分内容"，那说明这张图应该拆成三张。

3. 视觉层次：让读者的眼睛知道先看哪里

3.1 视觉权重的分配逻辑

图的信息架构决定了"画什么"，视觉层次决定了"读者先看到什么"。这两件事必须配合。一张信息架构正确但视觉层次混乱的图，读者依然读得很累。

视觉权重的分配有一个基本原则：越重要的信息，视觉权重越高。视觉权重由几个因素决定：大小、颜色对比度、位置、粗细。一个大的、深色的、位于画布中央的方框，视觉权重远高于一个小的、浅色的、位于角落的方框。

在实际操作中，我通常会把图中的元素分为三个权重层级：

• 一级元素：图的核心主题，比如"订单服务"这个核心模块。用最大的字号、最深的填充色、最粗的边框。
• 二级元素：与核心主题直接交互的模块，比如"库存服务"、"支付服务"。用中等字号、中等填充色。
• 三级元素：辅助说明、外部依赖、注释。用最小的字号、最浅的填充色，甚至可以只用轮廓不加填充。

这样分层的效果是：读者第一眼看到核心，第二眼看到直接关系，第三眼才去看细节。阅读路径是被设计好的，而不是随机扫视。

3.2 颜色的使用纪律

颜色是视觉设计里最容易被滥用的元素。我见过太多图，用了十几种颜色，每个模块一个色，结果读者根本不知道颜色代表什么。

颜色的使用应该遵循"少即是多"的原则。一张图里，颜色的种类最好不要超过四种（不包括黑白灰）。而且每一种颜色都应该有明确的语义：

• 蓝色系：通常表示"主要流程"或"核心模块"
• 绿色系：通常表示"成功路径"或"正常状态"
• 橙色/黄色系：通常表示"警告"或"需要注意的分支"
• 红色系：通常表示"错误"或"异常路径"
• 灰色系：通常表示"外部依赖"或"非核心内容"

这个语义体系一旦确定，就要在全图甚至全套图中保持一致。不能这张图里蓝色表示核心模块，那张图里蓝色又表示外部依赖。一致性是降低读者认知成本的关键。

还有一个实操细节：如果你用的是深色填充，文字一定要用白色或浅色；如果用浅色填充，文字用深色。我见过有人在深蓝色填充的方框里放深灰色文字，对比度极低，读者根本看不清。这不是审美问题，是可用性问题。

3.3 对齐与间距的隐形力量

对齐和间距是视觉设计中"看不见但感受得到"的元素。一张图如果对齐混乱、间距不均，读者会觉得"哪里不对"但说不出来；如果对齐整齐、间距均匀，读者会觉得"看起来很舒服"但同样说不出来。

对齐的核心原则是：同一层级的元素，边缘必须对齐。比如三个并列的模块，它们的顶部边缘应该在同一条水平线上，宽度应该一致，之间的间距应该相等。这听起来是废话，但实际画图时，很多人是用鼠标拖拽来放置元素的，很难做到精确对齐。

我的做法是：先用网格（Grid）功能把画布分成均匀的格子，然后把元素吸附到网格上。Draw.io、Figma、Excalidraw都支持网格吸附。如果工具不支持，那就手动设置元素的坐标值，确保对齐。

间距的原则是：相关元素间距小，不相关元素间距大。这利用了格式塔心理学里的"接近性原则"——人会自动把距离近的元素归为一组。所以如果你想让读者知道"这三个模块是一伙的"，就把它们放近一点，和别的模块拉开距离。

注意：对齐和间距不需要做到像素级完美，但必须做到"肉眼看起来整齐"。如果一张图需要放大到200%才能看出对齐问题，那在实际阅读场景中就不是问题。

4. 工具选型：不同场景下用什么画图

4.1 代码驱动 vs 手动拖拽

画图工具大致可以分为两类：代码驱动型和手动拖拽型。这两类没有绝对的好坏，关键看场景。

代码驱动型工具（Mermaid、PlantUML、Graphviz）的核心优势是"可版本控制"。图的定义是一段文本代码，可以放在Git仓库里，可以diff，可以code review。当系统架构发生变化时，你只需要改几行代码，图就自动更新了。这对于需要频繁更新的技术文档来说，价值巨大。

但代码驱动型工具的劣势也很明显：布局不可控。Mermaid的自动布局算法有时候会把图排得很难看，你很难精确控制某个节点放在哪里。而且代码驱动型工具对"视觉设计"的支持有限，颜色、字体、间距的调整空间不大。

手动拖拽型工具（Draw.io、Figma、Excalidraw、Visio）的核心优势是"布局完全可控"。你可以把任何一个元素放在画布上的任何位置，可以精确调整颜色、字体、间距、对齐。适合做最终交付给客户或领导的"精修图"。

劣势是"不可版本控制"——图是一个二进制文件或者复杂的JSON，很难diff，多人协作时容易冲突。

我的实际做法是：用代码驱动工具做草稿和迭代，用手动拖拽工具做最终交付。具体来说，先用Mermaid快速把逻辑关系画出来，确认信息架构没问题；然后用Draw.io或Figma照着草稿精修视觉，调整布局和配色。这样既保证了逻辑的准确性，又保证了视觉的专业度。

4.2 在线工具与本地工具的取舍

在线工具（Draw.io网页版、Excalidraw、Figma）的好处是跨平台、免安装、协作方便。你发一个链接给同事，对方打开就能看、就能改。对于分布式团队来说，这是刚需。

但在线工具也有风险：网络不稳定时无法使用，服务商停止服务时数据可能丢失，敏感信息放在第三方平台上有合规风险。所以我的建议是：非敏感内容用在线工具，敏感内容用本地工具。Draw.io有桌面版，Excalidraw可以自部署，Figma有桌面客户端，这些都能在一定程度上规避在线工具的风险。

还有一个实操细节：不管你用什么工具，导出格式一定要选对。给技术文档用，导出SVG（矢量图，放大不糊）；给PPT用，导出PNG（位图，兼容性好）；给打印用，导出PDF（排版稳定）。我见过有人把截图直接贴到文档里，放大后模糊一片，非常不专业。

4.3 那些"看起来很美"但实际不好用的工具

市面上有一些画图工具，宣传得很厉害，但实际用起来问题很多。比如某些AI自动生成图表的工具，你输入一段文字，它自动生成一张图。听起来很美好，但实际生成的图往往逻辑混乱、布局诡异，你需要花大量时间调整，还不如自己从头画。

还有一些"模板库"极其丰富的工具，里面有几千个预设模板。但模板的问题是：它们的设计逻辑是通用的，不一定适合你的具体场景。你硬套模板，结果就是图看起来"很正式"但信息表达不清楚。

我的经验是：工具的选择应该服务于信息设计，而不是反过来。先想清楚你要表达什么，再选最顺手的工具。不要因为某个工具"功能多"就去用它，功能多往往意味着学习成本高、操作复杂。

5. 从零画一张图的完整实操流程

5.1 第一步：用纸笔或白板做逻辑草稿

这一步很多人会跳过，直接打开工具开始画。但我的经验是：在纸上画草稿的时间，能节省三倍的在工具里调整布局的时间。

纸笔草稿的目的不是画得好看，而是把逻辑关系理清楚。你只需要画方框和箭头，不需要考虑颜色、字体、对齐。重点是：哪些模块存在？它们之间怎么连接？有没有遗漏的分支？

我通常会用一张A4纸，横过来，先画核心模块在中间，然后往外扩展。如果画到一半发现纸不够用了，说明这张图的信息量太大了，需要拆分。

草稿阶段还有一个好处：你可以快速尝试不同的布局方案。比如核心模块放中间还是放左边？流程是自上而下还是从左到右？在纸上改这些只需要几秒钟，在工具里改可能需要几分钟。

5.2 第二步：确定图的阅读方向

图的阅读方向决定了读者的视线路径。最常见的两种方向是"自上而下"和"从左到右"。

自上而下的布局适合"层级关系"明显的图，比如组织架构图、模块分层图。读者从顶部开始，逐层往下看，符合"从抽象到具体"的认知习惯。

从左到右的布局适合"时间顺序"或"流程顺序"明显的图，比如时序图、业务流程图。读者从左边开始，向右推进，符合"从开始到结束"的认知习惯。

选定方向之后，全图的所有元素都应该遵循这个方向。不能一部分自上而下、一部分从左到右，那样读者的视线会来回跳跃，非常累。

5.3 第三步：先放核心元素，再放辅助元素

在工具里画图时，不要从左上角开始一个一个往右画。正确的做法是：先把核心元素放在画布中央，然后围绕核心元素放置辅助元素。

为什么？因为核心元素的位置决定了整张图的视觉重心。如果核心元素偏在角落，整张图会看起来不平衡。先把核心放在中央，然后根据连接关系往四周扩展，这样布局最自然。

放置元素时，先用统一的尺寸和样式。比如所有模块都用同样大小的矩形，所有文字都用同样的字号。等所有元素都放好之后，再根据视觉层次调整大小和样式。这样能避免"一边画一边调样式"导致的不一致。

5.4 第四步：连线的路由与避让

连线是图里最容易出问题的部分。连线画得好，图看起来清爽；画得不好，图看起来像一团乱麻。

连线的核心原则是：尽量走直线，尽量少交叉，尽量不穿过元素。

如果两个元素之间必须连线，优先走直线。如果直线会穿过其他元素，走折线（先横后竖或先竖后横）。如果折线也会穿过，那就调整元素的位置，给连线留出通道。

连线的交叉是不可避免的，但可以减少。一个实用的技巧是：把连接关系多的元素放在一起，连接关系少的元素放在外围。这样连线自然就少了交叉。

还有一个细节：箭头的方向要明确。如果是双向关系，用双向箭头；如果是单向依赖，用单向箭头。不要用没有箭头的线来表示关系，读者会困惑"到底是谁依赖谁"。

5.5 第五步：标注与图例

图例（Legend）是很多图缺少的部分。如果图里用了不同的颜色、线型、形状来表示不同的含义，就必须加图例。否则读者只能猜。

图例的位置通常在图的右下角或左下角，不要放在顶部，因为顶部通常是标题区。图例的样式要和图中元素一致——如果图中模块是圆角矩形，图例里也用圆角矩形。

标注（Annotation）是对图中某个元素的补充说明。比如某个模块旁边加一行小字"仅在生产环境启用"。标注的字号要比正文小，颜色要比正文浅，避免喧宾夺主。

提示：如果一张图需要大量标注才能看懂，说明图本身的信息设计有问题。标注应该是锦上添花，不是雪中送炭。

6. 那些年我踩过的画图坑

6.1 坑一：追求"大而全"导致图不可读

我刚工作的时候，画过一张"系统全貌图"，把公司所有服务、所有数据库、所有中间件都画在一张图上。结果那张图有A3纸那么大，打印出来字小得看不清，在屏幕上需要不断缩放才能看清细节。

后来我学乖了：图的尺寸应该控制在"一屏能看完"的范围内。如果信息量太大，就拆图。拆图的原则是按"关注点"拆——关注业务流程的看流程图，关注系统结构的看架构图，关注接口交互的看时序图。

6.2 坑二：颜色太多导致语义混乱

有一段时间我特别喜欢用颜色来区分模块，一张图用了十几种颜色。结果同事看完之后问我："蓝色和青色有什么区别？"我自己都答不上来。

颜色的语义必须明确且一致。如果你不能用一句话说清楚"这个颜色代表什么"，那就不要用这个颜色。我的建议是：一张图最多用四种颜色，每种颜色都有明确的语义。

6.3 坑三：忽略字体和字号的可读性

字体和字号是图里最容易被忽略的元素。很多人画图时用默认字体，导出之后发现字太小、太细，根本看不清。

我的经验是：图里的正文字号不要小于12px，标题字号不要小于16px。如果是给PPT用的图，字号还要再大一些，因为投影仪会缩小视觉效果。字体选择上，中文用思源黑体或苹方，英文用Inter或Roboto，这些字体在屏幕上显示清晰，不会糊。

6.4 坑四：不检查导出效果

画完图直接导出，不检查导出效果，是另一个常见坑。有时候在工具里看着好好的图，导出成PNG之后发现某些元素被裁掉了，或者颜色变了，或者文字换行了。

我的习惯是：导出之后一定要打开文件检查一遍。检查内容包括：所有元素是否完整、文字是否清晰、颜色是否一致、尺寸是否合适。如果是给文档用的图，还要检查在文档里的显示效果。

6.5 坑五：不维护图的更新

图画完之后就不管了，系统改了图没改，这是最致命的坑。一张过时的图比没有图更糟糕，因为它会误导读者。

我的做法是：把图当成代码来维护。如果图是代码驱动型工具画的，就放在代码仓库里，和代码一起更新。如果是手动拖拽型工具画的，就在图旁边标注"最后更新时间"和"对应系统版本"，定期检查是否需要更新。

7. 进阶技巧：让图从"能看"到"专业"

7.1 用留白制造呼吸感

新手画图喜欢把画布填满，觉得空白是浪费。但专业设计师知道，留白（White Space）是设计的一部分。留白让图有呼吸感，让读者的眼睛有休息的地方。

留白的原则是：元素之间的间距不要小于元素本身尺寸的1/4。比如一个100px宽的方框，它和旁边方框的间距不要小于25px。如果间距太小，图会显得拥挤。

7.2 用粗细和虚实表达层级

除了颜色和大小，线条的粗细和虚实也是表达层级的重要手段。粗线表示"主要关系"，细线表示"次要关系"；实线表示"直接关系"，虚线表示"间接关系"或"异步关系"。

这个技巧在架构图里特别有用。比如"同步调用"用实线，"异步消息"用虚线，"数据流向"用带箭头的粗线。读者一眼就能区分不同的关系类型。

7.3 用分组框表达边界

分组框（Group Box）是把相关元素框在一起的手段。它表达的是"这些元素属于同一个边界内"。比如"前端"、"后端"、"数据层"各用一个分组框框起来，读者就能清楚地知道哪些模块属于哪一层。

分组框的样式通常是浅色填充或无填充、虚线边框。不要用太深的颜色，否则会抢走内部元素的注意力。分组框的标题放在左上角，字号比内部元素稍大。

7.4 用图标替代文字

在合适的地方用图标替代文字，可以降低图的文字密度，提高可读性。比如用"人形图标"表示用户，用"数据库图标"表示存储，用"云图标"表示外部服务。

但图标的使用要克制。如果图里全是图标没有文字，读者需要先学习"每个图标代表什么"，反而增加了认知成本。我的建议是：图标+文字标签，图标负责快速识别，文字负责精确表达。

8. 不同场景下的画图策略

8.1 技术文档里的图

技术文档里的图，首要目标是"准确"和"可维护"。所以优先选择代码驱动型工具，把图的定义和文档放在一起，随文档一起更新。

技术文档里的图不需要太花哨，黑白灰加一两种强调色就够了。重点是逻辑清晰、标注完整。读者看技术文档是为了理解系统，不是为了欣赏设计。

8.2 方案汇报里的图

方案汇报里的图，首要目标是"有说服力"。所以优先选择手动拖拽型工具，精修视觉，让图看起来专业、可信。

汇报用的图要注意"远距离可读性"——投影仪会把图缩小，所以字号要大、对比度要高、元素要少。一张汇报图里，核心信息不要超过五个。

8.3 白板讨论里的图

白板讨论里的图，首要目标是"快速"和"可修改"。所以直接用白板或白板工具（Excalidraw、Miro），不要追求美观，追求的是快速表达和快速修改。

白板图的特点是"手绘风格"，这反而有助于营造"讨论中"的氛围，让参与者更愿意提出修改意见。如果白板图画得太正式，参与者会觉得"已经定稿了"，不敢提意见。

8.4 教学材料里的图

教学材料里的图，首要目标是"循序渐进"。所以通常需要一组图，而不是一张图。从最简化的核心概念图开始，逐步增加细节，最后展示完整图。

教学图要注意"一致性"——同一套材料里的图，配色、字体、布局风格要统一。这样读者在学习过程中不需要重新适应视觉风格，可以把全部注意力放在内容上。

9. 我个人的画图工具箱与日常习惯

说了这么多方法论，最后分享一下我自己的工具箱和日常习惯，供你参考。

我日常用得最多的三个工具是：Excalidraw（快速草稿和白板讨论）、Draw.io（正式架构图和流程图）、Mermaid（技术文档里的嵌入图）。这三个工具覆盖了我90%的画图需求。

我的日常习惯是：任何图都先画草稿，草稿确认后再精修。草稿阶段用Excalidraw，因为它的手绘风格让我不会过早陷入"美化"的陷阱。精修阶段用Draw.io，因为它的对齐和样式控制最精确。技术文档里的图用Mermaid，因为可以直接嵌入Markdown，随文档一起版本控制。

还有一个习惯是：每张图都存一个源文件。Draw.io存.drawio文件，Excalidraw存.excalidraw文件，Mermaid存.md文件。这样以后需要修改时，可以直接改源文件，而不是重新画。我见过太多人只存了导出的PNG，后来要改图时发现改不了，只能重画。

最后说一个心态上的体会：画图这件事，完成比完美重要。我见过很多人因为追求完美，一张图改了十几个版本还没定稿，最后耽误了正事。图是沟通工具，不是艺术品。只要信息表达清楚了，视觉上过得去，就可以交付。后续有需要再迭代，不要一次追求完美。