1. 从一张草图到一套系统：diagram-design 到底在解决什么问题第一次看到 “diagram-design” 这个标题，很多人会以为它只是教你怎么画流程图、时序图或者架构图。但真正做过技术方案、写过设计文档、给团队做过架构评审的人都知道，画图这件事从来不是“画得好看”这么简单。它背后牵扯的是一整套信息表达体系：用什么图表达什么关系、图里放多少信息、不同角色看图时关注什么、图怎么随着系统演进而维护。diagram-design 这个项目，本质上是在解决一个非常具体且高频的痛点——如何用一套可复用的设计方法，把复杂的系统、流程、结构，稳定地转化成别人能看懂、能评审、能落地的图。我自己的经历很典型。早些年做后端服务拆分，每次评审前都要熬夜画架构图，画完发现评审会上大家问的问题根本不在图上；后来做跨团队方案对齐，一张图改了十几版，最后没人记得哪版是最新的。问题不在于工具不好用，而在于没有一套从“信息梳理”到“图形表达”的固定套路。diagram-design 的价值就在于，它把这件事从“个人手感”变成了“可复制的流程”。这个项目适合谁？如果你属于下面几类人，它会非常有用：技术方案负责人：需要把复杂系统讲清楚，让不同背景的人达成共识。产品与设计同学：需要把业务流程、状态流转、页面关系可视化，减少沟通歧义。刚入行的开发者：面对一堆模块和接口，不知道怎么下手画第一张架构图。团队里的“文档担当”：每次都要帮别人补图，想找一套标准模板和检查清单。它不教你某个具体工具的快捷键，而是教你在动手画之前想清楚什么、画的过程中遵循什么规则、画完之后怎么验证。这套东西一旦掌握，换任何工具都能用，换任何项目都能迁移。2. 核心设计思路拆解：为什么“先想后画”比“先画后改”省三倍时间2.1 图的本质是信息压缩，不是美术创作很多人画图的第一反应是打开工具，拖几个框，连几条线。diagram-design 的第一个核心原则恰恰相反：先确定这张图要回答什么问题，再决定画什么。一张架构图如果既想展示部署拓扑，又想展示数据流向，还想展示团队边界，最后大概率是一团乱麻。因为不同的问题需要不同的抽象层级。我习惯把图分成三类，这也是项目里反复强调的：图类型回答的核心问题典型读者信息密度概念图系统由哪些部分组成，关系是什么产品、业务、新成员低，重关系逻辑图模块之间怎么调用，数据怎么流转开发、测试、架构师中，重路径物理图部署在哪，网络怎么走，依赖什么运维、SRE、安全高，重细节如果你把三类信息塞进一张图，读者会迷失。diagram-design 的做法是一张图只回答一个问题，如果确实需要多视角，就拆成多张，用统一的命名和编号关联起来。这个思路听起来简单，但实操中能坚持的人很少。我见过太多“一张图走天下”的方案，最后连作者自己都说不清某个框代表的是服务还是服务器。2.2 从“元素清单”到“关系矩阵”的推导过程确定图的目标之后，下一步不是画框，而是列元素。diagram-design 里有一个很实用的方法：先用文字把系统拆成名词和动词。名词就是候选元素，动词就是候选关系。比如“订单服务调用库存服务扣减库存”，名词是订单服务、库存服务、库存，动词是调用、扣减。这样列出来之后，你会发现有些名词其实是同一个东西的不同叫法，有些动词其实包含了多个步骤。我通常会让团队先做一张关系矩阵表，行和列都是元素，交叉点填关系类型。这个表看起来笨，但它能逼你把所有关系想清楚，避免画图时漏掉关键依赖。矩阵做完之后，图其实已经在大脑里成型了，剩下的只是把它“翻译”成图形。注意：关系矩阵不需要给所有人看，它是你自己的思考工具。但如果你跳过这一步直接画图，大概率会在评审时被问住。2.3 为什么选择“分层+分区”而不是“自由布局”diagram-design 在布局上有一个明确的倾向：分层和分区优先于自由布局。自由布局看起来灵活，但读者需要花额外认知成本去理解你的空间安排。分层（比如接入层、逻辑层、存储层）和分区（比如按业务域、按团队边界）能让读者快速建立心理模型。具体操作上，我习惯先画三条水平线，把图分成上中下三层，再画两条垂直线，分成左中右三个区。九个格子先空着，然后把元素往格子里放。放不进去的元素，要么是分类没想清楚，要么是这张图的目标太杂。这个“九宫格”方法虽然粗暴，但非常有效，尤其适合第一次画某个系统的架构图。3. 核心细节解析与实操要点：从空白画布到可评审图稿的完整路径3.1 元素命名规范：让图自己会说话图里的每个框、每条线、每个箭头，都需要命名。diagram-design 对命名有很具体的要求：框内文字用“名词+角色”：比如“订单服务（核心）”、“用户库（主）”，避免只写“订单”这种模糊词。箭头标注用“动词+关键参数”：比如“创建订单（同步）”、“推送事件（异步）”，不要只画箭头不写字。颜色和线型承载语义：实线表示同步调用，虚线表示异步消息，粗线表示关键路径，细线表示辅助关系。颜色不要超过三种，否则读者会开始猜。我踩过的一个坑是：早期喜欢用不同颜色区分团队，结果评审时大家一直在讨论颜色含义，没人关注架构本身。后来改成颜色只表示状态（正常、异常、废弃），团队边界用分区背景色表示，讨论效率明显提升。3.2 信息密度的控制：一张图放多少个元素合适这个问题没有绝对答案，但有一个经验值：一张图里的核心元素不超过 9 个，总元素不超过 15 个。超过这个数，读者就需要频繁缩放和对照，理解成本急剧上升。如果系统确实复杂，就拆成多张图，用“总览图+分图”的方式组织。总览图只放最顶层的 5 到 7 个模块，每个模块用一句话说明职责。分图再展开每个模块的内部结构。这样读者可以先看总览建立全局观，再按需深入。diagram-design 里把这叫做“渐进式披露”，和写文档的逻辑是一样的。3.3 连线规则：避免“意大利面条”的五个技巧连线是图里最容易失控的部分。我总结了五个实操技巧：同层元素之间尽量不连线，如果必须连，用弧线绕开，不要横穿其他元素。跨层连线走垂直方向，不要斜着穿过多层，否则读者会跟丢。双向关系用两条单向箭头，不要用一条双向箭头，因为双向箭头的语义太模糊。避免交叉，如果两条线必须交叉，用“跳线”符号表示不连接。关键路径加粗，辅助路径用灰色细线，让读者一眼看到主流程。这些规则看起来琐碎，但实际画的时候能帮你省下大量调整时间。我现在的习惯是：先按规则画一版，然后打印出来用笔在上面改，改完再回到工具里调整。纸质版的全局视野比屏幕好得多。3.4 图例与注释：别让读者猜每张图都应该有图例，说明颜色、线型、符号的含义。图例放在图的右下角或左下角，不要放在顶部，因为顶部通常是标题区。注释用编号标注，在图下方统一解释，不要在图里写大段文字。提示：如果你的图需要超过 5 行注释才能解释清楚，说明图本身没画好，回去重新梳理元素和关系。4. 实操过程与核心环节实现：一个模拟项目的完整画图记录4.1 项目背景与目标定义假设我们要为一个“跨平台订单处理系统”画架构图。这个系统包含订单接收、库存扣减、支付处理、通知推送四个核心模块，涉及三个团队。图的目标是：让新加入的开发和运维在 10 分钟内理解系统的核心流程和依赖关系。第一步不是画图，而是写一句话目标：“这张图要展示订单从接收到完成的核心路径，以及各模块之间的同步和异步关系。”这句话决定了图的边界——我们不展示数据库表结构，不展示部署细节，不展示团队内部实现。4.2 元素清单与关系矩阵根据目标，列出核心元素：订单接收服务库存服务支付服务通知服务消息队列订单数据库关系矩阵如下：从 \ 到订单接收库存支付通知消息队列订单库订单接收-同步调用同步调用异步消息发送事件写入库存----发送事件读写支付----发送事件读写通知----消费消息-这个矩阵一出来，图的结构就清楚了：订单接收是入口，库存和支付是同步依赖，通知是异步消费，消息队列是异步枢纽。4.3 分层布局与元素放置按三层布局：接入层：订单接收服务逻辑层：库存服务、支付服务、通知服务、消息队列存储层：订单数据库用九宫格方法，接入层放顶部中间，逻辑层放中间一排，存储层放底部中间。消息队列放在逻辑层右侧，因为它连接多个服务。订单数据库放在底部，因为多个服务都要访问它。4.4 连线与标注连线规则应用：订单接收到库存、支付：实线箭头，标注“同步调用”。订单接收到消息队列：虚线箭头，标注“发送订单事件”。库存、支付到消息队列：虚线箭头，标注“发送状态事件”。消息队列到通知：虚线箭头，标注“消费事件”。各服务到订单数据库：实线箭头，标注“读写”。关键路径（订单接收→库存→支付→消息队列→通知）用加粗线，辅助路径用细线。4.5 图例与最终检查图例说明：实线=同步调用，虚线=异步消息，粗线=关键路径，细线=辅助关系。颜色只用两种：蓝色表示正常流程，灰色表示辅助组件。最终检查清单：图是否回答了目标问题？是。元素是否超过 15 个？否，共 6 个。连线是否交叉？无交叉。图例是否清晰？是。新成员能否在 10 分钟内理解？找了一位未参与项目的同事测试，8 分钟理解核心流程。5. 常见问题与排查技巧实录：画图路上踩过的坑5.1 图太乱怎么办：从“删元素”开始图乱的第一反应通常是调整布局，但真正有效的方法是删元素。问自己：这个元素不画，读者还能理解核心问题吗？如果能，就删掉。我做过一个实验：把一张 20 个元素的图删到 8 个，评审通过率反而提高了。因为读者不再被细节干扰，能聚焦在核心关系上。5.2 评审时被问住：提前做“反向提问”评审前，找一位不了解项目的同事，让他看图后提问。他问的问题，就是评审时可能被问的问题。提前准备好答案，或者把答案补到图里。这个习惯让我在多次架构评审中避免了尴尬。5.3 图更新不及时：把图纳入版本管理图过期是常态，因为代码在变，图没人改。diagram-design 的建议是：把图源文件纳入代码仓库，和代码一起提交。每次架构变更，必须更新图，否则 PR 不通过。这个规则听起来严格，但执行三个月后，团队就习惯了。5.4 工具选择：够用就好，别折腾我用过很多画图工具，最后发现工具不是关键，方法才是。文本描述工具适合版本管理，拖拽工具适合快速出图，手绘工具适合早期讨论。我的建议是：早期讨论用手绘或白板，方案确定后用文本工具生成正式图，评审用导出图片。不要在一开始就追求完美工具，那会消耗大量时间。常见问题排查思路解决方法图太乱元素是否超过 15 个删减非核心元素读者看不懂是否缺少图例和注释补充图例，简化标注评审被问住是否提前做过反向提问找同事预审，补全信息图过期是否纳入版本管理图源文件入仓库，变更必更新连线交叉多布局是否合理调整分层分区，避免斜线5.5 独家避坑技巧：先画“错误图”这个方法很少有人提，但非常有效：先故意画一张错误的图，把常见误解画进去，然后对比正确图。这样你能提前发现读者可能误解的地方，在正式图里避免。我通常在方案讨论阶段用这招，能快速对齐认知。6. 从单张图到图体系：diagram-design 的长期价值6.1 建立团队图库：统一命名与索引单张图画得再好，如果团队里每个人画法不同，整体效率还是低。diagram-design 的长期价值在于建立团队级的图库。所有图统一命名规则，比如“系统名-视图类型-版本号”，统一存放位置，统一索引。新成员入职，先看图库，再读代码。6.2 图与文档的联动：让图成为文档的入口图不应该孤立存在。每张图都应该链接到对应的详细文档，文档里再链接回图。这样读者可以从图快速定位到细节，也可以从文档快速回到全局。我现在的习惯是：每张图下方放三个链接——相关设计文档、相关代码仓库、相关评审记录。6.3 定期复盘：图的质量反映系统的质量图乱通常意味着系统乱。如果一张架构图怎么画都画不清楚，大概率是系统本身耦合太严重。diagram-design 的一个隐藏价值是：通过画图暴露系统设计问题。我经历过一次，画图时发现两个模块之间连线太多，后来一查，果然是职责边界没划清。修好系统之后，图自然就清晰了。6.4 个人体会：画图是思考，不是表达最后分享一个我自己的体会：画图的过程比图本身更重要。很多人把画图当成“把想好的东西画出来”，但实际是“通过画图把东西想清楚”。diagram-design 教的方法，本质上是一套思考工具。你按照元素、关系、分层、连线的顺序走一遍，系统里的模糊地带会自己暴露出来。所以我的建议是：不要等想清楚了再画，而是通过画来想清楚。先画草图，再画正式图，最后用正式图去评审。这个顺序反过来，效率会高很多。另外一个小技巧：如果你画完一张图，自己看着觉得“还行”，但说不出哪里好，那大概率是没画好。真正好的图，你能用一句话说清楚它展示了什么，读者也能用一句话复述出来。如果做不到，回去重新梳理目标。
1. 从一张草图到一套系统：diagram-design 到底在解决什么问题第一次看到 “diagram-design” 这个标题，很多人会以为它只是教你怎么画流程图、时序图或者架构图。但真正做过技术方案、写过设计文档、给团队做过架构评审的人都知道，画图这件事从来不是“画得好看”这么简单。它背后牵扯的是一整套信息表达体系：用什么图表达什么关系、图里放多少信息、不同角色看图时关注什么、图怎么随着系统演进而维护。diagram-design 这个项目，本质上是在解决一个非常具体且高频的痛点——如何用一套可复用的设计方法，把复杂的系统、流程、结构，稳定地转化成别人能看懂、能评审、能落地的图。我自己的经历很典型。早些年做后端服务拆分，每次评审前都要熬夜画架构图，画完发现评审会上大家问的问题根本不在图上；后来做跨团队方案对齐，一张图改了十几版，最后没人记得哪版是最新的。问题不在于工具不好用，而在于没有一套从“信息梳理”到“图形表达”的固定套路。diagram-design 的价值就在于，它把这件事从“个人手感”变成了“可复制的流程”。这个项目适合谁？如果你属于下面几类人，它会非常有用：技术方案负责人：需要把复杂系统讲清楚，让不同背景的人达成共识。产品与设计同学：需要把业务流程、状态流转、页面关系可视化，减少沟通歧义。刚入行的开发者：面对一堆模块和接口，不知道怎么下手画第一张架构图。团队里的“文档担当”：每次都要帮别人补图，想找一套标准模板和检查清单。它不教你某个具体工具的快捷键，而是教你在动手画之前想清楚什么、画的过程中遵循什么规则、画完之后怎么验证。这套东西一旦掌握，换任何工具都能用，换任何项目都能迁移。2. 核心设计思路拆解：为什么“先想后画”比“先画后改”省三倍时间2.1 图的本质是信息压缩，不是美术创作很多人画图的第一反应是打开工具，拖几个框，连几条线。diagram-design 的第一个核心原则恰恰相反：先确定这张图要回答什么问题，再决定画什么。一张架构图如果既想展示部署拓扑，又想展示数据流向，还想展示团队边界，最后大概率是一团乱麻。因为不同的问题需要不同的抽象层级。我习惯把图分成三类，这也是项目里反复强调的：图类型回答的核心问题典型读者信息密度概念图系统由哪些部分组成，关系是什么产品、业务、新成员低，重关系逻辑图模块之间怎么调用，数据怎么流转开发、测试、架构师中，重路径物理图部署在哪，网络怎么走，依赖什么运维、SRE、安全高，重细节如果你把三类信息塞进一张图，读者会迷失。diagram-design 的做法是一张图只回答一个问题，如果确实需要多视角，就拆成多张，用统一的命名和编号关联起来。这个思路听起来简单，但实操中能坚持的人很少。我见过太多“一张图走天下”的方案，最后连作者自己都说不清某个框代表的是服务还是服务器。2.2 从“元素清单”到“关系矩阵”的推导过程确定图的目标之后，下一步不是画框，而是列元素。diagram-design 里有一个很实用的方法：先用文字把系统拆成名词和动词。名词就是候选元素，动词就是候选关系。比如“订单服务调用库存服务扣减库存”，名词是订单服务、库存服务、库存，动词是调用、扣减。这样列出来之后，你会发现有些名词其实是同一个东西的不同叫法，有些动词其实包含了多个步骤。我通常会让团队先做一张关系矩阵表，行和列都是元素，交叉点填关系类型。这个表看起来笨，但它能逼你把所有关系想清楚，避免画图时漏掉关键依赖。矩阵做完之后，图其实已经在大脑里成型了，剩下的只是把它“翻译”成图形。注意：关系矩阵不需要给所有人看，它是你自己的思考工具。但如果你跳过这一步直接画图，大概率会在评审时被问住。2.3 为什么选择“分层+分区”而不是“自由布局”diagram-design 在布局上有一个明确的倾向：分层和分区优先于自由布局。自由布局看起来灵活，但读者需要花额外认知成本去理解你的空间安排。分层（比如接入层、逻辑层、存储层）和分区（比如按业务域、按团队边界）能让读者快速建立心理模型。具体操作上，我习惯先画三条水平线，把图分成上中下三层，再画两条垂直线，分成左中右三个区。九个格子先空着，然后把元素往格子里放。放不进去的元素，要么是分类没想清楚，要么是这张图的目标太杂。这个“九宫格”方法虽然粗暴，但非常有效，尤其适合第一次画某个系统的架构图。3. 核心细节解析与实操要点：从空白画布到可评审图稿的完整路径3.1 元素命名规范：让图自己会说话图里的每个框、每条线、每个箭头，都需要命名。diagram-design 对命名有很具体的要求：框内文字用“名词+角色”：比如“订单服务（核心）”、“用户库（主）”，避免只写“订单”这种模糊词。箭头标注用“动词+关键参数”：比如“创建订单（同步）”、“推送事件（异步）”，不要只画箭头不写字。颜色和线型承载语义：实线表示同步调用，虚线表示异步消息，粗线表示关键路径，细线表示辅助关系。颜色不要超过三种，否则读者会开始猜。我踩过的一个坑是：早期喜欢用不同颜色区分团队，结果评审时大家一直在讨论颜色含义，没人关注架构本身。后来改成颜色只表示状态（正常、异常、废弃），团队边界用分区背景色表示，讨论效率明显提升。3.2 信息密度的控制：一张图放多少个元素合适这个问题没有绝对答案，但有一个经验值：一张图里的核心元素不超过 9 个，总元素不超过 15 个。超过这个数，读者就需要频繁缩放和对照，理解成本急剧上升。如果系统确实复杂，就拆成多张图，用“总览图+分图”的方式组织。总览图只放最顶层的 5 到 7 个模块，每个模块用一句话说明职责。分图再展开每个模块的内部结构。这样读者可以先看总览建立全局观，再按需深入。diagram-design 里把这叫做“渐进式披露”，和写文档的逻辑是一样的。3.3 连线规则：避免“意大利面条”的五个技巧连线是图里最容易失控的部分。我总结了五个实操技巧：同层元素之间尽量不连线，如果必须连，用弧线绕开，不要横穿其他元素。跨层连线走垂直方向，不要斜着穿过多层，否则读者会跟丢。双向关系用两条单向箭头，不要用一条双向箭头，因为双向箭头的语义太模糊。避免交叉，如果两条线必须交叉，用“跳线”符号表示不连接。关键路径加粗，辅助路径用灰色细线，让读者一眼看到主流程。这些规则看起来琐碎，但实际画的时候能帮你省下大量调整时间。我现在的习惯是：先按规则画一版，然后打印出来用笔在上面改，改完再回到工具里调整。纸质版的全局视野比屏幕好得多。3.4 图例与注释：别让读者猜每张图都应该有图例，说明颜色、线型、符号的含义。图例放在图的右下角或左下角，不要放在顶部，因为顶部通常是标题区。注释用编号标注，在图下方统一解释，不要在图里写大段文字。提示：如果你的图需要超过 5 行注释才能解释清楚，说明图本身没画好，回去重新梳理元素和关系。4. 实操过程与核心环节实现：一个模拟项目的完整画图记录4.1 项目背景与目标定义假设我们要为一个“跨平台订单处理系统”画架构图。这个系统包含订单接收、库存扣减、支付处理、通知推送四个核心模块，涉及三个团队。图的目标是：让新加入的开发和运维在 10 分钟内理解系统的核心流程和依赖关系。第一步不是画图，而是写一句话目标：“这张图要展示订单从接收到完成的核心路径，以及各模块之间的同步和异步关系。”这句话决定了图的边界——我们不展示数据库表结构，不展示部署细节，不展示团队内部实现。4.2 元素清单与关系矩阵根据目标，列出核心元素：订单接收服务库存服务支付服务通知服务消息队列订单数据库关系矩阵如下：从 \ 到订单接收库存支付通知消息队列订单库订单接收-同步调用同步调用异步消息发送事件写入库存----发送事件读写支付----发送事件读写通知----消费消息-这个矩阵一出来，图的结构就清楚了：订单接收是入口，库存和支付是同步依赖，通知是异步消费，消息队列是异步枢纽。4.3 分层布局与元素放置按三层布局：接入层：订单接收服务逻辑层：库存服务、支付服务、通知服务、消息队列存储层：订单数据库用九宫格方法，接入层放顶部中间，逻辑层放中间一排，存储层放底部中间。消息队列放在逻辑层右侧，因为它连接多个服务。订单数据库放在底部，因为多个服务都要访问它。4.4 连线与标注连线规则应用：订单接收到库存、支付：实线箭头，标注“同步调用”。订单接收到消息队列：虚线箭头，标注“发送订单事件”。库存、支付到消息队列：虚线箭头，标注“发送状态事件”。消息队列到通知：虚线箭头，标注“消费事件”。各服务到订单数据库：实线箭头，标注“读写”。关键路径（订单接收→库存→支付→消息队列→通知）用加粗线，辅助路径用细线。4.5 图例与最终检查图例说明：实线=同步调用，虚线=异步消息，粗线=关键路径，细线=辅助关系。颜色只用两种：蓝色表示正常流程，灰色表示辅助组件。最终检查清单：图是否回答了目标问题？是。元素是否超过 15 个？否，共 6 个。连线是否交叉？无交叉。图例是否清晰？是。新成员能否在 10 分钟内理解？找了一位未参与项目的同事测试，8 分钟理解核心流程。5. 常见问题与排查技巧实录：画图路上踩过的坑5.1 图太乱怎么办：从“删元素”开始图乱的第一反应通常是调整布局，但真正有效的方法是删元素。问自己：这个元素不画，读者还能理解核心问题吗？如果能，就删掉。我做过一个实验：把一张 20 个元素的图删到 8 个，评审通过率反而提高了。因为读者不再被细节干扰，能聚焦在核心关系上。5.2 评审时被问住：提前做“反向提问”评审前，找一位不了解项目的同事，让他看图后提问。他问的问题，就是评审时可能被问的问题。提前准备好答案，或者把答案补到图里。这个习惯让我在多次架构评审中避免了尴尬。5.3 图更新不及时：把图纳入版本管理图过期是常态，因为代码在变，图没人改。diagram-design 的建议是：把图源文件纳入代码仓库，和代码一起提交。每次架构变更，必须更新图，否则 PR 不通过。这个规则听起来严格，但执行三个月后，团队就习惯了。5.4 工具选择：够用就好，别折腾我用过很多画图工具，最后发现工具不是关键，方法才是。文本描述工具适合版本管理，拖拽工具适合快速出图，手绘工具适合早期讨论。我的建议是：早期讨论用手绘或白板，方案确定后用文本工具生成正式图，评审用导出图片。不要在一开始就追求完美工具，那会消耗大量时间。常见问题排查思路解决方法图太乱元素是否超过 15 个删减非核心元素读者看不懂是否缺少图例和注释补充图例，简化标注评审被问住是否提前做过反向提问找同事预审，补全信息图过期是否纳入版本管理图源文件入仓库，变更必更新连线交叉多布局是否合理调整分层分区，避免斜线5.5 独家避坑技巧：先画“错误图”这个方法很少有人提，但非常有效：先故意画一张错误的图，把常见误解画进去，然后对比正确图。这样你能提前发现读者可能误解的地方，在正式图里避免。我通常在方案讨论阶段用这招，能快速对齐认知。6. 从单张图到图体系：diagram-design 的长期价值6.1 建立团队图库：统一命名与索引单张图画得再好，如果团队里每个人画法不同，整体效率还是低。diagram-design 的长期价值在于建立团队级的图库。所有图统一命名规则，比如“系统名-视图类型-版本号”，统一存放位置，统一索引。新成员入职，先看图库，再读代码。6.2 图与文档的联动：让图成为文档的入口图不应该孤立存在。每张图都应该链接到对应的详细文档，文档里再链接回图。这样读者可以从图快速定位到细节，也可以从文档快速回到全局。我现在的习惯是：每张图下方放三个链接——相关设计文档、相关代码仓库、相关评审记录。6.3 定期复盘：图的质量反映系统的质量图乱通常意味着系统乱。如果一张架构图怎么画都画不清楚，大概率是系统本身耦合太严重。diagram-design 的一个隐藏价值是：通过画图暴露系统设计问题。我经历过一次，画图时发现两个模块之间连线太多，后来一查，果然是职责边界没划清。修好系统之后，图自然就清晰了。6.4 个人体会：画图是思考，不是表达最后分享一个我自己的体会：画图的过程比图本身更重要。很多人把画图当成“把想好的东西画出来”，但实际是“通过画图把东西想清楚”。diagram-design 教的方法，本质上是一套思考工具。你按照元素、关系、分层、连线的顺序走一遍，系统里的模糊地带会自己暴露出来。所以我的建议是：不要等想清楚了再画，而是通过画来想清楚。先画草图，再画正式图，最后用正式图去评审。这个顺序反过来，效率会高很多。另外一个小技巧：如果你画完一张图，自己看着觉得“还行”，但说不出哪里好，那大概率是没画好。真正好的图，你能用一句话说清楚它展示了什么，读者也能用一句话复述出来。如果做不到，回去重新梳理目标。