★ FEATURED ARTICLE 1. 从“diagram-design”这个标题说起它到底在解决什么问题第一次看到“diagram-design”这个标题很多人会下意识觉得它是个画图工具或者某个设计软件的插件。但如果你真正做过技术方案评审、系统架构梳理、或者给非技术同事讲清楚一个复杂流程你就会明白画图这件事难点从来不在“画”而在“设计”。一张好的图能让五个人开半小时会就对齐认知一张烂的图能让同一个问题反复讨论三周还在原地打转。“diagram-design”这个标题背后指向的是一类非常具体的需求如何用结构化的方法把脑子里混乱的信息变成一张别人能看懂、能复用、能直接拿去汇报的图。它不是一个具体的软件名称而是一套关于图表设计的方法论和实践集合。关键词虽然为空但从标题本身可以拆出三个核心维度信息分层、视觉编码、场景适配。这三个维度决定了你画出来的图是“自嗨型”还是“沟通型”。这篇文章适合谁看如果你是技术开发者需要画架构图、流程图、时序图来对齐方案如果你是产品经理需要画业务流程图、状态机图来跟开发和设计沟通如果你是咨询顾问或项目管理者需要画组织图、路线图、矩阵图来汇报进展——那这篇内容就是为你准备的。我会从最底层的“为什么图会画废”开始讲一直讲到具体场景下的参数设置和避坑技巧中间会穿插大量我在实际项目中踩过的坑和总结出来的土办法。先给一个反直觉的结论大多数人画图慢、画图丑、画完没人看根本原因不是审美不行也不是工具不熟而是动手之前没有做“信息分层”。你打开工具就开始拖方框、拉箭头结果画到一半发现逻辑不对删了重来或者画完了别人问你“这个模块为什么在这里”你自己都说不清楚。这就是典型的“用战术上的勤奋掩盖战略上的懒惰”。2. 信息分层为什么你的图总是“看起来乱”2.1 一张图只能有一个“主角”我见过太多人画图恨不得把系统里所有模块、所有接口、所有数据流都塞进一张图里。结果就是图比屏幕还大字号小到要放大三倍才能看清箭头交叉得像一团乱麻。这种图唯一的用途就是“证明我画过”没有任何沟通价值。正确的做法是在动手之前先问自己一个问题——这张图是给谁看的他看完之后需要做什么决策如果是给技术负责人看架构评审图那主角就是“模块边界和依赖关系”数据库表结构、字段类型这些细节统统不要出现如果是给业务方看流程优化图那主角就是“角色和动作的流转”技术实现细节一个字都不要提。我习惯在画图之前先写一句话“这张图要说明的是______。”如果这句话超过20个字还说不清楚说明你还没想明白别急着打开工具。这句话就是你这张图的“主角”所有元素都要围绕它来取舍。跟主角无关的再重要也砍掉或者放到另一张图里。2.2 分层不是画三层框而是分三次画很多人理解的信息分层就是在图上画三个横向的框上面写“表现层”“逻辑层”“数据层”。这只是视觉上的分层不是认知上的分层。真正的分层是分三次画图第一次只画“实体”。把系统里所有关键角色、模块、外部系统列出来用最简单的方框表示不要连线不要颜色不要图标。这一步的目的是确认“有哪些东西”。第二次只画“关系”。在实体之间连线标注关系类型调用、依赖、数据流向、继承等。这一步不要考虑布局好不好看先把逻辑关系理清楚。我经常在这一步发现原本以为两个模块是调用关系仔细一想其实是事件通知关系箭头方向完全反了。第三次才做“视觉编码”。给不同层级的实体分配不同的颜色、形状、大小给不同关系分配不同的线型和箭头样式。这一步才是大多数人一上来就做的事但如果没有前两步你做的视觉编码就是无根之木。提示如果你用的是支持图层的工具比如Figma、Draw.io、Excalidraw把这三步分别放在三个图层里。第一步的图层叫“实体”第二步叫“关系”第三步叫“样式”。这样后期修改的时候你可以单独隐藏某一层快速检查逻辑是否有遗漏。2.3 信息密度的“三秒法则”一张图的信息密度是否合适有一个很简单的检验方法把图缩小到手机屏幕大小三秒内能不能看出这张图在讲什么。如果三秒内只能看到一团模糊的色块和线条说明信息密度太高了如果三秒内只能看到两三个孤零零的方框说明信息密度太低了。我自己的经验值是一张A4纸大小的图核心实体不超过9个核心关系不超过15条。超过这个数要么拆图要么做“总-分”结构——一张总览图加若干张细节图。总览图上每个实体只写名称细节图里再展开具体内容。这样别人可以先看总览建立全局认知再按需深入细节。3. 视觉编码颜色、形状、线条到底怎么选3.1 颜色不是用来“好看”的是用来“分类”的新手画图最容易犯的错误就是给每个模块分配一个不同的颜色觉得这样“色彩丰富、好看”。结果就是彩虹图看的人根本记不住哪个颜色代表什么。颜色的第一原则是同一类事物用同一种颜色不同类事物用不同色系。具体怎么操作我通常把颜色分成三个层级主色用于最核心的实体通常是你要强调的那个模块或角色。一张图里主色只能有一种饱和度可以高一点让人一眼就看到。辅色用于与主色直接交互的实体可以用主色的邻近色或者降低饱和度的同色系。辅色可以有2-3种用来区分不同的功能组。中性色用于背景、边框、辅助说明文字。灰色系是 safest 的选择不会抢视觉焦点。如果你实在不知道怎么配色记住一个万能公式深蓝主 浅蓝/灰蓝辅 浅灰背景 橙色强调。深蓝给人稳重专业的感觉浅灰不抢戏橙色用来标出需要特别注意的地方比如风险点、待确认项。这个组合在投影仪、打印稿、手机屏幕上都不容易出错。3.2 形状承载语义不要随便用方框、圆角矩形、圆形、菱形、圆柱体——这些形状在长期的使用中已经形成了约定俗成的语义。你当然可以打破这些约定但前提是你有足够强的理由并且要在图例里说清楚。形状常见语义适用场景直角矩形模块、组件、系统架构图、部署图圆角矩形服务、接口、动作流程图、时序图圆形/椭圆角色、参与者、状态用例图、状态图菱形判断、分支流程图、决策树圆柱体数据库、存储架构图、数据流图平行四边形数据、输入输出数据流图虚线框边界、分组、可选任何需要分组的场景我个人的习惯是架构图里所有模块都用直角矩形所有外部系统用虚线框所有数据库用圆柱体。这样即使我不写图例有经验的读者也能一眼看懂。流程图里所有动作都用圆角矩形判断用菱形开始和结束用胶囊形两端半圆的矩形。这套规则一旦定下来团队里所有人画图都遵守沟通成本会大幅降低。3.3 线条的粗细和样式比颜色更重要很多人花大量时间调颜色却忽略了线条。实际上在信息传达效率上线条样式 线条粗细 线条颜色。实线表示强关系直接调用、同步请求虚线表示弱关系异步通知、依赖但非直接调用点线表示可选关系或未来规划。箭头方向表示数据流向或控制流向。线条粗细也有讲究主流程用粗线2px以上辅助流程用细线1px。这样即使两张图内容一样主流程突出的那张看起来就更有重点。我见过一个架构图所有线条都是1px黑色实线结果看的人根本分不清哪个是核心链路哪个是边缘依赖。还有一个细节尽量避免线条交叉。如果两条线必须交叉在交叉处画一个小半圆“跳线”表示两条线没有连接关系。这个技巧在画复杂网络拓扑时特别有用能减少大量歧义。4. 场景适配不同图种的设计要点完全不同4.1 架构图边界比细节重要架构图的核心任务是说清楚“什么在什么里面”和“什么依赖什么”。所以边界Boundary是第一位的。我通常用虚线框或浅色背景块来表示边界比如“客户端边界”“服务端边界”“第三方边界”。边界内部放模块边界之间用箭头表示调用关系。架构图最容易犯的错误是“把部署图画成架构图”。部署图关心的是物理节点、IP、端口、容器架构图关心的是逻辑模块、职责、依赖。如果你在架构图上写“192.168.1.10:8080”那说明你画错了。架构图上的模块应该是“用户服务”“订单服务”“支付网关”这种逻辑概念具体部署在几台机器上、用什么端口那是部署图的事。另一个经验架构图上的箭头要标注协议或方式。比如“HTTP/JSON”“gRPC”“MQ”“WebSocket”。不标的话看的人会默认是同步调用但实际上可能是异步消息这会导致对系统行为的误解。我习惯在箭头旁边用小号灰色字体标注不抢眼但信息完整。4.2 流程图泳道和异常分支是灵魂流程图的核心任务是说清楚“谁在什么条件下做了什么动作产生了什么结果”。所以泳道Swimlane是必不可少的。没有泳道的流程图就像没有标点符号的长句读起来费劲还容易歧义。泳道怎么分按角色分是最常见的用户、前端、后端、数据库、第三方。但有时候按系统分更合适客户端、网关、业务服务、数据层。选择标准是看这张图的人最关心哪个维度的分工。如果是给业务方看按角色分如果是给运维看按系统分。流程图的另一个关键是异常分支。很多人画流程图只画“成功路径”结果开发实现的时候发现各种边界情况没考虑。我习惯在画完主流程后强制自己问三个问题如果这一步失败了怎么办如果这一步超时了怎么办如果用户在这一步取消了怎么办把这三个问题的答案画成异常分支用红色或橙色线条标出。这样一张流程图才算是完整的。注意异常分支不要画得太深。如果异常处理本身很复杂单独画一张“异常处理流程图”在主流程图上只标注“见异常处理图X”。否则主流程会被异常分支淹没失去可读性。4.3 时序图消息编号和激活条是专业度的分水岭时序图Sequence Diagram是技术评审中最常用的图种之一但也是最容易画得不专业的图种。不专业的时序图长这样几条竖线几个箭头箭头上的文字挤在一起看不清。专业的时序图长这样消息有编号激活条Activation Bar清晰返回消息用虚线自调用消息用折线。消息编号非常重要。当评审时有人说“第三步和第五步之间是不是漏了一个校验”你可以直接说“没有漏第三步的返回消息里包含了校验结果你看编号3.1”。没有编号的话大家只能靠“那个箭头”“上面那个”来指代效率极低。激活条表示对象在某个时间段内是活跃的。很多人忽略这个细节结果看的人不知道某个服务是在处理请求还是已经返回了。我的习惯是同步调用画实心激活条异步处理画空心激活条。这样一眼就能看出哪些环节是阻塞的哪些是并行的。4.4 状态图状态命名和迁移条件是关键状态图State Diagram在业务系统里用得很多比如订单状态、工单状态、审批状态。状态图最容易犯的错误是状态命名太随意。比如“待处理”“处理中”“已处理”——这三个状态看起来没问题但仔细一想“待处理”和“处理中”的边界是什么谁来决定从“待处理”变成“处理中”如果没有明确的迁移条件开发实现的时候就会各写各的最后状态机乱成一团。我的经验是状态名用“形容词名词”或“过去分词”比如“待审核”“审核中”“审核通过”“审核拒绝”。迁移条件用“事件守卫条件”表示比如“用户提交事件 金额小于1000守卫条件”。这样每个状态和每条迁移线都有明确的语义开发照着实现就不会有歧义。5. 工具选型别在工具上纠结超过十分钟5.1 三类工具三种场景市面上的画图工具大致分三类各有各的适用场景第一类代码化绘图工具如PlantUML、Mermaid、Graphviz。特点是图用代码描述版本可控适合放在代码仓库里跟代码一起维护。缺点是样式调整不灵活复杂布局很难精确控制。我通常用这类工具画时序图和简单的流程图因为这两类图对布局要求不高代码化反而效率更高。第二类拖拽式绘图工具如Draw.io、Excalidraw、Figma。特点是所见即所得样式自由度高适合画架构图和需要精细排版的图。缺点是版本管理麻烦多人协作容易冲突。我通常用这类工具画需要放进PPT或文档里的最终版图。第三类专业建模工具如Enterprise Architect、Visual Paradigm。特点是支持UML全规范能生成代码和文档。缺点是学习曲线陡峭启动慢。除非项目强制要求否则我一般不用这类工具因为大部分场景下Draw.io已经够用了。5.2 我的实际工作流经过多年折腾我固定下来一套工作流草稿阶段用Excalidraw定稿阶段用Draw.io需要版本管理的用PlantUML。Excalidraw的手绘风格在草稿阶段特别好用因为它“看起来就不像最终版”所以评审的时候大家更愿意提意见不会觉得“你都画这么漂亮了我还挑毛病是不是不太好”。等意见收集得差不多了再用Draw.io画一版规整的放进正式文档。如果是需要长期维护的图比如系统架构图我会用PlantUML写一份放在代码仓库的docs/目录下。每次架构变更改代码的同时改图保证图和代码同步。虽然PlantUML的样式不如Draw.io好看但“同步更新”这个优点远远盖过了“不好看”这个缺点。提示不管你用什么工具导出格式首选SVG。SVG是矢量图放大不模糊而且可以用文本编辑器打开方便做批量替换比如把所有“测试环境”改成“生产环境”。PNG只适合发聊天消息不适合放进文档。5.3 团队协作的“图例规范”如果你在团队里推动画图规范第一件事不是教大家怎么画而是定一份图例规范。这份规范不用很长一页纸就够但必须包含形状语义、颜色语义、线条语义、字体大小、命名规则。我见过一个团队图例规范只有三条蓝色方框是前端绿色方框是后端灰色方框是外部系统。就这三条团队里所有人画的架构图风格统一新人进来一看就懂。反而是一些定了二十页规范但没人看的团队画出来的图五花八门。图例规范定好之后在团队共享的绘图工具里建一个模板文件。所有人画图都从这个模板开始颜色、字体、形状都是预设好的想跑偏都难。这个动作一次性投入半小时后面能省几百小时的沟通成本。6. 避坑实录那些年我画废过的图6.1 坑一在图上写代码刚工作那会儿我画架构图喜欢在方框里写类名和方法名觉得这样“信息量大、显得专业”。结果评审的时候技术负责人看了一眼说“你这是架构图还是代码注释我要看的是模块职责不是你的类设计。”后来我明白了架构图的读者关心的是“这个模块负责什么”而不是“这个模块怎么实现”。类名、方法名、参数类型这些是详细设计文档的内容不应该出现在架构图上。正确的做法是方框里只写模块名称和一句话职责描述。比如“订单服务负责订单创建、查询、状态流转”。如果某个模块的职责特别复杂用注释或附件说明不要塞进方框里。6.2 坑二箭头方向画反这个坑我踩过不止一次。特别是在画数据流图的时候到底是“用户请求流向服务”还是“服务响应流向用户”箭头方向经常搞混。后来我定了一个规矩箭头永远指向“被调用方”或“数据接收方”。用户发起请求箭头从用户指向服务服务返回响应箭头从服务指向用户。这样虽然图上会有双向箭头但语义清晰不会歧义。还有一个更隐蔽的坑异步消息的箭头方向。比如服务A发消息到消息队列服务B从消息队列消费。正确的画法是A → 消息队列 → B。但很多人画成A → B把消息队列省略了。这在简单场景下没问题但如果消息队列有重试、死信、顺序保证等特性省略它就会导致理解偏差。6.3 坑三忽略图例和标题我见过太多图画得挺不错但就是没有标题和图例。看的人第一反应是“这图讲什么的”第二反应是“这个蓝色方块代表什么”。这两个问题消耗的认知资源比图本身的内容还多。标题要写“什么系统的什么图”比如“订单系统-创建订单流程图”。不要只写“流程图”更不要不写。图例要解释所有非通用的视觉元素比如“橙色虚线表示异步调用”“灰色背景表示第三方边界”。如果图里用了缩写图例里要给出全称。6.4 坑四一张图改到天荒地老这是心理层面的坑。很多人画完图之后反复调整布局、对齐、颜色花了两小时画图三小时调格式。我的建议是设置一个“够用就好”的时间盒。草稿图15分钟正式图45分钟。时间一到不管满不满意先发出去收集反馈。因为你自己觉得“不够完美”的地方别人可能根本注意不到而别人真正在意的问题你可能压根没画出来。我现在的习惯是画完第一版之后强制自己站起来走一圈回来再看一眼。如果第一眼能看到核心信息就发出去。如果第一眼觉得“有点乱”就只调最乱的那一处不整体重排。这样效率高很多图的质量反而更好因为你的精力花在了信息本身而不是像素级对齐。7. 从“画图”到“设计图”的思维转变7.1 图是沟通工具不是艺术品这个认知转变花了我最长时间。刚入行的时候我总觉得图要画得“漂亮”才算好。后来发现一张“丑但清晰”的图价值远远大于一张“美但费解”的图。因为图的本质是沟通工具沟通的第一目标是“准确传递信息”第二目标才是“让人愿意看”。所以我现在画图优先保证三件事信息准确、层级清晰、重点突出。至于颜色搭配、图标精美、阴影渐变这些都是锦上添花有时间就做没时间就不做。我甚至专门做过实验同一份内容一版用精心设计的配色和图标一版只用黑白灰和基本形状。结果在评审中黑白灰那版获得的有效反馈更多因为大家把注意力放在了内容上而不是“这个渐变色真好看”。7.2 先写文字大纲再画图这是我强烈推荐的一个习惯在打开任何绘图工具之前先用纯文本写一份大纲。大纲的格式很简单图标题______ 核心信息______ 实体列表 - 实体A类型模块职责______ - 实体B类型外部系统职责______ 关系列表 - A → B类型同步调用协议HTTP - B → A类型异步通知协议MQ这份大纲写完之后你自己读一遍如果逻辑通顺再开始画图。如果大纲里就有说不通的地方画成图只会更乱。这个习惯让我画图的一次通过率提高了至少一倍因为大部分逻辑问题在文字阶段就暴露了。7.3 图的“可维护性”比“一次性效果”重要如果你画的图需要长期使用比如系统架构图、业务流程图那可维护性就是第一优先级。什么叫可维护性就是当系统变更时你能在五分钟内更新图而不是重新画一遍。提高可维护性的技巧包括用图层分离实体和样式、用组件复用相同模块、用变量管理颜色和字体、用注释记录变更历史。这些技巧在画单张图的时候可能显得麻烦但当你有二十张图需要同步更新时就能体会到好处了。我自己的做法是所有长期维护的图都用PlantUML或Mermaid写放在Git仓库里。每次系统变更改代码的同时改图提交信息里写清楚“更新架构图新增支付网关模块”。这样图的变更历史和代码的变更历史是对齐的回溯问题的时候特别方便。8. 几个能立刻用上的实操技巧8.1 对齐和分布手动调不如用工具如果你还在手动拖拽方框来对齐赶紧停下来。所有主流绘图工具都有对齐和分布功能。选中多个元素按“水平居中对齐”或“垂直等距分布”一秒钟搞定。这个技巧看起来简单但我见过太多人不知道硬是用方向键一个一个像素地调。更高级一点的技巧是用网格和参考线。在Draw.io里按CtrlShiftG打开网格在Figma里按CtrlShift打开布局网格。把元素吸附到网格上整体会整齐很多。如果工具支持“智能参考线”拖动时自动显示与其他元素的对齐关系一定要打开。8.2 字体一个图里不要超过两种字号字体大小是很多人忽略的细节。我见过一张图里用了五种字号结果看的人不知道哪个是标题、哪个是正文、哪个是注释。一张图里最多两种字号主字号用于实体名称和辅字号用于注释和标注。主字号比辅字号大2-4px就够了不需要差太多。字体家族也尽量统一。如果图要放进文档用文档的正文字体如果图要单独展示用无衬线字体如Arial、Helvetica、思源黑体。不要用衬线字体画架构图因为衬线字体在小字号下容易糊投影的时候尤其明显。8.3 导出根据用途选格式和分辨率用途推荐格式分辨率/设置放进Word/PDF文档SVG或EMF矢量无限缩放放进PPTPNG或SVGPNG用2倍分辨率SVG直接插入发聊天消息PNG宽度1920px文件小于2MB打印PDF或SVG矢量A4或A3尺寸网页展示SVG矢量文件尽量小注意导出PNG的时候背景一定要选透明或白色。我见过有人导出透明背景的PNG结果在深色模式的聊天软件里黑色文字完全看不见。如果不确定对方用什么背景导出白色背景最安全。8.4 快捷键画图效率翻倍不管你用什么工具花十分钟把常用快捷键记下来效率至少翻倍。以Draw.io为例CtrlD复制CtrlG组合CtrlShiftG取消组合CtrlShiftH水平翻转CtrlShiftJ垂直翻转AltShift方向键微调位置。这些快捷键在菜单里都能找到但用快捷键操作手不用离开键盘思路不会断。还有一个通用技巧按住Shift键画线可以锁定水平、垂直或45度角。画架构图的时候水平线和垂直线占90%以上按住Shift画出来的线又直又整齐比手动调省事多了。9. 最后分享一个我用了五年的“图检查清单”每次画完图在发出去之前我会花两分钟过一遍这个清单。这个习惯帮我避免了很多低级错误也让我画的图在团队里逐渐有了“靠谱”的口碑。第一遍看信息图标题写了吗核心信息在三秒内能看出来吗有没有多余的元素可以删掉实体和关系的命名有没有歧义第二遍看视觉颜色有没有超过四种字号有没有超过两种线条粗细有没有区分主次对齐和分布整齐吗第三遍看逻辑箭头方向对吗异常分支画了吗边界标了吗图例和缩写解释了吗第四遍看场景这张图是给谁看的他看完之后能做出我期望的决策吗如果我是他我会问什么问题这些问题图上能回答吗这四遍过完图基本就没大问题了。如果时间紧至少过第一遍和第三遍这两遍能拦住80%的致命问题。画图这件事说到底是个“想清楚”的功夫。工具再熟、技巧再多如果脑子里是一团浆糊画出来的图也一定是浆糊。反过来如果你能把信息分层、视觉编码、场景适配这三件事想明白哪怕用记事本画ASCII图别人也能看懂。我在实际项目中越来越觉得画图的时间应该三七开七分想三分画。想明白了画就是几分钟的事没想明白画三小时也是白画。
阅读完成 · 觉得有帮助？
