diagram-design：构建可复用图表设计系统的工程实践指南

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

第一次听到 “diagram-design” 这个词，很多人会下意识觉得它只是“画图”的另一种说法。但真正在项目里被图表折磨过的人知道，画图本身从来不是最痛的部分。最痛的是：图画完了，需求变了；图改完了，风格不统一；风格统一了，换个人接手又全部推倒重来。diagram-design 要处理的，正是这一连串连锁反应。

我把它理解成一套“图表设计系统”，而不是一个单纯的绘图工具。它的核心主张是：把图表当成产品来设计，而不是当成一次性插图来应付。这意味着你需要先定义一套规则——节点怎么表示、连线怎么走、颜色怎么分配、层级怎么区分、不同图种之间如何保持视觉一致性——然后再用这套规则去生成和维护所有图表。听起来有点重，但一旦跑通，后面每一张图的产出成本会断崖式下降。

这套东西适合谁？如果你只是偶尔画一张流程图发群里，那确实用不上。但如果你处在下面这些场景里，diagram-design 的价值会非常明显：技术团队需要维护架构图、时序图、状态机图，且这些图会随版本迭代反复更新；产品团队要输出业务流程图、用户旅程图，且要求多张图风格统一；文档团队要把零散的手绘草图整理成可长期维护的图库；甚至个人做知识管理，希望自己的笔记配图有一套稳定的视觉语言。这些场景的共同点是：图不是终点，图是要被反复引用、修改和复用的资产。

我见过太多团队在图表上踩的坑，本质上都不是“不会画”，而是“没有设计”。有人用某款工具画架构图，换一款工具画流程图，结果两份文档放在一起像两个不同公司出的。有人每次改图都直接在原图上动刀，改到第五版的时候已经没人记得最初的结构是什么。还有人把图导出成图片后就再也改不动，需求一变只能重画。diagram-design 的思路，就是把这些隐形成本提前暴露出来，用一套设计规范把它们摁住。

所以这篇内容不会教你某个具体软件的按钮在哪，而是把 diagram-design 拆成可执行的几个层面：设计原则怎么定、图种怎么分类、工具链怎么选、实操流程怎么跑、出问题怎么排查。你可以把它当成一份“图表设计系统搭建指南”，也可以当成一份避坑清单。不同基础的读者都能从中拿到能直接用的东西——新手能照着搭出第一套规范，有经验的人能对照检查自己漏了哪一环。

2. 核心设计思路拆解：为什么图表需要一套“设计系统”

2.1 图表失控的根源：把“画”和“设计”混为一谈

大部分图表问题的根源，在于我们把两个完全不同的动作混在了一起：一个是“画”，一个是“设计”。画是执行层面的，是把脑子里的结构落到画布上；设计是规则层面的，是决定这个结构用什么视觉语言表达。绝大多数人只做前者，不做后者，于是每画一张图都在重新发明轮子。

你可以这样理解：画图就像写代码里的业务逻辑，设计就像写代码里的架构规范。没有架构规范的代码，每个人按自己的习惯写，短期能跑，长期就是灾难。图表也一样。没有设计规范的图，单张看可能没问题，一旦放到一起、一旦需要修改、一旦换人接手，问题就全冒出来了。

diagram-design 的第一个核心思路，就是把“设计”这一步从隐性变成显性。具体做法是：在画任何一张图之前，先定义一套最小可用的视觉规则。这套规则不需要多复杂，但必须覆盖几个关键维度——节点样式、连线样式、颜色语义、字体层级、间距节奏。这五个维度定下来，后面所有图都在这套框架里生成，一致性就有了根基。

我试过在一个小项目里跳过这一步，直接开画。结果前三张图还算统一，到第五张的时候，因为要表达一个之前没出现过的概念，我临时加了一种新样式。到第十张的时候，图里已经出现了四种不同的圆角矩形和三种不同的箭头。这不是我懒，而是没有规则约束时，人脑会本能地“就地解决”，每一次就地解决都在积累不一致。

2.2 规则先行：用“约束”换“效率”的底层逻辑

很多人抗拒先定规则，觉得这是给自己上枷锁。但实际跑下来你会发现，规则带来的不是限制，而是效率。原因很简单：当规则确定后，你在画图时就不再需要做视觉决策了。你不需要想“这个节点用什么颜色”“这条线用实线还是虚线”，因为规则已经替你决定了。你只需要专注在结构本身——谁连谁、谁依赖谁、流程怎么走。

这就像写代码时用了代码规范工具，刚开始觉得烦，用久了发现它帮你省掉了大量“这里要不要加空格”“变量怎么命名”的琐碎决策，让你能把精力放在真正的逻辑上。diagram-design 里的规则，扮演的就是这个角色。

具体来说，规则先行能解决三个高频问题。第一是风格漂移：没有规则时，图会随着时间推移慢慢变形，今天加一点，明天改一点，最后面目全非。第二是协作摩擦：多人参与时，每个人对“好看”的理解不同，没有规则就会陷入无休止的审美争论。第三是维护成本：规则清晰时，改一张图只需要改规则，所有图自动跟随；规则模糊时，改一张图就是一次手工重做。

提示：规则不要一次定太多。我建议第一版规则控制在“五个维度、每个维度不超过三个选项”的范围内。规则太多会导致执行成本过高，反而没人愿意遵守。先跑起来，再迭代。

2.3 图种分类：不同图表不该用同一套视觉语言

diagram-design 的第二个核心思路，是承认不同图种需要不同的视觉语言。很多人为了“统一”，强行让所有图用同一套样式，结果架构图和流程图看起来一模一样，读者根本分不清自己在看什么。统一不等于一样，统一是指在同一套设计原则下，允许不同图种有自己的表达重点。

我通常把图表分成四大类，每类有自己的设计侧重。第一类是结构类，包括架构图、部署图、组件图，重点是表达“谁和谁在一起、谁依赖谁”，视觉上强调分组和边界。第二类是流程类，包括流程图、时序图、状态机图，重点是表达“先后顺序和条件分支”，视觉上强调方向和节奏。第三类是关系类，包括思维导图、关系图、树状图，重点是表达“层级和关联”，视觉上强调中心与辐射。第四类是数据类，包括各种统计图和趋势图，重点是表达“量和变化”，视觉上强调对比和趋势。

这四类图可以共享同一套颜色语义和字体层级，但在节点形状、连线样式、布局方式上应该有明显区分。比如结构类图适合用矩形节点加实线连接，流程类图适合用圆角节点加带箭头的连线，关系类图适合用圆形节点加曲线连接。这样读者一眼就能判断自己在看什么类型的图，认知负担会小很多。

2.4 工具选型：代码化还是可视化，取决于你的维护频率

工具选型是 diagram-design 里最容易纠结的一环。市面上的选择大致分两派：一派是可视化拖拽工具，一派是代码化生成工具。我的经验是，不要问“哪个工具最好”，而要问“这张图的维护频率有多高”。

维护频率低的图，比如一次性汇报用的示意图，用可视化工具最快，拖拖拽拽十分钟搞定，没必要上代码。维护频率高的图，比如会随版本迭代的架构图，用代码化工具更合适，因为改起来是改文本，可以进版本控制，可以 diff，可以 review。维护频率中等的图，比如季度更新的业务流程图，可以先用可视化工具出初稿，再转成代码化格式长期维护。

这里有个容易被忽略的点：工具选型不只是选一个软件，而是选一套工作流。可视化工具的工作流是“打开软件、拖拽、导出”，代码化工具的工作流是“写文本、渲染、提交”。两套工作流的协作方式、版本管理方式、复用方式完全不同。你在选工具的时候，其实是在选后面几个月甚至几年的工作方式。

我个人的做法是混合使用：结构类和流程类图用代码化工具，因为这两类图最需要版本管理和复用；关系类和数据类图用可视化工具，因为这两类图更依赖即时调整和视觉微调。这个分工不是绝对的，但逻辑是清晰的——让工具的特性匹配图种的维护需求。

3. 核心细节解析与实操要点：把设计系统落到每一张图上

3.1 节点设计：形状、尺寸、间距的三角关系

节点是图表的基本单元，节点设计没做好，后面全白搭。节点设计里最核心的是三个参数：形状、尺寸、间距。这三个参数互相牵制，必须一起考虑。

形状决定语义。我的习惯是：矩形表示“实体或模块”，圆角矩形表示“过程或动作”，圆形表示“状态或事件”，菱形表示“判断或分支”。这套映射不是标准答案，但一旦定下来就要严格执行。我见过有人在同一张图里用矩形表示模块、又用矩形表示动作，读者根本分不清哪个是哪个。形状的语义一旦混乱，整张图的可读性就崩了。

尺寸决定节奏。节点太大，图会显得松散，信息密度低；节点太小，文字挤在一起，读起来费劲。我的经验值是：节点高度控制在文字行高的两到三倍，节点宽度根据文字长度自适应，但设置一个最小宽度和最大宽度。最小宽度保证短文字不会缩成一个小方块，最大宽度保证长文字不会拉成一条长条。这个范围我一般设在 120px 到 280px 之间，具体根据画布尺寸调整。

间距决定呼吸感。节点之间的水平间距和垂直间距要成比例，我通常用 1:1.5 的比例，也就是水平间距小一点，垂直间距大一点。原因是人眼在垂直方向上的阅读惯性更强，垂直间距大一些能让层级更清晰。同一层级内的节点间距要一致，不同层级之间的间距可以适当加大，用间距本身来表达分组关系。

注意：节点内的文字对齐方式也要统一。我建议统一用居中对齐，因为居中在视觉上最稳定，不会因为文字长度变化导致节点看起来“歪”。左对齐适合文字量大的场景，但在图表里文字通常很短，居中的优势更明显。

3.2 连线设计：方向、样式、标签的语义化处理

连线是图表的血管，连线的设计直接决定读者能不能顺畅地“读”完一张图。连线设计里最重要的是三件事：方向、样式、标签。

方向要一致。流程类图的连线方向应该统一，要么全部从左到右，要么全部从上到下，不要混着来。混着来的图，读者需要不断调整阅读方向，认知负担会成倍增加。结构类图的连线方向可以灵活一些，但也要遵循一个原则：主要依赖关系用直线，次要依赖关系用曲线，这样主次分明。

样式要分层。实线表示强关系或主流程，虚线表示弱关系或辅助流程，点线表示可选关系或待定关系。这套分层规则定下来后，读者扫一眼就能判断哪些是核心、哪些是边缘。我见过有人把所有连线都画成实线，结果整张图看起来像一团乱麻，根本分不清主次。

标签要克制。连线上的标签能不加就不加，能短就短。标签太长会遮挡连线，标签太多会让图变得嘈杂。如果一条连线的含义需要很长的文字才能说清，那说明这条连线本身可能设计得有问题，应该考虑拆成两条或者换个表达方式。标签的位置也要统一，我一般放在连线的中点偏上位置，避免和连线重叠。

3.3 颜色系统：用语义色而不是装饰色

颜色是图表设计里最容易滥用的元素。很多人把颜色当装饰用，觉得“加点颜色好看”，结果图里五颜六色，读者完全不知道每种颜色代表什么。diagram-design 里的颜色应该是语义化的，每一种颜色都有明确的含义。

我通常用四种语义色：主色表示核心模块或主流程，辅色表示支撑模块或辅助流程，强调色表示需要特别注意的部分，中性色表示背景或次要信息。这四种颜色的数量要严格控制，主色和辅色各一种，强调色最多两种，中性色两到三种。颜色太多会稀释语义，读者记不住。

颜色的选择还要考虑可访问性。色盲色弱人群对红绿区分度低，所以尽量不要用红绿对比来表达关键信息。我一般用蓝橙对比代替红绿对比，蓝色表示常规，橙色表示异常或重点。另外，颜色的明度要有区分，深色表示重要，浅色表示次要，这样即使打印成黑白也能看出层级。

提示：定好颜色后，把色值写进规范文档里，不要凭感觉调。我见过太多人每次画图都重新调一遍颜色，结果十张图十种蓝。把色值固定下来，复制粘贴，省时省力还统一。

3.4 字体与排版：层级比字体本身更重要

字体选择上，我的建议是：不要追求花哨，用系统默认的无衬线字体就够了。图表里的文字是功能性的，不是装饰性的，可读性永远排第一。真正影响阅读体验的不是字体本身，而是字体层级。

字体层级我一般分三级：一级标题用 18px 到 20px，加粗；二级标题用 14px 到 16px，常规；正文用 12px 到 14px，常规。三级之间要有明显的尺寸差异，读者才能一眼分辨层级。如果一级和二级只差 2px，那这个层级等于没有。

行高也很关键。图表里的文字通常比较短，行高可以设得紧一些，1.2 到 1.4 倍就够了。行高太大会让节点显得空，行高太小会让文字挤在一起。我一般用 1.3 倍行高作为默认值，根据实际效果微调。

排版上还有一个容易被忽略的点：文字和节点边界的距离。文字不能贴着节点边缘，要留出内边距。内边距我一般设成节点高度的 15% 到 20%，这样文字看起来是“住在”节点里，而不是“卡在”节点里。这个细节很小，但对整体质感的影响很大。

4. 实操过程与核心环节实现：从零搭一套可复用的图表系统

4.1 第一步：定义你的最小设计规范

搭系统的第一步不是画图，而是写规范。规范不用长，一页纸就够，但必须覆盖前面说的五个维度。我通常用一个表格来承载这份规范，左边是维度，右边是规则和示例。

这份规范定下来后，打印出来贴在显示器旁边，或者放在文档最前面。每次画图前扫一眼，画图时对照执行。刚开始可能会觉得别扭，画上十张图之后就变成肌肉记忆了。

规范不是一成不变的。跑一段时间后，你会发现某些规则不适用，或者某些场景需要补充新规则。这时候就更新规范，但更新要有记录，不要悄悄改。我一般会在规范文档里加一个“变更记录”小节，写清楚什么时候改了什么、为什么改。这样团队里其他人能跟上变化，不会出现“怎么突然不一样了”的困惑。

4.2 第二步：搭建可复用的组件库

规范定好后，下一步是把规范变成可复用的组件。这一步是 diagram-design 从“理念”变成“工具”的关键。组件库的本质，是把规范里的每一条规则都做成一个可以直接拖拽或引用的模板。

组件库我一般分三层。第一层是基础组件，包括各种形状的节点、各种样式的连线、各种层级的文字。这些是最小单元，所有图都从这里取。第二层是组合组件，包括常见的模块组合，比如“服务+数据库”“用户+网关+服务”。这些组合在架构图里反复出现，做成模板能省大量时间。第三层是图种模板，包括架构图模板、流程图模板、时序图模板。这些模板预设好了布局和样式，新建图的时候直接套用，只需要填内容。

组件库的维护有个原则：只增不改。意思是，已经发布的组件不要直接修改，要改就新增一个版本。原因是，旧图可能还在引用旧组件，直接改会导致旧图变形。新增版本可以让新旧共存，逐步迁移。这个原则听起来麻烦，但能避免大量“改一个组件崩十张图”的事故。

提示：组件库不要一开始就追求大而全。我建议先从最常用的五到十个组件开始，用起来之后再逐步补充。一开始就搭一个大库，维护成本高，而且很多组件可能根本用不上。

4.3 第三步：用代码化工具实现版本管理

如果你决定用代码化工具，这一步就是核心。代码化工具的最大优势是图表可以进版本控制，可以 diff，可以 review。这意味着图表的修改过程和代码的修改过程一样，是可追溯、可回滚、可协作的。

我以常见的文本化图表工具为例说明工作流。首先，把图表定义写成文本文件，每个图一个文件，文件名用图表的用途命名，比如system-architecture.txt、user-flow.txt。然后，把这些文件放进代码仓库，和项目代码一起管理。修改图表时，新建一个分支，改完提交，走 review 流程，合并到主分支。

这个流程的好处是，每次图表变更都有记录。谁改的、什么时候改的、改了什么、为什么改，全部可查。需求方说“这张图怎么和上次不一样了”，你可以直接调出 diff 给他看。这在可视化工具里是很难做到的，因为可视化工具的修改历史通常很粗糙，只能看到“保存了”，看不到“改了什么”。

代码化工具的另一个好处是复用。你可以把公共的样式定义抽成一个单独的文件，所有图表引用这个文件。改样式的时候只改一个地方，所有图自动更新。这个机制在可视化工具里也有，但通常不够灵活，代码化工具在这方面的控制力更强。

4.4 第四步：建立图表审查清单

系统搭好后，还需要一个质量把关的环节。我通常用一个审查清单来检查每张图，确保它符合规范。清单不用长，十条以内就够，但每一条都要能快速判断“是”或“否”。

我的审查清单大概长这样：节点形状是否符合语义映射；连线样式是否区分了主次；颜色是否只用了规范里的语义色；字体层级是否清晰；节点间距是否一致；文字是否居中且留了内边距；连线标签是否克制；整体布局是否方向一致；是否有未定义的样式混入；导出格式是否适合目标场景。这十条过一遍，基本能拦住大部分问题。

审查清单的用法有两种。一种是自审，画完图自己过一遍清单，确认没问题再发出去。另一种是互审，团队里两个人互相检查，因为自己看自己的图容易有盲区。我建议两种都用，自审保证基本质量，互审发现深层问题。

审查清单也要迭代。跑一段时间后，你会发现某些问题反复出现，那就把对应的检查项加进去。比如团队里总是有人忘记统一连线方向，那就把“连线方向是否一致”加进清单。清单越长，说明系统越成熟，因为你知道哪些地方容易出问题。

5. 常见问题与排查技巧实录：那些踩过的坑和绕过的弯

5.1 图表越改越乱怎么办

这是最高频的问题。图表改到第三版、第四版的时候，往往会出现“改不动了”的感觉，每改一处就崩一处。根本原因通常是：修改没有在规范层面进行，而是在实例层面硬改。

排查思路是这样的：先看这张图有没有对应的规范。如果没有，那问题不在图本身，在于缺规范，先补规范再改图。如果有规范，看修改是否违反了规范。如果违反了，那就要么改规范、要么改图，不能两头都不动。如果没违反规范，看是不是规范本身有漏洞，需要补充新规则。

我的经验是，图表越改越乱，九成情况下是因为一开始就没有规范，或者规范太模糊。解决办法不是硬改，而是停下来，先把规范理清楚，再回头改图。这听起来费时间，但比在混乱中反复挣扎要快得多。

5.2 多人协作时风格不统一怎么办

多人协作的风格问题，本质是规范执行问题。规范定了但没人遵守，等于没定。解决办法有三个层次。

第一层是降低执行成本。规范要简单到不需要思考就能执行。如果规范里说“节点宽度根据内容自适应”，那每个人理解的自适应可能都不一样。改成“节点宽度在 120px 到 280px 之间，短文字用 120px，长文字用 280px”，执行起来就没有歧义了。

第二层是提供现成模板。不要让人从零开始画，而是提供预设好样式的模板。模板里已经把规范固化了，用模板就等于遵守规范。这比让人对着规范文档手动执行要可靠得多。

第三层是建立审查机制。前面说的审查清单就是干这个的。定期抽查，发现问题及时纠正。纠正的时候不要只说“这里不对”，要说“这里违反了规范第几条，应该改成什么样”。这样既解决了问题，又强化了规范意识。

5.3 图表导出后失真怎么办

导出失真通常有三种表现：文字变模糊、颜色变暗淡、布局错位。这三种问题的原因不同，解决办法也不同。

文字变模糊通常是分辨率不够。导出图片时，分辨率要设成目标显示尺寸的两倍以上。比如图要在 1920px 宽的屏幕上显示，导出宽度至少 3840px。如果是打印，分辨率要设成 300dpi 以上。这个参数在导出设置里通常叫“缩放”或“倍率”，调大就行。

颜色变暗淡通常是色彩空间问题。屏幕显示用 RGB，打印用 CMYK，两者色域不同。如果图是屏幕用，导出时选 RGB；如果是打印用，导出时选 CMYK。另外，导出格式也有影响，PNG 支持透明背景，JPG 不支持，如果图需要透明背景，必须用 PNG。

布局错位通常是字体缺失。如果图里用了非系统字体，导出时目标设备没有这个字体，就会用默认字体替代，导致文字宽度变化、布局错位。解决办法是导出前把文字转成轮廓，或者只用系统默认字体。我一般建议后者，因为转轮廓后文字就不可编辑了，后续修改麻烦。

5.4 图表信息量太大怎么精简

信息量太大的图，读者根本读不完。精简的核心原则是：一张图只讲一件事。如果一张图里塞了三件事，那就拆成三张图。

拆图的方法有几种。按层级拆，把高层概览和底层细节分开，高层图只画主要模块，底层图展开每个模块的内部结构。按流程拆，把端到端流程拆成几个阶段，每个阶段一张图。按角色拆，把不同角色关注的视图分开，运维看部署图，开发看架构图，产品看业务流程图。

拆完之后，每张图的信息量就降下来了。如果拆完还是觉得多，那就继续拆，直到每张图都能在三十秒内被读懂。三十秒是个经验值，超过三十秒还没读懂，说明图还是太复杂。

注意：拆图不是越多越好。拆得太碎会导致读者需要在多张图之间来回跳转，反而增加认知负担。我一般控制在三到五张图讲完一个主题，超过五张就要考虑是不是主题本身太大了。

5.5 常见问题速查表

5.6 几个我踩过的坑

第一个坑是规范定得太细。我一开始把规范定到了像素级，每个节点的高度、宽度、圆角半径都写死了。结果画图的时候，遇到稍微不同的场景就要改规范，改到最后规范文档比图还长。后来我改成“范围值”，比如高度 40 到 60px，宽度 120 到 280px，灵活多了。

第二个坑是组件库更新太频繁。有段时间我每画一张图就发现组件库缺东西，于是不停往里加。加到最后组件库有上百个组件，找起来比重新画还慢。后来我定了个规则：同一个组件被用到三次以上才加进库，用不到三次的就临时画。这样组件库精简了很多，找起来也快。

第三个坑是审查清单太长。我一开始列了二十多条检查项，结果每次审查都要花十几分钟，审着审着就烦了，干脆不审了。后来砍到十条以内，每条都能在十秒内判断，审查就变成了一件顺手的事。清单不是越长越好，能执行才是关键。

第四个坑是工具换得太勤。有段时间我总觉得下一个工具会更好，于是不停换。每换一次工具，之前的图就要重画一遍，组件库也要重建。换到第三个工具的时候我意识到，问题不在工具，在于我没有把设计规范独立于工具之外。后来我把规范写成纯文本，工具只是渲染器，换工具的时候规范不用动，迁移成本就低多了。

6. 图表系统的扩展与长期维护

6.1 从单项目到跨项目的规范迁移

一套图表系统在一个项目里跑通后，很自然会想迁移到其他项目。迁移的时候有个原则：规范可以共享，组件库要按项目定制。规范是通用的设计原则，比如“矩形表示模块”“实线表示主流程”，这些在哪个项目都适用。组件库是项目特定的，比如某个项目有特殊的模块类型，需要专门的节点样式，这个就不适合直接搬到其他项目。

迁移的步骤我一般这样走：先把规范文档复制过去，然后在新项目里搭一个最小组件库，只包含最常用的几个组件。跑一段时间后，根据新项目的实际需求逐步补充组件。不要一上来就把旧项目的组件库全搬过去，因为旧项目里很多组件在新项目里可能根本用不上，搬过去只会增加维护负担。

跨项目迁移还有一个好处：能检验规范是否真的通用。如果某个规范在新项目里不适用，那说明它可能不是真正的“设计原则”，而是某个项目的“特定规则”。这种规则应该从通用规范里拆出来，放到项目特定的规范里。经过几次迁移，通用规范会越来越精炼，越来越接近本质。

6.2 图表系统的版本管理策略

图表系统的版本管理，我建议分两个层面：规范版本和图表版本。规范版本用语义化版本号，比如 v1.0、v1.1、v2.0。小版本表示补充规则，大版本表示规则变更。图表版本跟着规范版本走，规范升级后，图表逐步迁移到新规范。

迁移的时候不要一刀切。旧图可以继续用旧规范，新图用新规范，等旧图需要修改的时候再顺便迁移。这样迁移成本被分摊到日常修改里，不会集中爆发。我见过有人一次性把所有图迁移到新规范，结果迁移过程中出了大量问题，反而影响了正常使用。

版本管理还有一个细节：每次规范升级都要写迁移指南。指南里说清楚哪些规则变了、旧图怎么改、有没有自动化工具。没有迁移指南的规范升级，等于把迁移成本全甩给了执行者，执行者往往会选择不迁移，导致新旧规范长期共存。

6.3 图表系统的自动化检查

当图表数量多到一定程度，人工审查就不够用了。这时候可以考虑自动化检查。自动化检查的原理很简单：把规范里的规则写成检查脚本，脚本扫描图表文件，发现违规就报错。

能自动检查的规则包括：节点形状是否符合语义映射、颜色是否在允许的色值列表里、字体大小是否在允许的范围内、连线样式是否只有规定的几种。这些规则都是确定性的，适合自动化。不能自动检查的规则包括：布局是否合理、信息层级是否清晰、连线是否交叉太多。这些规则需要人工判断，自动化做不了。

自动化检查的落地方式，取决于你用的工具。代码化工具通常支持插件或脚本，可以在渲染前跑检查。可视化工具可能需要导出成中间格式再检查。我一般建议先从代码化工具开始做自动化，因为代码化工具的图表定义本身就是文本，检查起来最方便。

6.4 图表系统的长期演进方向

图表系统不是搭完就完了，它需要持续演进。演进的方向我观察下来有三个。第一个方向是更细的语义化，从“节点形状表示类型”进化到“节点形状加颜色加边框表示更细的类型”。第二个方向是更强的复用，从“组件复用”进化到“子图复用”，把常见的子结构做成可复用的模块。第三个方向是更好的协作，从“规范加审查”进化到“规范加自动化加实时协作”。

这三个方向不是必须都走，取决于你的实际需求。如果图表数量不多，语义化到一定程度就够了，不需要无限细化。如果复用需求不强，子图复用可能用不上。如果团队规模小，实时协作也不是刚需。演进的原则是：需求驱动，不要为了演进而演进。

我个人在实际操作中的体会是，图表系统的价值不在于它有多完善，而在于它能不能被持续使用。一套简单但被严格执行的规范，比一套完善但没人遵守的规范有价值得多。所以搭系统的时候，宁可先搭一个粗糙但能跑的版本，也不要追求一步到位。跑起来之后，根据实际反馈迭代，系统会自己长成它该有的样子。

最后再分享一个小技巧：把图表系统的规范文档和组件库放在团队最容易访问的地方，比如项目文档的首页或者代码仓库的根目录。让每个人都能随手拿到，而不是藏在某个深层文件夹里。访问成本越低，使用率越高。这个细节很小，但往往是系统能不能活下来的关键。