1. 从一张草图到一套系统：diagram-design 到底在解决什么问题
第一次听到 “diagram-design” 这个词，很多人会下意识觉得它只是“画图”的另一种说法。但真正在项目里被图表折磨过的人知道，画图本身从来不是最痛的部分。最痛的是：图画完了，需求变了；图改完了，风格不统一；风格统一了，换个人接手又看不懂。diagram-design 要处理的，正是这一连串“画完之后”的问题。
我把它理解成一套围绕图表展开的设计方法论加落地工具链。它不局限于某一种图形，也不绑定某一个软件，而是把“信息结构—视觉表达—协作维护”这三件事串成一条线。你手里可能是一张业务流程、一张系统架构、一张数据流转图，甚至是一张给非技术同事看的说明图，diagram-design 关心的是：这张图有没有把该说的事说清楚，能不能被别人接着改，改完之后还保不保持一致性。
它适合的人比想象中广。产品经理拿它梳理需求链路，研发拿它画架构和时序，设计师拿它统一视觉语言，运营拿它做活动流程说明。哪怕你只是偶尔要出一张汇报用的结构图，这套思路也能让你少返工几次。核心价值就一句话：让图表从“一次性消耗品”变成“可维护的资产”。这也是我后面所有内容的主线，围绕它拆思路、拆细节、拆实操、拆踩坑。
2. 内容整体设计与思路拆解
2.1 为什么图表项目总是“画完就废”
先说说我观察到的普遍现象。大部分团队的图表生命周期是这样的：有人要一张图，找个人花两小时画出来，发到群里，大家点个赞，然后这张图就死了。等到三个月后要改，原文件找不到，找到了也看不懂当时为什么这么画，于是重新画一张。周而复始，团队里堆了几十张风格各异、逻辑打架的图。
问题不在画图的人不努力，而在于缺少设计层面的约束。没有约束，每个人凭手感画，手感这东西不可复制、不可传承。diagram-design 的第一个设计思路，就是先把“约束”立起来。约束包括三层：语义约束（什么形状代表什么）、视觉约束（颜色、字号、间距的规则）、结构约束（图的组织方式和命名方式）。这三层立住了，图才可能被复用。
我试过在没有任何约束的情况下让三个人画同一张流程图，结果三个人用了三种箭头含义、四种配色、两种布局方向。这不是能力问题，是规则缺失。所以 diagram-design 的起点不是工具，是规则。
2.2 方案选型：为什么是“设计系统”而不是“画图技巧”
市面上讲画图的内容，绝大多数在教技巧：怎么对齐、怎么调色、怎么用某个软件的某个功能。技巧有用，但技巧解决的是“这一张图”，解决不了“一百张图”。diagram-design 走的是设计系统的路子，这背后有明确的取舍。
设计系统的核心是把决策前置并固化。比如颜色，不是每次画图现挑，而是提前定义好一套语义色板：主流程用什么色、异常分支用什么色、外部依赖用什么色。这样任何人画图，只要按语义选色，出来的图天然一致。再比如形状，矩形代表什么、圆角矩形代表什么、菱形代表什么，提前约定好，读者不需要每次重新学习图例。
这个选择的优势在于可扩展性和可维护性。代价是前期要花时间搭规则。我的经验是，一个五人以上的团队，前期投入半天搭规则，后面能省下几十个小时的返工。人少或者只画一次图，确实没必要上系统，直接画更快。所以选型要看场景，不是所有情况都值得上重装备。
2.3 三层结构：语义层、视觉层、维护层
把 diagram-design 拆开，我习惯分成三层来看，这样理解起来最清楚。
语义层管的是“图在说什么”。这一层要定义图表的类型体系：流程图、架构图、时序图、状态图、思维导图各自承担什么表达任务，什么场景该用哪种。很多人画图混乱，根源是选错了图类型，用流程图去表达本该用状态图表达的东西，读者自然晕。
视觉层管的是“图长什么样”。颜色、字体、线型、间距、图标风格，全部在这里定规矩。视觉层的目标是让图在没有文字说明的情况下，读者也能靠视觉线索快速分区、快速定位重点。
维护层管的是“图怎么活下去”。文件怎么命名、版本怎么管理、源文件放哪、导出格式怎么选、变更怎么记录。这一层最容易被忽略，但它决定了图是资产还是垃圾。我见过太多团队语义和视觉都做得不错，就是维护层缺失，半年后图全废了。
三层缺一不可，而且顺序不能乱。先想清楚说什么，再决定长什么样，最后安排怎么维护。反过来做，先纠结配色，往往画到一半发现图类型都选错了。
3. 核心细节解析与实操要点
3.1 语义层：图表类型与表达任务的匹配
语义层最容易犯的错，是“一张图想表达所有事”。我见过一张图里既有业务流程、又有系统架构、还塞了数据表结构，读者看三分钟就放弃了。diagram-design 的做法是一图一任务，每张图只回答一个问题。
具体怎么匹配？我整理了一张对照表，这是我在多个项目里反复验证过的：
| 表达任务 | 推荐图类型 | 关键特征 | 常见误用 |
|---|---|---|---|
| 步骤先后与分支 | 流程图 | 有明确起点终点，箭头表流向 | 用它表达状态循环 |
| 系统组成与依赖 | 架构图 | 分层或分组，强调模块边界 | 混入时间维度 |
| 对象间交互顺序 | 时序图 | 有生命线，强调消息往来 | 用它表达静态结构 |
| 状态迁移 | 状态图 | 状态节点加迁移条件 | 用它表达普通流程 |
| 概念发散与归类 | 思维导图 | 中心辐射，层级展开 | 用它表达精确流程 |
选对类型，图就成功了一半。我个人的判断口诀是：问“然后呢”用流程图，问“谁跟谁”用时序图，问“由什么组成”用架构图，问“现在处于什么阶段”用状态图。这个口诀帮我在需求评审时快速决定该画哪种图，避免画错返工。
还有一个细节：图类型确定后，要明确这张图的读者是谁。给研发看的架构图可以带技术术语，给业务方看的流程图必须去掉实现细节。同一件事，读者不同，图就该不同。这不是偷懒，是尊重读者的认知成本。
3.2 视觉层：颜色、形状、文字的规则化
视觉层的规则化，核心是建立映射关系，而不是追求好看。好看是结果，不是目标。目标是让读者看到某个视觉元素，立刻知道它代表什么。
颜色方面，我建议用语义色板而不是装饰色板。语义色板的意思是，每种颜色绑定一个含义。比如蓝色代表主流程、橙色代表异常或警告、灰色代表外部系统、绿色代表成功终态。这样画图时选色就是选语义，不需要审美判断。色板数量控制在五到七种，多了记不住。颜色之外一定要有第二重区分手段，比如线型或填充，因为要考虑到色觉差异的读者。
形状方面，约定要简单且一致。我的常用约定是：矩形代表处理步骤、圆角矩形代表开始或结束、菱形代表判断、圆柱代表数据存储、虚线框代表外部边界。这套约定不唯一，关键是团队内部统一，并且写进文档。形状一旦约定，就不要随意发明新形状，新形状意味着读者要重新学习。
文字方面，字号层级不要超过三级。标题、正文、注释，三级足够。字号差距要明显，否则层级感出不来。字体选系统自带的无衬线字体最稳，跨平台不会乱。文字对齐方式统一，要么全左对齐，要么全居中，混用会显得很乱。
提示：视觉规则一定要写成文档，最好配一张“图例示例图”。口头约定撑不过两周，文档才能传下去。
3.3 维护层：命名、版本与源文件管理
维护层是 diagram-design 里最不性感但最值钱的部分。我踩过的坑几乎都在这里。图本身画得漂亮，结果源文件叫“新建文件1”，三个月后没人知道它对应哪个需求，只能重画。
命名规则我推荐**“模块-图类型-版本”**三段式，比如“订单模块-流程图-v2”。模块名用团队通用的业务词，图类型用语义层的标准叫法，版本号用 v 加数字。这样在文件夹里排序，一眼就能找到最新的。日期可以放在版本后面，但不是必须，版本号本身已经表达了新旧。
版本管理有个关键决策：源文件和导出文件分开存。源文件是可编辑的，导出文件是给人看的。源文件进版本管理，导出文件按需生成。我见过把导出的图片当源文件存的，想改的时候发现改不了，只能重画。源文件格式尽量选开放或通用的，避免绑定某个特定软件导致以后打不开。
变更记录也要有。不用很复杂，一个表格就行：日期、改了什么、为什么改、谁改的。这张表在需求反复变更的项目里能救命，因为你能快速回答“这个分支为什么长这样”这种问题。没有变更记录，图一旦复杂起来，连原作者都说不清。
4. 实操过程与核心环节实现
4.1 从零搭建一套图表规范：完整步骤
假设你现在要在一个团队里从零落地 diagram-design，我把我实际用过的流程拆成六步，你可以直接照着做。
第一步，盘点现有图表。把团队过去半年画过的图收集起来，看看都用了哪些类型、哪些颜色、哪些形状。这一步的目的是找出混乱点，也为后面的规则提供素材。盘点完你大概率会发现，同类图用了好几种画法。
第二步，确定图类型清单。根据盘点结果，列出团队最常用的三到五种图类型，每种写清楚它的表达任务和适用场景。不要贪多，先把高频的定下来，低频的以后再说。
第三步，定义语义色板和形状约定。色板五到七色，每色绑定含义。形状约定五到八种，每种绑定含义。这一步要拉上实际画图的人一起定，否则规则落地时会被抵触。
第四步，制作模板文件。把色板、形状、字号、间距都做进模板里，画图的人打开模板就能用，不需要每次手动设置。模板是规则落地的关键，没有模板，规则就是纸上谈兵。
第五步，写一份一页纸的规范文档。包含图类型清单、色板含义、形状含义、命名规则、存放位置。一页纸，多了没人看。文档放在团队共享的地方，新人入职第一件事就是读它。
第六步，试点并迭代。选一个正在进行的项目试点，用新规范画图，收集反馈，一个月后调整一次。规范不是一次成型的，是迭代出来的。
4.2 一张流程图的完整设计记录
我拿一张“用户下单流程”的图做例子，完整走一遍设计过程，你能看到每一步的决策依据。
需求是梳理从用户点击下单到订单完成的全部环节，读者是产品和研发。首先定图类型：有步骤、有分支、有终态，选流程图。然后定范围：只画主流程和关键异常分支，支付渠道的内部实现不画，那是另一个模块的事。
接着定节点。主流程节点：提交订单、校验库存、锁定库存、生成订单、发起支付、支付回调、订单完成。异常分支：库存不足、支付超时、支付失败。每个节点用矩形，开始和结束用圆角矩形，判断用菱形。
然后定颜色。主流程用蓝色，异常分支用橙色，终态用绿色，外部系统（支付渠道）用灰色。这样读者一眼就能区分正常路径和异常路径。
再定布局。主流程从上到下，异常分支从右侧引出，避免交叉线。交叉线是流程图可读性的大敌，能避就避。如果实在避不开，用跳线符号标注。
最后定命名和存放。“订单模块-流程图-v1”，源文件放团队图表库的订单目录下，导出 PNG 和 SVG 各一份，PNG 用于文档嵌入，SVG 用于放大展示。
整个过程大概四十分钟，比随手画慢一点，但这张图后面被改了五次，每次改都很快，因为规则清晰，改的人不需要重新理解整张图。
4.3 参数选择：字号、间距、线宽的具体数值
视觉参数这块，很多人凭感觉调，结果就是不一致。我给一套我常用的基准值，你可以在此基础上微调。
字号方面，如果图用于屏幕展示，标题 20 到 24 像素，正文 14 到 16 像素，注释 11 到 12 像素。如果用于打印或大屏，整体放大 1.5 倍。字号层级差距至少 4 像素，否则层级感不明显。
间距方面，节点之间的水平间距建议是节点宽度的 0.5 到 0.8 倍，垂直间距建议是节点高度的 0.8 到 1.2 倍。间距太小显得拥挤，太大显得松散。同一张图里，同类间距必须一致，这是对齐的基础。
线宽方面，主流程线 2 像素，辅助线 1 像素，边界框 1 像素虚线。箭头大小和线宽匹配，线宽 2 像素配中等箭头，线宽 1 像素配小箭头。线宽不要超过三种，多了显得杂乱。
这些数值不是绝对的，但同一套规范内必须统一。统一比精确更重要。我见过有人纠结 14 像素还是 15 像素，其实只要全图统一，14 和 15 读者根本分不出来。
5. 常见问题与排查技巧实录
5.1 图表可读性差的五个典型症状
图画出来读者看不懂，是最常见的问题。我总结了五个典型症状和对应的排查方向。
症状一：读者不知道从哪看起。排查：有没有明确的起点标识，有没有视觉引导（比如加粗的主路径）。解决：给起点加醒目标记，主路径用更粗的线或更深的色。
症状二：读者看一半迷路。排查：交叉线是不是太多，节点是不是太密。解决：重新布局，减少交叉，必要时拆成两张图。
症状三：读者分不清主次。排查：是不是所有节点一样大一样色。解决：用大小和颜色区分主次，核心节点放大或加深。
症状四：读者看不懂符号。排查：有没有图例，图例是不是完整。解决：加图例，图例放在图的角落，不遮挡内容。
症状五：读者看完记不住。排查：信息是不是太散，有没有归纳。解决：用分组框把相关节点框起来，加分组标题。
这五个症状覆盖了我遇到的大部分可读性问题。排查时按顺序过一遍，基本能定位到原因。
5.2 团队协作中的规则冲突与解法
多人协作画图，规则冲突几乎必然发生。最常见的冲突是“我觉得这样更好看”。这时候要回到规则本身：规则是为了可读性和可维护性，不是为了好看。如果新画法确实提升了可读性，那就更新规则，全团队一起改；如果只是个人偏好，那就按现有规则来。
另一个冲突是规则太严导致画图变慢。我的解法是分级执行：核心规则（色板、形状含义）必须严格遵守，次要规则（间距微调、字号微调）允许一定弹性。核心规则保证一致性，次要规则给一点自由空间，这样既统一又不僵化。
还有一种冲突是新人不知道规则。解法很简单：把规范文档放在新人必读清单里，并且安排一次半小时的讲解。我试过只发文档不讲解，新人照样按自己的习惯画。讲解一次，后面省很多事。
5.3 图表维护的常见坑与避坑清单
维护层的坑我踩得最多，整理成清单给你。
- 坑一：源文件丢失。避坑：源文件统一存放，定期备份，命名规范。
- 坑二：版本混乱。避坑：版本号只增不减，旧版本归档不删除。
- 坑三：导出格式单一。避坑：至少导出 PNG 和 SVG 两种，应对不同场景。
- 坑四：变更无记录。避坑：维护一张变更表，改图必记录。
- 坑五：图与文档脱节。避坑：图嵌入文档时用链接而非截图，图更新文档自动更新。
- 坑六：无人负责。避坑：每张图指定一个负责人，负责它的更新和维护。
注意：维护层的投入在项目初期看不出价值，但项目周期超过三个月，它的价值就会指数级显现。别省这个功夫。
6. 工具选型与落地建议
6.1 工具选型的三个判断维度
工具这块我不推荐具体品牌，因为工具更新太快，推荐了也容易过时。我给三个判断维度，你自己套。
维度一：是否支持规则固化。好的工具应该能让你把色板、形状、模板存起来复用，而不是每次从头设置。支持自定义库和模板的工具优先。
维度二：源文件是否开放。源文件格式最好是开放的或通用的，避免绑定某个工具导致以后迁移困难。能导出多种格式的工具更稳。
维度三：协作是否顺畅。多人能不能同时编辑，能不能评论，能不能看到修改历史。协作功能强的工具，在团队场景里省很多沟通成本。
三个维度里，如果只能选一个，我选规则固化。因为规则固化直接决定了一致性，而一致性是 diagram-design 的核心目标。
6.2 小团队与大团队的落地差异
小团队和大团队落地 diagram-design 的策略完全不同，不能照搬。
小团队（五人以下）建议轻量落地：一套色板、一套形状约定、一个模板文件，够了。不需要复杂的版本管理和变更记录，口头同步加一个共享文件夹就能跑起来。重点是快，别让规则成为负担。
大团队（十人以上）建议重量落地：完整的规范文档、模板库、版本管理、变更记录、定期审查。因为人多，口头同步失效，必须靠文档和流程。大团队还要考虑跨部门协作，规则要更明确，否则部门之间画法打架。
我待过的一个中型团队，用的是中间方案：核心规则文档化，模板共享，版本管理用简单的文件夹加日期，变更记录用表格。跑了一年，效果不错。所以落地策略要匹配团队规模，不是越重越好。
6.3 从单张图到图表库的演进路径
diagram-design 的终极形态是图表库，但不要一上来就建库。演进路径我建议分三步。
第一步，单张图规范化。先把一张图按规范画好，验证规范可行。这一步的目标是跑通流程。
第二步，同类图模板化。把高频图类型做成模板，比如流程图模板、架构图模板。这一步的目标是提效。
第三步，图表库成型。把模板、色板、形状库、规范文档、变更记录整合成一个库，新人进来直接用。这一步的目标是传承。
三步走下来，大概需要两到三个月。急不得，跳步容易翻车。我见过直接建库的团队，库建好了没人用，因为规范没经过验证，用起来别扭。所以顺序很重要。
7. 我在实际项目中的几点体会
最后分享几个我自己的体会，都是踩坑踩出来的。
第一个体会：规则的价值在于减少决策，不在于限制创意。很多人抵触规范，觉得规范束缚了表达。其实规范省掉的是重复的、低价值的决策（比如这次用什么颜色），让你把精力放在高价值的决策上（比如这个流程怎么拆更清楚）。想通这一点，接受规范就容易多了。
第二个体会：图的可读性不取决于画图的人，取决于读图的人。你觉得清楚没用，读者觉得清楚才有用。所以画完图一定要找目标读者试读，看他们卡在哪。我试过自己觉得完美的一张图，给同事一看，他第一句话是“从哪开始看”，那一刻我就知道图有问题。
第三个体会：维护层的投入要趁早。我早期画图从不做版本管理和变更记录，觉得麻烦。后来项目周期一长，图改到第五版的时候，我自己都分不清哪版是哪版，只能重画。从那以后，我画第一版就开始记录，后面省了无数时间。
第四个体会：工具是次要的，思路是主要的。我见过用很简单的工具画出极清晰图的人，也见过用很高级的工具画出混乱图的人。工具放大的是你的思路，思路清晰，简单工具也够用；思路混乱，高级工具也救不了。所以先把思路理清楚，再选工具。
这套 diagram-design 的思路，我用了几年，从单张图到团队图表库都跑过。它不是银弹，但确实让图表这件事从“一次性消耗”变成了“可积累的资产”。如果你也在被图表返工折磨，不妨从一张图开始，按语义、视觉、维护三层走一遍，感受一下差别。
