1. 从“diagram-design”这个标题里能读出什么第一次看到“diagram-design”这个标题，我脑子里蹦出来的不是某个具体工具，而是一类非常典型的工作场景：手里有一堆零散的信息——业务流程、系统模块、数据流向、组织关系——需要把它们变成一张别人能看懂的图。这件事听起来简单，做起来要命。我见过太多人画图的方式是打开一个绘图工具，拖几个框，连几条线，然后开始纠结“这个框要不要加阴影”“箭头用实心还是空心”“颜色配什么好看”。折腾两小时，图没画完，信息倒是丢了一半。“diagram-design”这个标题的核心，其实不是“画图”，而是“设计图”。画图是把信息摆上去，设计图是让信息自己会说话。这两者的差距，大概就是“把菜炒熟”和“做一道让人记住的菜”之间的差距。我写这篇东西，就是想把这几年在各类项目里画图、改图、被图坑、又靠图救场的经验整理出来，给那些需要频繁用图来表达复杂信息的人——产品经理、技术文档写作者、系统架构师、咨询顾问、甚至是要做答辩PPT的学生——一份能直接上手用的参考。关键词和摘要描述虽然没给，但从标题本身能拆出几个核心方向：图的类型选择、信息层级设计、视觉编码规则、工具链搭配、以及最容易被忽略的“图的生命周期管理”。这些方向我会在下面逐个展开，不搞理论堆砌，只讲我实际用过、踩过、验证过的东西。2. 先想清楚图的“任务”，再动手选类型2.1 图不是装饰品，它承担的是“认知压缩”任务很多人画图之前不思考一个问题：这张图到底是给谁看的，看完之后要做什么决策？我见过一个典型反面案例：某团队做系统重构，架构师画了一张巨详细的部署图，节点、端口、中间件版本全标上了，结果拿去给业务方评审，业务方看了五分钟问了一句“所以我们的订单流程到底变了没有”。问题不在图本身，在于图的“任务”和观众的“需求”错位了。图的核心价值是认知压缩——把一大段文字描述才能说清的关系，压缩成一眼能扫完的视觉结构。但压缩是有损的，你必须决定丢掉什么、保留什么。这个决策的依据就是：观众看完图之后要做什么。如果观众要做技术评审，那端口和版本不能丢；如果观众要理解业务变化，那流程节点和触发条件才是重点，部署细节反而是噪音。我自己的习惯是，动手之前先写一句话：“这张图要让[谁]在[什么场景]下看懂[什么关系]，以便做出[什么决策]。”这句话写不出来，图就别画了，画了也是白画。2.2 常见图类型的适用边界与误用场景下面这张表是我根据实际项目经验整理的，列出了几种高频图类型的真实适用场景和常见误用：图类型最适合表达的关系常见误用我的使用建议流程图步骤顺序、条件分支、角色分工把并行关系画成串行，导致读者误判耗时泳道图优先，角色维度比步骤维度更重要架构图模块边界、依赖方向、层次划分把所有组件平铺，看不出主次分层画，每层不超过7个元素时序图交互顺序、消息传递、超时处理把异常分支全画进去，图变成蜘蛛网主流程一张，异常流程单独一张状态机图状态迁移、触发条件、终态状态和动作混在一起，分不清哪个是哪个状态用圆角矩形，动作标在箭头上数据流图数据来源、加工节点、存储位置把控制流和数据流画在一起数据流图只画数据，控制逻辑另开一张思维导图发散思考、层级归类、头脑风暴当成正式交付物，缺乏精确性只用于个人整理，对外交付要转成结构化图这张表里的每一条都是我踩过坑之后总结的。比如“架构图每层不超过7个元素”这条，来源于一次惨痛经历：我曾经画过一张包含23个模块的架构图，自以为很全面，结果评审会上没人能记住任何一个模块的名字。后来我把它拆成三张图——核心链路一张、支撑服务一张、数据层一张——每张不超过7个元素，评审效率直接翻倍。2.3 一个判断图类型是否选对的简单测试我有个土办法测试图类型选得对不对：把图拿给一个不熟悉项目的人看30秒，然后让他用自己的话复述图里表达的核心关系。如果他能说出“A依赖B，B在C之后发生”这类结构信息，说明图选对了；如果他只能说“有很多框和线”，那要么图太复杂，要么类型选错了。这个测试的关键在于“30秒”和“用自己的话”。30秒逼着你做减法，用自己的话逼着你检查信息是否真的被传递了。我试过很多次，凡是通不过这个测试的图，回去改完之后质量都会上一个台阶。3. 信息层级设计：让读者的眼睛知道先看哪里3.1 视觉权重的分配逻辑一张图里，每个元素的视觉权重应该和它的信息重要性成正比。这话听起来像废话，但实际操作中，大部分人会把所有框画成一样大、所有线画成一样粗、所有颜色用同一个色系。结果就是读者的眼睛在图上乱窜，找不到入口。我的做法是给每个元素打一个“重要性分数”，然后按分数分配视觉权重。具体规则如下：核心节点（分数8-10）：最大尺寸、最深填充色、最粗边框。一张图里这类节点不超过3个。支撑节点（分数5-7）：中等尺寸、浅填充色、常规边框。数量控制在7个以内。辅助节点（分数1-4）：最小尺寸、无填充或极浅填充、细边框或虚线边框。可以多一些，但要用分组框圈起来。这个规则背后的逻辑是视觉搜索效率。人眼在扫视一张图时，会优先被高对比度、大面积、深色的元素吸引。如果你把所有元素都做成高对比度，等于没有对比度，眼睛就失去了导航。我见过一个反例：某项目的业务架构图，把“用户”这个节点画得和“日志服务”一样大，颜色也一样。结果评审时，业务方第一眼看到的是“日志服务”，因为它在图的正中间。这就是视觉权重分配失败的典型。3.2 分组与边界的画法细节分组框（也叫容器、泳道、边界框）是diagram-design里最容易被低估的工具。很多人画分组框就是画一个矩形把几个元素圈起来，标个名字完事。但分组框的视觉设计直接影响读者对“边界”的理解。我的经验是，分组框要满足三个条件才算合格：边界清晰但不抢眼：边框用浅灰或浅蓝，线宽1px，填充色比背景色深一点点就行。分组框是“背景”，不是“前景”。标签位置固定：统一放在左上角，字号比节点文字小一号，颜色用中灰。不要一会儿放上面一会儿放下面。嵌套层级不超过两层：分组框套分组框，最多两层。三层以上读者就晕了，这时候应该考虑拆图。还有一个细节：分组框之间的间距要大于分组框内部元素之间的间距。这是格式塔心理学里的“接近性原则”——人眼会自动把距离近的元素归为一组。如果你把两个分组框贴得太近，读者会误以为它们是一体的。3.3 连线不是越短越好新手画图有个执念：连线越短越好，最好所有节点都紧挨着。但实际上，连线太短会导致两个问题：一是箭头方向看不清，二是交叉线难以避免。我的做法是给连线留出“呼吸空间”。具体来说：相邻节点之间的连线，至少留出节点宽度1.5倍的距离。跨分组的连线，走线要绕开分组框的标签区域。如果两条线必须交叉，在交叉点画一个“跳线”符号（半圆弧），而不是直接十字交叉。这些细节看起来微不足道，但实际评审时，一张连线清晰的图能节省大量解释时间。我曾经对比过两版架构图，内容完全一样，只是连线方式不同，第二版因为加了跳线和呼吸空间，评审时间从40分钟缩短到15分钟。4. 视觉编码规则：颜色、形状、线型的系统化用法4.1 颜色不是用来“好看”的，是用来“分类”的我见过太多人画图时凭感觉选颜色，结果一张图里出现了七八种颜色，每种颜色代表什么全靠猜。颜色在diagram-design里的核心功能是分类编码，不是装饰。我的颜色使用规则很简单：主色不超过3种：一种用于核心元素，一种用于支撑元素，一种用于辅助元素。每种颜色只表达一个维度：比如蓝色表示“服务”，绿色表示“数据”，橙色表示“外部系统”。不要用蓝色既表示服务又表示正常状态。颜色要有语义联想：红色表示警告或错误，绿色表示正常或成功，灰色表示禁用或废弃。这些约定俗成的联想不要随意打破。考虑色盲友好：大约8%的男性有红绿色盲，所以不要只靠红绿来区分关键信息。可以搭配形状或线型来双重编码。我自己的配色方案通常是：深蓝（核心）、中灰（支撑）、浅灰（辅助）、橙色（外部依赖）、红色（异常路径）。这套方案用了好几年，在各种投影仪和打印环境下都验证过，清晰度足够。4.2 形状的语义约定形状在diagram-design里承担的是“类型标识”功能。不同形状代表不同类别的元素，读者看到形状就能预判这个元素的属性。下面是我常用的形状语义表：形状语义使用场景矩形普通节点、服务、模块最通用的形状，用于大多数元素圆角矩形状态、阶段状态机图、生命周期图菱形判断、条件分支流程图中的决策点圆柱体数据存储、数据库数据流图、架构图云形外部系统、第三方服务架构图、集成图人形角色、用户、外部参与者用例图、泳道图虚线框可选、废弃、规划中架构演进图、路线图这套约定不是强制标准，但一旦你在一个项目里用了，就要在所有图里保持一致。我见过一个团队，同一个项目里有的图用圆柱体表示数据库，有的图用矩形表示数据库，结果新成员入职时看图画了两天才搞明白。4.3 线型的表意功能线型（实线、虚线、点线、粗细）在diagram-design里经常被浪费。很多人所有线都用实线，导致图里丢失了一个重要的信息维度。我的线型使用规则：实线：强依赖、主流程、同步调用。虚线：弱依赖、异步调用、可选路径。点线：数据流、事件通知、非阻塞消息。粗线：关键路径、高频调用、核心链路。带箭头的线：有方向的关系。没有方向的关联用无箭头线。这些规则组合起来，一张图能承载的信息量会大幅提升。比如“服务A通过异步消息通知服务B”这个关系，用点线加箭头就能表达，不需要额外写文字说明。5. 工具链的选择与搭配：没有万能工具，只有组合拳5.1 不同阶段的工具选择逻辑画图不是一步到位的事，它通常经历“草稿→细化→定稿→维护”四个阶段。每个阶段对工具的需求完全不同：草稿阶段：需要的是速度，不是美观。我通常用纸笔或者最简单的白板工具，几分钟画完，重点是理清思路。细化阶段：需要的是结构化编辑能力。这时候我会用支持自动布局的工具，比如基于文本描述的绘图方案，改一个节点位置，连线自动调整。定稿阶段：需要的是精确控制和导出质量。这时候用矢量绘图工具，手动调整每个元素的位置和样式。维护阶段：需要的是版本管理和协作能力。图要能跟着代码或文档一起更新，不能画完就锁死在PPT里。这个阶段划分很重要，因为很多人用定稿阶段的工具画草稿，结果在“这个框放左边还是右边”上纠结半小时。我的建议是：草稿阶段用最糙的工具，定稿阶段用最精细的工具，不要混用。5.2 文本驱动绘图方案的实际体验这几年我越来越倾向于用文本描述来生成图，而不是直接拖拽。原因很简单：文本可以版本控制，可以diff，可以review。拖拽出来的图，改一个地方要重新对齐所有元素，而且没法追踪“谁在什么时候改了什么”。文本驱动绘图的典型工作流是这样的：# 用文本描述图的结构 # 节点定义 service_a [label="订单服务", type=service] service_b [label="库存服务", type=service] db [label="订单库", type=database] # 关系定义 service_a -> service_b [label="扣减库存", style=solid] service_a -> db [label="写入订单", style=solid] service_b -> db [label="读取库存", style=dashed]这种方式的优势在于：改一个节点名字，所有引用它的地方自动更新；调整布局算法，整张图重新排列；把文本文件提交到代码仓库，每次变更都有记录。当然，文本驱动也有局限。对于需要精确控制每个元素位置的场景，比如要匹配某个设计规范，还是得用矢量工具手动调。我的做法是：结构用文本定义，样式用配置文件覆盖，最终导出矢量图做微调。5.3 工具链搭配的实战建议经过多个项目的磨合，我目前稳定使用的工具链是这样的：思路整理：纸笔或白板，不追求美观，只追求快。结构定义：文本描述语言，配合版本控制。样式调整：矢量绘图工具，手动微调关键图。交付输出：根据场景选择格式——评审用PDF，文档用SVG，演示用PNG。维护更新：源文件（文本+矢量）和导出文件分开管理，源文件进仓库，导出文件进文档系统。这套组合拳的核心逻辑是：让图的生命周期和项目的生命周期对齐。图不是一次性交付物，它要跟着项目一起演进。如果图只存在于某个人的电脑里，项目迭代时图就废了。6. 图的生命周期管理：画完只是开始6.1 图会过期，而且过期速度比你想象的快我统计过自己参与过的项目，一张架构图从定稿到第一次需要修改，平均间隔是11天。也就是说，图的生命周期比很多人想象的要短得多。如果你画完图就把它锁在PPT里，两周后它就开始误导人了。图过期的原因通常有三类：结构变化：新增了服务、删除了模块、调整了依赖关系。语义变化：同一个模块的职责变了，但名字没变，图上看不出来。环境变化：部署环境、版本号、配置参数变了，图里还是旧的。第一类变化最容易发现，因为图上的元素对不上了。第二类和第三类最危险，因为图看起来还是“对的”，但实际含义已经错了。6.2 让图可持续维护的三个习惯基于上面的教训，我养成了三个习惯：习惯一：图源文件和代码放在一起。如果项目用Git管理，图源文件也进同一个仓库。改代码的时候顺手改图，review代码的时候顺便review图。这个习惯坚持下来，图的过期率能降低一半以上。习惯二：每张图标注“最后验证日期”。在图的一角写上“本图于2024年X月X日验证有效”。这个日期不是画图日期，是最后一次确认图与实际情况一致的日期。评审时看到日期超过一个月的图，先验证再使用。习惯三：建立图的“废弃标记”机制。当一张图不再准确但暂时没时间更新时，在图的最上方加一条醒目的横条：“此图已过期，最新版本见[链接]”。不要直接删图，因为可能还有人引用；也不要放着不管，因为会误导人。6.3 图与文档的同步策略图和文档的关系很微妙。图是文档的一部分，但图又比文档更容易过期。我的策略是：图负责表达结构，文档负责解释细节。图里只放最稳定的结构信息，容易变的细节放在文档正文里。举个例子：架构图里画了“订单服务”和“库存服务”的依赖关系，但不标具体的API版本号和超时时间。这些细节写在文档的“接口说明”章节里。这样即使API版本升级了，图也不用改，只需要改文档。这个策略的关键是分离关注点：图关注“谁和谁有关系”，文档关注“关系怎么实现的”。两者各司其职，同步成本最低。7. 几个真实场景下的diagram-design决策复盘7.1 场景一：给非技术观众讲系统改造有一次我需要给业务方讲一个系统改造方案，改造涉及六个模块的拆分和合并。我一开始画了一张标准的架构图，分层、分模块、标依赖，自认为很清晰。结果业务方看完问：“所以我们的订单处理时间会变长还是变短？”这个问题让我意识到，业务方关心的不是“模块怎么拆”，而是“对我的业务指标有什么影响”。于是我重新画了一张图，只有三个元素：改造前、改造后、业务指标变化。改造前和改造后各用一个大框，里面用简单的图标表示关键变化，业务指标用箭头和数字标出来。这张图业务方一眼就看懂了。这个案例的教训是：图的抽象层级要匹配观众的决策层级。给高层看，图要抽象到业务指标层面；给技术看，图要具体到模块和接口层面。同一件事，不同观众需要不同的图。7.2 场景二：排查一个跨系统问题有一次线上出问题，涉及四个系统的交互。排查时我在白板上画了一张时序图，把每个系统的请求和响应按时间顺序排列。画到一半就发现了问题：某个系统的响应时间异常，但日志里看不出来，因为日志只记录了总耗时，没记录分段耗时。这张图的价值不在于“好看”，而在于它强迫我把时间维度展开，让隐藏的延迟暴露出来。后来我们根据这张图加了分段埋点，问题很快定位了。这个案例的教训是：图不仅是表达工具，还是分析工具。画图的过程本身就是一种结构化思考，很多问题在画图的过程中就会自己浮现出来。7.3 场景三：维护一份长期演进的架构图有一个项目我维护了两年多，架构图改了十几版。早期我每次都用矢量工具重新画，后来发现这样太累，而且容易漏掉之前的修改。于是我改成文本驱动的方式，把架构定义写成一个结构化文件，每次变更只改文本，图自动重新生成。这个方式的好处是：变更历史清晰，每次改了什么一目了然；回滚容易，改错了直接revert；协作方便，多人同时改不同部分不会冲突。这个案例的教训是：对于长期维护的图，投资一套文本驱动的工作流是值得的。前期花几个小时搭建，后期每次修改能省几十分钟，几个月就回本了。8. 我个人的几条硬核经验最后分享几条我这些年画图总结出来的硬核经验，每一条都是用时间和返工换来的：第一条：图里不要出现“待定”两个字。如果某个信息还没确定，要么不画，要么用虚线框加问号标注。写“待定”等于告诉读者“这张图不可信”。第二条：评审前自己先看三遍。第一遍看逻辑，第二遍看文字，第三遍看对齐。我见过太多图因为一个错别字或者一个没对齐的框，被评审会揪住不放，浪费半小时。第三条：图的标题比图本身重要。标题要写清楚“这张图表达什么关系”，而不是“XX系统架构图”。前者告诉读者看图的目的，后者只告诉读者图的主题。第四条：不要在一张图里塞两个主题。如果一张图既要表达部署结构又要表达数据流向，拆成两张。一张图一个主题，这是铁律。第五条：保存源文件，导出多种格式。源文件用于修改，PDF用于评审，PNG用于文档，SVG用于网页。不要只保存一种格式，不同场景需要不同格式。第六条：定期清理过期的图。每季度花半小时检查项目里的图，过期的标记或删除，有效的更新验证日期。这个习惯能让你的图库始终保持可信。这些经验看起来简单，但真正坚持下来的人不多。我见过太多团队在项目初期画了一堆漂亮的图，项目中期图就没人维护了，项目后期图变成了“历史文物”，没人敢用也没人敢删。diagram-design这件事，画得好不好是能力问题，维护得好不好是习惯问题。能力可以学，习惯只能靠坚持。
1. 从“diagram-design”这个标题里能读出什么第一次看到“diagram-design”这个标题，我脑子里蹦出来的不是某个具体工具，而是一类非常典型的工作场景：手里有一堆零散的信息——业务流程、系统模块、数据流向、组织关系——需要把它们变成一张别人能看懂的图。这件事听起来简单，做起来要命。我见过太多人画图的方式是打开一个绘图工具，拖几个框，连几条线，然后开始纠结“这个框要不要加阴影”“箭头用实心还是空心”“颜色配什么好看”。折腾两小时，图没画完，信息倒是丢了一半。“diagram-design”这个标题的核心，其实不是“画图”，而是“设计图”。画图是把信息摆上去，设计图是让信息自己会说话。这两者的差距，大概就是“把菜炒熟”和“做一道让人记住的菜”之间的差距。我写这篇东西，就是想把这几年在各类项目里画图、改图、被图坑、又靠图救场的经验整理出来，给那些需要频繁用图来表达复杂信息的人——产品经理、技术文档写作者、系统架构师、咨询顾问、甚至是要做答辩PPT的学生——一份能直接上手用的参考。关键词和摘要描述虽然没给，但从标题本身能拆出几个核心方向：图的类型选择、信息层级设计、视觉编码规则、工具链搭配、以及最容易被忽略的“图的生命周期管理”。这些方向我会在下面逐个展开，不搞理论堆砌，只讲我实际用过、踩过、验证过的东西。2. 先想清楚图的“任务”，再动手选类型2.1 图不是装饰品，它承担的是“认知压缩”任务很多人画图之前不思考一个问题：这张图到底是给谁看的，看完之后要做什么决策？我见过一个典型反面案例：某团队做系统重构，架构师画了一张巨详细的部署图，节点、端口、中间件版本全标上了，结果拿去给业务方评审，业务方看了五分钟问了一句“所以我们的订单流程到底变了没有”。问题不在图本身，在于图的“任务”和观众的“需求”错位了。图的核心价值是认知压缩——把一大段文字描述才能说清的关系，压缩成一眼能扫完的视觉结构。但压缩是有损的，你必须决定丢掉什么、保留什么。这个决策的依据就是：观众看完图之后要做什么。如果观众要做技术评审，那端口和版本不能丢；如果观众要理解业务变化，那流程节点和触发条件才是重点，部署细节反而是噪音。我自己的习惯是，动手之前先写一句话：“这张图要让[谁]在[什么场景]下看懂[什么关系]，以便做出[什么决策]。”这句话写不出来，图就别画了，画了也是白画。2.2 常见图类型的适用边界与误用场景下面这张表是我根据实际项目经验整理的，列出了几种高频图类型的真实适用场景和常见误用：图类型最适合表达的关系常见误用我的使用建议流程图步骤顺序、条件分支、角色分工把并行关系画成串行，导致读者误判耗时泳道图优先，角色维度比步骤维度更重要架构图模块边界、依赖方向、层次划分把所有组件平铺，看不出主次分层画，每层不超过7个元素时序图交互顺序、消息传递、超时处理把异常分支全画进去，图变成蜘蛛网主流程一张，异常流程单独一张状态机图状态迁移、触发条件、终态状态和动作混在一起，分不清哪个是哪个状态用圆角矩形，动作标在箭头上数据流图数据来源、加工节点、存储位置把控制流和数据流画在一起数据流图只画数据，控制逻辑另开一张思维导图发散思考、层级归类、头脑风暴当成正式交付物，缺乏精确性只用于个人整理，对外交付要转成结构化图这张表里的每一条都是我踩过坑之后总结的。比如“架构图每层不超过7个元素”这条，来源于一次惨痛经历：我曾经画过一张包含23个模块的架构图，自以为很全面，结果评审会上没人能记住任何一个模块的名字。后来我把它拆成三张图——核心链路一张、支撑服务一张、数据层一张——每张不超过7个元素，评审效率直接翻倍。2.3 一个判断图类型是否选对的简单测试我有个土办法测试图类型选得对不对：把图拿给一个不熟悉项目的人看30秒，然后让他用自己的话复述图里表达的核心关系。如果他能说出“A依赖B，B在C之后发生”这类结构信息，说明图选对了；如果他只能说“有很多框和线”，那要么图太复杂，要么类型选错了。这个测试的关键在于“30秒”和“用自己的话”。30秒逼着你做减法，用自己的话逼着你检查信息是否真的被传递了。我试过很多次，凡是通不过这个测试的图，回去改完之后质量都会上一个台阶。3. 信息层级设计：让读者的眼睛知道先看哪里3.1 视觉权重的分配逻辑一张图里，每个元素的视觉权重应该和它的信息重要性成正比。这话听起来像废话，但实际操作中，大部分人会把所有框画成一样大、所有线画成一样粗、所有颜色用同一个色系。结果就是读者的眼睛在图上乱窜，找不到入口。我的做法是给每个元素打一个“重要性分数”，然后按分数分配视觉权重。具体规则如下：核心节点（分数8-10）：最大尺寸、最深填充色、最粗边框。一张图里这类节点不超过3个。支撑节点（分数5-7）：中等尺寸、浅填充色、常规边框。数量控制在7个以内。辅助节点（分数1-4）：最小尺寸、无填充或极浅填充、细边框或虚线边框。可以多一些，但要用分组框圈起来。这个规则背后的逻辑是视觉搜索效率。人眼在扫视一张图时，会优先被高对比度、大面积、深色的元素吸引。如果你把所有元素都做成高对比度，等于没有对比度，眼睛就失去了导航。我见过一个反例：某项目的业务架构图，把“用户”这个节点画得和“日志服务”一样大，颜色也一样。结果评审时，业务方第一眼看到的是“日志服务”，因为它在图的正中间。这就是视觉权重分配失败的典型。3.2 分组与边界的画法细节分组框（也叫容器、泳道、边界框）是diagram-design里最容易被低估的工具。很多人画分组框就是画一个矩形把几个元素圈起来，标个名字完事。但分组框的视觉设计直接影响读者对“边界”的理解。我的经验是，分组框要满足三个条件才算合格：边界清晰但不抢眼：边框用浅灰或浅蓝，线宽1px，填充色比背景色深一点点就行。分组框是“背景”，不是“前景”。标签位置固定：统一放在左上角，字号比节点文字小一号，颜色用中灰。不要一会儿放上面一会儿放下面。嵌套层级不超过两层：分组框套分组框，最多两层。三层以上读者就晕了，这时候应该考虑拆图。还有一个细节：分组框之间的间距要大于分组框内部元素之间的间距。这是格式塔心理学里的“接近性原则”——人眼会自动把距离近的元素归为一组。如果你把两个分组框贴得太近，读者会误以为它们是一体的。3.3 连线不是越短越好新手画图有个执念：连线越短越好，最好所有节点都紧挨着。但实际上，连线太短会导致两个问题：一是箭头方向看不清，二是交叉线难以避免。我的做法是给连线留出“呼吸空间”。具体来说：相邻节点之间的连线，至少留出节点宽度1.5倍的距离。跨分组的连线，走线要绕开分组框的标签区域。如果两条线必须交叉，在交叉点画一个“跳线”符号（半圆弧），而不是直接十字交叉。这些细节看起来微不足道，但实际评审时，一张连线清晰的图能节省大量解释时间。我曾经对比过两版架构图，内容完全一样，只是连线方式不同，第二版因为加了跳线和呼吸空间，评审时间从40分钟缩短到15分钟。4. 视觉编码规则：颜色、形状、线型的系统化用法4.1 颜色不是用来“好看”的，是用来“分类”的我见过太多人画图时凭感觉选颜色，结果一张图里出现了七八种颜色，每种颜色代表什么全靠猜。颜色在diagram-design里的核心功能是分类编码，不是装饰。我的颜色使用规则很简单：主色不超过3种：一种用于核心元素，一种用于支撑元素，一种用于辅助元素。每种颜色只表达一个维度：比如蓝色表示“服务”，绿色表示“数据”，橙色表示“外部系统”。不要用蓝色既表示服务又表示正常状态。颜色要有语义联想：红色表示警告或错误，绿色表示正常或成功，灰色表示禁用或废弃。这些约定俗成的联想不要随意打破。考虑色盲友好：大约8%的男性有红绿色盲，所以不要只靠红绿来区分关键信息。可以搭配形状或线型来双重编码。我自己的配色方案通常是：深蓝（核心）、中灰（支撑）、浅灰（辅助）、橙色（外部依赖）、红色（异常路径）。这套方案用了好几年，在各种投影仪和打印环境下都验证过，清晰度足够。4.2 形状的语义约定形状在diagram-design里承担的是“类型标识”功能。不同形状代表不同类别的元素，读者看到形状就能预判这个元素的属性。下面是我常用的形状语义表：形状语义使用场景矩形普通节点、服务、模块最通用的形状，用于大多数元素圆角矩形状态、阶段状态机图、生命周期图菱形判断、条件分支流程图中的决策点圆柱体数据存储、数据库数据流图、架构图云形外部系统、第三方服务架构图、集成图人形角色、用户、外部参与者用例图、泳道图虚线框可选、废弃、规划中架构演进图、路线图这套约定不是强制标准，但一旦你在一个项目里用了，就要在所有图里保持一致。我见过一个团队，同一个项目里有的图用圆柱体表示数据库，有的图用矩形表示数据库，结果新成员入职时看图画了两天才搞明白。4.3 线型的表意功能线型（实线、虚线、点线、粗细）在diagram-design里经常被浪费。很多人所有线都用实线，导致图里丢失了一个重要的信息维度。我的线型使用规则：实线：强依赖、主流程、同步调用。虚线：弱依赖、异步调用、可选路径。点线：数据流、事件通知、非阻塞消息。粗线：关键路径、高频调用、核心链路。带箭头的线：有方向的关系。没有方向的关联用无箭头线。这些规则组合起来，一张图能承载的信息量会大幅提升。比如“服务A通过异步消息通知服务B”这个关系，用点线加箭头就能表达，不需要额外写文字说明。5. 工具链的选择与搭配：没有万能工具，只有组合拳5.1 不同阶段的工具选择逻辑画图不是一步到位的事，它通常经历“草稿→细化→定稿→维护”四个阶段。每个阶段对工具的需求完全不同：草稿阶段：需要的是速度，不是美观。我通常用纸笔或者最简单的白板工具，几分钟画完，重点是理清思路。细化阶段：需要的是结构化编辑能力。这时候我会用支持自动布局的工具，比如基于文本描述的绘图方案，改一个节点位置，连线自动调整。定稿阶段：需要的是精确控制和导出质量。这时候用矢量绘图工具，手动调整每个元素的位置和样式。维护阶段：需要的是版本管理和协作能力。图要能跟着代码或文档一起更新，不能画完就锁死在PPT里。这个阶段划分很重要，因为很多人用定稿阶段的工具画草稿，结果在“这个框放左边还是右边”上纠结半小时。我的建议是：草稿阶段用最糙的工具，定稿阶段用最精细的工具，不要混用。5.2 文本驱动绘图方案的实际体验这几年我越来越倾向于用文本描述来生成图，而不是直接拖拽。原因很简单：文本可以版本控制，可以diff，可以review。拖拽出来的图，改一个地方要重新对齐所有元素，而且没法追踪“谁在什么时候改了什么”。文本驱动绘图的典型工作流是这样的：# 用文本描述图的结构 # 节点定义 service_a [label="订单服务", type=service] service_b [label="库存服务", type=service] db [label="订单库", type=database] # 关系定义 service_a -> service_b [label="扣减库存", style=solid] service_a -> db [label="写入订单", style=solid] service_b -> db [label="读取库存", style=dashed]这种方式的优势在于：改一个节点名字，所有引用它的地方自动更新；调整布局算法，整张图重新排列；把文本文件提交到代码仓库，每次变更都有记录。当然，文本驱动也有局限。对于需要精确控制每个元素位置的场景，比如要匹配某个设计规范，还是得用矢量工具手动调。我的做法是：结构用文本定义，样式用配置文件覆盖，最终导出矢量图做微调。5.3 工具链搭配的实战建议经过多个项目的磨合，我目前稳定使用的工具链是这样的：思路整理：纸笔或白板，不追求美观，只追求快。结构定义：文本描述语言，配合版本控制。样式调整：矢量绘图工具，手动微调关键图。交付输出：根据场景选择格式——评审用PDF，文档用SVG，演示用PNG。维护更新：源文件（文本+矢量）和导出文件分开管理，源文件进仓库，导出文件进文档系统。这套组合拳的核心逻辑是：让图的生命周期和项目的生命周期对齐。图不是一次性交付物，它要跟着项目一起演进。如果图只存在于某个人的电脑里，项目迭代时图就废了。6. 图的生命周期管理：画完只是开始6.1 图会过期，而且过期速度比你想象的快我统计过自己参与过的项目，一张架构图从定稿到第一次需要修改，平均间隔是11天。也就是说，图的生命周期比很多人想象的要短得多。如果你画完图就把它锁在PPT里，两周后它就开始误导人了。图过期的原因通常有三类：结构变化：新增了服务、删除了模块、调整了依赖关系。语义变化：同一个模块的职责变了，但名字没变，图上看不出来。环境变化：部署环境、版本号、配置参数变了，图里还是旧的。第一类变化最容易发现，因为图上的元素对不上了。第二类和第三类最危险，因为图看起来还是“对的”，但实际含义已经错了。6.2 让图可持续维护的三个习惯基于上面的教训，我养成了三个习惯：习惯一：图源文件和代码放在一起。如果项目用Git管理，图源文件也进同一个仓库。改代码的时候顺手改图，review代码的时候顺便review图。这个习惯坚持下来，图的过期率能降低一半以上。习惯二：每张图标注“最后验证日期”。在图的一角写上“本图于2024年X月X日验证有效”。这个日期不是画图日期，是最后一次确认图与实际情况一致的日期。评审时看到日期超过一个月的图，先验证再使用。习惯三：建立图的“废弃标记”机制。当一张图不再准确但暂时没时间更新时，在图的最上方加一条醒目的横条：“此图已过期，最新版本见[链接]”。不要直接删图，因为可能还有人引用；也不要放着不管，因为会误导人。6.3 图与文档的同步策略图和文档的关系很微妙。图是文档的一部分，但图又比文档更容易过期。我的策略是：图负责表达结构，文档负责解释细节。图里只放最稳定的结构信息，容易变的细节放在文档正文里。举个例子：架构图里画了“订单服务”和“库存服务”的依赖关系，但不标具体的API版本号和超时时间。这些细节写在文档的“接口说明”章节里。这样即使API版本升级了，图也不用改，只需要改文档。这个策略的关键是分离关注点：图关注“谁和谁有关系”，文档关注“关系怎么实现的”。两者各司其职，同步成本最低。7. 几个真实场景下的diagram-design决策复盘7.1 场景一：给非技术观众讲系统改造有一次我需要给业务方讲一个系统改造方案，改造涉及六个模块的拆分和合并。我一开始画了一张标准的架构图，分层、分模块、标依赖，自认为很清晰。结果业务方看完问：“所以我们的订单处理时间会变长还是变短？”这个问题让我意识到，业务方关心的不是“模块怎么拆”，而是“对我的业务指标有什么影响”。于是我重新画了一张图，只有三个元素：改造前、改造后、业务指标变化。改造前和改造后各用一个大框，里面用简单的图标表示关键变化，业务指标用箭头和数字标出来。这张图业务方一眼就看懂了。这个案例的教训是：图的抽象层级要匹配观众的决策层级。给高层看，图要抽象到业务指标层面；给技术看，图要具体到模块和接口层面。同一件事，不同观众需要不同的图。7.2 场景二：排查一个跨系统问题有一次线上出问题，涉及四个系统的交互。排查时我在白板上画了一张时序图，把每个系统的请求和响应按时间顺序排列。画到一半就发现了问题：某个系统的响应时间异常，但日志里看不出来，因为日志只记录了总耗时，没记录分段耗时。这张图的价值不在于“好看”，而在于它强迫我把时间维度展开，让隐藏的延迟暴露出来。后来我们根据这张图加了分段埋点，问题很快定位了。这个案例的教训是：图不仅是表达工具，还是分析工具。画图的过程本身就是一种结构化思考，很多问题在画图的过程中就会自己浮现出来。7.3 场景三：维护一份长期演进的架构图有一个项目我维护了两年多，架构图改了十几版。早期我每次都用矢量工具重新画，后来发现这样太累，而且容易漏掉之前的修改。于是我改成文本驱动的方式，把架构定义写成一个结构化文件，每次变更只改文本，图自动重新生成。这个方式的好处是：变更历史清晰，每次改了什么一目了然；回滚容易，改错了直接revert；协作方便，多人同时改不同部分不会冲突。这个案例的教训是：对于长期维护的图，投资一套文本驱动的工作流是值得的。前期花几个小时搭建，后期每次修改能省几十分钟，几个月就回本了。8. 我个人的几条硬核经验最后分享几条我这些年画图总结出来的硬核经验，每一条都是用时间和返工换来的：第一条：图里不要出现“待定”两个字。如果某个信息还没确定，要么不画，要么用虚线框加问号标注。写“待定”等于告诉读者“这张图不可信”。第二条：评审前自己先看三遍。第一遍看逻辑，第二遍看文字，第三遍看对齐。我见过太多图因为一个错别字或者一个没对齐的框，被评审会揪住不放，浪费半小时。第三条：图的标题比图本身重要。标题要写清楚“这张图表达什么关系”，而不是“XX系统架构图”。前者告诉读者看图的目的，后者只告诉读者图的主题。第四条：不要在一张图里塞两个主题。如果一张图既要表达部署结构又要表达数据流向，拆成两张。一张图一个主题，这是铁律。第五条：保存源文件，导出多种格式。源文件用于修改，PDF用于评审，PNG用于文档，SVG用于网页。不要只保存一种格式，不同场景需要不同格式。第六条：定期清理过期的图。每季度花半小时检查项目里的图，过期的标记或删除，有效的更新验证日期。这个习惯能让你的图库始终保持可信。这些经验看起来简单，但真正坚持下来的人不多。我见过太多团队在项目初期画了一堆漂亮的图，项目中期图就没人维护了，项目后期图变成了“历史文物”，没人敢用也没人敢删。diagram-design这件事，画得好不好是能力问题，维护得好不好是习惯问题。能力可以学，习惯只能靠坚持。