先聊个很多人都经历过的场景项目评审会上有人打开一张系统架构图满屏五颜六色的框、二十来个服务、七八种箭头、十几个缩写。讲解的人讲了十分钟听众还是一脸茫然。问一句某个数据到底怎么流转的讲解的人自己也卡住了低头在图上找了半天最后说呃这里可能我没画清楚。这种场面我经历过太多次后来实在忍不了就花了两个多月把怎么把图画清楚这件事系统性地做了一遍项目代号就叫 diagram-design。它不是一个画图软件而是一整套关于图表设计的思路、模板和检查清单。这套东西不挑工具也不挑行业无论是架构图、流程图、时序图还是数据图表核心逻辑都通用。这篇就把整个项目的思考过程和落地细节完整拆开讲适合正在为图怎么画都画不清楚发愁的开发者、产品经理和技术写作者也适合团队里负责沉淀知识文档的人参考。1. 从一场混乱的评审会到 diagram-design 这个项目1.1 那张把我讲晕的架构图到底错在哪先说那次评审会。当时某内部业务平台准备做一次大的架构调整负责的同事花了一周时间画了一张全景架构图意图是把所有服务、依赖、存储、消息链路一次性讲清楚。图确实很大打印出来能贴满一面墙但问题恰恰就出在什么都想画上。那张图的第一个问题是图层没有主次。所有服务框都是一样的描边、一样的配色、一样的字号根本分不清哪个是入口、哪个是核心、哪个是边缘支撑。第二个问题是指向混乱有单箭头、双向箭头、虚线箭头、带圆点的箭头但图上没有任何图例没人知道实线和虚线分别代表什么。第三个问题是颜色被当成装饰而不是信息纯为了看起来好看而填色。我当时在台下听第一反应是这图真大第二反应是完全没看懂。事后我和同事复盘他其实非常了解整个系统表达能力也不差问题是他把我知道的东西直接搬到了图上跳过了读者需要按什么顺序接收信息这一步。那一刻我意识到画图这件事之所以做不好大多数时候不是工具问题也不是审美问题而是缺少一套设计方法和判断标准。我们的知识文档里写满了文字规范却没有人定义过一张好的图应该长什么样。1.2 diagram-design 的定位和边界那次之后我开始动手整理 diagram-design但最开始我犯了一个方向性错误——我差点又陷进再做一个画图工具的坑里。调研了一圈现有工具之后我发现缺的从来不是画布、画框、箭头、图标的软件能力而是拿到一堆信息后怎么组织的方法。所以我重新定义了项目的边界diagram-design 不产出软件只产出一套可复用的知识资产具体是三块东西。第一块是图型选择指南。拿到一个表达需求时先不急着画而是判断它到底属于哪一种信息类型是讲步骤顺序、讲结构包含、讲时间线上的交互还是讲数据分布与对比。图型选对了一张图就成功了一半选错了后面再精细的画工也救不回来。第二块是模板库。把高频出现的图型结构沉淀成参数化模板比如系统架构图模板、部署流程图模板、时序交互模板、状态流转模板。使用时只需要替换内容不需要从零思考排版和布局。第三块是出图检视清单。一张图画完之后按清单逐项检查受众是谁、主视觉是否一眼可见、信息层级是否清晰、图标箭头是否有图例、色彩是否传达语义、输出格式是否匹配使用场景。这张清单后来成了团队内部最有用的东西因为它是唯一一部分画图前打开和画完图后打开都会被反复使用的内容。这三块内容在下面几章会逐一展开不过先别着急跳到细节。如果你想用这套思路有一点要提前想明白diagram-design 强调的是先想清楚再动手这和我们平时习惯的打开画布就开始拖框完全相反。刚开始你会觉得别扭但只要按这个顺序走出图的效率和图的可用性都会明显提升。2. 图表的底层逻辑选型、层级和信息密度2.1 图型选型先分类再画而不是看哪个图型名气大很多图之所以难看本质上不是画功问题而是图型选错了。你拿来看二维表更合适的数据去画成架构图拿流程图去表现结构包含关系当然会别扭。diagram-design 里的第一条规则就是把信息按叙事类型分类再去匹配图型。我平时把信息分成五个大的叙事类型。第一类是流程时序型信息的核心是先后顺序、条件分支、角色之间的先后动作这时优先考虑流程图、时序图、泳道图。第二类是结构归属型信息讲的是包含关系、模块边界、系统分层这时候架构图、树状图和嵌套图更合适。第三类是状态变化型信息里充满状态之间的跳转、事件触发、状态约束最合适的是状态图。第四类是对比分布型面对多组数据之间的比较、占比、趋势应该落在柱状图、折线图、饼图这些统计图形范畴。第五类是关系网络型信息里是节点与节点之间的多对多关联比如服务调用关系、社交图谱需要用网络图。这套分类看着简单但实际使用中很容易栽跟头。最常见的情况是把结构归属画成了流程。举个例子有一个团队给新系统画模块关系结果用流程图的方式把所有模块串成一条线加上箭头就是一个从A到B到C再到D的顺序过程但模块之间明明是并行调用关系。这么一画读者会误以为必须严格按顺序走完对系统行为的理解就完全错了。反过来有人把一段真实的审批流程画成了架构图分层的框是画出来了可谁先谁后完全体现不出来。我在内部给这个环节起名叫一分钟图型判定拿到需求后先花一分钟回答三个问题——信息里有没有顺序信息里有没有包含信息里有没有角色交替有顺序优先考虑流程图有包含优先考虑架构图有角色交替并强调时间线就顺手补充时序图。这套判定在 diagrem-design 模板库里实现成了一个小小的决策脚本后面讲模板的时候会再提到。2.2 信息层级一张图必须能被扫读先聊一个真实体验我拿同一批信息画了两版架构图让团队选大多数人只看了一眼就选了后者甚至说不出具体理由只是觉得这版更清楚。差距其实只在一个点上信息层级。人的阅读模式分两种一种是单点聚焦阅读一种是快速扫读。好的图表首先要支持扫读因为读者第一次看到图时会用极短的时间扫描全图确认这是什么图、重点在哪、和我有什么关系然后才进入局部细节。如果扫读阶段失败读者就会产生看不懂的挫败感后面再多的信息也传不进去。要让扫读成功层级设计必须清晰通常我会分三层搭建。第一层是全局识别层包括图表的标题、主区域的大色块和边界的划分。这部分负责回答图里讲的是什么领域所以标题要具体主区域之间的边界要足够明显。第二层是核心逻辑层包括主链路、主要依赖关系、核心模块。这部分是整张图的心脏应该通过更强的视觉权重来突出比如更粗的线条、更深的颜色、更大的字号。第三层是细节支撑层包括辅助节点、注释、图例、参数说明这些信息可以相对弱化字号小一点颜色灰一点放在主图的下方或侧边。这三层在版面上的实际对应位置大概是这样的主区域占版面中央约 70% 的位置这是个安全比例。细节支撑可以放到底部或右侧的注释放置处但要和主区域之间留出明确的白空间隔。全局标题放在左上角因为中文阅读习惯是从左上进入。还有一点容易被忽略对齐。图里的所有框体凡是同一层级、同一类型的元素尽量沿同一条基线对齐保持相同的水平间距和垂直间距。很多图看上去乱不是颜色和形状的问题就是单纯的对齐没做好。只要把元素对齐、间距统一清晰度会立刻上一个台阶这个效果几乎是立竿见影的。2.3 信息密度什么该画什么该删什么该折叠信息密度的问题本质上是对读者认知带宽的估算。人短时间内能记住的信息组块是有限的一张图里如果塞进太多组块读者就会丢三落四。我之前看过的那些全量大图问题就出在这里作者把一周调研的所有信息都堆在一张图里每个细节都舍不得删结果读者一个重点都没记住。diagram-design 给信息密度定了一个可操作的判断标准一张图只解决一个核心问题。这个一个不是指只画一个模块而是指整张图必须有一条一眼能说清楚的主链路。围绕这条主链路相关的元素可以列入但要把它们区分为主链路必要信息和背景上下文信息两类。后者如果不影响理解主链路就折叠起来放到注释里用文字描述如果确实要和主图共存就缩小尺寸、降低色彩饱和度。一句实用的口诀是如果一张图删掉某个节点后读者依然能准确复述这张图在讲什么那这个节点就是冗余的。刚开始做裁剪的时候总会心疼觉得信息删掉就丢了但实际上折扣并不会丢失信息只是把它们从图内强视觉挪到了图外弱视觉在需要的时候还能查得到。另外还有一个容易被忽略的密度指标是图中箭头的数量。箭头是视觉噪音最大的元素每增加一条线读者的注意力就会多一分负担。我见过一张业务链路图里面详情调用和数据回写的箭头交织在一起形成了一张蜘蛛网。规范的做法是把高频主链路和低频异步链路分开表达不同线型配合图例而不是全部挤在同一区域。说到这个就正好引出下一章的工具选型——工具虽然是载体但它在很大程度上决定了你处理密度和层级的方式。3. 工具选型的实际踩坑与最终取舍3.1 三类主流载体手绘白板、GUI 绘图、代码化绘图图表设计绕不开工具选型这个问题。我在 diagram-design 里把常用载体分成三大类每一类的适用场景和代价都很不一样。第一类是手绘白板和纸笔。它的最大价值是够快、够随便。在需求讨论的早期阶段信息还是碎片化的思路也没成型适合用白板快速画框、画线、画箭头画错了直接擦掉重来。这个阶段千万不要一上来就打开绘图软件精修因为早期的重点是把想法暴露出来而不是把排版做漂亮。白板图的缺点也很明显不可版本管理、不可复制、不可搜索所以它只适合想清楚的阶段不适合沉淀下来的阶段。第二类是 GUI 绘图工具包括我们已经非常熟悉的通用画布类工具和专用图表类软件。它们的优势在于所见即所得、排版自由度高、内置图形丰富适合制作复杂的示意图、大尺寸海报图、以及需要精细调整视觉效果的对外文档插图。劣势在于图一旦复杂起来元素的对齐和修改成本直线上升而且要改动结构时往往需要手动调整大量框和线条的位置效率很低。第三类是代码化绘图比如用 Graphviz 的 dot 语言、PlantUML、和各类基于文本描述的图表工具。这类方式把图和源码绑定可以进版本库、可以 diff、可以 review、可以自动化生成。改一个节点只需要改一行文本。劣势是布局自由度低很多视觉效果无法精确控制中文排版有时也需要额外配置。这三类工具的界限不是固定的实际使用中我反而把它们当成一条流水线白板负责形成思路代码化负责沉淀结构GUI 负责最终视觉润色。拿比例来说我自己在整个 diagram-design 项目里使用频率从高到低是代码化约 50%白板约 30%GUI 约 20%。这个比例在很多团队里会被质疑因为大部分人更习惯直接打开 GUI 拖拽。我的建议是不要照搬这个比例但可以试试把代码化这个环节加进来你会发现很多场景下它能解决你以前没意识到的痛点。3.2 为什么我在 diagram-design 里把代码化当作主力这个选择一开始不被理解有人觉得代码画图不如拖拽工具灵活、学起来还有门槛。但跑了几轮实际项目之后团队就服气了因为代码化解决了好几个 GUI 工具很难解决的问题。首先是版本管理和变更记录。图一旦用代码描述就可以和代码一样提交到版本库。每次修改都有 diff谁改了哪一行、为什么改清清楚楚。我印象很深的一次某服务的依赖关系半夜上线后出了问题排查时就是靠架构图的 dot 文件 diff 快速定位到是哪条新增的调用链导致的这在 GUI 工具里几乎不可能实现。其次是模板化生成。diagram-design 里沉淀的架构图模板本质是一段带占位变量的 dot 代码。通过脚本批量替换变量一套模板就能生成不同项目的架构图不用每次从空白画布开始。比如下面这个简化的例子把服务名字、依赖关系写进变量一段代码就代表一张清晰的结构骨架digraph G { rankdirTB; node [shapebox, stylerounded,filled, fontnamePingFang SC]; gateway [label网关, fillcolor#dff0f9]; order [label订单服务, fillcolor#dff0f9]; pay [label支付服务, fillcolor#dff0f9]; logistics [label物流服务, fillcolor#dff0f9]; gateway - order [label下单]; order - pay [label发起支付]; pay - order [label支付回调]; order - logistics [label创建运单]; }这段代码生成的图结构很朴素但它最大的价值是评审友好团队评审时可以直接对着 diff 讨论而不是打开一张像素级别的图片指指点点。代码化让图第一次具备了和代码同等的可维护性。3.3 代码化绘图的短板与补救方法当然代码化不是万能的我踩过的坑也不少于受益。最明显的痛点是布局不可控。Graphviz 有自己的一套自动排版算法它排出来的布局在逻辑上没问题但视觉上未必符合预期。比如希望网关在最顶部、数据库在最底部自动布局却把某些节点挤到奇怪的角落。这种情况需要用 rank、constraint、subgraph 这些手段做精细干预但干预语法本身有学习成本。第二个痛点是非 ASCII 字符和中文的渲染。很多代码化工具默认字体对中文支持一般输出的图片里中文可能会变成豆腐块或者出现重叠、截断。我的习惯是在 dot 文件里显式设置 fontname 为中文字体这一步几乎每次都要做别指望默认配置能用。第三个痛点是复杂装饰效果做不了。代码化绘图适合表达结构不适合表达视觉表现力。如果你需要做一张用于对外宣传海报的架构图需要渐变、阴影、高清位图素材那就不适合纯代码化。我的补救方案是分层处理结构骨架用代码化生成导成 SVG 之后再放进 GUI 工具里做视觉润色。这样既保住了可维护性又拿到了视觉效果。工具这部分总结起来就一句话不要被某一个工具绑架。diagram-design 里的建议是按阶段切换工具而不是所有图都用同一个工具画完。当你把工具从唯一创作环境降级成流水线上的一个环节整个人会轻松很多图的品质也会上来。下面我用一个完整的实战过程把上面这些原则串起来。4. 实战拆解一张系统架构图的完整设计过程4.1 需求判定先确认这张图是给谁看的抽象的原则讲再多都不如跑一遍完整流程来得直观。我拿一个真实做过的案例来拆解场景是要为某内部业务平台的订单履约系统画一张架构图。但先说明这里的重点是设计思路服务名和调用关系我已经做了简化脱敏不涉及任何真实业务数据。拿到需求后我没有立刻开始画而是先做了需求判定。我问了三个问题第一这张图给谁看的答案是刚入职的开发同学目的是让他们尽快建立起对系统全貌的认知。第二读者拿到图之后要做什么答案是能说出系统分了哪几层、核心服务之间如何协作、数据如何流转。第三有没有强制的篇幅限制答案是要能放在一页文档里方便打印和被引用。这三个问题的答案直接决定了后续的图型选型和信息取舍。因为读者是新人所以我决定在结构层级和主调用链之间做平衡主视觉以分层架构为主附加一条从下单到履约完成的主链路。因为目的不是排查问题所以不画繁复的异常分支、不画底层队列细节那些信息可以留到专门的故障排查图里。这个环节是整个流程里最重要的一步。很多人一拿到需求就直接开画画到一半发现这图到底是给谁看的都没想清楚结果就是既想照顾老板的全貌需求又想照顾开发的细节诉求最后画出一张两头不靠的妥协图。4.2 从白板草图到结构化草案需求判定之后进入真正的设计阶段。我的习惯是先上白板把脑子里零散的信息全部铺开这一步完全不考虑美观。当时我在白板上画了大概十几个方框分别代表用户端、网关、订单服务、支付服务、库存服务、物流服务、消息队列、数据库等。然后开始画箭头画的过程中不断问自己这个调用是同步还是异步是从上往下还是从下往上白板草图的作用是逼你把我知道的信息变成我能说清楚的逻辑。我当时的一个明显收获是原本我以为订单履约链路很清晰可真往白板上画的时候才发现支付回调这条链路的归属我一直没有理顺到底是支付服务主动调用订单服务还是订单服务轮询支付状态这个问题不弄清楚后面画到图里就是一条错误的箭头。白板阶段的这个纠错动作其实就是在为成稿打地基。白板讨论结束信息已经收敛成了一张结构化的草案。为了不让它停留在白板照片阶段我会把每一项依赖关系整理成表格。比如下面这张表就是当时从白板整理出来的核心内容编号起点终点方向类型说明1用户端API网关下行HTTPS 同步请求入口2API网关订单服务下行同步创建订单3订单服务支付服务下行同步发起支付4支付服务事件中心下行异步支付成功事件5事件中心订单服务上行异步订阅支付结果6订单服务库存服务下行同步预占库存7订单服务物流服务下行同步创建运单8物流服务事件中心下行异步物流状态变化这张表看起来笨拙但它的价值超常它让你在成稿之前就对到底有哪些依赖、每条依赖是什么性质达成共识。后续画图的过程本质上就是把这张表可视化的过程。4.3 成稿细化布局、配色、字体与导出草案确定之后我进入了代码化绘制环节。用 dot 描述布局时我遵循一个很大的原则先用分组把结构边界画出来再用连线把依赖关系表达出来最后用颜色和线型表达语义。分组对应的是分层架构的视觉表达用 subgraph 来表示。我把参与者分为四层接入层、应用层、支撑层、数据层。对应的代码结构是这样digraph order_system { rankdirTB; splinesortho; node [shapebox, stylerounded,filled, fontnamePingFang SC, fontsize12]; subgraph cluster_edge { label接入层; stylerounded,dashed; color#888888; gateway [labelAPI网关, fillcolor#dff0f9]; web [label用户端, fillcolor#dff0f9]; } subgraph cluster_app { label应用层; stylerounded,dashed; color#888888; order [label订单服务, fillcolor#dff0f9]; pay [label支付服务, fillcolor#dff0f9]; stock [label库存服务, fillcolor#dff0f9]; logistics [label物流服务, fillcolor#dff0f9]; } subgraph cluster_support { label支撑层; stylerounded,dashed; color#888888; event [label事件中心, fillcolor#fdf5d5]; } subgraph cluster_data { label数据层; stylerounded,dashed; color#888888; db_order [label订单库, fillcolor#e8e8e8]; db_stock [label库存库, fillcolor#e8e8e8]; } web - gateway [label下单]; gateway - order [label创建订单]; order - pay [label发起支付]; order - stock [label预占库存]; order - logistics [label创建运单]; pay - event [label支付成功, styledashed]; event - order [label订阅结果, styledashed]; order - db_order [label读写]; stock - db_stock [label读写]; }这里每一处细节都是有意的。接入层和应用层的节点用浅蓝色因为它们是主链路的主角支撑层用淡黄色表示它扮演事件枢纽的辅助角色数据层用灰色代表底层存储。整体配色全部控制在低饱和度的浅色系这样既能在屏幕上长时间观看不吃力打印出来也不会因为大面积深色块浪费墨。线型和颜色同样承载语义同步调用用实线异步事件用虚线。添加图例说明线型和颜色的含义并在图底部注明本图省略异常重试与补偿链路的说明避免读者误以为图里的流转就是全貌。字体和字号上节点内的中文统一使用同一套无衬线字体主标签 12 号分组标题 13 号加粗注释文字 10 号。不要在一张图里混用超过两种字体和三个字号层级否则很容易显得杂。整个布局里我会刻意让主链路尽量笔直网关到订单服务、支付服务、物流服务这条核心路径在同一条竖直方向附近读者视线从上往下一扫就能理解数据是怎么进来的、怎么流转的。这里的干预手段主要靠 rank 同组设置和空白节点辅助虽然 dot 的自动布局偶尔需要手动伺候但从成品效果看是值得的。成稿之后是导出。架构图这类需要嵌入文档系统的图我的首选是 SVG因为它是矢量图放大缩小都不糊还能被文本检索工具索引到内在文字。如果使用场景是 PPT 或者 IM 聊天再从 SVG 转一份合适尺寸的 PNG。导出时记得检查一个问题SVG 里的中文字体是否被正确嵌入有些导出工具如果没选对选项换台机器打开就一堆方块。这个问题在团队协作中特别容易炸我至少踩过三次。4.4 交付后的反馈迭代一张图从来不是一次画完的成稿交付给团队评审时我预期大家会直接接收结果还是被提了几个扎心的问题。第一个反馈是入口网关和用户端之间的关系没有标注清楚新人分不清谁是外部角色谁是内部服务。当时的图里用户端和网关都在接入层都是同样的蓝色系但它们的性质完全不同一个是系统外部发起者一个是内部拦截入口。我随后把用户端的填充色改成了绿色系并在图例里注明绿色代表外部角色这样新人一眼就能分清边界。第二个反馈是异步链路没有表达出先后顺序。我最初画了支付服务发事件、事件中心订阅、订单服务消费三个要素但三者在图上位置松散读者看不出时间上的先后。于是我用编号标注的方法在虚线箭头上加了带圈数字序号明确表达1 发事件2 订阅3 消费的先后关系。这个小小的改动让异步链路的理解成本大幅下降。第三个反馈来自一位经常排查线上问题的同事他说你这张图对新人友好但对我这种要定位故障的人缺信息消息队列里的死信、重试、补偿都画哪里了我当时的回答是这张图就不该承载那部分功能但这也启发了我另一件事不要试图在一张图里满足所有人的所有诉求。最终我在文档体系的规划里明确区分了两类图——系统认知图和排查流程图各司其职。这件事让我深刻体会到图和任何设计产物一样服务好一个核心受众就够了想讨好所有人最后一定什么都不到位。5. 沉淀复盘模板库、检视清单与高频坑位5.1 把高频结构沉淀成参数化模板实战跑完几轮之后diagram-design 进入了一个新的阶段把重复劳动变成模板调用。我积攒了十几张不同系统的架构图、流程图、时序图之后发现虽然业务千差万别但图的骨架结构高度相似。于是我开始提炼模板把变化的部分用变量替代把不变的结构固化成模板。说个具体的例子分层架构图的模板把内容抽象为四个分组接入层、应用层、支撑层、数据层。变的部分只有两个层名和每层的具体服务。使用时改一份 JSON 配置脚本就能自动生成一张图。这样的模板为团队产出带来很大价值同样的工作原来画一张图需要半天现在大概十分钟就能生成初稿剩下的时间都在打磨和评审。做模板有一个关键心得不要一开始就把模板设计得面面俱到。第一版模板只抽象主干结构用到第五、六次时再根据实际使用情况把出现频率高的场景加进去。过早追求抽象往往会把模板做得又复杂又不容易使用。diagram-design 的第一版架构图模板只有三个分组、五六个节点迭代了三个月之后才逐步丰富到现在的形态。5.2 每次出图前过一遍的八项检视清单项目沉淀里最容易被低估的是一份检查清单。它不教你画图但它可以有效拦截那些看着还行但其实有问题的图。我把自己踩过坑的关键点整理成了八个问题每次出图之前逐条过一遍这张图的受众是谁他是否已经具备足够的背景知识这张图要解决的核心问题是什么图里有没有一条一眼可辨的主链路图型选对了吗流程信息有没有用架构图表达等其他选型错误的现象信息层级是否清晰标题区、主视觉区、注释区是否分工明确箭头和图元是否都有图例实线、虚线、不同颜色分别代表什么颜色是否在传达语义还是单纯为了装饰文字字号层级是否可控有没有字被压扁、截断、重叠的情况输出格式是否匹配使用场景嵌入文档、演示还是在聊天工具里查看这八条清单看起来平淡但实战中拦截率非常高。我记得有一次团队用模板生成了一张部署架构图结构完全正确、配色也符合规范只有一条箭头没有图例。同事看完图后只能靠猜去理解实线和虚线的区别这张图就因此在评审中被打了回票。清单存在的意义就是让这些低级但要命的疏漏能体系化地被拦截住。5.3 几个反复踩过的坑以及绕过去的办法最后分享几个在 diagram-design 项目过程中反复踩过的坑这些坑不只在画图时会出现在写文档、做 PPT、甚至做 UI 设计时都有共性。第一个坑是一张图吞下所有信息。前面说过很多次但它是所有坑里最顽固的一个每个人都会抱有画全一点总是好的的侥幸心理。绕过办法只有一个也是最有效的设图幅上限。我在团队里约定一张标准技术架构图的宽度不能超过一页文档展开的宽度逻辑上不能超过 15 个左右的核心节点。超出上限就拆分绝不通融。这个硬性限制逼着每个人做取舍效果可以说是立竿见影。第二个坑是命名不一致。同一件事图里叫订单中心旁边注释里叫订单域文档正文里又叫订单服务三个词指同一个东西但读者会以为是三个。解决方法是画图之前先列一张术语对照表把全图涉及的核心名词统一列表然后在图里注释放置处旁标明术语定义见注释。这张表还可以顺便给图里的每一个缩写补上全称防止新人被缩写劝退。第三个坑是箭头方向随心所欲。有些图一半箭头从上往下一半从下往上还有从右到左的读者的视线就会来回乱跳。我的习惯是统一主方向业务类的图从上到下或从左到右数据流向的图保持一致反方向的链路必须用不同线型并配合图例说明否则就折叠到注释里。第四个坑是沉淀断档。一图画完扔进文档再也没人维护。几个月后系统改了图却没有跟着改新人看旧图反而比没图更误导。解决办法是在图旁加一个维护信息栏标明最近一次更新时间、维护人和维护频率。每次系统评审顺手把关联的图一起过一遍这可以避免图腐烂的概率在团队内大幅下降。做 diagram-design 这个项目我自己最大的变化不是画的图变好看了而是画图之前多想了一分钟。现在不管是画系统架构图、业务流程图还是给新人准备的技术概览我都会先问一句这张图到底要让谁看懂什么。这句话一次次的重复比任何技巧都更管用。最后留一个小习惯每次画完图别急着发出去先把它发给一个完全不熟悉背景的人让他在 30 秒内讲出这张图的主链路。如果讲不出来那就别问他为什么看不懂回去改图吧因为问题大概率出在图自己身上。