1. 从一张草图到一套系统diagram-design 到底在解决什么问题第一次看到 “diagram-design” 这个项目名很多人会以为它只是某个画图工具的皮肤或者模板集合。但真正上手之后你会发现它其实是一套关于“如何把脑子里模糊的结构变成别人一眼能看懂的画面”的完整方法论。我最初接触这类项目是因为团队里每周都要做架构评审每次有人甩出一张线条乱飞、箭头方向全靠猜的草图会议时间至少要多花二十分钟在“你这个框到底连的是谁”上面。diagram-design 这类项目的核心价值就是把这二十分钟省下来。它做的事情可以拆成三层第一层是视觉语法也就是用什么样的形状、颜色、连线来表达“包含”“依赖”“流向”“分层”这些关系第二层是布局规则保证图在信息量增加时不会变成一团乱麻第三层是可复用的组件化思路让你画完一张图之后下一张图不用从零开始。这三层加起来解决的其实是同一个问题降低结构信息的传递损耗。适合谁来参考如果你是需要画系统架构图的后端开发、要梳理业务流程的产品经理、要写论文里技术路线图的研究生或者只是想在周报里放一张清晰流程图的职场人这套东西都能直接用。它不要求你会什么高级设计软件甚至不要求你有美术基础核心在于理解“图是给人看的不是给自己看的”这个前提。我见过太多人把图当成个人笔记来画结果除了自己没人能看懂这就完全背离了 diagram-design 的初衷。接下来的内容我会从设计思路、核心细节、实操过程、常见问题四个方向把这套方法拆开讲清楚。每一部分都会给出具体的参数、步骤和踩坑记录你可以直接照着改自己的图。2. 整体设计思路为什么是这套视觉语法2.1 先定关系类型再定图形样式很多人画图的第一步是打开工具拖一个矩形出来然后开始想要写什么字。这个顺序是反的。diagram-design 的思路是先问这张图里存在哪几种关系再决定用什么图形去承载它们。常见的关系类型其实不多我习惯分成四类包含关系A 里面装着 B比如一个服务里包含多个模块。这种关系用嵌套矩形或者分组框最直观边界线要明显比内部元素粗。依赖关系A 需要 B 才能工作比如订单服务依赖库存服务。这种用带箭头的实线箭头指向被依赖方。数据流向数据从 A 流到 B比如用户请求经过网关到业务层。这种用带箭头的线但线型可以比依赖关系细一点或者用不同颜色区分。层级关系A 在 B 之上或之下比如基础设施层、应用层、接入层。这种用横向或纵向的分层色块层与层之间留出固定间距。为什么要把关系类型放在图形样式前面因为一旦你先拖了图形你的思维就会被图形限制住。比如你先画了一个圆就会不自觉地想把所有东西都塞进圆里哪怕它其实更适合用矩形。先定关系图形是服务于关系的这样画出来的图逻辑自洽别人看的时候不需要猜。2.2 颜色只用来区分不用来装饰这是我在实际项目里反复强调的一点。diagram-design 里颜色的第一原则是功能性不是美观性。什么意思如果你用红色表示“核心链路”那整张图里红色就只能出现在核心链路上不能因为某个框空着不好看就随手填个红色。我见过一张图用了七种颜色结果问作者每种颜色什么意思他自己都说不清楚。比较稳妥的做法是主色不超过三种每种颜色对应一个明确的语义。比如蓝色表示“我方系统”灰色表示“外部依赖”橙色表示“异步处理”。如果关系类型超过三种优先用线型和箭头样式来区分而不是继续加颜色。因为人对线型的辨识度在复杂图里比颜色更稳定尤其是打印成黑白之后颜色区分就完全失效了。还有一个细节背景色和元素色的对比度要足够。我试过用浅灰背景配中灰元素投影仪一打出来全糊在一起。后来固定用白色或极浅的灰做背景元素用饱和度中等偏上的颜色对比度控制在 4.5:1 以上基本就不会出问题。2.3 布局遵循“阅读动线”而不是“空间均分”新手画图很容易陷入一个误区把画布当成一个需要填满的容器每个元素之间距离相等整体看起来像棋盘。但 diagram-design 的布局逻辑是阅读动线优先。人看图的习惯是从左上到右下或者从上到下所以重要的元素要放在动线的起点次要的放在后面。具体操作上我会把图分成几个“视觉区块”每个区块内部元素间距小一点比如 20px区块之间间距大一点比如 60px。这样即使没有画分组框别人也能一眼看出哪几个元素是一伙的。这个技巧在画微服务架构时特别有用服务内部的模块紧凑排列服务之间留出明显空隙整个图的可读性会提升一个档次。另外连线尽量走直线或者规整的折线避免斜线和曲线交叉。斜线在复杂图里是灾难因为人眼追踪斜线的成本比直线高很多。如果实在避不开交叉就用“跳线”符号也就是在交叉处画一个小弧线表示这两条线没有连接关系。3. 核心细节解析图形、连线与文字的实操要点3.1 图形选择矩形、圆角矩形、圆柱体分别代表什么在 diagram-design 的体系里每种图形都有约定俗成的含义乱用会让人产生误解。我整理了一张对照表你可以直接参考图形常见含义使用场景注意事项直角矩形模块、服务、组件大多数系统元素最通用不知道用什么就用它圆角矩形过程、步骤、状态流程图、状态机圆角半径不要太大否则像按钮圆柱体数据库、存储数据持久化层不要用来表示缓存缓存通常用圆角矩形加虚线菱形判断、分支流程图条件节点出口必须标注条件否则等于没画平行四边形输入输出数据流入流出在架构图里少用容易和矩形混淆虚线框分组、边界划分模块范围虚线框本身不表示实体只是视觉分组这里有个坑很多人喜欢用圆柱体表示“消息队列”或者“缓存”但圆柱体在大多数人的认知里就是数据库。如果你非要用圆柱体表示队列最好在图例里写清楚否则评审的时候一定有人问“这个库是什么库”。我的建议是消息队列用圆角矩形加一个队列图标缓存用圆角矩形加虚线边框这样既区分了类型又不会造成误解。3.2 连线规范箭头、线型、标签的三要素连线是图里最容易出问题的地方。我总结了一个“三要素检查法”箭头方向、线型语义、标签位置。每次画完图沿着每一条线走一遍问自己这三个问题。箭头方向箭头指向的是“被依赖方”还是“数据接收方”这两个方向有时候是相反的。比如 A 调用 B依赖箭头从 A 指向 B但数据流向也是从 A 到 B这两个是一致的。但如果 B 返回结果给 A数据流向就是 B 到 A而依赖关系还是 A 依赖 B。这种情况下我通常只画一条依赖箭头然后在旁边标注“请求/响应”而不是画两条相反方向的箭头那样图会乱。线型语义实线表示同步调用虚线表示异步消息点线表示可选依赖。这个规则不是绝对的但一旦你定了整张图就要统一。我见过一张图里实线虚线混用问作者什么意思他说“随手画的”。这种图在评审时基本会被打回重画。标签位置连线上的文字要放在线的上方或者左侧不要压在线上。如果线是斜的文字保持水平不要跟着斜。标签内容尽量用动词或者动词短语比如“查询库存”“发送通知”而不是只写“库存”“通知”。动词能让人一眼看出这条线在干什么。3.3 文字排版字号、对齐、留白的硬性参数文字是图的灵魂但也是最容易被忽视的部分。diagram-design 对文字的要求可以总结为三个数字字号层级不超过三级对齐方式不超过两种留白不少于元素高度的 30%。字号层级主标题 20-24px模块名称 14-16px注释说明 10-12px。不要出现 13px、15px 这种中间值层级不清晰。我通常只用三档大、中、小分别对应标题、元素名、备注。对齐方式要么全部左对齐要么全部居中对齐。混用对齐方式会让图看起来像拼凑的。如果元素是矩形文字居中对齐比较稳如果元素是分组框文字左对齐更自然。整张图统一一种对齐方式视觉上会干净很多。留白元素内部的文字不要顶到边框上下左右至少留出元素高度的 30% 作为内边距。比如一个 60px 高的矩形文字区域不要超过 40px。这个参数是我试了很多次之后固定下来的低于 30% 会显得拥挤高于 50% 会显得空旷。提示如果你用的是在线绘图工具把网格间距设为 10px所有元素的位置和大小都对齐到网格。这样即使后续调整也不会出现 1px 的错位整张图会显得非常规整。4. 实操过程从零画出一张可评审的架构图4.1 第一步用纸笔列出所有元素和关系不要一上来就打开软件。我习惯先用纸笔或者纯文本编辑器把所有要画的东西列出来。格式很简单元素 - 接入层网关 - 应用层订单服务、库存服务、用户服务 - 数据层订单库、库存库、用户库 - 外部支付系统 关系 - 网关 - 订单服务路由 - 订单服务 - 库存服务扣减库存 - 订单服务 - 支付系统发起支付 - 订单服务 - 订单库读写 - 库存服务 - 库存库读写 - 用户服务 - 用户库读写这一步的目的是把逻辑关系和视觉表现分开。你在纸上改关系的成本几乎为零但在软件里拖来拖去改关系十分钟就过去了。我试过直接上手画结果画到一半发现漏了一个服务整个布局要重排非常浪费时间。列完之后检查一遍有没有循环依赖有没有孤立元素有没有关系方向写反的这些问题在纸面上很容易发现在图上反而容易被线条掩盖。4.2 第二步确定布局骨架和分层根据元素列表确定图的分层结构。上面那个例子自然的分层是接入层在最上面应用层在中间数据层在最下面外部系统放在右侧或者底部。每一层内部元素按调用顺序从左到右排列。分层之间的间距设为 80-100px层内元素间距设为 30-40px。这个比例是我实测下来比较舒服的层与层之间有明显分隔层内元素又足够紧凑。如果你用的是 16:9 的画布三层结构刚好占满高度不会显得太空或者太挤。确定骨架之后先用灰色矩形把每个元素的位置占住不要写文字也不要画连线。这一步叫“占位”目的是确认整体布局是否平衡。如果某个区域太空就调整元素间距如果某个区域太挤就考虑把部分元素移到下一层。4.3 第三步填充元素样式和文字占位确认之后开始给矩形上色、加圆角、写文字。按照前面说的颜色规则我方系统用蓝色外部依赖用灰色数据层用深一点的蓝色或者蓝灰色。文字统一用无衬线字体比如系统默认的 UI 字体不要用宋体或者楷体那些字体在小字号下辨识度很低。写文字的时候注意模块名称用“名词动词”或者“名词名词”的结构比如“订单服务”“库存扣减”“支付网关”。不要写“处理订单的模块”这种长句图里放不下别人也没耐心读。如果确实需要解释用编号标注然后在图下方写注释。4.4 第四步画连线并标注连线从依赖关系的起点画到终点箭头指向被依赖方。同步调用用实线异步消息用虚线。如果两条线交叉尽量调整元素位置避免交叉如果避不开用跳线符号。连线上的标签用动词短语放在线的中点上方的位置。如果线太短放不下标签就把标签放在线的旁边用一条细引线指过去。标签字号比元素名称小一档颜色用深灰色不要用纯黑纯黑在视觉上太重会抢元素的注意力。画完所有连线后整体看一遍有没有箭头方向反的有没有漏标的线有没有两条线重叠在一起分不清的这些问题在评审时都会被问到提前检查一遍能省很多解释时间。4.5 第五步导出前的最终检查清单导出之前我固定会过一遍这个清单所有元素是否对齐到网格颜色是否只用了三种以内每种颜色是否有明确语义连线是否只有实线和虚线两种箭头方向是否一致文字是否只有三档字号对齐方式是否统一是否有图例说明颜色和线型的含义导出格式是 PNG 还是 SVGPNG 用于文档嵌入SVG 用于后续编辑。注意如果图要放进 PPT 或者文档里导出 PNG 时分辨率至少设为 2 倍否则投影或者打印时会模糊。SVG 虽然清晰但有些文档编辑器不支持所以我会同时导出两种格式备用。5. 常见问题与排查技巧实录5.1 图太乱信息量太大怎么办这是最常见的问题。一张图里塞了三十个元素和五十条连线谁看谁晕。我的处理原则是一张图只讲一个故事。如果信息量确实大就拆成多张图第一张讲整体架构第二张讲某个核心流程第三张讲数据模型。每张图只聚焦一个主题图与图之间用编号关联。如果实在不想拆那就做“分层展示”默认只显示高层模块把内部细节折叠起来用“”“-”符号控制展开。很多在线绘图工具支持这种交互导出静态图的时候只导出默认状态需要细节的时候再单独导出展开状态。5.2 连线交叉太多怎么优化连线交叉的根本原因是元素排列顺序和调用顺序不一致。解决办法是调整元素位置让调用关系相近的元素靠在一起。比如订单服务调用了库存服务和支付系统那就把库存服务和支付系统放在订单服务的右侧或者下方而不是放在画布的另一端。如果调整位置之后还是有交叉那就用“跳线”符号或者在交叉点加一个小的白色圆点表示这两条线没有连接。千万不要让两条线直接交叉而不做任何标记那样读者会以为它们连在一起。5.3 评审时别人看不懂图例怎么办图例是图的说明书但很多人画图例的时候很随意。我的做法是图例放在图的右下角或者左下角用一个小方框圈起来里面列出颜色和线型的含义。图例的文字要和图内文字保持同样的字号层级不要图例用 10px 图内用 14px那样看起来像两个东西。如果图里只有一种颜色和一种线型那就不需要图例直接在标题或者注释里说明就行。图例不是必须的只有当图里存在多种视觉编码时才需要。5.4 常见问题速查表问题现象可能原因解决方法图看起来拥挤元素间距太小留白不足层间距调到 80px 以上元素内边距调到 30%颜色混乱颜色超过三种语义不明确减到三种以内每种颜色对应一个语义连线看不清线太细颜色太浅线宽调到 1.5-2px颜色用深灰文字读不清字号太小字体不对最小字号 10px用无衬线字体箭头方向混乱依赖和数据流混用统一用依赖方向数据流用标签说明图例缺失多种视觉编码但没说明加图例框放在角落导出模糊分辨率不够PNG 导出设为 2 倍分辨率5.5 我踩过的三个坑第一个坑是过度依赖自动布局。有些工具提供自动排列功能一键把元素排成网格。听起来很省事但自动布局不考虑语义关系经常把相关的元素排得很远不相关的排在一起。我试过一次自动布局结果订单服务和用户服务被排在一起库存服务被排到角落整个图逻辑全乱了。后来我都是手动布局自动布局只用来做初始占位。第二个坑是颜色用得太花。刚开始画图的时候总想用颜色区分更多东西结果一张图用了六种颜色评审的时候有人问“这个紫色和粉色有什么区别”我自己都答不上来。后来固定用三种颜色反而没人再问颜色的问题了。第三个坑是忘记加图例。有一次画了一张图用了实线和虚线表示同步和异步但没加图例。评审时有人问“虚线是什么意思”我才发现忘了说明。从那以后只要图里用了超过一种线型或者颜色我一定加图例。6. 进阶技巧让图从“能看”变成“好用”6.1 用编号代替长文字图里的文字越少可读性越高。如果某个元素需要解释不要在图里写一大段话而是给它一个编号比如“①”然后在图下方或者单独的注释文档里写“① 订单服务负责订单创建、状态流转和超时取消”。这样图本身保持干净需要细节的人可以去看注释。编号的另一个好处是方便在评审时引用。你可以说“大家看③号元素”而不是“那个蓝色的、在中间的、写着库存服务的框”沟通效率会高很多。6.2 用缩略图做导航如果拆成了多张图可以在每张图的角落放一个缩略图标出当前图在整个架构中的位置。缩略图不用很详细用灰色方块表示各个模块当前模块用高亮色标出就行。这样读者在看细节图的时候不会迷失在整体结构里。6.3 版本管理和变更记录图是会变的。今天画完的架构图下个季度可能就过时了。我习惯在图的右下角加一个小的版本号比如“v1.2”然后在文档里维护一个变更记录写清楚每个版本改了什么。这样评审的时候如果有人问“这个服务上次不是叫这个名字吗”你可以直接翻变更记录而不是靠记忆去解释。版本号不用太复杂主版本号加次版本号就够了。主版本号表示架构有重大调整次版本号表示小修小补。变更记录用表格维护三列版本号、日期、变更内容。6.4 建立自己的图形库画得多了之后你会发现很多元素是重复的。比如“网关”“数据库”“消息队列”这些每次画图都要重新调样式。我的做法是建一个自己的图形库把常用元素做成模板下次直接拖出来用。图形库不用很复杂一个文件里放十几个常用图形就行每个图形预设好颜色、字号、圆角半径。这个习惯帮我省了很多时间。以前画一张架构图要一个小时现在有了图形库二十分钟就能画完而且风格统一不会出现这张图圆角大那张图圆角小的情况。6.5 用灰度测试可读性这是一个很实用的技巧把画好的图转成灰度看看还能不能看懂。如果转成灰度之后某些元素分不清了说明你的颜色对比度不够或者过度依赖颜色来区分元素。好的图在灰度下依然能看清结构因为它的区分主要靠形状、位置和线型颜色只是辅助。我每次导出之前都会做一次灰度测试用图片编辑工具去色就行。如果灰度下没问题彩色下肯定没问题如果灰度下有问题那就调整颜色或者增加形状区分。7. 工具选型不同场景用什么画图7.1 快速草图纸笔或者白板工具如果只是内部讨论不需要正式输出纸笔或者白板工具是最快的。我习惯用白板工具画草图因为可以随时拖拽调整比纸笔灵活。草图不用讲究样式能看清关系就行。讨论完之后把草图截图存档作为正式图的参考。7.2 正式架构图矢量绘图工具正式输出的架构图我推荐用矢量绘图工具。矢量图的好处是放大不失真导出 SVG 之后可以在任何分辨率下保持清晰。选择工具的时候看三点是否支持网格对齐、是否支持自定义图形库、是否支持导出 SVG。这三点满足基本就够用了。7.3 流程图和状态机专用流程图工具流程图和状态机有专门的工具比通用绘图工具更高效。专用工具通常内置了流程图的图形库和自动连线功能画起来更快。但要注意专用工具导出的图风格可能和架构图不一致如果要在同一份文档里混用最好统一一下颜色和字体。7.4 数据可视化图表工具如果图里主要是数据关系比如 ER 图或者数据流图用图表工具比通用绘图工具更合适。图表工具能自动处理实体和关系的布局减少手动调整的工作量。但图表工具的自由度通常较低如果图里有非标准的元素可能还是得用通用绘图工具。8. 团队协作中的 diagram-design 实践8.1 统一图例和样式规范团队里每个人画图的习惯不一样如果各画各的最后放在一起就像拼凑的。我的做法是制定一份简单的样式规范写清楚颜色含义、线型含义、字号层级、对齐方式。规范不用很长一页纸就够了关键是大家都要遵守。规范制定之后找一个大家都要画的图作为样板让每个人都按规范画一遍然后互相评审。这样一轮下来规范就落地了。后面新加入的人直接看样板图就能学会。8.2 图的评审流程图不是画完就完了评审是保证质量的关键环节。我习惯把评审分成两步第一步是逻辑评审只看元素和关系对不对不看样式第二步是视觉评审看样式是否规范、是否清晰。两步分开的好处是逻辑问题在第一步解决不会因为样式问题分散注意力。逻辑评审的时候让作者对着图讲一遍流程其他人跟着走。如果讲的过程中有人卡住了说明图里有歧义需要修改。视觉评审的时候把图投影出来让每个人从自己的位置看一遍如果有看不清的地方就调整字号或者对比度。8.3 图的归档和检索图画多了之后找图是个问题。我习惯按项目或者按模块建文件夹每个文件夹里放该项目的所有图文件名用“日期-主题-版本”的格式比如“20250115-订单架构-v1.2”。这样按文件名排序就能看到最新的版本不用一个个打开看。另外在文档里引用图的时候用相对路径而不是绝对路径这样文件夹整体移动之后引用不会失效。如果图更新了旧版本不要删移到“历史版本”子文件夹里万一需要回溯还能找到。9. 从 diagram-design 延伸出去的思考画图这件事表面上是视觉工作底层其实是结构化思维的训练。你画不出一张清晰的图往往不是因为不会用工具而是因为脑子里的结构本身就是乱的。diagram-design 这套方法逼着你在画之前先把关系理清楚这个“理”的过程比最后画出来的图更有价值。我自己的体会是每次画架构图之前先在纸上列元素和关系的那十分钟经常能发现设计上的漏洞。比如某个服务依赖了一个不该依赖的服务或者某个数据流绕了一圈又回来了。这些问题在代码里可能隐藏得很深但在图上会非常明显。所以我现在把画图当成设计评审的一部分而不是设计完成之后的文档工作。另外图的受众意识很重要。给自己看的图和给别人看的图画法完全不一样。给自己看的图可以很潦草自己能看懂就行给别人看的图要考虑对方的背景知识、阅读习惯、甚至观看环境投影还是打印。diagram-design 的很多规则本质上都是在为受众服务。你越了解受众越能画出他们看得懂的图。最后分享一个小技巧如果你不确定一张图是否清晰找一个完全不了解这个项目的人来看让他用自己的话复述图里的流程。如果他复述得八九不离十说明图没问题如果他卡在某个地方那个地方就是需要修改的重点。这个方法比任何自查清单都有效因为它是从真实读者的角度出发的。