企业官网建设流程全解析

1. 从零搭建 diagram-design 的完整思路

第一次接触 diagram-design 这个方向时，我踩过的最大坑就是把它当成一个纯画图工具。实际上，diagram-design 的核心价值在于把"设计思维"和"图表表达"这两件事捏在一起——它不是让你画得好看，而是让你画得"对"。很多人一上来就打开工具开始拖拽方框，结果画到一半发现逻辑根本走不通，只能推倒重来。这篇文章我会把整个流程拆开，从需求梳理、结构设计、视觉规范到最终交付，每一步都讲清楚为什么这么做，以及我实际踩过的坑。

diagram-design 适合谁看？如果你是需要画架构图、流程图、时序图、状态机图的技术人员，或者是需要把复杂逻辑讲清楚的产品、运营、设计从业者，这篇文章都能给你一套可以直接抄作业的方法。哪怕你之前完全没接触过图表设计，跟着走一遍也能画出结构清晰、逻辑自洽的图。

我个人的核心观点是：图表设计 80% 的功夫在画之前，20% 在画的过程中。下面这张表是我总结的常见误区与正确做法对比，先建立一个整体认知。

2. 画之前必须想清楚的三件事

2.1 这张图到底要回答什么问题

我见过太多人画图时脑子里只有一个模糊的"我要画个架构图"，结果画出来的东西谁看了都不知道重点在哪。正确的做法是：在动手之前，用一句话写出这张图要回答的核心问题。

比如"这张图要说明用户下单后系统内部经过了哪些服务"、"这张图要说明订单状态在哪些条件下会发生流转"。这句话写不出来，就说明你还没想清楚，这时候画图纯属浪费时间。

这句话还有一个作用：它是你后续所有取舍的判断标准。当你在纠结某个细节要不要画进去时，就问自己"这个细节和核心问题相关吗"，不相关就果断砍掉。图表设计的本质是做减法，不是做加法。

2.2 读者是谁，他们带着什么背景知识来

同一个系统，给不同的人看，图完全不一样。给运维看的部署图要标清楚机器、端口、网络区域；给产品经理看的业务流程图要标清楚角色、动作、判断条件；给新人看的入门图要从最基础的概念讲起。

我一般的做法是：在图的角落或者配套文档里写清楚"本图假设读者已经了解 X、Y、Z"。这样既避免了在图里塞一堆基础概念解释，也让读者知道如果看不懂应该先去补什么。这个习惯是从写技术文档里迁移过来的，非常好用。

2.3 图的边界在哪里

这一点最容易被忽略。任何一张图都不可能画完整个系统，你必须明确这张图不包含什么。比如画订单系统的流程图，你可能明确不包含支付网关内部的逻辑、不包含风控系统的判断细节，这些用一个个"外部系统"的方框代替即可。

明确边界的好处是：读者不会追问"为什么这里没有 XX"，你自己画的时候也不会陷入"要不要把这个也画上"的纠结。边界之外的东西，用一句话注释说明"XX 部分详见另一张图"就够了。

3. 结构设计：把逻辑翻译成图形语言

3.1 先选图形类型，再填内容

不同的逻辑关系对应不同的图形类型，选错了类型，后面怎么画都别扭。我整理了一张对照表，基本上覆盖了日常 90% 的场景。

选类型的判断标准很简单：看你的核心问题是"顺序"、"交互"、"状态"还是"结构"。顺序用流程图，交互用时序图，状态用状态机图，结构用架构图。不要试图用一张流程图去表达状态流转，那会画得非常别扭。

3.2 用"主干+分支"的方式组织节点

确定图形类型后，不要急着把所有节点都列出来。我的习惯是先找出主干路径——也就是最核心、最常走的那条路径，把它画成一条直线或者一个主循环。然后再把分支、异常、边界情况挂到主干上。

这样做的好处是图有主次之分，读者一眼就能看到主线，细节可以按需深入。如果一上来就平铺所有节点，图会变成一团乱麻，读者根本找不到入口。

具体操作上，我会用不同颜色或者不同线宽来区分主干和分支。主干用粗线或者深色，分支用细线或者浅色。这个技巧在复杂流程图里特别有效，实测下来读者的理解速度能提升不少。

3.3 命名规范：让节点自己说话

节点命名是图表设计里最容易被低估的环节。我见过太多图里写着"处理"、"判断"、"服务 A"这种毫无信息量的名字。好的命名应该让读者不看连线也能猜出这个节点在干什么。

我的命名原则是：动词+名词，或者名词+状态。比如"校验订单合法性"、"订单已支付"、"调用库存服务"。避免用"处理"、"操作"、"逻辑"这种万能词，它们等于没说。

还有一个细节：同一个概念在全图里必须用同一个名字。不要一会儿叫"用户"一会儿叫"客户"，一会儿叫"订单"一会儿叫"交易单"。这种不一致会让读者以为是两个不同的东西，产生不必要的困惑。

4. 视觉规范：让图好看且不喧宾夺主

4.1 颜色只用来编码语义

颜色是图表设计里最强大的工具，也是最容易被滥用的工具。我的原则是：每一种颜色都必须对应一个明确的语义，不能因为"这个颜色好看"就用它。

常见的语义编码方式有几种：按角色分色（用户相关蓝色、系统相关灰色、外部系统绿色）、按状态分色（正常绿色、警告黄色、异常红色）、按层级分色（上层深色、下层浅色）。选一种方式贯彻到底，不要混用。

颜色数量控制在3 到 5 种以内。超过 5 种，读者就记不住了，颜色反而成了干扰。如果确实需要区分更多类别，用形状、线型、标签来辅助，不要无限增加颜色。

4.2 对齐和间距决定专业度

一张图看起来"专业"还是"业余"，很大程度上取决于对齐和间距。我见过内容完全正确但看起来就是很乱的图，问题基本都出在这两点上。

对齐方面，同一层级的节点必须对齐，要么顶部对齐，要么中心对齐，不要参差不齐。连线尽量走直线或者直角折线，避免斜线和曲线，除非是时序图这种天然需要斜线的场景。

间距方面，节点之间的间距要一致，不要有的地方挤在一起有的地方空一大片。我一般的做法是先定一个基础间距单位（比如 20px），所有间距都用这个单位的整数倍。这样整张图会有一种内在的节奏感，看起来就很舒服。

4.3 文字排版：能横排就不竖排

文字排版有个铁律：能横排就横排，能一行就不要两行。竖排文字阅读成本极高，除非是侧边栏标签这种特殊情况，否则一律横排。

节点内的文字如果太长，优先考虑缩短文字而不是换行。比如"用户提交订单请求"可以缩短成"提交订单"，因为上下文已经说明了是用户操作。实在缩短不了再考虑换行，换行时注意保持每行长度相近，不要出现一行特别长一行特别短的情况。

字号方面，正文文字不小于 12px，标题文字比正文大 2 到 4px。层级不要太多，一般两级就够了（节点标题 + 节点说明）。字号层级太多会让图看起来很碎。

5. 工具选型：不同场景用不同的家伙

5.1 代码化图表工具 vs 拖拽式工具

这是图表设计里最重要的一个选型决策。代码化工具（用文本描述生成图表）和拖拽式工具（用鼠标画）各有适用场景，选错了会非常痛苦。

我的建议是：逻辑性强、需要频繁修改的图用代码化工具；视觉要求高、一次性交付的图用拖拽式工具。很多人的问题是所有图都用拖拽工具画，结果改一次图要花半小时调整布局，效率极低。

5.2 代码化工具的语法选择

代码化图表工具有好几种语法风格，选择时主要看两点：表达能力和生态支持。表达能力强的语法能画出更复杂的图，但学习曲线也陡；生态支持好的语法有更多现成的编辑器和渲染工具。

我一般的选型逻辑是：如果团队里大家都熟悉某种语法，就用那种；如果从零开始，选一种语法接近自然语言、文档齐全的。不要为了追求"强大"去选一种小众语法，后期维护成本会很高。

5.3 拖拽式工具的图层管理

用拖拽式工具时，图层管理是专业和业余的分水岭。业余选手把所有元素堆在一个图层里，改一个东西要选中半天；专业选手会按功能分层，比如背景层、连线层、节点层、标注层。

分层的好处是：改连线的时候不会误选到节点，改背景的时候不会动到内容。我一般至少分四层，复杂图会分到七八层。这个习惯养成之后，画图效率会有质的提升。

6. 实测中的高频问题与排查思路

6.1 图太乱：先砍内容再调布局

图乱是第一大高频问题。很多人遇到图乱的第一反应是调整布局，把节点挪来挪去，结果挪了半天还是乱。正确的排查顺序是：先砍内容，再调布局。

具体操作：把图里所有节点列出来，逐个问"这个节点和核心问题相关吗"，不相关的直接删掉。删完之后如果还乱，再问"这些节点能不能合并"，把功能相近的节点合并成一个。内容精简到不能再精简了，再去调布局。

我实测下来，大部分"图乱"的问题，砍掉 30% 的内容就解决了，根本不需要调布局。

6.2 连线交叉：用分层和桥接解决

连线交叉是第二大高频问题。完全避免交叉很难，但可以大幅减少。两个技巧：分层和桥接。

分层是指把节点按逻辑分成几层，同层节点横向排列，连线主要在层与层之间走，这样交叉会少很多。桥接是指当两条线必须交叉时，用一个小弧线表示"这里跨过去了"，而不是直接十字交叉。桥接在电路图和流程图中很常见，能显著提升可读性。

如果交叉实在太多，说明你的图可能承载了太多信息，考虑拆成两张图。

6.3 读者看不懂：找外行试读

这是最容易被忽略的排查步骤。你自己画的图，你当然看得懂，但读者不一定。唯一的验证方法是找一个不了解这个业务的人来试读，让他说出这张图在讲什么。

如果他说出来的和你想要表达的不一致，说明图有问题。常见的问题有：入口不明确（读者不知道从哪看起）、术语没解释（读者卡在某个词上）、逻辑跳跃（读者跟不上你的思路）。根据反馈针对性修改，通常改两三轮就能达到"外行也能看懂"的程度。

7. 从草图到交付的完整流程

7.1 草图阶段：用纯文本列结构

我强烈建议在打开任何工具之前，先用纯文本把结构列出来。用缩进表示层级，用箭头表示流向，用括号表示条件。这个阶段完全不考虑视觉，只考虑逻辑。

比如一个订单流程可以这样列：

用户提交订单 -> 校验库存 -> 库存充足 -> 锁定库存 -> 创建订单 -> 跳转支付 -> 库存不足 -> 提示用户 -> 结束

这个纯文本结构确认无误之后，再翻译成图形。这样做的好处是：逻辑问题在文本阶段就暴露了，不会等到画完图才发现逻辑不通。

7.2 初稿阶段：先画主干再补分支

翻译成图形时，先画主干路径，确认主干清晰之后，再补分支和异常。不要一上来就画所有细节，那样很容易迷失在细节里。

初稿阶段不要纠结视觉，用最朴素的样式把结构画出来就行。颜色、字体、间距这些留到下一阶段统一处理。这个阶段的目标是结构正确，不是好看。

7.3 精修阶段：统一视觉规范

结构确认之后，进入精修阶段。这个阶段做几件事：统一颜色语义、统一字体字号、统一间距、对齐节点、优化连线。这些操作比较机械，但决定了图的专业度。

我一般的顺序是：先定颜色方案，再定字体字号，然后调间距和对齐，最后优化连线。每做完一步都整体看一遍，确保没有遗漏。

7.4 交付阶段：导出和配套说明

导出时注意两点：格式和分辨率。如果图要放进文档，用矢量格式（SVG、PDF）；如果要放进 PPT 或者聊天工具，用高分辨率位图（PNG，2 倍或 3 倍分辨率）。不要导出低分辨率位图，放大就糊。

配套说明也很重要。图本身能表达的信息有限，关键的假设、边界、术语解释要写在图外的说明里。我一般会在图下方加一段简短的说明，写清楚这张图的适用范围和阅读顺序。

8. 几个让我少走弯路的实操心得

第一个心得：图是改出来的，不是画出来的。我早期总想一次画到位，结果每次都要大改。后来接受了一个事实：第一版一定是错的，快速画出第一版，然后基于反馈迭代，效率反而更高。

第二个心得：建立自己的图表模板库。常用的架构图、流程图、时序图，各做一个模板，下次画同类图时直接套用。模板里预设好颜色、字体、间距，能省下大量重复劳动。我现在的模板库有十来个模板，覆盖了日常 80% 的场景。

第三个心得：图的标题和注释和图本身一样重要。很多人只重视图的内容，标题随便写个"架构图"就完事。好的标题应该说明这张图的核心结论，比如"订单系统采用读写分离架构，写库单点、读库可扩展"。读者看标题就能 get 到重点，图是佐证。

第四个心得：定期回顾旧图。我每隔一段时间会翻出几个月前画的图，看看现在还能不能看懂。如果看不懂了，说明当时的表达有问题，记录下来避免下次再犯。这个习惯帮我发现了不少表达上的坏习惯。

第五个心得：不要追求一张图讲完所有事。我早期总想用一张图覆盖所有场景，结果图越来越复杂，越来越难懂。后来学会了拆图，一张图只讲一件事，讲清楚就行。多张图之间用编号和引用关联起来，整体反而更清晰。

关于 diagram-design 这个方向，我的整体判断是：它是一项被严重低估的技能。大部分人觉得画图就是"把想法画出来"，但实际上，画图的过程本身就是一次深度思考。你在纠结某个节点要不要画、某条线怎么走的时候，其实是在逼自己把逻辑想清楚。所以我的建议是：不要把它当成负担，把它当成梳理思路的工具，用多了你会发现，很多想不清楚的问题，画着画着就清楚了。