1. 从零搭建 diagram-design 的完整思路第一次接触 diagram-design 这个方向时我踩过的最大坑就是把它当成一个纯画图工具。实际上diagram-design 的核心价值在于把设计思维和图表表达这两件事捏在一起——它不是让你画得好看而是让你画得对。很多人一上来就打开工具开始拖拽方框结果画到一半发现逻辑根本走不通只能推倒重来。这篇文章我会把整个流程拆开从需求梳理、结构设计、视觉规范到最终交付每一步都讲清楚为什么这么做以及我实际踩过的坑。diagram-design 适合谁看如果你是需要画架构图、流程图、时序图、状态机图的技术人员或者是需要把复杂逻辑讲清楚的产品、运营、设计从业者这篇文章都能给你一套可以直接抄作业的方法。哪怕你之前完全没接触过图表设计跟着走一遍也能画出结构清晰、逻辑自洽的图。我个人的核心观点是图表设计 80% 的功夫在画之前20% 在画的过程中。下面这张表是我总结的常见误区与正确做法对比先建立一个整体认知。常见误区正确做法背后的原因打开工具直接画先用纸笔或纯文本列结构工具会限制你的思考先想清楚再动手追求视觉炫酷优先保证逻辑清晰图表的本质是沟通不是装饰一张图塞所有信息拆成多张分层图单图信息过载会让读者直接放弃颜色越多越好用颜色编码语义颜色是信息维度不是装饰元素画完就交付找不懂业务的人试读自测永远发现不了理解障碍2. 画之前必须想清楚的三件事2.1 这张图到底要回答什么问题我见过太多人画图时脑子里只有一个模糊的我要画个架构图结果画出来的东西谁看了都不知道重点在哪。正确的做法是在动手之前用一句话写出这张图要回答的核心问题。比如这张图要说明用户下单后系统内部经过了哪些服务、这张图要说明订单状态在哪些条件下会发生流转。这句话写不出来就说明你还没想清楚这时候画图纯属浪费时间。这句话还有一个作用它是你后续所有取舍的判断标准。当你在纠结某个细节要不要画进去时就问自己这个细节和核心问题相关吗不相关就果断砍掉。图表设计的本质是做减法不是做加法。2.2 读者是谁他们带着什么背景知识来同一个系统给不同的人看图完全不一样。给运维看的部署图要标清楚机器、端口、网络区域给产品经理看的业务流程图要标清楚角色、动作、判断条件给新人看的入门图要从最基础的概念讲起。我一般的做法是在图的角落或者配套文档里写清楚本图假设读者已经了解 X、Y、Z。这样既避免了在图里塞一堆基础概念解释也让读者知道如果看不懂应该先去补什么。这个习惯是从写技术文档里迁移过来的非常好用。2.3 图的边界在哪里这一点最容易被忽略。任何一张图都不可能画完整个系统你必须明确这张图不包含什么。比如画订单系统的流程图你可能明确不包含支付网关内部的逻辑、不包含风控系统的判断细节这些用一个个外部系统的方框代替即可。明确边界的好处是读者不会追问为什么这里没有 XX你自己画的时候也不会陷入要不要把这个也画上的纠结。边界之外的东西用一句话注释说明XX 部分详见另一张图就够了。3. 结构设计把逻辑翻译成图形语言3.1 先选图形类型再填内容不同的逻辑关系对应不同的图形类型选错了类型后面怎么画都别扭。我整理了一张对照表基本上覆盖了日常 90% 的场景。逻辑关系推荐图形关键特征步骤有先后顺序流程图有明确的开始和结束箭头单向多方按时间交互时序图有生命线消息在生命线之间传递对象状态流转状态机图状态是节点事件是边系统分层结构分层架构图从上到下或从外到内分层模块依赖关系依赖图节点是模块边是依赖方向数据流向数据流图强调数据的加工和存储选类型的判断标准很简单看你的核心问题是顺序、交互、状态还是结构。顺序用流程图交互用时序图状态用状态机图结构用架构图。不要试图用一张流程图去表达状态流转那会画得非常别扭。3.2 用主干分支的方式组织节点确定图形类型后不要急着把所有节点都列出来。我的习惯是先找出主干路径——也就是最核心、最常走的那条路径把它画成一条直线或者一个主循环。然后再把分支、异常、边界情况挂到主干上。这样做的好处是图有主次之分读者一眼就能看到主线细节可以按需深入。如果一上来就平铺所有节点图会变成一团乱麻读者根本找不到入口。具体操作上我会用不同颜色或者不同线宽来区分主干和分支。主干用粗线或者深色分支用细线或者浅色。这个技巧在复杂流程图里特别有效实测下来读者的理解速度能提升不少。3.3 命名规范让节点自己说话节点命名是图表设计里最容易被低估的环节。我见过太多图里写着处理、判断、服务 A这种毫无信息量的名字。好的命名应该让读者不看连线也能猜出这个节点在干什么。我的命名原则是动词名词或者名词状态。比如校验订单合法性、订单已支付、调用库存服务。避免用处理、操作、逻辑这种万能词它们等于没说。还有一个细节同一个概念在全图里必须用同一个名字。不要一会儿叫用户一会儿叫客户一会儿叫订单一会儿叫交易单。这种不一致会让读者以为是两个不同的东西产生不必要的困惑。4. 视觉规范让图好看且不喧宾夺主4.1 颜色只用来编码语义颜色是图表设计里最强大的工具也是最容易被滥用的工具。我的原则是每一种颜色都必须对应一个明确的语义不能因为这个颜色好看就用它。常见的语义编码方式有几种按角色分色用户相关蓝色、系统相关灰色、外部系统绿色、按状态分色正常绿色、警告黄色、异常红色、按层级分色上层深色、下层浅色。选一种方式贯彻到底不要混用。颜色数量控制在3 到 5 种以内。超过 5 种读者就记不住了颜色反而成了干扰。如果确实需要区分更多类别用形状、线型、标签来辅助不要无限增加颜色。4.2 对齐和间距决定专业度一张图看起来专业还是业余很大程度上取决于对齐和间距。我见过内容完全正确但看起来就是很乱的图问题基本都出在这两点上。对齐方面同一层级的节点必须对齐要么顶部对齐要么中心对齐不要参差不齐。连线尽量走直线或者直角折线避免斜线和曲线除非是时序图这种天然需要斜线的场景。间距方面节点之间的间距要一致不要有的地方挤在一起有的地方空一大片。我一般的做法是先定一个基础间距单位比如 20px所有间距都用这个单位的整数倍。这样整张图会有一种内在的节奏感看起来就很舒服。4.3 文字排版能横排就不竖排文字排版有个铁律能横排就横排能一行就不要两行。竖排文字阅读成本极高除非是侧边栏标签这种特殊情况否则一律横排。节点内的文字如果太长优先考虑缩短文字而不是换行。比如用户提交订单请求可以缩短成提交订单因为上下文已经说明了是用户操作。实在缩短不了再考虑换行换行时注意保持每行长度相近不要出现一行特别长一行特别短的情况。字号方面正文文字不小于 12px标题文字比正文大 2 到 4px。层级不要太多一般两级就够了节点标题 节点说明。字号层级太多会让图看起来很碎。5. 工具选型不同场景用不同的家伙5.1 代码化图表工具 vs 拖拽式工具这是图表设计里最重要的一个选型决策。代码化工具用文本描述生成图表和拖拽式工具用鼠标画各有适用场景选错了会非常痛苦。维度代码化工具拖拽式工具版本管理天然支持文本可 diff困难二进制文件修改效率改一行文本即可需要手动调整布局布局控制自动布局省心手动布局精确学习成本需要学语法上手快适合场景逻辑图、时序图、状态机架构图、示意图、海报我的建议是逻辑性强、需要频繁修改的图用代码化工具视觉要求高、一次性交付的图用拖拽式工具。很多人的问题是所有图都用拖拽工具画结果改一次图要花半小时调整布局效率极低。5.2 代码化工具的语法选择代码化图表工具有好几种语法风格选择时主要看两点表达能力和生态支持。表达能力强的语法能画出更复杂的图但学习曲线也陡生态支持好的语法有更多现成的编辑器和渲染工具。我一般的选型逻辑是如果团队里大家都熟悉某种语法就用那种如果从零开始选一种语法接近自然语言、文档齐全的。不要为了追求强大去选一种小众语法后期维护成本会很高。5.3 拖拽式工具的图层管理用拖拽式工具时图层管理是专业和业余的分水岭。业余选手把所有元素堆在一个图层里改一个东西要选中半天专业选手会按功能分层比如背景层、连线层、节点层、标注层。分层的好处是改连线的时候不会误选到节点改背景的时候不会动到内容。我一般至少分四层复杂图会分到七八层。这个习惯养成之后画图效率会有质的提升。6. 实测中的高频问题与排查思路6.1 图太乱先砍内容再调布局图乱是第一大高频问题。很多人遇到图乱的第一反应是调整布局把节点挪来挪去结果挪了半天还是乱。正确的排查顺序是先砍内容再调布局。具体操作把图里所有节点列出来逐个问这个节点和核心问题相关吗不相关的直接删掉。删完之后如果还乱再问这些节点能不能合并把功能相近的节点合并成一个。内容精简到不能再精简了再去调布局。我实测下来大部分图乱的问题砍掉 30% 的内容就解决了根本不需要调布局。6.2 连线交叉用分层和桥接解决连线交叉是第二大高频问题。完全避免交叉很难但可以大幅减少。两个技巧分层和桥接。分层是指把节点按逻辑分成几层同层节点横向排列连线主要在层与层之间走这样交叉会少很多。桥接是指当两条线必须交叉时用一个小弧线表示这里跨过去了而不是直接十字交叉。桥接在电路图和流程图中很常见能显著提升可读性。如果交叉实在太多说明你的图可能承载了太多信息考虑拆成两张图。6.3 读者看不懂找外行试读这是最容易被忽略的排查步骤。你自己画的图你当然看得懂但读者不一定。唯一的验证方法是找一个不了解这个业务的人来试读让他说出这张图在讲什么。如果他说出来的和你想要表达的不一致说明图有问题。常见的问题有入口不明确读者不知道从哪看起、术语没解释读者卡在某个词上、逻辑跳跃读者跟不上你的思路。根据反馈针对性修改通常改两三轮就能达到外行也能看懂的程度。7. 从草图到交付的完整流程7.1 草图阶段用纯文本列结构我强烈建议在打开任何工具之前先用纯文本把结构列出来。用缩进表示层级用箭头表示流向用括号表示条件。这个阶段完全不考虑视觉只考虑逻辑。比如一个订单流程可以这样列用户提交订单 - 校验库存 - 库存充足 - 锁定库存 - 创建订单 - 跳转支付 - 库存不足 - 提示用户 - 结束这个纯文本结构确认无误之后再翻译成图形。这样做的好处是逻辑问题在文本阶段就暴露了不会等到画完图才发现逻辑不通。7.2 初稿阶段先画主干再补分支翻译成图形时先画主干路径确认主干清晰之后再补分支和异常。不要一上来就画所有细节那样很容易迷失在细节里。初稿阶段不要纠结视觉用最朴素的样式把结构画出来就行。颜色、字体、间距这些留到下一阶段统一处理。这个阶段的目标是结构正确不是好看。7.3 精修阶段统一视觉规范结构确认之后进入精修阶段。这个阶段做几件事统一颜色语义、统一字体字号、统一间距、对齐节点、优化连线。这些操作比较机械但决定了图的专业度。我一般的顺序是先定颜色方案再定字体字号然后调间距和对齐最后优化连线。每做完一步都整体看一遍确保没有遗漏。7.4 交付阶段导出和配套说明导出时注意两点格式和分辨率。如果图要放进文档用矢量格式SVG、PDF如果要放进 PPT 或者聊天工具用高分辨率位图PNG2 倍或 3 倍分辨率。不要导出低分辨率位图放大就糊。配套说明也很重要。图本身能表达的信息有限关键的假设、边界、术语解释要写在图外的说明里。我一般会在图下方加一段简短的说明写清楚这张图的适用范围和阅读顺序。8. 几个让我少走弯路的实操心得第一个心得图是改出来的不是画出来的。我早期总想一次画到位结果每次都要大改。后来接受了一个事实第一版一定是错的快速画出第一版然后基于反馈迭代效率反而更高。第二个心得建立自己的图表模板库。常用的架构图、流程图、时序图各做一个模板下次画同类图时直接套用。模板里预设好颜色、字体、间距能省下大量重复劳动。我现在的模板库有十来个模板覆盖了日常 80% 的场景。第三个心得图的标题和注释和图本身一样重要。很多人只重视图的内容标题随便写个架构图就完事。好的标题应该说明这张图的核心结论比如订单系统采用读写分离架构写库单点、读库可扩展。读者看标题就能 get 到重点图是佐证。第四个心得定期回顾旧图。我每隔一段时间会翻出几个月前画的图看看现在还能不能看懂。如果看不懂了说明当时的表达有问题记录下来避免下次再犯。这个习惯帮我发现了不少表达上的坏习惯。第五个心得不要追求一张图讲完所有事。我早期总想用一张图覆盖所有场景结果图越来越复杂越来越难懂。后来学会了拆图一张图只讲一件事讲清楚就行。多张图之间用编号和引用关联起来整体反而更清晰。关于 diagram-design 这个方向我的整体判断是它是一项被严重低估的技能。大部分人觉得画图就是把想法画出来但实际上画图的过程本身就是一次深度思考。你在纠结某个节点要不要画、某条线怎么走的时候其实是在逼自己把逻辑想清楚。所以我的建议是不要把它当成负担把它当成梳理思路的工具用多了你会发现很多想不清楚的问题画着画着就清楚了。