diagram-design 这个名字听起来像某个开源组件库的仓库名但它实际是我给自己定的一套画图规范——从图类型的选择、画布布局、配色规则、连线方式到怎么跟同事一起评审一张架构图把零散的画图经验固化成一套能复用的流程。日常工作中几乎每个人都要画图流程图、架构图、时序图、部署图但真正能把图画明白的人说实话我这些年遇到的不超过三分之一。多数图的问题不是画得不好看而是看的人抓不住重点甚至看不懂作者想表达什么。这个项目要解决的就是这件事。文章下面所有内容都来自我实际踩坑、翻车、改进之后沉淀下来的做法。我会先讲图表设计的核心原则再讲不同类型图的选型边界然后给出一套从原始信息到成图的完整实操流程最后把高频翻车现场整理成排查清单。无论你是刚入行的新人还是带团队的老手我相信这些经验都能直接拿去用。1. 图表设计不是“画图”是一套信息表达的规矩1.1 为什么我决定把“画图”当成一个正经项目来做两年前我在某个跨团队协作项目里当接口人最大的痛点是每个团队拿出来的架构图风格完全不同。有人用 PowerPoint 画框框有人用在线白板画手绘风还有人直接在 IDE 里用文本图。开会时一张图投影出来光解释图例就要花五分钟。更麻烦的是同一套系统在不同文档里有两种画法。开发说“这是服务调用关系图”测试看了以为是部署拓扑图产品又以为模块之间是强依赖。图本身没有统一规范信息传递就变成了猜谜。后来我意识到问题不在于大家不会用工具而在于缺少一套统一的表达规矩什么信息画成什么形状什么关系用什么线重要信息怎么突出次要信息怎么弱化。这些规则一旦定下来任何人都能用任何工具画出风格一致、逻辑清晰的图。diagram-design 就是在这样的背景下起步的最初只是我自己的一份检查清单后来逐渐补全成一套完整的方法。1.2 我总结的三条核心原则层级、克制、直观第一条原则是层级。一张图里只能有一条最重要的信息路径比如核心业务流程或关键依赖链。这条路径要用最重的颜色、最大的区块或最突出的位置体现出来剩下的信息都应该是背景。我见过很多团队画系统架构图把所有模块都画成一模大的的方块结果主调用链和次要依赖混在一起根本分不清先后顺序。第二条原则是克制。色彩和形状的种娄必须限制。我给自己定的上限是颜色不超过五类形状不超过三种线型不超过三种。超过这个阈值图就会变成“彩虹图”人的注意力会被大量无意义的视觉差异消耗掉。克制不意味着单调而是让每一个视觉差异都有明确的语义。第三条原则是直观。图是给人看的不是给自己看的。一张图如果离开作者的讲解就没人能看懂那就是失败的。检验方法很简单把图发给一个不了解背景的同事过五分钟问他图上表达的核心信息是什么。如果答不上来就需要重新设计信息层级和标注。1.3 这套方法适合谁参考我最初以为这套规范只对架构师有用后来发现完全不是。前端工程师画组件依赖图后端画服务调用链路运维画部署拓扑产品画业务流程图测试画用例路径——凡是需要把脑子里复杂的逻辑关系变成一张图的工作都可以从这套方法里受益。如果你带团队这套规范特别适合作为团队内部的“画图共识”。不用强制所有人都用同一个工具只要大家遵循同一种表达规矩协作效率就会有非常明显的提升。如果你只是一个人画图这套方法能帮你在评审时少被追问“这里是什么意思”这种问题。2. 先分清类型你画的到底是流程、结构还是时序2.1 六种最常见图表一张对照表讲清适用范围很多人画图跑偏第一步就错了——选错了图的类型。类型决定了你要表达的关系维度选错类型等于用螺丝刀拧钉子怎么拧都别扭。图类型表达的核心关系典型场景常见误区流程图时间顺序与分支业务流程、算法逻辑、状态流转把组织结构画进流程里架构图系统组成与依赖模块划分、服务拓扑、代码分层把部署信息混进逻辑架构时序图消息先后与交互接口调用、跨系统协作、事件驱动线性顺序画成网状关系ER 图实体与关联数据库设计、领域模型把字段数量画得过细部署图物理节点与网络关系环境搭建、容器编排、机房规划把逻辑模块画进部署节点路线图计划与里程碑版本规划、项目排期、演进方向承诺精确日期实际没人能保证这里面的常见误区值得展开说说。画架构图时最容易犯的错是把部署信息直接塞进来。比如“这个模块跑在三台机器上”这是部署视角应该单独画部署图架构图里硬要塞机器数量和端口号反而会让模块之间的依赖关系看不清。流程图的典型误区则是把组织结构混进来比如“A 团队负责这件事然后交给 B 团队”如果组织职责不是流程的关键判断条件画进去只会干扰主线。2.2 架构图的两种主流画法分层式与拓扑式架构图里面最常画也最难画好的是系统架构图。我总结下来主流画法就两种。第一种是分层式架构图。从上到下把系统按层次展开比如展示层、业务层、数据层。这种画法的优势是阅读路径清晰适合描述系统内部的职责划分。缺点是如果层次之间有复杂的反向依赖连线会交叉得很厉害反而难懂。第二种是拓扑式架构图。强调节点之间的连接关系比如服务 A 调用服务 BB 又依赖 C整体呈现一个网络结构。拓扑式适合表达服务间依赖、数据流向和系统边界。缺点是需要刻意规划布局否则连线会绕成蜘蛛网。我常用的一个技巧是混合使用先用分层式定义主框架再用拓扑式补充跨层的关键依赖。但做这一步的前提是你能明确区分哪些是主结构、哪些是附属依赖。主结构用大区块附属依赖用细连线视觉上自然就有层级了。2.3 画图前先问三句话基本不会跑偏我对自己的要求是任何一张图动笔之前先回答三个问题。给谁看新人看需要补充大量背景注释技术评审看需要突出决策点管理层看只需要结论和风险。一张图不可能同时满足所有读者强行兼顾的结果就是所有人都觉得啰嗦。要传递什么关键信息图的中心思想只能有一句话。比如“登录流程涉及三个子系统失败路径需要特别关注”。这就是图的灵魂画的时候所有元素都要为这句话服务无关信息一律砍掉。最重要的那一条路径在哪里找到它然后让它在视觉上跳出来。其他元素都是它的背景。这个判断是决定图好坏的分水岭也是后面每一步设计取舍的依据。3. 从需求到成图的完整实操流程3.1 七步法从原始信息到第一版草稿很多人一上来就打开画图工具边想边画结果画到一半发现逻辑不通又推翻重来。我现在的习惯是先不碰工具用手写或纯文本把信息理顺再进画布。七步流程如下。第一步收集原始素材。把需求文档、代码调用关系、接口定义、会议纪要先堆在一张纸上不管顺序和结构先确认素材完整。 第二步确定读者和信息层级。按上一节三个问题回答给谁看核心信息是什么主路径在哪里 第三步选图类型。对照六种图的适用范围选最贴合表达目标的一种。 第四步在纸上画草图。这一步非常关键只用框和线画出大结构不纠结样式。草图能帮你在五分钟内验证逻辑是否成立。很多问题在这一步就能暴露出来比如模块缺依赖、流程有死循环。 第五步用工具实现第一版。把草图搬到工具里先摆好主结构再连依赖线最后加标注。不要边摆边调颜色第一版的目标是“结构正确”。 第六步统一视觉参数。对齐网格、统一字号、上色、加图例把所有视觉元素调整到位。 第七步找一个人看图并收集反馈。最好是不知道背景的人让他描述自己看到了什么。如果描述和你的核心信息一致这张图就成功了如果不一致回到第四五六步迭代。这套流程我用了很长时间最大的体会是第四步和第七步的价值被严重低估。很多人跳过了扎实的草图阶段直接在工具里反复挪框花了大量时间在排版而非逻辑上。而评审反馈是唯一能检验图是否成功的标准。3.2 一次真实的迭代过程从信息堆到一张清楚的关系图讲一个具体事例。某次我协助设计一个订单中心模块最初拿到的信息是一堆文字订单服务负责创建和查询订单支付服务处理支付回调库存服务在订单创建时扣减库存优惠券服务在支付成功后锁定并核销优惠券当支付失败时库存要回滚优惠券要释放。按照七步法来第一步把素材整理成无序列表。第二步确定读者是后端的同事核心信息是“订单创建这个主流程调用了哪些服务以及失败的补偿链路”。于是图画的类型确定为流程图加依赖信息。第四步草图很潦草但已经能看出来主流程是订单创建调用库存扣减再发起支付支付成功的回调里核销优惠券。失败路径则是支付失败触发库存回滚和优惠券释放。到第五步用工具正式画的时候我没有把文本里的所有细节都画进去。比如“订单服务负责创建和查询订单”查询是另一个独立场景我选择它留在注释文字里而不是作为流程图里的分支——否则主路径会被信息淹没。最终成图只保留了创建订单、扣库存、发起支付、支付回调、核销优惠券、失败回滚四条连线。一张本来会乱成一团的图被压缩成了一条清晰的主链和一条失败补偿链。读者拿到图十秒内就能说出核心逻辑。3.3 落地的视觉参数你可以直接抄作业视觉参数是让图从“能看”到“专业”的分水岭。我整理了一份自己的默认参数你可以在此基础上调整。画布比例默认用 16:9 横版左侧留出标题和信息区。整体对齐用 8 像素网格所有方框的位置都对齐到网格线上间距不一致最明显的表现就是图面显得“脏”。字号上标题 18 号加粗模块名 14 号说明性文字 12 号。中文字体用无衬线体英文和数字用等宽字体保持统一。模块间距控制在 20 到 40 像素之间太密显得压抑太疏显得松散。边框默认用 1 像素需要突出的重点模块加粗到 2 到 3 像素。配色上主结构使用同一色系用不同深浅表示层级。推荐一个稳定的组合主色用深蓝次级用浅灰强调色用暖橙错误/风险用红色成功/正常路径用绿色。背景保持纯白或浅灰不要加任何纹理。这套参数最核心的逻辑是让所有视觉差异都对应信息差异。字号不同代表层级不同颜色不同代表语义不同线宽不同代表强度不同。如果任何一个视觉参数没有对应信息含义它就是噪音应该删掉。4. 提升图表表现力的细节设计4.1 箭头、边框、圆角这些“小零件”决定专业程度大结构对了之后细节就决定一张图的质感。我整理了几个最容易忽视的细节。箭头是最容易用错的地方。箭头表达方向性和依赖关系画之前要明确每个箭头的语义是数据流还是控制流是同步还是异步是强依赖还是弱引用。千万别在一张图里混用相同样式的箭头表达不同语义。我见过最典型的问题有人用实线箭头表示服务调用也用同样的实线箭头表示数据库访问读者不追问根本不知道线的含义不同。边框的虚实也有讲究。我的规则是实线框表示明确的组件或系统虚线框表示逻辑分组或可选模块。比如“支付网关”是一个实体用实线“海外扩展区域”是逻辑分组用虚线包住多个模块。这套规则执行起来简单但能让图的逻辑层次立刻清晰起来。圆角的语义同样可以定义。大圆角容器表示系统边界或逻辑区域小圆角方块表示具体模块直角框表示外部系统或第三方。这样读者不看文字只看形状就能区分元素类型。这个技巧在复杂的架构图里特别有效。4.2 颜色语义化与留白为什么你的图一眼看去很乱“一眼看去很乱”是图表设计里最抽象也最常见的反馈它的根源通常有两个颜色没有语义化以及留白不够。颜色语义化是指每种颜色都承担固定的信息含义而不是“我觉得这个模块用蓝色好看”。我定义了一套额度内的用法蓝色系代表核心业务模块灰色系代表基础组件和外部依赖橙色系代表当前版本的重点改动红色系代表风险、异常路径或需要预警的节点绿色系代表正常状态或关键成功路径。这套语义在全团队达成共识后任何人画图都可以沿用评审时一眼就能识别出重点。留白是很多程序员画图时完全忽略的元素。画布四周留出至少 40 像素边距模块之间避免拥挤。最重要的模块周围留出比其他模块更大的空白区域相当于给它一个视觉缓冲区。人眼天然会被间距更开阔的元素吸引这和排版里的“留白即是强调”是同一个道理。4.3 图例与标注让一张图在没有讲解时也能自解释我经常提醒自己一句话好图不需要翻译。图例就是实现“自解释”的关键。图例应放在图的右上角或左下角包含各类框的含义、各类线的含义、颜色对应的语义。图例的字号可以比正文小一号但信息必须完整。有人觉得图例碍事但真正需要时才知道它的价值——你把图贴到文档里或发给新同事时没有图例就只能靠嘴讲。标注方面最容易被忽略的是“接口名”和“协议名”。画服务调用图时线上最好标注接口名或消息主题名而不是只画一条连线。这样图的信息密度会立刻抬一个量级。不过标注也要克制关键路径标注完整次要路径只标注模块名避免整张图全是文字。另外一个使用技巧是版本信息。在标题区标注这张图对应哪个版本、哪天更新的、作者是谁。架构和代码一样是会演进的没有版本信息的图会在三个月后变成“历史不可考图”到时候没人敢改它也没人敢删它。5. 常见的图设计问题与排查经验5.1 我踩过的五个真实翻车现场翻车现场一逻辑跳层。有一次我画系统调用链把“订单服务”“MySQL 数据库”“缓存”“消息队列”放在同一层还混进了“财务对账”这种业务流程节点。结果被同事当场指出调用链上的节点有的是进程有的是存储有的是抽象业务动作根本不在一个抽象层级。后来我养成了一个习惯——画完图先给每个节点标注类型。逻辑上同一层的东西放在同一层不同层用容器包起来不能平铺。翻车现场二箭头满天飞。某个服务依赖图我为了展示所有细节画了三十几条连线结果图面交叉成了蜘蛛网没人看得清主线。后来强制自己遵守一条规则如果一个节点关联的连线超过五条就该考虑合并依赖或调整布局。这个限制逼我重新思考哪些依赖是真正需要画的。翻车现场三五颜六色的彩虹图。早期画画喜欢每个模块一个颜色自我感觉良好但评审时被问“这个模块为什么是紫色的”我答不上来。从此我只用固定色板颜色必然对应明确的语义。翻车现场四没有边界的“无限画布”。在无限缩放的画布上我经常画着画着就把内容铺满了整个屏幕没有任何聚合关系。后来我规定了画布边界要么用一个大圆角容器包住整个系统要么把内容限制在 16:9 的矩形里。容器边界就是系统边界边界越清晰读者越容易定位上下文。翻车现场五命名随意。早期有些模块叫“服务 1”“处理模块”部门内部看得懂换个人看就是天书。现在我的规范是模块名必须是一句话能说清职责的名字比如“库存扣减服务”而不是“服务 A”。所有缩写首次出现必须附全称或注释。5.2 高频问题速查表症状原因排查办法图看起来乱同层元素尺寸不一致、间距不等对齐到网格统一模块尺寸和间距看不清主流程没有突出主路径把核心链路加粗或改用高对比色连线交叉多布局未按逻辑分组重新分组减少跨区连线颜色含义不明未做语义化定义色板语义并向读者说明模块不知用途命名太泛改用职责清晰的命名并补充注释图上文字太多信息层级失控把大量说明挪到图外文字只保留关键标注无法确认版本缺少版本信息标题区增加日期、版本号、作者新人不理解缺少图例和术语说明补充图例、缩写对照、阅读顺序提示这张表是我做图审时的主要依据。遇到问题时不瞎猜而是对着症状找原因花的时间能少很多。5.3 如何跟团队对图审图的三个视角画完图只是第一步跟别人一起看图才是真正的检验。我推荐在评审时至少找三类人分别用三个视角看图。第一个视角是逻辑正确性通常找熟悉系统的后端开发来看。他关心的是这条调用关系是否真实有没有漏掉关键的失败处理缓存和数据库的读写顺序对不对这个视角解决“图对不对”的问题。 第二个视角是业务完整性通常找产品经理或业务负责人来看。他关心的是核心业务路径是否覆盖异常分支是否表达清楚这个视角解决“图全不全”的问题。 第三个视角是信息可达性最好是找一个新人或非技术同事来看。他关心的是我能不能看懂哪个地方困惑这个视角解决“图好不好懂”的问题。三个视角缺一不可。逻辑正确但新人看不懂是表达问题新人能看懂但逻辑不对是事实问题业务路径没覆盖是范围问题。评审的关键不是让你把所有问题都改一遍而是让你知道图在哪方面最薄弱然后有针对性地迭代。6. 工具、AI 辅助与我的最后一点体会6.1 工具选型哪类图用哪个工具最靠谱画图工具没有唯一解关键是根据场景选对工具。我用过并仍在用的有这几个。手绘风草图和头脑风暴用 Excalidraw 最舒服。它自带手绘感能降低读者对精度的苛求特别适合早期逻辑讨论。 正式的架构图和流程图我推荐用 diagrams.net开源、免费、本地化好文件可以存在 git 仓库里做版本管理非常契合开发团队的工作流。 复杂的时序图和 UML 图PlantUML 这类基于文本描述的工具效率很高。文本描述能进代码仓库和代码一起评审、一起 diff。 在线协作白板适合多人实时编辑但缺点是导出效果一般且文件格式封闭我一般只在讨论阶段使用最终成图会搬到正式工具里重画。选工具的一个重要原则是工具应该适配你的工作流而不是反向绑架你。如果你画的图需要和代码一起维护优先选文本型或文件型工具如果只需要一次性会议展示在线白板完全够用。6.2 AI 生成图表的正确用法现在不少 AI 工具能根据文本描述直接生成图表代码或框架图这些工具能节省大量时间但直接用的效果通常不太好。我的经验是AI 可以当草稿生成器但要产出高质量图必须人工改三轮。第一轮是准备。把核心信息用结构化文字描述清楚比如“订单服务调用库存服务成功后再调用支付服务失败时调用补偿服务”。这一步越清晰AI 给出的初稿越接近目标。 第二轮是删减。AI 生成的图基本都会信息过载会把所有描述里的细节都画出来。你需要对照“核心信息是什么”的标准删掉无关的节点和连线。 第三轮是规范化和美化。把 AI 输出的默认样式全部改为自己团队的视觉规范统一配色、字号、线型。这一轮不能省否则图看起来“像 AI 画的”风格与团队标准不一致。AI 的价值是帮你跳过从零到一的空白恐惧但图和代码一样最终质量还是取决于人的判断。依赖 AI 生成而不做人工打磨只会得到一张比平均线略高的平庸图。6.3 什么时候不该画图以及我现在的习惯画图不是万能药。依赖关系有十几条但多为重复模式时表格更直观逻辑描述极复杂但只有指标对比时文字列表更好。我给自己定的判断标准是图应该让读者“看清关系”如果信息本质是“对比数据”或“单调枚举”画图反而浪费精力。我自己现在的习惯是无论画什么图都会先在文档里写下核心信息的完整文字描述再按章七步法画图。文字和图像结合才能真正确认逻辑没有漏洞。图不是最终交付物它只是让逻辑更清晰的手段。一个好的团队画图规范应该和代码规范一样被认真对待因为从一张图的呈现方式就能看出团队的思维质量。diagram-design 这套方法真正给我带来的价值是让我把每一张图都当成一次信息表达的机会。以前我随手画完图就丢进文档现在我会先想清楚读者、核心信息、主路径三件事再动手。正因为这样我后来参加的评审几乎没有人再在“这是什么意思”上浪费时间。如果你也经常被图折磨不妨从下一张图开始试着先回答那三个问题再打开工具。 
长河君 · 2026/10/21 10:11:56 · 阅读 1.2k 把画图变成一项工程：架构图与流程图的表达规范
diagram-design 这个名字听起来像某个开源组件库的仓库名但它实际是我给自己定的一套画图规范——从图类型的选择、画布布局、配色规则、连线方式到怎么跟同事一起评审一张架构图把零散的画图经验固化成一套能复用的流程。日常工作中几乎每个人都要画图流程图、架构图、时序图、部署图但真正能把图画明白的人说实话我这些年遇到的不超过三分之一。多数图的问题不是画得不好看而是看的人抓不住重点甚至看不懂作者想表达什么。这个项目要解决的就是这件事。文章下面所有内容都来自我实际踩坑、翻车、改进之后沉淀下来的做法。我会先讲图表设计的核心原则再讲不同类型图的选型边界然后给出一套从原始信息到成图的完整实操流程最后把高频翻车现场整理成排查清单。无论你是刚入行的新人还是带团队的老手我相信这些经验都能直接拿去用。1. 图表设计不是“画图”是一套信息表达的规矩1.1 为什么我决定把“画图”当成一个正经项目来做两年前我在某个跨团队协作项目里当接口人最大的痛点是每个团队拿出来的架构图风格完全不同。有人用 PowerPoint 画框框有人用在线白板画手绘风还有人直接在 IDE 里用文本图。开会时一张图投影出来光解释图例就要花五分钟。更麻烦的是同一套系统在不同文档里有两种画法。开发说“这是服务调用关系图”测试看了以为是部署拓扑图产品又以为模块之间是强依赖。图本身没有统一规范信息传递就变成了猜谜。后来我意识到问题不在于大家不会用工具而在于缺少一套统一的表达规矩什么信息画成什么形状什么关系用什么线重要信息怎么突出次要信息怎么弱化。这些规则一旦定下来任何人都能用任何工具画出风格一致、逻辑清晰的图。diagram-design 就是在这样的背景下起步的最初只是我自己的一份检查清单后来逐渐补全成一套完整的方法。1.2 我总结的三条核心原则层级、克制、直观第一条原则是层级。一张图里只能有一条最重要的信息路径比如核心业务流程或关键依赖链。这条路径要用最重的颜色、最大的区块或最突出的位置体现出来剩下的信息都应该是背景。我见过很多团队画系统架构图把所有模块都画成一模大的的方块结果主调用链和次要依赖混在一起根本分不清先后顺序。第二条原则是克制。色彩和形状的种娄必须限制。我给自己定的上限是颜色不超过五类形状不超过三种线型不超过三种。超过这个阈值图就会变成“彩虹图”人的注意力会被大量无意义的视觉差异消耗掉。克制不意味着单调而是让每一个视觉差异都有明确的语义。第三条原则是直观。图是给人看的不是给自己看的。一张图如果离开作者的讲解就没人能看懂那就是失败的。检验方法很简单把图发给一个不了解背景的同事过五分钟问他图上表达的核心信息是什么。如果答不上来就需要重新设计信息层级和标注。1.3 这套方法适合谁参考我最初以为这套规范只对架构师有用后来发现完全不是。前端工程师画组件依赖图后端画服务调用链路运维画部署拓扑产品画业务流程图测试画用例路径——凡是需要把脑子里复杂的逻辑关系变成一张图的工作都可以从这套方法里受益。如果你带团队这套规范特别适合作为团队内部的“画图共识”。不用强制所有人都用同一个工具只要大家遵循同一种表达规矩协作效率就会有非常明显的提升。如果你只是一个人画图这套方法能帮你在评审时少被追问“这里是什么意思”这种问题。2. 先分清类型你画的到底是流程、结构还是时序2.1 六种最常见图表一张对照表讲清适用范围很多人画图跑偏第一步就错了——选错了图的类型。类型决定了你要表达的关系维度选错类型等于用螺丝刀拧钉子怎么拧都别扭。图类型表达的核心关系典型场景常见误区流程图时间顺序与分支业务流程、算法逻辑、状态流转把组织结构画进流程里架构图系统组成与依赖模块划分、服务拓扑、代码分层把部署信息混进逻辑架构时序图消息先后与交互接口调用、跨系统协作、事件驱动线性顺序画成网状关系ER 图实体与关联数据库设计、领域模型把字段数量画得过细部署图物理节点与网络关系环境搭建、容器编排、机房规划把逻辑模块画进部署节点路线图计划与里程碑版本规划、项目排期、演进方向承诺精确日期实际没人能保证这里面的常见误区值得展开说说。画架构图时最容易犯的错是把部署信息直接塞进来。比如“这个模块跑在三台机器上”这是部署视角应该单独画部署图架构图里硬要塞机器数量和端口号反而会让模块之间的依赖关系看不清。流程图的典型误区则是把组织结构混进来比如“A 团队负责这件事然后交给 B 团队”如果组织职责不是流程的关键判断条件画进去只会干扰主线。2.2 架构图的两种主流画法分层式与拓扑式架构图里面最常画也最难画好的是系统架构图。我总结下来主流画法就两种。第一种是分层式架构图。从上到下把系统按层次展开比如展示层、业务层、数据层。这种画法的优势是阅读路径清晰适合描述系统内部的职责划分。缺点是如果层次之间有复杂的反向依赖连线会交叉得很厉害反而难懂。第二种是拓扑式架构图。强调节点之间的连接关系比如服务 A 调用服务 BB 又依赖 C整体呈现一个网络结构。拓扑式适合表达服务间依赖、数据流向和系统边界。缺点是需要刻意规划布局否则连线会绕成蜘蛛网。我常用的一个技巧是混合使用先用分层式定义主框架再用拓扑式补充跨层的关键依赖。但做这一步的前提是你能明确区分哪些是主结构、哪些是附属依赖。主结构用大区块附属依赖用细连线视觉上自然就有层级了。2.3 画图前先问三句话基本不会跑偏我对自己的要求是任何一张图动笔之前先回答三个问题。给谁看新人看需要补充大量背景注释技术评审看需要突出决策点管理层看只需要结论和风险。一张图不可能同时满足所有读者强行兼顾的结果就是所有人都觉得啰嗦。要传递什么关键信息图的中心思想只能有一句话。比如“登录流程涉及三个子系统失败路径需要特别关注”。这就是图的灵魂画的时候所有元素都要为这句话服务无关信息一律砍掉。最重要的那一条路径在哪里找到它然后让它在视觉上跳出来。其他元素都是它的背景。这个判断是决定图好坏的分水岭也是后面每一步设计取舍的依据。3. 从需求到成图的完整实操流程3.1 七步法从原始信息到第一版草稿很多人一上来就打开画图工具边想边画结果画到一半发现逻辑不通又推翻重来。我现在的习惯是先不碰工具用手写或纯文本把信息理顺再进画布。七步流程如下。第一步收集原始素材。把需求文档、代码调用关系、接口定义、会议纪要先堆在一张纸上不管顺序和结构先确认素材完整。 第二步确定读者和信息层级。按上一节三个问题回答给谁看核心信息是什么主路径在哪里 第三步选图类型。对照六种图的适用范围选最贴合表达目标的一种。 第四步在纸上画草图。这一步非常关键只用框和线画出大结构不纠结样式。草图能帮你在五分钟内验证逻辑是否成立。很多问题在这一步就能暴露出来比如模块缺依赖、流程有死循环。 第五步用工具实现第一版。把草图搬到工具里先摆好主结构再连依赖线最后加标注。不要边摆边调颜色第一版的目标是“结构正确”。 第六步统一视觉参数。对齐网格、统一字号、上色、加图例把所有视觉元素调整到位。 第七步找一个人看图并收集反馈。最好是不知道背景的人让他描述自己看到了什么。如果描述和你的核心信息一致这张图就成功了如果不一致回到第四五六步迭代。这套流程我用了很长时间最大的体会是第四步和第七步的价值被严重低估。很多人跳过了扎实的草图阶段直接在工具里反复挪框花了大量时间在排版而非逻辑上。而评审反馈是唯一能检验图是否成功的标准。3.2 一次真实的迭代过程从信息堆到一张清楚的关系图讲一个具体事例。某次我协助设计一个订单中心模块最初拿到的信息是一堆文字订单服务负责创建和查询订单支付服务处理支付回调库存服务在订单创建时扣减库存优惠券服务在支付成功后锁定并核销优惠券当支付失败时库存要回滚优惠券要释放。按照七步法来第一步把素材整理成无序列表。第二步确定读者是后端的同事核心信息是“订单创建这个主流程调用了哪些服务以及失败的补偿链路”。于是图画的类型确定为流程图加依赖信息。第四步草图很潦草但已经能看出来主流程是订单创建调用库存扣减再发起支付支付成功的回调里核销优惠券。失败路径则是支付失败触发库存回滚和优惠券释放。到第五步用工具正式画的时候我没有把文本里的所有细节都画进去。比如“订单服务负责创建和查询订单”查询是另一个独立场景我选择它留在注释文字里而不是作为流程图里的分支——否则主路径会被信息淹没。最终成图只保留了创建订单、扣库存、发起支付、支付回调、核销优惠券、失败回滚四条连线。一张本来会乱成一团的图被压缩成了一条清晰的主链和一条失败补偿链。读者拿到图十秒内就能说出核心逻辑。3.3 落地的视觉参数你可以直接抄作业视觉参数是让图从“能看”到“专业”的分水岭。我整理了一份自己的默认参数你可以在此基础上调整。画布比例默认用 16:9 横版左侧留出标题和信息区。整体对齐用 8 像素网格所有方框的位置都对齐到网格线上间距不一致最明显的表现就是图面显得“脏”。字号上标题 18 号加粗模块名 14 号说明性文字 12 号。中文字体用无衬线体英文和数字用等宽字体保持统一。模块间距控制在 20 到 40 像素之间太密显得压抑太疏显得松散。边框默认用 1 像素需要突出的重点模块加粗到 2 到 3 像素。配色上主结构使用同一色系用不同深浅表示层级。推荐一个稳定的组合主色用深蓝次级用浅灰强调色用暖橙错误/风险用红色成功/正常路径用绿色。背景保持纯白或浅灰不要加任何纹理。这套参数最核心的逻辑是让所有视觉差异都对应信息差异。字号不同代表层级不同颜色不同代表语义不同线宽不同代表强度不同。如果任何一个视觉参数没有对应信息含义它就是噪音应该删掉。4. 提升图表表现力的细节设计4.1 箭头、边框、圆角这些“小零件”决定专业程度大结构对了之后细节就决定一张图的质感。我整理了几个最容易忽视的细节。箭头是最容易用错的地方。箭头表达方向性和依赖关系画之前要明确每个箭头的语义是数据流还是控制流是同步还是异步是强依赖还是弱引用。千万别在一张图里混用相同样式的箭头表达不同语义。我见过最典型的问题有人用实线箭头表示服务调用也用同样的实线箭头表示数据库访问读者不追问根本不知道线的含义不同。边框的虚实也有讲究。我的规则是实线框表示明确的组件或系统虚线框表示逻辑分组或可选模块。比如“支付网关”是一个实体用实线“海外扩展区域”是逻辑分组用虚线包住多个模块。这套规则执行起来简单但能让图的逻辑层次立刻清晰起来。圆角的语义同样可以定义。大圆角容器表示系统边界或逻辑区域小圆角方块表示具体模块直角框表示外部系统或第三方。这样读者不看文字只看形状就能区分元素类型。这个技巧在复杂的架构图里特别有效。4.2 颜色语义化与留白为什么你的图一眼看去很乱“一眼看去很乱”是图表设计里最抽象也最常见的反馈它的根源通常有两个颜色没有语义化以及留白不够。颜色语义化是指每种颜色都承担固定的信息含义而不是“我觉得这个模块用蓝色好看”。我定义了一套额度内的用法蓝色系代表核心业务模块灰色系代表基础组件和外部依赖橙色系代表当前版本的重点改动红色系代表风险、异常路径或需要预警的节点绿色系代表正常状态或关键成功路径。这套语义在全团队达成共识后任何人画图都可以沿用评审时一眼就能识别出重点。留白是很多程序员画图时完全忽略的元素。画布四周留出至少 40 像素边距模块之间避免拥挤。最重要的模块周围留出比其他模块更大的空白区域相当于给它一个视觉缓冲区。人眼天然会被间距更开阔的元素吸引这和排版里的“留白即是强调”是同一个道理。4.3 图例与标注让一张图在没有讲解时也能自解释我经常提醒自己一句话好图不需要翻译。图例就是实现“自解释”的关键。图例应放在图的右上角或左下角包含各类框的含义、各类线的含义、颜色对应的语义。图例的字号可以比正文小一号但信息必须完整。有人觉得图例碍事但真正需要时才知道它的价值——你把图贴到文档里或发给新同事时没有图例就只能靠嘴讲。标注方面最容易被忽略的是“接口名”和“协议名”。画服务调用图时线上最好标注接口名或消息主题名而不是只画一条连线。这样图的信息密度会立刻抬一个量级。不过标注也要克制关键路径标注完整次要路径只标注模块名避免整张图全是文字。另外一个使用技巧是版本信息。在标题区标注这张图对应哪个版本、哪天更新的、作者是谁。架构和代码一样是会演进的没有版本信息的图会在三个月后变成“历史不可考图”到时候没人敢改它也没人敢删它。5. 常见的图设计问题与排查经验5.1 我踩过的五个真实翻车现场翻车现场一逻辑跳层。有一次我画系统调用链把“订单服务”“MySQL 数据库”“缓存”“消息队列”放在同一层还混进了“财务对账”这种业务流程节点。结果被同事当场指出调用链上的节点有的是进程有的是存储有的是抽象业务动作根本不在一个抽象层级。后来我养成了一个习惯——画完图先给每个节点标注类型。逻辑上同一层的东西放在同一层不同层用容器包起来不能平铺。翻车现场二箭头满天飞。某个服务依赖图我为了展示所有细节画了三十几条连线结果图面交叉成了蜘蛛网没人看得清主线。后来强制自己遵守一条规则如果一个节点关联的连线超过五条就该考虑合并依赖或调整布局。这个限制逼我重新思考哪些依赖是真正需要画的。翻车现场三五颜六色的彩虹图。早期画画喜欢每个模块一个颜色自我感觉良好但评审时被问“这个模块为什么是紫色的”我答不上来。从此我只用固定色板颜色必然对应明确的语义。翻车现场四没有边界的“无限画布”。在无限缩放的画布上我经常画着画着就把内容铺满了整个屏幕没有任何聚合关系。后来我规定了画布边界要么用一个大圆角容器包住整个系统要么把内容限制在 16:9 的矩形里。容器边界就是系统边界边界越清晰读者越容易定位上下文。翻车现场五命名随意。早期有些模块叫“服务 1”“处理模块”部门内部看得懂换个人看就是天书。现在我的规范是模块名必须是一句话能说清职责的名字比如“库存扣减服务”而不是“服务 A”。所有缩写首次出现必须附全称或注释。5.2 高频问题速查表症状原因排查办法图看起来乱同层元素尺寸不一致、间距不等对齐到网格统一模块尺寸和间距看不清主流程没有突出主路径把核心链路加粗或改用高对比色连线交叉多布局未按逻辑分组重新分组减少跨区连线颜色含义不明未做语义化定义色板语义并向读者说明模块不知用途命名太泛改用职责清晰的命名并补充注释图上文字太多信息层级失控把大量说明挪到图外文字只保留关键标注无法确认版本缺少版本信息标题区增加日期、版本号、作者新人不理解缺少图例和术语说明补充图例、缩写对照、阅读顺序提示这张表是我做图审时的主要依据。遇到问题时不瞎猜而是对着症状找原因花的时间能少很多。5.3 如何跟团队对图审图的三个视角画完图只是第一步跟别人一起看图才是真正的检验。我推荐在评审时至少找三类人分别用三个视角看图。第一个视角是逻辑正确性通常找熟悉系统的后端开发来看。他关心的是这条调用关系是否真实有没有漏掉关键的失败处理缓存和数据库的读写顺序对不对这个视角解决“图对不对”的问题。 第二个视角是业务完整性通常找产品经理或业务负责人来看。他关心的是核心业务路径是否覆盖异常分支是否表达清楚这个视角解决“图全不全”的问题。 第三个视角是信息可达性最好是找一个新人或非技术同事来看。他关心的是我能不能看懂哪个地方困惑这个视角解决“图好不好懂”的问题。三个视角缺一不可。逻辑正确但新人看不懂是表达问题新人能看懂但逻辑不对是事实问题业务路径没覆盖是范围问题。评审的关键不是让你把所有问题都改一遍而是让你知道图在哪方面最薄弱然后有针对性地迭代。6. 工具、AI 辅助与我的最后一点体会6.1 工具选型哪类图用哪个工具最靠谱画图工具没有唯一解关键是根据场景选对工具。我用过并仍在用的有这几个。手绘风草图和头脑风暴用 Excalidraw 最舒服。它自带手绘感能降低读者对精度的苛求特别适合早期逻辑讨论。 正式的架构图和流程图我推荐用 diagrams.net开源、免费、本地化好文件可以存在 git 仓库里做版本管理非常契合开发团队的工作流。 复杂的时序图和 UML 图PlantUML 这类基于文本描述的工具效率很高。文本描述能进代码仓库和代码一起评审、一起 diff。 在线协作白板适合多人实时编辑但缺点是导出效果一般且文件格式封闭我一般只在讨论阶段使用最终成图会搬到正式工具里重画。选工具的一个重要原则是工具应该适配你的工作流而不是反向绑架你。如果你画的图需要和代码一起维护优先选文本型或文件型工具如果只需要一次性会议展示在线白板完全够用。6.2 AI 生成图表的正确用法现在不少 AI 工具能根据文本描述直接生成图表代码或框架图这些工具能节省大量时间但直接用的效果通常不太好。我的经验是AI 可以当草稿生成器但要产出高质量图必须人工改三轮。第一轮是准备。把核心信息用结构化文字描述清楚比如“订单服务调用库存服务成功后再调用支付服务失败时调用补偿服务”。这一步越清晰AI 给出的初稿越接近目标。 第二轮是删减。AI 生成的图基本都会信息过载会把所有描述里的细节都画出来。你需要对照“核心信息是什么”的标准删掉无关的节点和连线。 第三轮是规范化和美化。把 AI 输出的默认样式全部改为自己团队的视觉规范统一配色、字号、线型。这一轮不能省否则图看起来“像 AI 画的”风格与团队标准不一致。AI 的价值是帮你跳过从零到一的空白恐惧但图和代码一样最终质量还是取决于人的判断。依赖 AI 生成而不做人工打磨只会得到一张比平均线略高的平庸图。6.3 什么时候不该画图以及我现在的习惯画图不是万能药。依赖关系有十几条但多为重复模式时表格更直观逻辑描述极复杂但只有指标对比时文字列表更好。我给自己定的判断标准是图应该让读者“看清关系”如果信息本质是“对比数据”或“单调枚举”画图反而浪费精力。我自己现在的习惯是无论画什么图都会先在文档里写下核心信息的完整文字描述再按章七步法画图。文字和图像结合才能真正确认逻辑没有漏洞。图不是最终交付物它只是让逻辑更清晰的手段。一个好的团队画图规范应该和代码规范一样被认真对待因为从一张图的呈现方式就能看出团队的思维质量。diagram-design 这套方法真正给我带来的价值是让我把每一张图都当成一次信息表达的机会。以前我随手画完图就丢进文档现在我会先想清楚读者、核心信息、主路径三件事再动手。正因为这样我后来参加的评审几乎没有人再在“这是什么意思”上浪费时间。如果你也经常被图折磨不妨从下一张图开始试着先回答那三个问题再打开工具。