1. 为什么图会越画越乱：diagram-design到底在解决什么问题
1.1 图的本质是空间信息，不是方框和箭头
最近在帮一位朋友复盘他手里项目的系统架构图。他改了一周，每次都觉得乱，但又说不上乱在哪。我把图里的元素挨个问下去：这个色块代表什么？这条线是调用关系还是部署关系？右上角那组节点为什么存在？他想了几秒，答不上来。
这个场景我见过太多次。diagram-design（图表设计）看起来是个偏设计的名词，但真正让它变形的从来不是配色、工具或者模板，而是缺少一套"为什么这么画"的思考框架。很多人打开绘图工具就开干，画出来的东西自己都觉得乱，只是不知道问题出在哪里。
文字是线性的，从左读到右、从上读到下，信息只能逐句出现。而图的优势在于二维空间：读者可以在同一屏里同时看到A和B的位置关系、连线方向、颜色深浅。可绝大多数人画图时，只是在用画图的方式写文章——把所有内容从上到下排成一列，完全没有利用"空间"来表达关系。这是diagram-design第一个要解决的事：让空间替你说话。
我在画图前会反复确认一件事：这张图的"空间主语"是什么。上下通常表示层级或时间先后，左右通常表示步骤或并列，距离则表示关系远近。如果你画一个模块时，它的位置没有任何含义，那这个位置就是噪音。
1.2 图乱起来的三个真实根源
我复盘过很多张"越改越乱"的图，最终都能归到三个根源上。
第一个根源是信息没有主线。作者什么都想画，把异常分支、边界条件、历史状态、次要模块全部塞进主图，最后主流程反而被淹没。最常见的例子是画用户登录流程：账户锁定、验证码过期、异地登录提醒全部横在主链路上，读者走三步就得跳去读分支，整张图的主线就断了。
第二个根源是视觉层级失效。所有节点一样大、所有线条一样粗、所有色块一样深。读者扫一圈不知道先看哪里，只能挨个框去读，读完之后在大脑里重新组装结构。这不是图的问题，等于你给读者出了一道拼图题。
第三个根源是装饰过了头。阴影、渐变、透明度、高饱和渐变、每块一个颜色，技术型图表尤其容易踩这个坑。装饰本身不产生信息，但它会抢占注意力，读者看图的能量是有限的，被装饰耗掉了，就没精力去理解结构。
回顾我自己的图，凡是最后被推翻重来的，基本都在这三个问题里。
1.3 有意识设计的检验标准：每个元素都要回答"为什么"
现在我对自己有一个硬性要求：图上任何一个元素，都能在五秒内说清它为什么存在。如果说不清，删掉它，或者把它移到附录。
我给自己设计了一个"元素三问"：第一，这个框、这条线、这段文字，是帮助读者理解，还是增加负担？第二，删掉它之后，图会不会反而更好懂？第三，它和其他元素之间的关系，读者一眼能不能看出来？
举一个具体例子。有人画状态机图，某状态只出现一次，且后续没有任何交互，却因为"状态完备性"把它放在主图里。这个框不产生任何信息价值，只增加了记忆负担。正确的做法是把完整状态列表放进附录，主图只保留核心迁移路径。
这套检验标准听起来简单，执行起来很残酷。你会被迫砍掉大量"画都画了"的元素，但图也正是在这个过程中变得干净有力。
2. 动手前先花50分钟想清楚问题，别让画布背锅
2.1 第一个问题：这张图是给谁看的
我见过的最大的时间浪费，是画了一张"全世界都能看"的图。主流程有了，异常分支有了，部署环境有了，请求链路也有了，最后谁看都费劲。
图表设计的第一步不是选图画布，而是确认受众。给决策者看图，他们要的是关键路径、成本风险、结论建议，信息密度必须低。给执行团队看图，他们要的是模块边界、依赖关系、异常分支，细节必须保留。给外部协作方看图，则要在图中补充术语解释、上下文背景，因为对方没有你脑子里那个"项目上下文"。
| 受众 | 关注点 | 信息密度 | 我惯用的处理方式 |
|---|---|---|---|
| 决策者 | 主路径、结论、风险 | 低 | 只留主干，分支折叠成"详见备注" |
| 执行团队 | 边界、依赖、异常 | 中高 | 完整保留核心节点，异常分支单独子图 |
| 外部协作方 | 概念、流程、术语 | 中 | 补图例、补名词注释，减少隐含信息 |
同一份系统架构，给这三类人看，我会画三张完全不同的图。因为"给谁看"决定了一张图的信息上限，条件变了，图就应该变。
2.2 第二个问题：我到底要在图上表达什么关系
很多人选图表类型时是"看着哪个好看选哪个"，这是本末倒置。图表类型本质上是某种"信息关系"的载体。先想清楚关系，类型自然而然就该确定。
我总结过一个很朴素的对应关系：如果信息是顺序推进的，用流程图；如果涉及多个角色或系统的协作分工，用泳道图；如果是静态的分层和边界关系，用架构图；如果是消息的先后顺序，用时序图；如果关注的是状态之间的迁移条件，用状态机图。
关系是这个句子的主语，图是谓语。你心里要先有一个句子，比如"我想表达'用户下单后，订单系统、支付系统、库存系统之间按什么顺序协作'"——这句话说清楚了，泳道图还是时序图的选择范围已经很窄了。
反过来，如果连"我要表达什么关系"都说不出，那一张图无论选什么类型都会失败。花二十分钟把这个关系写成一个完整句子，比花二十分钟调样式有用得多。
2.3 第三个问题：这张图最后会出现在哪里
图表设计的第三个约束是交付形态。同样一张图，放在幻灯片里、技术文档里、白板讨论里、监控大屏里，设计逻辑完全不同。
幻灯片需要"远距离可读"。我一般按一个经验值估算字号：观看距离每增加1米，标题字号至少要增加7到9pt。如果是3米外看的汇报页，正文字号低于20pt基本等于没写。技术文档的场景反过来，读者是凑近看的，字号可以小，但信息密度可以高，因为看不懂可以回看。白板场景最特殊，你要预留涂改空间，不要画得太满。
大屏场景还要考虑一件事：它是被远距离扫视的，人不会逐字去读。所以大屏图的图层信息要极简，只有最重要的状态色和趋势线。我见过太多人把技术文档里的图直接放大扔上大屏，结果远看是一团彩色噪点。
先确认这三点，再打开绘图工具。这个习惯让我少返工了至少一半的图。
3. 图表选型不是点菜：类型背后的关系语义
3.1 四种最常用的图：流程图、泳道图、架构图、时序图
我在日常工作里，超过八成场景只需要四种图。每种图都有自己的擅长区和禁区。
流程图擅长表达"步骤与分支"。它的阅读节奏是线性的，跟着箭头走就行。但它有一个明显的阈值：如果主流程节点超过15个，读者记住前面就已经忘了后面，必须拆成多张子图，或者用编号分段承接。
泳道图擅长表达"职责边界"。一条条泳道把不同角色、系统、团队隔开，读者能清楚看到"谁在哪个阶段做什么"。泳道图最大的禁忌是泳道数量超过5条——人扫视时能同时记住的横向分组有限，泳道一多，边界感就消失了。
架构图擅长表达"静态结构与层级"。它用方框的堆叠和分区表达系统边界，但不要指望架构图去表达动态调用顺序。动不动在架构图上画几十根调用箭头，会把分层结构搅成一碗面。
时序图擅长表达"消息的先后顺序"。它把参与方排成一列，消息从上往下走，时间顺序天然清晰。但参与方一旦超过6个，连线会交叉成一团。我的处理方式是：拆场景，一个核心用例一张图，不要试图画"全量交互总图"。
| 图表类型 | 擅长表达的关系 | 主要风险 | 推荐克制区间 |
|---|---|---|---|
| 流程图 | 顺序与分支 | 节点过多 | 主流程节点≤15 |
| 泳道图 | 跨角色协作 | 泳道过多 | 泳道≤5条 |
| 架构图 | 分层与边界 | 混入动态流程 | 每个分区层级≤4层 |
| 时序图 | 消息顺序 | 参与方过多 | 参与方≤6个 |
3.2 一个关系，多种候选图：怎么取舍
经常有人问我："我画下单流程，为什么你建议用泳道图而不是流程图？"
因为这里有一个取舍逻辑。同样是"用户下单"这个行为，如果我想表达的是用户操作步骤，那流程图就够了；如果我想表达的是订单系统、支付系统、库存系统之间的协作分工，那泳道图更合适；如果我关心的是消息发送时序，比如先调支付再扣库存、失败之后怎么回滚，那时序图才是正解。
我的取舍准则只有一条：核心问题是什么。把核心问题写出来，然后看哪种图能让读者用最少的步骤得到答案。不要空想，直接画两版草图摆在一起，用眼睛对比，十秒就能分出胜负。
这也是为什么我一直强调"图服务于问题"——当你是为了某个具体问题而画图时，选型几乎不需要犹豫。真正让你纠结的，往往是你根本没想清楚问题。
3.3 克制使用组合拳：一张图只讲一个主要故事
技术图表最常见的翻车现场是"组合拳"：又画架构分层，又画调用流程，还把数据库表关系塞进去，最后再加一段异步消息说明。这种图看起来信息量很大，实际上没有一个信息能被顺利接收。
我给自己定了一条纪律：一张图只允许有一个"主要故事"。如果你的图可以用一句话说清楚，比如"这张图表达服务之间的调用关系"，那它合格。如果那句话里出现了"以及"、"还有"，比如"这张图表达服务调用以及部署环境以及数据表关系"，那它已经过载了，要拆。
拆图的优先级我一般这样排：先拆部署环境，那是静态拓扑；再拆调用流程，那是动态行为；最后拆数据关系，那是另一套语义。三个故事混在一起，读者的大脑在三种思维模式之间来回横跳，图再漂亮也没用。
4. 先有结构再谈配色：画布上的信息架构决定成败
4.1 第一步永远是丑陋的线框图
画图最大的误区是打开软件先找模板、先选配色。我在构思阶段几乎不用正式绘图软件，纸笔或者白板就够。画出来的东西越丑越好，因为丑才能逼你只关心信息结构，不会被"好看"骗过去。
一张图的线框阶段只需要做三件事：划出页面分区，确定主阅读路径，指出明显的信息分组。我举一个最典型的例子，画一条跨部门的业务流程时，线框长这样：
[顶部标题区：流程名称与适用范围] [角色A泳道] 步骤1 ──▶ 步骤3 ──▶ 步骤5 │ [角色B泳道] ▼ 步骤2 ──▶ 步骤4 ──▶ 步骤6 [底部注脚区：异常处理、版本说明、图例]这个阶段不需要任何配色。分区对了，空间关系对了，后面上色只是锦上添花；分区错了，后面怎么调颜色都是错的。
4.2 视觉层级的三级体系
图表的视觉层级，我习惯划分为三级。
一级元素是标题、核心对象、主干路径，它们应该占据最大面积、最深颜色、最粗线宽，确保读者第一眼扫到的东西就是你要表达的主语。二级元素是模块容器、分组区域、次要流程分支，它们应该比一级明显弱一档，但依然能清晰辨认。三级元素是标签、属性说明、辅助注释，它们是背景信息，不能喧宾夺主。
| 层级 | 典型元素 | 视觉特征 | 读者的第一反应 |
|---|---|---|---|
| 一级 | 标题、核心对象、主路径 | 大面积、深色、粗线 | "这就是重点" |
| 二级 | 分组容器、分支流程 | 中面积、中深色、中等粗细 | "这是模块划分" |
| 三级 | 标签、注释、图例 | 小面积、浅色、细字 | "需要时再看" |
有一个特别容易踩的坑：用单一维度表达层级，比如只靠颜色深浅，或者只靠框的大小。我会刻意用面积、颜色、位置三个维度同时强调重点，这样即使印刷成灰度版，层级也不会失效。
4.3 距离和留白也是信息：相近的元素自动成组
很多人画图时特别依赖框。为了表示"这几个节点是一组"，就给它们套一个虚线框，套完一个又套一个，整张图到处都是框，视觉噪音非常严重。
其实不需要框，距离本身就是分组语言。人眼天生会把距离近的元素当成一组，这是格式塔原理里的"相近性"。我画图时会让组内元素间距保持在8到12像素，组与组之间的间距直接拉开到24到32像素，比例基本维持2比1以上。只要距离拉开了，读者会自动看出分组，框就成了多余的东西。
如果一张图里出现了大量虚线框、实线框、圆角框、矩形框去做分组，我会优先怀疑是间距设计出了问题，而不是框的数量不够。
4.4 用眼睛模拟阅读路径：检验结构是否顺畅
图表虽然是非线性的，但也有自己的阅读节奏。大多数人的扫视习惯是从左上角进入，先看标题，再看中间偏上的区域，最后才看角落。我会刻意利用这条路径安排信息顺序。
一个很有效的自测方法：把画好的图缩到很小，小到看不清文字，眯着眼看三秒。如果这时候还能看出"主线大概是从哪里走到哪里"，说明结构是成立的；如果缩小的图糊成一团，问题一定出在结构层级上，而不是配色或者字体。另一个方法更简单：把图转成灰度，再看层级是否保持清晰。颜色会骗人，灰度不会。
我几乎每张图都会做这个"缩小看结构"测试，它能在三秒内暴露我花了三个小时都发现不了的布局问题。
5. 质感藏在细节里：专业图和业余图的基本盘
5.1 配色系统：先定语义，再定装饰
图表配色的核心不是"好看"，是"可记忆"。如果你用了超过三个主色，读者看完整张图之后，很可能记不住哪个颜色代表什么。
我自己的配色习惯是"3加1加灰"：最多3个有语义的主色，1个用于强调异常的强调色，其余全部用灰色系充当结构色。语义色一定要先分配含义：主流程用中性色，比如深灰或深蓝；分支用另一色；异常、告警才动用强调色。这样谁是什么角色，一眼就清楚。
还有一个很容易被忽略的问题：色弱读者。红配绿、红配灰这类组合对色弱人群极不友好，我尽量用"蓝、橙、灰"这类色相差较大的组合，并且始终坚持"颜色只是辅助，不是唯一的信息载体"——重要的语义差异，还要靠线型、图标、标注来兜底。
5.2 字体和字号：让注释也能被看见
字体的混乱程度，常常和图表的专业度成反比。我见过一张图里用了五六种字体，标题一种、模块名一种、注释一种，中英文的粗细还不一样，整张图充满了廉价感。
我一般只维护一套极简的字号梯度：大标题16到20pt，模块标题12到14pt，正文内容10到12pt，注释说明8到9pt。一张图里最多使用两种字重，正文用常规字重，标题和核心对象用加粗就够了。不要再为"美观"去引入第三四种字重，层级靠字号拉开，不是靠字体切换。
中文和数字混排时还要注意对齐细节，数字尽量统一使用等宽数字，避免在表格里出现错位跳动。文字在图上尽量保持水平，不旋转、不竖排，实在放不下就先删掉次要文字，而不是压缩字号。
5.3 线条语言：粗细、方向和箭头的一致性
线条是图表的骨骼。线一乱，整张图的气质就垮了。
我给线条定了一套使用规范：主干流程线最粗，大概2到3px；分支线稍细，1到1.5px；辅助参考线、边框线最细，用0.5到1px。粗细的差异直接告诉读者"这条路径更重要"。箭头也要代表一致的含义：实心箭头表示步骤转移或流程方向，开放三角箭头表示数据流向，无箭头的线表示组合或包含关系。最忌讳的是同一张图里"尖箭头、圆箭头、无箭头"混用，没有任何规律，读者只能靠猜。
线条的转折方式也要统一。直角转折有工程感和硬度，圆角转折显得柔和流畅，我一般在一张图里只会用一种。圆角半径全图统一，比如固定4px，避免出现一个框是大圆角、另一个框是直角的情况。
5.4 标注与图例：减少读者回忆负担
我评判一张图是否友好，有一个很感性的标准：读者看图时需不需要频繁回看。
降低回看次数最有效的办法是"就近标注"。图例虽然规范，但放在角落会强迫读者来回对照色块和含义。我更习惯在关键位置直接写一句短的说明，比如在某个分支旁边直接写"失败重试3次"，而不是让读者去图例里查"橙色实线代表什么"。图例越短，图越好懂。
注释也建议写"结论"，不要写"现象"。一条"支付超时走异步重试"的注释，比"支付流程"有价值得多。读者看图的目的是获取结论，不是替你去解读画面。图表里每多一个需要二次解读的地方，就多流失一部分读者的耐心。
6. 工具只是表达载体：别让选型拖累思路
6.1 不同阶段用不同的工具，别指望一把刀走天下
经常有人拿着某款绘图软件问我"这个工具够不够专业"。我的判断标准一直是"你现在处在哪个阶段"。
构思阶段，纸笔和白板是最快的。它们的好处是即时、可涂改、没有格式包袱，你可以在一分钟之内推翻重画。等到逻辑基本闭环，需要多人协作讨论时，我再转到支持多人同步的白板协作工具，这时候重点是"一起改"，不是"画得美"。到了最终交付阶段，我才用专业绘图工具精修，导出满足文档要求的矢量格式。
选工具的三条底线：能不能快速修改？导出格式是否满足文档要求？团队是否都能打开？三条都满足，这个工具就是合适的。不要为了学某个工具花大把时间，工具解决的是"画得快不快"，而不是"画得好不好"。
6.2 模板可以起步，但必须改造成自己的
模板最大的价值是提供"容器参考"，不是提供"内容答案"。我见过太多人下载一个漂亮的模板之后就往里面硬塞内容，结果模板的视觉元素和实际信息结构完全对不上，越画越拧巴。
正确用法是把模板当成一次"容量测试"：先把内容放进去，然后删掉所有与内容无关的装饰元素，再按自己的信息结构重新组织布局。模板的颜色、字体、间距，并不天然适配你的语义。我几乎每次用模板都要大改，最后留下来的往往只有版式灵感，而不是模板本身。
6.3 图表评审：让别人当你的第二双眼睛
我自己画的图，经常陷入"作者已经看熟了"的盲区。破这个局的唯一办法，是找一个人来做"注意力测试"。
具体做法是，请对方看图，但是不要让他"提意见"——提意见的人会自动进入批判模式，他会去挑毛病而不是描述感受。我会请他回答三个问题：你第一眼看到的是哪个区域？如果要给这张图起个标题，你会写什么？主流程在你看来是哪一条路径？
这三个问题能精准暴露这张图的注意力分配。我曾经自认为画到完美的架构图，就这样被一位同事指出：所有人的视线第一眼全落在右下角的Logo上，而不是主框架。这个发现靠我自己永远做不出来。评审是用来做注意力校准的，不是用来找错误的。
7. 一次改版复盘：三张混乱的架构图如何变清晰
7.1 原始问题：一张图塞了三件事
我处理过一个很典型的案例，某业务系统需要画一张架构图，初稿里同时包含了三套信息：部署环境拓扑、服务模块之间的调用关系、一次请求的完整时序。
这还不是最要命的，最要命的是三套信息没有任何视觉区分。方框一会儿代表服务器，一会儿代表服务模块，一会儿代表数据表；颜色随机分配；线条交叉密集。读者读完图约等于做了三套题，第一遍根本不知道该按什么顺序看。
典型症状在这里其实已经很清晰：没有标题层级，所有区块平等；节点没有任何分组规则，读者无法自动聚类；颜色没有语义，只是不同区域用了不同颜色；几十条连线交叉，主路径荡然无存。
7.2 改版路径：五步清理法
我接下这张图之后，用了五步把它彻底拆干净。
第一步，先问"给谁看、表达什么"。这张图最终是给部署运维的人看环境边界的，不是给人看调用时序的。于是在这一步已经决定了要拆图。
第二步，拆。把部署环境、调用关系、请求时序分别画成三张独立图。每张图只允许有一个主语。
第三步，为每张图选定主干路径。比如部署图画的是"接入层、应用层、数据层"的分层；调用图画的是"核心链路从订单服务到支付服务到库存服务"；时序图画的是"下单请求的完整消息序列"。
第四步，重新布置空间。把主干放在画面中央或左上到右下的黄金路径上，次要模块往两侧让位；统一线型、统一配色、统一字号梯度；用间距做分组，去掉多余的虚线框。
第五步，盲测。找一位不熟悉项目的同事看图，记录他的第一反应，再根据反馈微调标注和图例位置。
| 步 骤 | 核心动作 | 解决的问题 |
|---|---|---|
| 定义 | 确认读者和核心关系 | 避免信息过载 |
| 拆图 | 一图一主语 | 消除三种语义混揉 |
| 选主干 | 确定视觉第一路径 | 让读者知道先看哪 |
| 布空间 | 统一网格与间距 | 建立清晰层级 |
| 盲测 | 记录第一直觉 | 发现作者盲区 |
这套流程走完，原本"一图三讲"的方案变成了"一图一讲"的三组件，每张都能在三秒内找准主线。
7.3 改版后的经验清单：能复用的判断标准
这次改版给我留下几条可以用在任意图上的判断标准。
一张图只讲一个主语，这句话怎么强调都不过分。如果你发现图里有两个主角，大概率需要拆成两张。先分区再连线，这句话直接对应"距离先于框线"：结构错位时先调整空间，而不是急着画画框去补救。颜色必须先有语义再谈好看，否则你只是在用颜色做装饰，而不是传递信息。把图缩小看灰度，这句话是视觉层级的终审法官，任何花哨的配色在灰度下都会现原形。评审测的是注意力，不是找错。
这些标准没有一条需要高级审美，它们只是把"读者怎么理解"放在"作者怎么表达"之前的常识而已。
8. 我长期在用的几个"反直觉"小习惯
8.1 缩小看结构，放大看细节
我画完一张图，永远不会直接交出去。第一件事是把它缩到看不出字的程度，眯着眼看三秒。这个动作我坚持了很长时间，它帮我砍掉了大量"看起来很精致但结构上失败"的作品。如果缩小的图看不出主线，那问题一定出在布局和层级，与配色、字体无关，此时我会直接回到线框阶段重排，而不是在细节上继续打磨。
8.2 任何图都有版本号
听起来很土的规矩，但救命。图表改版最可怕的是"我明明记得有这一版，但文件找不到了"。我现在的做法是给每一版图都记录改动点：这版改了层级，那版改了配色，这个分支是从哪个版本演化来的。改到第三版的时候，这个习惯会替你省下一整个下午。
8.3 评审时请对方描述而非提意见
我在前文讲过一次，但值得再强调：请同事看图时，千万不要问"你觉得怎么样"。这句话一旦问出口，对方就会进入找茬模式。我一般会问"你第一眼看到了什么"、"你会怎么给这张图起名"。这两个问题测出的才是真实的阅读体验。好的图表能让不同的人说出相近的主线，如果你的观众各说各话，那问题多半出在图本身，而不是观众的理解力。
diagram-design说到底不是技术，也不是审美，它是一个"替读者扫清障碍"的过程。你替读者想得越细，图的表达就越干净。画图之前多问自己三次"为什么"，画完之后请别人替你测一次注意力，这两件事做好，你的图会立刻和大多数人拉开差距。
