先说一个我观察了很久的现象大多数技术人画图缺的不是工具而是设计意识。同样的结构有人画出来一目了然有人画出来就是一团乱线。这不只是审美差异而是有没有把“画图”这件事当成一个正经的设计问题来对待。我在整理 diagram-design 这套工作流的时候最大的体会就是好的架构图、流程图、ER 图背后一定有一套可复用的规则而不是灵感。这篇文章想把 diagram-design 从理念到落地掰开揉碎讲清楚。适合的人群很广要给系统画架构图的后端开发、要画业务流程图的产品经理、要出技术方案文档的云架构师以及所有被“图丑但不自知”困扰过的写文档的人。我会讲清楚好图的标准、工具链选型、一套可以直接照抄的设计流程再用一个真实的系统架构图案例走完整遍过程。最后是我自己踩过的坑这些基本在官方文档里看不到。1. 先搞清楚一张好图到底“好”在哪里很多人对 diagram 设计有个误解觉得图嘛就是把模块框起来用箭头连一连标注清楚就完事了。但如果你真的在团队里评审过技术方案就会发现同样一张系统架构图有人画完大家秒懂有人画完被追问二十分钟“这里是什么意思”。差别不在信息量而在信息组织方式。1.1 图表设计的三个层级信息架构、视觉编码、叙事引导我把 diagram 设计拆成三个层级这也是我每次动笔前强制自己过一遍的框架。第一层是信息架构。这一层解决的是“图里应该放什么、不放什么”。大部分丑图烂图根源都在这一层——什么细节都想塞进去结果没有主次。你要先回答几个问题这张图要给谁看他要基于这张图做什么决策哪些信息是必要的背景哪些是核心路径哪些是可以留到附录里的细节第二层是视觉编码。这是 diagram 区别于普通文字描述的核心能力。人眼处理图形信息的速度远快于文字但前提是你得尊重视觉规律。大小代表权重颜色代表分组间距代表关系亲疏箭头方向代表流向。如果你把这些视觉变量用反了信息量越大越混乱。第三层是叙事引导。一张好图是有阅读顺序的读者的眼睛应该被你设计的视觉路径牵着走。从哪开始看经过哪里最后落在哪这跟写文章起承转合是一个道理。很多人画图失败就是把一张 A4 纸当成全景地图读者根本不知道该聚焦在哪。1.2 那些“颜色丰富但看不懂”的图的共病默认设置陷阱我见过太多人用工具自带的默认样式。Mermaid 默认配色、Draw.io 默认字体、Visio 默认阴影这些默认设置单独看都还行但组合在一起就灾难了。你会发现整张图每个框都在抢注意力颜色之间没有语义只有装饰。这里有个反常识的判断diagram 里的颜色越少通常信息传递效率越高。颜色应该只被用来表达某个特定的维度比如“哪些模块属于用户端”“哪些链路是核心路径”“哪个节点当前是故障状态”。如果一个颜色在图上不能对应到一个明确含义它就只是噪音。我用过一个很笨但有效的办法画完图之后闭上一只眼睛把图缩到很小看还能不能认出大致结构和重点。如果缩到 50% 就糊成一团说明视觉层级没做好。这种测试比盯着细节死抠有效得多。1.3 我用来评判一张图的核心 checklist每次画完图我会过一遍自己的 checklist全部满足才会发布出去。信息完整性不依赖额外口头说明光看图能不能理解核心逻辑层级清晰度第一眼能不能分辨主次核心链路是否比次要信息更快抓住视线分组合理性相关模块之间是否有明确的视觉边界或邻近关系标签可读性所有文字在目标尺寸下是否清晰字体大小是否有层级路径流畅度箭头和连线是否存在交叉、回绕、穿越文字的问题一致性同类元素是否用了同样的形状、颜色、线型和图标风格这六条看起来很基础但我评审过大量团队内部的 diagram能全部通过的不多。以前我刚开始做 diagram 设计时最常被 challenge 的就是“标签不可读”和“路径不清”这两个问题都是可从 checklist 层面拦截的。后来把自检变成肌肉记忆后图的质量稳定上升输出效率也快了。2. 工具选型别一上来就选最高级的工具是 diagram 设计里最容易被过度讨论的话题。经常有人问我是用 Draw.io 还是 Figma 还是 Mermaid其实这个问题的前提就错了。工具是服务于你的设计流程的你连自己的流程都没想清楚换什么工具都一样画不出好图。2.1 三类 diagram 工具的真实适用场景对比我这些年实际重度用过几大类工具按场景说下真实感受。手动布局类代表是 draw.io、Visio、Figma。优点是完全控制布局想怎么摆怎么摆表达力最强。适合信息架构图、系统总览图、PPT 里要给人讲的故事型 diagram。缺点也很明显维护成本高一旦系统结构变了改图是一场灾难。代码驱动类代表是 Mermaid、PlantUML、Graphviz。核心逻辑是“以文本描述关系自动生成布局”。优点是可版本管理、可注释、改起来快和代码一起进 Git 仓库非常舒服。缺点是把布局控制权交给了算法复杂结构很容易生成出绕线或重叠的图。Mermaid 最典型的问题就是节点一多布局基本不受控。自动布局类代表是 D2、Structurizr。这类工具介于前两者之间更强调从架构描述到图示的映射。尤其 Structurizr 是直接基于 C4 模型来组织 diagram 的适合系统复杂度高、需要贴近代码建模的场景。D2 则在易用性和布局质量上做了平衡我实际体验下来比 Mermaid 可控性要好一些。三类工具不是互斥的我的工作流里三者会用在不同阶段。快速梳理想法用 Mermaid/D2需要精细表达时导出到 draw.io 微调需要给高层汇报或产品展示时再挪到 Figma 里精修。重要的是你是在用工具实现设计意图不要让工具反过来限制你的表达。2.2 为什么我最终选择“自建设计规范”而不是堆功能这个观点可能跟主流推荐不太一样但我真实感受是工具的功能是次要的真正决定产出质量的是一套你能持续贯彻的设计规范。之前我在一个项目里同时用过 draw.io 和 Mermaid但产出并不稳定。今天画一张图用蓝色系明天画一张用绿色系今天框用圆角明天用直角。图与图之间没有统一的辨识度放到同一个文档里像三个不同的人画的。后来我花了两个下午给自己做了一份“diagram 设计规范”里面定义了配色板、字体规则、圆角弧度、边框粗细、间距栅格、连线样式、图标风格。此后所有图都基于这份规范产出质量和一致性立刻上来了。规范这件事本质上是在降低每一次做决定时的认知负担。没有规范的时候你每画一个框都要纠结颜色和尺寸有了规范决策全变成了查表。这个换来的效率提升极其可观。我强烈建议哪怕你是个人使用也花一两个小时把规范定下来长期回报率非常高。2.3 从手绘到成品的完整路径流程先于工具还有一个建议动手画任何图之前先用手绘或文字清单把信息架构过一遍。这一步不要用数字工具。原因是数字工具给了你太多“优雅地调整位置”的能力会让你过早陷入细节微调反而忽略了结构本身的问题。一张纸和一支笔你只能画框、写关键词、画箭头但恰恰是这种粗粝的方式逼着你先解决核心问题。我的标准路径是手绘草图确认信息架构然后 Mermaid/D2 快速生成一版可分享的图再根据反馈在 draw.io 或 Figma 里精调视觉细节。这条路径保证了每一层只解决对应的问题草图解决逻辑代码生成解决效率精修解决表达。3. 一套能直接照抄的图表设计工作流随手画图谁都会但要在时间和精力可控的前提下稳定产出高水准的 diagram需要一套明确的流程。下面这些步骤是我在大量实战里磨合出来的一套流程核心思路是先花时间把问题定义清楚再动手画最后统一自检。3.1 第一步用“一句话需求”锁定图表使命《金字塔原理》里有个观点如果一个句子表达不清楚说明你没想清楚。画图是一样的。如果不能用一句话说明“这张图存在的唯一理由”你就不该开始画。这句话要具体到能指导取舍。比如“这张图给新同学看让他们能说清楚下单到支付的完整链路”和“这张图给 DBA 看让他确认订单表的读写压力来源”虽然画的可能是同一个系统但信息详略完全不一样。前者需要业务语义清晰后者需要存储细节突出。我通常在需求的描述里把这句话写死然后画图的每一步决策都拿它来检验。不确定哪个信息该放时就问自己删掉它这张图的使命还能不能达成能达成就是不必要的信息果断删。这个动作能把大量冗余信息挡在半路之外。3.2 第二步信息分组与视觉主次的确定需求定了接下来是穷举并组织信息。不要直接开画先在纸上或文档里列出跟这张图相关的所有模块、实体、系统和流程。列完再分组管理。分组维度一般有两类按层级和按域。按层级是纵向的用户端、接入层、服务层、数据层。按域是横向的订单域、用户域、支付域。大部分系统图其实是交叉的但我建议一张图只突出一个维度另一个维度用颜色或分区弱化表达。两个维度同时拉满图基本就废了。视觉主次上我定三个等级就可以。一级是核心链路或核心系统二级是直接相关的辅助系统三级是外部依赖和边缘节点。一级元素用最大字号二级次之三级最小。颜色饱和度也按这个顺序递减。这样一眼看过去核心信息能毫不费力地跳出来。3.3 第三步网格、间距、对齐规则的落地这一步是最容易被忽略的也是专业 diagram 和业余 diagram 拉开差距最关键的地方。所有元素的位置都对齐到同一个栅格上。最小单元格建议 8px元素的外边距、内边距、元素之间的间距都用它做基准。框和框之间的最小间距我建议不小于 12px不大于 32px。小于这个范围会显得拥挤和贴近大于则显得松散和离散。对齐是另一个高频问题。框的上下边、左右边都要尽量对齐到同一条横线或竖线上。这不是强迫症而是人眼对整齐有天然的好感歪歪扭扭的布局会极大消耗读者的耐心。分组间距要大于内部间距。组内元素间距 12-16px组间间距 32-40px这样才能通过留白“画”出边界而不是依赖画边框。能用留白表达的结构就不要用边框和底色图会干净很多。3.4 第四步从草稿到审查自检与审阅视角画完第一版不要急着发出去。我会强制过一遍自检项缩到 60% 看整体辨识度检查是否有文字重叠或连线穿字确认所有颜色都有意义再数一下图的“噪声比”——装饰性元素和功能性元素的比例。如果装饰占了上风果断砍。然后做一次“上下文视角切换”。我会假装自己是三个人分别读这张图第一次看文档的新手、只关心核心链路的架构负责人、要照图操作或排障的运维同事。三个角色读同一张图需求完全不同。新手要的是全局认知和术语解释架构师要的是边界和依赖关系运维要的是部署维度、环境和链路关键节点。如果能分别满足这三个视角这张图基本就稳了。如果团队有条件找同事做一次 30 秒测试也是一个很高效的办法。把图发过去请对方看 30 秒后回答你三个问题“核心逻辑是什么”“哪部分是重点”“哪里看不懂”。如果答案和你的预期有偏差说明图的信息组织还有问题而不是读者的问题。4. 实战拆解一个系统架构图的完整设计过程理论的讲完我用一个真实项目里的系统架构图来走一遍完整流程。这个案例很有代表性因为它的信息量天然很大最初画出来的初稿就是那种典型的“所有模块同等重要”的混乱图。4.1 需求还原架构图常见的“信息爆炸”问题当时这个系统有三十多个微服务涉及 API 网关、鉴权中心、用户服务、订单服务、商品服务、支付服务、消息队列、缓存集群、搜索集群、多个 MySQL 实例和各种第三方依赖。全画上去一张 A4 纸根本装不下不画全又怕被挑战说架构图没有完整性。这就是我开头说的信息架构决策问题。第一步仍然是先给这张图定使命给新加入团队的后端同学看让他 5 分钟内能准确说出“一次下单请求从进入到落库经过了哪些系统各系统扮演什么角色”。基于这个目标我立刻做了一个很多人都想不到的取舍这张图不追求覆盖所有服务和完整细节只为了讲清楚核心业务链路。这意味着什么三十多个微服务我只在图上保留与下单链路直接相关的 11 个。其他比如搜索服务、营销服务、消息通知服务在这个核心任务下不是重点我选择再画子图来承载架构图表达主脉络就足够了。很多第一次做 diagram 的人在这个节点会失控什么都想画最后画出一张看起来极其完整、实则无人能读懂的“信息垃圾场”。4.2 布局策略分层、分区、路径设计信息筛选完之后布局上我用了“分层 分区”的组合策略。图的主方向是自顶向下最上面是一层是客户端App/PC/H5往下是接入层API 网关、鉴权中心再往下是业务核心层最下面是数据存储层。这种分层方式是系统架构图最通用的也有最高的认知成本效益读者不用猜就知道越靠下越接近数据。分区则体现在把“下单主链路”相关的系统放在图中央偏左的区域用几乎满饱和度的主色把“支撑性系统”比如配置中心、注册中心、监控系统放在右侧用低饱和度辅助色把“外部依赖”如第三方支付渠道沉到最底部用灰色弱化。这样一区分核心主链路和辅助系统一眼就能被分开识别。路径设计上我刻意让主链路箭头贯穿图的纵向直接从客户端一路向下打到底部数据层。整个箭头序列不回头、不交叉在必要回环处用弯曲弧线避开其他连线保证视觉上的流畅感。同时给主链路标注了“1、2、3…”的顺序号。这看着不起眼但对读者的引导价值很高尤其是面对复杂图和多条并行链路时数字顺序能彻底消除阅读歧义。4.3 细节润色标注、配色、字体的一致化布局确定后视觉规范开始起作用。配色上我严格只用四类颜色主链路用深蓝色支撑系统用浅灰色底加深灰字数据层用蓝绿色系外部依赖统一用灰色带虚线边框。除此之外没有任何多余的颜色。这样所有颜色都承担语义不会有人问“这个橙色是什么含义”因为图上根本没有橙色。字体方面统一使用同一字族核心系统用 16px 加粗辅助系统用 14px 常规外部依赖用 12px。三档字号层级明确核心信息在最远距离也能看清。字体不超过两种优先选无衬线体中文场景下思源黑体或者系统默认 Sans 都行。标注细节有一个我积累的小技巧不要在图上写大段说明文字。该注释的内容用编号标注在边框之外或底部小字区图面上的文字只承担标识职责。以保证图面的干净和可读性。最后一步是全局审查字体对齐和连线贴边。所有文字的起点与框左边距离均匀一致线条都连接在框边中点或固定锚点上框间距对齐暗网格。一套微调下来图的质量会彻底不一样。5. 踩坑清单我在 diagram-design 里交过的学费这些坑几乎每一个都真实耗费过我一到几天的时间有的甚至影响到了线上协作。我整理出来希望能帮你省掉这些成本。5.1 最常见的十个图表设计问题按出现频率从高到低排我列过一份 list基本可以覆盖大多数团队内部混乱图的通病核心链路不突出。所有元素一个视觉权重眉毛胡子一把抓。箭头方向混乱。用户读图时视线被箭头牵着画圈不知道主方向是哪里。文字重叠或截断。元素尺寸设计时没考虑字体实际渲染尺寸。颜色无语义只有装饰。用了一堆颜色却不代表任何逻辑分组。框与框之间间距不一致。整个图看起来歪歪扭扭。缺少留白分区。所有内容挤在一起没有组的概念。缩写无注释且也不扩展说明。非本域读者看后和看天书一样。一次画完不迭代。第一版就发出去没有经过自检和审阅。图例缺失或位置不统一。读者靠猜来理解颜色和线型含义。和文档脱节。图的内容和文字描述出现矛盾。这十条里我感慨最深的是第 9 条图例。很多画图的人觉得图例是多余的觉得“每个图都应该能自解释”这确实是对的但自解释不意味着不能有图例。复杂的系统图里有多种虚线、实线、箭头形态、颜色系统一个角落的图例能省下读者大量猜测成本。我自己现在画所有非平凡图都会加图例而且图例本身也纳入设计规范。5.2 复杂度控制什么时候该拆图而不是硬塞图太复杂时最省事的方案不是蒙头硬排而是拆图。一般来说我判断拆图的阈值是核心主链路涉及超过 10 个节点或同一张图上需要表达两个以上独立流程或单方向跨度过大导致文字无法清晰阅读有了这些信号就要考虑拆图了。拆图的逻辑本身也是一种设计决策。我会先画一张“总览图”只保留最高层级的模块和它们之间的连接关系可能只有 5-6 个大块。然后针对每一个大块再画一张“分解图”展开内部细节。两层图之间通过编号或颜色保持关联并在文档里互相引用。这种设计方式在关系型数据库建模领域被称为分层设计。你不用在一个层级里承载全部信息让每张图的信息密度控制在可读范围内整体的表达效果反而会更好。对于读者来说完全不亏先看总览获得全局框架再有需要时下钻到细节图。5.3 跨端展示的适配问题打印、投影、移动端这一点是我踩过坑之后才意识到的同一张图在不同介质上呈现设计要求完全不一样。投屏场景核心信息要足够大。一般会议室投影分辨率是 1080p坐在后排的人看 12px 的文字是很吃力的。这种场景下图上只放核心结构和重大结论细节要么删掉要么放到附录。打印场景注意边界问题。很多工具画出来是无限的画布打印时内容会被自动切到多页出现一个连线中途断掉、箭头切到纸外的惨状。我的方案是提前在图四边留足 20mm 以上的安全边距导出前检查好纸张方向。移动端阅读场景最容易被忽略。手机屏幕宽度有限横向跨度大的图会被缩到没法看。如果你的文档读者很多是移动端就要考虑以下对策之一要么拆图让每张图尽量窄要么就提供高清可缩放的导出文件要么干脆提供图加文字的双轨描述。以前我以为“反正可以缩放”但技术上缩放到某个比例之后细节会糊掉也有操作动作成本这跟阅读体验完全是两回事。我在 diagream-design 的实际演练中最终的习惯是为每个图做一次“双版本输出”一版信息完整的 svg 高清版本用于文档和评审一版精简摘要的 png 版本用于快速浏览和移动端阅读。虽然多了一些工作量但从读者的反馈来看非常值得。最后再分享一个我在实际项目里反复验证过的小技巧把你这套设计规范用一份示例图固化下来而不只是文字描述。示例图本身就是规范新成员拿过来对照学习和复用比读十页设计文档有用得多。团队协作场景里规范的“可复制性”永远大于“理论正确性”而 diagram 设计的手感也正是在这种不断复制与反馈中慢慢长出来的。