先说个真事儿。上周评审会上，某同事贴了一张系统架构图，密密麻麻七八十个框，五颜六色，线缆密得像电路板。我指着其中一条虚线问：“这条线是什么意思？”他愣了几秒，说：“大概是依赖关系吧。”那一刻我意识到，很多人做 diagram-design 时，把精力全花在了“画得全”上，却完全没想过“画得懂”。
这几年我经手过不少图表设计工作，从技术架构图、数据流图、部署拓扑图，到给管理层汇报用的概念图。说实话，画图这个动作本身很简单，难的从来都是画图之前的信息梳理和画完之后的校验确认。今天这篇，我打算把做 diagram-design 的一套完整方法论捋一遍——怎么拆需求、怎么排结构、怎么选工具、怎么避坑。不管你用的是拖拽工具还是代码化方案，这套思路都适用。适合所有需要画图表达复杂信息的人：架构师、研发、产品经理、技术文档工程师，以及所有被“图乱得像蜘蛛网”困扰过的朋友。
1. 图表设计不是画图，是信息架构设计
1.1 为什么很多图“看着很专业，其实看不懂”
大部分图出问题，不是因为作者不专业，而是因为作者把“设计图”当成了“记录图”。记录图的目的是把所有东西都放进去，设计图的目的是让读者在一个可预期的时间内抓住核心信息。这两种目标有着本质冲突。
我总结了一下，看不懂的图通常有四个通病。第一是元素平权：所有框一样大小、一样颜色、一样粗细，视觉上没有主次，读者不知道该先看哪。第二是线条语义混乱：实线、虚线、点线、带箭头的、不带箭头的混在一起，而且没有任何图例说明，全靠读者猜。第三是缺少叙述顺序：一张图里既有业务流程又有部署拓扑，既有逻辑服务又有物理节点，读者进来找不到阅读起点。第四是信息密度失控：一张图硬塞四十个节点，投影之后字比蚂蚁还小，手机上看直接糊成一团。
这些问题的根子都在信息架构层面，而不是视觉层面。就像盖房子，墙面歪了不是因为油漆刷得不好，而是结构梁歪了。你花再多时间调颜色对齐框，也救不了一张信息架构混乱的图。
1.2 把图表设计拆成三个层次：信息、结构、视觉
我从一开始做 diagram-design 就养成了一个习惯：把一张图的设计过程拆成三层，逐层推进，绝不混着做。
第一层是信息层，回答“这张图要表达哪些事实”。比如这张架构图里有哪些系统、哪些服务、哪些存储，它们之间有哪些调用关系、依赖关系、数据流转关系。这一层是纯内容问题，和绘图工具完全无关。
第二层是结构层，回答“这些事实怎么编排才合理”。哪些信息是主干，哪些是分支；哪些需要突出，哪些可以弱化甚至省略；彼此之间按什么逻辑摆放——是上下分层的部署结构，还是从左到右的数据流。这一层决定图的骨架。
第三层才是视觉层，回答“用什么颜色、线型、布局方式让读者最省力”。统一框的样式、定好配色语义、控制箭头方向一致性、设置合理留白。
很多人习惯一开始就打开工具拖控件，等于把三层一次性混着做。结果是画到一半发现信息不对，又要重排结构，视觉上越改越乱。正确做法是把前三步放在纸上或用笔记大纲完成，确认信息层和结构层没问题之后，再开画布。
1.3 一张合格图的五分钟检查清单
我把自己检查一张图是否合格的标准固定成了一张清单，每次画完都过一遍。
| 检查项 | 合格标准 | 不合格表现 |
|---|---|---|
| 主视觉识别 | 读者5秒内能找到最核心的框或路径 | 所有框一样抢眼，看不出焦点 |
| 图例完整性 | 图中出现的线型、颜色、图标都有说明 | 虚线点线混用，无任何图例 |
| 阅读起点 | 有明确的入口和视觉流向 | 图上任意位置都能开始读，但读哪都对 |
| 信息密度 | 一级元素在7个左右，不超过12个 | 密密麻麻，缩略图直接糊掉 |
| 线型一致 | 同一语义只用一种线型 | 实线表示调用，在另一处又表示部署 |
| 色彩语义 | 颜色数量在5种以内，同色同义 | 彩虹图，颜色纯装饰 |
| 可读性 | 导出后在手机屏幕和投影上都能看清 | 最小字号低于8号，投影后完全看不清 |
| 省流版本 | 有30秒讲述版和5分钟阅读版 | 只有一版，给谁都是同一张图 |
这套检查清单治好了我“画完自我感觉良好”的毛病。很多图在不看清单时觉得还行，一行行对照下来才发现到处都是问题。
2. 动手前最重要的一步：需求拆解与元素清单
2.1 先搞清三个问题：给谁看、在哪看、解决什么
我见过太多人画图之前只问一句“帮我画个架构图”，然后就开始动手。这样画出来的图，往往不是读者需要的。
建议在动手前先花十分钟回答三个问题。第一，这张图的读者是谁？研发同事关注模块边界和接口关系，管理层关注系统能力和风险，新同学关注整体框架和入门路径。读者不同，图上应该突出的东西完全不同。第二，这张图在哪被看？PPT演示时要粗粒度、大字、少元素；技术方案文档里可以细到接口名；白板讨论时则只需要粗糙的框和线。第三，这张图要促成什么决策？是评审架构方案、排查性能瓶颈、还是安排开发计划？不同的决策目标，决定了信息的裁剪方向。
这三个问题没有想清楚，后面所有细节都是浪费。有一次我为某跨平台系统画部署图，第一版把所有中间件、端口、心跳机制全画上了，结果评审会上老板只关心一个问题：“这套系统的故障域是怎么划分的？”我那版图一屏要塞下所有信息，唯独没突出故障域边界。后来重画，删掉大部分中间件细节，用三个虚线框把故障域画清楚，会议十分钟就通过了。
2.2 用“名词-动词”法梳理核心元素
梳理信息时我强烈推荐一个笨办法：先写名词，再写动词。这个做法简单粗暴但极其有效。
名词就是图上要出现的所有“东西”：系统、模块、服务、数据库、外部依赖、角色等。你把这些名词全部列出来，写在一张纸上。动词就是这些“东西”之间的动作：调用、写入、订阅、推送、认证、读取、同步。每个名词和动词都要写下。
列完之后做两道减法。第一道减法：如果一个名词不在你想要表达的核心故事里，删掉。某跨平台系统开发时，我把监控系统、日志采集、消息队列全列上了，后来发现这张图想表达的是“用户请求从发起到落库的主链路”，消息队列只是旁路，果断删掉。第二道减法：如果一个动词在图上出现了超过五次，考虑用分组或聚合来简化，否则这张图的线会密到没法看。
写名词和动词的时候千万别打开画图工具。一旦打开工具，你的注意力就会被对齐、颜色、布局带走，信息梳理这件事会做得非常潦草。在纸上用纯文字列清单，比在画布里拖框高效十倍。
2.3 定主视觉层次：一张图只说一件事
信息清单列完之后，还要做最后一件事：给信息定级，确定主视觉层次。
原则很简单——一张图只有一个核心焦点。如果这张图的核心故事是“请求的完整流转”，那么最重的主视觉就是那条贯穿全图的调用链，其他一切都是背景。如果核心故事是“系统的分层架构”，那么主视觉就是那几条横向分组线，以及每一层的核心组件。
定级时我会把信息分成三等。一级信息是那张图的主干，要用最大视觉重量，比如最深颜色、最粗线条、最核心的版面位置。二级信息是必要的支撑细节，视觉上要明显弱于主干，比如用浅色框、细线、次要位置。三级信息是参考性内容，比如具体的端口号、实例数量、配置参数，直接塞进注释或备用说明区，不要放进主图。
这张图的每一层都要有明确的信息层级。做完这一步，你手里拿着的已经不是一堆素材了，而是一张可以照着画的“图纸”。
3. 代码化绘图的思路与工具选型解析
3.1 为什么我推荐用代码而不是拖拽来画核心图表
工具选型上，我最终选择了代码化绘图作为主力方案，拖拽画图只留作快速草稿。原因不是“代码比鼠标高级”，而是代码化在工程实践上的优势太大了。
第一是版本管理。做 diagram-design 的同行应该都有体会，一张架构图定稿之后不可能不改。方案一变、服务拆分一调整，图就要跟着改。拖拽画图工具的原始文件通常是二进制或私有格式，git diff 完全不可读，改过什么只能靠猜。而代码化绘图的源文件是纯文本，每次改动都能通过 git diff 清晰看到：谁在什么时候加了一条线、删了一个节点、改了一个文案。对于团队协作来说，这一点价值无可替代。
第二是可复用。拖拽画图很难把一套统一风格沉淀下来，每次画图都重新调一遍颜色和字号。代码化绘图可以把主题、公共节点、公共组件抽出来定义一次，之后所有图引用同一个定义。我们在某跨平台系统里沉淀了一套公共主题：框架层的颜色、业务服务的形状、外部依赖的描边样式，全部统一定义。后续新增任何一张架构图，直接引入这套主题，视觉风格天然一致。
第三是可讨论。代码化绘图的源文件可以被评审，可以在代码评审里被提意见——“这里不应该有一条实线，应该是异步消息”。架构图和代码一样能被 review，这件事在拖拽工具时代几乎是不可想象的。
3.2 主流的代码化绘图工具对比
这里我把常见的几种代码化绘图方案放在一起对比，方便你按需选型。
| 工具 | 上手难度 | 布局能力 | 输出格式 | 最适用场景 |
|---|---|---|---|---|
| PlantUML | 低 | 中（自动布局够用） | PNG/SVG/ASCII | UML 图、架构图、时序图、部署图 |
| Graphviz/DOT | 中 | 强（节点布局算法丰富） | PNG/SVG/多种格式 | 复杂节点关系图、依赖图、流程图 |
| D2 | 低 | 中（布局现代美观） | SVG/PNG | 现代架构图、网络拓扑图 |
| 文本手绘（ASCII/Box-drawing） | 极低 | 无（完全手动） | 文本 | 文档内嵌草稿、代码注释里的示意图 |
| 画布类工具 | 低 | 强（完全手动自由） | 导出图片/PDF | 白板讨论、快速草图、与不懂代码的人协作 |
我个人日常用得最多的是 PlantUML 和 Graphviz。PlantUML 语法对工程背景的人几乎零门槛，组件图、部署图、时序图一套语法全覆盖；Graphviz 胜在布局算法，节点特别多、关系特别复杂时，它能自动排出相对可读的布局方案，而 PlantUML 在这个场景下经常束手无策。
不过工具只是手段。我给个建议：别在工具选择上耗太久。先选一个语法最顺手的，把画图方法论跑通，再考虑要不要换。工具永远是次要的，架构能力才是核心。
3.3 版本管理、组件复用与团队协作
代码化绘图真正厉害的地方在于，它能像代码一样被管理和协作。我把这套工作流叫作“图表即代码”。
在团队协作中，我们做三件事。第一是全部图表源文件入库，走 git 管理，和代码库放一起。每次文档更新、架构变更，图表同步更新并提交变更记录。第二是建立公共组件库，把常用节点、主题、图例定义集中放在一个公共文件里，各张图引用这份定义。比如“数据库”节点长什么样、“外部系统”怎么描边、“用户请求”用什么样式，全部统一。第三是写一个简单的导出脚本，在需要发布文档时一键渲染出 PNG/SVG，保证文档里嵌的图和源文件是对应的。
这套流程做起来后，团队里再也没出现过“文档里的架构图和实际系统对不上”的情况。以往这是所有技术文档的通病——图画完就没人维护。现在源文件躺在代码库里，和代码一起演进，图永远不会过期。
3.4 什么时候拖拽工具依然更合适
代码化绘图不是万能的，我也不会把所有场景都往代码化上凑。
快速头脑风暴时，拖拽工具或直接白板手绘依然是最高效的。这种场景的核心是“把想法快速摊开”，而不是“表达准确信息”，代码化绘图反而会成为思想流动的阻碍。和白板工具画草图，让想法快速流动起来，比什么方式都强。
和完全不懂技术的人协作时，拖拽工具也更合适。比如产品同学在白板上理解业务流程，用画布工具现场拖，能实时互动修改，代码化绘图还要改源文件重新渲染，交互上天然吃亏。
所以我的原则是：产出需要进文档、需要长期维护、需要多人协作的正式图表，走代码化；临时讨论、探索思路、跨角色互动沟通，用拖拽工具或白板。工具服务于场景，别本末倒置。
4. 从零设计一张系统架构图的完整实操流程
这一节我用某跨平台系统中的“订单服务架构图”作为案例，带你把完整流程走一遍。
4.1 第一步：先写信息清单，不开画布
我首先在文档里写下名词清单：用户App、接入网关、订单服务、支付服务、库存服务、消息队列、订单数据库、日志服务、外部支付渠道。
然后写动词清单：用户App发起下单请求、网关转发、订单服务调用支付服务、订单服务扣减库存（通过消息队列异步通知库存服务）、支付服务调用外部支付渠道、订单服务读写订单数据库、订单服务异步投递订单状态到消息队列、日志服务收集所有链路日志。
写完开始做减法。这张图的核心故事是“下单请求从发起到订单落库的主链路”。外部支付渠道属于第三方依赖，可以画成外部边界；日志服务不是主链路，在这张图里直接省略。最终留下七个名词：用户App、接入网关、订单服务、支付服务、库存服务、消息队列、订单数据库。
这里有个硬性建议：一张图的一级元素尽量不要超过七个正负两个。人脑的工作记忆容量大概在七个左右，超过这个数，读者的认知负担会急剧上升，图就会“看起来乱”。如果你的系统确实很复杂，那就拆成多张图，一张主图加若干细节展开图，别指望一张图装下全世界。
4.2 第二步：确定布局方向与分组策略
信息清单确定后，开始排结构。这张图我选用了从左到右的布局方向——这是数据流图最常用的布局，因为人类阅读习惯从左到右，用户请求从左边发起，一路向右流转到数据落库，叙事顺序天然吻合。
布局方向选型的逻辑是这样的：数据流和调用链主导的图，用从左到右；分层架构和部署结构主导的图，用从上到下，因为上层通常是接入层，下层是数据层，竖向排列更直观；带核心和外围的概念图，用中心向外的布局，突出核心系统，外围是依赖和生态。选布局方向要考虑图想表达的叙事逻辑，让视觉方向和信息逻辑保持一致。
分组上，我在图上加了两个边界框。第一个框圈住订单服务、支付服务、库存服务、消息队列和订单数据库，命名“核心业务域”；第二个框只圈住用户App和接入网关，命名“接入层”。这样读者一眼就能看出哪些是内部组件、哪些是边界组件，系统边界一目了然。
4.3 第三步：统一样式语言
结构和布局定了，接下来才是视觉。我的样式语言遵循三条铁律。
第一条，颜色语义固定。蓝色系表示服务组件，灰色系表示外部依赖或第三方系统，绿色系表示正常状态或数据存储，橙色系表示待建设或规划中的组件，红色系只用于异常和警示路径。
第二条，线型语义固定。实线带箭头表示同步调用，虚线带箭头表示异步消息，点线表示数据依赖或配置依赖，无箭头实线表示静态包含关系。整张图里，这些线型的含义全局一致，不能换场景就变。
第三条，文字和框的规范固定。框内文字用标准字体，字号统一，动词标注在线上，名词标注在框内。箭头不出现双头，表示方向性调用。如果一个关系确实不需要区分方向，就用无箭头线。
基于这些规范，在工具里用代码来表达这张图。比如用文本化定义语言描述核心结构，大概长这样：
用户App --> 接入网关 : 下单请求 接入网关 --> 订单服务 : 转发请求 订单服务 --> 支付服务 : 发起支付 支付服务 -->> 外部支付渠道 : 调用支付 订单服务 --> 订单数据库 : 读写订单 订单服务 --> 消息队列 : 投递订单状态消息 消息队列 --> 库存服务 : 异步通知扣库存这一版描述里，同步调用用实线箭头，异步消息用虚线箭头，外部依赖用了跨边界的灰色描边。整个结构读起来清清楚楚。
4.4 第四步：迭代与评审
初稿只花了十分钟就导出来了，但真正费时间的是迭代和评审。我的迭代节奏是至少过三轮。
第一轮，对照最初的信息清单自查。看看有没有漏掉核心关系、有没有混入无关信息、线型语义有没有用对。这轮主要是防漏和不偏离主干。
第二轮，做“过曝测试”。把图缩小到缩略图尺寸，看还能不能辨认出主路径。如果缩略图上一团模糊，需要放大才能找到主流程，就说明一级信息的视觉权重不够。这时候把主链路上的线加粗、颜色加深，把背景浅化，强化对比。
第三轮，找一位对业务不熟的同事做“盲读测试”。让他只看图、不看说明，然后讲出他从图上读到了什么。如果他讲的三个要点和你原定的一级信息吻合，这张图就合格了。如果不吻合，说明图里有些元素在“抢戏”，要么弱化它们，要么直接删掉。
在项目里，我专门把“盲读测试”设为定义完成的必须环节。图上画了什么，和读者读到了什么，永远是两回事。你要验证的是后者。
4.5 演进对比：从信息堆砌到一张可读的图
我拿出这张架构图的真实演进过程，你感受一下差异。
第一版就是典型的“信息平权图”：八个框用同一颜色、同一大小，横平竖直排成两排，线全部是黑实线带箭头，没有任何图例。这版图信息量完整，但没有人能快速说出主链路，而且所有节点视觉重量完全一样，像一张躺平的通讯录。
第二版做了一次结构优化：把用户App和接入网关划进“接入层”边界框，把核心服务划进“核心业务域”边界框，外部支付渠道移到灰色区域表示外部依赖。从这版开始，图有了系统边界的感知。
第三版做了视觉深化调整：主链路加粗并用深蓝色，异步消息改为虚线并配上图例，外部依赖整体灰化，分组框用浅底色。这一版完成了从“信息完整”到“信息清晰”的转化。
第四版反而做减法：去掉图例区直接改成标题下方一行注释，把两条不重要的旁路关系折叠进注释里。这版才是最终交付版，所有人看它，第一眼都能找到主链路，第二眼能理解系统边界，第三眼才注意到次要细节。一张好图就是这样一层层“减”出来的。
5. 常见问题与排查技巧实录
5.1 常见问题速查表：图怎么就是不理想
做 diagram-design 这么久，我整理了遇到频率最高的几类问题和对应解法。
| 现象 | 根因 | 解法 |
|---|---|---|
| 图里线多得像蜘蛛网 | 关系没做聚合，一级关系太多 | 引入中间节点或分组，把多对多改成结构化关系 |
| 读者看完抓不住重点 | 元素平权，无视觉分层 | 重梳信息清单，定一级焦点，强化主干弱化配角 |
| 图很漂亮但看不懂 | 视觉先行，结构未梳理清 | 删掉视觉装饰，回到信息-结构-视觉三层流程 |
| 文档里的图和实际系统对不上 | 图没有持续维护机制 | 图表代码化，入版本管理，与代码一起演进 |
| 同一套系统不同图风格不一 | 缺少公共主题和组件定义 | 沉淀公共样式库，所有新图引用 |
| 每次改动牵一发动全身 | 元素间关系耦合过紧 | 拆图：每张图只讲一件事，细节图单独展开 |
这张速查表我直接贴在工作文档里，每次遇到图的问题先查表再动手，比凭感觉改高效得多。
5.2 “图太乱”的根因：布局问题还是信息问题
处理过最多的求助是“我这图怎么调都不好看”。每次我接手一看，发现问题根本不在布局算法、不在配色方案，而在信息层没有梳理清楚。
举一个典型例子：一张图里三个服务和两个数据库之间，画了十二条线表示各种查询关系。这种“多对多”的关系用网格状表达出来，再强的布局算法也排不乱。正确的做法是引入一个“数据访问层”的中间节点，让三个服务和两个数据库之间的交互收敛成：服务→数据访问层→数据库。十二条线变成了五条线，图瞬间就清爽了。
这就是我常说的：图上每多一条线，读者的阅读成本不是线性增长，而是指数增长。所以控制线条数量的最好方法不是调布局，而是重构信息结构，把多对多变成树状或星状。遇到图乱的求助，我几乎从来不给“把箭头缩短一点”“调整节点间距”这类建议，那些都是治标不治本。真正有效的是重新审视这张图到底依赖了多少关系，这些关系哪些是主干的，哪些是可以聚合的。
5.3 怎么自查一张图是否“合格”
除了刚才提过的“盲读测试”，我还有一个很笨但有用的自查方法：打印测试。把导出的图直接打印到一张A4纸上，距离一臂远看整体轮廓，然后再贴近看细节文字。
一臂远看不清主路径，说明视觉层次分布有问题；贴近了看不清节点文字，说明字号太小或导出分辨率不够。这个物理层面的测试，比在屏幕上放大缩小更能暴露真实问题。因为你的读者，大多数情况下只能在一张A4纸或一页PPT上读完你的图。
还有一个更狠的测试：只给图不给标题，发到群里让大家猜这张图讲的什么。如果十个人给的答案基本一致，说明你的图是自己会说话；如果十个人十个答案，说明信息架构完全失败了。我团队里现在把这类测试当成图表的门禁检查，过不了就重新画。
5.4 团队协作中图表管理的三个坑
单打独斗时图的问题还挺好解决，真正麻烦的是团队协作时的图表管理。我碰到过三个印象深刻的坑。
第一个坑是同一个组件在不同图里画得不一样。架构图里某个服务在文档A里是蓝色的，在文档B里是绿色的；在文档C里叫“订单中心”，在文档D里叫“订单域”。读者对照多张图看时会非常困惑。解法就是前面说的公共组件库加统一命名规范，在所有图里共用同一套定义和命名。
第二个坑是线型语义在团队里没有统一约定。一个人用实线表示进程内调用，另一个人用实线表示网络调用，图放在一起看就是灾难。解法是团队约定一个线型标准并写进文档规范，作为强制要求。
第三个坑是图过期无人维护。架构图最怕“画完就忘”。开发同学改完代码不会同步改图，等三个月后文档里的图已经和系统南辕北辙。解法就是图表代码化，和代码仓库放一起，代码评审时要求图和代码同步更新。图一旦和代码进了同一个变更流程，它就不会过期。
6. 图表设计实战心得：让图真正活起来
6.1 每张图都要有一条“阅读路径”
我第一次被前辈指出“你的图没有引导”，是在某次方案评审会后。他说：“这图我看了半天，眼睛不知道往哪走。”这句话我一直记着。
好的图本质上是视觉叙事。一张图应该有一条明确的阅读路径，像讲故事一样带领读者：先看这里，再看那里，最后看结论。实现路径的手段有很多：把主链路加粗并用深色，让读者的视线第一时间被吸过去；用颜色深浅做层次，深色的先看，浅色的后看；用分组边界引导视线流，先看大边界里的主结构，再看角落的辅助细节。
每次画完图，我都会问自己一个问题：这张图的第一主角是谁？如果答案清晰，而且它在视觉上确实最突出，那这张图基本就成功了。如果第一主角说不出来，或者说出来之后发现图上最醒目的其实是另一个框，那就继续改。
6.2 我踩过的几个大坑和修正
分享几个我真实踩过、改了又改才修正过来的问题。
第一个是“渲染依赖症”。早期我画图严重依赖工具自动布局，节点一多，自动布局就把节点排得乱七八糟，我心说“算了，勉强能看”。后来想通了：自动布局的目标是“节点不重叠”，不是“语义清晰”。要真正控制语义布局，必须手动指定分组和位置，不能完全把布局交给算法。现在我的习惯是先用自动布局得到初步结构，再手调分组和主路径走向，保证语义优先。
第二个是“贪多”。早期画架构图恨不得把所有中间件、所有依赖、所有端口全部画上，觉得少画一个就是不专业。结果图越画越密，读者越来越看不懂。后来被教训多了才明白，专业不是把信息全堆上去，而是知道该舍掉哪些信息。现在我的默认策略是：画完第一版，主动删掉三分之一信息再做一次减法，图的质量会立刻上一个台阶。
第三个是“色彩失明”。有段时间我特别喜欢用红绿色表示状态，后来一位同事告诉我他有红绿色弱，这张图在他眼里等于没有状态区分。从那次之后，我的图纸里，状态区分除了颜色还叠加线型或图标符号，确保不依靠颜色也能读图。这是个细节问题，但做 diagram-design 的人真的应该把色弱友好当成常识。
6.3 从画好一张图，到建好一个图表体系
做到后期，我逐渐意识到，单张图画得再好，价值也有限。真正能让图表在团队里持续产生价值的，是把“画图”变成“建体系”。
体系具体落地是三件事。一是建立模板库：把团队常用的架构图、流程图、时序图模板沉淀成公共文件，新图画得飞快，风格天然统一。二是建立命名规范：图名、文件、节点命名、图例位置，全部有固定约定，避免各画各的。三是建立视图矩阵：同一个系统，按不同读者和场景拆成多张视图——逻辑架构视图给研发、部署拓扑视图给运维、概念架构视图给管理层。这些视图共享组件定义，信息一致但视角不同，就是一套完整的图表体系了。
做这件事的时候有个体会很深刻：建体系的成本比单画一张图高很多，但回报是长期的。一张图用一次就过期，一套体系能支撑团队把所有文档持续更新下去。做 diagram-design 这几年，我最大的体会是，画图从来不是画画，而是想清楚之后的一次输出。把信息梳理明白，把结构排布清楚，让视觉服从于语义，这样的图才真正是把复杂变简单的工具。如果你也在画图这件事上挣扎过，希望这篇能帮你少走几个弯路。
