1. 从“diagram-design”这个标题能读出什么第一次看到“diagram-design”这个标题我脑子里蹦出来的不是某个具体工具而是一类非常典型的工作场景手里有一堆零散的信息——流程、层级、关系、时序、状态流转——需要用一张图把它们讲清楚而且这张图还得好看、好懂、好维护。很多人以为画图就是拖拖拽拽真做过项目的人都知道图这东西一旦进入正式文档、技术方案、产品说明它就不再是“随便画画”而是一种信息压缩和认知传递的设计工作。“diagram-design”拆开看核心落在两个词上diagram图表/示意图和 design设计。它指向的不是单纯的绘图技巧而是“如何设计一张图”。这背后至少包含四层需求第一层是选型什么内容该用什么图第二层是结构图的节点、连线、分组怎么组织第三层是视觉颜色、字号、间距、对齐怎么处理第四层是维护图怎么跟着内容一起迭代而不至于每次重画。这四层里前两层决定图对不对后两层决定图好不好用。我见过太多团队在这件事上翻车。有人用流程图去表达一个本质上是状态机的逻辑结果图画得密密麻麻还是说不清有人把架构图画成了“框框连连看”每个框里塞满文字读者看三秒就放弃还有人图做得挺漂亮但源文件丢了改一个字段要重新画一遍。所以这篇内容我想聊的不是“哪个画图工具最好”而是把 diagram-design 当成一个完整的设计问题来拆从需求判断到图形选型从结构搭建到视觉规范再到工程化维护把这条链路走通。适合谁看如果你是技术写作者、产品经理、架构师、设计师或者任何需要把复杂信息可视化的人这篇都能对上号。如果你只是偶尔画个简单示意图也能从里面挑几招直接用。下面我按自己实际做项目的顺序一层层往下拆。2. 先判断“该不该画图”再决定“画什么图”2.1 什么内容值得用图表达不是所有信息都适合画图。我踩过的第一个坑就是“为了画图而画图”——把一段本来三句话能说清的内容硬做成一张图结果读者要花更多时间解读图形符号。判断标准其实很简单当信息之间存在“关系”且这种关系用文字描述会变得冗长或容易歧义时图才有价值。具体来说以下几类内容天然适合图形化流程与分支多个步骤按顺序执行中间有条件判断和回流。文字描述会变成“先做A如果满足X则做B否则做C做完B或C之后再回到A”读起来累画成流程图一目了然。层级与包含组织架构、目录结构、模块划分。这类内容的核心是“谁在谁里面”用嵌套矩形或树形图最直观。时序与交互多个角色之间按时间顺序交换消息。这类内容用文字写就是流水账用时序图能同时表达“谁和谁”“先后顺序”“消息内容”三个维度。状态与迁移一个对象在不同状态之间切换以及触发切换的条件。状态机图是这类内容的专属表达。关系与拓扑节点之间的连接关系比如网络拓扑、依赖关系、数据流向。这类图的重点是“连接”不是“顺序”。反过来如果内容只是并列的几条要点没有顺序、没有层级、没有连接关系那用列表就够了硬画成图反而增加认知负担。我自己的经验法则是如果一段文字里出现了“然后”“如果”“回到”“同时”“依赖于”这类关系词超过三次就值得考虑画图。2.2 图形选型对照表确定要画图之后下一步是选对图形类型。这一步错了后面怎么调都别扭。我整理了一张常用图形与适用场景的对照表基本覆盖了日常工作中八成以上的需求图形类型核心表达适用场景不适用场景流程图步骤顺序与条件分支业务流程、算法逻辑、操作步骤表达状态循环、多角色交互状态机图状态与迁移条件订单状态、连接状态、生命周期表达线性步骤时序图角色间按时间交互接口调用、协议交互、消息流转表达静态结构架构图模块划分与依赖系统分层、服务关系、部署结构表达执行顺序树形图层级与包含目录结构、分类体系、组织架构表达交叉连接关系图节点间连接数据模型、依赖网络、拓扑表达严格顺序甘特图任务与时间跨度项目排期、并行任务表达逻辑依赖细节选型时还有一个容易被忽略的点一张图只表达一个核心维度。我见过有人试图在一张图里同时表达流程、角色和时间结果画出来像蜘蛛网。正确做法是拆成多张图每张图聚焦一个维度图与图之间用编号或引用关联。比如一个完整的下单系统可以用一张架构图讲模块划分一张时序图讲下单交互一张状态机图讲订单状态流转三张图各司其职读者按需查阅。2.3 先画草图再上工具这一步很多人跳过但它直接决定最终图的质量。我的习惯是在打开任何绘图工具之前先用纸笔或白板把节点和连线列出来。这个阶段只关心“有哪些元素”和“它们怎么连”完全不考虑美观。具体做法是把所有节点写成短句或关键词然后问自己三个问题——哪些节点是同一类、哪些节点之间有直接关系、哪些节点是起点和终点。回答完这三个问题图的基本骨架就出来了。这时候再上工具你是在“翻译”一个已经想清楚的结构而不是在工具里一边想一边画。后者最容易出现的问题是画到一半发现结构不对推倒重来时间全浪费在调整布局上。提示草图阶段用不同颜色的笔区分“确定的节点”和“待确认的节点”能帮你快速识别信息缺口避免把不确定的内容画进正式图里。3. 结构设计让图“读得下去”的底层逻辑3.1 节点粒度一个节点只装一件事图读不下去十有八九是节点粒度出了问题。最常见的错误是把一整段描述塞进一个框里框比别的框大五倍读者视线被它吸住整个图的节奏就乱了。我的原则是一个节点只承载一个概念节点内的文字控制在两行以内。如果某个节点的内容确实很多说明它应该被拆成多个节点或者把细节移到图外的注释里。举个例子画一个“用户登录”流程不要写“用户输入账号密码并点击登录按钮系统校验账号密码是否正确”而是拆成“输入凭证”“提交登录”“校验凭证”三个节点。拆开之后每个节点都短连线关系也清晰读者一眼就能扫完。节点粒度还影响图的扩展性。粒度粗的图加一个新步骤就要动大手术粒度细的图加节点只是多一个框和一条线。所以从维护角度看宁可拆细不要合并。3.2 连线规则减少交叉明确方向连线是图的血管血管乱了图就废了。减少连线交叉有几个实用技巧分层布局把节点按“阶段”或“层级”排成几行连线尽量在相邻行之间走避免跨行大跨度连接。统一方向流程图统一从上到下或从左到右不要一会儿横一会儿竖。方向统一之后读者不需要思考“这条线往哪走”。合并同类连线如果多个节点都指向同一个目标可以用一条总线汇聚而不是画多条平行线。用颜色区分连线类型比如实线表示主流程虚线表示异常分支不同颜色表示不同角色。但颜色不要超过三种否则就变成彩虹图了。方向性上箭头是必须的但箭头太多也会造成视觉噪音。一个折中方案是主流程用箭头辅助关系用无箭头连线或虚线。这样读者能快速区分“主要路径”和“次要关联”。3.3 分组与边界用容器表达“归属”当图里的节点超过十五个就需要分组了。分组的作用是告诉读者“这几个节点是一伙的”。常见的分组方式有矩形框最直接把相关节点框在一起框上标组名。背景色块比矩形框更轻量适合分组边界不需要强调的场景。泳道按时序图或流程图中的角色划分每个角色一条泳道节点放在对应泳道里。分组的关键是边界要清晰组名要具体。我见过有人用“其他”作为组名这种分组等于没分。组名应该是一个有意义的概念比如“认证模块”“数据层”“外部依赖”。另外分组不要嵌套太深两层基本是上限三层以上读者就晕了。3.4 一张图的信息密度控制信息密度是图设计里最微妙的平衡。太稀疏图显得空洞读者觉得“这点东西也值得画图”太密集读者直接放弃。我的经验值是一张图里的节点数量控制在 7 到 15 个之间连线数量控制在节点数量的 1.5 倍以内。超过这个范围就要考虑拆图。拆图的方式有两种一种是按维度拆比如把“流程”和“状态”拆成两张图另一种是按层级拆先画一张总览图每个模块再画一张细节图。总览图用编号标注模块细节图用同样的编号读者可以按图索骥。注意拆图之后一定要有“导航”也就是告诉读者这几张图之间的关系。最简单的做法是在每张图下方写一句“本图是总览图中模块 3 的展开”。4. 视觉规范让图“看起来专业”的具体参数4.1 字体与字号可读性优先图的视觉问题里字体和字号是最容易被忽视的。很多人画完图觉得“哪里不对”但又说不上来往往就是字体在作祟。我的建议是字体统一全图只用一种字体中文用无衬线字体如思源黑体、苹方英文用对应的无衬线字体。不要混用衬线和无衬线。字号分级标题字号、节点字号、注释字号拉开差距。一般标题 16-20px节点文字 12-14px注释 10-12px。差距太小层级出不来差距太大注释看不清。行高适中节点内多行文字的行高设为字号的 1.4 到 1.6 倍太挤读起来累太松显得散。还有一个细节节点内的文字对齐方式要统一。要么全部左对齐要么全部居中不要有的左对齐有的居中。左对齐适合文字较多的节点居中适合短标签。4.2 配色三色原则与语义色配色是图设计里最容易“用力过猛”的地方。我的原则是主色不超过三种每种颜色有明确的语义。具体做法是选一个主色用于主要节点一个辅助色用于次要节点或强调一个中性色灰用于背景和辅助线。如果还需要区分更多类别用同色系的不同深浅而不是引入新色相。比如主色是蓝色可以用深蓝、中蓝、浅蓝区分三个层级视觉上仍然统一。语义色是进阶技巧让颜色承载信息。比如绿色表示“正常/成功”红色表示“异常/失败”黄色表示“警告/待定”。这样读者不需要看图例就能理解节点含义。但语义色一旦确定全图甚至全文档都要保持一致不能这张图绿色表示成功那张图绿色表示待办。4.3 间距与对齐专业感的来源如果说配色决定图“好不好看”那间距和对齐决定图“专不专业”。这两点做不好图会显得很“业余”但很多人又说不清问题在哪。间距的核心是一致性节点之间的水平间距一致垂直间距一致节点内文字与边框的间距一致。我通常用 8px 作为基础间距单位所有间距都是 8 的倍数8、16、24、32。这样图看起来会有一种内在的节奏感。对齐的核心是网格把所有节点对齐到隐形的网格上。大多数绘图工具都有“对齐到网格”或“智能参考线”功能一定要打开。对齐之后即使节点大小不一整体也会显得整齐。我见过最有效的改进就是把一张图里所有节点的左边缘对齐专业感立刻提升一个档次。4.4 图例与标注降低理解成本图例不是每张图都需要但如果图里用了颜色、线型、形状来区分含义就必须有图例。图例的位置一般在图的右下角或下方不要放在图中间干扰阅读。标注比图例更灵活用于解释特定节点或连线的细节。标注的写法有讲究用短句不用长句用具体名词不用代词。比如“此处超时重试三次”比“这里会做一些处理”有用得多。标注的引线要指向明确不要指向空白区域让读者猜。5. 工具选型不同场景下的取舍5.1 代码化绘图 vs 拖拽式绘图工具选型上最大的分水岭是“代码化绘图”和“拖拽式绘图”。两者没有绝对优劣关键看场景。代码化绘图如 Mermaid、Graphviz、PlantUML 这类文本描述生成图形的方案的优势是图的内容可以进版本控制改动能追溯批量修改方便改一个定义全图生效适合结构规整、节点多的图和文档系统集成好改文档时图自动更新劣势是布局控制力弱复杂图容易排得难看学习成本高需要记语法不适合需要精细视觉调整的场景拖拽式绘图如各类在线白板和桌面绘图软件的优势是所见即所得布局完全可控上手快不需要学语法适合视觉要求高、结构不规整的图劣势是源文件容易丢改图靠手动多人协作时版本混乱图多了之后维护成本高我的实际做法是混合使用结构规整、需要频繁更新的图如流程图、时序图、状态机图用代码化方案视觉要求高、一次性或低频更新的图如架构总览、宣传用图用拖拽式方案。两者不是对立的而是各管一段。5.2 选型时容易忽略的三个维度除了“代码还是拖拽”选型时还有三个维度容易被忽略第一导出格式。图最终要放到哪里如果是文档需要矢量格式SVG、PDF如果是演示需要高分辨率位图PNG如果是网页SVG 最合适。选工具前先确认它能不能导出你需要的格式。第二协作方式。是单人画还是多人改多人改的话工具是否支持实时协作、评论、版本历史如果团队里有人不熟悉工具学习成本也要算进去。第三长期维护。这张图三个月后还要改吗如果要改源文件在哪里改的人能不能找到我见过太多“图在文档里源文件在某人电脑里某人离职了”的悲剧。所以源文件必须和文档放在一起或者用代码化方案让图本身成为文档的一部分。5.3 我的工具组合与使用场景说具体一点我目前的组合是这样的流程图、时序图、状态机图用文本描述生成源文件直接写在 Markdown 里和文档同源。改文档的时候顺手改图不会出现图和文档不一致的情况。架构图、部署图用拖拽式工具画导出 SVG 放进文档。这类图视觉要求高且更新频率低拖拽式更合适。草图、讨论用图用在线白板快速画完截图发群里不追求精度追求速度。复杂关系图用自动布局的图形描述语言让工具算布局人只负责定义节点和关系。这个组合的核心逻辑是让图的维护成本跟它的更新频率匹配。更新频繁的用代码化更新少的用拖拽式一次性的用白板。6. 从“画完”到“维护好”图的工程化6.1 源文件管理图也要进版本控制图最大的维护痛点是“源文件丢失”。解决办法只有一个把图的源文件当成代码来管理。具体来说代码化方案的源文件本身就是文本直接进版本控制和文档放同一个仓库。拖拽式方案的源文件如 .drawio、.fig 等也要进仓库不要只存导出的图片。导出的图片作为“产物”可以进仓库也可以不进但源文件必须在。这样做的好处是任何时候都能找到图的“可编辑版本”改图不需要从零开始。而且版本控制能记录每次改动出问题可以回滚。6.2 命名与目录让图能被找到图多了之后找图就成了问题。我的做法是给图建立命名规范文件名用“模块-图类型-版本”的格式比如auth-flow-v2、order-state-v1。所有图放在统一的diagrams目录下按模块分子目录。文档里引用图的时候用相对路径不要用绝对路径。这样任何人拿到仓库都能快速定位到需要的图。命名规范不需要复杂关键是团队内统一并且坚持执行。6.3 图与文档的同步策略图和文档不同步是另一个常见问题。文档改了图没改读者看到的是过时信息。解决办法有两个方案一图内嵌在文档里。用代码化方案图直接写在文档源文件中改文档就是改图天然同步。这是最省心的方案适合结构规整的图。方案二图独立但建立检查机制。如果图必须独立比如拖拽式画的就在文档里标注图的版本号并在每次文档更新时检查相关图是否需要同步。可以做一个简单的检查清单文档改了哪些章节对应哪些图逐一确认。我倾向于方案一能用代码化就用代码化把同步问题消灭在源头。实在不能用代码化的图至少要做到“改文档时顺手看一眼相关图”。6.4 常见维护坑与规避最后列几个我在维护图的过程中踩过的坑供你参考坑一图里写死了具体数据。比如流程图中写了“最多重试 3 次”后来改成 5 次图忘了改。规避方法是把可变参数抽出来图里只写“重试”具体次数在文档正文里说明。坑二一张图承担太多职责。既想表达流程又想表达状态结果两边都不清楚。规避方法是拆图一张图一个维度。坑三图没有标题和说明。读者不知道这张图在讲什么。规避方法是每张图都加标题必要时加一句说明。坑四颜色语义不一致。这张图红色表示错误那张图红色表示重点。规避方法是建立全文档统一的颜色语义表画图时对照使用。提示如果你刚开始做图的工程化管理不要一次上太多规范。先从“源文件进版本控制”和“统一命名”这两条做起跑顺了再加别的。7. 我在这件事上的几个真实体会做了这么多图我最大的体会是图的质量不取决于你用了多高级的工具而取决于你在画之前想了多少。那些看起来干净利落的图背后都是先把结构想清楚了才动手的。反过来那些画得乱七八糟的图往往是边画边想最后结构失控。第二个体会是图是给人看的不是给工具看的。很多人画图时盯着工具里的对齐线、网格、样式面板却忘了读者会怎么读这张图。每次画完我都会把图缩小到 50% 看一眼——如果缩小后还能看出主要结构说明图是清晰的如果缩小后变成一团糊说明信息密度太高或者层级没拉开。第三个体会是维护成本要在画图之前就考虑。一张图如果三个月后要改那它就不应该用“画完就丢”的方式来做。源文件、命名、版本控制这些事看起来是“额外工作”实际上是省未来的时间。我见过太多团队在“重画图”上浪费的时间远超当初建立规范的成本。最后一个体会是关于拆图的宁可多画几张简单的图也不要画一张复杂的图。读者的耐心是有限的一张图如果三十秒内看不懂大概率就不会再看了。拆成几张图每张聚焦一个点读者反而愿意逐张看下去。这个道理和写文档一样——长文档要分章节复杂的图也要分层次。 
长河君 · 2026/10/21 19:56:52 · 阅读 1.2k diagram-design：从图形选型到工程化维护的图表设计指南
1. 从“diagram-design”这个标题能读出什么第一次看到“diagram-design”这个标题我脑子里蹦出来的不是某个具体工具而是一类非常典型的工作场景手里有一堆零散的信息——流程、层级、关系、时序、状态流转——需要用一张图把它们讲清楚而且这张图还得好看、好懂、好维护。很多人以为画图就是拖拖拽拽真做过项目的人都知道图这东西一旦进入正式文档、技术方案、产品说明它就不再是“随便画画”而是一种信息压缩和认知传递的设计工作。“diagram-design”拆开看核心落在两个词上diagram图表/示意图和 design设计。它指向的不是单纯的绘图技巧而是“如何设计一张图”。这背后至少包含四层需求第一层是选型什么内容该用什么图第二层是结构图的节点、连线、分组怎么组织第三层是视觉颜色、字号、间距、对齐怎么处理第四层是维护图怎么跟着内容一起迭代而不至于每次重画。这四层里前两层决定图对不对后两层决定图好不好用。我见过太多团队在这件事上翻车。有人用流程图去表达一个本质上是状态机的逻辑结果图画得密密麻麻还是说不清有人把架构图画成了“框框连连看”每个框里塞满文字读者看三秒就放弃还有人图做得挺漂亮但源文件丢了改一个字段要重新画一遍。所以这篇内容我想聊的不是“哪个画图工具最好”而是把 diagram-design 当成一个完整的设计问题来拆从需求判断到图形选型从结构搭建到视觉规范再到工程化维护把这条链路走通。适合谁看如果你是技术写作者、产品经理、架构师、设计师或者任何需要把复杂信息可视化的人这篇都能对上号。如果你只是偶尔画个简单示意图也能从里面挑几招直接用。下面我按自己实际做项目的顺序一层层往下拆。2. 先判断“该不该画图”再决定“画什么图”2.1 什么内容值得用图表达不是所有信息都适合画图。我踩过的第一个坑就是“为了画图而画图”——把一段本来三句话能说清的内容硬做成一张图结果读者要花更多时间解读图形符号。判断标准其实很简单当信息之间存在“关系”且这种关系用文字描述会变得冗长或容易歧义时图才有价值。具体来说以下几类内容天然适合图形化流程与分支多个步骤按顺序执行中间有条件判断和回流。文字描述会变成“先做A如果满足X则做B否则做C做完B或C之后再回到A”读起来累画成流程图一目了然。层级与包含组织架构、目录结构、模块划分。这类内容的核心是“谁在谁里面”用嵌套矩形或树形图最直观。时序与交互多个角色之间按时间顺序交换消息。这类内容用文字写就是流水账用时序图能同时表达“谁和谁”“先后顺序”“消息内容”三个维度。状态与迁移一个对象在不同状态之间切换以及触发切换的条件。状态机图是这类内容的专属表达。关系与拓扑节点之间的连接关系比如网络拓扑、依赖关系、数据流向。这类图的重点是“连接”不是“顺序”。反过来如果内容只是并列的几条要点没有顺序、没有层级、没有连接关系那用列表就够了硬画成图反而增加认知负担。我自己的经验法则是如果一段文字里出现了“然后”“如果”“回到”“同时”“依赖于”这类关系词超过三次就值得考虑画图。2.2 图形选型对照表确定要画图之后下一步是选对图形类型。这一步错了后面怎么调都别扭。我整理了一张常用图形与适用场景的对照表基本覆盖了日常工作中八成以上的需求图形类型核心表达适用场景不适用场景流程图步骤顺序与条件分支业务流程、算法逻辑、操作步骤表达状态循环、多角色交互状态机图状态与迁移条件订单状态、连接状态、生命周期表达线性步骤时序图角色间按时间交互接口调用、协议交互、消息流转表达静态结构架构图模块划分与依赖系统分层、服务关系、部署结构表达执行顺序树形图层级与包含目录结构、分类体系、组织架构表达交叉连接关系图节点间连接数据模型、依赖网络、拓扑表达严格顺序甘特图任务与时间跨度项目排期、并行任务表达逻辑依赖细节选型时还有一个容易被忽略的点一张图只表达一个核心维度。我见过有人试图在一张图里同时表达流程、角色和时间结果画出来像蜘蛛网。正确做法是拆成多张图每张图聚焦一个维度图与图之间用编号或引用关联。比如一个完整的下单系统可以用一张架构图讲模块划分一张时序图讲下单交互一张状态机图讲订单状态流转三张图各司其职读者按需查阅。2.3 先画草图再上工具这一步很多人跳过但它直接决定最终图的质量。我的习惯是在打开任何绘图工具之前先用纸笔或白板把节点和连线列出来。这个阶段只关心“有哪些元素”和“它们怎么连”完全不考虑美观。具体做法是把所有节点写成短句或关键词然后问自己三个问题——哪些节点是同一类、哪些节点之间有直接关系、哪些节点是起点和终点。回答完这三个问题图的基本骨架就出来了。这时候再上工具你是在“翻译”一个已经想清楚的结构而不是在工具里一边想一边画。后者最容易出现的问题是画到一半发现结构不对推倒重来时间全浪费在调整布局上。提示草图阶段用不同颜色的笔区分“确定的节点”和“待确认的节点”能帮你快速识别信息缺口避免把不确定的内容画进正式图里。3. 结构设计让图“读得下去”的底层逻辑3.1 节点粒度一个节点只装一件事图读不下去十有八九是节点粒度出了问题。最常见的错误是把一整段描述塞进一个框里框比别的框大五倍读者视线被它吸住整个图的节奏就乱了。我的原则是一个节点只承载一个概念节点内的文字控制在两行以内。如果某个节点的内容确实很多说明它应该被拆成多个节点或者把细节移到图外的注释里。举个例子画一个“用户登录”流程不要写“用户输入账号密码并点击登录按钮系统校验账号密码是否正确”而是拆成“输入凭证”“提交登录”“校验凭证”三个节点。拆开之后每个节点都短连线关系也清晰读者一眼就能扫完。节点粒度还影响图的扩展性。粒度粗的图加一个新步骤就要动大手术粒度细的图加节点只是多一个框和一条线。所以从维护角度看宁可拆细不要合并。3.2 连线规则减少交叉明确方向连线是图的血管血管乱了图就废了。减少连线交叉有几个实用技巧分层布局把节点按“阶段”或“层级”排成几行连线尽量在相邻行之间走避免跨行大跨度连接。统一方向流程图统一从上到下或从左到右不要一会儿横一会儿竖。方向统一之后读者不需要思考“这条线往哪走”。合并同类连线如果多个节点都指向同一个目标可以用一条总线汇聚而不是画多条平行线。用颜色区分连线类型比如实线表示主流程虚线表示异常分支不同颜色表示不同角色。但颜色不要超过三种否则就变成彩虹图了。方向性上箭头是必须的但箭头太多也会造成视觉噪音。一个折中方案是主流程用箭头辅助关系用无箭头连线或虚线。这样读者能快速区分“主要路径”和“次要关联”。3.3 分组与边界用容器表达“归属”当图里的节点超过十五个就需要分组了。分组的作用是告诉读者“这几个节点是一伙的”。常见的分组方式有矩形框最直接把相关节点框在一起框上标组名。背景色块比矩形框更轻量适合分组边界不需要强调的场景。泳道按时序图或流程图中的角色划分每个角色一条泳道节点放在对应泳道里。分组的关键是边界要清晰组名要具体。我见过有人用“其他”作为组名这种分组等于没分。组名应该是一个有意义的概念比如“认证模块”“数据层”“外部依赖”。另外分组不要嵌套太深两层基本是上限三层以上读者就晕了。3.4 一张图的信息密度控制信息密度是图设计里最微妙的平衡。太稀疏图显得空洞读者觉得“这点东西也值得画图”太密集读者直接放弃。我的经验值是一张图里的节点数量控制在 7 到 15 个之间连线数量控制在节点数量的 1.5 倍以内。超过这个范围就要考虑拆图。拆图的方式有两种一种是按维度拆比如把“流程”和“状态”拆成两张图另一种是按层级拆先画一张总览图每个模块再画一张细节图。总览图用编号标注模块细节图用同样的编号读者可以按图索骥。注意拆图之后一定要有“导航”也就是告诉读者这几张图之间的关系。最简单的做法是在每张图下方写一句“本图是总览图中模块 3 的展开”。4. 视觉规范让图“看起来专业”的具体参数4.1 字体与字号可读性优先图的视觉问题里字体和字号是最容易被忽视的。很多人画完图觉得“哪里不对”但又说不上来往往就是字体在作祟。我的建议是字体统一全图只用一种字体中文用无衬线字体如思源黑体、苹方英文用对应的无衬线字体。不要混用衬线和无衬线。字号分级标题字号、节点字号、注释字号拉开差距。一般标题 16-20px节点文字 12-14px注释 10-12px。差距太小层级出不来差距太大注释看不清。行高适中节点内多行文字的行高设为字号的 1.4 到 1.6 倍太挤读起来累太松显得散。还有一个细节节点内的文字对齐方式要统一。要么全部左对齐要么全部居中不要有的左对齐有的居中。左对齐适合文字较多的节点居中适合短标签。4.2 配色三色原则与语义色配色是图设计里最容易“用力过猛”的地方。我的原则是主色不超过三种每种颜色有明确的语义。具体做法是选一个主色用于主要节点一个辅助色用于次要节点或强调一个中性色灰用于背景和辅助线。如果还需要区分更多类别用同色系的不同深浅而不是引入新色相。比如主色是蓝色可以用深蓝、中蓝、浅蓝区分三个层级视觉上仍然统一。语义色是进阶技巧让颜色承载信息。比如绿色表示“正常/成功”红色表示“异常/失败”黄色表示“警告/待定”。这样读者不需要看图例就能理解节点含义。但语义色一旦确定全图甚至全文档都要保持一致不能这张图绿色表示成功那张图绿色表示待办。4.3 间距与对齐专业感的来源如果说配色决定图“好不好看”那间距和对齐决定图“专不专业”。这两点做不好图会显得很“业余”但很多人又说不清问题在哪。间距的核心是一致性节点之间的水平间距一致垂直间距一致节点内文字与边框的间距一致。我通常用 8px 作为基础间距单位所有间距都是 8 的倍数8、16、24、32。这样图看起来会有一种内在的节奏感。对齐的核心是网格把所有节点对齐到隐形的网格上。大多数绘图工具都有“对齐到网格”或“智能参考线”功能一定要打开。对齐之后即使节点大小不一整体也会显得整齐。我见过最有效的改进就是把一张图里所有节点的左边缘对齐专业感立刻提升一个档次。4.4 图例与标注降低理解成本图例不是每张图都需要但如果图里用了颜色、线型、形状来区分含义就必须有图例。图例的位置一般在图的右下角或下方不要放在图中间干扰阅读。标注比图例更灵活用于解释特定节点或连线的细节。标注的写法有讲究用短句不用长句用具体名词不用代词。比如“此处超时重试三次”比“这里会做一些处理”有用得多。标注的引线要指向明确不要指向空白区域让读者猜。5. 工具选型不同场景下的取舍5.1 代码化绘图 vs 拖拽式绘图工具选型上最大的分水岭是“代码化绘图”和“拖拽式绘图”。两者没有绝对优劣关键看场景。代码化绘图如 Mermaid、Graphviz、PlantUML 这类文本描述生成图形的方案的优势是图的内容可以进版本控制改动能追溯批量修改方便改一个定义全图生效适合结构规整、节点多的图和文档系统集成好改文档时图自动更新劣势是布局控制力弱复杂图容易排得难看学习成本高需要记语法不适合需要精细视觉调整的场景拖拽式绘图如各类在线白板和桌面绘图软件的优势是所见即所得布局完全可控上手快不需要学语法适合视觉要求高、结构不规整的图劣势是源文件容易丢改图靠手动多人协作时版本混乱图多了之后维护成本高我的实际做法是混合使用结构规整、需要频繁更新的图如流程图、时序图、状态机图用代码化方案视觉要求高、一次性或低频更新的图如架构总览、宣传用图用拖拽式方案。两者不是对立的而是各管一段。5.2 选型时容易忽略的三个维度除了“代码还是拖拽”选型时还有三个维度容易被忽略第一导出格式。图最终要放到哪里如果是文档需要矢量格式SVG、PDF如果是演示需要高分辨率位图PNG如果是网页SVG 最合适。选工具前先确认它能不能导出你需要的格式。第二协作方式。是单人画还是多人改多人改的话工具是否支持实时协作、评论、版本历史如果团队里有人不熟悉工具学习成本也要算进去。第三长期维护。这张图三个月后还要改吗如果要改源文件在哪里改的人能不能找到我见过太多“图在文档里源文件在某人电脑里某人离职了”的悲剧。所以源文件必须和文档放在一起或者用代码化方案让图本身成为文档的一部分。5.3 我的工具组合与使用场景说具体一点我目前的组合是这样的流程图、时序图、状态机图用文本描述生成源文件直接写在 Markdown 里和文档同源。改文档的时候顺手改图不会出现图和文档不一致的情况。架构图、部署图用拖拽式工具画导出 SVG 放进文档。这类图视觉要求高且更新频率低拖拽式更合适。草图、讨论用图用在线白板快速画完截图发群里不追求精度追求速度。复杂关系图用自动布局的图形描述语言让工具算布局人只负责定义节点和关系。这个组合的核心逻辑是让图的维护成本跟它的更新频率匹配。更新频繁的用代码化更新少的用拖拽式一次性的用白板。6. 从“画完”到“维护好”图的工程化6.1 源文件管理图也要进版本控制图最大的维护痛点是“源文件丢失”。解决办法只有一个把图的源文件当成代码来管理。具体来说代码化方案的源文件本身就是文本直接进版本控制和文档放同一个仓库。拖拽式方案的源文件如 .drawio、.fig 等也要进仓库不要只存导出的图片。导出的图片作为“产物”可以进仓库也可以不进但源文件必须在。这样做的好处是任何时候都能找到图的“可编辑版本”改图不需要从零开始。而且版本控制能记录每次改动出问题可以回滚。6.2 命名与目录让图能被找到图多了之后找图就成了问题。我的做法是给图建立命名规范文件名用“模块-图类型-版本”的格式比如auth-flow-v2、order-state-v1。所有图放在统一的diagrams目录下按模块分子目录。文档里引用图的时候用相对路径不要用绝对路径。这样任何人拿到仓库都能快速定位到需要的图。命名规范不需要复杂关键是团队内统一并且坚持执行。6.3 图与文档的同步策略图和文档不同步是另一个常见问题。文档改了图没改读者看到的是过时信息。解决办法有两个方案一图内嵌在文档里。用代码化方案图直接写在文档源文件中改文档就是改图天然同步。这是最省心的方案适合结构规整的图。方案二图独立但建立检查机制。如果图必须独立比如拖拽式画的就在文档里标注图的版本号并在每次文档更新时检查相关图是否需要同步。可以做一个简单的检查清单文档改了哪些章节对应哪些图逐一确认。我倾向于方案一能用代码化就用代码化把同步问题消灭在源头。实在不能用代码化的图至少要做到“改文档时顺手看一眼相关图”。6.4 常见维护坑与规避最后列几个我在维护图的过程中踩过的坑供你参考坑一图里写死了具体数据。比如流程图中写了“最多重试 3 次”后来改成 5 次图忘了改。规避方法是把可变参数抽出来图里只写“重试”具体次数在文档正文里说明。坑二一张图承担太多职责。既想表达流程又想表达状态结果两边都不清楚。规避方法是拆图一张图一个维度。坑三图没有标题和说明。读者不知道这张图在讲什么。规避方法是每张图都加标题必要时加一句说明。坑四颜色语义不一致。这张图红色表示错误那张图红色表示重点。规避方法是建立全文档统一的颜色语义表画图时对照使用。提示如果你刚开始做图的工程化管理不要一次上太多规范。先从“源文件进版本控制”和“统一命名”这两条做起跑顺了再加别的。7. 我在这件事上的几个真实体会做了这么多图我最大的体会是图的质量不取决于你用了多高级的工具而取决于你在画之前想了多少。那些看起来干净利落的图背后都是先把结构想清楚了才动手的。反过来那些画得乱七八糟的图往往是边画边想最后结构失控。第二个体会是图是给人看的不是给工具看的。很多人画图时盯着工具里的对齐线、网格、样式面板却忘了读者会怎么读这张图。每次画完我都会把图缩小到 50% 看一眼——如果缩小后还能看出主要结构说明图是清晰的如果缩小后变成一团糊说明信息密度太高或者层级没拉开。第三个体会是维护成本要在画图之前就考虑。一张图如果三个月后要改那它就不应该用“画完就丢”的方式来做。源文件、命名、版本控制这些事看起来是“额外工作”实际上是省未来的时间。我见过太多团队在“重画图”上浪费的时间远超当初建立规范的成本。最后一个体会是关于拆图的宁可多画几张简单的图也不要画一张复杂的图。读者的耐心是有限的一张图如果三十秒内看不懂大概率就不会再看了。拆成几张图每张聚焦一个点读者反而愿意逐张看下去。这个道理和写文档一样——长文档要分章节复杂的图也要分层次。