1. 从一张草图到一套系统diagram-design 到底在解决什么问题第一次看到 “diagram-design” 这个标题很多人会以为它只是教你怎么把图画得好看一点。但真正做过技术方案、写过设计文档、给团队讲过架构的人都知道画图这件事从来不只是“美不美”的问题。一张图能不能把复杂系统讲清楚能不能让产品、研发、测试、运维在同一个语境下对齐认知能不能在三个月后自己回头看还能秒懂这才是 diagram-design 的核心价值。我做了十多年一线项目画过的架构图、流程图、时序图、状态机图、部署图、数据流图加起来没有一千也有八百张。早期我也走过弯路用绘图工具拖一堆方框和箭头颜色花里胡哨结果评审会上大家盯着图看了五分钟问的第一个问题却是“这个箭头到底代表数据流还是控制流”。那一刻我才意识到diagram-design 不是美术工作而是信息设计。它要解决的是“把脑子里的结构无损地搬到别人脑子里”这件事。所以这篇内容适合三类人第一类是需要频繁输出技术方案、系统设计、流程说明的工程师和架构师第二类是需要用图跟非技术角色对齐需求的产品经理和项目负责人第三类是想建立一套可复用、可维护、可协作的图表规范让团队文档不再各画各的。无论你之前是用什么工具画图只要你想让图真正“会说话”diagram-design 这套思路都能直接抄作业。2. 内容整体设计与思路拆解2.1 为什么 diagram-design 要先定“信息层级”而不是先选工具很多人一上来就问用什么工具画图我的回答永远是先别管工具。diagram-design 的第一步是确定信息层级。一张图里哪些是核心实体哪些是支撑组件哪些是外部依赖哪些是可选路径这些如果不先想清楚换什么工具都白搭。我通常把图的信息分成三层。第一层是主叙事层也就是这张图最想让读者记住的三到五个关键节点。第二层是关系层描述这些节点之间怎么连接、方向如何、有没有条件分支。第三层是注释层包括协议、端口、数据格式、异常说明、版本号等细节。主叙事层决定图的骨架关系层决定图的逻辑注释层决定图的可落地性。为什么这个顺序不能反因为一旦你先陷入注释层比如纠结某个接口用 HTTP 还是 gRPC图就会变得又大又碎读者根本抓不住重点。我见过太多架构图密密麻麻写满了技术栈但看完不知道系统到底分几块、谁调用谁。这就是典型的“信息层级塌陷”。提示画图前先用一句话写下这张图的结论比如“用户请求经过网关后由三个服务协同完成”。如果这句话写不出来说明你还没想清楚先别打开绘图工具。2.2 方案选型背后的考量为什么我最终偏向“约束型”图表规范diagram-design 的另一个核心决策是用自由画布还是用约束型规范。自由画布看起来很爽想怎么摆就怎么摆但团队协作时会迅速失控。A 同学用蓝色表示服务B 同学用蓝色表示数据库C 同学用蓝色表示外部系统最后图例都救不回来。我后来坚定选择约束型规范原因有三个。第一认知成本低。当颜色、形状、线型都有固定语义时读者不需要每次重新学习图例看一眼就能进入内容。第二协作效率高。新人加入项目只要给他一份规范他画出来的图就能直接进文档不需要反复返工。第三维护成本低。系统演进时你只需要改节点和连线不需要重新设计视觉体系。具体约束我一般这样定矩形代表服务或模块圆角矩形代表外部系统圆柱代表数据存储菱形代表判断或网关虚线代表异步或可选路径实线代表同步调用。颜色上最多用四种主色表示核心链路辅色表示支撑组件灰色表示非重点红色只用于异常或风险标注。这套规则不复杂但足够覆盖百分之九十的技术图场景。2.3 避免什么问题diagram-design 最常见的三个反模式第一个反模式是**“全家福图”**。一张图里塞了二十多个服务、三十多条连线还附带数据库表结构和部署节点。这种图唯一的用途是证明作者很努力但对读者毫无帮助。我的经验是一张图只讲一个故事超过十五个节点就该拆图。第二个反模式是**“箭头无方向”**。很多图里的线没有箭头或者箭头方向随意读者只能靠猜。数据流、控制流、依赖关系、调用关系这些语义必须通过线型和箭头明确区分。我通常要求同步调用用实线箭头异步消息用虚线箭头数据流向用带标签的实线依赖关系用无箭头虚线。第三个反模式是**“图例失踪”**。有些图用了各种颜色和形状但没有任何图例说明。作者自己记得过两周自己都忘了。diagram-design 的硬性要求是只要用了非默认视觉元素就必须在图内或图下方给出图例。图例不是装饰是图的字典。3. 核心细节解析与实操要点3.1 节点设计一个方框里到底该写什么节点是 diagram-design 的最小信息单元。我见过太多方框里写着“服务A”“模块B”“系统C”这种命名等于没命名。一个好的节点标签应该包含三要素角色、职责、边界。比如“订单服务”不如“订单服务创建/查询/取消”“用户中心”不如“用户中心认证/授权/Profile”。如果空间允许我还会在节点下方用更小的字号标注技术栈或部署形态比如“Spring Boot / 3 副本”。这样读者不用问就知道这个节点大概是什么。但要注意节点信息不能过载。一个方框里塞五行字图就会变成文档。我的原则是节点主标签不超过十二个字副标签不超过一行。更多细节放到图外的说明表格里或者用编号引用。注意节点命名要统一语言。要么全中文要么全英文不要中英混排。如果必须保留英文专有名词首次出现时用括号注明中文含义。3.2 连线设计箭头、线型与标签的语义约定连线是 diagram-design 里最容易出错的部分。我的实操要点是每一条线都必须能回答“谁对谁、做什么、什么条件”。同步调用实线 实心箭头标签写“调用”或具体接口名。异步消息虚线 实心箭头标签写“发送事件”或消息主题。数据流向实线 空心箭头标签写数据内容。依赖关系虚线 无箭头标签写“依赖”。条件分支在连线旁标注条件比如“库存充足”“支付成功”。如果两条线交叉尽量用跳线或者调整布局避免歧义。我试过在复杂图里用不同颜色区分不同链路的连线效果很好但前提是颜色数量不超过三种否则读者会眼花。还有一个细节连线的标签位置要统一。我通常放在线的中点上方如果线太短就放在右侧。不要一会儿左一会儿右读者会找不到。3.3 布局设计从左到右、从上到下还是中心辐射布局决定了读者的阅读路径。diagram-design 里我常用的布局有三种。从左到右适合流程和调用链读者视线自然从左向右移动。从上到下适合层级结构和部署架构上层是入口下层是基础设施。中心辐射适合以某个核心组件为中心的生态图但容易显得乱慎用。布局的核心原则是减少交叉线。如果发现连线大量交叉说明布局需要调整而不是加跳线硬撑。我通常会先把节点按依赖关系排成几列再把连线尽量拉直。如果还是交叉就考虑拆图。另外留白很重要。节点之间至少留一个节点宽度的间距图边缘留出图例和标题的空间。拥挤的图会让读者产生压迫感信息吸收率直线下降。3.4 颜色与字体少即是多的视觉纪律颜色在 diagram-design 里只有一个作用区分语义。我一般只用四种颜色蓝色表示核心业务绿色表示数据存储橙色表示外部依赖灰色表示非重点或待定。红色只用于异常路径或风险提示且一张图里红色元素不超过两个。字体方面我坚持用无衬线字体字号不超过三级。图标题最大节点标签次之注释最小。不要用斜体、下划线、艺术字这些都会干扰阅读。加粗只用于强调关键节点且一张图里不超过三个。提示如果你不确定颜色是否合适把图转成灰度看一下。如果灰度下仍然能区分不同元素说明你的设计是稳的。4. 实操过程与核心环节实现4.1 从需求到草图我如何用十分钟完成一张图的骨架接到画图需求后我不会立刻打开工具。我先拿一张白纸或者打开一个纯文本编辑器用列表把关键节点写下来。比如要画一个订单系统我会先写用户、网关、订单服务、库存服务、支付服务、消息队列、订单库、库存库。然后我用箭头把这些节点连起来标上方向。这一步只关心逻辑不关心美观。写完后再读一遍问自己这张图想说明什么如果结论是“下单后库存和支付异步协同”那消息队列就是重点其他节点可以简化。接下来才是打开绘图工具。我通常先用统一大小的方框把所有节点摆上去再调整位置减少交叉最后加连线和标签。整个过程控制在十分钟到二十分钟超过这个时间说明信息层级没想清楚需要回到第一步。4.2 工具选型不同场景下我用什么画 diagram-design工具没有绝对好坏只有适不适合。我按场景分三类。快速沟通用白板或在线白板工具优势是快劣势是不易维护。正式文档用支持代码化绘图的工具比如用文本描述生成图表优势是版本可控、可 diff、可复用。复杂架构用专业绘图工具优势是布局自由、样式丰富劣势是协作时需要统一规范。我个人的主力方案是代码化绘图。原因很简单图可以跟代码一起进版本库改一行文本就能更新图评审时直接看 diff。对于需要频繁迭代的系统设计这比拖拽式工具高效太多。但代码化绘图也有坑。第一布局控制弱复杂图可能需要手动调坐标。第二样式定制麻烦需要花时间调主题。第三学习成本不低新人需要一两天适应。所以我的建议是简单图用代码化复杂图用专业工具临时沟通用白板。4.3 参数与规范落地我如何让团队统一 diagram-design 风格团队统一风格不能靠喊口号要靠可执行的规范。我一般会做三件事。第一写一份一页纸的图表规范包含形状语义、颜色语义、线型语义、字体字号、图例要求。第二提供模板文件新人直接复制模板改内容。第三在代码评审或文档评审里加入图表检查项不符合规范的图打回重画。规范落地最大的阻力是“太麻烦”。我的应对方法是先在小范围试点收集反馈把规范简化到最少必要规则。比如颜色从八种减到四种形状从十种减到五种。规则越少执行率越高。还有一个技巧把规范做成检查清单而不是长篇文档。比如“节点标签是否包含角色和职责”“连线是否有方向和标签”“是否包含图例”“灰度下是否可读”。四条检查项一分钟就能过一遍。4.4 一张完整图的诞生从草图到发布的全记录我拿一个模拟项目举例。需求是画一张“用户下单到订单完成”的链路图。第一步我列出节点用户、API 网关、订单服务、库存服务、支付服务、消息队列、订单库、库存库、支付回调。第二步我确定主叙事用户请求经网关进入订单服务订单服务同步扣减库存、异步发起支付支付回调后更新订单状态。第三步布局。我把用户和网关放最左订单服务居中库存和支付放右侧消息队列放订单服务下方数据库放最右。第四步连线。用户到网关用实线箭头标“下单请求”网关到订单服务用实线箭头标“转发”订单服务到库存服务用实线箭头标“扣减库存”订单服务到消息队列用虚线箭头标“支付事件”消息队列到支付服务用虚线箭头标“消费”支付服务到订单服务用虚线箭头标“回调”。第五步加注释。在库存服务旁标注“乐观锁”在支付服务旁标注“幂等”在消息队列旁标注“至少一次投递”。第六步加图例说明实线、虚线、颜色的含义。第七步灰度检查确认可读。第八步导出 PNG 和源文件源文件进版本库PNG 进文档。整个过程大约四十分钟其中二十分钟花在布局调整上。我的经验是布局值得花时间因为布局决定了图的可读性上限。5. 常见问题与排查技巧实录5.1 图太乱怎么办三个立竿见影的整理手法图太乱通常有三个原因节点太多、连线太杂、注释太密。对应的整理手法是拆图、分层、折叠。拆图把一张大图拆成多张小图每张图讲一个子故事。比如把“整体架构”拆成“接入层”“业务层”“数据层”三张图。分层用不同颜色或区域划分层次比如上层是接入中层是业务下层是存储。折叠把非重点节点合并成一个“其他服务”方框需要时再展开。我试过最有效的一招是“删节点”。把图里所有节点过一遍问“没有它这张图还能讲清楚吗”。如果能就删掉。通常删掉百分之三十的节点后图会清爽很多。5.2 读者看不懂怎么办用“三秒测试”验证图的有效性我有个习惯图画完后找一个没参与项目的同事让他看三秒然后问他“这张图在讲什么”。如果他说不出来说明图失败了。这个“三秒测试”非常残酷但非常有效。如果三秒测试失败通常是因为主叙事不突出。解决办法是把核心链路加粗或放大把非核心元素调灰或缩小把结论写在图标题里。比如标题不写“订单系统架构图”而写“订单系统下单后异步扣库存与支付”。标题本身就是结论读者一眼就能抓住重点。5.3 图更新后没人看怎么办让 diagram-design 跟文档同生命周期图更新后没人看根本原因是图和文档脱节。我的做法是图必须嵌入文档且图源文件跟文档同仓库。文档更新时图必须同步更新否则评审不通过。另外我会在图下方加一行“最后更新日期”和“对应版本”。这样读者知道这张图是不是最新的。如果图有多个版本我会保留历史版本但只把最新版放在文档顶部。还有一个技巧把图的关键结论写成文字放在图上方。这样即使读者不看图也能获取核心信息。图是辅助不是唯一信息载体。5.4 常见问题速查表问题现象可能原因排查思路解决方法图太乱节点过多、连线交叉数节点数量看交叉点拆图、删节点、调整布局读者看不懂主叙事不突出做三秒测试加粗核心链路标题写结论颜色混乱颜色语义不统一检查图例限定四种颜色灰度验证连线歧义线型无约定检查箭头和标签统一线型语义每条线加标签图更新滞后图与文档分离检查版本和日期图源进仓库加更新日期协作返工多规范不统一检查模板和检查项提供模板加评审检查项注意这张表建议打印出来贴在工位上画图前过一遍能省下大量返工时间。6. 进阶技巧让 diagram-design 从“能看”到“好用”6.1 用“图 表”组合承载复杂信息一张图能承载的信息量有限硬塞只会让图变乱。我的进阶做法是“图 表”组合。图负责讲结构和关系表负责讲细节和参数。比如架构图讲服务划分表格讲每个服务的接口、协议、SLA、负责人。这样做的另一个好处是表格可以单独更新不需要重画图。系统演进时接口变了改表格结构变了改图维护成本大幅降低。6.2 用“分层图”替代“一张大图”复杂系统我通常画三张图。第一张是上下文图只画系统边界和外部依赖不超过十个节点。第二张是容器图画系统内部的主要服务或模块以及它们之间的调用关系。第三张是组件图针对某个核心服务展开内部组件。这三张图层层递进读者可以按需深入。上下文图给管理层看容器图给跨团队看组件图给开发看。同一套 diagram-design 规范贯穿三张图认知成本最低。6.3 用“版本化”管理图的演进图不是画完就完了它会随系统演进。我建议把图源文件纳入版本管理每次变更都提交写清楚变更原因。这样你可以回溯任何一张图的历史状态也可以对比不同版本的差异。如果团队用文档平台可以把图源文件和导出图都放上去导出图用于展示源文件用于编辑。每次更新时先改源文件再导出替换。不要直接在导出图上改那样会丢失源文件。6.4 用“评审清单”保证图的质量最后分享一份我常用的图表评审清单画完图后逐条检查图标题是否包含结论节点数量是否超过十五个每个节点标签是否包含角色和职责每条连线是否有方向和标签是否包含图例颜色是否不超过四种灰度下是否可读是否通过三秒测试是否标注了更新日期和版本图源文件是否已入库这十条过一遍图的质量基本就有保障了。我踩过的坑告诉我图的问题从来不是工具问题而是纪律问题。diagram-design 的本质是用约束换清晰用规范换效率。你可以在第一个项目里就建立这套习惯后面会越用越顺。
1. 从一张草图到一套系统diagram-design 到底在解决什么问题第一次看到 “diagram-design” 这个标题很多人会以为它只是教你怎么把图画得好看一点。但真正做过技术方案、写过设计文档、给团队讲过架构的人都知道画图这件事从来不只是“美不美”的问题。一张图能不能把复杂系统讲清楚能不能让产品、研发、测试、运维在同一个语境下对齐认知能不能在三个月后自己回头看还能秒懂这才是 diagram-design 的核心价值。我做了十多年一线项目画过的架构图、流程图、时序图、状态机图、部署图、数据流图加起来没有一千也有八百张。早期我也走过弯路用绘图工具拖一堆方框和箭头颜色花里胡哨结果评审会上大家盯着图看了五分钟问的第一个问题却是“这个箭头到底代表数据流还是控制流”。那一刻我才意识到diagram-design 不是美术工作而是信息设计。它要解决的是“把脑子里的结构无损地搬到别人脑子里”这件事。所以这篇内容适合三类人第一类是需要频繁输出技术方案、系统设计、流程说明的工程师和架构师第二类是需要用图跟非技术角色对齐需求的产品经理和项目负责人第三类是想建立一套可复用、可维护、可协作的图表规范让团队文档不再各画各的。无论你之前是用什么工具画图只要你想让图真正“会说话”diagram-design 这套思路都能直接抄作业。2. 内容整体设计与思路拆解2.1 为什么 diagram-design 要先定“信息层级”而不是先选工具很多人一上来就问用什么工具画图我的回答永远是先别管工具。diagram-design 的第一步是确定信息层级。一张图里哪些是核心实体哪些是支撑组件哪些是外部依赖哪些是可选路径这些如果不先想清楚换什么工具都白搭。我通常把图的信息分成三层。第一层是主叙事层也就是这张图最想让读者记住的三到五个关键节点。第二层是关系层描述这些节点之间怎么连接、方向如何、有没有条件分支。第三层是注释层包括协议、端口、数据格式、异常说明、版本号等细节。主叙事层决定图的骨架关系层决定图的逻辑注释层决定图的可落地性。为什么这个顺序不能反因为一旦你先陷入注释层比如纠结某个接口用 HTTP 还是 gRPC图就会变得又大又碎读者根本抓不住重点。我见过太多架构图密密麻麻写满了技术栈但看完不知道系统到底分几块、谁调用谁。这就是典型的“信息层级塌陷”。提示画图前先用一句话写下这张图的结论比如“用户请求经过网关后由三个服务协同完成”。如果这句话写不出来说明你还没想清楚先别打开绘图工具。2.2 方案选型背后的考量为什么我最终偏向“约束型”图表规范diagram-design 的另一个核心决策是用自由画布还是用约束型规范。自由画布看起来很爽想怎么摆就怎么摆但团队协作时会迅速失控。A 同学用蓝色表示服务B 同学用蓝色表示数据库C 同学用蓝色表示外部系统最后图例都救不回来。我后来坚定选择约束型规范原因有三个。第一认知成本低。当颜色、形状、线型都有固定语义时读者不需要每次重新学习图例看一眼就能进入内容。第二协作效率高。新人加入项目只要给他一份规范他画出来的图就能直接进文档不需要反复返工。第三维护成本低。系统演进时你只需要改节点和连线不需要重新设计视觉体系。具体约束我一般这样定矩形代表服务或模块圆角矩形代表外部系统圆柱代表数据存储菱形代表判断或网关虚线代表异步或可选路径实线代表同步调用。颜色上最多用四种主色表示核心链路辅色表示支撑组件灰色表示非重点红色只用于异常或风险标注。这套规则不复杂但足够覆盖百分之九十的技术图场景。2.3 避免什么问题diagram-design 最常见的三个反模式第一个反模式是**“全家福图”**。一张图里塞了二十多个服务、三十多条连线还附带数据库表结构和部署节点。这种图唯一的用途是证明作者很努力但对读者毫无帮助。我的经验是一张图只讲一个故事超过十五个节点就该拆图。第二个反模式是**“箭头无方向”**。很多图里的线没有箭头或者箭头方向随意读者只能靠猜。数据流、控制流、依赖关系、调用关系这些语义必须通过线型和箭头明确区分。我通常要求同步调用用实线箭头异步消息用虚线箭头数据流向用带标签的实线依赖关系用无箭头虚线。第三个反模式是**“图例失踪”**。有些图用了各种颜色和形状但没有任何图例说明。作者自己记得过两周自己都忘了。diagram-design 的硬性要求是只要用了非默认视觉元素就必须在图内或图下方给出图例。图例不是装饰是图的字典。3. 核心细节解析与实操要点3.1 节点设计一个方框里到底该写什么节点是 diagram-design 的最小信息单元。我见过太多方框里写着“服务A”“模块B”“系统C”这种命名等于没命名。一个好的节点标签应该包含三要素角色、职责、边界。比如“订单服务”不如“订单服务创建/查询/取消”“用户中心”不如“用户中心认证/授权/Profile”。如果空间允许我还会在节点下方用更小的字号标注技术栈或部署形态比如“Spring Boot / 3 副本”。这样读者不用问就知道这个节点大概是什么。但要注意节点信息不能过载。一个方框里塞五行字图就会变成文档。我的原则是节点主标签不超过十二个字副标签不超过一行。更多细节放到图外的说明表格里或者用编号引用。注意节点命名要统一语言。要么全中文要么全英文不要中英混排。如果必须保留英文专有名词首次出现时用括号注明中文含义。3.2 连线设计箭头、线型与标签的语义约定连线是 diagram-design 里最容易出错的部分。我的实操要点是每一条线都必须能回答“谁对谁、做什么、什么条件”。同步调用实线 实心箭头标签写“调用”或具体接口名。异步消息虚线 实心箭头标签写“发送事件”或消息主题。数据流向实线 空心箭头标签写数据内容。依赖关系虚线 无箭头标签写“依赖”。条件分支在连线旁标注条件比如“库存充足”“支付成功”。如果两条线交叉尽量用跳线或者调整布局避免歧义。我试过在复杂图里用不同颜色区分不同链路的连线效果很好但前提是颜色数量不超过三种否则读者会眼花。还有一个细节连线的标签位置要统一。我通常放在线的中点上方如果线太短就放在右侧。不要一会儿左一会儿右读者会找不到。3.3 布局设计从左到右、从上到下还是中心辐射布局决定了读者的阅读路径。diagram-design 里我常用的布局有三种。从左到右适合流程和调用链读者视线自然从左向右移动。从上到下适合层级结构和部署架构上层是入口下层是基础设施。中心辐射适合以某个核心组件为中心的生态图但容易显得乱慎用。布局的核心原则是减少交叉线。如果发现连线大量交叉说明布局需要调整而不是加跳线硬撑。我通常会先把节点按依赖关系排成几列再把连线尽量拉直。如果还是交叉就考虑拆图。另外留白很重要。节点之间至少留一个节点宽度的间距图边缘留出图例和标题的空间。拥挤的图会让读者产生压迫感信息吸收率直线下降。3.4 颜色与字体少即是多的视觉纪律颜色在 diagram-design 里只有一个作用区分语义。我一般只用四种颜色蓝色表示核心业务绿色表示数据存储橙色表示外部依赖灰色表示非重点或待定。红色只用于异常路径或风险提示且一张图里红色元素不超过两个。字体方面我坚持用无衬线字体字号不超过三级。图标题最大节点标签次之注释最小。不要用斜体、下划线、艺术字这些都会干扰阅读。加粗只用于强调关键节点且一张图里不超过三个。提示如果你不确定颜色是否合适把图转成灰度看一下。如果灰度下仍然能区分不同元素说明你的设计是稳的。4. 实操过程与核心环节实现4.1 从需求到草图我如何用十分钟完成一张图的骨架接到画图需求后我不会立刻打开工具。我先拿一张白纸或者打开一个纯文本编辑器用列表把关键节点写下来。比如要画一个订单系统我会先写用户、网关、订单服务、库存服务、支付服务、消息队列、订单库、库存库。然后我用箭头把这些节点连起来标上方向。这一步只关心逻辑不关心美观。写完后再读一遍问自己这张图想说明什么如果结论是“下单后库存和支付异步协同”那消息队列就是重点其他节点可以简化。接下来才是打开绘图工具。我通常先用统一大小的方框把所有节点摆上去再调整位置减少交叉最后加连线和标签。整个过程控制在十分钟到二十分钟超过这个时间说明信息层级没想清楚需要回到第一步。4.2 工具选型不同场景下我用什么画 diagram-design工具没有绝对好坏只有适不适合。我按场景分三类。快速沟通用白板或在线白板工具优势是快劣势是不易维护。正式文档用支持代码化绘图的工具比如用文本描述生成图表优势是版本可控、可 diff、可复用。复杂架构用专业绘图工具优势是布局自由、样式丰富劣势是协作时需要统一规范。我个人的主力方案是代码化绘图。原因很简单图可以跟代码一起进版本库改一行文本就能更新图评审时直接看 diff。对于需要频繁迭代的系统设计这比拖拽式工具高效太多。但代码化绘图也有坑。第一布局控制弱复杂图可能需要手动调坐标。第二样式定制麻烦需要花时间调主题。第三学习成本不低新人需要一两天适应。所以我的建议是简单图用代码化复杂图用专业工具临时沟通用白板。4.3 参数与规范落地我如何让团队统一 diagram-design 风格团队统一风格不能靠喊口号要靠可执行的规范。我一般会做三件事。第一写一份一页纸的图表规范包含形状语义、颜色语义、线型语义、字体字号、图例要求。第二提供模板文件新人直接复制模板改内容。第三在代码评审或文档评审里加入图表检查项不符合规范的图打回重画。规范落地最大的阻力是“太麻烦”。我的应对方法是先在小范围试点收集反馈把规范简化到最少必要规则。比如颜色从八种减到四种形状从十种减到五种。规则越少执行率越高。还有一个技巧把规范做成检查清单而不是长篇文档。比如“节点标签是否包含角色和职责”“连线是否有方向和标签”“是否包含图例”“灰度下是否可读”。四条检查项一分钟就能过一遍。4.4 一张完整图的诞生从草图到发布的全记录我拿一个模拟项目举例。需求是画一张“用户下单到订单完成”的链路图。第一步我列出节点用户、API 网关、订单服务、库存服务、支付服务、消息队列、订单库、库存库、支付回调。第二步我确定主叙事用户请求经网关进入订单服务订单服务同步扣减库存、异步发起支付支付回调后更新订单状态。第三步布局。我把用户和网关放最左订单服务居中库存和支付放右侧消息队列放订单服务下方数据库放最右。第四步连线。用户到网关用实线箭头标“下单请求”网关到订单服务用实线箭头标“转发”订单服务到库存服务用实线箭头标“扣减库存”订单服务到消息队列用虚线箭头标“支付事件”消息队列到支付服务用虚线箭头标“消费”支付服务到订单服务用虚线箭头标“回调”。第五步加注释。在库存服务旁标注“乐观锁”在支付服务旁标注“幂等”在消息队列旁标注“至少一次投递”。第六步加图例说明实线、虚线、颜色的含义。第七步灰度检查确认可读。第八步导出 PNG 和源文件源文件进版本库PNG 进文档。整个过程大约四十分钟其中二十分钟花在布局调整上。我的经验是布局值得花时间因为布局决定了图的可读性上限。5. 常见问题与排查技巧实录5.1 图太乱怎么办三个立竿见影的整理手法图太乱通常有三个原因节点太多、连线太杂、注释太密。对应的整理手法是拆图、分层、折叠。拆图把一张大图拆成多张小图每张图讲一个子故事。比如把“整体架构”拆成“接入层”“业务层”“数据层”三张图。分层用不同颜色或区域划分层次比如上层是接入中层是业务下层是存储。折叠把非重点节点合并成一个“其他服务”方框需要时再展开。我试过最有效的一招是“删节点”。把图里所有节点过一遍问“没有它这张图还能讲清楚吗”。如果能就删掉。通常删掉百分之三十的节点后图会清爽很多。5.2 读者看不懂怎么办用“三秒测试”验证图的有效性我有个习惯图画完后找一个没参与项目的同事让他看三秒然后问他“这张图在讲什么”。如果他说不出来说明图失败了。这个“三秒测试”非常残酷但非常有效。如果三秒测试失败通常是因为主叙事不突出。解决办法是把核心链路加粗或放大把非核心元素调灰或缩小把结论写在图标题里。比如标题不写“订单系统架构图”而写“订单系统下单后异步扣库存与支付”。标题本身就是结论读者一眼就能抓住重点。5.3 图更新后没人看怎么办让 diagram-design 跟文档同生命周期图更新后没人看根本原因是图和文档脱节。我的做法是图必须嵌入文档且图源文件跟文档同仓库。文档更新时图必须同步更新否则评审不通过。另外我会在图下方加一行“最后更新日期”和“对应版本”。这样读者知道这张图是不是最新的。如果图有多个版本我会保留历史版本但只把最新版放在文档顶部。还有一个技巧把图的关键结论写成文字放在图上方。这样即使读者不看图也能获取核心信息。图是辅助不是唯一信息载体。5.4 常见问题速查表问题现象可能原因排查思路解决方法图太乱节点过多、连线交叉数节点数量看交叉点拆图、删节点、调整布局读者看不懂主叙事不突出做三秒测试加粗核心链路标题写结论颜色混乱颜色语义不统一检查图例限定四种颜色灰度验证连线歧义线型无约定检查箭头和标签统一线型语义每条线加标签图更新滞后图与文档分离检查版本和日期图源进仓库加更新日期协作返工多规范不统一检查模板和检查项提供模板加评审检查项注意这张表建议打印出来贴在工位上画图前过一遍能省下大量返工时间。6. 进阶技巧让 diagram-design 从“能看”到“好用”6.1 用“图 表”组合承载复杂信息一张图能承载的信息量有限硬塞只会让图变乱。我的进阶做法是“图 表”组合。图负责讲结构和关系表负责讲细节和参数。比如架构图讲服务划分表格讲每个服务的接口、协议、SLA、负责人。这样做的另一个好处是表格可以单独更新不需要重画图。系统演进时接口变了改表格结构变了改图维护成本大幅降低。6.2 用“分层图”替代“一张大图”复杂系统我通常画三张图。第一张是上下文图只画系统边界和外部依赖不超过十个节点。第二张是容器图画系统内部的主要服务或模块以及它们之间的调用关系。第三张是组件图针对某个核心服务展开内部组件。这三张图层层递进读者可以按需深入。上下文图给管理层看容器图给跨团队看组件图给开发看。同一套 diagram-design 规范贯穿三张图认知成本最低。6.3 用“版本化”管理图的演进图不是画完就完了它会随系统演进。我建议把图源文件纳入版本管理每次变更都提交写清楚变更原因。这样你可以回溯任何一张图的历史状态也可以对比不同版本的差异。如果团队用文档平台可以把图源文件和导出图都放上去导出图用于展示源文件用于编辑。每次更新时先改源文件再导出替换。不要直接在导出图上改那样会丢失源文件。6.4 用“评审清单”保证图的质量最后分享一份我常用的图表评审清单画完图后逐条检查图标题是否包含结论节点数量是否超过十五个每个节点标签是否包含角色和职责每条连线是否有方向和标签是否包含图例颜色是否不超过四种灰度下是否可读是否通过三秒测试是否标注了更新日期和版本图源文件是否已入库这十条过一遍图的质量基本就有保障了。我踩过的坑告诉我图的问题从来不是工具问题而是纪律问题。diagram-design 的本质是用约束换清晰用规范换效率。你可以在第一个项目里就建立这套习惯后面会越用越顺。
![[deprecated]第四章：TTM分析: 4.2.1 存储分配ttm_bo_validate功能实现分析](http://pic.xiahunao.cn/yaotu/[deprecated]第四章：TTM分析: 4.2.1 存储分配ttm_bo_validate功能实现分析)
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
