做过一阵子diagram-design相关的事情之后我最大的感受是画图工具从来不是瓶颈真正难的是在动手之前想清楚这张图要给谁看、要传递什么信息、读者看完之后要做什么。同样是画一张系统架构图有人画出来是满屏矩形加连线看的人一头雾水有人画出来是清晰的三层结构加几条核心链路扫一眼就知道数据从哪来、经过谁、落到哪去。差距不在绘图技巧而在设计方法。这篇文章我想把自己在diagram-design上沉淀下来的整套思路整理一遍包括图表类型选型、布局和信息层级设计、用文本化 DSL 管理图表源文件、配色与导出的细节以及最容易被忽略的图表验证方法。不管你是要做方案汇报图、技术架构图、业务流程图还是产品功能导图这套方法都能直接用重点是让图经得起推敲而不是只追求好看。1. 先搞清图表要回答的三个问题给谁看、看什么、看完做什么很多人画图一上来就打开画布琢磨颜色和字体结果画完之后反复改。我现在的习惯是画任何一张图之前先用几句话把下面三个问题写下来写不清楚就不动笔。1.1 读者决定图表的密度和颗粒度同一个系统架构给研发同事看可以画到服务名、端口号、数据库表级别给业务部门看只需要画清楚前端→业务处理→数据存储三个大块给决策层看可能只需要表达本地化程度够了、扩展风险在哪里。读者决定颗粒度这是图表设计的第一原则。我在实践中会用一个问题来校准读者是否能只看图本身不靠你口头解释就理解结构如果答案是需要逐块讲那说明颗粒度选错了。颗粒度太细读者淹没在细节里颗粒度太粗读者觉得图没信息量。经验值是一张图里主节点数量控制在 7 到 12 个超过这个数一般人都需要来回扫视才能记住结构。1.2 图表的动词决定类型描述现状、梳理流程、还是定位问题我习惯把图表要承担的任务翻译成动词到底是描述当前系统长什么样还是梳理一个流程如何流转或者是定位某个瓶颈卡在哪。动词不同选图类型完全不同。描述现状适合组件图、架构图、分层图梳理流程适合流程图、泳道图、状态图定位问题适合用依赖图、时序图或者加了高亮的链路图。很多人一张图又描述结构又描述流程结果图上既要有矩形分层、又要有箭头流转还要标红位置最后成了大杂烩。我的建议是一张图只做一个动词多动词就拆图。1.3 输出物决定成图尺寸与介质这个很多人会忽略。同样的内容投到投影幕布上和放进文档里设计方式完全不一样。投影幕布的图不能有太细的字号不能有过于密集的连线文档里的图可以慢慢看能承载更多细节如果是打印黑白版本那就必须避免用颜色做唯一区分的语义。我通常在动手前就确定最终输出物是汇报用的大图还是文档里的插图还是演示文稿里的一页。输出物定了画布尺寸、字号下限、线宽、配色方案就全都跟着定了后面不用返工。2. 图表类型选型别让流程图承担所有工作和不少人协作过之后我发现大家最爱画的图是流程图但流程图并不是万能解法。很多信息其实用其他类型的图来表达效率更高。我把高频用到的图表类型和适用场景整理了一下。2.1 六种高频图表与它们的真实适用场景图表类型核心表达什么时候用什么时候别用流程图活动与决策顺序业务流程、操作步骤、异常处理路径表达结构关系时误用比如层级归属架构图系统组成部分与关系系统分层、模块归属、部署结构表达时间顺序时需要配合时序图不能硬画时序图参与者之间的消息顺序接口调用链、跨系统协作、事件顺序只是静态依赖时用依赖图更直接泳道图角色/系统与流程的关系跨部门流程、职责边界、接力过程单人单系统的简单流程用流程图更清爽思维导图主题分解与归类头脑风暴、需求拆分、知识整理表达严格先后依赖时不适用依赖图节点之间的依赖关系模块依赖、任务依赖、故障影响分析规律强、方向明确的流程还是用流程图我在diagram-design过程中最大的体会是选型不是越复杂越好而是越贴合信息结构越好。比如表达哪些模块依赖哪些模块用依赖图一张就能说清如果硬用流程图画出来的箭头方向反而会误导人。2.2 一张决策判断表帮你快速选型为了让自己和团队伙伴不纠结我做了一个简单的判断顺序照着走基本不会错先判断要表达的是结构还是过程。结构走架构图/依赖图过程走流程图/时序图。如果是过程再判断有没有多个角色或系统参与。有则考虑泳道图没有则普通流程图。如果有明确的先后顺序和等待关系时序图优先于流程图。如果是梳理思路和发散想法思维导图优先因为它不强迫你过早确定顺序。这个判断顺序的核心逻辑是先定图的性质再定图的复杂度层级。很多人选错图是因为直接跳到了我习惯画哪种图而不是从信息本身出发。2.3 组合图的边界什么时候适合拆分我理解大家都希望一张图把事说完但组合图非常考验设计功力。我的经验是只有当两个视角共享同一组节点并且读者可以同时对照时组合才有价值。比如架构图里在某个环节加一条高亮的数据链路让读者同时看到静态结构和链路走向这种组合是合理的。但如果两个视角需要不同的阅读顺序组合就会互相干扰。比如同时表达模块依赖关系和处理流程顺序一个是寻找最短路径、一个是沿时间线推进读者大脑会在两种模式中切换反而读不快。碰到这种情况拆成两张图一张讲依赖、一张讲流程中间用统一的命名关联效果更好。3. 布局与信息层级diagram-design的骨架工程布局是图表设计中被人低估最多的地方。很多人觉得布局就是把节点摆整齐实际上布局决定了读者的扫视路径和信息获取效率。布局不合理再好看的配色都救不回来。3.1 主方向的确定时间轴优先与依赖优先每张图都应该有一个主导阅读方向读者不需要思考就知道从哪往哪读。流程图和时序图通常用自上而下表达时间顺序这是最符合阅读习惯的方向架构图和依赖图通常用自左向右表达依赖传递关系源在左、目标在右。我在实际画图时会在画布的角落先画一个极小的方向箭头提醒自己全图都要服从这个方向。一旦某个分支的方向与主方向冲突我就会优先调整布局而不是保留这个分支。方向统一带来一个非常大的好处读者可以用扫视而不是搜索来读图认知负担会明显下降。3.2 节点分组、锚点与留白的底层逻辑节点不是散落在画布上的应该有自己的物理边界。我常用两种方式组织一种是在语义上把相关节点圈到同一个容器里构成分组另一种是用更大的间距形成视觉分区。容器适合表达强归属关系比如一个服务内的多个组件间距适合表达弱相关不希望通过额外的视觉框增加噪音。留白不是浪费空间它是给读者分段呼吸的机会。我的经验是分组之间的间距至少要是组内间距的 1.5 到 2 倍这样读者能自然地感知到层次。同时每个分组最好有一个明确的锚点节点通常是负责对外交互的那个节点把它放在分组的边缘、靠近图中心的方向这样组间连线会变得规律很多。3.3 交叉线治理超过三条交叉就该重新布局连线的质量直接决定图是否能被读懂。我给自己定了一个硬性规则任何一张图里连线交叉超过三条就必须重新布局因为交叉线会打断扫视路径需要读者的眼睛走回头路。减少交叉有几个实用手法第一调整节点顺序把有连线关系的节点尽量靠在一起第二增加锚点层让连线先汇聚到分组接口节点再连接到外部而不是每个节点都直接连出去第三允许部分连线走向走一段绕行虽然路径变长但只要绕行方向固定读者依然能跟踪。我经常见到有人为了省一点空间把连线拉得很近结果整张图像一团毛线省下的空间反而被读图成本吃掉。4. 用文本化DSL管理图表从手工拖动到可复现画图这件事最痛苦的地方就是重复修改。后来我把源文件从图形画布换成了文本描述也就是自己设计了一套简单的 DSL用文本定义节点、关系和分组再由脚本渲染成图。这个改动让diagram-design的整个流程变得可提交、可 review、可回溯。4.1 为什么选择文本作为图表的源格式图形画布的优势是所见即所得但问题在于修改成本高、难以对比差异、难以评审。文本源文件可以像代码一样管理改动一行描述重新渲染一次就能看到结果也能用 diff 看到两个版本之间到底改了哪里。对于需要频繁更新的架构图这个优势是决定性的。另外一个隐藏优势是复用。一个模块在架构图里出现它的描述可以直接用在另一张局部详图里不需要重新画。文本源让我可以把节点定义和图分离节点是数据布局规则是逻辑渲染只是把两者合起来这比每次重新摆框拖线高效太多。4.2 自定义DSL的最小实现节点、关系、泳道我设计的 DSL 只保留了三个最小概念节点定义、节点之间的关系、可选的泳道分组。下面是一个接近我实际使用形式的示例nodes: - id: web name: Web 前端 group: client - id: api name: API 服务 group: server - id: db name: 数据库 group: storage - id: cache name: 缓存 group: storage edges: - from: web to: api label: HTTPS 请求 - from: api to: db label: 读写数据 - from: api to: cache label: 访问热点 lanes: client: 客户端层 server: 服务层 storage: 存储层渲染脚本拿到这份描述后会先按lanes把节点分区再在区内部做自动布局最后根据edges画箭头。因为布局规则是固定的只要数据是确定的出图结果就是稳定的不会出现手动画图时这次摆得高一点、下次摆得低一点的随机性。4.3 渲染管线与版本协同我把渲染过程拆成了三步解析 DSL 结构、计算布局坐标、绘制输出。每一步都有对应的调整空间。解析阶段可以做校验比如发现引用了不存在的节点就报错布局阶段采用分层思考先排泳道内节点再排泳道间连线绘制阶段负责配色和字号。在团队使用时这个方式的优势更加明显。所有图表的源文件进版本库任何人想改图提一个改动描述即可评审人能清楚地看到你改了哪个节点、加了一条什么连线、把谁从哪个分组挪走了。相比你把这张图画得好看一点的口头沟通文本化的流程让图表协作变成了工程协作。5. 读图成本控制配色、字号、图例与导出布局解决的是路径问题样式解决的是注意力和可读性问题。很多人把配色当成装饰但在图表里颜色本质上是第二套语义系统用不好会严重干扰读者。5.1 颜色是语义不是装饰我给图表配色的核心原则是颜色的数量等于语义类别的数量同一种颜色只表示同一种含义。比如在架构图里蓝色代表基础服务、绿色代表业务系统、红色代表需要关注的风险点一旦这样约定全图所有出现红色的节点都必须和风险相关不能为了好看突然把某个无关节点也涂红。我建议一张图的颜色数量控制在三种主色以内最多再加一种强调色和一种警示色。超过五色的图表读者看第一眼会觉得丰富但第二眼开始就要不断回忆这个颜色是什么意思记忆负担会显著上升。如果实在需要区分更多类型优先用形状、图标、线型来分担而不是无限增加颜色。5.2 字号分层与标签策略字体大小和标签措辞也属于隐形的设计细节。我固定的分层是图标题最大主节点名称其次连线标签最小但必须能看清。主节点名称字号建议与正文同级或略大连线标签字号可以小一到两号但不能小于可读下限。标签措辞方面我的经验是动词 对象比名词更有利于读图。连线标签写读取配置比只写配置好写推送告警比写告警好因为动词让读者直接理解箭头动作的方向和语义。另外标签尽量不要跨多条线如果某个标签需要读者绕好远去找对应连线那就把标签搬到连线的起点附近。5.3 导出与嵌入场景的适配图的最终形态是由导出场景决定的。投屏汇报需要足够大的字号和粗线导成高清位图时建议用两倍分辨率导出嵌入文档需要兼顾清晰度和文件体积矢量格式通常比位图更合适如果还没确定背景导出白色背景永远是最稳妥的选择。透明度也是一个容易被忽略的坑。有的渲染结果在深色画布上很漂亮但贴进白底文档之后半透明背景的图层叠出了不该有的色块。我的建议是输出前先放到目标场景里预览一次确认底色、对比度和边界都正确再钉版发布。这一步看似繁琐却能避免很多交付现场才发现的问题。6. 验证图表是否合格用走读测谎两步法画完图不等于设计完。我在项目里推行过一个简单的两步验证法走读和测谎。这两步能在不发版本给别人看之前先自己或小范围地发现大部分问题。6.1 走读沿着主路径朗读节点文字走读的做法是把自己想象成读者沿着图的主方向从起点开始逐个节点读文字每读到一条连线就大声说出它的方向和语义。这一步的目的不是检查语法而是检查读起来是否通顺。走读时我会重点找三类问题第一有没有节点名称让读者无法判断它是什么第二有没有连线的语义在上下文中含混不清第三有没有某个分支突然跳出了主方向让阅读路径断裂。任何一次卡顿都是一个真实存在的读图障碍不要因为读者看多了就习惯了而放过好的图应当无卡顿地一遍读完。6.2 测谎让不熟悉项目的人指认依赖关系走读能发现自洽性问题但发现不了只有作者能懂的暗号。测谎的做法是请一位不熟悉该项目的人看图然后让他指认几个具体关系哪个节点依赖哪个节点数据从哪进入、从哪出去如果这个角色出了问题最先影响谁他能指认出来说明图是完整的如果指认不出来问题不在他在图。我在实践中最常遇到的测谎失败有某个节点根本没有输入来源、某个标注了告警的连线却不知道告警发给谁、某个分组叫服务层但里面混进了数据源。这些问题在面对原作者时不会暴露因为作者会自动脑补缺失信息而测谎对象的脑补能力有限反而是最可靠的接收质量检验。6.3 常见返工清单与修正动作如果验证没通过我有一套固定的返工清单按优先级处理。第一优先级是信息完整性比如节点缺输入、缺输出、缺关键连线第二优先级是布局问题包括方向混乱、交叉过多、分组间距不当第三优先级才是样式问题比如配色不统一、字号过小、标签歧义。修正动作对应地也很直接缺少输入就补依赖节点或者把隐式来源画出来交叉过多就调整节点顺序或者引入锚点层样式问题就对照配色语义表逐项查。做完这三轮修正之后再重新走读一遍通常就能达到稳定交付的状态。我很少能一次画到位但有了这套验证流程返工次数明显变少。最后再分享一个我在多次diagram-design中得出的体会好的图表设计不是把所有信息塞进一张图而是每一张图都克制地只表达一件事让读者一遍读懂。如果你发现自己画图总是越画越复杂试着砍掉一半节点、压缩一半颜色再用上面的走读和测谎验证一下结果可能会让你惊讶。