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

第一次看到 “diagram-design” 这个标题，很多人会以为它只是教你怎么画图——选个模板、拖几个框、连几条线，导出 PNG 就完事了。但真正做过技术方案、写过设计文档、给团队讲过架构的人都知道，画图这件事远没有看上去那么轻松。一张好的架构图，能让评审会上的人三分钟看懂你的思路；一张糟糕的图，讲半小时别人还在问“这个箭头到底代表什么”。diagram-design 要解决的，正是从“随手画”到“系统化设计”之间的那道鸿沟。

我做了十多年技术方案和文档工作，画过的图少说也有几千张。早期用画图工具，后来用代码生成，再后来自己维护了一套图表规范。踩过的坑包括：图例不统一导致读者误解、配色太花导致重点丢失、布局混乱导致信息层级不清、版本迭代后图没同步导致文档和实际脱节。这些问题看似琐碎，但每一个都真实地消耗过团队的时间和信任。diagram-design 的核心价值，就是把这些零散的经验固化成一套可复用的设计系统，让画图这件事从“手艺活”变成“工程活”。

这篇文章适合三类人看：第一类是需要频繁输出技术图表但没受过设计训练的工程师；第二类是需要统一团队文档视觉规范的负责人；第三类是对信息可视化感兴趣、想让自己的图“看起来更专业”的任何人。我会从设计思路、核心要素、实操流程、常见问题四个维度，把 diagram-design 这套方法拆开揉碎讲清楚。不管你现在用的是哪种画图工具，这套思路都能直接迁移过去。

2. 整体设计思路：为什么图表也需要一套“设计系统”

2.1 图表混乱的根源：缺少约束

大部分人画图的过程是这样的：打开工具，拖一个矩形，输入文字，再拖一个箭头，调整颜色，觉得不好看再换一个。整个过程没有任何预设规则，每个决定都是临时的。结果就是，画出来的图在局部看没问题，但放到整个文档体系里就显得格格不入。更麻烦的是，当团队多人协作时，每个人都有自己的“临时决定”，最终文档里的图风格五花八门，读者需要不断重新适应。

这跟早期前端开发的状态很像——没有组件库的时候，每个页面都从头写样式，最后整个产品视觉不一致。diagram-design 的思路就是给图表建立一套“组件库”和“样式指南”：颜色有固定语义、形状有固定含义、间距有固定比例、连线有固定规则。一旦这些约束建立起来，画图就从“每次都要做一百个决定”变成“在框架内做几个关键决定”。

2.2 约束不是限制，而是效率工具

有人可能会担心，搞一套规范会不会让图变得死板？我的实际经验恰恰相反。约束越清晰，创作越高效。就像写代码时有了好的框架，你不需要每次纠结目录结构怎么建、错误怎么处理，可以把精力集中在业务逻辑上。图表设计也一样，当颜色、形状、间距这些底层决策被固化后，你可以把全部注意力放在信息结构本身——哪些是核心模块、它们之间是什么关系、读者应该按什么顺序看。

diagram-design 的约束体系主要覆盖四个维度：语义色板、形状语法、空间节奏、连线规则。下面逐个拆解。

2.3 语义色板：颜色不是装饰，是信息

很多人的图表配色逻辑是“好看就行”，但专业图表里，颜色承担的是信息编码功能。diagram-design 建议把颜色分成三类：结构色、状态色、强调色。

结构色用于区分不同层级或不同子系统，通常选低饱和度的色系，比如灰蓝、灰绿、灰紫，它们不抢眼但能清晰划分区域。状态色用于表示运行状态，比如正常、警告、异常，通常用绿、黄、红这个经典组合，但要注意饱和度不能太高，否则整张图会显得刺眼。强调色用于突出当前讨论的重点模块，通常只用一个高饱和度的颜色，比如橙色或亮蓝，而且一张图里强调色出现的面积不应超过总面积的百分之十。

我自己的习惯是，在项目开始前先定好一套六色色板，三个结构色、两个状态色、一个强调色，所有图都从这六个颜色里选。这样即使画了二十张图，放在一起看也是统一的。

2.4 形状语法：每种形状都有固定含义

形状在图表里不是随便选的。diagram-design 推荐建立一套形状语法：矩形代表服务或模块，圆角矩形代表外部系统或用户角色，圆柱体代表数据存储，菱形代表判断或网关，虚线框代表边界或分组。这套语法一旦定下来，读者看到形状就能大致猜出含义，不需要每次都看图例。

这里有个细节容易被忽略：形状的圆角半径和线条粗细也需要统一。我见过很多图，有的矩形圆角大、有的圆角小，有的边框粗、有的边框细，放在一起就显得很业余。建议圆角半径统一用 4px 或 8px，边框统一用 1.5px 或 2px，具体数值根据图的尺寸调整，但同一张图里必须一致。

2.5 空间节奏：间距比对齐更重要

对齐是基本功，但真正让图看起来舒服的是间距节奏。diagram-design 建议采用 8px 基准网格，所有元素之间的间距都是 8 的倍数：8、16、24、32、48。同一层级的模块间距一致，不同层级之间用更大的间距区分。这样即使不看内容，光看布局就能感受到信息的层次。

我自己的经验是，画图时先把所有模块按逻辑分组，组内间距用 16px，组间间距用 32px，整个图的外边距用 48px。这个规则简单到可以背下来，但效果非常明显。

2.6 连线规则：箭头不是越多越好

连线是图表里最容易失控的部分。很多图密密麻麻全是箭头，读者根本追不过来。diagram-design 的建议是：能不用箭头就不用，能用一条线表达就不用两条。具体规则包括：主流程用实线加箭头，数据流向用虚线加箭头，依赖关系用无箭头实线，双向关系用无箭头虚线。同一对模块之间只保留一条连线，如果需要表达多种关系，用标签区分而不是画多条线。

另外，连线尽量走直角，避免斜线和曲线。直角连线看起来更整洁，也更容易追踪。如果必须交叉，尽量让交叉点集中在空白区域，不要压在模块上。

3. 核心要素拆解：从零搭建一套图表规范

3.1 第一步：确定图表的“阅读路径”

在动手画任何图之前，先问自己一个问题：读者应该按什么顺序看这张图？是从左到右、从上到下，还是从中心向外辐射？这个阅读路径决定了整体的布局方向。

diagram-design 推荐三种基本布局：线性布局适合流程和时序，层级布局适合架构和分类，网络布局适合关系和依赖。线性布局从左到右或从上到下，层级布局从中心或顶部展开，网络布局则围绕核心节点分布。选定布局后，所有模块的摆放都要服务于这条阅读路径，不要随意放置。

我见过很多图的问题就在于没有阅读路径，模块东一个西一个，读者眼睛不知道该往哪看。解决这个问题的方法很简单：画完之后眯着眼睛看，如果能隐约看出一条主线，说明布局是成功的；如果看到的是一盘散沙，那就需要重新调整。

3.2 第二步：建立模块的“视觉权重”

不是所有模块都同等重要，但很多图里所有模块看起来一样大、一样重，读者无法区分主次。diagram-design 建议通过三个维度建立视觉权重：尺寸、颜色、位置。

核心模块可以稍微大一点，或者用强调色，或者放在阅读路径的起点或中心。次要模块用结构色，尺寸稍小，放在边缘或后方。辅助信息用最浅的颜色和最小的字号，放在角落或底部。这样读者一眼就能看出哪些是重点。

具体操作上，我通常把模块分成三级：一级模块占图面面积的百分之五十以上，二级模块占百分之三十，三级模块占百分之二十。字号也相应分为三档，比如一级用 16px，二级用 14px，三级用 12px。这些数值不是绝对的，但分级思路是关键。

3.3 第三步：统一文字规范

文字是图表里信息密度最高的部分，但也是最容易被忽视的。diagram-design 建议统一四个文字属性：字体、字号、字重、对齐方式。

字体选无衬线字体，比如系统默认的 sans-serif，保证在不同设备上都能清晰显示。字号分三档就够了：标题 16-18px，正文 13-14px，注释 11-12px。字重只用两种：常规和加粗，加粗只用于模块名称或关键标签。对齐方式统一用居中对齐或左对齐，同一张图里不要混用。

还有一个细节：文字不要贴边。模块内的文字距离边框至少留 8px 的内边距，否则看起来会很挤。如果文字太长，宁可换行也不要缩小字号，缩小字号会破坏整体的字号层级。

3.4 第四步：定义连线样式

连线样式包括颜色、粗细、线型、箭头四个属性。diagram-design 的建议是：连线颜色比模块边框颜色浅一度，粗细统一用 1.5px，线型只用实线和虚线两种，箭头只用一种样式。

实线用于主流程和强关系，虚线用于辅助流程和弱关系。箭头大小要统一，不要有的箭头大有的箭头小。如果连线需要标签，标签放在连线中间，背景用白色或浅色遮挡连线，避免文字和线重叠。

我自己的习惯是，连线颜色用比模块边框浅百分之二十的灰色，这样连线不会抢模块的视觉焦点。箭头用简单的三角形，不要用花哨的样式。

3.5 第五步：制定图例和标注规则

图例是图表的“说明书”，但很多图要么没有图例，要么图例太复杂。diagram-design 建议：如果一张图里用到的形状和颜色不超过五种，可以不加图例；超过五种，必须加图例。图例放在图的右下角或底部，用最小的字号，只列出非常规的形状和颜色。

标注则用于解释特殊模块或特殊关系。标注的文字要简短，不超过一行，用引线指向被标注的对象。引线用细虚线，颜色比连线更浅。标注不要太多，一张图里超过五个标注就会显得杂乱。

4. 实操流程：从需求到成图的完整步骤

4.1 需求梳理：先想清楚再动手

画图之前，先花十分钟把需求理清楚。具体要回答四个问题：这张图给谁看？他们需要从中获取什么信息？这张图会放在哪里（文档、PPT、白板）？需要多详细？

给不同的人看，图的详细程度完全不同。给高层看，只需要核心模块和主流程；给开发看，需要接口和数据流向；给运维看，需要部署和网络拓扑。放在文档里可以详细，放在 PPT 里要精简，放在白板上要留白。

我自己的习惯是，先在纸上或白板上画一个草图，确定模块和关系，然后再用工具正式画。草图阶段不考虑美观，只考虑逻辑是否完整。逻辑确认后再进入正式绘制，这样返工的概率会大大降低。

4.2 工具选择：适合场景的才是最好的

画图工具没有绝对的好坏，关键看场景。diagram-design 本身不绑定任何工具，但不同工具适合不同的需求。

我的建议是：早期讨论用白板工具，正式文档用代码生成或桌面软件，需要协作时用在线工具。不管用什么工具，最终导出的图要统一格式和分辨率，文档里用 PNG 或 SVG，PPT 里用 PNG，白板拍照只用于内部讨论。

4.3 布局绘制：先骨架后血肉

正式绘制时，先画骨架——把所有模块用最简单的矩形摆出来，确定位置和大小。这个阶段不要管颜色和文字，只看布局是否合理、阅读路径是否清晰。骨架确认后，再填充颜色、文字、连线。

骨架阶段有个技巧：用灰度模式画。把所有模块都设成灰色，这样你会更关注布局和层级，而不是被颜色干扰。灰度模式下如果层级清晰，加上颜色后只会更清晰；灰度模式下如果层级混乱，加颜色也救不回来。

4.4 细节打磨：五个检查点

图基本画完后，用五个检查点过一遍：对齐、间距、颜色、文字、连线。

对齐检查：所有模块是否对齐到网格？同一层级的模块是否左对齐或居中对齐？间距检查：组内间距是否一致？组间间距是否大于组内间距？颜色检查：颜色是否超过六种？强调色是否只用于重点？文字检查：字号是否统一？是否有文字溢出或贴边？连线检查：是否有不必要的连线？连线是否交叉过多？

这五个检查点过完，图的质量基本就有保障了。我自己的经验是，前三个检查点能解决百分之八十的视觉问题，后两个检查点能解决百分之八十的逻辑问题。

4.5 导出与归档：让图可维护

图不是画完就结束了，还要考虑后续的维护。diagram-design 建议：源文件、导出文件、版本说明三者一起归档。源文件用于后续修改，导出文件用于文档引用，版本说明记录每次修改的内容和时间。

如果用的是代码生成工具，源文件本身就是版本可控的，只需要在提交信息里写清楚修改内容。如果用的是拖拽工具，建议每次修改后另存一个版本，不要覆盖旧版本。导出文件统一命名规则，比如“项目名-图名-版本号-日期”，方便查找。

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

5.1 图太乱怎么办：做减法而不是加法

图太乱是最常见的问题。很多人的第一反应是调整布局或换颜色，但真正有效的方法是做减法。具体步骤：先删掉所有非必要的模块，只保留核心模块；再删掉所有非必要的连线，只保留主流程；最后删掉所有非必要的装饰，只保留信息本身。

我试过一张图从三十个模块删到十二个模块，信息量没有减少，但可读性提升了一倍。删减的标准是：如果删掉这个模块，读者是否还能理解核心信息？如果能，就删掉。

5.2 颜色不够用怎么办：用形状和标签补充

有时候模块类型太多，六种颜色不够用。这时候不要增加颜色，而是用形状和标签来区分。比如同样是矩形，可以用不同的边框样式（实线、虚线、双线）来区分；同样是结构色，可以用不同的填充深浅来区分。

另一个方法是分组。把相关模块放在一个虚线框里，框上标注组名，这样组内模块可以用同一种颜色，组间用不同颜色。分组不仅能解决颜色不够的问题，还能让信息层级更清晰。

5.3 连线交叉太多怎么办：调整布局或分层

连线交叉太多通常是因为布局不合理。解决方法有两个：调整模块位置，让相关模块靠近；或者分层，把图分成上下两层或左右两层，层内连线，层间用少量连线连接。

如果调整布局后还是交叉太多，可以考虑把一张图拆成两张。第一张画高层概览，第二张画细节。读者先看概览理解整体，再看细节深入局部。拆图的原则是：每张图只讲一个故事。

5.4 团队风格不统一怎么办：建立共享规范文档

团队协作时，风格不统一是必然的。解决方法不是反复口头强调，而是建立一份共享的规范文档。文档里写清楚颜色值、字号、间距、形状规则、连线规则，并附上正例和反例。每次新成员加入时，先读这份文档再画图。

规范文档不需要很长，一页纸就够了。关键是要有正例和反例的对比图，这样比纯文字描述直观得多。我自己的团队用一份两页的规范文档，新成员基本一天就能上手，两周后画的图就能和老成员保持一致。

5.5 常见问题速查表

5.6 独家避坑技巧

第一个技巧：画图前先定色板。不要画到一半再选颜色，那样很容易越加越多。先定好六色色板，画图时只从这六个颜色里选，从源头控制颜色数量。

第二个技巧：用灰度模式检查层级。画完骨架后，把所有模块设成灰色，看层级是否清晰。灰度模式下层级清晰，加颜色后才会清晰。

第三个技巧：找没看过图的人试读。自己画的图自己看得懂，但别人不一定。找一个没参与项目的同事，让他看图说一遍理解，你能发现很多自己忽略的问题。

第四个技巧：保存历史版本。每次大改之前另存一个版本，这样改坏了可以回退。我自己的习惯是用日期命名版本，比如“架构图-20240115”，一目了然。

第五个技巧：图不要超过一屏。如果一张图需要滚动才能看完，说明信息量太大了，考虑拆图。一屏能看完的图，读者更容易建立整体认知。

6. 从单张图到图表体系：diagram-design 的扩展思路

6.1 建立项目级的图表库

单张图画得再好，如果项目里有几十张图风格各异，整体效果还是会打折扣。diagram-design 的扩展思路是建立项目级的图表库：把常用的模块、连线、图例做成模板，画新图时直接复用。

模板库不需要很复杂，一个文件就够了。里面放常用的形状组合、颜色样式、文字样式，画图时复制粘贴，改改文字就行。这样既能保证风格统一，又能提高效率。我自己的模板库里有二十多个常用模块，画一张新图的时间从一小时缩短到二十分钟。

6.2 图表与文档的同步维护

图表和文档脱节是常见问题。文档更新了，图没更新；图更新了，文档没更新。解决方法是把图表源文件放在文档同一个目录下，每次更新文档时顺便检查图表是否需要更新。

如果用的是代码生成工具，可以把图表生成脚本集成到文档构建流程里，文档构建时自动生成最新图表。这样只要源文件更新，图表就会自动同步，不会出现脱节。

6.3 图表评审的检查清单

团队协作时，图表评审是保证质量的重要环节。diagram-design 建议用一份检查清单来评审：信息是否完整？层级是否清晰？颜色是否统一？文字是否可读？连线是否合理？是否符合项目规范？

评审时不要只说“好看”或“不好看”，要具体指出问题。比如“这个模块的颜色和那个模块太接近，建议换一个”“这条连线和那条连线交叉了，建议调整布局”。具体的反馈才能带来具体的改进。

6.4 持续迭代：图表规范也需要版本管理

图表规范不是一成不变的，随着项目发展，可能需要增加新的形状、新的颜色、新的规则。这时候要对规范进行版本管理，记录每次修改的内容和原因。

版本管理不需要很复杂，一个更新日志就够了。每次修改规范时，在日志里写清楚改了什么、为什么改、影响哪些图。这样新成员能了解规范的演变过程，老成员能追溯历史决策。

我个人在实际操作中的体会是，图表设计这件事，入门容易精通难。画出一张能看的图不难，但画出一套风格统一、信息清晰、可维护的图表体系，需要持续的投入和迭代。diagram-design 提供的不是一套死板的规则，而是一种系统化的思维方式——把每一次画图都当作一次信息设计，把每一张图都当作整个文档体系的一部分。一旦建立起这种思维方式，你会发现不仅图变好看了，连思考问题的方式都变得更结构化了。

最后再分享一个小技巧：每次画完图，把它打印出来或者缩小到百分之五十看一遍。缩小后如果还能看清主线和重点，说明图的视觉层级是成功的；如果缩小后一片模糊，说明模块太大、间距太小，需要调整。这个技巧简单但非常有效，我几乎每张图都会用。