1. 从“diagram-design”这个标题里能读出什么第一次看到“diagram-design”这个标题，很多人会以为它只是讲“怎么画图”。但如果你真正做过技术方案、写过设计文档、给团队讲过架构，就会明白：画图只是表象，背后是一整套信息压缩与传递的方法论。一个架构图能不能让新人在五分钟内理解系统边界，一张流程图能不能让产品、开发、测试三方对齐状态流转，这才是 diagram-design 真正要解决的问题。我见过太多团队在 diagram-design 上踩坑：有人用专业绘图工具画了三天，结果评审时没人看得懂；有人随手用在线白板画了十分钟，反而被夸“清晰直观”。差别不在于工具多高级，而在于有没有掌握图元语义、层级关系、视觉动线这三件事。这篇内容就是把我这些年做 diagram-design 的经验拆开，从需求判断、工具选型、绘制技巧到评审避坑，全部讲透。不管你是刚入行的开发者，还是需要频繁输出方案的产品经理、技术负责人，都能直接抄作业。提示：diagram-design 不是美术设计，而是信息设计。你的目标不是“好看”，而是“让特定读者在特定场景下快速获取正确信息”。2. 先想清楚“给谁看、在哪看、看完干什么”2.1 三类读者决定三种画法做 diagram-design 的第一步不是打开工具，而是问自己：这张图给谁看？根据我的经验，读者基本分三类，每类的诉求完全不同。第一类是决策者，比如技术总监、项目负责人。他们关心的是“这个方案能不能解决业务问题、成本多少、风险在哪”。给他们看的图，必须结论先行，把核心模块和关键数据放在视觉中心，细节全部折叠。我通常用“三层结构”：顶层是业务目标，中层是核心系统，底层是技术选型，每层只保留三到五个关键节点。第二类是执行者，比如开发、测试、运维。他们关心的是“我负责哪块、接口怎么调、异常怎么处理”。这类图需要精确到字段和状态，比如时序图要标清楚请求参数和返回码，状态机图要穷举所有流转条件。我习惯在图的旁边附一个“图例说明表”，把每个图元的含义、颜色编码、线型语义写清楚，避免口头解释。第三类是外部协作者，比如客户、供应商。他们只关心“边界在哪、我怎么接入”。这类图要隐藏内部实现，只画对外接口和交互流程，用“黑盒”表示内部系统。我一般会加一个“范围说明”标注，明确哪些是本次交付内容，哪些是依赖项。2.2 使用场景决定图的尺寸和精度同一个系统，放在 PPT 里讲和放在 Wiki 里查，画法完全不同。PPT 场景下，图要大、粗、少：一页只讲一个核心观点，字号至少 18pt，线条至少 2px，颜色不超过三种。我见过有人把二十个微服务的架构图塞进一页 PPT，结果投影出来全是蚂蚁线，这种 diagram-design 就是无效的。Wiki 或文档场景下，图要全、细、可检索：可以放完整的分层架构，每个节点带链接跳转到详细文档，颜色可以按业务域区分。但要注意，文档里的图必须自带上下文，因为读者可能从搜索引擎直接跳进来，看不到前后文。我的做法是在图的上方写一段“本图说明”，用两三句话讲清楚这张图回答什么问题、不包含什么内容。2.3 先写“图纲”再动手画这是我最想强调的一个习惯：动手画之前，先用纯文本把图的骨架写出来。比如你要画一个订单系统的流程图，先写：起点：用户提交订单判断：库存是否充足分支 A：充足 → 锁定库存 → 生成支付单分支 B：不足 → 返回缺货提示 → 结束异常：支付超时 → 释放库存 → 结束这个“图纲”写完之后，你自然就知道需要几个节点、几条连线、哪些判断分支。很多人的 diagram-design 之所以乱，就是因为一边想逻辑一边拖图元，最后线交叉成一团。先写图纲，再画图，效率至少提升一倍。3. 工具选型：别被“专业”两个字绑架3.1 四类工具的适用边界市面上的绘图工具我基本都用过，总结下来分四类，各有各的甜点区。工具类型代表形态最适合场景致命短板代码驱动型用文本描述生成图需要版本管理、频繁迭代的架构图学习成本高，样式调整不直观白板协作型无限画布、多人实时头脑风暴、快速对齐、远程评审图元不规范，容易画歪专业绘图型桌面端矢量工具对外交付、印刷级精度协作差，文件体积大文档内嵌型在文档里直接画需求文档、设计文档配图复杂图容易卡顿，排版受限我的建议是：日常迭代用代码驱动型，评审讨论用白板协作型，对外交付用专业绘图型，文档配图用文档内嵌型。不要试图用一个工具解决所有问题，那只会让你在每个场景下都别扭。3.2 代码驱动型工具的核心优势为什么我强烈推荐至少掌握一种代码驱动型工具？因为它解决了 diagram-design 最大的痛点：版本管理。你用白板画的图，改了三版之后，根本不知道第一版长什么样。但代码驱动的图，每次修改都是一次提交，可以 diff、可以回滚、可以分支。举个例子，你要给一个系统画架构图，第一版只有三个模块，第二版加了缓存层，第三版拆了微服务。用代码驱动的方式，你只需要改几行文本，图自动重绘，而且 git log 里清清楚楚记录了什么时间加了什么。这在方案评审时特别有用，有人问“为什么加缓存层”，你直接翻出那次提交的说明就行。注意：代码驱动型工具不适合画“自由布局”的图，比如组织架构图、思维导图。它的强项是结构化图：流程图、时序图、状态图、ER 图、类图。3.3 白板协作型的“隐形规范”白板工具最大的问题是“太自由”，导致每个人画出来的图风格迥异。我在团队里推行过一套“白板 diagram-design 规范”，效果很好，分享给你：颜色语义固定：蓝色=前端，绿色=后端，橙色=数据库，红色=外部依赖，灰色=待定。形状语义固定：矩形=服务/模块，圆角矩形=流程步骤，菱形=判断，圆柱=存储，云形=外部系统。连线语义固定：实线=同步调用，虚线=异步消息，粗线=主流程，细线=辅助流程。命名规范：节点名用“动词+名词”或“名词+类型”，比如“订单服务”“库存校验”“支付回调”。这套规范不需要写在文档里，只要在第一次评审时讲清楚，后面大家自然就统一了。我试过，一个十人团队，用这套规范后，跨组评审的效率提升了至少百分之四十，因为大家不用再问“这个橙色方块是什么意思”。4. 图元、连线与布局：diagram-design 的三大基本功4.1 图元不是随便选的很多人画图时，矩形、圆角矩形、菱形随手就用，觉得“差不多就行”。但在 diagram-design 里，图元形状本身就是一种语义。读者看到菱形，大脑会自动预期“这里有个判断”；看到圆柱，会自动预期“这里是数据存储”。如果你用矩形表示数据库，读者就会困惑。我整理了一份常用图元语义对照表，你可以直接拿去用：图元形状标准语义常见误用矩形服务、模块、系统用来表示判断圆角矩形流程步骤、操作用来表示外部系统菱形判断、分支用来表示普通节点圆柱数据库、存储用来表示服务平行四边形输入/输出用来表示处理步骤云形外部系统、第三方用来表示内部模块泳道角色/部门划分用来表示时间顺序还有一个细节：图元的大小要反映重要性。核心服务画大一点，辅助模块画小一点，读者一眼就能看出主次。我见过有人把所有节点画成一样大，结果评审时大家花了十分钟才找到核心链路在哪。4.2 连线的“交通规则”连线是 diagram-design 里最容易乱的部分。我的经验是：连线要像城市道路，有主干道、有辅路、有立交桥，不能全是平交路口。具体做法：主干道用粗实线，从左到右或从上到下，尽量走直线，不要拐弯。辅路用细实线，可以拐弯，但拐弯次数不超过两次。异步消息用虚线，方向要明确，箭头大小要一致。避免交叉：如果两条线必须交叉，用“跳线”符号（一个小半圆）表示不连接。减少箭头：如果一条线从 A 到 B 再到 C，不要画两个箭头，画一条线加两个节点即可。还有一个容易被忽略的点：连线的标签。很多人画完线就不管了，读者根本不知道这条线代表什么调用。我的习惯是，每条线至少标一个动词，比如“查询”“写入”“通知”“回调”。如果线太密，就用编号，然后在图旁边附一个“连线说明表”。4.3 布局的“视觉动线”设计布局决定了读者的眼睛往哪走。人类阅读习惯是从左到右、从上到下，所以 diagram-design 的主流程应该遵循这个方向。但很多图是“放射状”的，中心一个节点，四周全是线，读者根本不知道从哪看起。我的布局原则：主流程走“Z”字形：左上开始，向右，再向下，再向右，像读文字一样自然。辅助流程走“边缘”：放在图的底部或右侧，用浅色或虚线区分。分组用“容器”：把相关节点放进一个浅色背景框里，标注组名，比如“订单域”“支付域”。留白至少 20%：图元之间不要挤在一起，留白本身就是一种信息分组。我做过一个实验：同一个系统，用“放射状”布局和“Z 字形”布局分别给两组人看，结果 Z 字形组的理解速度快了将近一倍。这不是审美问题，是认知负荷问题。5. 从需求到成图：一个完整 diagram-design 的实操链路5.1 需求拆解：把“画个图”翻译成“回答什么问题”假设有人跟你说“画个订单系统的图”，你千万别直接打开工具。先追问三个问题：这张图要回答什么问题？是“订单怎么创建”，还是“订单状态怎么流转”，还是“订单系统和其他系统怎么交互”？读者是谁？是开发、产品、还是运维？用在哪？是评审 PPT、设计文档、还是故障排查手册？这三个问题问完，你基本就知道该画什么图了。如果是“订单怎么创建”，画流程图；如果是“状态怎么流转”，画状态机图；如果是“系统怎么交互”，画时序图或架构图。图种选错，后面画得再漂亮也是白费。5.2 草图阶段：用纸笔或白板快速迭代我强烈建议在打开专业工具之前，先用纸笔或白板画一版草图。这个阶段的目标不是“好看”，而是“逻辑通”。你可以画得很丑，但要把所有节点、连线、判断分支都画出来。草图阶段最容易发现的问题是逻辑漏洞。比如你画到一半发现“库存不足”之后没有处理分支，或者“支付超时”之后忘了释放库存。这些问题在草图阶段改，成本几乎为零；等到用专业工具画完再改，就要重新调整布局和连线，非常痛苦。提示：草图阶段可以拍照留档，后面正式画图时对照着来，避免遗漏。5.3 正式绘制：先骨架后血肉正式绘制时，我的顺序是：画容器和分组：先把大的边界画出来，比如“前端”“网关”“订单服务”“库存服务”“数据库”。放核心节点：每个容器里放三到五个核心节点，不要超过七个，超过就再分组。连主干线：把主流程的线连上，用粗实线，走直线。连辅助线：把异步、回调、异常处理的线连上，用虚线或细线。加标签和图例：给每条线加动词标签，给每个颜色加图例说明。调整布局：检查有没有交叉线、有没有拥挤区域、有没有留白不足。导出和检查：导出成 PNG 或 SVG，在手机上看一眼，如果手机上能看清，投影和打印就没问题。5.4 评审避坑：别让图成为“猜谜游戏”图评审时，最常听到的反馈是“这里看不懂”。根据我的经验，看不懂通常有三个原因：缺少图例：读者不知道颜色和形状代表什么。解决方案：图旁边加图例表。缺少上下文：读者不知道这张图的范围和边界。解决方案：图上方加一段“本图说明”。缺少层次：所有节点一样大、所有线一样粗，读者找不到重点。解决方案：用大小和粗细区分主次。还有一个坑：不要在评审时口头补充图里没有的信息。如果你发现某个信息很重要，但图里没画，那就改图，而不是靠嘴说。因为图是要存档的，口头补充的信息会丢失。6. 那些年我在 diagram-design 上踩过的坑6.1 坑一：追求“大而全”，结果“全而乱”我刚工作时，总想把所有细节都画进一张图里。一个系统架构图，画了五十多个节点，连每个接口的字段都标上了。结果评审时，没人看得懂，领导直接说“你重新画一张，只画核心的”。后来我学乖了：一张图只讲一件事。如果信息太多，就拆成多张图，用“总-分”结构。第一张画全局架构，只放核心模块；第二张画某个模块的详细流程；第三张画数据模型。每张图都有自己的标题和说明，读者可以按需查看。6.2 坑二：颜色太多，反而没有重点有一段时间我特别喜欢用颜色区分模块，一张图用了七八种颜色。结果打印出来全是灰色，根本分不清。而且颜色太多，读者会下意识地寻找“颜色规律”，反而忽略了图的逻辑。现在我最多用三种颜色：主色（核心流程）、辅色（辅助流程）、警示色（异常或风险）。其他区分用形状和线型来实现。这样即使黑白打印，也能看清逻辑。6.3 坑三：忽略“图外信息”很多人画完图就结束了，但 diagram-design 的完整交付物应该包括：图本身：PNG 或 SVG 格式。图例说明：颜色、形状、线型的含义。范围说明：这张图包含什么、不包含什么。版本记录：什么时候画的、改过哪些地方。相关链接：指向详细文档或代码仓库。我见过一个团队，图画得很好，但没有任何说明文档。半年后新人入职，看到图完全不知道从哪看起，只能一个个问老人。这就是“图外信息”缺失的代价。6.4 坑四：不更新，图变成“历史文物”系统迭代了，图没更新，这是最常见的问题。我的做法是：把图纳入版本管理，和代码一样。每次系统有重大变更，就更新图，并在提交说明里写清楚改了什么。如果是代码驱动型工具，图本身就是代码的一部分，天然同步。如果是白板或专业工具，就定期（比如每个迭代）检查一次，过期就归档或删除。注意：过期的图比没有图更危险，因为它会误导读者。如果一张图已经不代表现状，要么更新，要么明确标注“已过期”。7. 进阶：让 diagram-design 成为团队资产7.1 建立团队图库一个人画图，画得再好也只是个人能力。如果能把 diagram-design 变成团队资产，价值就完全不一样了。我的做法是建一个“团队图库”，按业务域分类，每个图都有统一的命名规范、图例规范和更新记录。图库的好处：新人入职：直接看图库，快速理解系统。方案评审：直接引用图库里的图，不用每次重画。故障排查：对照图库，快速定位问题模块。知识沉淀：图库本身就是团队的知识资产。7.2 制定“最小图规范”图库要可持续，必须有规范。但规范不能太复杂，否则没人遵守。我推荐“最小图规范”，只规定三件事：图元语义：矩形、圆角矩形、菱形、圆柱分别代表什么。颜色语义：最多三种颜色，分别代表什么。命名规范：节点名和连线标签的命名格式。这三件事定下来，团队里任何人画的图，别人都能看懂。其他的风格问题，比如字体、间距、对齐，可以慢慢统一，不必一开始就追求完美。7.3 用 diagram-design 驱动设计讨论最后分享一个我常用的技巧：用画图来驱动设计讨论。当团队对某个方案有分歧时，不要一直口头争论，直接打开白板，说“我们来画一下”。画的过程中，分歧点会自然浮现：有人觉得应该加缓存，有人觉得不需要；有人觉得应该同步调用，有人觉得应该异步。图一画出来，大家对着图讨论，效率比纯文字高得多。而且图是可视化的，每个人都能看到自己的观点被画在哪里，减少了误解。我试过很多次，原本争论半小时的问题，画图十分钟就达成共识了。7.4 从“画图”到“信息架构”说到底，diagram-design 的终极目标不是画出一张好看的图，而是设计一套信息架构。你要考虑：读者是谁、他们需要什么信息、信息怎么分层、怎么引导读者的视线、怎么让图在脱离上下文时依然可读。当你开始用“信息架构”的视角看待 diagram-design，你会发现，画图只是最后一步。前面的需求分析、读者分析、逻辑拆解、布局设计，才是真正决定图质量的关键。我现在的习惯是，画图时间只占百分之三十，百分之七十的时间花在“想清楚”上。想清楚了，画出来就是水到渠成的事。这个习惯让我在方案评审时很少被问倒，因为每个图元、每条连线、每个颜色，我都能说出“为什么这样设计”。如果你也想让 diagram-design 成为你的核心竞争力，不妨从下一张图开始，先想清楚，再动手画。
1. 从“diagram-design”这个标题里能读出什么第一次看到“diagram-design”这个标题，很多人会以为它只是讲“怎么画图”。但如果你真正做过技术方案、写过设计文档、给团队讲过架构，就会明白：画图只是表象，背后是一整套信息压缩与传递的方法论。一个架构图能不能让新人在五分钟内理解系统边界，一张流程图能不能让产品、开发、测试三方对齐状态流转，这才是 diagram-design 真正要解决的问题。我见过太多团队在 diagram-design 上踩坑：有人用专业绘图工具画了三天，结果评审时没人看得懂；有人随手用在线白板画了十分钟，反而被夸“清晰直观”。差别不在于工具多高级，而在于有没有掌握图元语义、层级关系、视觉动线这三件事。这篇内容就是把我这些年做 diagram-design 的经验拆开，从需求判断、工具选型、绘制技巧到评审避坑，全部讲透。不管你是刚入行的开发者，还是需要频繁输出方案的产品经理、技术负责人，都能直接抄作业。提示：diagram-design 不是美术设计，而是信息设计。你的目标不是“好看”，而是“让特定读者在特定场景下快速获取正确信息”。2. 先想清楚“给谁看、在哪看、看完干什么”2.1 三类读者决定三种画法做 diagram-design 的第一步不是打开工具，而是问自己：这张图给谁看？根据我的经验，读者基本分三类，每类的诉求完全不同。第一类是决策者，比如技术总监、项目负责人。他们关心的是“这个方案能不能解决业务问题、成本多少、风险在哪”。给他们看的图，必须结论先行，把核心模块和关键数据放在视觉中心，细节全部折叠。我通常用“三层结构”：顶层是业务目标，中层是核心系统，底层是技术选型，每层只保留三到五个关键节点。第二类是执行者，比如开发、测试、运维。他们关心的是“我负责哪块、接口怎么调、异常怎么处理”。这类图需要精确到字段和状态，比如时序图要标清楚请求参数和返回码，状态机图要穷举所有流转条件。我习惯在图的旁边附一个“图例说明表”，把每个图元的含义、颜色编码、线型语义写清楚，避免口头解释。第三类是外部协作者，比如客户、供应商。他们只关心“边界在哪、我怎么接入”。这类图要隐藏内部实现，只画对外接口和交互流程，用“黑盒”表示内部系统。我一般会加一个“范围说明”标注，明确哪些是本次交付内容，哪些是依赖项。2.2 使用场景决定图的尺寸和精度同一个系统，放在 PPT 里讲和放在 Wiki 里查，画法完全不同。PPT 场景下，图要大、粗、少：一页只讲一个核心观点，字号至少 18pt，线条至少 2px，颜色不超过三种。我见过有人把二十个微服务的架构图塞进一页 PPT，结果投影出来全是蚂蚁线，这种 diagram-design 就是无效的。Wiki 或文档场景下，图要全、细、可检索：可以放完整的分层架构，每个节点带链接跳转到详细文档，颜色可以按业务域区分。但要注意，文档里的图必须自带上下文，因为读者可能从搜索引擎直接跳进来，看不到前后文。我的做法是在图的上方写一段“本图说明”，用两三句话讲清楚这张图回答什么问题、不包含什么内容。2.3 先写“图纲”再动手画这是我最想强调的一个习惯：动手画之前，先用纯文本把图的骨架写出来。比如你要画一个订单系统的流程图，先写：起点：用户提交订单判断：库存是否充足分支 A：充足 → 锁定库存 → 生成支付单分支 B：不足 → 返回缺货提示 → 结束异常：支付超时 → 释放库存 → 结束这个“图纲”写完之后，你自然就知道需要几个节点、几条连线、哪些判断分支。很多人的 diagram-design 之所以乱，就是因为一边想逻辑一边拖图元，最后线交叉成一团。先写图纲，再画图，效率至少提升一倍。3. 工具选型：别被“专业”两个字绑架3.1 四类工具的适用边界市面上的绘图工具我基本都用过，总结下来分四类，各有各的甜点区。工具类型代表形态最适合场景致命短板代码驱动型用文本描述生成图需要版本管理、频繁迭代的架构图学习成本高，样式调整不直观白板协作型无限画布、多人实时头脑风暴、快速对齐、远程评审图元不规范，容易画歪专业绘图型桌面端矢量工具对外交付、印刷级精度协作差，文件体积大文档内嵌型在文档里直接画需求文档、设计文档配图复杂图容易卡顿，排版受限我的建议是：日常迭代用代码驱动型，评审讨论用白板协作型，对外交付用专业绘图型，文档配图用文档内嵌型。不要试图用一个工具解决所有问题，那只会让你在每个场景下都别扭。3.2 代码驱动型工具的核心优势为什么我强烈推荐至少掌握一种代码驱动型工具？因为它解决了 diagram-design 最大的痛点：版本管理。你用白板画的图，改了三版之后，根本不知道第一版长什么样。但代码驱动的图，每次修改都是一次提交，可以 diff、可以回滚、可以分支。举个例子，你要给一个系统画架构图，第一版只有三个模块，第二版加了缓存层，第三版拆了微服务。用代码驱动的方式，你只需要改几行文本，图自动重绘，而且 git log 里清清楚楚记录了什么时间加了什么。这在方案评审时特别有用，有人问“为什么加缓存层”，你直接翻出那次提交的说明就行。注意：代码驱动型工具不适合画“自由布局”的图，比如组织架构图、思维导图。它的强项是结构化图：流程图、时序图、状态图、ER 图、类图。3.3 白板协作型的“隐形规范”白板工具最大的问题是“太自由”，导致每个人画出来的图风格迥异。我在团队里推行过一套“白板 diagram-design 规范”，效果很好，分享给你：颜色语义固定：蓝色=前端，绿色=后端，橙色=数据库，红色=外部依赖，灰色=待定。形状语义固定：矩形=服务/模块，圆角矩形=流程步骤，菱形=判断，圆柱=存储，云形=外部系统。连线语义固定：实线=同步调用，虚线=异步消息，粗线=主流程，细线=辅助流程。命名规范：节点名用“动词+名词”或“名词+类型”，比如“订单服务”“库存校验”“支付回调”。这套规范不需要写在文档里，只要在第一次评审时讲清楚，后面大家自然就统一了。我试过，一个十人团队，用这套规范后，跨组评审的效率提升了至少百分之四十，因为大家不用再问“这个橙色方块是什么意思”。4. 图元、连线与布局：diagram-design 的三大基本功4.1 图元不是随便选的很多人画图时，矩形、圆角矩形、菱形随手就用，觉得“差不多就行”。但在 diagram-design 里，图元形状本身就是一种语义。读者看到菱形，大脑会自动预期“这里有个判断”；看到圆柱，会自动预期“这里是数据存储”。如果你用矩形表示数据库，读者就会困惑。我整理了一份常用图元语义对照表，你可以直接拿去用：图元形状标准语义常见误用矩形服务、模块、系统用来表示判断圆角矩形流程步骤、操作用来表示外部系统菱形判断、分支用来表示普通节点圆柱数据库、存储用来表示服务平行四边形输入/输出用来表示处理步骤云形外部系统、第三方用来表示内部模块泳道角色/部门划分用来表示时间顺序还有一个细节：图元的大小要反映重要性。核心服务画大一点，辅助模块画小一点，读者一眼就能看出主次。我见过有人把所有节点画成一样大，结果评审时大家花了十分钟才找到核心链路在哪。4.2 连线的“交通规则”连线是 diagram-design 里最容易乱的部分。我的经验是：连线要像城市道路，有主干道、有辅路、有立交桥，不能全是平交路口。具体做法：主干道用粗实线，从左到右或从上到下，尽量走直线，不要拐弯。辅路用细实线，可以拐弯，但拐弯次数不超过两次。异步消息用虚线，方向要明确，箭头大小要一致。避免交叉：如果两条线必须交叉，用“跳线”符号（一个小半圆）表示不连接。减少箭头：如果一条线从 A 到 B 再到 C，不要画两个箭头，画一条线加两个节点即可。还有一个容易被忽略的点：连线的标签。很多人画完线就不管了，读者根本不知道这条线代表什么调用。我的习惯是，每条线至少标一个动词，比如“查询”“写入”“通知”“回调”。如果线太密，就用编号，然后在图旁边附一个“连线说明表”。4.3 布局的“视觉动线”设计布局决定了读者的眼睛往哪走。人类阅读习惯是从左到右、从上到下，所以 diagram-design 的主流程应该遵循这个方向。但很多图是“放射状”的，中心一个节点，四周全是线，读者根本不知道从哪看起。我的布局原则：主流程走“Z”字形：左上开始，向右，再向下，再向右，像读文字一样自然。辅助流程走“边缘”：放在图的底部或右侧，用浅色或虚线区分。分组用“容器”：把相关节点放进一个浅色背景框里，标注组名，比如“订单域”“支付域”。留白至少 20%：图元之间不要挤在一起，留白本身就是一种信息分组。我做过一个实验：同一个系统，用“放射状”布局和“Z 字形”布局分别给两组人看，结果 Z 字形组的理解速度快了将近一倍。这不是审美问题，是认知负荷问题。5. 从需求到成图：一个完整 diagram-design 的实操链路5.1 需求拆解：把“画个图”翻译成“回答什么问题”假设有人跟你说“画个订单系统的图”，你千万别直接打开工具。先追问三个问题：这张图要回答什么问题？是“订单怎么创建”，还是“订单状态怎么流转”，还是“订单系统和其他系统怎么交互”？读者是谁？是开发、产品、还是运维？用在哪？是评审 PPT、设计文档、还是故障排查手册？这三个问题问完，你基本就知道该画什么图了。如果是“订单怎么创建”，画流程图；如果是“状态怎么流转”，画状态机图；如果是“系统怎么交互”，画时序图或架构图。图种选错，后面画得再漂亮也是白费。5.2 草图阶段：用纸笔或白板快速迭代我强烈建议在打开专业工具之前，先用纸笔或白板画一版草图。这个阶段的目标不是“好看”，而是“逻辑通”。你可以画得很丑，但要把所有节点、连线、判断分支都画出来。草图阶段最容易发现的问题是逻辑漏洞。比如你画到一半发现“库存不足”之后没有处理分支，或者“支付超时”之后忘了释放库存。这些问题在草图阶段改，成本几乎为零；等到用专业工具画完再改，就要重新调整布局和连线，非常痛苦。提示：草图阶段可以拍照留档，后面正式画图时对照着来，避免遗漏。5.3 正式绘制：先骨架后血肉正式绘制时，我的顺序是：画容器和分组：先把大的边界画出来，比如“前端”“网关”“订单服务”“库存服务”“数据库”。放核心节点：每个容器里放三到五个核心节点，不要超过七个，超过就再分组。连主干线：把主流程的线连上，用粗实线，走直线。连辅助线：把异步、回调、异常处理的线连上，用虚线或细线。加标签和图例：给每条线加动词标签，给每个颜色加图例说明。调整布局：检查有没有交叉线、有没有拥挤区域、有没有留白不足。导出和检查：导出成 PNG 或 SVG，在手机上看一眼，如果手机上能看清，投影和打印就没问题。5.4 评审避坑：别让图成为“猜谜游戏”图评审时，最常听到的反馈是“这里看不懂”。根据我的经验，看不懂通常有三个原因：缺少图例：读者不知道颜色和形状代表什么。解决方案：图旁边加图例表。缺少上下文：读者不知道这张图的范围和边界。解决方案：图上方加一段“本图说明”。缺少层次：所有节点一样大、所有线一样粗，读者找不到重点。解决方案：用大小和粗细区分主次。还有一个坑：不要在评审时口头补充图里没有的信息。如果你发现某个信息很重要，但图里没画，那就改图，而不是靠嘴说。因为图是要存档的，口头补充的信息会丢失。6. 那些年我在 diagram-design 上踩过的坑6.1 坑一：追求“大而全”，结果“全而乱”我刚工作时，总想把所有细节都画进一张图里。一个系统架构图，画了五十多个节点，连每个接口的字段都标上了。结果评审时，没人看得懂，领导直接说“你重新画一张，只画核心的”。后来我学乖了：一张图只讲一件事。如果信息太多，就拆成多张图，用“总-分”结构。第一张画全局架构，只放核心模块；第二张画某个模块的详细流程；第三张画数据模型。每张图都有自己的标题和说明，读者可以按需查看。6.2 坑二：颜色太多，反而没有重点有一段时间我特别喜欢用颜色区分模块，一张图用了七八种颜色。结果打印出来全是灰色，根本分不清。而且颜色太多，读者会下意识地寻找“颜色规律”，反而忽略了图的逻辑。现在我最多用三种颜色：主色（核心流程）、辅色（辅助流程）、警示色（异常或风险）。其他区分用形状和线型来实现。这样即使黑白打印，也能看清逻辑。6.3 坑三：忽略“图外信息”很多人画完图就结束了，但 diagram-design 的完整交付物应该包括：图本身：PNG 或 SVG 格式。图例说明：颜色、形状、线型的含义。范围说明：这张图包含什么、不包含什么。版本记录：什么时候画的、改过哪些地方。相关链接：指向详细文档或代码仓库。我见过一个团队，图画得很好，但没有任何说明文档。半年后新人入职，看到图完全不知道从哪看起，只能一个个问老人。这就是“图外信息”缺失的代价。6.4 坑四：不更新，图变成“历史文物”系统迭代了，图没更新，这是最常见的问题。我的做法是：把图纳入版本管理，和代码一样。每次系统有重大变更，就更新图，并在提交说明里写清楚改了什么。如果是代码驱动型工具，图本身就是代码的一部分，天然同步。如果是白板或专业工具，就定期（比如每个迭代）检查一次，过期就归档或删除。注意：过期的图比没有图更危险，因为它会误导读者。如果一张图已经不代表现状，要么更新，要么明确标注“已过期”。7. 进阶：让 diagram-design 成为团队资产7.1 建立团队图库一个人画图，画得再好也只是个人能力。如果能把 diagram-design 变成团队资产，价值就完全不一样了。我的做法是建一个“团队图库”，按业务域分类，每个图都有统一的命名规范、图例规范和更新记录。图库的好处：新人入职：直接看图库，快速理解系统。方案评审：直接引用图库里的图，不用每次重画。故障排查：对照图库，快速定位问题模块。知识沉淀：图库本身就是团队的知识资产。7.2 制定“最小图规范”图库要可持续，必须有规范。但规范不能太复杂，否则没人遵守。我推荐“最小图规范”，只规定三件事：图元语义：矩形、圆角矩形、菱形、圆柱分别代表什么。颜色语义：最多三种颜色，分别代表什么。命名规范：节点名和连线标签的命名格式。这三件事定下来，团队里任何人画的图，别人都能看懂。其他的风格问题，比如字体、间距、对齐，可以慢慢统一，不必一开始就追求完美。7.3 用 diagram-design 驱动设计讨论最后分享一个我常用的技巧：用画图来驱动设计讨论。当团队对某个方案有分歧时，不要一直口头争论，直接打开白板，说“我们来画一下”。画的过程中，分歧点会自然浮现：有人觉得应该加缓存，有人觉得不需要；有人觉得应该同步调用，有人觉得应该异步。图一画出来，大家对着图讨论，效率比纯文字高得多。而且图是可视化的，每个人都能看到自己的观点被画在哪里，减少了误解。我试过很多次，原本争论半小时的问题，画图十分钟就达成共识了。7.4 从“画图”到“信息架构”说到底，diagram-design 的终极目标不是画出一张好看的图，而是设计一套信息架构。你要考虑：读者是谁、他们需要什么信息、信息怎么分层、怎么引导读者的视线、怎么让图在脱离上下文时依然可读。当你开始用“信息架构”的视角看待 diagram-design，你会发现，画图只是最后一步。前面的需求分析、读者分析、逻辑拆解、布局设计，才是真正决定图质量的关键。我现在的习惯是，画图时间只占百分之三十，百分之七十的时间花在“想清楚”上。想清楚了，画出来就是水到渠成的事。这个习惯让我在方案评审时很少被问倒，因为每个图元、每条连线、每个颜色，我都能说出“为什么这样设计”。如果你也想让 diagram-design 成为你的核心竞争力，不妨从下一张图开始，先想清楚，再动手画。