1. 从一张草图到一套系统diagram-design 到底在解决什么问题第一次看到 “diagram-design” 这个标题很多人会下意识觉得它只是“画图”的另一个说法。但真正在项目里被图表折磨过的人知道画图本身从来不是最痛的部分。最痛的是图画完了需求变了图改完了风格崩了风格统一了协作的人看不懂好不容易大家都看懂了交付时又发现导出格式不对、字体缺失、线条错位。diagram-design 要处理的正是这一整条链路上的系统性混乱。我把它理解成一套“图表设计的方法论加可复用资产库”。它不局限于某一个绘图工具也不绑定某一种图形语言而是围绕“如何让图表在表达信息的同时保持设计一致性”这个核心命题展开。你可以用它来规范团队内部的架构图、流程图、时序图、状态机图也可以用它来搭建个人知识库里的概念关系图、决策树、思维导图。只要你的工作里存在“需要把复杂关系画清楚”的场景这套东西就有用武之地。适合读这篇内容的人大致分三类。第一类是技术团队里那个“默认要画图的人”可能是架构师、技术负责人也可能是刚入职就被安排整理系统文档的新同学。第二类是产品与设计岗位需要频繁输出用户旅程图、服务蓝图、信息架构图却总在“好看”和“准确”之间反复拉扯。第三类是做知识管理、教学材料、技术写作的独立创作者希望自己的图表既有个人辨识度又能被别人直接复用。这三类人的共同点是他们不缺画图工具缺的是一套能稳定产出高质量图表的“设计系统”。diagram-design 的核心价值可以拆成三个层面来看。最表层是视觉规范包括线宽、圆角、间距、配色、字体层级、箭头样式、节点形状语义。中间层是结构规范也就是什么类型的图该用什么布局逻辑分层怎么分、分组怎么组、连线怎么走、标签放哪里。最底层是协作规范涉及源文件怎么组织、组件怎么命名、版本怎么管理、导出怎么适配不同场景。很多人只做了最表层结果就是“单张图好看一套图灾难”。diagram-design 真正要解决的是让图表从“一次性作品”变成“可维护资产”。这里有个很关键的认知转变图表不是画出来的是“设计”出来的。画图是手工艺设计是系统思维。手工艺依赖个人状态系统思维依赖规则和资产。diagram-design 的出发点就是把你从“每次都要重新想怎么画”的重复劳动里解放出来让你把精力放在“信息结构是否准确”这个真正重要的问题上。我见过太多团队图表的视觉风格换了三四轮但信息层级始终是乱的这就是典型的把力气用错了地方。还有一个容易被忽略的点diagram-design 不只是给“画图的人”用的。它同样服务于“看图的人”。一张符合设计规范的图表读者能在三秒内抓住主干在十秒内定位细节在三十秒内理解关系。而一张没有设计规范的图表读者需要先花时间解码你的视觉语言才能开始理解内容。这个解码成本在跨团队沟通里会被放大十倍。所以 diagram-design 的收益一半体现在产出效率上另一半体现在沟通效率上。2. 核心设计思路拆解为什么是“系统”而不是“模板”2.1 模板思维的天花板在哪里大多数人接触图表设计是从下载模板开始的。这很自然模板能快速解决“从零到一”的问题。但模板思维有个致命缺陷它假设你的内容和模板作者的内容结构相似。一旦你的系统分层是五层而不是三层一旦你的流程有异常分支而不是一条直线模板立刻就不够用了。这时候你有两个选择要么削足适履把内容硬塞进模板要么临时改模板改着改着就改成了四不像。我踩过最典型的一个坑是早期做微服务架构图时直接套了一个“三层架构”模板。结果我们的系统实际上有网关层、应用层、领域服务层、基础设施层还有一条独立的可观测性链路。硬塞进三层模板后网关和可观测性被挤到了边角连线交叉得一塌糊涂。后来我花了整整两天重画才意识到问题不在画功而在“模板没有给我定义分层规则只给了我一个固定形状”。diagram-design 的思路完全不同。它不提供“一张画好的图”而是提供“一套决定图怎么画的规则”。规则包括分层数量由内容决定但每层的视觉权重必须有明确梯度分组框的嵌套深度不超过两层超过就要拆图连线优先走正交路径斜线只用于表达“非结构化关系”节点形状与语义绑定矩形代表实体、圆角矩形代表服务、圆柱代表存储、菱形代表判断。这些规则一旦确定你画任何图都有了依据而不是每次凭感觉。2.2 设计令牌让图表风格可计算diagram-design 里最值得深入的一个概念是“设计令牌”。这个词听起来很抽象其实很简单把图表里所有可变的视觉属性抽成一组有名字的变量。比如line-primary是主连线颜色line-secondary是辅助连线颜色node-fill是节点填充色node-stroke是节点描边色font-title是标题字号font-label是标签字号spacing-unit是基础间距单位。为什么要这么做因为图表的视觉一致性靠人眼记忆是记不住的。你今天调了一个颜色明天画另一张图时凭感觉再调一个两张图放在一起就会露馅。而有了设计令牌你只需要维护一套变量表所有图表都从这套变量里取值。改一个变量所有图同步更新。这在工具支持上Figma 的 Variables、Penpot 的 Design Tokens、甚至 draw.io 的自定义样式库都能实现。我自己的做法是把设计令牌分成三组。第一组是“结构令牌”控制间距、线宽、圆角、箭头大小这组决定图表的“骨架感”。第二组是“语义令牌”控制不同节点类型、不同连线类型的颜色和样式这组决定图表的“信息编码”。第三组是“排版令牌”控制字体、字号、行高、标签内边距这组决定图表的“可读性”。三组令牌分开维护改结构不影响语义改语义不影响排版维护成本大幅降低。2.3 从“画一张图”到“搭一套组件”diagram-design 的另一个核心思路是把图表元素组件化。传统画图是“画一个矩形再画一个矩形”组件化画图是“拖一个‘服务节点’组件再拖一个‘数据库节点’组件”。区别在于组件自带语义和样式你不需要每次重新设置填充色、描边、圆角、字体。更重要的是组件可以带“插槽”比如一个“服务节点”组件可以预留标题区、描述区、标签区你只需要往里填内容。组件化的收益在协作场景下尤其明显。假设团队里有五个人要画图如果没有组件库五个人会画出五种风格的矩形。有了组件库五个人拖出来的节点长得一模一样连线样式也统一。审图的人不需要再花精力判断“这个圆角大一点是不是有特殊含义”因为所有圆角都是同一个值有特殊含义的节点会用另一种组件表达。这里有个实操细节值得展开组件命名。我见过太多组件库死在命名上。Rectangle 1、Frame 23、Group 7这种命名过一周自己都不认识。diagram-design 推荐的命名方式是“语义-变体-状态”三段式。比如node-service-default、node-service-highlighted、node-database-default、edge-sync-default、edge-async-dashed。命名即文档看到名字就知道用途新人接手也能快速上手。2.4 布局规则让图表自己“长”出结构图表设计里最难自动化的是布局。很多人画图慢不是慢在画形状而是慢在“这个节点放哪里、那条线怎么绕”。diagram-design 对布局的处理思路是先定义布局模式再让内容往里填。常见的布局模式有四种。第一种是分层布局适合架构图、网络拓扑图从上到下或从左到右分层层内节点水平或垂直排列。第二种是流程布局适合流程图、状态机图按主路径线性排列分支路径向侧方展开。第三种是中心辐射布局适合概念图、依赖关系图核心节点居中相关节点环绕。第四种是泳道布局适合跨角色流程图按角色分列流程在列间流动。每种布局模式都有对应的“布局约束”。比如分层布局里同层节点必须对齐基线层间距必须大于层内节点间距跨层连线必须垂直或水平不允许斜穿。这些约束看起来是限制实际上是帮你做决策。没有约束时你会陷入“这样放也行那样放也行”的决策瘫痪有了约束你只需要判断“这个节点属于哪一层”剩下的交给规则。3. 核心细节解析与实操要点3.1 视觉层级让读者三秒抓住主干图表的第一使命是传达信息层级而不是展示画功。diagram-design 里对视觉层级的定义遵循“三秒原则”读者看一张图三秒内应该能说出这张图的主干是什么。如果三秒后读者还在找“从哪里开始看”那这张图的视觉层级就是失败的。实现视觉层级的手段有五个按优先级排序。第一是尺寸核心节点明显大于辅助节点但差距不超过两倍否则会显得突兀。第二是颜色饱和度主干路径用高饱和度辅助路径用低饱和度背景元素用极低饱和度。第三是线宽主连线 2px辅助连线 1px装饰性连线 0.5px 或直接省略。第四是留白核心区域周围留白多边缘区域留白少用留白引导视线。第五是字体权重主标题用粗体节点标签用常规体注释用细体。我自己的经验是这五个手段不要同时用满。同时用满会让图表显得“吵”。通常选两到三个就够了。比如架构图我一般用“尺寸颜色饱和度线宽”三件套流程图用“颜色饱和度线宽字体权重”三件套。留白是贯穿始终的底层手段不单独作为主要手段但永远不能省。注意视觉层级不是“越明显越好”。层级差距过大读者会忽略辅助信息层级差距过小读者抓不住主干。建议在正式出图前把图缩小到 50% 看一眼如果缩小后主干依然清晰说明层级合格如果缩小后一片糊说明层级不够。3.2 连线设计图表里最容易翻车的部分连线是图表设计里最容易被低估的部分。很多人画节点很讲究画连线却很随意结果就是“节点好看连线灾难”。diagram-design 对连线的处理有几个硬性规则。第一连线必须正交。所谓正交就是连线只能走水平或垂直方向拐弯处用直角。斜线只用于表达“非结构化关系”比如“参考”“关联”这类弱关系。正交连线的好处是视觉上整洁读者视线可以沿着线走而不跳脱。斜线一多图表就会显得凌乱。第二连线交叉要最小化。交叉是图表可读性的大敌。减少交叉的方法有三个调整节点顺序把关联紧密的节点放近使用“跳线”符号在交叉处画一个小弧线表示“这里不相连”拆图如果交叉实在太多说明信息密度过高应该拆成两张图。第三连线标签要贴线。连线上的文字标签应该紧贴连线并且与连线方向平行。水平连线标签放线上方垂直连线标签放线右侧。标签不要离连线太远否则读者不知道这个标签属于哪条线。第四箭头样式要统一。同步调用用实线实心箭头异步调用用虚线实心箭头事件发布用实线空心箭头数据流用粗实线。样式一旦定义全图统一。我见过一张图里同时出现五种箭头样式读者光理解箭头含义就花了半分钟。3.3 配色策略少即是多图表配色最容易犯的错是把配色当装饰。实际上图表配色的唯一目的是“编码信息”。颜色应该承载语义而不是承载情绪。diagram-design 的配色策略是“一个主色两个辅助色一个强调色一个中性色系”。主色用于核心节点和主干路径通常选一个饱和度适中、辨识度高的颜色。辅助色用于次要节点和辅助路径选主色的邻近色或低饱和度变体。强调色用于需要特别注意的节点比如“异常节点”“待办节点”选一个与主色对比明显的颜色但使用面积要小。中性色系用于背景、边框、注释文字通常是灰阶。这里有个实操技巧把配色方案转成灰度看一眼。如果转成灰度后信息层级依然清晰说明配色是合格的如果转成灰度后一片糊说明你过度依赖颜色区分信息这在打印或色觉障碍场景下会出问题。灰度测试是检验配色是否“承载信息”而非“承载装饰”的快速方法。提示不要用纯黑#000000和纯白#FFFFFF。纯黑太硬纯白太刺眼。用#1A1A1A到#333333之间的深灰代替纯黑用#FAFAFA到#F5F5F5之间的浅灰代替纯白。这个细节能让图表的“质感”提升一个档次。3.4 字体与排版被忽视的可读性基石图表里的文字承担着“精确传达”的任务。图形传达结构文字传达细节。字体选错细节就传达不到位。diagram-design 对字体的要求是无衬线优先字重齐全字符区分度高。无衬线字体在屏幕上更清晰字重齐全意味着你可以用不同字重表达层级字符区分度高意味着1和l、0和O不容易混淆。字号层级建议不超过四级。以 16px 为基准标题 20px 到 24px节点主标签 14px 到 16px节点副标签 12px 到 14px注释 10px 到 12px。字号差距太小层级出不来字号差距太大排版会显得跳跃。行高建议是字号的 1.4 到 1.6 倍这个范围在可读性和紧凑性之间平衡得最好。标签内边距也值得一说。节点里的文字不能贴着节点边框。水平内边距至少 8px垂直内边距至少 6px。如果节点有图标图标与文字间距至少 6px。这些数值看起来琐碎但正是这些琐碎细节决定了图表是“精致”还是“粗糙”。4. 实操过程与核心环节实现4.1 第一步定义你的设计令牌表动手画第一张图之前先把设计令牌表定下来。这张表不需要很复杂但必须存在。我通常用一个简单的表格来维护字段包括令牌名、值、用途说明。下面是一个最小可用的示例。令牌名值用途spacing-unit8px基础间距单位所有间距都是它的倍数line-primary2px主连线线宽line-secondary1px辅助连线线宽radius-node6px节点圆角color-primary#2F6FED主色核心节点color-secondary#7BA7F5辅助色次要节点color-accent#E8590C强调色异常节点color-neutral-900#1A1A1A主文字color-neutral-600#666666次要文字color-neutral-200#E0E0E0边框font-title20px/600标题字号/字重font-label14px/400标签字号/字重font-note11px/400注释字号/字重这张表定下来后所有图表都从这里取值。工具支持变量的话直接建变量工具不支持的话至少把这张表放在手边每次设置样式时对照取值。我自己的习惯是把这张表放在项目根目录的design-tokens.md里团队任何人画图前先看一遍。4.2 第二步搭建组件库设计令牌定好后开始搭组件库。组件库不需要一次搭全先搭最常用的五类节点、连线、分组框、标签、图例。节点组件按语义分至少要有服务节点、数据库节点、队列节点、外部系统节点、用户节点。每个节点组件包含标题区、描述区、标签区三个插槽。连线组件按语义分至少要有同步调用、异步调用、数据流、依赖关系。分组框组件按层级分至少要有一级分组、二级分组。标签组件按位置分至少要有节点内标签、连线标签、浮动注释。图例组件按图表类型分至少要有节点图例、连线图例。组件搭好后做一次“压力测试”用组件库快速拼一张包含十个节点、十五条连线的图。如果拼图过程中需要频繁“脱离组件”手动调整说明组件库覆盖度不够需要补充。如果拼图顺畅说明组件库可用。这个测试我每次搭新组件库都会做能提前发现很多问题。4.3 第三步按布局模式出图组件库就绪后开始正式出图。出图流程分四步。第一步是“信息梳理”把要表达的内容列成清单明确哪些是核心、哪些是辅助、哪些是背景。第二步是“布局选择”根据内容类型选布局模式架构图选分层流程图选流程概念图选中心辐射跨角色流程选泳道。第三步是“节点摆放”先放核心节点再放辅助节点最后放背景节点。第四步是“连线绘制”先画主干连线再画辅助连线最后处理交叉。这里有个实操心得不要一边摆节点一边画连线。先摆完所有节点确认布局合理再统一画连线。一边摆一边画很容易陷入“为了连线好看而挪节点挪完节点连线又乱了”的死循环。分开做效率高很多。4.4 第四步导出与适配图画完后导出环节同样有讲究。不同场景需要不同格式。文档嵌入用 SVG矢量清晰、体积小、可搜索文字。演示汇报用 PNG兼容性好、不会因字体缺失而错位。协作评审用源文件链接方便别人直接改。打印输出用 PDF排版稳定。导出前有几个检查项。第一字体是否转曲或嵌入避免对方打开时字体替换。第二颜色模式是否正确屏幕用 RGB打印用 CMYK。第三画布边界是否留足避免导出后边缘被裁。第四背景是否透明嵌入深色文档时透明背景更灵活。这四项检查花不了一分钟但能避免大量返工。注意SVG 导出时如果图表里有大量文字建议把文字转成路径避免对方环境缺字体。但转路径后文字不可搜索所以最好同时保留一份“文字可搜索”的 SVG 和一份“文字转路径”的 SVG按场景选用。5. 常见问题与排查技巧实录5.1 图表越画越乱怎么办这是最高频的问题。症状是节点越加越多连线越画越密最后自己都看不懂。根因通常不是画功问题而是“一张图承载了太多信息”。排查方法是问自己这张图的核心信息是什么如果核心信息能用一句话说清那所有与这句话无关的节点和连线都应该删掉或移到另一张图。我的处理流程是“三步瘦身”。第一步标出核心路径把不在核心路径上的节点全部标灰。第二步看标灰节点里有没有必须保留的有的话说明核心路径定义错了重新定义。第三步把确认要删的节点删掉把确认要移的节点移到“补充图”里。通常瘦身后图表可读性会提升一个档次。5.2 连线交叉太多怎么破连线交叉多的根因是“节点顺序与连线关系不匹配”。比如 A 连 CB 连 D但节点顺序是 A、B、C、D那 A-C 和 B-D 必然交叉。解决办法是调整节点顺序为 A、C、B、D交叉就消失了。所以遇到交叉多先别急着画跳线先看节点顺序能不能调。如果节点顺序调不了再用跳线。跳线是在交叉处画一个小弧线表示“这里不相连”。跳线不要滥用一张图里超过五处跳线读者就会晕。超过五处说明该拆图了。5.3 团队协作时风格不统一怎么办风格不统一的根因是“没有共享的设计令牌和组件库”。解决办法分三步。第一步把设计令牌表同步给所有画图的人要求所有人从表里取值。第二步把组件库发布到团队共享空间要求所有人从组件库拖组件。第三步建立“出图前检查”机制每张图发布前对照检查清单过一遍。检查清单可以很简单五条就够线宽是否统一、圆角是否统一、配色是否来自令牌表、字体是否统一、箭头样式是否统一。这五条过了风格基本就统一了。我见过团队用这五条检查清单把图表风格一致性从“看运气”提升到“稳定达标”。5.4 导出后字体错位怎么办字体错位的根因是“对方环境没有你用的字体”。解决办法有三个。第一用系统通用字体比如思源黑体、Inter、Roboto这些字体在大多数环境都有或容易安装。第二导出时把文字转成路径彻底摆脱字体依赖。第三导出 PDF 时嵌入字体。三个办法按场景选文档嵌入用转路径演示汇报用通用字体打印输出用嵌入字体。5.5 常见问题速查表问题根因解决图表越画越乱单图信息过载三步瘦身拆图连线交叉太多节点顺序与连线关系不匹配调节点顺序用跳线拆图风格不统一无共享令牌和组件库同步令牌表发布组件库出图前检查导出字体错位对方环境缺字体通用字体转路径嵌入字体图表缩小后看不清视觉层级不足加大尺寸/颜色/线宽差距配色转灰度后一片糊过度依赖颜色区分增加形状和线宽区分组件库不够用覆盖度不足压力测试补充组件连线标签归属不清标签离连线太远标签贴线与线平行6. 我个人的实操心得与扩展思路6.1 先定规则再动手画这是我踩了无数坑之后最想分享的一条。很多人画图是“先画画完再想怎么统一”。这个顺序是反的。正确的顺序是“先定规则再按规则画”。规则包括设计令牌、组件库、布局模式、连线规则。规则定好后画图速度会快很多因为大部分决策已经被规则做完了你只需要做“内容决策”不需要做“样式决策”。我自己的习惯是每接一个新的图表任务先花十分钟把规则过一遍。如果任务类型是之前画过的直接复用规则如果是新类型补充规则后再画。这十分钟的投入能省下后面一小时的返工。6.2 图表也要做“版本管理”图表不是画完就完了它会随需求变化而更新。没有版本管理你会陷入“这张图是最终版吗”“上次改的是哪一版”的混乱。我的做法是图表源文件和代码一样做版本管理。每次修改前先提交一版修改后写清楚改了什么。文件名带日期和版本号比如architecture-20240115-v3。这样任何时候都能回溯到历史版本。6.3 图表可以“组件化复用”到文档里图表画好后不要只导出图片。把图表源文件链接嵌入到文档里文档读者可以直接点开源文件看最新版。这样文档里的图表永远是最新的不需要每次更新文档时重新导出图片。这个做法在协作场景下特别有用文档和图表分离维护各自更新互不阻塞。6.4 后续可以这样扩展diagram-design 这套思路可以扩展到很多场景。比如扩展到“图表模板市场”把团队常用的图表类型做成模板新人直接套用。扩展到“图表自动化”用脚本从代码或配置里生成图表减少手工维护。扩展到“图表评审流程”把图表纳入代码评审一样的流程出图前有人审审完才发布。我个人最看好的扩展方向是“图表即代码”。用文本描述图表结构用脚本渲染成图。这样图表可以进版本管理可以 diff可以自动生成。虽然学习成本高一点但长期收益很大。我试过用这种方式维护一套架构图改一个节点只需要改一行文本渲染出来的图自动更新效率比手工画高很多。最后分享一个小技巧每次画完图把图发给一个不熟悉这个项目的人看问他“这张图在说什么”。如果他能在一分钟内说对主干说明图合格如果说不对说明图还有优化空间。这个“外人测试”比任何自查都有效因为你自己看自己的图永远会脑补缺失的信息。