1. 从“diagram-design”这个标题里能读出什么
第一次看到“diagram-design”这个标题，我脑子里蹦出来的不是某个具体工具，而是一类非常典型的工作场景：有人需要把脑子里那张“说不清楚但确实存在”的结构图，变成一张能放进文档、能讲给同事听、能贴在白板上讨论的图。这个标题本身没有给出任何正文、关键词和摘要，信息量几乎为零，但恰恰是这种“极简标题”，反而暴露了它背后最真实的需求——图的表达设计，而不是图本身画得多花哨。
我做了十多年项目，见过太多人把“画图”和“设计图”混为一谈。画图是把元素摆上去，设计图是让元素之间的关系自己会说话。diagram-design 这个标题，如果让我拆，它至少包含三层意思：第一层是 diagram，也就是图的结构化表达，节点、连线、层级、流向；第二层是 design，也就是视觉层面的决策，颜色、间距、对齐、字体、留白；第三层是那个不起眼的连字符，它暗示这两件事不是分开做的，而是一体化的——你在设计结构的时候就在设计视觉，你在调视觉的时候也在反过来修正结构。
这篇文章适合谁看？如果你平时要写技术方案、画架构图、做流程梳理、给非技术同事解释系统逻辑，或者你是一个需要频繁输出图表的博主、产品经理、项目负责人，那这篇内容就是给你准备的。它不依赖任何特定软件，也不假设你有设计基础，我会把 diagram-design 这件事拆成可操作的判断标准和实操步骤，让你下次打开画图工具之前，先知道自己在干什么。
提示：本文讨论的 diagram-design 是一种通用能力，不绑定任何具体商业工具，所有示例均为虚构场景，仅用于说明方法。
2. 为什么大多数人画的图“能看懂但不好用”
2.1 结构对了，但阅读路径是乱的
我见过大量这样的图：节点齐全、连线正确、逻辑也没错，但你就是得盯着看半天才能找到入口。问题出在阅读路径没有被设计。人看图是有习惯的，从左到右、从上到下、从中心向外，这些是默认的视觉动线。如果你的图把起点放在右下角，把终点放在左上角，读者的大脑就要额外做一次“反向翻译”，这个成本看似很小，但在一个几十页的文档里，每一张图都这样，累积起来就是灾难。
diagram-design 的第一条原则就是：先定阅读路径，再摆元素。具体怎么做？你可以先用纸笔画一条虚线，标出你希望读者第一眼看哪里、第二眼扫哪里、最后停在哪里。这条虚线不需要出现在最终图里，但它决定了你所有元素的排布顺序。我自己的习惯是，在画任何图之前，先写一句话：“这张图应该让读者先看到 A，然后顺着 B 走到 C，最后意识到 D 和 E 是并列的。”这句话写不出来，图就别急着画。
2.2 视觉噪音盖过了信息本身
第二个高频问题是视觉噪音。什么叫视觉噪音？所有不承载信息但占用注意力的东西都算：多余的边框、深浅不一的灰色、粗细不等的线条、五颜六色的标签、没有对齐的文本框。很多人觉得“加点颜色好看”，结果一张图里出现了七八种颜色，读者根本不知道哪种颜色代表什么含义。
我处理这个问题的办法很粗暴：先做黑白稿。把所有元素用黑白灰三色画出来，只靠形状、大小、位置和线条粗细来区分层级。如果黑白稿已经能让人看懂结构，那颜色就是锦上添花；如果黑白稿看不懂，加颜色也救不回来。这个习惯帮我省掉了大量返工时间，因为颜色一旦加上去，人就会产生“已经完成了”的错觉，反而不愿意再动结构。
2.3 层级关系被“画平”了
第三个问题更隐蔽：层级关系被画平了。比如一个系统里有主模块和子模块，有人把所有模块画成同样大小的方块，只是用连线表示从属关系。读者得顺着线一条条看，才能还原出层级。正确的做法是让视觉层级直接映射逻辑层级：主模块更大、更粗、颜色更重，子模块更小、更细、颜色更轻，或者用嵌套容器把子模块包在主模块里面。
这里有个经验值可以参考：主模块和子模块的视觉权重差至少要有 2 倍。什么叫视觉权重？就是面积、线宽、颜色深度的综合感受。如果你只是把主模块的字加粗，子模块的字不加粗，这个差距在远距离观看时几乎为零。我通常会让主模块的边框粗一倍、背景色深一档、字号大两号，三个维度同时拉开差距，这样即使图被缩小到 50%，层级依然清晰。
3. diagram-design 的核心决策清单
3.1 先问“这张图要回答什么问题”
任何一张图都应该回答一个明确的问题。这个问题不是“这个系统长什么样”，而是更具体的，比如“数据从用户输入到落库经过了哪几个环节”“三个方案在成本和复杂度上的取舍是什么”“这个流程里哪一步是瓶颈”。问题越具体，图的形态就越确定。
我习惯在画图前把这个问题写在便签上，贴在屏幕边上。画的过程中如果发现某个元素跟这个问题无关，就果断删掉。很多人舍不得删，觉得“万一读者想知道呢”，但 diagram-design 的本质是取舍，不是穷举。一张图能回答一个问题就已经合格，能回答两个问题是优秀，想回答三个以上问题，大概率一个都答不好。
3.2 选对图的“骨架类型”
图的骨架类型决定了信息组织方式。常见的骨架有几种：线性流程、树形层级、网状关系、矩阵对比、时间轴、泳道。选错骨架，后面怎么调都别扭。比如你要表达“三个方案在四个维度上的对比”，用流程图就是灾难，用矩阵表格或者雷达图才合适；你要表达“一个请求经过五个服务”，用树形图也不对，线性流程或者泳道图才对。
这里有个简单的判断方法：看你的核心信息是“顺序”“从属”“关联”还是“对比”。顺序用线性或时间轴，从属用树形或嵌套，关联用网状，对比用矩阵或并列。一张图里可以混合两种骨架，但主骨架只能有一个，否则读者会迷失。
3.3 连线的语义必须统一
连线是 diagram-design 里最容易被忽视的元素。很多人画线只关心“连上了没有”，不关心“这条线代表什么”。实际上，连线的样式应该承载语义：实线代表直接调用，虚线代表异步消息，粗线代表主路径，细线代表辅助路径，带箭头的代表方向，不带箭头的代表关联。如果一张图里实线和虚线混用但没有说明，读者就会困惑。
我的做法是，在图的角落放一个极简的图例，只列三种线型：主路径、辅助路径、异步/关联。超过三种，读者记不住；少于三种，信息表达不充分。图例不需要花哨，一行小字加三个线段示例就够了。这个细节看起来微不足道，但它能让你的图从“能看懂”变成“不用问就能看懂”。
3.4 文字标签的“三秒原则”
图里的文字标签有个三秒原则：读者在三秒内扫过一张图，应该能抓住每个节点的大致含义。这意味着标签要短、要具体、要避免行话。比如“用户认证与授权服务模块”就不如“认证服务”来得直接；“数据持久化层”就不如“数据库”来得清楚。如果确实需要详细说明，把详细说明放在图外的正文里，图里只留关键词。
我见过有人把整段需求描述塞进一个节点里，结果节点变成一个大文本框，图的结构完全被文字淹没。diagram-design 的底线是：图为主，字为辅。文字是给图做注脚的，不是反过来。
4. 从零画一张图的完整实操链路
4.1 准备阶段：纸笔比软件快
我强烈建议在打开任何画图软件之前，先用纸笔画三到五版草图。为什么？因为软件会诱导你过早关注细节——你会忍不住去调颜色、对齐像素、选字体，而这些在结构没定之前都是浪费时间。纸笔没有这些干扰，你只能画方块和线条，反而能逼自己把结构想清楚。
草图阶段只做三件事：定阅读路径、定骨架类型、定节点数量。节点数量控制在 7 到 12 个之间，这是人短期记忆的舒适区。超过 12 个，就要考虑拆成两张图，或者用分组容器把节点归类。我自己的经验是，一张图超过 15 个节点，读者的理解成本会指数级上升，不管你的视觉设计多好。
4.2 搭建阶段：先容器后节点
进入软件之后，不要急着画节点。先画容器。容器是分组用的框，它决定了图的宏观布局。比如你有三个子系统，就先画三个大框，把画布分成三块，然后再往每块里填节点。这个顺序的好处是，你从一开始就在处理层级关系，而不是画完一堆节点再想办法分组。
容器的命名也有讲究。容器名应该是一个名词短语，代表这一组节点的共同属性，比如“前端层”“数据层”“外部依赖”。不要用“其他”“杂项”这种名字，那说明你的分组逻辑还没想清楚。如果某个节点放不进任何容器，要么给它单独建一个容器，要么考虑它是不是根本不该出现在这张图里。
4.3 连线阶段：主路径优先
节点摆好之后，先连主路径。主路径就是那张图要回答的核心问题所对应的那条线。比如你的问题是“请求怎么走”，那主路径就是从入口到出口的那条链路。主路径的线要最粗、最直、最少拐弯。其他辅助线可以细一些、弯一些、颜色浅一些。
这里有个实操技巧：主路径尽量走直线，辅助线走曲线。直线在视觉上天然比曲线更“重”，不需要额外加粗就能突出。如果主路径必须拐弯，拐弯次数不要超过两次，每次拐弯的角度尽量接近 90 度或 45 度，这样看起来整洁。辅助线可以用贝塞尔曲线，绕开主路径，形成视觉上的“背景层”。
4.4 标注阶段：最后加文字和图例
文字标注放在最后做。因为文字会改变节点的大小，如果先写文字再调布局，你会陷入“改一个字就要挪一次位置”的死循环。正确的顺序是：结构定稿、连线定稿、视觉层级定稿，最后统一填文字。填文字的时候，先填节点名，再填连线标签，最后加图例和标题。
标题的位置也有讲究。我习惯把标题放在左上角，字号比节点文字大两号，不加粗，用中等灰色。为什么不用黑色加粗？因为标题是“说明”，不是“内容”，它不应该跟图里的核心信息抢注意力。读者扫一眼知道这张图叫什么就行，不需要盯着标题看。
5. 视觉设计里那些“不说但很重要”的参数
5.1 间距：8 的倍数原则
间距是 diagram-design 里最容易被忽略、但对可读性影响最大的因素。我的经验是，所有间距都取 8 的倍数：节点内边距 8 或 16，节点之间间距 24 或 32，容器内边距 16 或 24，容器之间间距 40 或 48。为什么是 8？因为大多数屏幕和导出尺寸都能被 8 整除，这样在缩放时不会出现半像素模糊。更重要的是，8 的倍数形成一个节奏，让整张图的疏密关系看起来是“设计过的”，而不是随手摆的。
如果你觉得 8 太小，可以用 8 的倍数往上加：16、24、32、40、48、64。关键是同一层级的间距必须一致。所有同级节点之间的间距一样，所有同级容器之间的间距一样。一旦出现“这个间距 24、那个间距 28”的情况，图就会显得脏，虽然读者说不出哪里不对，但就是觉得不舒服。
5.2 字号：三级足够
一张图里的字号不要超过三级。我通常用：节点标题 14px，节点说明 12px，图例和标注 10px。如果导出后要打印，整体放大 1.5 倍。字号差距要明显，14 和 12 的差距在屏幕上几乎看不出来，所以要么用 16 和 12，要么用 14 和 10。我的建议是节点标题和说明至少差 4px，这样即使图被缩小，层级依然可辨。
字体选择上，中文用系统默认的无衬线字体就行，不要用宋体或楷体，那些字体在小字号下笔画会糊。英文和数字可以用同一套无衬线字体，保持一致性。如果图里中英文混排，确保中英文的基线对齐，否则会看起来高低不平。
5.3 颜色：最多三档灰加一个强调色
颜色是最容易滥用的元素。我的原则是：整张图最多三档灰色加一个强调色。三档灰分别用于背景、容器、节点，强调色只用于主路径或关键节点。强调色的面积不要超过整张图的 10%，否则就不叫强调色了，叫主色。
选强调色的时候，避开纯红和纯绿，这两个颜色在色弱人群眼里容易混淆。蓝色、橙色、紫色是比较安全的选择。如果你不确定，就把图导出成灰度模式看一眼，如果灰度模式下层级依然清晰，那颜色就没问题；如果灰度模式下所有东西糊成一团，说明你的层级过度依赖颜色，需要回去调结构和线宽。
5.4 对齐：看不见的网格线
对齐是专业和业余的分水岭。业余的图里，节点边缘总是差几个像素，看起来就是“没对齐”。专业的图里，所有节点都落在一条看不见的网格线上。实操上，你可以打开软件的网格功能，把网格间距设为 8px，然后让所有节点的边缘都吸附到网格上。如果软件没有网格吸附，就手动对齐：选中所有同级节点，用“左对齐”或“顶对齐”功能统一位置。
对齐不只是节点对齐，还包括文字对齐。节点内的文字应该左对齐或居中对齐，同一张图里保持一致。连线标签应该放在线的中点或靠近目标节点的一端，不要随意漂在空白处。这些细节单独看都很小，但叠加起来就是“这张图很专业”和“这张图能用”的区别。
6. 不同场景下的 diagram-design 变体
6.1 技术架构图：分层与边界
技术架构图的核心是分层和边界。分层就是把系统切成前端、网关、服务、数据等层，每层用一个大容器表示，层与层之间用主路径连接。边界就是哪些模块属于同一个服务、哪些模块跨服务调用，用容器嵌套和连线样式来区分。架构图最忌讳把所有模块画成一排，那样既看不出层级，也看不出边界。
我画架构图时，会先画三条水平线，把画布分成四层，然后从最上层开始往下填。每层内部的模块横向排列，层与层之间的连线垂直走。如果某个模块跨层，就用一条垂直的粗线穿过所有层，表示它是贯穿性的组件。这样画出来的架构图，读者从上往下扫一遍就能理解系统的宏观结构。
6.2 流程图：泳道与决策点
流程图的核心是泳道和决策点。泳道用来区分不同的角色或系统，每个泳道是一个横向或纵向的条带，条带内的节点按时间顺序排列。决策点用菱形表示，每个决策点引出的分支要标注条件，条件文字放在连线旁边，不要放在菱形里面。流程图的阅读路径是“之”字形的，所以泳道的排列顺序要跟实际流程的参与方顺序一致。
一个常见的错误是把太多细节塞进流程图。流程图应该只保留关键决策和关键动作，具体的参数、异常处理、日志记录这些放在正文里说。如果一张流程图超过 20 个节点，就说明你试图用一张图讲完整个系统，这时候应该拆成“主流程”和“异常流程”两张图。
6.3 对比图：矩阵与雷达
对比图的核心是维度对齐。如果你要对比三个方案在四个维度上的表现，最清晰的形式是矩阵表格：行是方案，列是维度，单元格里放评分或简短描述。如果维度是连续的、可以量化的，雷达图也可以，但雷达图的面积容易误导读者，所以要在图例里说明每个轴的量纲。
对比图最忌讳的是“每个方案画一张小图然后并排”。这样读者需要自己在脑子里做对比，认知成本很高。正确的做法是把所有方案放在同一个坐标系或同一个表格里，让差异直接可见。如果方案太多放不下，就分组对比，先比大类，再比小类。
6.4 时间轴图：等距与不等距
时间轴图的核心是时间刻度的处理。如果事件之间的时间间隔是均匀的，就用等距刻度；如果间隔不均匀，要么用不等距刻度（但这样视觉上会失真），要么用等距刻度加标注说明实际间隔。我倾向于用等距刻度，然后在每个事件旁边标注实际时间，这样视觉上整洁，信息也不丢失。
时间轴的方向可以是水平的，也可以是垂直的。水平时间轴适合事件较少的场景，垂直时间轴适合事件较多、需要滚动查看的场景。如果时间轴上的事件有分支，比如一个项目有多个并行的工作流，就用泳道加时间轴的组合，每个泳道一条时间线，泳道之间用连线表示依赖关系。
7. 我踩过的那些坑和后来怎么改的
7.1 追求“好看”导致结构变形
早期我画图有个毛病：为了让图看起来对称、好看，会强行调整节点的位置，结果把逻辑关系搞乱了。比如本来 A 应该指向 B，但为了对称，我把 B 放到了 A 的左边，连线就变成了从右往左，阅读路径完全反了。后来我定了一条规矩：结构正确优先于视觉对称。如果结构要求不对称，那就接受不对称，用留白和分组来平衡视觉，而不是挪动节点。
7.2 图例写得太复杂没人看
我曾经在一张图里放了六种线型和四种颜色，图例写了满满一屏。结果同事跟我说：“你这图例比图还难懂。”后来我砍到三种线型、一个强调色，图例缩成一行，反而没人再问“这条线什么意思”了。这件事让我明白，图例的目的是降低理解成本，不是展示你的设计能力。图例越简单，图越容易被传播。
7.3 导出格式选错导致文字糊
这个坑很具体：早期我用 PNG 导出，分辨率设得不够高，图放进文档里一放大，文字就糊了。后来我改用 SVG 导出，矢量格式在任何缩放下都清晰。如果必须用位图，分辨率至少设成 300dpi，并且导出前把画布尺寸放大两倍。还有一个细节：导出 SVG 时，把文字转成路径可以避免字体缺失，但转成路径后文字就不能再编辑了，所以保留一份可编辑的源文件很重要。
7.4 一张图想讲太多事
最惨的一次，我试图用一张图同时讲清楚系统架构、数据流向和部署拓扑，结果画了三天，画出来一张谁都不愿意看的“蜘蛛网”。后来我拆成三张图：架构图讲模块关系，数据流图讲数据走向，部署图讲物理分布。三张图加起来还没原来一张复杂，但每张都能独立看懂。这件事教会我：图的边界就是问题的边界，一个问题一张图，不要贪心。
8. 让 diagram-design 变成肌肉记忆的日常练习
8.1 拆解别人的图
我有个习惯，看到任何一张图，不管是文档里的、PPT 里的还是白板上的，都会在心里拆一遍：它的阅读路径是什么？骨架类型是什么？主路径是哪条？用了几个层级？颜色和线宽怎么分配的？这个练习不需要额外时间，通勤路上看一篇文章就能做。拆得多了，你自己画图的时候，这些判断会变成条件反射，不需要刻意想。
8.2 限制练习：只用黑白灰
每周挑一张图，强迫自己只用黑白灰三色画完。没有颜色可用的时候，你会被迫在形状、大小、位置、线宽上做文章，这些恰恰是 diagram-design 的基本功。我坚持这个练习大概半年之后，发现自己即使不加颜色，图的可读性也比以前加满颜色的图要好。颜色变成了可选项，而不是拐杖。
8.3 让别人“盲测”你的图
画完一张图，找一个不了解背景的同事，给他 30 秒看这张图，然后让他复述图的内容。如果他能说出 70% 以上的核心信息，说明图合格了；如果他说“看不懂”或者“信息太多”，那就回去改。这个测试比任何设计原则都直接，因为 diagram-design 的最终标准不是“好看”，而是“能被正确理解”。
8.4 建立自己的组件库
当你画了足够多的图之后，会发现很多元素是重复的：标准节点、标准容器、标准连线、标准图例。把这些整理成一个组件库，下次画图直接拖出来用。组件库的好处不只是省时间，更重要的是保证一致性——同一套组件画出来的图，风格天然统一，不会出现“这张图圆角、那张图直角”的尴尬。我自己的组件库大概有 20 个元素，覆盖了 90% 的日常场景。
注意：组件库要定期清理，把半年没用过的元素删掉，否则库会越来越臃肿，拖出来的时候反而要花时间找。
9. 关于工具选择的一点个人看法
工具这件事，我的态度是：工具服务于习惯，不是习惯迁就工具。如果你习惯纸笔草图，那就用纸笔，软件只用来做最终输出；如果你习惯在软件里直接画，那就选一个网格吸附和组件库做得好的工具。关键不是工具本身，而是你有没有一套稳定的 diagram-design 流程。
我见过有人为了选工具纠结一个月，结果一张图都没画。也见过有人用最基础的画图工具，画出来的图比谁都清楚。工具的上限是效率，不是质量。质量取决于你的结构思维和视觉判断，这两样东西跟工具无关，跟练习有关。
如果你现在还没有固定工具，我的建议是：先用手边能用的，画够 20 张图，再决定要不要换。20 张图之后，你自然知道自己需要什么功能，那时候再选工具，就不会被营销话术带偏。选工具的标准很简单：能不能快速对齐、能不能保存组件、能不能导出矢量格式。这三个满足，就够用了。
10. 最后分享几个我压箱底的小技巧
第一个技巧：画图前先写图注。图注就是图下面那行说明文字，比如“图 3：请求从入口到落库的完整链路”。先写图注，等于先定义这张图的边界和核心信息，画的时候不容易跑偏。如果图注写不出来，说明你还没想清楚这张图要干什么。
第二个技巧：用灰度模式检查层级。画完图之后，把显示器调成灰度模式，或者导出成灰度图看一眼。如果灰度下层级依然清晰，说明你的设计是稳的；如果灰度下糊成一团，说明你过度依赖颜色，需要回去调线宽和大小。
第三个技巧：给图留 20% 的空白。不要把画布填满，四周留出至少 20% 的空白。空白不是浪费，它给读者的眼睛提供休息区，也让图看起来更从容。我见过太多图把元素挤到边缘，看起来就像早高峰的地铁，信息密度再高也让人不想看。
第四个技巧：版本命名要带日期和用途。比如“架构图-20240512-对外分享版”。这样你回头找图的时候，一眼就知道哪个是最新的、哪个是给谁看的。我吃过亏，把内部详细版发给了外部合作方，虽然内容本身没问题，但详细程度不合适。从那以后，所有导出文件都带用途标签，再也没出过错。
这些技巧没有一条是“必须”，但每一条都是我实际踩坑之后留下来的。diagram-design 这件事，说到底就是用结构思维做减法，用视觉手段做加法，减到不能再减，加到刚好够用。你画得越多，越会发现，最好的图不是最漂亮的图，而是那张让读者看完之后说“哦，原来如此”的图。
