1. 从一张草图到一套系统diagram-design 到底在解决什么问题第一次看到 “diagram-design” 这个组合词很多人会以为它只是“画图”或者“设计图表”的缩写。但真正做过系统设计、技术方案评审、产品架构梳理的人会立刻意识到它指向的是一套更底层的能力把脑子里模糊的结构关系变成一张别人能看懂、能讨论、能落地的图。这件事听起来简单做起来却极其考验功力。我见过太多项目代码写得漂亮文档却一塌糊涂一张架构图里塞了三十个方框、五十条连线最后连作者自己都说不清数据到底从哪流到哪。diagram-design 的核心价值不在于教你用某个具体工具画出好看的图形而在于帮你建立一套从信息梳理到视觉表达的完整方法论。它要解决的问题包括面对一堆零散的需求和模块怎么快速识别出核心实体和关系面对不同受众开发、产品、运维、管理层怎么调整图的粒度和视角面对频繁变更的系统怎么让图保持可维护而不是画完就废。这套东西适合谁我认为三类人最需要一是刚带项目的新手负责人需要快速把思路可视化来对齐团队二是写了多年代码但一画图就头疼的工程师想补上结构化表达这一课三是需要频繁做方案汇报和评审的人希望用一张图代替十页文字。我自己在这个领域踩过的坑比成功案例多得多。早期我习惯一上来就打开工具开始拖方框结果画到一半发现漏了关键模块只能推翻重来。后来才慢慢悟到diagram-design 的第一步根本不是“画”而是“拆”。你得先把系统拆成不可再分的单元把单元之间的交互关系列清楚把数据流向和依赖方向标明白然后才轮到视觉呈现。这个顺序一旦搞反后面全是返工。还有一个常见的误解很多人觉得图越详细越好。实际上一张好的设计图信息密度是有上限的。超过那个上限读者的认知负荷就会爆炸图就失去了沟通价值。所以 diagram-design 里有一个很重要的原则叫“一图一意图”——每张图只回答一个核心问题。比如“系统有哪些模块”是一张图“一次请求经过哪些环节”是另一张图“数据存储在哪里”又是另一张图。把这些问题混在一起图就废了。接下来的内容我会从整体设计思路、核心细节拆解、实操过程、常见问题排查几个维度把 diagram-design 这套方法完整展开。无论你之前有没有画图经验只要跟着走一遍至少能做到拿到一个陌生系统三十分钟内产出一张让团队看得懂、能讨论的草图。2. 整体设计思路为什么先拆后画而不是先画后改2.1 从“画图工具思维”转向“信息架构思维”大部分人接触 diagram-design 的起点是找工具。网上搜一圈能列出几十个画图软件有在线的、有本地的、有代码驱动的、有拖拽式的。工具本身没有绝对好坏但如果你把注意力全放在工具上就会忽略一个事实图的质量取决于信息架构的质量而不是渲染引擎的质量。我见过用最朴素的文本框加箭头画出来的架构图逻辑清晰到可以直接当开发规范用也见过用高级工具画出来的炫酷图看完不知道系统到底有几个服务。所以 diagram-design 的第一层设计思路是先把“画图”这件事拆成三个阶段信息采集、结构建模、视觉编码。信息采集阶段你要回答“这个系统里有哪些东西”结构建模阶段你要回答“这些东西之间是什么关系”视觉编码阶段你才回答“用什么图形、什么颜色、什么布局来表达这些关系”。三个阶段有严格的先后顺序跳步就会出问题。为什么这个顺序不能乱因为视觉编码一旦开始你的大脑就会不自觉地被图形牵着走。比如你画了一个方框就会下意识地想给它加个边框、加个阴影、加个标题然后为了填满空白区域又会硬塞一些不重要的模块进去。这就是典型的“工具反噬思维”。先拆后画本质上是用结构约束视觉而不是让视觉随意发挥。2.2 核心实体识别怎么找到系统里“不可再分”的单元拆系统的第一步是识别核心实体。什么叫核心实体我的定义是在业务语义上不可再分、且具有独立生命周期的东西。比如一个电商系统用户、商品、订单、支付单这些是核心实体而“订单状态”不是实体它是订单的一个属性“下单动作”也不是实体它是实体之间的交互。识别实体的实操方法我常用的是“名词提取法”。拿一张纸把需求文档、接口定义、数据库表结构里出现的所有名词圈出来然后做三件事合并同义词比如“客户”和“用户”可能指同一个东西、剔除属性词比如“订单金额”是属性不是实体、标记生命周期比如“购物车”在结算后是否还存在。经过这三步剩下的名词基本就是核心实体。这里有一个容易犯的错误把技术组件和业务实体混在一起。比如“消息队列”是技术组件“订单”是业务实体。在高层设计图里业务实体应该是主角技术组件是支撑角色。如果你把两者平铺在同一层级图就会变得又乱又难懂。我的经验是先画业务实体图再画技术组件图最后画两者之间的映射图。这样每一张图都有明确的意图读者也不会被无关信息干扰。2.3 关系建模一对一、一对多、多对多到底怎么标实体识别完之后下一步是标关系。关系建模里最核心的是基数Cardinality也就是一个实体对应另一个实体的数量关系。一对一、一对多、多对多这三种关系在图上必须用不同的视觉符号区分开否则读者根本没法判断数据规模。我见过很多图连线就是一根光秃秃的线两端没有任何标记。这种图在评审时最容易被挑战“一个用户能有多个地址吗”“一个订单能拆成多个支付单吗”如果图上没标就得靠嘴解释而嘴解释的信息是留不下来的。所以我的习惯是每条连线两端都必须标基数用 1、N、M 这种符号或者用更直观的“1—*”表示一对多。除了基数关系的方向也很重要。数据流向、依赖方向、调用方向这三者有时候一致有时候不一致。比如服务 A 调用服务 B依赖方向是 A 依赖 B但数据流向可能是 B 返回结果给 A。如果图上只画一根箭头读者就会混淆。我的做法是用实线箭头表示调用或数据流向用虚线箭头表示依赖方向并在图例里写清楚。这样即使图变复杂了读者也能快速区分。2.4 视觉编码颜色、形状、布局的克制使用原则到了视觉编码阶段很多人会放飞自我。红橙黄绿青蓝紫全用上圆形方形菱形六边形全堆上最后图变成了调色盘和几何展览。diagram-design 里有一条铁律视觉元素的数量与信息清晰度成反比。每增加一种颜色、一种形状读者的认知负担就增加一分。我的做法是颜色最多用三种一种主色表示核心实体一种辅助色表示支撑组件一种警示色表示外部系统或边界。形状最多用两种矩形表示实体或服务圆角矩形表示外部接口或用户角色。布局上优先用分层布局把同一层级的实体放在同一水平线上上层依赖下层或者左侧流向右侧。这样读者扫一眼就能看出系统的层次结构。还有一个细节连线尽量不要交叉。如果实在避不开就用“跳线”符号表示交叉但不连接。我见过一张图连线交叉了二十多次读者根本追不出一条完整的路径。后来我帮他重画把实体重新分组调整布局方向交叉减少到三次图立刻就能看懂了。所以布局不是美术问题是逻辑问题。3. 核心细节解析从需求到成图的六个关键环节3.1 需求转译把模糊描述变成可画的结构实际工作中你拿到的需求往往不是“请画一张架构图”而是一段模糊的描述“我们要做一个新的订单系统要支持拆单、要对接多个支付渠道、还要能实时通知用户。”这段话里没有实体、没有关系、没有边界直接画图就是灾难。我的做法是先做一轮需求转译把这段话拆成三个清单实体清单、行为清单、约束清单。实体清单里放“订单、子订单、支付单、用户、通知”行为清单里放“拆单、支付、通知”约束清单里放“实时、多支付渠道”。然后针对每个清单追问实体之间的生命周期关系是什么行为触发了哪些实体的状态变化约束条件影响哪些环节的设计这个过程我通常会花十五到二十分钟用纸笔或者纯文本编辑器完成不打开任何画图工具。因为一旦打开工具注意力就会被界面吸引思考深度会下降。转译完成后我会得到一张“实体-行为-约束”的对照表这张表就是后续画图的唯一依据。3.2 边界划定哪些画进去哪些坚决不画边界划定是 diagram-design 里最容易被忽视、但影响最大的环节。一张图如果边界不清读者就不知道哪些是系统内、哪些是系统外讨论时就会跑题。比如你画了一个“支付”方框但没标清楚是自研支付系统还是调用外部支付渠道评审时就会有人问“支付失败了怎么重试”而这个问题可能根本不在本次设计范围内。我的边界划定方法是用一条虚线框把系统边界圈出来框内是本次设计要负责的部分框外是依赖或交互的外部系统。框外的实体用灰色或浅色表示框内的实体用主色表示。这样读者一眼就能看出哪些是“我们的”哪些是“别人的”。还有一个经验边界不要划得太大。有些图把整个公司的所有系统都画进去结果核心系统被淹没在几十个方框里。我的建议是一张图的边界最多包含三到五个核心实体超过这个数量就拆成多张图。每张图只聚焦一个子系统或一个业务域图与图之间用“引用”符号连接。3.3 层级划分一张图里到底放几层层级划分决定了图的纵向深度。我见过两种极端一种是所有实体平铺在一层图又宽又扁读者看不出主次另一种是层级太多画了七八层读者看到第三层就晕了。我的经验值是一张图的层级控制在三到四层最多不超过五层。三到四层怎么分以典型的业务系统为例第一层是用户或外部系统第二层是接入层或网关第三层是核心业务服务第四层是数据存储或基础设施。每一层用一条水平线分隔层与层之间的连线表示调用或数据流向。这样读者从上往下看就能理解一次请求的完整路径。如果系统特别复杂四层放不下怎么办我的做法是纵向拆分把核心业务服务层再拆成“订单域”“支付域”“用户域”三张子图每张子图仍然保持三到四层。然后在总览图里用一个大方框表示“业务服务层”旁边标注“详见子图 A/B/C”。这样既保持了总览图的简洁又保留了细节的可追溯性。3.4 连线规范箭头、虚线、颜色到底怎么用连线是图的血管血管乱了图就死了。我给自己定了一套连线规范用了好几年基本没出过问题实线箭头表示同步调用或数据流向箭头指向被调用方或数据接收方。虚线箭头表示异步消息或依赖关系箭头指向依赖方。无箭头实线表示关联关系比如“用户”和“地址”之间的归属关系。红色虚线表示异常流或补偿流比如支付失败后的退款路径。颜色上我尽量只用黑色和灰色画连线只有在需要特别强调某条路径时才用红色或蓝色。因为连线颜色一多图就会变得花哨读者的注意力会被分散到颜色上而不是逻辑上。还有一个细节连线上的标签。如果一条连线表示“调用”最好在线上标注调用的接口名或动作名比如“创建订单”“查询余额”。这样读者不用猜这条线到底在传什么。标签的位置也有讲究尽量放在线的中段不要压在实体方框上。3.5 图例设计让读者三秒内看懂你的符号系统图例是图的说明书。我见过很多图没有图例读者只能靠猜这个菱形是什么意思这个虚线框代表什么猜错了就会误解整个设计。所以我的习惯是每张图都必须带图例图例放在图的右下角或左下角不占用核心区域。图例里至少包含四类信息形状含义、颜色含义、连线含义、基数含义。比如“矩形业务实体圆角矩形外部系统实线箭头同步调用虚线箭头异步消息1—* 一对多”。图例的文字要简短一行一个不要写成段落。如果图是给非技术背景的人看的图例还要更直白。比如把“同步调用”改成“直接请求”“异步消息”改成“稍后通知”。我甚至见过有人在图例里加一句“看不懂的方框可以忽略不影响理解主流程”这种贴心的设计能大幅降低沟通成本。3.6 版本管理图改了怎么让所有人知道图不是画完就完了系统在变图也要跟着变。但很多人改图不改版本导致不同人手里的图不一样讨论时各说各话。我的做法是每张图都带版本号和日期放在图的左上角或标题下方。版本号用“v1.0”“v1.1”这种格式日期用“2025-03-15”这种格式。更重要的是每次改图都要写变更说明。变更说明不用长一两句话就行比如“v1.1新增支付渠道回调流程调整订单状态机”。变更说明可以放在图的备注区也可以单独维护一个变更日志。这样当有人问“为什么图里多了个方框”时你直接指变更说明就行不用重新解释一遍设计思路。如果团队用协作工具我建议把图源文件和导出图片都放进版本库每次修改都提交一次。这样即使图被误删或误改也能快速回滚。我吃过这个亏有一次直接在一个共享文档里改图改到一半发现改错了想撤回却发现没有历史版本只能凭记忆重画。4. 实操过程三十分钟产出一张可讨论的架构草图4.1 准备阶段纸笔、白板还是工具很多人一上来就问“用什么工具画图”我的回答是第一张草图永远用纸笔或白板。为什么因为纸笔的修改成本极低画错了划掉重画就行不会像工具那样让你产生“已经画了这么多舍不得推翻”的心理负担。而且纸笔没有对齐、没有自动连线、没有样式面板你的注意力会完全集中在逻辑上。我自己的流程是先用纸笔画三到五版草图每版只花五到十分钟重点是把实体和关系理顺。等草图稳定了再用工具画正式版。正式版工具的选择标准只有三条支持快速对齐、支持导出矢量图、支持协作编辑。具体用哪个工具不重要重要的是别在工具选择上花超过十分钟。如果你习惯用白板我建议用分区白板把白板分成四个区域左上角写实体清单右上角写关系清单左下角画草图右下角写待确认问题。这样讨论时所有人的注意力都有明确的落点不会乱跑。4.2 第一轮只画实体不画关系第一轮画图我要求自己只画实体方框不画任何连线。把实体清单里的每个名词画成一个方框按层级摆好然后用一句话描述每个实体的职责。比如“订单记录一次交易的核心信息包含商品、金额、状态”。这句话不用写在图上但你要能说出来。这一轮的目的是验证实体识别的完整性。如果画完发现某个实体说不清职责或者两个实体职责高度重叠就说明实体识别有问题需要回到需求转译阶段重新拆。我见过一个案例有人把“订单”和“交易”画成两个实体但说不清区别最后发现它们其实是一个东西只是不同团队叫法不同。第一轮结束后我会把图给一个不了解这个系统的同事看问他“你觉得这个系统里最重要的三个东西是什么”。如果他的回答和我的预期一致说明实体识别过关如果他说“我看不出来”说明实体命名或分组有问题。4.3 第二轮加关系标基数标方向第二轮开始加连线。每加一条线我都要问自己三个问题这条线表示什么关系基数是多少方向是什么三个问题答不上来这条线就不该画。加线的顺序也有讲究先画核心业务流再画支撑关系。比如电商系统先画“用户—订单—支付单”这条主链再画“订单—商品”“支付单—支付渠道”这些分支。主链画完了图的骨架就立起来了分支加进去也不会乱。这一轮最容易犯的错误是连线过多。我见过一张图两个实体之间画了五条线分别表示“创建”“查询”“修改”“删除”“通知”。这种图读者根本追不过来。我的做法是同一对实体之间最多画两条线一条表示主要交互一条表示次要交互其他交互用文字备注。如果交互确实很多就拆成两张图一张画读操作一张画写操作。4.4 第三轮加边界、加图例、加版本号第三轮是收尾。先用虚线框把系统边界圈出来框外实体改成灰色框内实体保持主色。然后加图例把形状、颜色、连线、基数的含义写清楚。最后加版本号和日期写上作者和变更说明。这一轮还有一个重要动作检查连线交叉。如果交叉超过五次我会调整实体位置把关联紧密的实体放在一起把长距离连线尽量缩短。有时候只需要把两个方框换个位置交叉就能减少一半。这个调整过程可能花五到十分钟但非常值得因为交叉少的图阅读体验会好很多。收尾完成后我会把图导出成 PNG 和 SVG 两种格式。PNG 用于快速分享和插入文档SVG 用于放大查看和二次编辑。如果团队用协作工具我还会把源文件链接附在图的备注里方便别人直接修改。4.5 评审阶段怎么用图引导讨论而不是被图带偏图画完了接下来是评审。评审时最容易出现的问题是讨论跑题有人盯着一个方框问“这个服务为什么不用消息队列”然后整个评审就变成了技术选型讨论偏离了架构设计的主题。我的做法是评审开始前先花两分钟重申图的意图“这张图只回答‘订单系统有哪些核心模块以及它们如何交互’不讨论具体技术实现。”然后按层级从上到下走一遍每到一个层级先讲设计意图再让参会人提问。提问时我会引导“这个问题属于本次设计范围吗如果属于我们记下来会后细化如果不属于我们放到下一张图讨论。”还有一个技巧用颜色标记待确认项。评审过程中如果遇到有争议的点我会在图上用黄色高亮标出来旁边写一个问号。评审结束后把所有黄色高亮项整理成待办清单逐项确认。这样既不会打断评审节奏也不会遗漏问题。5. 常见问题与排查技巧实录5.1 图太乱从“什么都想画”到“只画关键路径”图太乱是最高频的问题。症状包括方框超过二十个、连线交叉超过十次、颜色超过五种、读者看三十秒还找不到入口。根本原因只有一个你想在一张图里回答太多问题。排查方法是把图拿给一个不了解系统的人看让他用一句话说出这张图在讲什么。如果他说不出来或者说的和你的预期不符就说明图太乱。解决方法是做减法把非核心实体移到备注区把次要连线改成文字说明把颜色减少到三种以内。如果减完还是乱就拆图。我自己的经验是一张图的信息量上限大约是十二个方框加十五条连线。超过这个数读者的短期记忆就装不下了。所以每次画完图我都会数一下方框和连线的数量超了就拆。5.2 关系标错一对多和多对多到底怎么区分关系标错通常是因为对业务理解不够深。比如“用户”和“订单”表面上看一个用户可以有多个订单是一对多。但如果业务允许一个订单关联多个用户比如家庭共享订单那就变成了多对多。这种细节如果不和业务方确认图上就会标错。我的排查方法是用具体数字追问“一个用户最多能有几个订单一个订单最多能关联几个用户”如果答案是“一个用户多个订单一个订单一个用户”那就是一对多如果答案是“一个用户多个订单一个订单多个用户”那就是多对多。多对多关系在图上要用中间实体表示比如“用户订单关联表”不能直接画一条线。还有一个容易混淆的是可选和必选。比如“订单”必须关联“用户”但“用户”可以不关联“订单”。这种关系要在连线上标注“0..1”或“1..*”表示可选或必选。不标的话开发人员可能会做出错误的空值判断。5.3 层级混乱什么该放上层什么该放下层层级混乱的症状是读者看不出哪些是核心、哪些是支撑感觉所有方框都一样重要。根本原因是没有按抽象层次分组。比如把“用户界面”和“数据库”放在同一层把“业务逻辑”和“消息队列”放在同一层读者就会困惑。排查方法是按“谁依赖谁”排序。上层依赖下层被依赖的放在下面。比如用户界面依赖业务服务业务服务依赖数据存储那么用户界面在最上业务服务在中间数据存储在最下。如果两个实体互相依赖说明它们应该在同一层或者需要引入中间层来解耦。我的经验是层级划分要反映系统的稳定度。越底层的组件越稳定越上层的组件越易变。把稳定的放下面易变的放上面这样图在后续演进时底层不需要频繁改动改动主要集中在顶层。5.4 工具依赖换工具就画不出图怎么办有些人用某个工具用久了换一个工具就不知道怎么画了。这是因为他们把“画图能力”和“工具操作能力”混为一谈。真正的 diagram-design 能力是结构化的思考能力工具只是表达手段。排查方法是用纯文本画一遍图。比如用缩进表示层级用箭头表示关系用括号表示基数。如果你能用纯文本把系统结构说清楚说明你的设计能力没问题换工具只是熟悉快捷键的事。如果纯文本说不清楚说明你的结构还没想明白换什么工具都画不好。我自己的习惯是每次画正式图之前先用纯文本写一个“结构大纲”。大纲写清楚了再打开工具画图效率会高很多。而且纯文本大纲可以直接放进代码仓库和代码一起做版本管理比图片文件方便得多。5.5 维护断档图改了一次就再也没人更新图改了一次就没人更新是团队协作里的经典问题。根本原因是图没有和代码或文档绑定改图全靠自觉。一旦项目忙起来图就被遗忘了。我的解决方法是把图纳入变更流程。每次有架构变更必须同时提交图更新否则变更不通过。具体做法是在代码仓库里建一个docs/diagrams目录图源文件和导出图片都放在里面和代码一起提交。然后在合并请求的模板里加一条检查项“本次变更是否影响架构图如果是请更新对应图文件。”还有一个技巧用代码生成图。有些工具支持用文本描述生成图比如用特定语法写实体和关系然后渲染成图片。这样图就和代码一样可以 diff、可以 review、可以回滚。虽然学习成本高一点但长期维护成本低很多。5.6 常见问题速查表问题症状可能原因排查动作解决方向图太乱读者找不到入口信息量超载数方框和连线数量做减法或拆图关系标错评审被挑战业务理解不足用具体数字追问基数和业务方确认后重标层级混乱主次不分未按抽象层次分组按依赖方向重新排序稳定底层易变顶层换工具就画不出图工具依赖过强用纯文本写结构大纲先练结构化思考图改一次就没人更新未纳入变更流程检查是否有更新机制图与代码同仓库管理连线交叉太多实体布局不合理统计交叉次数调整实体位置或拆图图例缺失读者靠猜忽略图例设计检查是否有图例补全形状、颜色、连线说明版本混乱各说各话无版本号和变更说明检查图上有无版本信息加版本号、日期、变更日志6. 进阶技巧让 diagram-design 从“能看”到“好用”6.1 用颜色编码状态而不是分类大多数人用颜色来区分实体类型比如红色是服务、蓝色是数据库、绿色是外部系统。这种用法没错但有一个进阶技巧用颜色编码状态。比如在订单状态图里用灰色表示初始状态黄色表示进行中绿色表示成功红色表示失败。这样读者不仅能看到实体还能看到实体在生命周期中的位置。状态颜色编码特别适合流程类图。我做过一个支付流程的图用颜色标出每个环节的成功、失败、重试状态评审时业务方一眼就能看出哪些环节容易出问题。后来这张图直接被拿去当运维监控的参考因为颜色和监控告警的级别对应上了。6.2 用分组框表达边界和职责分组框Group Box是一个被低估的视觉元素。它可以把一组相关的实体圈在一起表达“这些实体属于同一个模块”或“这些实体在同一个边界内”。比如把“订单服务”“支付服务”“库存服务”圈在一个大框里标注“交易域”读者立刻就能理解它们的归属关系。分组框的用法要注意两点一是不要嵌套太多层最多两层三层以上读者就晕了二是分组框的标签要放在左上角不要放在中间否则会遮挡实体。我见过有人把分组标签放在框的正中央结果盖住了两个实体读者只能靠猜。6.3 用注释框补充“为什么”而不是“是什么”图能表达“是什么”但很难表达“为什么”。比如图上画了一个“消息队列”但为什么用消息队列而不是直接调用图里看不出来。这时候就需要注释框。注释框可以放在图的空白区域用一条虚线连到相关实体上里面写清楚设计决策的理由。注释框的内容要简短一两句话就行。比如“引入消息队列是为了削峰填谷避免订单高峰期直接压垮支付服务”。这种注释在评审时特别有用因为评审人最常问的就是“为什么这么设计”。有了注释你就不用每次都重复解释。6.4 用多视图满足不同受众同一套系统不同角色关注的点不一样。开发关注接口和依赖运维关注部署和监控产品关注业务流程管理层关注系统边界和成本。如果只用一张图很难同时满足所有人。我的做法是维护多张视图一张业务流程图给产品看一张服务依赖图给开发看一张部署架构图给运维看一张系统上下文图给管理层看。多视图的关键是保持一致的核心实体命名。比如“订单服务”在所有视图里都叫“订单服务”不要一张图叫“订单服务”另一张图叫“订单中心”。命名不一致会让读者以为是两个东西沟通成本反而增加。我通常会维护一个术语表所有视图都从术语表里取名字。6.5 用自动化检查减少人为错误图多了之后人为错误就多了。比如某个实体在 A 图里叫“用户服务”在 B 图里叫“用户中心”或者某个关系在 A 图里是一对多在 B 图里变成多对多。这些不一致很难靠肉眼发现但可以用自动化检查。我的做法是把图源文件用结构化格式保存比如 JSON 或 YAML然后写一个简单的脚本检查三件事实体命名是否一致、关系基数是否冲突、连线两端实体是否存在。脚本不用复杂几十行代码就够。每次提交图文件时自动跑一遍有问题就报错。这样虽然前期要花点时间搭检查脚本但长期来看省下的沟通成本非常可观。7. 我个人的实操体会画了这么多年图我最大的体会是diagram-design 的终点不是图而是共识。一张图如果只有你自己看得懂那它只是一张草图如果团队所有人都能看懂并且基于它做出决策那它才是真正的设计图。所以每次画完图我都会问自己一个问题如果我不在场这张图能不能替我说清楚设计意图如果答案是否定的那就继续改。还有一个反直觉的经验图不是越详细越好而是越克制越好。克制意味着你知道什么该画、什么不该画什么该放大、什么该省略。这种克制来自对系统本质的理解而不是对工具的精通。我见过太多人把时间花在调颜色、调字体、调对齐上却忽略了最核心的实体和关系。结果图很漂亮但没人用。最后分享一个小技巧每次画完图隔一天再看一遍。隔一天之后你会从“作者视角”切换到“读者视角”很多当时觉得理所当然的地方再看就会发现表达不清。我很多次都是在隔天复查时发现遗漏了关键关系或者发现某个命名有歧义。这个习惯虽然简单但效果出奇地好。