开头部分可以直接抛出标题背后的核心问题很多技术方案、系统设计、汇报材料之所以看起来“差口气”问题往往出在图上。diagram-design不是一个现成的开源项目名字而是一类工作的总称——把系统结构、业务流程、数据关系画清楚的能力。这个标题背后涉及的是一整套图表设计的思路、工具链和落地规范。这篇文章我就围绕“怎么把一张技术图画专业、画明白”这件事把从设计思路到工具选型再到实操落地的经验一次说清楚。适合来看这篇内容的读者我觉得有三类一是经常要画架构图、流程图但总觉得画出来不够专业的开发者和架构师二是做技术方案、项目汇报时需要配图但不想在图上花太多时间的项目负责人三是对可视化表达感兴趣想建立一套自己的图表设计方法的人。无论你是哪一类这篇文章想解决的核心问题只有一个——让图表真正成为你表达想法的武器而不是拖后腿的累赘。1. 内容整体设计与思路拆解1.1 diagram-design到底在解决什么问题很多人对画图这件事有个误解觉得图嘛能看懂就行画得差不多就可以了。但如果你真的在技术方案评审、系统故障排查或者跨团队协作中吃过亏就会发现一张不够严谨的图带来的麻烦远超想象。我自己见过最典型的例子是一个微服务架构图上下游箭头画反了结果新来的同事按照图去排查调用链查了整整两天才发现是图本身错了——这种时间成本远比当初多花半小时画对一张图要高得多。diagram-design这个主题本质上是在解决三个层面的问题第一层是信息组织问题。你在画一张架构图之前脑子里其实装着大量信息系统有哪些模块、模块之间什么关系、数据怎么流转、依赖方向是什么、哪些是核心链路哪些是旁路逻辑。把这些信息梳理清楚本身就是一个很好的思考过程。很多时候图画不清楚不是因为画图技术不行而是因为你对要表达的内容还没想明白。第二层是视觉传达问题。同样一张系统架构图有的人画出来一眼就能看懂重点在哪、链路怎么走有的人画出来就是一堆框框和线条的堆砌。差别在哪里在于对视觉层次的理解——大小、颜色、间距、对齐、分组这些视觉元素都在传递信息。图不是把信息画上去就完了而是要让读者用最少的认知成本获取最多的有效信息。第三层是协作沟通问题。图纸在技术团队里往往承担着“通用语言”的角色。后端看架构图理解系统边界前端看流程图理解交互逻辑运维看部署图理解服务拓扑测试看时序图理解调用关系。一张规范清晰的图能让整个团队的沟通效率提升一个档次。反过来一张混乱的图就是团队里一颗随时会引爆的沟通炸弹。1.2 为什么值得为画图这件事建立方法论我见过不少工程师包括早期我自己在内画图都是“说到哪画到哪”——先拖几个框出来然后连线然后发现布局乱了又重新拖一遍再连线最后勉强弄出一张能看的图就赶紧交差。这种方式最大的问题不是效率低而是你永远无法稳定地产出高质量的图。稳定产出高质量的东西靠的是方法论而不是灵感。就像写代码要有代码规范一样画图也需要一套自己的规范和流程。这套流程大致是明确受众和目的 → 梳理信息结构 → 设计视觉层次 → 选择布局方式 → 动手绘制 → 审查优化。每一步都有可执行的标准和技巧而不是靠感觉。建立方法论还有一个额外的好处——可复用。当你把常用的一些图表模板沉淀下来之后再画类似的图就不是从零开始了。比如我给自己搭了几套固定的模板系统架构图模板、部署流程图模板、数据流转图模板、时序交互图模板每次要画相关类型的图直接基于模板改就行省时省力而且风格统一。这个方法论的框架也是这篇文章的主体脉络。接下来我会按照实际操作的顺序把每一环节的关键细节和实操要点拆开来讲附带具体的案例和操作截图级别的文字说明让读者能直接照着执行。2. 图表设计核心原则与实操要点2.1 先搞清楚受众和目的再决定画什么这是我画图的第一条铁律先想清楚给谁看、要达成什么效果再决定图画什么、画多细。很多人一上来就打开工具开始画结果画到一半开始纠结某个模块要不要画进去、某个细节要不要标注——这些纠结本质上都是因为前期没想清楚。给不同受众看的图颗粒度要求完全不一样受众类型典型场景图的颗粒度关注重点技术团队内部代码评审、架构讨论细可以到类、方法级别调用关系、依赖方向、边界划分跨团队协作前后端联调、业务对齐中到模块/服务级别接口定义、数据格式、交互流程项目管理层项目汇报、方案评审粗到系统/平台级别整体框架、关键路径、风险点客户/外部交付说明、产品介绍更粗突出价值业务能力、整体架构、安全可靠实操经验告诉我同一个系统通常需要准备至少两张不同颗粒度的图。一张偏技术细节给研发团队内部看一张偏整体概览给管理者和协作方看。不要试图用一张图满足所有受众的需求结果往往是谁都看不舒服。目的决定了图的表达侧重点。如果图是为了说明系统改造前后的差异那么左边画“改造前”右边画“改造后”中间用箭头或对比标注强调变化点。如果图是为了排查线上故障那么要把调用链路径和监控指标标注清楚而不是把页面也画进去。如果图是为了方案评审那要把决策点和备选方案标注出来让评审者能快速定位到需要拍板的地方。2.2 信息结构梳理画图之前先列清单在打开任何绘图工具之前我强烈建议你先花十到十五分钟在纸上或者在文档里列一个信息清单。这个清单不需要很正式但一定要把下面几类信息列清楚第一类是实体清单。这张图里需要出现哪些“东西”如果是架构图那就是各个服务、组件、存储如果是流程图那就是各个步骤、决策点、分支如果是时序图那就是各个参与对象。这个阶段宁可多列也不要遗漏后面再筛选哪些该上图画出来。第二类是关系清单。实体之间的关系是什么A依赖BA调用BA包含BA与B平行并列A是B的一种类型甚至有些关系是A在某个条件下才跟B发生交互。把所有关系整理出来你会发现很多之前没想清楚的逻辑被逼着理清了。第三类是重点清单。这张图最想让读者记住的一到三个信息点是什么是系统的高可用架构是数据流向还是接口的调用时序把重点拎出来后面所有设计决策都围绕重点来展开不容易跑偏。这三份清单列完之后信息结构图就已经在脑子里成型了。这时候再去打开绘图工具你会发现自己不再是无从下手而是清楚下一步该画什么、往哪里摆。2.3 视觉层次设计让读者一眼看到重点视觉层次是专业图表和业余图表最直观的分水岭。业余图表的典型特征是所有元素大小一致、颜色相近、排列松散读者看完之后根本不知道该把注意力放在哪里。专业图表恰恰相反它在视觉上会明确地告诉你——先看这里再看那里最后看那里。构建视觉层次核心是三个手段大小对比。核心模块用大的框或大的字体次要模块缩小一号。这个逻辑跟报纸排版是一样的标题字号最大正文小字号读者一眼就能抓住重点。实操中我通常把核心模块的宽度做到次要模块的1.5到2倍字体重一两号层次感一下子就出来了。颜色对比。重点内容用高饱和度的颜色或者浅色系中的深色来突出非重点内容用灰色系弱化。这里有个很重要的原则颜色不要用太多整张图的主色控制在两到三个以内加上灰色做辅助就足够表达清晰的层次了。颜色一多立刻显得杂乱而且不同颜色在读者的下意识里会被理解成不同分类如果你本意不是做分类就会造成误读。留白控制。适当留白不等于浪费空间恰恰相反留白能让阅读节奏更舒适。两个模块之间的间距如果太紧读者容易把相邻模块看成一组间距拉大一点分组关系立刻就清晰了。我一般会把模块间的间距控制在模块内边距的两倍左右这个比例在视觉上最舒服。2.4 布局方式选择不同图类型有不同讲究常见的图表类型各有各的布局逻辑不能一张模板走天下。我根据自己的实操经验把主要类型和布局要点总结了一下架构图布局讲究分层和分区。最常见的做法是自上而下分层接入层 → 应用层 → 服务层 → 数据层每层用统一的背景色或虚线框框起来。同层的模块水平排列层级之间垂直排列。这个布局方式之所以经典是因为它天然符合人的阅读习惯从上往下看每一层的职责一目了然。流程图布局讲究主路径清晰。用一条从起点到终点的主线串起所有关键步骤分支逻辑用平行或嵌套的方式展开但主路径必须在视觉上最突出。这里有个实操技巧主路径可以用垂直排列分支路径放到右侧平行展开这样阅读路径非常顺畅读者永远不会迷路。时序图布局讲究时间轴要直。参与者头部水平排列时间线垂直向下。这个布局的难点在于消息线的交叉处理——一定要尽量减少交叉方法是调整参与者的排列顺序让交互频繁的参与者排在相邻位置。拓扑图布局讲究空间关系符合物理直觉。比如把一个机房里的设备关系尽量按照机柜的物理位置来排列把不同区域的节点按照地域分布来放置。这样做的好处是熟悉物理环境的同事看到图就能秒懂不需要额外脑补。3. 工具选型与实操过程3.1 主流绘图工具对比与选择建议工欲善其事必先利其器。画图的工具选择直接影响效率和体验这里我把主流的几类工具做一个横向对比方便不同场景下做选择。工具类型优势劣势适用场景draw.io / diagrams.net在线/桌面免费、模板多、支持多种格式导出UI偏朴素默认样式一般技术方案快速画图Excalidraw在线手绘风格、上手极快、协作方便不适合复杂技术图头脑风暴、早期草图Figma在线设计能力强、组件化、团队协作好学习成本较高、偏设计向对外展示的精美图Visio桌面专业级图表、模板丰富收费、臃肿、样式老旧企业标准文档PlantUML / Mermaid代码画图文本定义、版本可控、自动布局复杂布局受限、样式优化难代码仓库里的文档图Python (Graphviz/Matplotlib)代码画图自动化、批量生成、数据驱动交互调整不便数据可视化、自动生成文档我给不同场景的建议是日常技术方案、架构评审优先用draw.io免费、导出方便、协作分享也好用。需要快速头脑风暴、画草稿的时候用Excalidraw它那个手绘风格天然给人一种“这是讨论稿不是最终结论”的心理暗示反而更容易激发讨论。如果要做对外展示或者产品宣传级别的架构图值得花时间用Figma做精修。如果你习惯把文档放在Git仓库里那PlantUML或Mermaid是绝配——图和代码一起版本化管理改图就是改代码再也不会出现文档图和代码不一致的情况。我自己最常用的组合是日常技术图画用draw.io快速出草稿用Excalidraw存在代码仓库里的规范图用PlantUML对外精美的架构图用Figma。每个工具都有它的位置关键是用在合适的场景。3.2 实操案例从需求到成图完整走一遍光讲原则不够我拿一个真实场景走一遍完整的画图流程大家感受一下每一步是怎么落地的。需求背景有一个订单系统要做微服务拆分需要画一张目标架构图用于技术方案评审受众是技术委员会和几位核心开发。第一步信息清单。我先把目标架构的模块全部列出来API网关、用户服务、商品服务、订单服务、支付服务、库存服务、消息队列、订单数据库、商品数据库、用户数据库、缓存集群、日志服务、监控服务。然后列关系API网关统一入口各业务服务注册到网关订单服务调用用户服务、商品服务、库存服务、支付服务订单服务发送消息到消息队列库存服务消费消息各服务读写各自的数据库缓存集群被订单服务和商品服务共用日志服务和监控服务与所有服务有交互。第二步视觉层次设计。组织架构已经比较清晰了网关是入口属于接入层业务服务是核心属于应用层数据库、缓存、消息队列是基础设施属于数据层日志和监控属于平台层。这样一张图分四层层次很清晰。重点要突出的是订单服务的核心地位和消息队列解耦的机制。第三步工具操作。这次我用draw.io来画。操作顺序是这样的先新建一个空白图设置画布大小为宽1920、高1080这个比例在做方案投影时显示效果最好。然后通过菜单Shape → Add Shape选择需要的图形样式架构图我习惯用矩形带阴影的样式简单干净。第四步逐层画图。从上往下先画接入层放一个API网关的框用深蓝色填充字体白色居中显示“API Gateway”。然后在下方画应用层一排五个服务框用户服务、商品服务、订单服务、库存服务、支付服务其中订单服务的框拉大一号用橙色填充突出核心地位。再往下画数据层三个数据库框、一个缓存集群框、一个消息队列框用灰色填充弱化。最底部画平台层日志服务、监控服务并排同样灰色系但稍微深一号以示区分。第五步连接关系。用箭头工具连接各模块直线箭头表示同步调用虚线箭头表示异步消息。这一步一定要有耐心箭头方向绝不能错——我踩过最大的坑就是方向画反尤其在这种跨团队评审的场合一个反向箭头会让整张图的信任度大打折扣。连完之后我会整体检查一遍确保所有箭头都是目标方向。第六步审查优化。画完之后不要急着导出先自己当一次读者。从读者视角看图问自己几个问题第一眼看到的是不是核心的订单服务调用链能不能顺畅地跟下来消息队列的解耦作用是不是一眼就能看懂边界是否清晰如果哪个问题的答案是否定的就回去调整图形大小、颜色或布局。3.3 参数调整与细节优化技巧外观层面有几个参数值得单独说因为它们在视觉上影响极其明显。字体大小体系很重要。我一般会建立一个三级字号体系标题字号20pt、模块名字号16pt、辅助说明字号12pt。统一字号体系之后图的整体观感会非常整齐。如果一张图里的字号大大小小各种尺寸立刻就显得业余。连线样式也有讲究。直线走主要调用链路圆角线走柔和关系虚线走异步/间接关系。线宽方面主流是2px需要突出的链路可以用3px。颜色上普通线条用深灰色强调链路用品牌色或红色系。这里有一个容易忽略的点箭头的样式要统一要么都用实心箭头要么都用空心箭头不要混用。配色方案建议建立一套自己的色板。我常用的方案是主色深蓝 #2563EB强调色橙色 #F59E0B中性色浅灰 #F1F5F9 和深灰 #334155危险/异常色红色 #EF4444。这套色板可以存成draw.io的自定义样式每次画图直接调用不需要重新调色。颜色使用的核心原则是少而精用颜色的数量越少每一处颜色的信息价值就越高。3.4 从草稿到成品一次图表的完整演进实录画图很少能一次成稿我的经验是“先有再优”。第一版通常只求信息完整和关系正确不追求美观第二版开始调整布局和视觉层次第三版精修细节。这个过程我用上面的订单系统架构图实际走一遍。第一版草稿把所有模块的框拖到画布上连线标注文本。这一版的问题是模块位置随意排列层次感弱视觉上是平铺的一堆框。但这一步的价值在于信息结构已经完整关系都梳理出来了相当于写代码之前先搭好了数据模型。第二版优化按照接入层-应用层-数据层-平台层的结构重新排列。每个模块放到正确的层级区域用浅灰色背景框把每一层的范围圈出来并在每层的左上角标注层名。这一版已经基本成形了读者能看懂整体架构但视觉上还不够突出核心链路。第三版精修把订单服务的框放大一号橙色填充把核心调用链路的线条加粗改成深蓝色弱化非核心模块的颜色饱和度。再检查一遍对齐和间距。最终成图的视觉效果跟第一版相比完全是两个层次——核心一眼能看到层次分明调用路径清晰。这个演进过程其实是可以用在绝大多数图表上的通用路径。不要指望一次画完就完美也别在第一版上死磕布局细节先出草稿再逐版优化反而比一步到位画得更快更好。4. 常见问题与排查技巧实录4.1 越画越乱信息过载怎么处理我自己画图踩过最大的坑就是信息过载。尤其是画系统架构图的时候总觉得这个模块不画不完整那个依赖不标不清楚结果画出来满满一页谁也看不懂。处理这个问题最有效的方法是分层绘制而不是单图硬抗。把“系统总体架构图”和“订单模块详细时序图”分成两张图画。总体架构图只保留模块级信息和主要依赖关系时序图再画到方法级调用。这就跟地图软件一样——有全国总览图有城市街道图有具体路口的导航图但永远不会把三个层级揉在一张图上。如果确实需要在一张图里呈现多个层次可以用“分层着色”的技巧。用透明度递进的方式核心层完全不透明中间层半透明外围层用极浅的颜色。视觉上会自动形成焦点区域和背景区域的区分读者能自然地聚焦到核心内容上。4.2 对齐问题为什么我的图看起来“歪”很多人画完图总觉得哪里不对但又说不上来哪里不对——这个问题十有八九是对齐问题。模块之间没有处在同一水平线或垂直线间距大小不一文字和图形边界没有留足空间这些细节累积起来整体观感就会差很多。解决这个问题最直接的方法是使用工具的辅助对齐功能。draw.io里选中多个模块后右键选择Align功能可以快速实现左对齐、右对齐、水平居中、垂直居中。另一个好用的是Distribute功能可以自动让多个模块之间的间距相等。用上这两个功能排布整齐度会立刻提升一个层次。间距问题也要留意。我习惯给所有模块设定统一的外边距标准比如横向两个模块之间固定为40px纵向固定为30px。手动拖动的时候难免有偏差所以画完一定用Distribute功能统一一遍。4.3 风格不统一一个团队的图像拼凑出来的如果你是一个团队的负责人或者经常需要把多个人画的图合并到一个文档里风格不统一是很头痛的事。字体不同、配色不同、线宽不同、图形样式不同拼在一起就是四不像。解决办法是建立团队的绘图规范并把它沉淀成模板。规范里至少应该包含统一的字体列表包括字体名称和字号、统一的主色板和辅助色板用HEX值标明、统一的线宽标准、统一的箭头样式、统一的图形圆角规范。有了规范之后大家在同一个规范下画图风格自然就统一了。draw.io支持自定义样式库可以把自己团队的规范做成一个Scratchpad或Custom Shapes团队成员直接调用不用每个人去记规范参数。我在我们团队就是这么落地的效果非常好。4.4 版本管理改了又改图到底哪版是对的代码有Git管着但是图怎么办这是很多团队都会遇到的问题。尤其是用在线工具画图默认没有版本管理功能改了一版之后就再也回不去了。我推荐的方案分两种场景。轻量级场景把绘图的源文件用固定的命名规范保存在网盘或共享目录里比如订单系统架构图_v1.2_20240615.drawio每次修改另存为新版本保留历史版本。这个方案成本低够用。重量级场景直接用PlantUML或Mermaid这类代码画图方案图以代码文件的形式存在Git仓库里天然就有版本管理还能在代码评审里追到每次改动是谁、在什么时候、为什么改的。我个人的倾向是凡是需要长期维护、多人协作的图尽量代码化一次性或者使用频率不高的图用draw.io的源文件管理方案就足够。4.5 导出与呈现在不同场景下怎么放图图画完了最终还是要给别人看。不同使用场景下图的导出格式和呈现方式有不同的讲究。投屏评审场景导出PNG推荐1920宽度分辨率保证投影放大后依然清晰。字体大小不要小于12pt否则后排的人看不清。这个我踩过坑——有一次评审会投屏一张架构图字号只有10pt后排的人全程眯着眼效果很差。文档嵌入场景如果目标是Word或PDF文档导出PDF矢量格式最合适放大不会模糊打印也清晰。draw.io和一些工具都支持直接导出PDFFigma更是矢量导出的强项。网页发布场景导出SVG是首选矢量格式加载快、缩放清晰还能部分保留交互能力。如果平台不支持SVG那PNG 2x分辨率也可以。代码仓库场景直接放PlantUML或Mermaid源码就行README里用对应的渲染器在线渲染展示。好处是最新的图永远和源码同步不会出现过期文档的问题。5. 进阶实践让图表说故事5.1 框线和箭头之外的叙事技巧基础图表画得熟练之后可以更进一步思考一个问题图表能不能讲故事技术图表通常给人冷冰冰的感觉但其实图表天然具备叙事能力。想想看一张图有起点、有路径、有终点这不就是故事的骨架吗让图表说故事的第一个技巧是设计视觉引导路径。人的视线天然会按照从左到右、从上到下的顺序移动你可以在图中刻意设计一条主导视线路径让读者的视线沿着你希望他理解的顺序移动。比如画一张用户登录的流程图从顶部用户输入开始垂直向下到鉴权服务分支出“成功”和“失败”两条路径成功路径用醒目的颜色失败路径用浅色弱化。读者的视线会自然沿着成功路径走一遍这个过程中他就“经历”了一遍用户成功登录的故事。第二个技巧是用注释和标记来说故事。在图的合适位置加上简短的文字注释就像电影里的旁白提示读者“注意这里”、“这个环节是关键”、“这里做了取舍”。这种注释在架构图和流程图中运用得当可以把静态的图变成动态的叙事。比如在订单服务旁边写一行“核心链路性能瓶颈重点关注”这行字传达的信息量可能比画一个模块还要大。第三个技巧是使用对比来讲故事。改造前后的对比图、优化前后的性能对比图、方案A和方案B的取舍对比图——用并排或者切换的方式把对比关系可视化读者不需要看文字说明就能直观感受到差异和变化。这类图在技术决策场景中非常有用。5.2 架构图、流程图、时序图的分场景设计要点不同类型的技术图在设计上有各自的侧重点我单独拿出来展开说一下这些都是我在实际项目中反复调整后总结的经验。架构图的设计重点是结构和边界。强调系统的分层关系、模块划分、依赖方向、通信方式。好的架构图读完之后应该能回答三个问题系统有哪些部分部分之间怎么协作系统的边界在哪里设计时不要把太多动态交互的内容放进架构图里架构图本质上是静态的“骨架”。流程图的设计重点是路径和决策。强调流程的主干、分支条件、异常处理、终态。设计流程图时我习惯先画主路径再补分支主路径永远是视觉上的主角。分支之间尽量避免交叉必要的时候宁可重复一个节点也不要让线条绕来绕去。流程图的文字说明追求“动宾结构”的简洁短语比如“校验参数”“查询库存”“扣减余额”比长句描述更容易扫描阅读。时序图的设计重点是顺序和交互。强调消息的发起方、接收方、先后顺序、同步或异步、返回结果。设计时序图要注意缩小参与者的范围——一张时序图里如果参与对象超过6个建议拆成多张图。我画时序图一般控制在4-6个参与者再多读者就看不过来了。5.3 用模板库沉淀团队智慧画图经验积累到一定阶段之后最有价值的事情就是建立自己或团队的模板库。模板不仅是拿来就用的便利品更重要的是它沉淀了团队对某一类图的最佳实践。我的模板库分三个层次基础模板、场景模板和精品模板。基础模板是通用的图形要素规范包括各类框式样、箭头样式、层背景样式这部分基本是固定的。场景模板是从具体场景中提炼出来的比如“微服务架构图模板”“CI/CD流水线模板”“部署架构模板”“登录时序模板”每个模板都预置了标准的层级结构、模块命名规范和连线风格。精品模板则是从我们团队做过的高质量图里精选出来的作为内部标杆案例。每次画出一张特别满意的图我都会多花十几分钟把它的结构抽象一下看看能不能沉淀成模板。这样做的好处是团队的绘图水平会随着时间逐渐提升——因为每个新人的起点都是之前最好的成品。5.4 从diagram-design到信息设计聊到这里我觉得有必要把视野再抬高一点。diagram-design表面上看是“怎么画好一张图”但本质上它属于更大的一个领域——信息设计。信息设计的核心命题是如何把复杂的、结构化的信息用尽可能高效的方式传递给读者。在这个视角下图表的元素框、线、箭头、颜色、文字就是你的词汇布局和层次就是你的语法叙事逻辑就是你的表达风格。当你把图表设计当作一门表达手艺来打磨的时候你会发现它不仅提升了图的质量还会反向影响你的思维方式——因为要画出清晰准确的图你就必须清晰地理解系统本身。这也是为什么我一直觉得画图能力是技术从业者被低估的一项核心能力。在技术评审会上你的代码别人不一定看得懂但一张架构图别人一定看得懂。能把图画清楚的人往往也是能把技术讲清楚、把系统想清楚的人。diagram-design这个主题背后真正值钱的不是某个工具的技巧而是这套把复杂变清晰的思维方法。6. 实操经验总结与心得写到这儿关于diagram-design的核心内容基本都讲完了。最后我想分享几条自己在实际操作中积累的、最想告诉后来者的经验。第一条是关于工具能力的。别在工具上花费过多的选择时间任何一款主流工具都足够支撑你画出一张好图。真正决定图表质量的是设计思维不是工具特性。我见过用系统自带画图工具也能画出漂亮架构图的人也见过手握Figma照样画出一堆视觉垃圾的人。工具只是画笔思想才是画作。第二条是关于练习方法的。如果想提升自己的图表设计能力最有效的练习方式不是多看别人的图而是拿自己正在负责的某个真实系统反复画五遍它的架构图。每画一遍要求自己在某个维度上做得比上一遍更好——第一次保证信息完整第二次优化层次结构第三次精修视觉细节第四次尝试叙事引导第五次追求整体美感。画完五遍你会明显感觉到自己对系统的理解更清晰了画图的手感也完全不同了。第三条是关于反馈闭环的。每次画完重要的图我都会主动找两三个人征求意见一个懂技术的人看逻辑对不对一个不懂技术的人看能不能看懂基本意思一个注重审美的人看视觉上哪里别扭。三方面意见综合下来图的改进方向会非常明确。这个反馈闭环的收益远超自己反复琢磨。最后说一个我反复跟团队强调的观点图是沟通工具不是艺术品。画图的最终目的不是让图好看而是让看图的人用最小的成本获得准确的信息。漂亮但不清晰的图是失败的朴素但逻辑分明的图是成功的。只要把握住“信息准确、结构清晰、重点突出”这三个核心你的图就已经超越了大多数人的水平。