架构图的核心不是画，而是设计：信息架构到评审迭代的方法论

一张合格的diagram-design，从来不是把框框和箭头摆整齐就完事。你可能也遇到过这种情况：花了一下午拖出来的架构图，评审会上被同事连续追问"这个模块到底是做什么的""这条链路谁发起谁响应""为什么中间少了缓存层"；或者三个月后你自己再看那张图，死活想不起某个虚线箭头代表的是异步消息还是回调。我去年有段时间被这类问题反复折磨，前后改了七八版图，最后才算摸清楚——架构图的核心不是"画"，而是"设计"。这里的design，指的是从信息架构层面想清楚每一层放什么、每条线传达什么语义、每个颜色承担什么职责，再动手落笔。

这篇文章就围绕diagram-design这件事，把我在实际项目中反复踩坑之后沉淀下来的一整套方法讲透：从动笔前的受众分析和层级拆分，到工具选型、图层配色规范、连线标注规则，再到评审迭代与版本归档。适合正在为团队画架构图、系统图、时序图的人看，无论你是刚入门的新人，还是被评审会虐过几次的老手，文里提到的规范和清单都能直接拿过去用。

1. 大多数架构图"能看但没用"，问题出在信息架构

我最早画架构图的方式很朴素：打开画布，把系统拆成几个大框，框里塞上组件，框之间拉箭头，标上"调用""写入""返回"，然后导出发群。这事干了几次之后发现一个扎心的事实——图发了，但没人真的照图干活。新同学入职问某个服务依赖谁，还是来问我；排障的时候查调用链，还是翻监控后台。那张漂亮的架构图，存在感几乎为零。

后来我意识到，问题不出在工具，也不出在绘图技巧，而出在最开始的信息架构。画图之前的脑子里只有一团模糊的"系统大概长这样"，落到画布上自然也只能是一张流水账。所谓diagram-design，本质上是在做信息的分层和翻译：把复杂的系统结构，按照阅读者的认知方式重新组织，把"一堆组件"变成"一组有层次、有边界、有语义的关系"。

1.1 场景案例：一张图为什么在排障时完全派不上用场

印象最深的一次，线上服务偶发超时，我临时打开那张精心绘制的总览图，想顺着链路找瓶颈。结果发现图上把所有模块画成一个大平层，每个框里塞了五六行文字，箭头密密麻麻——订单模块、库存模块、支付回调、异步对账全部交织在一起。我花了十分钟才找到"用户下单"的入口在哪儿，又花了几分钟追完了一条链路，但图上完全看不出哪一段是同步阻塞的、哪一段是异步解耦的，更看不到数据最终落在哪个存储。最后我还是关了图，直接用命令行一个个服务查过去。

那次之后我给自己定了一条规矩：一张图只回答一个问题。如果总览图拿来讲系统全景，就不要指望它同时承担链路排查的职责；真正用于排障的链路图，必须画出时序、同步/异步语义、超时和降级点。这不是多画几张图的问题，而是信息架构的自然延伸——先确定图要交付的核心价值，再决定上面放哪些元素。

1.2 架构图承载的角色：文档、沟通工具和决策依据

在团队里，架构图其实同时承担三个角色。首先是文档，它要记录系统的结构，让一个月后、一年后的人还能读懂；其次是沟通工具，它在评审会上充当大家讨论的统一坐标系，指着图说"这个模块边界不对"比空口争论有效得多；最后是决策依据，很多技术选型、重构方案的讨论都是围绕着一张准确的图展开的。

这三个角色对图的质量要求完全不同。作为文档，要求信息和代码现状一致，不能出现"理想架构"和"实际架构"两张皮；作为沟通工具，要求图层级清晰、焦点明确，让讨论能快速定位到具体区域；作为决策依据，要求把关键链路、依赖关系和数据流画得准确，不能有模糊表述。我在实践中发现，很多画图问题本质上都是角色错位：把用于沟通的草图画完就当作文档归档，文档里充斥着过时信息，最后连维护者自己都不信这张图。想清楚一张图服务谁、回答什么问题，是一切设计动作的前提。

2. 动笔前的三件事：先想清楚受众、边界和层级

很多教程上来就讲配色和连线技巧，但我的经验是，diagram-design最关键的决策都发生在画布打开之前。你只要在这个阶段多花十分钟，后面能省下大半天的返工。具体来说就是三件事：确认读者是谁，划定系统边界，拆分层级粒度。

2.1 先弄清这张图是画给谁看的

同一套系统，给技术委员会展示的图和给刚入职的新同学看的图，画法截然不同。给决策者看的图，重心在宏观结构和职责划分——它们关心的是模块边界是否清晰、关键依赖是否合理、演进方向是什么，这时候细节越多越干扰，应该用大颗粒度的组件，弱化具体接口；给一线开发看的图，重心在执行——它们需要知道谁调谁、数据怎么流、失败怎么处理，这时候必须体现接口语义、存储和中间件；给运维或SRE看的图，重心在部署拓扑和依赖关系——哪些服务部署在一起、哪些依赖跨机房、哪些点容易成为瓶颈，必须画清楚物理部署和逻辑架构的对应。

我习惯在新建画布前先写一行受众备注，比如"读者：某某项目组后端开发，目标：快速定位下单链路的依赖关系"。然后整个设计过程中不断拿这行字来校准取舍。一个很典型的取舍是：给团队的内部图我从不画业务操作流程，但给产品涉众看的图会把用户角色和动作显性标注出来——因为后者需要靠这些信息理解整个系统的上下文。

2.2 把系统边界和外部依赖单独列出来

第二件事是画出系统边界。我做这件事的方式很简单：打开一个空白文档，把系统内部模块写在左边，把外部依赖写在右边，中间画一条分隔线。线左边是你能控制和修改的部分，线右边是第三方服务、遗留系统、上游下游等外部实体。这样做的原因是，边界决定了讨论的物理空间。评审会上无休止的争论，九成是边界不清晰造成的——有人说的是"订单模块内部实现"，另一个人想的是"订单模块对外的接口行为"，两个人对不上话。

实践中我还会额外标注出哪些外部依赖是强依赖、哪些可以通过降级策略容忍不可用。这个信息在画图时不一定直接呈现，但它会影响我在图上怎么表示依赖方向——如果某个外部系统挂了会导致整体不可用，我会在依赖线上标注"强依赖"；反之会标注"可降级"。别小看这个细节，很多人画图只画线，忽略了依赖的语义，结果一张图上所有连线同等权重，真正关键的链路反而被淹没了。

2.3 按"全景—子系统—模块—时序"四级粒度分层

层级拆分是我认为整个diagram-design流程中最重要的一步。我通常把图分成四个层级来规划，而不是一股脑画在同一个画布上：

• L1系统全景图：展示整个系统包含哪些子系统/服务、它们之间的主要关系、外部依赖是哪几个。目标是让人三十秒内看懂"这是一个什么样的系统"。
• L2子系统架构图：聚焦某一个子系统，展示它的内部模块划分、存储设计、与相邻子系统的接口。目标是支撑模块设计和详细评审。
• L3模块内部图：细化到具体模块/服务内部的处理流程、子模块协作、领域模型关系。目标是指导编码和单元测试。
• L4时序图/交互图：以时间顺序展示一次具体请求或任务在各模块间的流转过程，标注同步/异步、成功/失败分支。目标是排障和联调。

这四级不是每张图都要画全，而是提醒你：想到什么直接往一张图上堆，是架构图变烂的起点。我在一个中等规模的项目里，实际只用到了L1全景图和L4时序图，但正是因为提前做了分层决策，才知道哪些细节应该舍弃。画L1时我会反复问自己："这个内部实现细节，跟这张图的读者理解全局有关系吗？"没有就删掉，放进L2的草稿里。

3. 工具选型：轻量画布、在线协作还是专业设计工具

工具这个话题特别容易引发争论，实际上一旦明确了自己的画图场景，选型没那么复杂。我把常用工具按工作方式分成四类，每一类都有明确适用场景，也都有不可忽视的短板。这里不推荐具体某个品牌，但会把选型时的判断维度讲清楚，你拿这些维度去对照手头的工具即可。

3.1 四种主流画图方式的适用场景与短板

第一类是老牌的桌面流程图工具，胜在元件齐全、模板多，画标准流程图、网络拓扑图很顺手；短板是版本协作麻烦，在今天这个团队协作频率下略显笨重。第二类是在线协作白板，多人同时编辑体验极好，适合评审会现场修改、头脑风暴时快速拉结构；短板是图形管理和规范性较弱，图一旦变复杂，拖动、对齐会很痛苦，而且样式风格容易失控。第三类是专业矢量设计软件，图层管理、自动布局、组件复用、样式统一都比前两种强一大截，如果你需要维护一整套架构图规范，它是最合适的选择；缺点是上手成本高，不适合几个人临时画一张草稿。第四类是代码驱动画图方案，用文本描述来生成图形，好处是易于版本控制、可审阅diff、可自动生成和更新；缺点是交互式拖拽体验缺失，表达式复杂时阅读门槛高。

3.2 我的选型组合：草稿用轻量画布，终稿用专业工具

我现在的做法是分层使用工具，而不是押注在单一工具上。动笔前做信息架构梳理时，我会直接用在线协作白板拉一个粗糙的结构框架，连颜色都不管，就图个快；等框架得到认可、基本不大会大改时，我才会搬到专业矢量设计软件里，认真排图层、配色、调间距。这样既享受了草稿阶段的高效率，又保证了终稿的规范性和可维护性。

如果你所在团队对架构图的依赖还不深，我建议先别急着上全套规范，把最低限度的工具约定定好就行：比如所有架构图的源文件放在统一目录，导出格式统一用PDF或SVG，文件命名带日期和版本。先让"画图"这件事流动起来，再逐步用专业工具收拢样式。我在团队里推规范化时踩过一个大坑——一上来就要求所有人用重型工具加统一模板，结果大家嫌麻烦，转头又用回自己的轻量工具，规范形同虚设。后来改成"草稿不限工具，终稿统一收口"，落地阻力小了很多。

3.3 跨端阅读与导出：SVG、PDF和PNG的不同用途

选定工具之后，还有一个经常被忽略的环节：导出格式。多数人习惯导出PNG往群里一丢，但PNG有几个天然问题——放大糊、文字不可搜索、占用空间大、不可以嵌入文档。我的建议是相同的图至少导出两种格式：SVG用于网页/文档内嵌和后续放大查看，PDF用于打印和归档翻页。PNG只在聊天场景给人快速预览时用。

顺带提一个细节，导出前务必检查文字是否被转成了轮廓。有些画图工具导出PDF或SVG时会把文字转曲线，这时候图里的文字就再也搜不到了，对后续检索和维护非常不利。我在归档一批旧图时吃过这个亏，最后只能重新打开源文件导出。建议在工具设置里关闭"导出时轮廓化文字"选项，除非对方明确要求。

4. 图层、配色与图标：让图在五米外也能被看懂

这个章节是很多人理解的"diagram-design"的全部，但其实它只是其中一环。好消息是，只要前面信息架构没走偏，样式规范的部分是有明确规则可循的。我总结了一句话：好的架构图样式，是让读者在任何距离、任何光线条件下，都能一眼分出区域、识别层级、判断语义。不是炫技，而是降低认知成本。

4.1 画布网格与模块尺寸：建立视觉秩序的地基

打开专业画图工具之后，第一件事不是拖图形，而是设置画布网格和模块的基本尺寸。我通常把网格步长设为8像素，所有模块的宽高都取8的倍数，模块间距也遵循8的倍数。原因很简单——大脑对规律排列的视觉对象天然觉得舒适，而无规律的间距会在潜意识里制造"杂乱感"。很多人画图觉得"怪怪的，说不上来哪里不对"，多半就是间距乱造成的。

模块的基础尺寸我常用两种：标准模块宽160高56，用于表示服务、组件等对象；仓储模块宽200高56，用于表示数据库、缓存等存储类对象。同层级的模块必须等宽等高，除非有一等一的理由需要突出某个模块，否则不要随意改变尺寸。不同层级的模块通过尺寸或者颜色来区分，而不是让高矮胖瘦五花八门。这一条看起来简单，却是很多图的画风从"业余"走向"专业"的分水岭。

4.2 图层命名与组织：从源头杜绝"找不到元素"

专业矢量设计软件的强大之处在于图层系统，但我见过很多人根本不用图层分组，所有元素堆在默认的"图层1"里。结果就是，想批量选中某个区域的组件时根本选不中，想隐藏背景网格时得手动挑半天。图层组织没有多难，关键在命名习惯。我目前的图层结构固定如下：

• 00-背景（画布底色、网格、区域底框）
• 01-区域（分组容器的底色和标题）
• 02-模块（所有服务、组件、存储的形状和文字）
• 03-连线（所有关系线、箭头）
• 04-标注（注释、说明框、图例）
• 05-装饰（水印、版本号、页码）

每一层下面再按模块分区建子图层，名字用区域-模块名格式，比如03-连线/订单中心-库存中心。这样做最大的好处是：改图时能精准定位，导出时能灵活隐藏装饰层，甚至能直接复用某个区域的图层来生成局部特写图。我在评审会现场改图时，这个习惯帮我省了至少一半时间。

4.3 语义化配色：颜色永远不承担"好看"的职责

关于配色，最常见的错误是把架构图画成调色盘——一个模块一个颜色，五颜六色非常抢眼，但读者看完没有任何记忆点。正确的思路是配色即语义：相同的颜色串起相同类型的元素，读者不需要读每个框里的字，光是扫颜色就能建立初步心智模型。

我维护了一套固定语义色，虽然不限定具体品牌的色板，但原则是可辨识度高、色盲友好、数量不超过六个核心色：

实际画的时候，同一色系内部用不同程度的深浅来表示层级，比如核心业务模块用深蓝，子模块用浅蓝，背景区域用更浅的蓝灰。整体画面饱和度不要拉满，稍低一点更有"技术图"的气质。另外务必画一个图例放在角落，哪怕你觉得自己选的颜色"一看就懂"，也不要高估第一次看图的人的判断能力。

4.4 图标与形状：少即是多的统一规则

图标是个双刃剑。用得好的时候能快速传递模块职责，比如数据库图标、消息队列图标，读者扫一眼就懂；用不好的时候反而造成视觉噪音——风格不统一的图标混在一起，比没有图标更糟。我在实际项目中的做法是：同一张图里只使用一套线性图标，统一线宽和圆角风格；如果找不到合适的图标，宁可不放图标，也绝对不放一个风格突兀的。

形状的语义也要固定：矩形表示服务/应用，圆柱体表示数据存储，圆角矩形表示外部系统或者由他人负责的模块，六边形表示可能产生事件的中间件。不要自作聪明地发明形状的新规则，除非你打算在图例里写清楚。对接过不少团队后我发现，架构图的视觉规范，本质是让常识更可预期——当一个读者看到蓝色矩形时，他的预期应该是"这是一个内部服务"，而不是"这又是个啥"。

5. 连线、标注与文字排版：决定一张图的细节质感

图层和配色解决的是"扫一眼能看懂"，但架构图能不能长期使用，往往取决于连线和标注这类细节。我自己改了那么多版图之后，最强烈的感受是：一张图报废，通常不是因为大结构错了，而是因为线太多、线太乱、标注不清，导致根本没勇气去更新它。

5.1 连线的类型与走线规则：每条线都要说出来意

先定规则，连接线只有三种，每种都有明确的语义：

• 实线箭头：同步调用/依赖，表示A请求B并等待响应。
• 虚线箭头：异步通知/消息，表示A发出事件或消息，不等待返回。
• 无箭头细线：弱关联/配置关系，表示两者有关联但不构成主链路。

这三种线之外的任何花样，比如双箭头、波浪线、点划线带菱形，除非你画了图例并且在评审时逐一说明，否则一律不用。线的走线规则同样重要：横线优先、直角拐弯、不允许跨越模块区域。横线最符合阅读习惯，直角拐弯比斜线容易对齐，跨越区域会让读者误以为两个模块之间还有隐藏关系。我见过一张图，一条线从左上角模块连到右下角模块，横穿整个画布，沿途盖住了三组组件之间的关系线——这种线就应该被拆成两段，或者重新布局让相邻模块连在一起。

5.2 标注与文字排版：如何让图"不用解释也能懂"

标注是图的说明书，它承载了那些不容易通过图形表达的信息：数据量级、超时时间、失败策略、幂等性要求等。我习惯在图里使用固定的标注样式：-角标：放在模块的右上角，表示非功能属性，比如"QPS峰值 2k""P99 80ms"。

• 线标签：放在连接线的中段上方，用极简文字说明链路的触发条件或数据格式，比如"下单事件 JSON"。
• 图例和脚注：放在图右上角或右下角，说明特殊符号、颜色语义、版本信息。

标注最忌讳的是写成小作文。一个线标签超过六个字就说明信息颗粒度不对，应该挪到正文文档里，图里只留索引。另外，标注文字的字体大小应该比模块名称小一到两号，形成层级。很多人把图里所有文字都设成同样大小，结果一眼看去密密麻麻，分不清哪个是模块名、哪个是备注。

5.3 字号层级与命名规范：给字排一个"信息优先级"

字号层级是让一张图迅速"山是山、水是水"的关键。我常用的规则表如下：

模块命名的规范也很重要。我强烈建议使用完整的业务名称，而不是内部代号或者拼音缩写。因为架构图的读者包括了新入职的同事、跨团队协作的人，他们可能完全不知道"wms"是什么。第一次画图写"仓储管理系统"费不了多少功夫，但能让整张图的生命周期长好几倍。如果担心名字太长，可以在图例里标注"仓储管理系统（下简称WMS）"，后续图内统一用缩写。

5.4 常见的连线与标注陷阱：改图改出来的经验教训

我踩过几个反复出现的坑。第一个是连线头撞到模块边界之外，箭头停在了模块外面几像素的位置，放大看总觉得哪里不对——这是没有开启"吸附到锚点"导致的。第二个是文字和连接线重叠，一段线标签正好压在另一个模块上，既遮挡了模块名，又让线看起来断掉了。第三个是平行线不看起点和终点，两条相邻的连线分别从"订单服务"连到"支付服务"和"库存服务"，但因为没有对齐锚点，画面上看起来像交叉了一样。

这些问题的解决方式很简单：画完第一版之后，从100%缩放到50%再整体检查一遍。缩小之后，布局是否失衡、连线是否交叉、文字是否重叠，全部一目了然。别笑，我见过太多人从头到尾只在200%缩放比例下画图，图在放大状态下精致得像艺术品，一缩小就乱成一锅粥。好的架构图要经得起"缩小审视"，这在评审会上投屏时是必然场景。

6. 从初稿到终稿：评审清单与改图迭代的真实过程

前面讲的都是单次绘制时的规范，但一张架构图真正成熟，靠的是持续迭代。一块独立而完整的图纸，从初稿到能归档，通常要经历三轮打磨。我把这个过程总结为"自审—互审—实景校验"，每一轮都有不同的关注点。

6.1 自审清单：发布之前自己先过三关

我把自审分成三关，每关花几分钟就能完成，但能过滤掉大部分低级问题。第一关是信息完整性：这张图要回答的问题，读者能从中找到答案吗？关键服务、存储、外部依赖、同步/异步关系有没有漏画？我见过很多图把"缓存层"漏掉了，导致图上显示服务直连数据库，与实际架构完全不符。第二关是视觉规范性：同层模块是否等宽等高？连线是否有交叉？文字是否重叠？配色是否踩了语义色规则？第三关是叙事逻辑：从一个新读者的视角，沿着图的阅读顺序走一遍，能不能在三十秒内说出"这个系统由哪几部分组成、依赖谁、数据大概怎么流动"。如果连自审都过不了，就不要发出来麻烦别人。

6.2 第一轮自查后调整：从"信息堆砌"到"一张图讲一件事"

我第一次画某系统的全景图时，犯了所有新人都会犯的错：订单、库存、支付、营销、用户、通知，所有域都画了上来，每个域里又画了五个以上子模块，再连上十几条线，整张图像一锅大杂烩。自审第一关就挂了——我说不清楚"这个系统到底长什么样"。后来我强制自己删掉营销域、用户域等外围部分，只保留"核心交易链路"涉及的模块，图一下子清爽了。同时把外部依赖从十一个减到四个，其余的在图例用文字说明"还有若干外部系统未展示"。

这次调整给我最大的启发是：一张图的信息容量是有限的，与其让所有信息都出现在图上但都含糊不清，不如让少量信息出现但每条都准确。删掉的部分不是消失了，而是放到了别的图或其他文档里，它们的信息价值没有损失，但视觉重点保住了。

6.3 评审会上的改图方法：三种改动信号的识别

评审是架构图质量提升最快的时机，前提是你要听得懂大家在说什么。我把评审反馈归纳为三类信号。第一类是结构级反馈：有人提出"这两个模块的边界不对""这个依赖方向画反了"。这类反馈最重要，说明信息架构有硬伤，必须当场确认并立刻修改，而且要在图上同步更新依赖关系，不能嘴上说"好的回头改"。第二类是语义级反馈：有人问"这条线是同步还是异步""这个存储是强一致还是最终一致"。这说明图的标注不够明确，需要在对应连线上补充标签。第三类是噪音级反馈：有人建议加装饰、改颜色、放大某个模块等审美建议。这类反馈可以作为参考，但不要每次都响应，否则图会被改成各方审美妥协的产物。

我在评审现场改图有个固定动作：改完一个大改动之后，花三十秒缩到最小比例再检查一遍。因为评审现场通常投屏，大家看的其实是缩小后的全图，当场发现布局崩了比事后被截图吐槽强。

6.4 用真实系统校验图纸：图不是画完就结束了

最后一步是实景校验——我把它叫"图与代码的一致性审计"。画完架构图之后，挑一个业务链路，对照真实部署清单和配置文件逐项核对：这个服务是不是真的存在？这个缓存真的是这个中间件吗？这条依赖链路跟服务发现里的一致吗？我在某次校验中发现，图上画着的"消息队列A"早就被替换成了"消息队列B"，但因为没人更新图，整整两版架构文档都沿用错误信息。这种错误比不画图更危险——错误的图比没有图更误导人。

所以我在团队里定了一条规矩：任何涉及服务部署结构、存储选型、接口协议的变更，必须同步更新对应的架构图，否则变更评审不通过。开始时大家都嫌麻烦，但真正执行起来之后，图的信息准确度大幅提升，新同学看图的置信度也高了，整体沟通成本下降得很快。

7. 文件的版本管理与归档：一张图三个月后依然可用

画图的最后一公里不是导出图片，而是归档。我见过太多团队,图倒是画了不少，但散落在各自电脑和聊天记录里，三个月后想找最新版只能挨个问。这个问题如果解决不好，前面所有规范都白搭，因为图一旦"找不到""不敢用"，就自然失去了作为文档的价值。

7.1 源文件、导出文件与命名规范

归档的第一步是确定文件的存放位置和命名规范。我的建议是：源文件统一放在团队的共享文档目录，按"模块/系统名-图类型-日期"命名，例如订单系统-全景图-20250515；导出文件放在同目录的export子目录，同一张图的SVG、PDF、PNG都放一起。严禁在本地电脑存"最终版""最终版2""最终不改了"这类命名文件，我在团队里说了很多次，但架不住惯性，后来直接把这写进归档规范，评审时抽查。

命名里的日期指的是"最近一次修改日期"，不是创建日期。这样翻目录时看到的最新日期就是最新版本，不需要打开文件确认。这个细节很琐碎，但它从根本上避免了"拿着旧图开了一个小时会才发现了"这种乌龙。

7.2 设计决策记录：让每一版改动都有据可查

归档除了图本身，还应该配一页简短的变更记录。我在每张重要架构图的源文件旁放一个文本文件，记录每次改动的时间、改动人、改动内容和触发原因。比如"2025-05-15：因缓存迁移，将图内缓存组件由A替换为B，并将此前标注的强依赖修正为同步调用"。这页记录的未来价值在于：几个月后如果架构又改回去，你可以直接查上次为什么改掉，不用重新走一遍分析流程。

这个习惯一开始是我自己动手做的，后来发现团队里其他人也受益——尤其是新同学接手模块时，看到这页记录就能理解图里那些看似奇怪的连线背后是有原因的。归档不只是存图，更是在存设计上下文。

7.3 定期Review制度：架构图不做"一次性消费品"

最后一条经验可能反直觉：架构图不是画完就结束的一次性交付物，它需要定期维护。我的做法是把架构图Review和架构评审绑定——每次大版本迭代前，先花半小时把所有涉及变更的图过一遍，标记出与实际部署不一致的地方，然后按优先级更新。不需要每周看一次，但至少每个迭代周期内应该有一次。

当然，不同类型的图维护频率是不同的：全景图建议每季度至少看一次，模块图和时序图则应该跟着代码变更实时更新。另外一个可执行的信号触发器是：发现有人不看图而是直接来问你系统结构时，就是图纸更新的时候了——说明图已经不可信到大家默认不会去查。与其被同一个问题反复打扰，不如趁这个时机把图中过时信息订正一次。

8. 结尾：关于diagram-design的一点个人体会

改图改到吐之后，我反而更看重画图之外的那些事。diagram-design听起来是个偏视觉的话题，但真正决定一张架构图好坏的是信息架构、语义规范和持续维护——工具只是最后落笔的那一层。我现在的习惯是先写一行受众描述，再划边界、拆层级，然后才动手拖框连线。这个过程听起来麻烦，但真的能让图从"能看"变成"能用"。

如果你现在手头正有一张改了两天还觉得不对的图，我的建议是别急着继续调样式，先退回第一步，问自己三个问题：这张图要回答什么问题？读者是谁？哪些细节属于另一张图的职责？把这三个问题想清楚，多半画布上该删掉什么就一目了然了。另外补充一个小技巧：无论用哪个工具画图，都养成分层命名的习惯——图层结构清晰，改图速度能快一倍，你会感谢这个习惯的。