diagram-design：从画图到系统化设计图的工程实践方法论

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

第一次看到 “diagram-design” 这个标题，很多人会以为它只是教你怎么把图画得好看一点。但真正做过系统设计、写过技术方案、给团队讲过架构的人都知道，图的问题从来不只是“好不好看”。一张图背后藏着的是信息层级、阅读路径、认知负担和协作效率。图画得乱，评审时就要花二十分钟解释“这个箭头到底从哪来”；图画得清楚，五分钟就能让所有人对齐关键决策。

diagram-design 这个项目，核心就是围绕“图的设计”建立一套可复用的方法论和工具链。它要解决的不是单一软件怎么用，而是从需求梳理、结构抽象、视觉编码到最终交付的完整链路。说得直白一点，它关心的是：怎么让一张图在最短时间内把最复杂的信息讲明白，并且让不同角色的人都能看懂、能改、能维护。

这个主题适合谁？如果你是技术方案撰写者、产品经理、系统架构师、技术博主，或者任何需要频繁用图表达复杂逻辑的人，这套内容都能直接拿去用。它不要求你会画画，也不要求你精通设计软件，它要求的是你愿意把“画图”当成一项工程来做，而不是随手拖几个框就完事。

我见过太多团队在 diagram-design 上踩坑：有人用彩色渐变把架构图做成了海报，结果打印出来全是灰块；有人把所有信息塞进一张图，最后谁也不敢改；还有人每次评审都重新画一遍，因为上一版的源文件已经找不到了。这些问题看起来是工具问题，实际上是设计思路和流程规范的问题。接下来我会从整体设计思路、核心细节、实操流程和常见问题四个维度，把 diagram-design 这件事拆开讲透。

2. 内容整体设计与思路拆解

2.1 为什么 diagram-design 要先定“信息层级”再定“视觉风格”

很多人做图的第一步是打开工具，选一个模板，然后开始拖框。这个顺序在 diagram-design 里是反的。正确的顺序是：先确定这张图要回答什么问题，再确定信息层级，最后才考虑视觉风格。

我举个实际场景。假设你要画一张系统架构图，评审对象是技术负责人和运维团队。技术负责人关心的是模块边界和依赖关系，运维团队关心的是部署单元和网络分区。如果你把这两类信息混在同一层级里，图就会变得又大又乱。正确的做法是：先画一张逻辑架构图，只保留模块和依赖；再画一张部署架构图，只保留节点和网络。两张图各自回答一个问题，而不是一张图回答所有问题。

这个思路背后的逻辑是认知负荷理论。人的工作记忆一次只能处理四到七个信息块。一张图如果同时呈现模块、协议、端口、部署区域、数据流向、安全边界，读者的工作记忆会瞬间过载，结果就是“看了半天不知道重点在哪”。diagram-design 的核心原则之一就是：一张图只讲一件事，其他信息用分层或链接的方式延展。

那怎么判断信息层级是否合理？我常用的方法是“三秒测试”：把图给一个没参与项目的同事看三秒，然后问他“这张图在讲什么”。如果他说不出来，说明信息层级有问题。这个测试听起来很粗糙，但实测下来非常有效，尤其是在评审前自查的时候。

2.2 工具选型：为什么我不推荐一上来就用重型设计软件

diagram-design 的工具选型有一个基本原则：图的维护成本必须低于它的沟通收益。如果一张图改一次要花半小时，那它很快就会被抛弃。所以我在工具选型上通常分三档。

第一档是文本驱动型工具，比如用代码描述图结构的方案。这类工具的优势是版本可控、diff 清晰、适合多人协作。缺点是学习曲线陡，调整布局不够直观。第二档是轻量级绘图工具，适合快速出草图、做评审稿。第三档才是重型设计软件，适合最终交付物需要极高视觉精度的场景，比如对外宣传材料或印刷品。

我自己的习惯是：内部评审一律用文本驱动或轻量级工具，因为评审阶段图会频繁改动，重工具反而拖慢节奏。只有最终定稿需要对外展示时，才会花时间做视觉精修。这个策略帮我省下了大量重复劳动。

这里有一个容易被忽略的点：工具选型要考虑“谁需要改这张图”。如果图只有你一个人维护，那选你顺手的就行。但如果图需要产品、开发、测试多方共同维护，那就要选一个大家都能上手的工具，哪怕它看起来不够高级。我见过一个团队用了一款非常专业的绘图软件，结果只有一个人会用，其他人提修改意见只能截图加批注，最后图更新滞后了两个月，直接失去了参考价值。

2.3 视觉编码：颜色、形状、线条到底该怎么用

diagram-design 里最容易被滥用的就是颜色。很多人觉得颜色越多越专业，实际上颜色是最稀缺的视觉资源。我的原则是：一张图的主色不超过三种，每种颜色必须对应一个明确的语义。

比如在架构图里，蓝色代表计算服务，绿色代表数据存储，灰色代表外部依赖。这个映射关系一旦确定，整张图甚至整个项目文档里都要保持一致。这样读者看第二张图的时候，不需要重新学习颜色含义，认知负担会大幅降低。

形状也是同理。矩形代表服务，圆柱代表数据库，菱形代表决策点，圆角矩形代表外部系统。这些约定不需要多新奇，关键是稳定。我见过有人为了“好看”把数据库画成六边形，结果读者第一眼根本没认出来那是什么。

线条的用法更讲究。实线代表同步调用，虚线代表异步消息，粗线代表主链路，细线代表辅助链路。如果一张图里所有线条都一样粗、一样实，那读者就无法判断哪些是核心路径。我的经验是：主链路最多三条，超过三条就说明这张图该拆了。

注意：颜色和形状的语义映射一旦确定，就要写进团队的设计规范文档里。否则每个人按自己的习惯画，图与图之间就无法对齐。

2.4 从“画图”到“设计图”：思维模式的转变

diagram-design 最核心的转变，是把“画图”当成一次性任务，变成“设计图”当成一套可迭代的系统。画图是一次性的，画完就完了；设计图是有生命周期的，需要版本管理、需要评审记录、需要和代码或文档保持同步。

这个转变带来的第一个变化是：你会开始给图写“元信息”。比如这张图的作者是谁、最后更新是什么时候、对应的需求文档链接在哪里、下一版计划改什么。这些信息看起来琐碎，但在团队协作里能救命。我曾经遇到过一次线上故障复盘，需要确认三个月前的架构图是否准确，结果发现图没有版本记录，谁也不知道当时改了什么，最后只能靠翻聊天记录拼凑。

第二个变化是：你会开始考虑图的“可修改性”。一张图如果只有原作者能改，那它就是死图。好的 diagram-design 应该让任何一个了解背景的人都能在十分钟内完成一次小修改。这就要求图层命名清晰、分组合理、样式统一，而不是把所有元素堆在一个图层里靠肉眼找。

3. 核心细节解析与实操要点

3.1 信息抽象：怎么从一堆需求里提炼出图的结构

做 diagram-design 最难的从来不是画，而是决定画什么。我常用的方法是“三步抽象法”。

第一步是列实体。把系统里所有名词列出来，比如用户、订单、支付服务、库存服务、消息队列、数据库。这一步不设限制，想到什么列什么。

第二步是定关系。把实体之间的动词找出来，比如“用户提交订单”“订单调用支付服务”“支付成功后发送消息”。这一步的关键是只保留核心关系，辅助关系先放一边。

第三步是分层级。把实体按重要性分成核心层、支撑层和外部层。核心层是这张图的主角，支撑层是配角，外部层是背景。分层之后，图的结构自然就出来了。

这个方法听起来简单，但实操时最容易犯的错误是“舍不得删”。很多人觉得每个细节都重要，结果图越画越大。我的经验是：第一版图只保留核心层和直接相关的支撑层，外部层用文字说明代替。如果评审时有人问“为什么没有画某某模块”，再决定是否加进去。这样能保证图始终聚焦在核心问题上。

3.2 布局算法：为什么手动排版永远比自动布局更可靠

现在很多绘图工具都提供自动布局功能，一键就能把图排得整整齐齐。但我在 diagram-design 里几乎不用自动布局，原因很简单：自动布局优化的是“不重叠”，而不是“好阅读”。

自动布局的算法通常基于力导向或层次布局，它会把节点均匀分布，减少连线交叉。但人的阅读习惯是从左到右、从上到下，而且对对称和分组有天然偏好。自动布局出来的图往往看起来“均匀但无重点”，读者需要花额外时间找入口。

我的做法是：先用自动布局生成一个基础版本，然后手动调整。调整的重点有三个。第一，把核心节点放在视觉中心或左上角，因为这是读者第一眼会看的位置。第二，把相关节点聚成组，用背景框或留白区分，而不是靠连线区分。第三，把主链路拉直，减少不必要的转折，让读者的视线能顺着主链路自然流动。

手动排版确实更费时间，但一张核心架构图的生命周期通常是几个月甚至几年，多花半小时排版换来的是几百次阅读的顺畅，这笔账怎么算都划算。

3.3 文字标注：图上的字到底该写多少

diagram-design 里有一个经典矛盾：字写少了看不懂，字写多了图就变成文档。我的原则是：图上只写“标识性文字”，解释性文字放到图外。

标识性文字包括节点名称、关键参数、版本号。比如“订单服务 v2.3”“超时时间 3s”“QPS 上限 5000”。这些文字是读者理解图结构的必要信息，必须写在图上。

解释性文字包括设计理由、历史背景、替代方案。比如“为什么选择消息队列而不是直接调用”“这个模块上一版有什么问题”。这些内容应该放在图下方的说明区，或者链接到独立文档。如果硬塞进图里，图会变得极其臃肿，而且每次修改都要调整文字框大小，维护成本极高。

我自己的习惯是：图上的文字不超过两行，每行不超过十五个字。超过这个限制，就说明这个信息应该被拆出去。这个规则听起来很死板，但执行下来效果很好，尤其是当图需要在手机或投影仪上展示时，小字根本看不清。

3.4 版本管理：图也需要像代码一样管理

diagram-design 的版本管理经常被忽略，但它直接决定了图能不能长期使用。我的做法是：每张正式发布的图都对应一个版本号，版本号写在图的右下角。同时维护一个变更记录表，记录每次修改的内容、原因和负责人。

变更记录表不需要很复杂，一个简单的表格就够了。比如：

这个表格看起来简单，但在实际项目里能解决大问题。比如新人入职时，可以通过变更记录快速了解系统演进过程；比如故障复盘时，可以确认当时的架构状态；比如评审时，可以避免重复讨论已经改过的方案。

提示：如果图是用文本驱动工具生成的，版本管理可以直接复用代码仓库的提交记录，不需要额外维护表格。这也是我推荐文本驱动工具的原因之一。

4. 实操过程与核心环节实现

4.1 从零开始画一张系统架构图的完整流程

假设现在要为一个模拟项目画一张系统架构图，项目是一个跨平台的订单处理系统。我会按以下步骤操作。

第一步，明确图的用途和读者。这张图是给技术评审用的，读者是开发团队和运维团队。所以图需要包含模块划分、依赖关系、部署单元和关键中间件。

第二步，列出所有实体。用户端、API 网关、订单服务、支付服务、库存服务、消息队列、订单数据库、缓存、日志服务、监控服务。一共十个实体。

第三步，确定核心链路。用户端到 API 网关到订单服务到支付服务和库存服务，支付成功后通过消息队列通知其他服务。这条链路是图的主线。

第四步，分层布局。把 API 网关放在最左侧，订单服务放在中心，支付服务和库存服务放在订单服务右侧，消息队列放在下方，数据库和缓存放在订单服务下方，日志和监控放在最底部作为支撑层。

第五步，添加视觉编码。订单服务用蓝色矩形，数据库用蓝色圆柱，消息队列用绿色圆角矩形，外部依赖用灰色。主链路用粗实线，异步消息用虚线。

第六步，标注关键信息。在 API 网关上标注“限流 1000 QPS”，在订单服务上标注“v2.3”，在消息队列上标注“Kafka 3.0”，在数据库上标注“MySQL 8.0 主从”。

第七步，自查和评审。用三秒测试确认图的核心信息是否清晰，然后发给团队评审。

这个流程走下来，一张图的初稿大概需要四十分钟到一个小时。其中布局和视觉编码占的时间最多，但这两步也是最值得花时间的。

4.2 参数计算：怎么确定图上的关键数值

diagram-design 里经常需要在图上标注关键参数，比如 QPS、超时时间、容量上限。这些数值不能随便写，需要有计算依据。

以 QPS 为例。假设订单系统日均订单量是 100 万，流量集中在早八点到晚十点，共 14 个小时。平均 QPS 是 1000000 除以 14 除以 3600，约等于 20。但峰值 QPS 通常是平均值的五到十倍，所以峰值 QPS 大约在 100 到 200 之间。考虑到未来半年的业务增长，按两倍冗余设计，图上标注的限流阈值可以设为 500 QPS。

这个计算过程不需要写在图上，但你自己心里要有数。因为评审时一定会有人问“为什么是 500 而不是 1000”，如果你能当场说出计算逻辑，评审效率会高很多。

超时时间的计算也是同理。比如订单服务调用支付服务，支付服务的 P99 响应时间是 800 毫秒，那么订单服务的超时时间至少应该设为 1.5 秒到 2 秒，留出网络抖动和重试的余量。如果设成 500 毫秒，那大量正常请求都会被误判为超时。

注意：图上的参数是给读者看的，不是给自己看的。所以只标注对理解系统行为有影响的参数，不要把所有配置都堆上去。

4.3 实操现场：一次架构图评审的完整记录

我记录过一次典型的架构图评审过程，这里分享出来供参考。

评审开始，我先用两分钟介绍图的背景和阅读方式。然后进入提问环节。第一个问题是“为什么订单服务和库存服务之间没有直接调用，而是通过消息队列”。我解释说，订单创建和库存扣减需要解耦，避免库存服务故障导致订单无法创建。消息队列在这里起到缓冲和异步的作用。

第二个问题是“缓存和数据库的一致性怎么保证”。我在图上补充了一个标注，说明缓存采用先更新数据库再删除缓存的策略，并且设置了短暂的过期时间作为兜底。

第三个问题是“日志服务和监控服务为什么放在最底部”。我解释说，它们是支撑层，不参与核心业务链路，放在底部是为了避免干扰主链路的阅读。

整个评审持续了四十分钟，图修改了三个地方。修改后的版本号从 v1.0 升到 v1.1，变更记录同步更新。这个过程看起来很繁琐，但正是这些细节让图真正成为团队共识的载体，而不是某个人电脑里的一个文件。

4.4 从架构图到流程图：不同图类型的实操差异

diagram-design 不只包括架构图，还包括流程图、时序图、状态图、部署图等。不同类型的图，实操要点差异很大。

流程图的重点是分支和异常。很多人画流程图只画正常路径，异常路径全部省略。结果开发时遇到异常情况才发现没有定义。我的做法是：正常路径用主色，异常路径用灰色虚线，并且每个异常路径都要标注处理方式。

时序图的重点是顺序和并发。时序图最容易犯的错误是把所有调用都画成串行，忽略了可以并行的部分。我的做法是：用不同的垂直泳道区分服务，并行的调用画在同一水平线上，让读者一眼就能看出哪些步骤可以同时进行。

状态图的重点是边界和转换条件。状态图最容易漏掉的是异常状态和超时状态。我的做法是：先把所有正常状态列出来，再逐个问“如果在这个状态超时了会怎样”“如果在这个状态收到非法请求会怎样”，把异常状态补全。

部署图的重点是网络分区和节点规格。部署图不需要画得太细，但网络分区和节点数量必须准确。我的做法是：用背景框区分不同的网络区域，每个节点标注实例数量和规格，比如“订单服务 4 核 8G 乘以 3 实例”。

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

5.1 图太乱看不清：从信息过载到分层拆解

图太乱是 diagram-design 里最常见的问题。症状是：一张图里有几十个节点、上百条连线，读者看了三分钟还不知道重点在哪。

排查思路分三步。第一步，数节点。如果节点超过十五个，基本可以确定需要拆图。第二步，数连线。如果连线超过节点数的两倍，说明关系太复杂，需要抽象。第三步，找主线。如果找不到一条清晰的主链路，说明图的结构有问题。

解决方法通常是分层拆解。把一张大图拆成三张小图：一张总览图，只画核心模块和主链路；一张详细图，画某个核心模块的内部结构；一张部署图，画物理部署和网络分区。三张小图各自回答一个问题，通过链接互相引用。

我自己的经验是：总览图的节点控制在七个以内，详细图的节点控制在十二个以内，超过这个数量就继续拆。这个数字不是绝对的，但可以作为参考。

5.2 图改不动：源文件管理和协作规范

图改不动的原因通常有两个：源文件丢失或源文件只有一个人能改。

源文件丢失的预防方法是：所有正式发布的图都必须保留源文件，并且源文件要和项目文档放在同一个仓库里。如果图是用文本驱动工具生成的，源文件就是代码文件，天然跟着代码仓库走。如果图是用绘图工具生成的，源文件要导出为可编辑格式，不要只保留图片。

源文件只有一个人能改的预防方法是：制定协作规范，包括图层命名规则、样式统一规则、分组规则。比如所有节点必须放在名为“nodes”的图层组里，所有连线必须放在名为“edges”的图层组里，所有文字标注必须使用统一的字体和字号。这些规则看起来琐碎，但能大幅降低协作成本。

提示：如果团队里只有一个人会用某个工具，那这个工具就不适合作为团队的标准工具。工具的选择权应该交给最需要改图的人，而不是最会画图的人。

5.3 图与代码不一致：同步机制和检查清单

图与代码不一致是技术文档的经典问题。架构图里画了缓存层，代码里其实已经去掉了；时序图里画了三个服务调用，代码里已经合并成两个了。这种不一致会让图失去信任，最终没人再看。

解决方法是建立同步机制。我的做法是：每次代码合并请求涉及架构变更时，必须同时更新对应的图。这个规则写进团队的开发规范里，并且在合并请求模板里加一个检查项：“本次变更是否影响架构图？如果是，请附上更新后的图链接。”

另外，每个季度做一次图的全量审查。把所有正式发布的图过一遍，对照当前代码和部署状态，确认是否一致。不一致的地方要么更新图，要么标注“已废弃”。这个审查不需要很频繁，但必须有，否则图会慢慢腐烂。

5.4 常见问题速查表

5.5 独家避坑技巧：我踩过的那些坑

第一个坑是“过度设计”。刚开始做 diagram-design 的时候，我喜欢把图做得非常精美，加阴影、加渐变、加图标。结果每次修改都要花大量时间调整样式，而且打印出来效果很差。后来我学乖了，内部评审图一律用最朴素的样式，黑白灰加一个主色，把精力放在信息结构上。

第二个坑是“忽略读者”。我曾经画过一张自认为很清晰的图，结果评审时有人问“这个箭头是什么意思”。我才发现，我用的箭头样式在团队里没有约定，每个人理解都不一样。从那以后，我每次画图都会在图的角落加一个图例，说明颜色、形状和线条的含义。

第三个坑是“不写变更记录”。有一次故障复盘，需要确认三个月前的架构状态，结果发现图改了但没记录，谁也不知道当时是什么样。从那以后，我强制自己每次改图都更新变更记录，哪怕只是改了一个字。

第四个坑是“用图代替文档”。我曾经试图把所有的设计细节都塞进一张图里，结果图变得巨大无比，没人看得下去。后来我明白，图的作用是建立整体认知，细节应该交给文档。图和文档是互补关系，不是替代关系。

6. 不同场景下的 diagram-design 实践差异

6.1 技术方案评审场景：图和文档怎么配合

技术方案评审是 diagram-design 最常用的场景。这个场景的特点是：读者专业、时间有限、需要快速对齐关键决策。

我的做法是：评审材料由三部分组成。第一部分是一张总览图，放在最前面，让读者在三十秒内建立整体认知。第二部分是若干张详细图，每张图对应一个关键设计点，比如数据模型、接口设计、部署方案。第三部分是文字说明，补充图里放不下的背景信息和替代方案对比。

图和文档的配合原则是：图负责“是什么”，文档负责“为什么”。图让读者快速看到结构，文档让读者理解设计理由。如果图里塞了太多“为什么”，图会变得臃肿；如果文档里没有图，读者需要花大量时间在脑中构建结构。

注意：评审图不要追求完美。评审的目的是发现问题，不是展示设计能力。图越早拿出来，越容易改。

6.2 新人入职培训场景：怎么用图降低理解成本

新人入职时，最痛苦的事情是面对一堆文档不知道从哪看起。diagram-design 在这个场景下能发挥巨大作用。

我的做法是：为新入职的同事准备一套“学习路径图”。第一张是系统总览图，标注核心模块和主链路。第二张是模块依赖图，标注每个模块的上下游关系。第三张是部署图，标注环境划分和发布流程。三张图配合一份简短的文字说明，新人可以在半天内建立对系统的整体认知。

这个场景下的图有一个特殊要求：必须标注“阅读顺序”。比如在图上用数字标注 1、2、3，告诉读者先看哪里再看哪里。这个细节看起来很小，但对新人非常友好。

6.3 故障复盘场景：怎么用图还原时间线

故障复盘是 diagram-design 的另一个重要场景。这个场景的特点是：需要精确还原时间线、需要标注关键决策点、需要区分事实和推测。

我的做法是：用一张时序图还原故障过程。横轴是时间，纵轴是服务。每个关键事件标注时间戳和现象，比如“10:03 订单服务响应时间上升”“10:05 监控告警触发”“10:08 运维介入排查”。关键决策点用不同颜色标注，比如“10:10 决定回滚”“10:15 决定扩容”。

这个场景下的图有一个特殊要求：必须区分事实和推测。事实用实线，推测用虚线。比如“订单服务响应时间上升”是监控数据，用实线；“可能是数据库连接池耗尽”是推测，用虚线。这样复盘时大家能清楚知道哪些是确定的，哪些还需要验证。

6.4 对外分享场景：怎么让图在脱离上下文后依然可读

对外分享场景包括技术博客、会议演讲、公开文档。这个场景的特点是：读者没有项目背景，图需要独立可读。

我的做法是：对外分享的图必须包含“自解释元素”。包括标题、图例、关键参数标注、版本信息。标题要说明这张图讲什么，图例要说明颜色和形状的含义，关键参数要标注数值和单位，版本信息要标注更新日期。

另外，对外分享的图要控制信息密度。内部评审图可以复杂一些，因为读者有背景知识。对外分享图要更简洁，因为读者需要从零开始理解。我的经验是：对外分享图的节点数量控制在十个以内，连线数量控制在十五条以内。

7. 工具链与自动化：让 diagram-design 可持续

7.1 文本驱动工具的核心优势

文本驱动工具是 diagram-design 里最值得投入的方向。它的核心优势是：图的结构用文本描述，文本可以版本控制、可以 diff、可以代码审查。

我自己的实践是：用文本描述图的结构，然后用工具生成图片。这样每次修改只需要改几行文本，生成的图片自动更新。更重要的是，文本可以放在代码仓库里，和代码一起做合并请求审查。架构变更时，代码和图在同一个合并请求里审查，天然保证一致性。

文本驱动工具的缺点是布局控制不够精细。但我的经验是：内部评审图对布局精度的要求并不高，清晰比精美更重要。只有对外分享图才需要精细调整布局，这时候可以导出文本生成的图，再用绘图工具做视觉精修。

7.2 自动化检查：怎么保证图的质量

diagram-design 的自动化检查包括三个层面。

第一个层面是语法检查。如果图是用文本描述的，可以在合并请求里加一个检查步骤，确认文本语法正确、能正常生成图片。这个检查可以防止因为语法错误导致图无法生成。

第二个层面是一致性检查。比如检查图里的服务名称是否和代码仓库里的服务列表一致，检查图里的版本号是否和最新发布版本一致。这个检查需要一些定制脚本，但能有效防止图与代码不一致。

第三个层面是视觉检查。比如检查图里是否有重叠的节点、是否有超出画布的连线、是否有字号过小的文字。这个检查比较难自动化，但可以用一些简单的规则做初步筛查。

提示：自动化检查不需要一步到位。先从最简单的语法检查开始，跑通之后再逐步增加检查项。

7.3 模板化：怎么让不同的人画出风格一致的图

模板化是保证 diagram-design 一致性的关键。我的做法是：为每种图类型准备一个模板，模板里预定义好颜色、形状、字体、图例位置、版本号位置。

比如架构图模板里，预定义蓝色矩形代表服务、蓝色圆柱代表数据库、绿色圆角矩形代表消息队列、灰色矩形代表外部依赖。模板里还预定义好图例的位置和格式，以及版本号的位置和格式。

模板化的好处是：任何人用模板画图，出来的风格都是一致的。评审时不需要花时间适应不同的视觉风格，可以直接关注内容。新人入职时也不需要学习复杂的样式规则，直接用模板就行。

模板的维护也很重要。每次发现新的通用需求，比如需要增加一种新的节点类型，就更新模板。模板更新后，新画的图自动使用新模板，旧图可以按需迁移。

8. 我个人的实操体会

diagram-design 这件事，我做了很多年，踩过的坑比画过的图还多。最大的体会是：图的质量不取决于你用了多好的工具，而取决于你有没有想清楚这张图要回答什么问题。想清楚了，用最简单的工具也能画出清晰的图；想不清楚，用再高级的工具也是白搭。

另一个体会是：图是需要维护的。很多人把图画完就扔在那里，觉得任务完成了。但实际上，图的生命周期才刚刚开始。一张没有人维护的图，三个月后就会变成误导人的信息。所以我现在画图，一定会同时考虑“这张图以后谁来改”“改了之后怎么同步”。如果这两个问题没有答案，我宁可不画。

最后一个体会是：图不是越多越好。我见过一些团队，每个模块都画图，结果图的总数超过一百张，没人知道哪张是最新的。我的做法是：只画核心图，辅助信息用文字说明。核心图控制在十张以内，每张图都有明确的负责人和更新机制。这样图才能真正成为团队的知识资产，而不是信息垃圾。

如果你刚开始做 diagram-design，我的建议是从一张图开始。选一个你最熟悉的系统，按上面的流程画一张架构图，然后用三秒测试检验一下。如果三秒测试通过，说明你已经入门了。如果不通过，就继续调整信息层级，直到通过为止。这个过程可能需要反复几次，但每一次调整都会让你对“什么是清晰的图”有更深的理解。