1. 从一张草图到一套系统diagram-design 到底在解决什么问题第一次看到 “diagram-design” 这个标题我脑子里蹦出来的不是某个具体工具而是一类非常典型的困境手里有一堆零散的信息——业务流程、系统架构、数据流向、组织关系——想把它画成一张图但打开画图软件之后面对空白画布愣了十分钟最后画出来的东西自己都不想看第二眼。这不是审美问题是方法问题。diagram-design 这个主题本质上讨论的是如何用工程化的思路去设计一张图而不是随手拖几个框、连几根线就完事。它覆盖的范围很广流程图、架构图、时序图、状态机图、思维导图、ER 图甚至包括 PPT 里那种用来讲清楚一件事的示意图。核心诉求只有一个——让图替你把话说明白。我做了十多年技术方案和产品设计画过的图少说也有大几百张。早期我也走过弯路追求好看配色花哨阴影拉满结果评审的时候没人看懂后来走向另一个极端全部用最朴素的黑白框结果信息层级完全糊在一起重点找不到。真正让我开窍的是有一次要把一个跨系统调用链路讲给非技术背景的同事听我画了整整一页的架构图对方看了三秒问我“所以数据是从哪到哪”那一刻我意识到图不是画给自己看的是画给读图的人看的。diagram-design 的核心就是站在读图者的角度反向设计信息的呈现方式。这篇文章适合谁看如果你是开发者、产品经理、技术写作者、咨询顾问或者任何需要频繁用图来表达复杂信息的人那这篇内容基本就是为你准备的。我会从设计思路、工具选型、实操步骤、常见坑四个维度把 diagram-design 这件事拆开揉碎讲清楚。不需要你有设计基础但需要你愿意在画图之前先想清楚三件事给谁看、说什么、怎么分层。下面进入正题。2. 画图之前先想清楚diagram-design 的底层设计逻辑2.1 图的本质是信息压缩不是信息堆砌很多人画图有个误区觉得图里信息越多越显得专业。实际上恰恰相反。一张好的图是把 10 页文档的内容压缩成 1 页而不是把 10 页文档原封不动搬到画布上。我习惯用一个简单的判断标准如果一张图需要配 500 字以上的文字说明才能看懂那这张图本身就是失败的。图的价值在于它利用人类视觉系统对空间关系、层级关系、连接关系的天然敏感度把抽象逻辑变成可以直接“看”到的东西。所以 diagram-design 的第一步不是打开工具而是做信息筛选。具体怎么筛我通常用“三层过滤法”第一层这张图要回答的核心问题是什么比如“订单从创建到履约经过了哪些系统”那所有跟这个链路无关的模块全部砍掉。第二层哪些信息是必须出现的核心节点、关键判断分支、数据流向。这些是骨架不能少。第三层哪些信息是锦上添花的比如某个节点的技术栈标注、某个接口的协议类型。这些可以放在图注或者附注里不要塞进主图。经过这三层过滤一张图的信息量通常会缩减到原始素材的 30% 左右。剩下的 70% 不是丢了而是转移到了你的口头讲解或者配套文档里。图负责建立框架文字负责填充细节这才是合理的分工。2.2 读图者的认知路径决定图的布局方式同一个系统画给不同的人看布局应该完全不同。这不是玄学是认知心理学的基本规律。给技术负责人看的架构图他关心的是模块边界、依赖关系、扩展性瓶颈。所以布局应该以分层为主接入层、逻辑层、存储层从上到下或者从左到右清晰展示每一层的职责和层间调用关系。给产品经理看的业务流程图他关心的是状态流转、异常分支、用户可感知的环节。所以布局应该以泳道为主不同角色放在不同泳道里流程从左到右推进分支用菱形判断节点展开。给管理层看的全局概览图他关心的是系统整体规模、核心模块、关键外部依赖。所以布局应该以中心辐射为主核心系统放中间周边系统环绕用粗细不同的连线表示交互频率或重要性。我见过太多人用同一张图应付所有场合结果就是谁都不满意。diagram-design 的关键决策之一就是在动手之前先确定读图者是谁然后选择对应的布局范式。这个决策花你五分钟但能省掉后面两小时的反复修改。2.3 视觉层级比配色方案重要一百倍新手最容易掉进的坑就是把大量精力花在选配色上。什么莫兰迪色系、赛博朋克风、渐变填充折腾半天图还是看不懂。真正决定一张图可读性的是视觉层级。什么叫视觉层级就是读图者的眼睛应该先看什么、再看什么、最后看什么。这个顺序必须由你的设计来引导而不是让读图者自己猜。建立视觉层级的手段有很多按优先级排序大概是这样的手段效果强度使用建议大小对比极强核心节点放大 1.5 到 2 倍位置对比极强重要内容放左上或中心粗细对比强主链路连线加粗辅助线变细颜色对比中同层级同色跨层级换色填充对比中实心表示核心空心表示辅助阴影/立体弱尽量不用容易干扰我的习惯是先用大小和位置把层级拉开再用粗细和颜色做微调阴影和立体效果基本不用。这样画出来的图哪怕打印成黑白层级依然清晰。注意如果你发现自己在一张图里用了超过 5 种颜色大概率是信息分类没做好。颜色是分类工具不是装饰工具。3. 工具选型不同场景下用什么画图最顺手3.1 代码驱动型工具适合需要版本管理的技术图如果你画的图需要进代码仓库、需要跟代码一起迭代、需要多人协作评审那代码驱动型工具是首选。这类工具的核心逻辑是你用文本描述图的结构工具负责渲染成图。典型代表是 Mermaid 和 PlantUML。Mermaid 的语法更接近自然语言上手快适合流程图、时序图、状态图、ER 图这些常见类型。PlantUML 功能更强大支持的类型更多但语法相对复杂一些。我自己的使用习惯是这样的跟代码强相关的图用 Mermaid 写在 Markdown 里跟代码弱相关的图用专业绘图工具。比如一个微服务的调用时序我会直接写在接口文档的 Markdown 里用 Mermaid 渲染但一个完整的系统部署架构我会用 draw.io 或者类似工具画因为需要更自由的布局控制。代码驱动型工具的优势很明显版本可控diff 清晰谁改了哪根线一目了然不需要手动对齐工具自动布局可以嵌入文档系统随文档一起发布但劣势也很明显布局自由度低复杂图容易乱样式定制能力有限很难做出精细的视觉效果学习成本存在团队需要统一约定3.2 拖拽式工具适合需要精细控制布局的场景拖拽式工具的代表是 draw.io、Excalidraw、Figma 这类。它们的核心优势是布局完全由你控制想放哪就放哪想怎么对齐就怎么对齐。这类工具适合画什么图我总结了几类系统架构图需要精确控制模块位置和连线走向业务全景图需要在一个画布上展示多个维度的信息汇报用图需要精细调整视觉效果适配 PPT 或文档排版手绘风格示意图Excalidraw 这类工具自带手绘感适合非正式场合draw.io 是我用得最多的免费、跨平台、支持导出多种格式、可以存本地也可以存云端。Excalidraw 适合快速画草图那种“随手一画”的感觉反而能让读者放松适合头脑风暴和早期讨论。3.3 专业图表工具适合数据可视化和标准化图形如果你的图涉及大量数据、需要精确的坐标轴、需要符合某种行业标准比如 UML 规范那可能需要更专业的工具。比如UML 建模StarUML、Visual Paradigm数据可视化Tableau、Power BI、ECharts网络拓扑亿图、Visio这类工具的学习曲线更陡但胜在专业性和标准化。我的建议是除非你的工作长期需要画某一类标准图否则不需要专门学。大部分场景下draw.io 加 Mermaid 的组合已经能覆盖 90% 的需求。3.4 工具选型的决策清单为了让你更快做决定我整理了一个简单的决策清单场景推荐工具理由接口文档里的时序图Mermaid跟文档一起版本管理系统架构评审图draw.io布局自由导出方便快速头脑风暴草图Excalidraw手绘风格降低正式感数据报表图表ECharts交互性强适配 Web标准 UML 图PlantUML语法规范类型齐全汇报 PPT 配图Figma视觉精细排版灵活提示工具不是越高级越好。我见过有人用 Figma 画架构图花了三小时调像素结果评审时被问“这个模块为什么放在这里”完全答不上来。工具服务于表达不要本末倒置。4. 实操全流程从零画出一张能用的图4.1 第一步用一句话定义图的主题这一步听起来简单但很多人跳过。我要求自己每次画图之前先写一句话“这张图要让 [谁] 在 [什么场景] 下看懂 [什么事]。”举个例子“这张图要让新入职的开发在 onboarding 时看懂订单系统的核心链路。”有了这句话后面所有决策都有了依据新入职开发不需要看历史包袱所以老系统可以简化onboarding 场景需要快速理解所以细节可以砍掉核心链路意味着异常分支可以暂时不展开。如果这句话写不出来说明你还没想清楚为什么要画这张图。那就先别画回去把需求想明白。4.2 第二步列出所有节点和连线先做加法定义清楚主题之后开始做信息收集。这一步不要考虑布局不要考虑美观就是把所有可能相关的节点和连线全部列出来。我通常用纸笔或者一个简单的文本列表来做这件事。比如画一个订单系统链路图我会先列用户端网关订单服务库存服务支付服务履约服务消息队列数据库缓存然后标注它们之间的调用关系用户端调网关网关调订单服务订单服务调库存和支付支付成功后发消息到队列履约服务消费消息等等。这一步的关键是宁多勿少。先把所有可能性列出来后面再做减法。如果一开始就做减法很容易漏掉关键节点。4.3 第三步做减法砍掉非核心信息现在你有了一个完整的节点列表接下来是最重要的一步砍。砍的标准还是回到第一步那句话。如果某个节点跟“让新入职开发看懂核心链路”这个目标无关就砍掉。比如监控系统砍掉onboarding 不需要关心监控。日志收集砍掉同上。配置中心可以保留但简化因为新开发需要知道配置从哪来。缓存保留因为影响链路理解。砍完之后节点数量通常能减少 30% 到 50%。这时候图才开始变得清晰。4.4 第四步选择布局范式并排列节点根据读图者的认知路径选择布局范式。对于订单系统链路图我选择从左到右的泳道式布局最左边是用户端第二列是网关第三列是核心服务订单、库存、支付第四列是异步处理消息队列、履约服务最右边是数据存储数据库、缓存每一列内部按调用顺序从上到下排列。这样读图者的眼睛自然从左到右移动跟数据流动方向一致。排列节点的时候有几个细节要注意对齐同一层级的节点必须对齐否则视觉上会显得混乱间距节点之间的间距要均匀不要有的挤在一起有的隔很远连线尽量用直线或简单的折线避免交叉。如果交叉不可避免用“跳线”或者不同颜色区分4.5 第五步建立视觉层级节点排好之后开始建立视觉层级。我的操作顺序是放大核心节点订单服务是核心放大到 1.5 倍加粗主链路用户到订单到支付这条线加粗弱化辅助节点缓存和数据库用浅色填充统一配色同一层级的节点用同一种颜色不同层级用不同色系添加标注关键节点旁边用小字标注技术栈或协议这一步做完图的基本骨架就出来了。4.6 第六步检查可读性并做最终调整最后一步是检查。我通常会把图缩小到 50% 看一遍再放大到 150% 看一遍。缩小看检查整体层级是否清晰核心节点是否突出有没有明显的视觉失衡放大看检查文字是否清晰连线是否准确标注是否到位如果缩小之后发现核心节点不够突出回去加大对比。如果放大之后发现连线交叉太多回去调整节点位置。实操心得我习惯在最终导出之前把图发给一个没参与设计的同事看一眼问他“你第一眼看到了什么”。如果他的回答跟我的设计意图一致说明图合格了如果不一致说明视觉层级没做好。5. 常见问题与排查技巧实录5.1 图太乱怎么办先做减法再做分层图乱是最高频的问题。很多人第一反应是调整布局但其实大部分情况下乱的根本原因是信息太多。我的排查顺序是这样的数节点如果节点超过 15 个先砍到 10 个以内数连线如果连线超过 20 条先合并同类连线看层级如果所有节点大小差不多先拉开大小对比看颜色如果颜色超过 5 种先统一色系经过这四步大部分图都能变得清晰。如果还是乱那可能是布局范式选错了需要换一种布局方式重新排。5.2 连线交叉太多怎么处理连线交叉是技术图的老大难问题。我的处理技巧有几个调整节点顺序把关联紧密的节点放在相邻位置使用跳线在交叉处画一个小弧线表示“这里不相连”分层画如果一张图实在画不下拆成两张一张画主链路一张画异常分支用颜色区分不同链路的连线用不同颜色交叉时也能区分注意不要为了减少交叉而把节点摆得乱七八糟。有时候适度的交叉是可以接受的只要整体逻辑清晰就行。5.3 文字太多放不下怎么办节点里的文字要精简到极致。我的原则是节点里只放名词不放动词不放形容词。比如“订单服务调用库存服务进行库存扣减”这句话节点里只写“订单服务”和“库存服务”连线上的标注写“扣减库存”。这样既节省空间又保持信息完整。如果实在需要更多说明用图注或者编号在图的下方统一解释。5.4 不同工具导出的图风格不统一怎么办团队协作中经常遇到这个问题有人用 draw.io有人用 Mermaid有人用 Figma导出来的图风格五花八门。我的建议是团队统一一套视觉规范包括统一字体比如都用思源黑体统一配色定义 3 到 5 个标准色统一节点样式圆角矩形、直角矩形、圆形分别代表什么统一连线样式实线、虚线、粗细分别代表什么这套规范不需要很复杂一页文档就能写完。但有了它不管谁画图风格都是一致的。5.5 常见问题速查表问题可能原因解决方法图太乱信息过多做减法砍到 10 个节点以内重点不突出视觉层级缺失放大核心节点加粗主链路连线交叉多节点顺序不合理调整节点位置使用跳线文字看不清字号太小或对比度低字号不小于 12px深色字配浅色底风格不统一缺少视觉规范制定团队绘图规范导出后模糊分辨率不够导出 SVG 或 2 倍图 PNG6. 进阶技巧让图从“能用”变成“好用”6.1 用图讲故事而不是列清单一张真正好的图应该像一篇好文章一样有起承转合。我画架构图的时候会刻意设计一条“视觉动线”读图者的眼睛从左上角进入沿着主链路移动在关键节点停留最后在右下角结束。这条动线上我会安排三个层次的节奏起点用一个明显的视觉元素吸引注意力比如一个加粗的入口节点高潮核心模块放大、加色、加粗让读图者知道这是重点终点用总结性的节点或标注收尾比如“数据落库”或“返回结果”这样读图的过程就变成了一次有引导的浏览而不是漫无目的地扫视。6.2 善用留白不要填满画布新手画图喜欢把画布填满觉得空白是浪费。但实际上留白是建立层级最有效的手段之一。我通常会在核心模块周围留出至少 2 倍于节点间距的空白让它在视觉上“浮”出来。不同层级之间也会留出明显的间隔形成自然的视觉分组。留白还有一个好处方便后续修改。如果画布填得太满加一个新节点就要重新调整全局布局如果留了白直接插进去就行。6.3 为不同媒介做适配同一张图放在文档里、放在 PPT 里、放在大屏上要求是不一样的。文档里字号可以小一些因为读者可以放大看颜色可以淡一些因为背景是白色PPT 里字号要大因为投影后可能看不清对比度要高因为环境光可能很亮大屏上要考虑远距离观看节点和文字都要放大颜色要鲜艳我的做法是先画一张主图然后根据媒介导出不同版本。draw.io 和 Figma 都支持这种操作调整一下字号和颜色就行不需要重新画。6.4 建立自己的图库画了几年图之后我积累了一套自己的“图库”常用的节点样式、配色方案、布局模板。每次画新图的时候直接复用这些素材效率能提升一倍以上。图库不需要很复杂我用的就是一个简单的 draw.io 文件里面存了常用节点服务、数据库、队列、网关等常用配色核心色、辅助色、警告色常用布局模板三层架构、泳道流程、中心辐射每次画新图从这个文件复制粘贴改改文字就行。7. 我踩过的坑和总结的经验画了这么多年图踩过的坑不少挑几个最有代表性的说说。第一个坑追求完美迟迟不动手。早期我总想把布局想得完美无缺再开始画结果想了半小时还没打开工具。后来我强迫自己“先画出来再优化”用 Excalidraw 快速画个草图然后再用 draw.io 精修。效率反而高了很多。第二个坑忽略读图者的背景。有一次给非技术同事画系统图我用了大量技术术语和缩写结果对方完全看不懂。后来我学会了“翻译”把“消息队列”写成“异步通知”把“负载均衡”写成“流量分配”。图还是那张图但读图者能看懂了。第三个坑不保存源文件。有次导出了 PNG 之后把源文件删了结果第二天要改一个文字只能重新画。从那以后我所有图都保留源文件并且按项目分类存档。第四个坑配色太随意。早期我画图喜欢用各种鲜艳的颜色觉得好看。后来发现打印成黑白之后完全分不清层级。现在我基本只用 3 到 4 种颜色并且确保它们在灰度模式下也能区分。第五个坑不写图注。有些图放了一段时间之后自己都忘了某个缩写是什么意思。现在我养成了习惯所有缩写和特殊标记都在图注里解释清楚哪怕当时觉得“这还用说吗”。最后分享一个小技巧如果你觉得一张图画得不错把它存下来下次遇到类似场景直接复用。我现在的图库里大概有 20 多张“模板图”覆盖了架构、流程、时序、状态机等常见类型。每次画新图先翻图库能找到相似的就改找不到再从零画。这个习惯让我画图的时间至少缩短了一半。这个内容后续还可以这样扩展针对特定领域比如数据流图、网络拓扑图、组织架构图做更深入的专题拆解或者整理一套完整的绘图规范文档方便团队内部统一使用。