diagram-design：从画图到系统设计，一套可复用的图工程规范

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

第一次看到 “diagram-design” 这个标题，很多人会以为它只是教你怎么把图画得好看一点。但真正做过系统设计、技术方案评审、产品架构梳理的人都知道，画图这件事从来不只是“美不美”的问题，它直接决定了信息能不能被准确传递、方案能不能被快速理解、团队能不能在同一个认知层面上讨论问题。我见过太多项目，代码写得漂漂亮亮，结果一张架构图把所有人看懵——箭头乱飞、模块边界模糊、数据流向自相矛盾。这种图不但没帮上忙，反而制造了新的沟通成本。

diagram-design 要解决的核心问题，就是把“画图”从个人审美行为升级为一套可复用、可协作、可验证的设计系统。它关注的不是某一张图好不好看，而是一整套图在面对不同读者、不同场景、不同复杂度时，能不能稳定地输出清晰、准确、一致的信息。换句话说，它更像是一套“图的工程规范”，而不是一个画图工具教程。

这套东西适合谁？我梳理下来大概有三类人收益最明显。第一类是技术方案的设计者和评审者，比如系统架构师、技术负责人，他们需要频繁用图来表达复杂系统，图的质量直接影响方案推进效率。第二类是产品经理和业务分析师，他们要用流程图、状态图、时序图来对齐需求，图错了需求就错了。第三类是刚入行的开发者或者转岗人员，他们往往能看懂代码，但不知道怎么把脑子里的逻辑变成一张别人也能看懂的图，diagram-design 提供的正是这套“翻译规则”。

我自己的体会是，图的问题从来不是孤立的。一张图画不清楚，背后往往是设计思路本身就没理顺。所以 diagram-design 的价值不只是产出好看的图，而是倒逼你把系统想清楚。你在调整一个箭头方向的时候，其实是在重新审视模块之间的依赖关系；你在统一图例的时候，其实是在梳理概念边界。这个过程本身就是一次设计复盘。

接下来的内容，我会从整体设计思路、核心细节、实操流程、常见问题几个层面，把这套方法拆开讲透。不管你现在用的是哪种画图工具，这些原则都能直接迁移过去。

2. 整体设计思路：为什么“好看”不是第一优先级

2.1 图的本质是信息压缩，不是视觉装饰

很多人对 diagram-design 的第一个误解，就是把它等同于“配色方案”或者“排版技巧”。我早期也走过这个弯路，花大量时间调渐变色、找图标库，结果图是漂亮了，但同事看完还是问“这个模块到底负责什么”。后来我才想明白，图的核心价值是信息压缩——把几百字说不清的关系，用一张图在几秒内讲明白。颜色、字体、间距这些视觉元素，都是为信息传递服务的，不能本末倒置。

举个生活化的类比。地铁线路图大家都见过，它把真实的地理位置、距离、走向全部抽象成横平竖直的线条和等距的站点。它不追求地理准确，但它让你在几秒内知道“从 A 到 B 要经过几站、在哪里换乘”。这就是信息压缩的典范。diagram-design 追求的正是这种效果：牺牲部分细节精度，换取整体认知效率。

所以我在做任何一张图之前，都会先问自己三个问题：这张图给谁看？他们最需要从图里获取什么信息？哪些细节可以砍掉而不影响核心结论？这三个问题的答案，直接决定了图的抽象层级和视觉复杂度。给高层看的图，模块可以粗到“业务层、服务层、数据层”；给开发看的图，可能就要细到具体组件和接口。

2.2 一致性优先于单张图的精致度

单张图做得再精致，如果和团队里其他图的风格、符号、命名规则不一致，整体认知成本反而更高。我踩过最典型的坑，就是同一个系统里，A 画的图用圆角矩形表示服务，B 画的图用圆角矩形表示数据库，结果评审会上大家对着两张图来回切换，脑子全乱了。

diagram-design 的一个核心原则就是建立并遵守统一的视觉语言。这套语言包括几个层面：形状语义（什么形状代表什么类型的元素）、颜色语义（什么颜色代表什么状态或层级）、连线语义（实线、虚线、箭头分别代表什么关系）、命名规范（模块名、接口名怎么起）。这套规则一旦定下来，就要像代码规范一样被强制执行。

我建议的做法是，团队维护一份“图例字典”，把常用的形状、颜色、连线样式和它们的含义固定下来。新画图的人直接查字典，而不是自己发明。这份字典不需要很复杂，一页纸就够，但它的存在能省下大量沟通成本。下面这张表是我在实际项目中常用的一套基础图例约定，你可以直接参考：

注意：图例字典一旦确定，就不要频繁改动。每次改动都要同步更新所有历史图，否则字典本身就成了混乱源。

2.3 分层抽象：一张图只讲一件事

我见过最劝退的图，是把部署架构、业务逻辑、数据流向、时序关系全塞进一张图里。这种图的信息密度看似很高，实际上谁也看不懂。diagram-design 强调分层抽象，一张图只回答一个核心问题。

常见的分层方式有这么几种。第一层是上下文图，只画系统和外部世界的关系，回答“这个系统边界在哪、和谁交互”。第二层是容器图，把系统拆成几个大的服务或应用，回答“系统内部由哪几块组成”。第三层是组件图，深入某个容器内部，回答“这个服务由哪些模块构成”。第四层是代码级图，通常只在必要时才画，回答“具体类或函数怎么协作”。

这种分层的好处是，不同角色的读者可以只看自己关心的那一层。高层看上下文图就够了，开发看组件图，运维看部署图。每张图都保持在一个可控的复杂度内，不会因为信息过载而失效。我个人的经验是，一张图里的元素数量控制在 7 到 12 个之间，超过这个范围就该考虑拆图了。这个数字不是拍脑袋来的，它和人的短期记忆容量有关，超过之后理解成本会急剧上升。

3. 核心细节解析：形状、连线、布局背后的门道

3.1 形状语义：让读者不用看图例就能猜个大概

形状是图的基本词汇。diagram-design 里对形状的使用有一套比较严格的约定，目的就是让读者即使没看图例，也能凭直觉猜出元素的大致类型。这不是为了装专业，而是为了降低认知负担。

矩形通常表示“主动的东西”，比如服务、应用、模块，它们会执行逻辑、发起调用。圆角矩形或者圆柱体表示“被动的东西”，比如数据库、缓存、文件存储，它们只负责存数据，不主动做事。菱形表示判断点，只在流程图里出现。人形图标表示外部角色或用户。云形表示外部系统或网络边界。

这套约定不是绝对的，但一旦你的团队接受了某种约定，就要保持一致。我见过有的图里用圆形表示服务，有的图里用圆形表示数据库，这种不一致会让读者每次都要重新确认，非常消耗精力。

还有一个细节是形状大小和层级的关系。我习惯让越靠近核心业务的模块形状越大，越边缘的依赖形状越小。这样读者一眼就能看出哪些是重点。但这个规则也要克制，不要搞出七八种大小，三档就够了：核心、一般、边缘。

3.2 连线语义：箭头方向比箭头样式更重要

连线是图的语法。很多人画图时把精力花在箭头样式上——实线、虚线、点线、粗细、颜色，结果忽略了最根本的东西：箭头方向代表的信息流向或依赖方向。

我的原则是，箭头方向必须和实际的数据流或调用方向一致。A 调用 B，箭头就从 A 指向 B。A 依赖 B，箭头也从 A 指向 B。不要出现双向箭头，除非确实是双向同步调用，而且这种情况本身就值得警惕。双向依赖往往是设计问题的信号，图里画出来正好提醒你去审视。

虚线通常表示异步、弱依赖或者可选关系。比如消息队列的生产者和消费者之间，用虚线箭头表示异步消息，比实线更准确。点线一般表示注释性的、非结构性的关系，我很少用，因为容易引起歧义。

还有一个容易被忽略的点是连线的交叉。交叉线越多，图越难读。diagram-design 里有个实用技巧：通过调整元素位置来减少交叉，而不是靠画“跨线桥”。如果交叉实在避不开，说明你的布局可能需要重新组织，或者这张图该拆了。

3.3 布局原则：从左到右、从上到下符合阅读习惯

布局是图的“排版”。同样的元素和连线，布局不同，可读性天差地别。diagram-design 遵循几个基本布局原则。

第一，主流程从左到右或从上到下。这符合大多数人的阅读习惯。比如时序图，时间轴从上往下；数据流图，数据从左边流入、右边流出。不要搞反向布局，读者会本能地按习惯去读，然后发现读反了，体验很差。

第二，相关元素就近放置。属于同一个子系统或同一个业务域的模块，应该聚在一起，用留白或浅色背景框和其他区域隔开。这样读者能快速识别出“这几块是一伙的”。

第三，对齐产生秩序。元素之间的对齐线越整齐，图看起来越专业，也越容易追踪连线。我习惯用网格对齐，哪怕工具不支持自动对齐，手动也要尽量对齐。歪歪扭扭的布局会让读者潜意识里觉得这张图“不靠谱”。

第四，留白是设计的一部分。不要把画布塞满，元素之间留出足够的呼吸空间。留白不仅让图更好看，更重要的是让分组关系更清晰。两个元素靠得近，读者会认为它们关系紧密；离得远，会认为它们关系疏远。这个视觉暗示比任何文字标注都有效。

3.4 文字与标注：少即是多，精确即是美

图里的文字是最容易失控的部分。我见过太多图，每个框里塞满文字，字号小到要放大才能看清。这种图的信息传递效率极低，因为读者要停下来逐字阅读，图的“一眼看懂”优势就没了。

diagram-design 对文字的处理原则是：框内只放名词性短语，动词和逻辑关系交给连线。比如一个服务框里写“订单服务”，而不是“负责处理订单创建、查询、取消的服务”。后者应该拆成多个框，或者放到图外的说明文档里。

标注的使用也要克制。只在连线含义不直观的时候才加标注，比如“每 5 分钟同步一次”“失败重试 3 次”。标注文字要短，能用一个词就不用一句话。如果一张图需要大量标注才能看懂，说明图本身的结构没设计好。

字号方面，我建议正文文字不小于 12px，标题不小于 16px。如果是投屏演示，还要再放大。颜色对比度要足够，浅灰底配白字这种组合，投影仪上一片糊，千万别用。

4. 实操过程：从零开始设计一张合格的系统图

4.1 第一步：明确图的读者和目的

动手画之前，先花五分钟想清楚这张图给谁看、要回答什么问题。这一步看起来简单，但跳过它的人特别多。我自己的习惯是，在画布角落先写一行小字：“本图面向 XX 角色，回答 XX 问题”。这行字最后会删掉，但它能帮我在整个绘制过程中不跑偏。

比如你要画一张给运维团队看的部署图，那重点就是节点、网络分区、端口、副本数，业务逻辑可以完全不画。如果你画的是给产品经理看的业务流程图，那重点就是角色、动作、判断分支，技术实现细节全部省略。同一套系统，面向不同读者的图，长得完全不一样，这是正常的。

4.2 第二步：列出元素清单，先做减法

明确目的之后，把所有可能相关的元素列出来，然后做减法。我的经验是，初稿列出的元素通常比最终需要的多一倍。减法的标准就是：这个元素删掉之后，图要回答的核心问题还成立吗？如果还成立，就删掉。

比如画一张订单系统的上下文图，核心问题是“订单系统和哪些外部系统交互”。那订单系统内部的“库存扣减模块”“优惠计算模块”就不该出现，它们属于下一层。外部系统里，“支付网关”“物流系统”“用户中心”要保留，“日志系统”“监控系统”如果和订单核心流程关系不大，也可以先不画。

这一步做完，你会得到一个精简的元素列表，通常控制在 10 个以内。这个列表就是图的骨架。

4.3 第三步：确定布局骨架，先摆位置再连线

很多人习惯边画元素边连线，画到后面发现布局乱了，再回头调整，非常痛苦。我的做法是先把所有元素的位置摆好，确认布局合理之后，再统一连线。

摆位置的时候，先确定主流程的方向。如果是数据流，就从左到右排；如果是调用链，就从上到下排。然后把相关元素聚成组，组和组之间留出明显大于组内间距的空白。摆完之后退后一步看整体，如果一眼能看出分组和主流程，布局就合格了。

这个阶段不要纠结形状和颜色，用最简单的矩形占位就行。布局是骨架，形状和颜色是皮肤，骨架没搭好，皮肤再漂亮也没用。

4.4 第四步：连线与标注，逐条确认语义

布局确定后开始连线。每连一条线，都要问自己：这条线代表什么关系？方向对吗？样式对吗？需要标注吗？我习惯连完线之后，把每条线从头到尾“读”一遍，用嘴说出它的含义，比如“订单服务调用支付网关发起支付”。如果说不通，说明这条线有问题。

连线阶段最容易犯的错误是“想当然”。比如两个模块之间有数据交互，但到底是同步调用还是异步消息，很多人不假思索就画了实线箭头。实际上这个区别很重要，画错了会误导读者。所以每一条线都要有依据，不能凭感觉。

4.5 第五步：视觉打磨与一致性检查

最后才是视觉打磨。统一形状、颜色、字号、间距，加上图例和标题。这一步的重点不是“好看”，而是“一致”。所有同类元素用同样的样式，所有同类关系用同样的连线，所有文字用同样的字体和字号。

打磨完之后，做一次一致性检查。我通常会用这几个问题自查：图例里的每种样式都在图里出现了吗？有没有图例里没提到的样式？同类元素样式统一吗？连线有没有交叉过多？文字有没有错别字？这张图给一个没参与设计的人看，他能在 30 秒内说出图在讲什么吗？

4.6 第六步：评审与迭代，图是改出来的

没有一张好图是一次画成的。diagram-design 强调图要经过评审和迭代。我习惯把初稿发给两三个人看，一个是目标读者，一个是完全不懂这个系统的局外人。目标读者看信息是否准确完整，局外人看是否易懂。这两类反馈往往能发现不同的问题。

评审时不要问“你觉得好看吗”，而要问“你能说出这个系统是怎么工作的吗”“哪里让你困惑”。根据反馈修改，通常两到三轮就能达到一个不错的状态。改完之后，把最终版和评审意见一起归档，下次画类似的图就有参考了。

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

5.1 图太复杂看不懂，怎么拆

这是最高频的问题。判断标准很简单：如果一张图需要超过 30 秒才能理解主干，或者元素超过 15 个，就该拆了。拆图的方式有两种：按层级拆，按场景拆。

按层级拆就是前面说的上下文图、容器图、组件图分层。按场景拆是把不同业务场景分开画，比如“下单流程”“退款流程”“对账流程”各一张图。拆完之后，用一张总览图把它们串起来，总览图只画高层模块和场景之间的关系。

拆图的时候要注意，每张子图都要能独立看懂，不能出现“这个模块在另一张图里定义”这种悬空引用。子图之间可以有重叠元素，但重叠部分的命名和样式必须一致。

5.2 连线交叉太多，怎么优化

连线交叉是布局问题，不是连线问题。解决方法有这几个。第一，调整元素位置，把关系紧密的元素放近一点。第二，改变布局方向，比如从左右布局改成上下布局。第三，引入中间节点，把多条线汇聚到一个中间元素再发散。第四，如果实在无法避免，考虑拆图。

我个人的经验是，交叉线超过三条，就值得花时间重新布局了。重新布局花十分钟，读者省下的理解时间可能是几十个人的几分钟，这笔账很划算。

5.3 团队风格不统一，怎么推动规范落地

这是组织问题，不是技术问题。我的做法是，先自己按规范画几张图，在评审会上展示效果，让大家感受到规范带来的可读性提升。然后整理一份轻量的图例字典，放到团队共享文档里。最后在代码评审或者方案评审流程里，加一条“图是否符合图例规范”的检查项。

推动规范最忌讳一上来就搞很重的流程和很复杂的字典。先从最核心的几条规则开始，比如形状语义和连线语义，跑顺了再逐步补充。规范的生命力在于被执行，不在于多完备。

5.4 工具选型：别让工具限制你的设计

diagram-design 是方法论，不是某个特定工具。市面上常见的画图工具各有优劣，我列个表对比一下常见类型：

我的建议是，架构类、需要长期维护的图用代码化方式，因为可以进版本库、可以 diff、可以复用组件。演示类、一次性的图用拖拽工具，效率优先。不要用一种工具解决所有问题，也不要因为工具换了就丢掉 diagram-design 的原则。

5.5 常见问题速查表

提示：这张表可以打印出来贴在工位上，画图卡壳的时候对照着看，大部分问题都能找到方向。

5.6 几个我踩过的坑，你别再踩

第一个坑是过度追求视觉完美。我早期花大量时间调颜色和阴影，结果图的信息结构一塌糊涂。后来才明白，图的专业度体现在信息组织上，不在视觉特效上。现在我的图基本都是黑白灰加一两个强调色，反而更受好评。

第二个坑是图例和图不一致。有次我图例里写了虚线表示异步，结果图里虚线实线混用，评审时被人当场指出，非常尴尬。从那以后，我养成了一个习惯：画完图之后，专门花两分钟对照图例逐条检查。

第三个坑是不写标题和图注。一张图脱离上下文之后，过两周自己都忘了在讲什么。现在我每张图都有标题、日期、作者、版本号，重要图还加一段简短说明。这些元信息看起来不起眼，但图的生命周期越长，它们的价值越大。

第四个坑是用图代替文档。图擅长表达结构关系，但不擅长表达细节逻辑和边界条件。我见过有人用一张流程图代替需求文档，结果开发时发现大量分支没覆盖。图和文档是互补的，图负责建立整体认知，文档负责补充精确细节，谁也替代不了谁。

6. 把 diagram-design 变成团队习惯

diagram-design 这套方法，说到底不是让你画得更累，而是让你画得更省。前期多花十分钟想清楚读者、目的、结构，后期能省下几十个人的理解成本。这笔账，做过方案评审的人都懂。

我现在的习惯是，任何一张要给别人看的图，都先按这套流程走一遍：明确读者和目的、列元素做减法、摆布局、连线、打磨、评审。熟练之后，整个过程也就二三十分钟，但图的质量和以前完全不是一个档次。团队里其他人看到效果，自然会来问你怎么画的，这时候把图例字典和流程分享出去，规范就慢慢落地了。

最后分享一个我最近在用的技巧：给每张图加一个“一句话摘要”，放在图的最上方或者最下方，用一句话说清这张图在讲什么。比如“本图展示订单系统与外部系统的交互关系”。这句话看起来简单，但它强迫你在画图之前就想清楚核心信息，也让读者在深入细节之前先建立整体认知。实测下来，这个小改动对图的可读性提升非常明显，你可以试试。