1. 为什么大部分技术图，看着专业其实没法用
先聊点真实的。我去年参与过好几次架构评审会，发现一个高频现象：投影仪打开一张架构图，画得很整齐，五颜六色，方框箭头一应俱全。可在场的每个人对这张图的理解都不一样。讲的人顺着自己的思路从左上角开始说，听众却在努力找“上一个模块到下一个模块之间丢掉的链路”。一场会开下来，问题没讨论清楚，倒是在图上标记了一堆口述才能生效的信息。这不是某一个人的问题，而是 diagram-design 里最常见的失败模式——把图画“漂亮”了，却没把信息画“明白”。
这里说的 diagram-design，指的不是某个具体的绘图软件，也不是单纯的“草图技巧”，而是一整套从信息拆解到视觉落地的设计方法。它覆盖架构图、时序图、数据流图、部署拓扑图、业务流程图，甚至一张简单的功能关系示意图。它的核心工作是回答三个问题：这张图要向谁传递什么信息？什么信息可以砍掉？哪些信息必须被一眼看到。
我一直觉得，技术图本质上不是“文档”，而是“一次无声的讲解”。它像一份讲稿，读者阅读的顺序、视线落点的优先级、模块之间的逻辑衔接，全都可以被设计。大多数让人困惑的图，问题不在“画得丑”，而在“顺序失控”和“层级缺失”。静态图既然不能让讲解者时刻在旁边解释，就必须靠自身的结构把话说清楚。
很多年前我看过一位老工程师画系统图，全程只用黑白两色，直角折线，模块大小严格按依赖关系排列，注释少得可怜。当时觉得这种图“寒碜”，后来才意识到那是被反复锤炼过的结果——每个元素都有存在理由，每条连线都代表真实调用关系。反观我早期画的图，装饰性渐变、圆角、图标、不同颜色的阴影都有，但核心链路要指给别人看，得用手指一路追过去。这就是典型的“视觉噪音吞掉了信息结构”。
所以这篇内容不想再做工具罗列，也不想给一堆“画好看”的套路，而是想认真拆一拆 diagram-design 这件事。我会把我踩过的一些坑、总结出的设计前置流程、不同场景下的工具选择逻辑，以及最容易翻车的视觉细节，按实操顺序完整过一遍。适合谁看呢？给那些需要画架构图、流程图、项目方案图但又总觉得“图出来以后差口气”的开发者、产品经理、设计师和项目经理。
2. diagram-design 的核心不是元素，而是信息结构
2.1 先搞清楚图的三层结构
我如今画任何一张稍微正式一点的技术图，动手前都会先在脑子里过一遍三层结构：语义层、关系层、视觉层。
- 语义层：图中会出现的所有“实体”，模块、服务、角色、数据表、节点，以及每一类实体对应的边界。
- 关系层：实体之间真实存在的连接，调用、依赖、反馈、数据流动、时序约束，以及这些连接有没有方向、有没有条件。
- 视觉层：如何用位置、大小、色彩、连线的曲直与虚实，把前两层表达出来。
多数人画图时直接从第三层起步——打开工具，拖入方框，选颜色，开始连线。这么做最大的问题是，视觉表达会反过来绑定语义和关系。比如你把某个模块放在了画布正中央，就觉得它“应该是核心”；你把连线画成了带箭头的实线，就可能忽略它其实只是异步事件通知。这种“先画后想”的方式，等到图需要改时，牵一发而动全身，很快就不想改了。
正确顺序应该倒过来：先把语义层的东西列全，再确认关系层哪些该画、哪些不该画，最后才谈视觉层怎么呈现。这一条我是在一个模拟项目X中吃亏后长记性的——当时画一个跨系统的数据同步方案，我急着把漂亮的部署图做出来，结果把消息队列的异步链路画成了同步调用，评审时被纠出来，整张图的箭头方向全要返工。
2.2 信息取舍：一张图只讲一个核心叙事
diagram-design 最容易犯的错，是把所有信息都塞进同一张图。画架构图时，既想表现部署环境，又想表现服务间的调用链路，还想顺带标注网络隔离策略，最终结果就是图上一锅粥。
我给自己定了一个原则：一张图只讲一个核心叙事。如果这张图的核心叙事是“服务间依赖关系”，那么机房分布、域名配置、网关策略细节就应该隐去或用简化标签代替，用单独的附图展开。所谓的“完整”，不应该是元素上的面面俱到，而是叙事上的闭环——读者看完，能回答“这个系统的关键机制到底是什么”。
取舍的标准我给三条：
- 这个元素能否支持核心叙事？不能就删，最多放附录图。
- 这个连线能否被一眼看懂方向？如果要从图例反查，就说明结构有问题。
- 去掉这个标签，读者会误解整体逻辑吗？会就保留，不会就删。
有一回我画数据库迁移方案，把几十行的字段映射表也放进了图里，结果整张图变成了 Excel 平移。后来我把字段对应关系抽成附表，图中只保留“迁移链路 + 回滚节点”，读者理解难度立刻降了一个台阶。信息设计，本质上就是帮读者节省认知负担。
2.3 分层展示：用“多图组合”替代“单图硬塞”
遇到复杂的系统，我更倾向于做一组图，而不是拼一张“超级大图”。一组图里有总览、有局部、有时间轴，各自承担不同职责。
- 总览图：展示系统整体边界，模块群之间的交互关系，基本不出现类级别细节。
- 局部图：聚焦某个关键链路或某个复杂模块，把内部组件、接口、流转条件放大讲清。
- 时序图/状态图：补足局部图中表达不出来的时间维度。
这个思路很像地图应用的比例尺缩放。没有人在一张地图上看完整个国家的道路规划，但每个人都依赖“先全局、再局部”的阅读方式。diagram-design 也一样——读者需要知道自己当前在图的哪个层级，才不会迷失。
拿一个我经历过的线上支付系统拆解项目举例。客户方特别强调要把从用户下单到资金清算的全链路画出来。如果只用一张 Deployment 架构图，支付网关、账户系统、风控系统、银行渠道网关、清算对账模块全部平铺，光是箭头就会超过四十条，视觉上几乎没法读。我们最终交付的是：一张全域总览图、一张“用户订单主链路时序图”、一张“异常补偿与对账”流程图，外加一张部署拓扑图。评审时主链路图看得最久，但它一点也不乱，因为每张图只讲一个层面。分层的理念，本质上就是用多张图的结构复杂度，交换读者对每张图的理解速度。
3. 从白板到交付：一次完整的架构图设计实操流程
3.1 信息采集阶段并不需要打开画图工具
我见过很多人在刚拿到需求时，就直接打开画布开始拖矩形，这是效率最低的方式。相比之下，我更推荐先在纯文本里完成一次“信息清点”。
第一步，把自己能想到的所有模块、系统、角色、数据落点全部列出来。一条占一行，不排序，不用管会不会重复。 第二步，针对每个条目补一句“它在这张图里承担什么角色”，如果答不上来，大概率是这次叙事不需要它。 第三步，画一份粗糙的邻接表，描述模块之间的调用或者依赖方向。这一步是最累的，但也是最赚的——后续图的正确性全在这里决定。 第四步，标出哪些连线是“主叙事链路”，哪些是“辅助链路”。主链路的表达力度在最终图里要有明显区分，不能和辅助链路同权展示。
这个阶段我一般用纯文本文件加缩进完成，不用任何专门工具。原因很简单：文本便于快速修改、便于对比增删，而且不会因为“图已经画好看”而舍不得删元素。视觉一旦固定，人就容易对信息错误产生容忍，这是心理惯性。文本阶段的结构越稳，后续画图的返工成本越低。
3.2 草图阶段：用位置表达主次，而不是用颜色
信息清点完成之后，我会在纸上画一版“布局草稿”。这个阶段我不考虑配色，不考虑图标，只确定每个模块在画布上的相对位置。
我有几个固定的布局原则：
- 主链路按照阅读方向从左到右或者从下到上排布，别把核心模块放在角落。
- 围绕核心模块的辅助模块，遵循“强相关者靠近，弱相关者远离”的规则。
- 对应层面的模块尽量放在同一条水平带上。比如网关层放最上面的横带，业务服务层放中间，数据层放最底，这种分区能为读者建立强烈“这个位置代表什么”的预期。
- 连线在草图阶段就规划好走向，避免最终出现大量跨度过长的折线。
草图画完后，我会对着它做一次“阅读测试”：不借助任何口头解释，只用眼睛扫描图上的结构，看能不能把主链路从起点读到终点。如果中途有迟疑或回溯，说明位置排布还有问题，需要调整。这一步不解决，后面做再精致的视觉也是空转。
3.3 工具成图阶段：布局优先于配色
从草图变成正式图的时候，我会先锁死布局，再谈样式。很多人习惯边摆位置边调颜色，这样容易陷入“调色半小时，布局依旧乱”的泥潭。正确做法是，工具里先把所有框体按草图位置放好，连线全部用默认样式拉通，然后整体审查一次布局结构，确认无误后，再做色彩和字体的收尾。
成图阶段我锚定的三个视觉变量很简单：
- 大形状决定实体边界，尽量用矩形和圆角矩形，少用奇形异形的图形。读者认知负担最小。
- 颜色只做“层级标签”和“状态提示”，不做装饰。
- 线型表达关系性质，实线表示确定性强的关系，虚线表示间接、异步或备份路径。
有一类图非常容易栽在“用色过度”上，比如用十种颜色区分用户端、管理端、运营后台、数据库分片、缓存集群。第一眼看着五彩斑斓，第二眼就不知道该先读哪块。如果你发现颜色数量超过了五种且每种都在传达“这个模块不同”，通常应该停一下，想想是不是要在结构上做分层，而不是继续加颜色。
3.4 连接线设计的隐性成本
连接线是 diagram-design 里最容易被低估的元素。它看着简单，实际上决定了读者阅读这张图是否顺畅。
我总结过一套连线使用的默认偏好：
- 直角折线优于弧线优于斜线。直角折线在视觉上和逻辑上的“指向性”最明确，斜线和弧线在日常 render 漂亮的图里多，但阅读时很容易让人失去坐标参照。
- 连线穿过任何区块都是大忌，要么调整经过路径，要么通过对侧引出。
- 两条线交叉时，尽量保证主线路径完整，让分支线绕行。
- 连线上尽量标注动词短语，确认这条线“做了什么”。没有线标的连线数超过总连线数的三分之一，说明图的信息表达还有空缺。
在具体项目里我还发现，很多读者对线的语义有模糊猜测。有人把虚线默认读成“异步”，有人把双向箭头读成“双向依赖”，也有人把箭头默认读成“调用方向”。如果你的图里存在这些有可能产生分歧的用法，一定在图例区给出明确说明，而且图例本身也要简洁。图例出现三行以上，就说明这张图的线型体系已经太复杂了。
4. 工具选型的三个管辖区：画布型、代码型、生成型
4.1 画布型工具的适用场景与边界
以自由拖拽为主要交互方式的绘图工具，是 diagram-design 最常见的载体。它们的优点是上手快、调整直观、适合协同讨论，适合画业务拓扑、部署结构、用例关系这一类强空间排布的场景。缺点是图形与数据绑定弱，一旦模块数量多，想整体保证对齐和节奏，就得靠人工拖到眼瞎。
在画布型工具里做复杂架构图，我给你几个绕开崩溃的建议：
- 善用“组合”或“容器”能力，把同一个子系统的内部元素包成一组，折叠后在总图里只留一个出口入口，展开时再打开局部细节。
- 配一套团队通用的样式预设，包括字体、边框粗细、色彩色板、连线箭头终点。大家把默认配置统一之后，协作出的图风格才一致。
- 定期做“合并整理”，不要一人一个版本，最终合并时满地都是重叠元素和重复模块。多人实时编辑虽然方便，但最好的方式还是约定“主线一个人维护，分支另建画板，最后统一合流”。
画布型工具的天花板不在体验，而在你对图的信息结构有没有想清楚。再顺滑的拖拽，也无法阻止结构混乱，这个锅工具不背。
4.2 代码型工具：用脚本管理高频更新图
当一张图会随代码仓库频繁迭代，比如接口变更、服务拆分，或者模块数量异常庞大，我建议考虑代码型的绘图方案，声明式的写节点和连线，由工具实时渲染成图。这种方案最大的优势是版本化、可 diff、可脚本生成，维护成本低。
用代码型工具画图，其实非常适合复用模板。把一种结构抽成公共片段，比如把“标准服务节点 + 健康检查探针 + 数据存储”做成一个可复用组件，以后画同类节点只需传参数。我见过有团队连生产环境部署图都是 CI 脚本直接推送生成，发布一次，图自动重建，从根源上杜绝了“图库和实际不一致”的经典问题。
这条路更适合具备一定工程习惯的团队。代价是学习曲线是真的陡，日常非高频绘图场景反而画得慢。所以我的建议很务实：静态方案图、概念讲解图用画布型工具；长期运营维护的技术地图、系统架构快照，尽早迁往代码型。
4.3 生成型工具的定位：辅助而非替代
现在很多“图生成”功能越来越强了，从一段文字就能生成文字流程图，还可以二次编辑。我的使用习惯是把这类工具当作“信息结构草稿机”而不是终稿工具——让它快速把文本转成初始拓扑布局，能节省很多白板起稿的时间。生成出来的图常常元素过于均匀堆叠，缺少层级主次，直接拿去交付还是不够。
有类工具专门从代码生成调用关系图或依赖图，这个在排查现状时很有用。我自己经常用它反向对照“架构图上画的是不是代码里真实发生的”，以便及时发现图实不一致。如果你想生成一张从阅读角度更合理的架构图，还是得人工介入做信息减法和层级排布。生成型工具负责给你一个全景底稿，diagram-design 的真正价值在于你基于底稿做的删改和重排。
5. 视觉避坑清单：颜色、标注重、以及两类最容易翻车的图
5.1 色彩的“语义优先级”原则
视觉层的颜色设计，我给自己定了一个特别死板的规矩：先用黑白灰把信息结构画成立体的，再考虑添加颜色。如果去掉颜色，图的基本逻辑依然成立，说明色彩只是辅助；如果去掉颜色，图立刻看不懂，说明你其实在用颜色硬撑结构。
颜色的使用优先级我建议这样排： 第一优先级，状态区分，比如正常流程、异常分支、降级路径。 第二优先级，层级区分，比如核心服务、支撑组件、外部依赖。 第三优先级，紧急强调，比如本次变更重点组件、已发现风险节点。 装饰性颜色可以直接不进候选池。
还有一个经常被忽略的细节：颜色要考虑色觉偏差用户。红绿作为“正常/异常”的唯二区分手段，对部分读者是天然障碍，加一个图形符号比如对勾、叉号或三角形同色提示，成本不高，对图的可读性提升却很实用。这些细节，我觉得恰好是“有经验的人画图”和“新手画图”的分水岭。
5.2 标注重配：注释的加法与减法
很多人画图时容易沿用一个错误直觉：标注越全越负责。实际恰恰相反，图上文字标签越多，读者定位关键信息的耗时越长。标注也分轻重，我习惯把标注分成“必须留在图上”和“可以挪进图例或附录”两类。
必须留在图上的标注，我只会保留三种：模块名称、核心链路的连线语义、节点或区域的关键状态。至于像“HTTP”“数据库连接池”“渠道超时阈值”这类次要属性，能不进图就不进图，频繁换行的小字是阅读体验的杀手。如果模块数量特别多，我通常会在图边上留一块儿独立的“图例区”或者“注释区”，把所有细碎的说明集中在那里，而不是散布在整张图的各个角落。
还有一个操作细节：所有的文字尽量平行或垂直摆放，不转夹角；文本字号尽量统一，同层级的元素字号必须严格一致。斜向文字看起来很自由，但代价是读者必须歪头阅读，这种成本累积起来特别可怕。
5.3 架构图翻车的高频原因：把“组件关系图”画成了“部署资源图”
这类翻车在项目评审中太常见了——整张图画的是网络、可用区、IP、负载均衡、容器 Pod，每个部署颗粒都画得很细致，唯独没有传达业务链路的流转。读者看完知道系统“部署在哪里”，却仍然不知道数据是怎么在系统内部流转的，也不知道某个模块依赖另一个模块的什么接口。
想让部署架构图真正发挥作用，务必要把“部署层级”和“应用逻辑层级”分开表达。如果必须在一张图内兼修，就用容器边框把部署环境包起来，再用内部嵌套更细的框表示模块逻辑归属。千万别把 Pod 和 Service 全都平铺成一层小方块，那样信息层级立即清零。
5.4 流程图翻车的高频原因：条件分支没有跳出“自上而下思维”
画业务流程图或状态流转图时，很多人因为习惯了纵向阅读，会把分支条件和主流程全部纵向堆叠。比如“判断是否过期”这个分支，一条向下写“未过期”，另一条继续向下写“已过期”，结果就是画面连续很长，很难分清什么时候回到主线。
我的建议是，把异常分支和弱化路径统一横摆或者侧摆，让主流程始终占据版面中心的固定走向。分支条件写得越偏离主视觉轴，读者越容易区分主次。这是流程图设计里最实用的一招，也是我优化过好多版流程图后才总结出的价值点。
5.5 助力排错的规范模板自查清单
最后给你一份我平时提交前会快速自查的 checklist，方便避免低级问题：
- 所有连线方向都确认过语义，没有“模棱两可的箭头”。
- 主链路从第一眼就能读通，中途不需要寻找起点。
- 所有模块名称与代码仓库、配置中的实际命名保持统一，不出现昵称和缩写混用。
- 颜色与线型含义保证全文一致，且存在图例。
- 容器边界和嵌套关系能一眼看清，没有框套框却看不出从属的错觉。
- 缩放导出后小字仍能辨识，不然就考虑裁切或拆图。
写在最后的一点体会
这些年我看了很多图、画了很多图、也推翻过很多图。最大的感受是，diagram-design 这件事的底层，根本不是“有没有美术天赋”，也不是“用什么软件更高级”。它就是一门关于信息减法和阅读节奏的工程。每一张能被快速消化、不会被第二个读者误解的图，背后一定是有人替读者提前想清了信息的优先级与结构。
我会建议你从下一个真实需求开始，试着先不打开绘图工具，用文本把模块和关系列一遍，然后再上手画。哪怕只是多花十分钟做信息清点，产出的图和以前也会是两种水准。我至今还保留着一个习惯：无论拿到多么成熟的模板，画完图后一定关闭电脑，用手机看一张压缩小图，看三秒钟能不能说出这张图的核心链路。说不出来，说明还需要改。能说出来，才说明它已经配得上被拿出去给更多人看了。
