1. 从一张草图到一套系统diagram-design 到底在解决什么问题第一次听到 “diagram-design” 这个词很多人会以为它只是“画图工具”的另一个说法。但真正在项目里被图表折磨过的人知道问题从来不是“画不出来”而是“画出来的东西没法用、没法改、没法统一”。你辛辛苦苦用某个在线工具拖了半小时的架构图产品经理一句“这个模块位置换一下”你就得从头再来你按照公司模板做了一套流程图结果同事发来的版本字体、配色、箭头粗细全都不一样拼在一起像打了补丁的旧衣服。diagram-design 要解决的就是这层“设计系统”层面的问题。它不是一个单纯的绘图软件而是一套围绕图表展开的设计方法论加工具链的组合。核心思路是把图表从“一次性手工作品”变成“可复用、可维护、可协作的工程资产”。换句话说它关心的是图表的视觉语言怎么定义、组件怎么拆分、不同角色怎么在同一套规则下协作、版本怎么管理、输出怎么适配不同场景。这套东西适合谁如果你只是偶尔画一张流程图发群里可能用不上这么重的思路。但如果你处在下面这些场景里diagram-design 的价值会非常明显技术团队需要维护几十张架构图和时序图且这些图会随着系统迭代不断更新设计团队要给多个产品线输出统一的图表规范咨询或方案团队要在短时间内产出大量风格一致的示意图开源项目需要让不同贡献者提交的图表看起来像一个人做的。这些场景的共同点是图表不是终点而是持续演进的沟通媒介。我见过太多团队在图表上踩的坑本质上都是“没有设计系统”导致的。有人用 Keynote 画架构图有人用在线白板有人直接手绘拍照最后汇总到一份文档里读者第一反应不是“这个系统怎么设计的”而是“这些图怎么长得都不一样”。diagram-design 的切入点就是把这个混乱局面收拢到一套可控的规则里。它不追求让你画出最炫酷的图而是让你画出的每一张图都稳定、清晰、可维护。2. 核心思路拆解为什么是“设计系统”而不是“绘图技巧”2.1 图表的第一性原理信息密度与认知负荷的平衡在深入 diagram-design 的具体做法之前有必要先想清楚一件事一张好的图表到底在做什么我的理解是它在做“信息密度”和“认知负荷”之间的平衡。信息密度太低读者觉得浪费时间信息密度太高读者直接放弃。而 diagram-design 的所有决策几乎都可以用这个平衡来解释。举个例子为什么很多架构图喜欢用圆角矩形加浅色填充不是因为好看而是因为圆角比直角在视觉上更“柔和”能降低边界带来的割裂感让读者把注意力放在文字上而不是形状上。为什么箭头要有粗细区分因为不同粗细的箭头在潜意识里传递了“主流程”和“辅助流程”的差异读者不需要读文字就能感知到层级。这些细节单独看都是“设计技巧”但放在一起就构成了 diagram-design 的底层逻辑每一个视觉元素都要有明确的功能指向不能为了装饰而装饰。我刚开始做图表规范的时候犯过一个典型错误把颜色用得特别丰富觉得这样显得专业。结果读者反馈说“看你的图很累不知道先看哪里”。后来我才明白颜色在图表里的第一作用是“分类”第二作用是“强调”第三才是“美观”。如果一张图里出现超过五种颜色分类功能就失效了读者会陷入“这个蓝色和那个蓝色有什么区别”的困惑。diagram-design 的思路就是先把功能定死再倒推视觉表现。2.2 组件化思维把图表拆成可复用的“积木”diagram-design 最核心的方法论是组件化。什么意思就是不要把一张图当成一个整体去画而是把它拆成若干个标准组件每个组件有固定的样式和行为然后像搭积木一样组合起来。这听起来简单但实际操作中能坚持的人不多。我拿一个常见的微服务架构图举例。传统画法是打开工具拖一个矩形写上“服务A”再拖一个矩形写上“服务B”然后画箭头连起来。下次再画类似的图重复一遍。组件化的画法是先定义“服务节点”这个组件——它的尺寸、圆角、字体、颜色、内边距、阴影全部固定再定义“数据存储”组件、“消息队列”组件、“外部依赖”组件然后定义“同步调用”箭头、“异步消息”箭头、“数据流”箭头的样式。之后每次画图你只需要从组件库里拖出来改文字就行。这两种方式的差异在单张图上可能不明显但在十张、五十张图上就是天壤之别。组件化的好处有三个第一一致性有保障不会出现“这张图的服务节点是蓝色那张图变成绿色”的情况第二修改成本极低如果公司品牌色变了你只需要改组件库里的一个颜色值所有图自动更新第三协作效率高新人拿到组件库就能画出符合规范的图不需要反复沟通“这个框应该多大”。注意组件化不是让你把所有图都画成一个样子。组件库解决的是“基础元素”的统一而图的布局、信息层级、叙事逻辑仍然需要根据具体场景设计。组件化是底线不是天花板。2.3 工具选型背后的取舍为什么我不推荐“全能型”工具聊到 diagram-design绕不开工具选型。市面上能画图的工具太多了从传统的 Visio、OmniGraffle到在线的 Figma、Excalidraw再到代码驱动的 Mermaid、PlantUML、D2。很多人问我“到底用哪个”我的回答永远是看你的图表是“一次性沟通”还是“长期资产”。如果只是开会时随手画个草图Excalidraw 这种手绘风格的工具反而更好因为它传递出“这是草稿欢迎修改”的信号不会让人误以为已经定稿。但如果是需要长期维护的架构图、流程图代码驱动的工具优势就出来了。以 Mermaid 为例你用文本描述图表结构版本管理工具能直接 diff 出“这次改了哪条连线”而不是像二进制文件那样只能看到“整个文件变了”。PlantUML 和 D2 在这方面类似D2 的语法更现代布局算法也更智能一些。但代码驱动工具的问题也很明显样式控制不够精细复杂布局容易失控。所以 diagram-design 的实践中我通常会建议“混合策略”用代码工具管理结构复杂、更新频繁的图用设计工具管理视觉要求高、结构相对稳定的图。两者之间通过统一的组件规范颜色、字体、间距来保持视觉一致性。这样既享受了版本管理的便利又不牺牲视觉质量。工具类型代表工具适合场景版本管理友好度视觉控制精度代码驱动Mermaid、PlantUML、D2结构复杂、频繁更新高中设计工具Figma、Sketch视觉要求高、稳定低高白板工具Excalidraw、tldraw快速沟通、草稿中低传统桌面Visio、OmniGraffle企业模板、打印低中高这个表格不是让你二选一而是帮你判断当前项目该把重心放在哪。我自己的做法是系统架构图用 D2 写因为改起来快对外汇报的示意图用 Figma 做因为要控制每一个像素头脑风暴阶段用白板工具因为速度最重要。3. 核心细节解析从颜色到间距的实操要点3.1 颜色系统为什么你的图表总是“花里胡哨”颜色是图表设计里最容易翻车的地方。我见过太多图作者本意是想“区分不同模块”结果用了七八种高饱和度颜色读者看完只觉得眼睛疼。diagram-design 对颜色的处理原则是先定功能色再定品牌色最后才是装饰色。功能色是指那些有明确语义的颜色。比如红色代表“警告或错误”绿色代表“成功或正常”黄色代表“待定或注意”蓝色代表“信息或主流程”。这些颜色在读者心里已经有共识你顺着用就行不要试图重新定义。品牌色是指公司或产品的标识色通常用在标题、关键节点或强调元素上用量要克制一张图里出现两三次就够了。装饰色是最后才考虑的而且我建议尽量不用因为装饰色最容易破坏信息层级。具体到操作层面我通常会先建立一个色板包含 5 到 7 个颜色一个主色、一个辅助色、三个功能色成功、警告、错误、两个中性色深灰用于文字浅灰用于背景或边框。然后严格规定每个颜色的使用场景。比如主色只用于“当前关注的核心模块”辅助色只用于“与核心模块直接交互的模块”功能色只用于状态标识。这样即使图很复杂读者也能通过颜色快速定位重点。提示如果你不确定颜色搭配是否合理把图转成灰度看一眼。如果灰度下仍然能分清层级和重点说明你的颜色系统是健康的如果灰度下变成一团糊说明你过度依赖颜色来传递信息了。3.2 字体与字号被大多数人忽略的“隐形骨架”字体在图表里的作用被严重低估了。很多人觉得“能看清就行”但实际上字体的选择直接影响了图表的专业感和可读性。diagram-design 的字体原则是无衬线字体优先字号层级不超过四级字重变化不超过三种。无衬线字体比如思源黑体、Inter、Roboto在屏幕上的可读性优于衬线字体尤其是在小字号下。字号层级我一般这样定图表标题 20-24px模块名称 14-16px说明文字 12-14px注释 10-12px。超过四级层级会让读者难以判断“哪个比哪个更重要”。字重方面Regular 用于正文Medium 用于模块名称Bold 用于标题最多再加一个 Light 用于辅助说明。再多就乱了。还有一个细节行高。很多人只关注字号忽略了行高。行高太紧文字挤在一起读者阅读困难行高太松文字散开视觉上不连贯。我的经验值是行高设为字号的 1.4 到 1.6 倍。比如 14px 的字行高设在 20px 到 22px 之间比较舒服。这个数值不是绝对的但偏离太多就会影响阅读体验。3.3 间距与对齐让图表“呼吸”的关键间距和对齐是图表设计里最考验耐心的部分。我见过很多图内容都对但看起来就是“不舒服”问题往往出在间距和对齐上。diagram-design 对间距的要求是同级元素等距不同级元素有明确的比例关系。具体来说如果两个模块是并列关系它们之间的间距应该相等如果一个模块包含子模块子模块之间的间距应该小于父模块与外部模块的间距。这样读者能通过间距自然感知到层级关系。我常用的间距比例是 8px 基础单位同级间距 16px 或 24px父子间距 8px 或 12px模块内边距 12px 或 16px。所有间距都取 8 的倍数这样在调整时不容易出现“差一像素”的尴尬。对齐方面我强烈建议开启工具的“对齐辅助线”或“网格吸附”功能。人眼对对齐非常敏感哪怕只差 2px也会让人觉得“哪里不对”。如果工具支持把关键元素对齐到网格上这样即使后续调整也不会破坏整体秩序。还有一个技巧把文字的左边缘对齐而不是把文本框的左边缘对齐。因为文本框可能有内边距直接对齐文本框会导致文字看起来没有对齐。4. 实操过程从零搭建一套图表设计系统4.1 第一步定义你的图表“原子”和“分子”搭建设计系统的第一步不是打开工具而是拿出一张纸把你项目里所有图表拆解成最基本的元素。我通常把元素分成三个层级原子、分子、有机体。原子是不可再分的基础元素比如颜色、字体、图标、线条样式。分子是由原子组成的组件比如“服务节点”“数据存储”“用户角色”。有机体是由分子组成的完整图表比如“订单系统架构图”“用户注册流程图”。这个拆解过程看起来繁琐但它是后续所有工作的基础。我一般会先列出项目里最常见的五种图表类型然后逐一分析它们共用了哪些元素。比如架构图和流程图都用到“矩形节点”和“箭头”时序图和状态图都用到“生命线”和“消息”。把这些共用元素提取出来就是你的原子和分子。注意不要一开始就追求大而全。先覆盖 80% 的常见场景剩下的 20% 在遇到时再补充。我见过有人花两周时间设计了一套包含五十个组件的库结果实际用到的只有八个其他都成了摆设。4.2 第二步在工具里落地组件库定义完元素之后就是在工具里把它们变成可复用的组件。如果你用 Figma可以用“组件”功能如果用 D2可以定义样式类和模板如果用 Mermaid可以通过主题配置和 CSS 类来实现。不同工具的实现方式不同但核心思路一致一次定义处处引用。以 Figma 为例我会先建一个“图表组件”页面把所有原子和分子做成组件。颜色和字体通过“样式”功能管理这样修改时只需要改一处。然后建一个“图表模板”页面把常见的图表布局做成框架比如“三层架构”“左右对比”“时间线”。每次画新图时复制一个模板然后从组件库里拖组件进去。这样即使是不太懂设计的人也能在十分钟内画出一张符合规范的图。如果你用代码驱动工具组件化的方式略有不同。以 D2 为例你可以定义classes来统一节点样式定义vars来管理颜色和间距。然后写一个基础模板文件其他图通过import引用这个模板。这样当品牌色变化时只需要改模板文件里的一个变量所有图自动更新。这种“配置即设计”的思路在长期维护中优势非常明显。4.3 第三步建立图表规范和检查清单组件库建好之后还需要一套规范来约束“怎么用”。我通常会写一份简短的图表规范文档包含以下内容颜色使用规则什么场景用什么颜色、字体层级规则标题、模块名、说明文字分别用什么字号、间距规则同级和父子级分别用多少间距、箭头规则什么关系用什么箭头样式、命名规则组件和图层怎么命名。这份规范不需要很长两三页就够了关键是可执行。比如“主色只用于当前核心模块”比“主色要合理使用”有用得多。然后我会配一个检查清单每次完成一张图后对照检查颜色是否超过五种字号层级是否超过四级同级元素间距是否一致文字是否对齐箭头样式是否统一这个清单能拦住 90% 的低级错误。检查项合格标准常见问题颜色数量不超过 5 种功能色用颜色区分过多模块字号层级不超过 4 级标题和模块名一样大同级间距完全一致手动拖拽导致间距不一文字对齐左边缘对齐文本框对齐但文字不齐箭头样式不超过 3 种实线虚线混用无规律4.4 第四步版本管理与协作流程图表作为长期资产必须纳入版本管理。我的做法是代码驱动的图表直接放在代码仓库里和代码一起提交设计工具做的图表导出为 SVG 或 PNG放在文档仓库里同时保留源文件链接。每次修改时在提交信息里写清楚“改了什么、为什么改”这样回溯时一目了然。协作方面我会指定一个“图表负责人”负责维护组件库和规范。其他人可以提交修改建议但组件库的变更必须由负责人审核。这样可以避免“每个人都按自己的喜好改组件最后又乱了”的情况。如果团队用 Figma可以利用“分支”功能让修改在合并前先评审。如果团队用代码工具就走正常的代码评审流程。提示图表源文件一定要和最终导出的图片放在一起并且保持同步更新。我见过太多“图片更新了但源文件还是旧版”的情况下次修改时直接崩溃。5. 常见问题与排查技巧实录5.1 图表太复杂读者看不懂怎么办这是最常见的问题。我的排查思路是先看信息层级再看视觉引导最后看文字量。信息层级方面问自己“读者第一眼应该看到什么”。如果答案是“所有东西”那说明你没有区分主次。解决办法是用颜色、大小、位置来建立层级核心模块用主色、大字号、居中辅助模块用中性色、小字号、边缘。视觉引导方面检查箭头的流向是否清晰。如果箭头交叉太多读者会迷失方向。可以尝试调整布局把主要流程放在一条主线上辅助流程放在侧面。文字量方面能删就删。图表里的文字应该是“关键词”而不是“完整句子”详细说明放在图外的文档里。5.2 组件库和实际需求不匹配怎么办这个问题通常出现在项目初期。我的建议是不要试图一次性设计完美的组件库而是采用“迭代式”方法。先定义最基础的五个组件然后在实际画图过程中遇到不够用的情况就补充。每次补充时问自己“这个新组件会不会和已有组件冲突”“它的使用场景是否足够通用”。如果只是某个特殊场景需要就不要加进组件库而是作为“一次性元素”处理。组件库的规模应该控制在 15 到 25 个之间太少不够用太多记不住。5.3 不同工具之间的图表风格不统一怎么办这是混合策略带来的必然问题。我的解决办法是建立一份“跨工具样式对照表”。比如在 Figma 里主色是 #3B82F6在 D2 的主题配置里也设为 #3B82F6Figma 里模块圆角是 8pxD2 的样式类里也设为 8px。字体方面如果工具不支持同一种字体就选择视觉上接近的替代品并调整字号和字重来补偿。关键是定期做“视觉审查”把不同工具产出的图放在一起看如果风格差异明显就调整对照表。常见问题排查方向解决方法图表太乱信息层级是否清晰用颜色和大小建立主次读者迷失箭头流向是否明确主线居中辅线侧置组件不够用是否覆盖核心场景迭代补充控制数量风格不统一跨工具样式是否对齐建立样式对照表修改成本高是否组件化一次定义处处引用5.4 独家避坑技巧我踩过的三个坑第一个坑是“过度设计”。刚开始做设计系统时我花了大量时间设计精美的组件结果实际画图时发现根本用不上因为真实场景比预想的复杂得多。后来我学乖了先用最简陋的组件把图跑通再逐步美化。第二个坑是“忽略导出场景”。我在设计工具里看着很完美的图导出成 PNG 后模糊不清因为没考虑导出分辨率。后来我规定所有图至少导出 2 倍图重要图导出 SVG。第三个坑是“没有版本记录”。有一次我改了一个组件结果所有引用它的图都变了样但我不知道哪些图受了影响。后来我养成了习惯改组件前先搜索引用改完后逐一检查。5.5 性能优化当图表数量超过一百张当项目里的图表超过一百张时管理就成了问题。我的做法是按模块或按图表类型分文件夹每个文件夹里放一个索引文件列出该文件夹下所有图表的名称、用途、最后更新时间。然后用脚本定期检查哪些图超过三个月没更新、哪些图引用了已废弃的组件、哪些图的源文件和导出文件不一致。这个脚本用 Python 写几十行就够了但能省下大量人工检查的时间。import os import json from datetime import datetime, timedelta def check_diagrams(root_dir): stale_threshold datetime.now() - timedelta(days90) issues [] for dirpath, _, filenames in os.walk(root_dir): for f in filenames: if f.endswith(.svg) or f.endswith(.png): full_path os.path.join(dirpath, f) mtime datetime.fromtimestamp(os.path.getmtime(full_path)) if mtime stale_threshold: issues.append(f过期未更新: {full_path}) return issues if __name__ __main__: for issue in check_diagrams(./diagrams): print(issue)这个脚本只是最基础的版本实际使用时可以根据项目需求扩展比如检查文件命名规范、检查源文件是否存在等。关键是建立“定期巡检”的习惯不要等到图表乱成一团再收拾。6. 图表设计系统的扩展与个人体会6.1 从图表到文档设计系统的外溢价值一套好的图表设计系统价值往往不止于图表本身。我在多个项目里发现当团队习惯了用统一的组件和规范来画图后写文档、做 PPT、甚至设计产品界面时都会不自觉地沿用这套规则。因为底层逻辑是相通的信息层级、视觉引导、一致性。有个同事跟我说他做完图表规范后连周报的排版都变整齐了因为“受不了字号不统一”。这种外溢效应是有意为之还是自然发生的我不好说。但如果你正在搭建图表设计系统不妨把视野放宽一点这套规则能不能复用到其他视觉沟通场景比如把颜色系统扩展到状态标签把间距规则扩展到页面布局把组件化思路扩展到文档模板。这样一套投入多处收益。6.2 个人体会设计系统是“养”出来的不是“建”出来的最后分享一个我反复验证过的体会图表设计系统不是一次性工程而是持续养护的过程。我见过太多团队花大力气建了一套系统然后放在那里吃灰因为“建完了”就没人管了。真正有效的做法是把设计系统当成一个产品来运营有负责人、有迭代计划、有用户反馈。每次画图时遇到问题就想想“这是不是系统需要补充的地方”每次修改组件时就想想“这会不会影响其他图”。还有一个反直觉的经验不要追求完美。我早期总想把组件库设计得无懈可击结果迟迟不敢发布拖了两个月还在调整。后来我强迫自己先发布一个“够用版”然后在实际使用中快速迭代。事实证明使用中暴露的问题比闭门造车想象的问题有价值得多。现在我的原则是先跑起来再优化。图表设计系统如此很多其他事情也如此。