企业官网建设流程全解析

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 里一个容易被忽略但极其关键的环节，是图表类型的选择。很多人拿到需求就开始画，却没想过“这个信息到底适合用什么图来表达”。我见过用流程图去表达数据关系的，也见过用架构图去表达时间顺序的，结果就是图不达意，读者越看越糊涂。

我的经验是，先明确表达意图，再选图表类型。表达意图大致分四类：结构关系、流程顺序、数据对比、状态变化。结构关系适合用架构图、拓扑图、层级图；流程顺序适合用流程图、泳道图、时序图；数据对比适合用柱状图、折线图、散点图；状态变化适合用状态机图、生命周期图。选错类型，就像用螺丝刀去敲钉子，不是不能用，但效率极低。

这里有个实操技巧：如果你不确定该用哪种图，先用一句话把要表达的核心信息写出来，然后看这句话的主语和谓语是什么。如果主语是“系统/模块”，谓语是“调用/依赖”，那就是结构关系；如果主语是“用户/任务”，谓语是“先/然后/最后”，那就是流程顺序。这个方法我用了很多次，基本能避免选错类型。

3. 核心细节解析：语义、视觉与布局的三层设计要点

3.1 语义层：让每个图形元素都有明确且唯一的含义

语义层是 diagram-design 的地基。地基没打好，上面视觉做得再漂亮也是空中楼阁。语义层的核心任务是定义“什么形状代表什么概念”，并且保证这个对应关系在整个文档体系里唯一且稳定。

我一般会先列一张“元素语义表”，把项目里会用到的所有概念列出来，然后给每个概念分配一个形状。比如在微服务架构图里，我会定义：圆角矩形代表业务服务，直角矩形代表基础设施组件，圆柱代表数据库，云朵代表外部依赖，虚线框代表边界。这张表一旦定下来，后面所有图都严格按表执行，不允许临时发明新形状。

这里有个容易踩的坑：形状语义冲突。比如你定义了圆角矩形代表服务，结果画流程图时又用圆角矩形代表开始节点，读者就会混淆。解决办法是把不同图表类型里的形状语义分开管理，架构图一套、流程图一套，但同一套内部必须严格一致。另外，形状的数量也要控制，我一般不超过六种，超过六种读者就记不住了。

还有一个细节是图例的必要性。如果形状语义足够直观，比如圆柱代表数据库是行业通用认知，那可以省略图例。但如果用了自定义形状，图例就必须有，而且要放在读者第一眼能看到的位置。我见过把图例放在图右下角的，读者看完图才发现图例，等于白放。图例的位置优先级是：图上方 > 图左侧 > 图下方，右侧和角落是最差选择。

3.2 视觉层：颜色、线型与字号的克制使用法则

视觉层是读者最先感知到的部分，也是最容易过度设计的地方。我刚开始做 diagram-design 时，总想把图做得“好看”，用了很多渐变色、阴影、立体效果，结果读者反馈“看着累”。后来才明白，图表的视觉设计目标不是好看，而是降低阅读阻力。

颜色方面，我的原则是“一色一义”。每种颜色只能代表一种含义，不能一色多用。比如蓝色代表“内部服务”，那所有内部服务都用蓝色，所有非内部服务都不能用蓝色。颜色数量控制在三到五种，超过五种就需要图例辅助，而图例本身又会增加认知负担。另外，颜色的选择要考虑色盲友好，红绿搭配是最差选择，蓝橙搭配相对安全。如果图要打印成黑白，还要保证不同颜色在灰度下也能区分，这个可以用灰度值来检验。

线型方面，实线、虚线、点线三种基本够用。实线代表强关系或主流程，虚线代表弱关系或可选流程，点线代表边界或分组。线宽也要统一，主流程线宽可以设为 2px，辅助线设为 1px，但同一层级的线宽必须一致。箭头样式同理，实心箭头代表调用或依赖，空心箭头代表继承或泛化，开放箭头代表数据流。这些规则一旦定下来，就不要随意更改。

字号方面，我一般用三档：标题 16px、正文 12px、注释 10px。字号差异要足够明显，否则读者分不清层级。字重也可以用来区分，标题用粗体，正文用常规，注释用细体。但字重变化不要超过两种，否则会显得杂乱。还有一个细节是文字对齐，同一层级的文字要么全部左对齐，要么全部居中对齐，混用会显得很不专业。

3.3 布局层：用空间关系传递信息层级

布局层是最容易被忽视但影响最大的部分。同样一组元素，布局不同，读者理解的速度可能差好几倍。diagram-design 的布局原则是：用空间关系传递信息层级，而不是靠文字标注。

最常见的布局模式有三种：分层布局、从左到右布局、中心辐射布局。分层布局适合表达上下级关系，比如架构图里的接入层、逻辑层、存储层，从上到下排列，读者一眼就能看出层级。从左到右布局适合表达时间顺序或流程，比如用户从进入页面到完成下单的流程，从左到右排列，符合阅读习惯。中心辐射布局适合表达以某个核心为中心的关系网，比如以网关为中心的服务调用关系，核心放中间，其他元素围绕四周。

布局的另一个关键是留白。很多人为了省空间，把元素排得密密麻麻，结果读者根本分不清哪些元素是一组。留白的本质是分组，同一组元素之间留小间距，不同组之间留大间距，读者自然会把靠近的元素归为一组。我一般用 8px 作为组内间距，24px 作为组间间距，这个比例在大多数场景下都适用。

还有一个实操技巧是对齐。人眼对对齐非常敏感，哪怕差 1px 都能看出来。我画图时一定会打开网格和对齐辅助线，保证同一层级的元素左边缘对齐、上边缘对齐。如果元素大小不一，可以用中心对齐。对齐做得好，图看起来就会很“整”，专业感立刻提升。

4. 实操过程：从零搭建一套可复用的图表设计系统

4.1 第一步：梳理信息架构，明确图表要回答的核心问题

动手画之前，先想清楚这张图要回答什么问题。我见过太多人拿到需求就开始拖框，画到一半发现信息不全，又回头补，效率极低。正确的做法是先做信息架构梳理，把要表达的内容列成大纲，再决定怎么画。

具体操作是，拿一张白纸或打开一个空白文档，用文字把图要表达的核心信息写出来。比如“这张图要说明用户下单后，订单服务如何调用库存服务和支付服务，以及失败时的补偿流程”。写完之后，把这句话拆成几个关键问题：有哪些参与方？它们之间是什么关系？主流程是什么？异常流程是什么？每个问题的答案就是图里要出现的元素和连线。

这个步骤看起来简单，但能避免大量返工。我自己的经验是，信息架构梳理花 10 分钟，后面画图能省 1 小时。而且梳理完之后，图的边界很清晰，不会出现“画着画着不知道还要不要加东西”的情况。

4.2 第二步：定义元素语义表与视觉规范

信息架构清晰后，接下来定义元素语义表和视觉规范。这一步是 diagram-design 的核心，也是最能体现“设计系统”思维的地方。

元素语义表我一般用表格来管理，三列：概念名称、形状、颜色。比如：

视觉规范则定义线型、线宽、字号、间距等。比如：主流程线用 2px 实线，辅助线用 1px 虚线；标题 16px 粗体，正文 12px 常规，注释 10px 细体；组内间距 8px，组间间距 24px。

这两张表定下来后，后面所有图都从这里取元素，不再临时发明。这样做的好处是，当团队多人协作时，大家用的是同一套语言，图与图之间自然统一。而且规范可以版本化管理，需求变了改规范，所有图同步更新。

4.3 第三步：用网格与对齐构建基础布局

有了规范，开始画图。第一步是搭布局框架，而不是直接画元素。我一般先画网格，把画布分成若干等份，然后按信息架构把元素放到网格上。

网格的作用是保证对齐和间距一致。比如画布宽 1200px，我分成 12 列，每列 100px，元素宽度占 2 列就是 200px，占 3 列就是 300px。这样所有元素宽度都是 100 的倍数，排列起来自然整齐。垂直方向同理，分成若干行，行高统一。

布局框架搭好后，再往里面填元素。填的时候注意分组，同一组元素放在相邻的网格里，组与组之间留出空行。连线尽量走直线，避免斜线和曲线，斜线会让图显得凌乱。如果必须交叉，用“跳线”表示不连接，而不是直接交叉，否则读者分不清哪条线连哪个元素。

4.4 第四步：连线与标注的规范化处理

连线是图表里最容易出问题的部分。我见过太多图，元素画得很规整，连线一团乱麻，读者根本追不下去。diagram-design 对连线的要求是：每一条线都要有明确的方向和含义。

方向方面，主流程线从左到右或从上到下，符合阅读习惯。如果流程有回退，用反向箭头表示，但反向箭头不要太多，否则图会显得很乱。含义方面，每条线要么代表调用，要么代表数据流，要么代表依赖，不能一条线同时代表多种含义。如果确实需要表达多种关系，用不同线型区分，比如实线代表同步调用，虚线代表异步消息。

标注方面，连线上的文字要简洁，一般不超过五个字。如果标注太长，把文字放在连线旁边，用引线指向连线，而不是直接压在线上。标注的位置也要统一，要么全部在线上方，要么全部在线下方，不要一会儿上一会儿下。

4.5 第五步：导出、版本管理与团队协作

图画完后，导出和版本管理也是 diagram-design 的一部分。我一般导出两种格式：矢量格式（如 SVG）用于文档嵌入，位图格式（如 PNG）用于快速预览。矢量格式的好处是放大不失真，而且文件小，适合放在文档里。

版本管理方面，我习惯把图表源文件和导出文件分开存放，源文件用工具的原生格式，导出文件按版本号命名。每次修改图，先改源文件，再重新导出，而不是直接在导出文件上改。这样保证源文件和导出文件始终一致，不会出现“源文件改了但导出文件没更新”的情况。

团队协作方面，最重要的是规范共享。我会把元素语义表和视觉规范放在团队共享文档里，所有人画图前先看规范，画完后互相 review。review 的重点不是图好不好看，而是有没有偏离规范、有没有语义冲突、有没有信息遗漏。坚持一段时间后，团队出图的效率和质量都会有明显提升。

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

5.1 图太乱看不清：从信息密度和视觉噪音入手

图太乱是最常见的问题。原因通常有两个：信息密度太高，或者视觉噪音太多。信息密度高是指一张图塞了太多元素，读者一眼看不过来。解决办法是拆图，把一张大图拆成几张子图，每张子图只表达一个主题。比如一张完整的架构图可以拆成部署架构、调用关系、数据流向三张图，每张图聚焦一个维度。

视觉噪音多是指颜色、线型、形状太花哨，读者被视觉元素干扰。解决办法是做减法，把不必要的颜色去掉，把不统一的线型统一，把多余的字号合并。我一般会问自己：这个颜色去掉后，信息会丢失吗？如果不会，就去掉。这个线型改成实线后，含义会变吗？如果不会，就改。做减法的过程很痛苦，但效果立竿见影。

还有一个技巧是“眯眼测试”：把图缩小到看不清文字的程度，如果还能看出大致的结构和分组，说明布局是清晰的；如果缩到很小就一团糊，说明布局有问题，需要重新调整。

5.2 读者看不懂图例：语义直观性与图例位置优化

读者看不懂图例，通常是因为语义不够直观，或者图例位置太偏。语义直观性方面，尽量用行业通用形状，比如圆柱代表数据库、云朵代表外部依赖，这些读者不用看图例就能猜出来。如果必须用自定义形状，图例就要做得足够醒目。

图例位置方面，前面说过，优先级是图上方 > 图左侧 > 图下方。图例的样式也要统一，每个图例项由形状和文字组成，形状和文字之间留适当间距。图例项的顺序按重要性排列，最重要的放最前面。如果图例项太多，可以考虑分组，比如“服务类”“存储类”“外部类”三组，每组内部再列具体项。

还有一个容易被忽略的细节是图例的更新。如果图里加了新元素但忘了更新图例，读者就会困惑。我的做法是，每次改图后检查一遍图例，确保图例和图里的元素一一对应。

5.3 团队风格不统一：规范落地与 review 机制

团队风格不统一是协作场景下的典型问题。根源在于规范没有落地，或者落地了但没人检查。解决办法分两步：第一步是把规范写清楚，不要含糊。比如“蓝色代表服务”就不够清楚，要写成“蓝色（色值 #4A90D9）代表业务服务，仅用于圆角矩形”。色值、形状、使用场景都写明白，减少歧义。

第二步是建立 review 机制。每次有人提交图表，指定一个人按规范检查，检查项包括：颜色是否在规范内、形状是否在语义表内、线型是否统一、字号是否一致、图例是否完整。检查不通过就打回修改，通过后才能合入文档。这个机制刚开始会有点繁琐，但坚持两三周后，大家就形成肌肉记忆了，后面基本不用怎么检查。

还有一个技巧是提供模板。把规范做成模板文件，大家画图时直接从模板开始，而不是从空白画布开始。模板里预置好颜色、形状、线型、字号，大家只需要拖元素、连线、填字。这样即使有人想偏离规范，成本也会很高，自然就统一了。

5.4 图表维护成本高：模块化与自动化思路

图表维护成本高，通常是因为图里的信息是“硬编码”的，改一个地方要改很多张图。解决办法是模块化，把常用的图元做成可复用的组件。比如“用户服务”这个组件，包含一个圆角矩形、一个图标、一段文字，做成组件后，所有用到用户服务的图都引用这个组件。需求变了要改用户服务的样式，只改组件，所有引用它的图同步更新。

自动化方面，如果图表数据来自代码或配置文件，可以考虑用脚本自动生成图。比如从服务注册中心拉取服务列表和调用关系，自动生成架构图。这样每次服务有变动，重新跑一下脚本，图就更新了，不用手动改。当然自动化不是必须的，但对于频繁变动的系统，自动化能省大量维护时间。

我自己的经验是，模块化优先于自动化。先把图元组件化，再考虑自动化。因为组件化是基础，没有组件化，自动化生成的图也是一团乱。组件化做得好，即使手动维护，成本也能降很多。

5.5 常见问题速查表

6. 工具选型与效率提升的实操心得

6.1 绘图工具的选择逻辑：从需求反推工具

工具选型没有绝对的好坏，只有适不适合。我选工具的逻辑是：先明确需求，再反推工具。需求分几个维度：是否需要多人协作、是否需要版本管理、是否需要自动化生成、是否需要嵌入文档、是否需要矢量导出。每个维度对应不同的工具特性。

如果需要多人协作和版本管理，优先选支持云端协作和版本历史的工具。如果需要自动化生成，优先选支持脚本或 API 的工具。如果需要嵌入文档，优先选支持矢量导出和透明背景的工具。如果只是个人画几张图，轻量级工具就够，不用上重型工具。

我自己的组合是：日常画图用轻量级工具，快速出图；复杂系统图用支持组件化的工具，方便复用；需要自动化的场景用脚本生成。不同场景用不同工具，不追求一个工具解决所有问题。

6.2 模板与组件库的积累方法

模板和组件库是提升效率的关键。我的做法是，每画完一张图，把里面可复用的部分抽出来，放进组件库。比如画完一张架构图，把“服务”“数据库”“网关”这些常用图元抽出来，下次画图直接拖。组件库积累到一定程度后，画新图的效率会大幅提升，因为大部分图元都是现成的，只需要排列组合。

组件库的管理要注意命名规范。组件名要能反映用途，比如“业务服务-蓝色”“数据库-绿色”，而不是“组件1”“组件2”。组件库也要定期清理，把不再使用的组件删掉，避免库太臃肿。我一般每季度清理一次，删掉三个月没用的组件。

模板方面，我一般按图表类型做模板，比如“架构图模板”“流程图模板”“时序图模板”。模板里预置好画布大小、网格、颜色、字号、图例位置，画图时直接套模板，省去设置时间。模板也要版本化，每次规范更新，模板同步更新。

6.3 快捷键与批量操作：把画图速度提上来

画图速度的提升，很大程度上靠快捷键和批量操作。我常用的快捷键包括：复制（Ctrl+C）、粘贴（Ctrl+V）、撤销（Ctrl+Z）、重做（Ctrl+Y）、编组（Ctrl+G）、取消编组（Ctrl+Shift+G）、对齐（各种对齐快捷键）。这些快捷键看起来简单，但熟练后能省大量时间。

批量操作方面，最常用的是批量改样式。比如选中所有同类元素，一次性改颜色、改字号、改线型。批量对齐也很常用，选中一组元素，一次性左对齐、上对齐、等距分布。批量操作的关键是先把元素分类选好，再统一操作，而不是一个一个改。

还有一个技巧是“格式刷”。画好一个元素后，用格式刷把它的样式复制到其他元素上，比手动设置快很多。格式刷的快捷键一般是 Ctrl+Shift+C 复制格式，Ctrl+Shift+V 粘贴格式，不同工具可能略有差异，但逻辑类似。

6.4 从手动画图到半自动生成的演进路径

手动画图适合少量、一次性的图，但如果图很多、变动频繁，手动画图就撑不住了。这时候可以考虑半自动生成。半自动生成的思路是：用结构化数据描述图的内容，用脚本把数据转成图。比如用 YAML 描述服务列表和调用关系，用脚本生成架构图。

半自动生成的好处是，数据变了重新跑脚本就行，不用手动改图。而且数据是结构化的，可以做校验，比如检查是否有孤立节点、是否有循环依赖。坏处是前期投入大，要写脚本、调样式，而且样式调整不如手动灵活。

我的建议是，先从手动画图开始，积累规范和组件库。当图的数量超过一定规模（比如 20 张以上），或者变动频率超过一定阈值（比如每周都要改），再考虑半自动生成。不要一上来就追求自动化，否则容易陷入“为了自动化而自动化”的陷阱。

7. 图表设计系统的扩展与长期维护

7.1 从单项目到跨项目的规范复用

一套图表设计系统在一个项目里跑通后，很自然会想复用到其他项目。但直接复用往往会遇到问题，因为不同项目的术语、架构、关注点不一样。我的做法是，把规范分成“通用层”和“项目层”。通用层包括颜色、线型、字号、间距这些视觉规则，跨项目通用；项目层包括元素语义表、图例定义这些跟项目相关的规则，每个项目单独定义。

通用层复用时，直接拷贝即可。项目层复用时，以通用层为基础，根据项目特点调整。比如同样是“服务”这个概念，在微服务项目里用圆角矩形，在数据项目里可能用圆柱，这没关系，只要项目内部统一就行。这样既保证了视觉一致性，又保留了项目灵活性。

跨项目复用的另一个关键是文档化。把通用层和项目层的规范都写成文档，新项目启动时直接参考文档，而不是口头传达。文档要包含示例图，让读者直观看到规范的效果。文档也要版本化，规范更新时同步更新文档。

7.2 规范迭代：什么时候该改，什么时候不该改

规范不是一成不变的，但也不能频繁改。我的原则是：影响面大的改动慎重，影响面小的改动灵活。影响面大的改动，比如改颜色语义、改形状定义，会影响所有已发布的图，改之前要评估成本，能不改就不改。影响面小的改动，比如加一个新形状、加一个新颜色，不影响已有图，可以灵活处理。

改规范的触发条件一般有三个：现有规范无法表达新概念、现有规范导致歧义、现有规范效率太低。第一个情况必须改，否则新内容没法画。第二个情况也要改，歧义是规范的大忌。第三个情况看成本，如果改动能显著提升效率，且影响面可控，就改；否则先忍着，等积累到一定程度再统一改。

改规范时要注意向后兼容。如果必须做破坏性改动，要提供迁移方案，比如旧图保持旧规范，新图用新规范，逐步过渡。不要一刀切，否则团队会抵触。

7.3 图表资产的沉淀与知识管理

图表资产是团队的宝贵财富，但很多团队没有好好管理，图散落在各个文档里，找起来很费劲。我的做法是建一个图表资产库，把所有图集中管理。资产库按项目、按类型分类，每张图有标题、描述、版本号、最后修改时间。找图时按分类找，很快就能定位。

资产库还要有搜索功能，支持按关键词搜图。比如搜“订单”，所有跟订单相关的图都列出来。搜索的关键是图的标题和描述要写清楚，不要用“图1”“图2”这种无意义的命名。我一般要求图的标题包含“主题+类型”，比如“订单服务调用关系图”“用户下单流程图”，这样搜索时容易命中。

资产库的维护也要有机制。每次新增或修改图，同步更新资产库。定期清理过期的图，避免库太臃肿。我一般每季度清理一次，把半年没访问的图归档，需要时再恢复。

7.4 我个人在实际操作中的几点体会

做了这么多年的 diagram-design，最大的体会是：图表设计的本质是信息设计，不是视觉设计。很多人把精力花在怎么让图好看上，但好看不等于好懂。一张图如果读者看不懂，再好看也是失败的。所以每次画图，我都会先问自己：这张图要回答什么问题？读者看完能回答这个问题吗？如果能，图就是成功的；如果不能，再好看也要重画。

第二个体会是：规范的价值在于执行，不在于制定。我见过很多团队花大力气制定规范，但制定完就放那儿了，没人执行。结果规范成了摆设，图还是各画各的。规范要落地，必须有 review 机制，必须有模板支持，必须有人负责检查。执行到位了，规范才有价值。

第三个体会是：工具是手段，不是目的。不要为了用某个工具而用某个工具，也不要因为某个工具流行就盲目跟风。选工具的标准只有一个：能不能高效地表达你要表达的信息。能满足这个标准的工具就是好工具，不能满足的，再流行也不用。

最后分享一个小技巧：如果你觉得画图很痛苦，不妨先停下来，用文字把要表达的内容写清楚，然后再画。文字写清楚了，图自然就清晰了。图不清晰，往往是文字没想清楚。这个技巧我用了很多次，每次都能帮我从“画不出来”的困境里走出来。