1. 从一张草图到一套系统diagram-design 到底在解决什么问题第一次看到 “diagram-design” 这个标题很多人会以为它只是教你怎么把图画得好看一点。但真正做过系统设计、写过技术方案、给团队讲过架构的人都知道图的问题从来不只是“好不好看”。一张图背后藏着的是信息层级、阅读路径、认知负担和协作效率。图画得乱评审时就要花二十分钟解释“这个箭头到底从哪来”图画得清楚五分钟就能让所有人对齐关键决策。diagram-design 这个项目核心就是围绕“图的设计”建立一套可复用的方法论和工具链。它要解决的不是单一软件怎么用而是从需求梳理、结构抽象、视觉编码到最终交付的完整链路。说得直白一点它关心的是怎么让一张图在最短时间内把最复杂的信息讲明白并且让不同角色的人都能看懂、能改、能维护。这个主题适合谁如果你是技术方案撰写者、产品经理、系统架构师、技术博主或者任何需要频繁用图表达复杂逻辑的人这套内容都能直接拿去用。它不要求你会画画也不要求你精通设计软件它要求的是你愿意把“画图”当成一项工程来做而不是随手拖几个框就完事。我见过太多团队在 diagram-design 上踩坑有人用彩色渐变把架构图做成了海报结果打印出来全是灰块有人把所有信息塞进一张图最后谁也不敢改还有人每次评审都重新画一遍因为上一版的源文件已经找不到了。这些问题看起来是工具问题实际上是设计思路和流程规范的问题。接下来我会从整体设计思路、核心细节、实操流程和常见问题四个维度把 diagram-design 这件事拆开讲透。2. 内容整体设计与思路拆解2.1 为什么 diagram-design 要先定“信息层级”再定“视觉风格”很多人做图的第一步是打开工具选一个模板然后开始拖框。这个顺序在 diagram-design 里是反的。正确的顺序是先确定这张图要回答什么问题再确定信息层级最后才考虑视觉风格。我举个实际场景。假设你要画一张系统架构图评审对象是技术负责人和运维团队。技术负责人关心的是模块边界和依赖关系运维团队关心的是部署单元和网络分区。如果你把这两类信息混在同一层级里图就会变得又大又乱。正确的做法是先画一张逻辑架构图只保留模块和依赖再画一张部署架构图只保留节点和网络。两张图各自回答一个问题而不是一张图回答所有问题。这个思路背后的逻辑是认知负荷理论。人的工作记忆一次只能处理四到七个信息块。一张图如果同时呈现模块、协议、端口、部署区域、数据流向、安全边界读者的工作记忆会瞬间过载结果就是“看了半天不知道重点在哪”。diagram-design 的核心原则之一就是一张图只讲一件事其他信息用分层或链接的方式延展。那怎么判断信息层级是否合理我常用的方法是“三秒测试”把图给一个没参与项目的同事看三秒然后问他“这张图在讲什么”。如果他说不出来说明信息层级有问题。这个测试听起来很粗糙但实测下来非常有效尤其是在评审前自查的时候。2.2 工具选型为什么我不推荐一上来就用重型设计软件diagram-design 的工具选型有一个基本原则图的维护成本必须低于它的沟通收益。如果一张图改一次要花半小时那它很快就会被抛弃。所以我在工具选型上通常分三档。第一档是文本驱动型工具比如用代码描述图结构的方案。这类工具的优势是版本可控、diff 清晰、适合多人协作。缺点是学习曲线陡调整布局不够直观。第二档是轻量级绘图工具适合快速出草图、做评审稿。第三档才是重型设计软件适合最终交付物需要极高视觉精度的场景比如对外宣传材料或印刷品。我自己的习惯是内部评审一律用文本驱动或轻量级工具因为评审阶段图会频繁改动重工具反而拖慢节奏。只有最终定稿需要对外展示时才会花时间做视觉精修。这个策略帮我省下了大量重复劳动。这里有一个容易被忽略的点工具选型要考虑“谁需要改这张图”。如果图只有你一个人维护那选你顺手的就行。但如果图需要产品、开发、测试多方共同维护那就要选一个大家都能上手的工具哪怕它看起来不够高级。我见过一个团队用了一款非常专业的绘图软件结果只有一个人会用其他人提修改意见只能截图加批注最后图更新滞后了两个月直接失去了参考价值。2.3 视觉编码颜色、形状、线条到底该怎么用diagram-design 里最容易被滥用的就是颜色。很多人觉得颜色越多越专业实际上颜色是最稀缺的视觉资源。我的原则是一张图的主色不超过三种每种颜色必须对应一个明确的语义。比如在架构图里蓝色代表计算服务绿色代表数据存储灰色代表外部依赖。这个映射关系一旦确定整张图甚至整个项目文档里都要保持一致。这样读者看第二张图的时候不需要重新学习颜色含义认知负担会大幅降低。形状也是同理。矩形代表服务圆柱代表数据库菱形代表决策点圆角矩形代表外部系统。这些约定不需要多新奇关键是稳定。我见过有人为了“好看”把数据库画成六边形结果读者第一眼根本没认出来那是什么。线条的用法更讲究。实线代表同步调用虚线代表异步消息粗线代表主链路细线代表辅助链路。如果一张图里所有线条都一样粗、一样实那读者就无法判断哪些是核心路径。我的经验是主链路最多三条超过三条就说明这张图该拆了。注意颜色和形状的语义映射一旦确定就要写进团队的设计规范文档里。否则每个人按自己的习惯画图与图之间就无法对齐。2.4 从“画图”到“设计图”思维模式的转变diagram-design 最核心的转变是把“画图”当成一次性任务变成“设计图”当成一套可迭代的系统。画图是一次性的画完就完了设计图是有生命周期的需要版本管理、需要评审记录、需要和代码或文档保持同步。这个转变带来的第一个变化是你会开始给图写“元信息”。比如这张图的作者是谁、最后更新是什么时候、对应的需求文档链接在哪里、下一版计划改什么。这些信息看起来琐碎但在团队协作里能救命。我曾经遇到过一次线上故障复盘需要确认三个月前的架构图是否准确结果发现图没有版本记录谁也不知道当时改了什么最后只能靠翻聊天记录拼凑。第二个变化是你会开始考虑图的“可修改性”。一张图如果只有原作者能改那它就是死图。好的 diagram-design 应该让任何一个了解背景的人都能在十分钟内完成一次小修改。这就要求图层命名清晰、分组合理、样式统一而不是把所有元素堆在一个图层里靠肉眼找。3. 核心细节解析与实操要点3.1 信息抽象怎么从一堆需求里提炼出图的结构做 diagram-design 最难的从来不是画而是决定画什么。我常用的方法是“三步抽象法”。第一步是列实体。把系统里所有名词列出来比如用户、订单、支付服务、库存服务、消息队列、数据库。这一步不设限制想到什么列什么。第二步是定关系。把实体之间的动词找出来比如“用户提交订单”“订单调用支付服务”“支付成功后发送消息”。这一步的关键是只保留核心关系辅助关系先放一边。第三步是分层级。把实体按重要性分成核心层、支撑层和外部层。核心层是这张图的主角支撑层是配角外部层是背景。分层之后图的结构自然就出来了。这个方法听起来简单但实操时最容易犯的错误是“舍不得删”。很多人觉得每个细节都重要结果图越画越大。我的经验是第一版图只保留核心层和直接相关的支撑层外部层用文字说明代替。如果评审时有人问“为什么没有画某某模块”再决定是否加进去。这样能保证图始终聚焦在核心问题上。3.2 布局算法为什么手动排版永远比自动布局更可靠现在很多绘图工具都提供自动布局功能一键就能把图排得整整齐齐。但我在 diagram-design 里几乎不用自动布局原因很简单自动布局优化的是“不重叠”而不是“好阅读”。自动布局的算法通常基于力导向或层次布局它会把节点均匀分布减少连线交叉。但人的阅读习惯是从左到右、从上到下而且对对称和分组有天然偏好。自动布局出来的图往往看起来“均匀但无重点”读者需要花额外时间找入口。我的做法是先用自动布局生成一个基础版本然后手动调整。调整的重点有三个。第一把核心节点放在视觉中心或左上角因为这是读者第一眼会看的位置。第二把相关节点聚成组用背景框或留白区分而不是靠连线区分。第三把主链路拉直减少不必要的转折让读者的视线能顺着主链路自然流动。手动排版确实更费时间但一张核心架构图的生命周期通常是几个月甚至几年多花半小时排版换来的是几百次阅读的顺畅这笔账怎么算都划算。3.3 文字标注图上的字到底该写多少diagram-design 里有一个经典矛盾字写少了看不懂字写多了图就变成文档。我的原则是图上只写“标识性文字”解释性文字放到图外。标识性文字包括节点名称、关键参数、版本号。比如“订单服务 v2.3”“超时时间 3s”“QPS 上限 5000”。这些文字是读者理解图结构的必要信息必须写在图上。解释性文字包括设计理由、历史背景、替代方案。比如“为什么选择消息队列而不是直接调用”“这个模块上一版有什么问题”。这些内容应该放在图下方的说明区或者链接到独立文档。如果硬塞进图里图会变得极其臃肿而且每次修改都要调整文字框大小维护成本极高。我自己的习惯是图上的文字不超过两行每行不超过十五个字。超过这个限制就说明这个信息应该被拆出去。这个规则听起来很死板但执行下来效果很好尤其是当图需要在手机或投影仪上展示时小字根本看不清。3.4 版本管理图也需要像代码一样管理diagram-design 的版本管理经常被忽略但它直接决定了图能不能长期使用。我的做法是每张正式发布的图都对应一个版本号版本号写在图的右下角。同时维护一个变更记录表记录每次修改的内容、原因和负责人。变更记录表不需要很复杂一个简单的表格就够了。比如版本日期修改内容修改人原因v1.02024-03-01初版发布某开发者架构评审v1.12024-03-15增加缓存层某开发者性能优化v1.22024-04-02调整支付链路A同学支付服务拆分这个表格看起来简单但在实际项目里能解决大问题。比如新人入职时可以通过变更记录快速了解系统演进过程比如故障复盘时可以确认当时的架构状态比如评审时可以避免重复讨论已经改过的方案。提示如果图是用文本驱动工具生成的版本管理可以直接复用代码仓库的提交记录不需要额外维护表格。这也是我推荐文本驱动工具的原因之一。4. 实操过程与核心环节实现4.1 从零开始画一张系统架构图的完整流程假设现在要为一个模拟项目画一张系统架构图项目是一个跨平台的订单处理系统。我会按以下步骤操作。第一步明确图的用途和读者。这张图是给技术评审用的读者是开发团队和运维团队。所以图需要包含模块划分、依赖关系、部署单元和关键中间件。第二步列出所有实体。用户端、API 网关、订单服务、支付服务、库存服务、消息队列、订单数据库、缓存、日志服务、监控服务。一共十个实体。第三步确定核心链路。用户端到 API 网关到订单服务到支付服务和库存服务支付成功后通过消息队列通知其他服务。这条链路是图的主线。第四步分层布局。把 API 网关放在最左侧订单服务放在中心支付服务和库存服务放在订单服务右侧消息队列放在下方数据库和缓存放在订单服务下方日志和监控放在最底部作为支撑层。第五步添加视觉编码。订单服务用蓝色矩形数据库用蓝色圆柱消息队列用绿色圆角矩形外部依赖用灰色。主链路用粗实线异步消息用虚线。第六步标注关键信息。在 API 网关上标注“限流 1000 QPS”在订单服务上标注“v2.3”在消息队列上标注“Kafka 3.0”在数据库上标注“MySQL 8.0 主从”。第七步自查和评审。用三秒测试确认图的核心信息是否清晰然后发给团队评审。这个流程走下来一张图的初稿大概需要四十分钟到一个小时。其中布局和视觉编码占的时间最多但这两步也是最值得花时间的。4.2 参数计算怎么确定图上的关键数值diagram-design 里经常需要在图上标注关键参数比如 QPS、超时时间、容量上限。这些数值不能随便写需要有计算依据。以 QPS 为例。假设订单系统日均订单量是 100 万流量集中在早八点到晚十点共 14 个小时。平均 QPS 是 1000000 除以 14 除以 3600约等于 20。但峰值 QPS 通常是平均值的五到十倍所以峰值 QPS 大约在 100 到 200 之间。考虑到未来半年的业务增长按两倍冗余设计图上标注的限流阈值可以设为 500 QPS。这个计算过程不需要写在图上但你自己心里要有数。因为评审时一定会有人问“为什么是 500 而不是 1000”如果你能当场说出计算逻辑评审效率会高很多。超时时间的计算也是同理。比如订单服务调用支付服务支付服务的 P99 响应时间是 800 毫秒那么订单服务的超时时间至少应该设为 1.5 秒到 2 秒留出网络抖动和重试的余量。如果设成 500 毫秒那大量正常请求都会被误判为超时。注意图上的参数是给读者看的不是给自己看的。所以只标注对理解系统行为有影响的参数不要把所有配置都堆上去。4.3 实操现场一次架构图评审的完整记录我记录过一次典型的架构图评审过程这里分享出来供参考。评审开始我先用两分钟介绍图的背景和阅读方式。然后进入提问环节。第一个问题是“为什么订单服务和库存服务之间没有直接调用而是通过消息队列”。我解释说订单创建和库存扣减需要解耦避免库存服务故障导致订单无法创建。消息队列在这里起到缓冲和异步的作用。第二个问题是“缓存和数据库的一致性怎么保证”。我在图上补充了一个标注说明缓存采用先更新数据库再删除缓存的策略并且设置了短暂的过期时间作为兜底。第三个问题是“日志服务和监控服务为什么放在最底部”。我解释说它们是支撑层不参与核心业务链路放在底部是为了避免干扰主链路的阅读。整个评审持续了四十分钟图修改了三个地方。修改后的版本号从 v1.0 升到 v1.1变更记录同步更新。这个过程看起来很繁琐但正是这些细节让图真正成为团队共识的载体而不是某个人电脑里的一个文件。4.4 从架构图到流程图不同图类型的实操差异diagram-design 不只包括架构图还包括流程图、时序图、状态图、部署图等。不同类型的图实操要点差异很大。流程图的重点是分支和异常。很多人画流程图只画正常路径异常路径全部省略。结果开发时遇到异常情况才发现没有定义。我的做法是正常路径用主色异常路径用灰色虚线并且每个异常路径都要标注处理方式。时序图的重点是顺序和并发。时序图最容易犯的错误是把所有调用都画成串行忽略了可以并行的部分。我的做法是用不同的垂直泳道区分服务并行的调用画在同一水平线上让读者一眼就能看出哪些步骤可以同时进行。状态图的重点是边界和转换条件。状态图最容易漏掉的是异常状态和超时状态。我的做法是先把所有正常状态列出来再逐个问“如果在这个状态超时了会怎样”“如果在这个状态收到非法请求会怎样”把异常状态补全。部署图的重点是网络分区和节点规格。部署图不需要画得太细但网络分区和节点数量必须准确。我的做法是用背景框区分不同的网络区域每个节点标注实例数量和规格比如“订单服务 4 核 8G 乘以 3 实例”。5. 常见问题与排查技巧实录5.1 图太乱看不清从信息过载到分层拆解图太乱是 diagram-design 里最常见的问题。症状是一张图里有几十个节点、上百条连线读者看了三分钟还不知道重点在哪。排查思路分三步。第一步数节点。如果节点超过十五个基本可以确定需要拆图。第二步数连线。如果连线超过节点数的两倍说明关系太复杂需要抽象。第三步找主线。如果找不到一条清晰的主链路说明图的结构有问题。解决方法通常是分层拆解。把一张大图拆成三张小图一张总览图只画核心模块和主链路一张详细图画某个核心模块的内部结构一张部署图画物理部署和网络分区。三张小图各自回答一个问题通过链接互相引用。我自己的经验是总览图的节点控制在七个以内详细图的节点控制在十二个以内超过这个数量就继续拆。这个数字不是绝对的但可以作为参考。5.2 图改不动源文件管理和协作规范图改不动的原因通常有两个源文件丢失或源文件只有一个人能改。源文件丢失的预防方法是所有正式发布的图都必须保留源文件并且源文件要和项目文档放在同一个仓库里。如果图是用文本驱动工具生成的源文件就是代码文件天然跟着代码仓库走。如果图是用绘图工具生成的源文件要导出为可编辑格式不要只保留图片。源文件只有一个人能改的预防方法是制定协作规范包括图层命名规则、样式统一规则、分组规则。比如所有节点必须放在名为“nodes”的图层组里所有连线必须放在名为“edges”的图层组里所有文字标注必须使用统一的字体和字号。这些规则看起来琐碎但能大幅降低协作成本。提示如果团队里只有一个人会用某个工具那这个工具就不适合作为团队的标准工具。工具的选择权应该交给最需要改图的人而不是最会画图的人。5.3 图与代码不一致同步机制和检查清单图与代码不一致是技术文档的经典问题。架构图里画了缓存层代码里其实已经去掉了时序图里画了三个服务调用代码里已经合并成两个了。这种不一致会让图失去信任最终没人再看。解决方法是建立同步机制。我的做法是每次代码合并请求涉及架构变更时必须同时更新对应的图。这个规则写进团队的开发规范里并且在合并请求模板里加一个检查项“本次变更是否影响架构图如果是请附上更新后的图链接。”另外每个季度做一次图的全量审查。把所有正式发布的图过一遍对照当前代码和部署状态确认是否一致。不一致的地方要么更新图要么标注“已废弃”。这个审查不需要很频繁但必须有否则图会慢慢腐烂。5.4 常见问题速查表问题现象可能原因排查方法解决建议图太乱看不清节点过多、连线过密数节点和连线数量拆成总览图和详细图图改不动源文件丢失或工具不通用检查源文件是否存在、是否可编辑统一工具、制定协作规范图与代码不一致缺少同步机制对比图和当前代码建立合并请求检查项、季度审查评审时解释不清信息层级混乱做三秒测试重新梳理信息层级图打印出来看不清颜色对比度不足、字号太小打印测试提高对比度、放大字号图在手机上看不清图太宽或太密手机预览拆图或调整布局5.5 独家避坑技巧我踩过的那些坑第一个坑是“过度设计”。刚开始做 diagram-design 的时候我喜欢把图做得非常精美加阴影、加渐变、加图标。结果每次修改都要花大量时间调整样式而且打印出来效果很差。后来我学乖了内部评审图一律用最朴素的样式黑白灰加一个主色把精力放在信息结构上。第二个坑是“忽略读者”。我曾经画过一张自认为很清晰的图结果评审时有人问“这个箭头是什么意思”。我才发现我用的箭头样式在团队里没有约定每个人理解都不一样。从那以后我每次画图都会在图的角落加一个图例说明颜色、形状和线条的含义。第三个坑是“不写变更记录”。有一次故障复盘需要确认三个月前的架构状态结果发现图改了但没记录谁也不知道当时是什么样。从那以后我强制自己每次改图都更新变更记录哪怕只是改了一个字。第四个坑是“用图代替文档”。我曾经试图把所有的设计细节都塞进一张图里结果图变得巨大无比没人看得下去。后来我明白图的作用是建立整体认知细节应该交给文档。图和文档是互补关系不是替代关系。6. 不同场景下的 diagram-design 实践差异6.1 技术方案评审场景图和文档怎么配合技术方案评审是 diagram-design 最常用的场景。这个场景的特点是读者专业、时间有限、需要快速对齐关键决策。我的做法是评审材料由三部分组成。第一部分是一张总览图放在最前面让读者在三十秒内建立整体认知。第二部分是若干张详细图每张图对应一个关键设计点比如数据模型、接口设计、部署方案。第三部分是文字说明补充图里放不下的背景信息和替代方案对比。图和文档的配合原则是图负责“是什么”文档负责“为什么”。图让读者快速看到结构文档让读者理解设计理由。如果图里塞了太多“为什么”图会变得臃肿如果文档里没有图读者需要花大量时间在脑中构建结构。注意评审图不要追求完美。评审的目的是发现问题不是展示设计能力。图越早拿出来越容易改。6.2 新人入职培训场景怎么用图降低理解成本新人入职时最痛苦的事情是面对一堆文档不知道从哪看起。diagram-design 在这个场景下能发挥巨大作用。我的做法是为新入职的同事准备一套“学习路径图”。第一张是系统总览图标注核心模块和主链路。第二张是模块依赖图标注每个模块的上下游关系。第三张是部署图标注环境划分和发布流程。三张图配合一份简短的文字说明新人可以在半天内建立对系统的整体认知。这个场景下的图有一个特殊要求必须标注“阅读顺序”。比如在图上用数字标注 1、2、3告诉读者先看哪里再看哪里。这个细节看起来很小但对新人非常友好。6.3 故障复盘场景怎么用图还原时间线故障复盘是 diagram-design 的另一个重要场景。这个场景的特点是需要精确还原时间线、需要标注关键决策点、需要区分事实和推测。我的做法是用一张时序图还原故障过程。横轴是时间纵轴是服务。每个关键事件标注时间戳和现象比如“10:03 订单服务响应时间上升”“10:05 监控告警触发”“10:08 运维介入排查”。关键决策点用不同颜色标注比如“10:10 决定回滚”“10:15 决定扩容”。这个场景下的图有一个特殊要求必须区分事实和推测。事实用实线推测用虚线。比如“订单服务响应时间上升”是监控数据用实线“可能是数据库连接池耗尽”是推测用虚线。这样复盘时大家能清楚知道哪些是确定的哪些还需要验证。6.4 对外分享场景怎么让图在脱离上下文后依然可读对外分享场景包括技术博客、会议演讲、公开文档。这个场景的特点是读者没有项目背景图需要独立可读。我的做法是对外分享的图必须包含“自解释元素”。包括标题、图例、关键参数标注、版本信息。标题要说明这张图讲什么图例要说明颜色和形状的含义关键参数要标注数值和单位版本信息要标注更新日期。另外对外分享的图要控制信息密度。内部评审图可以复杂一些因为读者有背景知识。对外分享图要更简洁因为读者需要从零开始理解。我的经验是对外分享图的节点数量控制在十个以内连线数量控制在十五条以内。7. 工具链与自动化让 diagram-design 可持续7.1 文本驱动工具的核心优势文本驱动工具是 diagram-design 里最值得投入的方向。它的核心优势是图的结构用文本描述文本可以版本控制、可以 diff、可以代码审查。我自己的实践是用文本描述图的结构然后用工具生成图片。这样每次修改只需要改几行文本生成的图片自动更新。更重要的是文本可以放在代码仓库里和代码一起做合并请求审查。架构变更时代码和图在同一个合并请求里审查天然保证一致性。文本驱动工具的缺点是布局控制不够精细。但我的经验是内部评审图对布局精度的要求并不高清晰比精美更重要。只有对外分享图才需要精细调整布局这时候可以导出文本生成的图再用绘图工具做视觉精修。7.2 自动化检查怎么保证图的质量diagram-design 的自动化检查包括三个层面。第一个层面是语法检查。如果图是用文本描述的可以在合并请求里加一个检查步骤确认文本语法正确、能正常生成图片。这个检查可以防止因为语法错误导致图无法生成。第二个层面是一致性检查。比如检查图里的服务名称是否和代码仓库里的服务列表一致检查图里的版本号是否和最新发布版本一致。这个检查需要一些定制脚本但能有效防止图与代码不一致。第三个层面是视觉检查。比如检查图里是否有重叠的节点、是否有超出画布的连线、是否有字号过小的文字。这个检查比较难自动化但可以用一些简单的规则做初步筛查。提示自动化检查不需要一步到位。先从最简单的语法检查开始跑通之后再逐步增加检查项。7.3 模板化怎么让不同的人画出风格一致的图模板化是保证 diagram-design 一致性的关键。我的做法是为每种图类型准备一个模板模板里预定义好颜色、形状、字体、图例位置、版本号位置。比如架构图模板里预定义蓝色矩形代表服务、蓝色圆柱代表数据库、绿色圆角矩形代表消息队列、灰色矩形代表外部依赖。模板里还预定义好图例的位置和格式以及版本号的位置和格式。模板化的好处是任何人用模板画图出来的风格都是一致的。评审时不需要花时间适应不同的视觉风格可以直接关注内容。新人入职时也不需要学习复杂的样式规则直接用模板就行。模板的维护也很重要。每次发现新的通用需求比如需要增加一种新的节点类型就更新模板。模板更新后新画的图自动使用新模板旧图可以按需迁移。8. 我个人的实操体会diagram-design 这件事我做了很多年踩过的坑比画过的图还多。最大的体会是图的质量不取决于你用了多好的工具而取决于你有没有想清楚这张图要回答什么问题。想清楚了用最简单的工具也能画出清晰的图想不清楚用再高级的工具也是白搭。另一个体会是图是需要维护的。很多人把图画完就扔在那里觉得任务完成了。但实际上图的生命周期才刚刚开始。一张没有人维护的图三个月后就会变成误导人的信息。所以我现在画图一定会同时考虑“这张图以后谁来改”“改了之后怎么同步”。如果这两个问题没有答案我宁可不画。最后一个体会是图不是越多越好。我见过一些团队每个模块都画图结果图的总数超过一百张没人知道哪张是最新的。我的做法是只画核心图辅助信息用文字说明。核心图控制在十张以内每张图都有明确的负责人和更新机制。这样图才能真正成为团队的知识资产而不是信息垃圾。如果你刚开始做 diagram-design我的建议是从一张图开始。选一个你最熟悉的系统按上面的流程画一张架构图然后用三秒测试检验一下。如果三秒测试通过说明你已经入门了。如果不通过就继续调整信息层级直到通过为止。这个过程可能需要反复几次但每一次调整都会让你对“什么是清晰的图”有更深的理解。