企业官网建设流程全解析

前几个月做一个内部项目，需要向协作方讲清楚一条跨系统的调用链路。我打开在线画图工具，拖了四十多个框出来，连上线，标好颜色，自认为信息很全。发给对方之后，收到的反馈只有一句：这图我看不懂。

这句"看不懂"让我重新认真对待 diagram-design 这件事。画图的门槛看起来极低，拖拖拽拽谁都会，但真正能让人三秒抓住重点、顺着箭头走完全程的图，门槛其实相当高。这篇内容是我近一年在 diagram-design 上的完整复盘，涉及读者分析、工具取舍、画图流程、实战迭代和长期维护，适合那些经常要画架构图、流程图、时序图，却总觉得图"不够清楚"的开发者和产品同学。

1. 先搞清楚一件事：你画的图是给谁看的

1.1 一次"看图失败"引发的重新思考

那天我画的是一套跨模块的异步消息链路，四十多个节点，二十多条线，还用了四种颜色区分不同服务。发到协作群之后，对面负责业务的同事问了一句："我就想知道订单状态更新之后接下来发生啥，你这图里在哪？"

我指着左上角那一堆框说，从这儿开始。他又问："那我为啥要看完右边这些？"我一时答不上来。右边那些是日志采集、监控告警的旁路节点，对他的问题毫无意义，但在我的图里，它们和核心链路占据着同样醒目的位置。

这件事让我意识到，diagram-design 的第一个问题永远不是"用什么工具"，而是"读者是谁、他要带走什么信息"。同一套系统，给架构评审画的图、给业务方讲链路画的图、给新人做 onboarding 画的图，完全可以长成三个样子。一张图想讨好所有人，最后往往谁都用不了。

1.2 三种典型读者和对应的信息取舍

我把日常遇到的读者粗分成三类，每一类的关注点和画法差别很大：

• 决策型读者：关注边界、依赖关系、风险点。他们要的是整体拓扑和模块职责，不需要知道每个接口字段。
• 执行型读者：关注具体流程、输入输出、异常分支。他们要的是主链路和分支条件，不需要看部署拓扑。
• 排查型读者：关注时序、状态流转、故障入口。他们需要的是事件顺序和因果链。

对应的画法完全不同。给决策型读者画，要突出分组和边界，用大色块区分领域，连线只画关键依赖；给执行型读者画，要从触发事件开始，沿着流程一步步走，分支画全但旁路灰化；给排查型读者画，要用泳道或时序的表达方式，把"谁在什么时间调了谁"讲清楚。

我见过的大部分烂图，根因不是画得不够多，恰恰是画得太全。把三类读者的需求硬塞进一张图，结果就是谁都没法快速拿到自己关心的东西。画之前先问一句"这张图给谁看"，能省掉后面所有返工。

1.3 信息密度的"三秒法则"

我后来给自己定了一个粗糙的检验办法：把图发给一个不了解上下文的人，让他看三秒，然后说出这张图在讲什么。如果他说不出来，说明图的视觉重心是散的，需要重画。

三秒法则背后是很朴素的认知心理学常识：人眼的注意力有限，第一眼只会落在面积最大、颜色最亮、线条最粗的元素上。如果你把所有元素都设计得同样醒目，那就等于没有重点。diagram-design 的核心能力，本质上是"做减法"的能力。

我现在遵守一条铁律：每张图只允许有一个视觉焦点。主链路用实线、饱和色；辅助流程用虚线、灰调；纯背景信息直接不画。读者需要更多细节时，他自然会放大、看注释、问你要第二种图，但第一眼你必须告诉他"该看哪儿"。

2. 工具选型：别让工具限制你的表达

2.1 四类工具和它们各自的主场

先说结论：没有万能工具，只有匹配场景的工具。我日常实际在用的大概四类，每一类都有自己的主场。

第一类是轻量拖拽型，包括在线白板工具和本地开源的轻量画图工具。它们最适合画"快速沟通图"——需求讨论、方案说明、评审草图。优点是上手零成本，拖拖拽拽几分钟就能出图；缺点是规范性差，同一个箭头在不同人手里可能表达完全不同的意思，图一复杂就乱。

第二类是文本描述型工具，用代码写图的描述，再生成图形。它最适合画"需要反复修改的工程图"，尤其是时序图、状态图这类结构重复度极高的图。优点是可版本化、可 diff、改起来快，一段文本就能完整表达结构；缺点是布局控制不自由，学习曲线也比拖拽型陡一些。

第三类是专业图表软件，适合画网络拓扑、机房布线、组织架构这类对图形规范要求极高的场景。优点是元素库完整、画出来非常标准；缺点是偏重、偏贵，协作体验一般，画逻辑图有点杀鸡用牛刀。

第四类是通用设计工具，适合画"最终要进文档、进 PPT、进官网"的高质量配图。好处是排版、配色、字体完全可控，能画出很有质感的成品；坏处是它本质是设计工具，画逻辑图偏重，维护成本也高。

2.2 两种范式的取舍：拖拽和文本描述

我见过很多团队在工具选型上吵得不可开交。其实核心矛盾就一个：拖拽型所见即所得，但改起来没有"痕迹"；文本描述型有"源码"，可以追踪变更，但预览和布局控制没那么自由。

我的选择标准很粗暴：如果只是几个人快速对齐思路，拖拽型完胜，别纠结规范和溯源；如果这张图要进文档库、要长期维护、要多人修改，那就必须用文本描述型，或者至少给拖拽型图配上严格的版本管理。

原因很简单。拖拽型图最大的问题不是画不出来，而是三个月后没人记得当初为什么这么连。文本描述型强制你把节点和关系写成可读的文本，每次改动都有记录，哪怕后来的人看不懂图，也能通过描述里的注释还原当时的思路。

2.3 我的实际组合：快图、活图和精图

我跑了快一年，固定组合是这样：日常沟通图用轻量拖拽工具，随开随画，用完就扔；正式文档里的架构图、时序图、状态图，用文本描述型工具生成，源文件跟着代码仓库走；要上 PPT 和对外文档的高质量图，最后在通用设计工具里重新排一版。

这套组合看起来折腾，实际跑下来很顺。因为 90% 的图都是"沟通完就作废"的，只有剩下 10% 需要长期活着。正式化是有成本的，这个成本要花在真正需要长期活着的图上，而不是每张图都追求"最终成品"。

3. 我整理的一套四步画图法

3.1 第一步：先写文字骨架，再碰画布

我踩过最大的坑，就是拿起工具就画。看起来效率很高，其实画到一半逻辑就乱，然后开始疯狂删框、挪位置、改连线，最后画出来的东西连自己都看不下去。

现在的第一步永远是拿文本编辑器写"图稿"。比如画一个订单超时关闭的流程，我先把逻辑写成几行字：触发条件是用户下单后 30 分钟未支付；定时任务扫描符合条件的订单；加锁并标记超时关闭中；判断库存是否可释放；释放库存、记录超时日志；通知消息服务推送提醒。

写完这几行，再判断图形结构。这六行是线性流程，用普通流程图；如果还涉及多个服务之间的来回调用，就得考虑泳道；如果重点是状态变化，优先画状态图。文字骨架最大的好处是逼你先想清楚"有哪些节点"和"节点之间什么关系"，而不是被一块空白画布吓到。

3.2 第二步：按表达目的选图型、定画布方向

文字稿确定之后，就要决定"用哪种图表达"。我通常按这套规则选，省脑子的很：

• 关心"谁在什么时候做了什么" → 时序图或泳道图
• 关心"一件事的先后顺序和分支" → 流程图
• 关心"系统由哪些模块组成、谁依赖谁" → 架构图
• 关心"一个对象的所有可能状态" → 状态图
• 关心"数据从哪来到哪去" → 数据流图

选型之后是画布结构。我的习惯是"从上到下"或"从左到右"二选一：主流程从上往下走，辅助说明放侧面；泳道按角色分列，时间从上往下推进。画布方向一旦确定，整张图的阅读方向就确定了，读者顺着方向走，不会迷路。

3.3 第三步：让颜色、线型和箭头只说语义

这一步是我最想分享的心得。很多图视觉混乱，是因为颜色随便用、线型随便选、箭头方向不统一。我给自己定了五条死规则，违反任何一条都直接返工：

第一，颜色必须有语义，只用于表达"类别或状态"，不用于装饰。比如所有外部系统一种色，所有内部服务一种色，所有数据存储一种色。

第二，实线代表"已实现的正式调用"，虚线代表"异步、事件或旁路"，两种线不可以混着表达。

第三，箭头方向统一指向数据或控制的流向目的地，不要一会儿从发起到接收，一会儿从接收到发起。

第四，文字标签放在线条的中部上方，不要断线，不要叠在节点框上。

第五，同一张图里，同一种图形只表达同一种含义：矩形是服务或模块，圆角矩形是状态或流程步骤，菱形是判断，圆柱是存储。不要今天这个意思、明天换个意思。

这些规则听起来基础到近乎啰嗦，但你翻翻身边项目里的图，十条有八条违反。视觉表达一旦混乱，读者就只能靠猜。

3.4 第四步：交付前一晚的陌生化检查

画完之后，我通常不会立刻发出去，而是把图放一晚上，第二天当作自己完全没参与过，重新看一遍。检查顺序固定：

先看整体，第一眼落在哪，是不是我想让它落的地方；再看主链路，能不能不读任何注释、只顺着实线走一遍；接着看分支，每个分支有没有明确的"是/否"或者"成功/失败"标签；最后看细节，字体大小是否一致、命名是否统一，比如同一张图里别一会儿写"订单服务"一会儿写"order-service"。

陌生化检查的核心是换一双眼睛。你画图时脑子是满的，所有省略你都默认读者知道，但读者真的什么都不知道。放一晚上这个动作看起来笨，却是性价比最高的排错手段。

4. 实战复盘：一张系统架构图的三轮迭代

4.1 第一版：什么都想画，结果什么都没讲清

我拿一个模拟项目举例，叫某跨平台订单系统，涉及客户端、网关、订单服务、支付服务、库存服务、消息队列、日志平台、监控系统。第一版我把所有东西都画进去了：每个服务一个框，框里再画子模块，连了二十多条线，旁边还挂了数据表结构。

结果就是前面说的，没人看得懂，我自己看都觉得累。问题出在哪？我用装饰性颜色给每个服务上了不同色，颜色带不来任何分类信息；我在每个框里堆满细节，导致框与框之间的连接关系被完全淹没；我还把监控、日志这类不属于订单主链路的内容，放在和支付服务同样醒目的位置。

这一版教会我一件事：图的价值不在于信息量，而在于信息结构。堆得越多，结构越模糊。

4.2 第二版：按层次重组，给主链路让路

第二版我做了三件事。第一，把所有节点分成四层：接入层（客户端、网关）、业务层（订单、支付、库存）、基础设施层（数据库、消息队列）、支撑层（日志、监控）。第二，主链路只保留"下单 → 支付 → 库存扣减 → 通知"这一条，用加粗实线表示；支撑层整体灰化放在图底部，只画虚线连到业务层。第三，所有颜色改成按层赋色，接入层一种色，业务层一种色，基础设施一种色，支撑层一种色。

这一版清晰了很多，第一眼就知道系统分几层、主链路在哪。但评审时还是有人问："这四个层之间的调用是从上往下还是从下往上？"我意识到，分层是对的，但箭头方向和层次关系没有协调好。

4.3 第三版：让箭头带着读者走完主流程

第三版我定了一条硬规矩：主流程的箭头一律从上往下、从左往右，不允许出现回头线。回头线是架构图的大忌，读者一旦要掉头，就得在图上反复横跳。

对于"订单创建后要异步通知支付结果"这种确实需要回流的场景，我把它单独拿出来，在图右侧画了一个局部时序图，而不是硬塞进主架构图里。改完的效果很明显：一个新同事第一次看这版图，顺着箭头不到一分钟就走完了主流程，还能独立回答出"支付失败会走哪条线"这种问题。

这三轮迭代让我最大的体会是：改图不是改细节，是改取舍。每一轮都在问同一个问题——读者最需要看到什么？答案清晰了，图自然就清楚了。

5. 比画图更重要的两件隐性工作

5.1 图也是资产，要跟着代码一起进版本管理

很多团队把图当成一次性产物，画完丢共享网盘，连文件名都不规范。半年后要更新，先得花半小时找"最终版_改3_真的最终版.png"。这种事我干过太多次。

如果你用文本描述型工具画图，这个问题天然就解决了——源文件跟着代码仓库走，每次改动有记录、有历史、能对比。如果必须用拖拽型工具，那就约定好导出统一的源格式，放进专门目录，并且每次内容变更必须配提交说明。

我的习惯是仓库里建一个 diagrams 目录，按项目分文件夹，命名规则统一，比如"项目名-图类型-主题"。任何人想找图，路径是确定的，不需要问人。

5.2 建一份自己的图元素库和参考案例集

画图画多了会发现大量重复：一样的服务节点、一样的箭头风格、一样的层次布局。每次从零画一遍是巨大的浪费，而且风格还不统一。

我目前维护一份自己的图元素库：常用服务节点模板、数据库节点模板、消息队列模板、三套配色方案、几种标准布局骨架，全都存成可复用格式。画新图时直接拖模板，几分钟就能出初稿。

另外，我会把画得好的图存成参考案例，旁边用注释写清楚这张图好在哪里、用的什么布局、颜色怎么分的。下次画同类图之前先翻一遍，能少走很多弯路。这比收藏一堆网上教程有用得多，因为参考案例是你自己验证过的。

5.3 关于提升画图能力的一件小事

工具、模板、流程全是外围，真正决定图的质量的，是动笔之前有没有想清楚读者要什么。我见过有人用很普通的工具画出非常清楚的图，也见过有人用顶级工具画出一团乱麻。

如果你也想提升 diagram-design 的能力，我建议从一件小事开始：把你最近画过的一张"自己觉得挺好"的图拿出来，用三秒法则自测一遍，然后试着把节点删掉一半，看看信息是不是反而更清楚了。我自己做过几次这个练习，印象最深的是第一次——删完一半节点之后，那张图居然比我精心画了三个小时的原版更容易看懂。这个练习做上十次，你再看图的感觉会完全不一样。