企业官网建设流程全解析

1. 从“diagram-design”这个标题里能读出什么

第一次看到“diagram-design”这个标题，我的直觉是：这大概率不是一个单纯的“画图工具推荐”，而是一个关于如何把复杂信息用图形语言重新组织的项目。项目正文和关键词都是空的，这反而给了我更大的拆解空间——因为标题本身已经足够说明问题：它把“diagram”和“design”并列，意味着重点不在“画”，而在“设计”。

很多人一听到画图，第一反应是找工具：ProcessOn、Draw.io、Excalidraw、Figma、Mermaid。工具当然重要，但工具解决的是“怎么画”，而“diagram-design”要解决的是“画什么、为什么这样画、画完能不能让人一眼看懂”。这两件事的差距，就像“会用Word”和“会写文章”之间的差距。

我做过不少技术方案图、架构图、流程图的整理工作，也帮人改过大量“画得很认真但没人看得懂”的图。一个很深的体会是：图的问题，九成不是工具问题，而是信息结构问题。线条歪一点、配色土一点，读者能忍；但层级混乱、箭头乱飞、重点淹没在细节里，读者三秒就关掉了。

所以这篇内容适合三类人：第一类是需要用图表达技术方案、业务流程、产品逻辑的从业者；第二类是经常被要求“画个图说明一下”但不知道从哪下手的人；第三类是对信息设计感兴趣、想让自己的图从“能看”变成“好读”的人。下面我会从设计逻辑、结构方法、实操步骤、常见坑几个角度，把“diagram-design”这件事拆开讲。

2. 先想清楚图的“读者任务”，再动手画第一根线

2.1 图不是给自己看的，是给特定读者完成特定任务用的

我见过太多人画图时的默认心态是“我要把我知道的都放上去”。这是典型的作者视角，不是读者视角。一张图能不能用，取决于读者能不能在预期时间内完成他该完成的任务。

举个具体场景。同样是“订单创建流程”，给不同人看，图的形态应该完全不同：

同一件事，四张图，没有一张是“完整”的，但每一张对它的读者都是完整的。这就是diagram-design的第一原则：完整性是相对于读者任务而言的，不是相对于事实而言的。

我自己的做法是，动手前先写一句话：“这张图是给____看的，他看完要能____。”这句话写不出来，图就别画了，因为你自己都不知道要表达什么。

2.2 信息层级比视觉美化重要十倍

很多人把“设计”理解成配色、圆角、阴影、图标。这些是视觉层的东西，属于最后一步。真正决定一张图好不好读的，是信息层级。

信息层级说白了就是：读者第一眼看到什么，第二眼看到什么，第三眼看到什么。一张好的图，读者的视线路径是被设计过的，而不是随机游走。

我常用的层级划分是三层：

• 第一层：结论层。读者扫一眼就能拿到的核心信息。通常是一个主标题、一个核心模块、一条主流程。
• 第二层：结构层。支撑结论的主要分组、阶段、角色。通常是几个并列的区块或泳道。
• 第三层：细节层。具体的字段、参数、备注、边界条件。通常放在角落、注释或折叠区域。

问题在于，大多数人画图时把这三层用同样的视觉权重呈现出来：同样的字号、同样的颜色、同样的线宽。结果就是读者不知道看哪里，只能从头到尾逐字读，那还不如直接看文档。

一个很实用的检验方法：把图缩小到25%看。如果缩小后还能看出主干结构，说明层级是清楚的；如果缩下去变成一团糊，说明你把细节和主干混在一起了。

2.3 为什么“先画框再填内容”比“边想边画”靠谱

我早期画图有个坏习惯：打开工具就开始拖方框，想到哪画到哪。结果经常是画到一半发现布局不够用，或者两个模块之间的关系没地方放，只能推倒重来。

后来我改成一个笨办法，但极其有效：先用纸或白板画出区块划分，不画具体内容。具体来说分三步：

1. 确定画布上要放几个大区块，它们的位置关系是什么（左右、上下、环绕）。
2. 确定区块之间的连接关系，是单向、双向还是多对多。
3. 确定每个区块内部大概要放几条信息，预留空间。

这三步做完，再打开工具。这时候你是在“填内容”，而不是“边想边画”。效率差别非常大，因为布局决策和内容决策是两种不同的脑力活动，混在一起做容易两头都做不好。

提示：如果你用的是支持无限画布的工具，不要因为“空间无限”就随意铺开。读者的屏幕是有限的，一张图的信息密度应该控制在“一屏能看完主干”的范围内。超出这个范围，就应该考虑拆图。

3. 几种常见图型的结构套路与适用边界

3.1 流程图：别把“判断”画成“步骤”

流程图是最常见的图型，也是最容易被画坏的。最常见的错误是把判断节点和操作节点混为一谈，导致读者分不清“这里要做一件事”还是“这里要做一个选择”。

我的习惯是严格区分三种节点：

• 操作节点：执行一个动作，比如“校验参数”“写入数据库”。
• 判断节点：产生分支，比如“库存是否充足”。
• 起止节点：流程的入口和出口。

判断节点一定要用菱形或明显的分支符号，并且每条出边都要标注条件。我见过太多图，一个方框伸出三条线，没有任何标注，读者根本不知道什么情况下走哪条。

另一个高频问题是异常分支的处理。很多流程图只画了“顺利路径”，异常情况全部省略。这在给开发看的图里是致命的，因为开发最关心的就是异常怎么处理。我的建议是：主流程用粗线或深色，异常分支用细线或浅色，但一定要画出来。如果异常分支太多，就单独拆一张“异常处理图”。

3.2 架构图：分层是手段，边界才是目的

架构图的核心不是“分层好看”，而是表达边界。什么是边界？就是“谁负责什么、谁依赖谁、谁不能直接碰谁”。

我画架构图时，会先问三个问题：

1. 这个系统对外暴露什么能力？
2. 内部拆成了几个职责单元？
3. 每个单元依赖哪些外部资源？

这三个问题的答案，决定了图的基本骨架。至于分成三层还是四层，用不用云图标，都是次要的。

一个很常见的坑是把部署架构和逻辑架构画在一张图里。逻辑架构关心的是模块职责和依赖关系，部署架构关心的是进程、节点、网络区域。这两件事混在一起，读者会分不清“这个框是一个代码模块还是一个服务器”。我的做法是分开画，逻辑架构图里不出现服务器，部署架构图里不出现业务模块名。

3.3 时序图：时间轴是唯一的锚点

时序图最容易出现的问题是“消息太多，读者找不到重点”。因为时序图天然是线性的，所有交互都排在同一条时间轴上，很容易变成流水账。

我的处理方式是给消息分级：

• 核心消息（决定主流程走向的）用实线加粗。
• 辅助消息（日志、监控、通知）用虚线或浅色。
• 异常消息单独用醒目的颜色，并在旁边标注触发条件。

另外，时序图的参与者（泳道）数量要控制。超过五六个参与者，图就会变得很宽，读者需要左右滚动才能看完一次交互。这时候应该考虑拆成多张图，或者把一些次要参与者合并成“外部系统”。

3.4 概念图/关系图：克制连线的冲动

概念图用来表达“事物之间是什么关系”，比如实体关系图、组织关系图、依赖关系图。这类图最大的诱惑是“把所有关系都画出来”，结果就是一张蜘蛛网。

我的经验是：一张概念图只表达一种关系类型。比如“包含关系”就只画包含，“调用关系”就只画调用。如果两种关系都重要，就画两张图，或者用两种明显不同的线型并加图例。

还有一个细节：连线的方向性要明确。如果关系是无向的，就用无箭头直线；如果是有向的，箭头方向必须和语义一致。我见过把“A依赖B”画成“B指向A”的图，这种错误会让读者对整个图的可信度产生怀疑。

4. 从空白画布到可交付图稿的完整操作链路

4.1 第一步：用一句话锁定图的“核心断言”

在打开任何工具之前，我会先写一句话，格式是：“这张图要证明/说明____。”这句话就是这张图的核心断言。所有内容都要为这句话服务，和它无关的，一律不放。

举个例子。如果核心断言是“订单系统在高并发下通过异步削峰保证稳定性”，那么图里应该突出的是：同步入口、消息队列、异步消费、限流降级。至于订单表有哪些字段、用了什么数据库，都不应该出现在这张图里。

这一步看起来简单，但能过滤掉大量无效信息。我自己的经验是，写不出这句话的图，画出来大概率是“资料汇编”，不是“设计作品”。

4.2 第二步：用纸笔或白板做“区块草稿”

这一步不追求好看，只追求结构。具体操作：

1. 画几个大框，代表主要模块或阶段。
2. 用箭头标出它们之间的关系。
3. 在每个框里写关键词，不写完整句子。
4. 用不同颜色的笔标出“必须保留”和“可以删掉”的内容。

这个阶段最重要的是快。不要纠结某个框放左边还是右边，先放上去，后面可以调。草稿阶段的目标是验证“信息放不放得下”，而不是“好不好看”。

我通常会做两到三版草稿，每版换一种布局方式。比如第一版从左到右，第二版从上到下，第三版用中心辐射。然后对比哪一版最能突出核心断言。

4.3 第三步：在工具里搭建骨架，先不管样式

选工具这件事，我的观点是：没有最好的工具，只有最适合当前协作方式的工具。几个常见选择：

我自己的组合是：草稿用白板类，正式图用专业绘图类，需要进代码仓库的用代码生成类。关键是不要在工具选择上花太多时间，先用你最熟的那个把骨架搭出来。

搭骨架的顺序是：先放区块，再放连接线，最后放文字。文字最后放，是因为文字长度会影响区块大小，如果先放文字再调布局，会反复返工。

4.4 第四步：做“减法”而不是“加法”

骨架搭完后，大多数人会开始加东西：加图标、加颜色、加阴影、加备注。我的建议恰恰相反：先做减法。

具体做法：

• 删掉所有不影响核心断言的节点。
• 删掉所有可以用一句话代替的细节。
• 删掉所有重复表达同一信息的元素。
• 删掉所有“因为好看所以加上去”的装饰。

做完减法后，如果图还能支撑核心断言，说明结构是稳的。然后再做加法：给核心节点加视觉权重，给不同类别加颜色区分，给关键路径加粗。

这个顺序很重要。先加后减，你会舍不得删；先减后加，你会更清楚什么值得加。

4.5 第五步：用“三秒测试”和“三十秒测试”验收

图做完后，我会做两个测试：

三秒测试：把图给一个不了解背景的人看三秒，然后问他“这张图在说什么”。如果他说不出大概方向，说明核心断言不够突出。

三十秒测试：让他看三十秒，然后问他“这张图分几个部分，它们是什么关系”。如果他说不清楚，说明结构层级有问题。

这两个测试不需要找很多人，找一两个同事就行。关键是不要给任何口头解释，让图自己说话。如果图需要你在旁边解释才能看懂，那这张图就是失败的。

5. 那些年我踩过的图设计坑

5.1 坑一：把“详细”当成“专业”

我刚工作时，总觉得图里信息越多越显得专业。一张架构图里塞了三十多个模块，每个模块下面还有五六个子项，字号小到要放大才能看清。结果拿去评审，领导第一句话是“这张图想说什么”。

后来我才明白，专业不是把复杂的东西画复杂，而是把复杂的东西画简单。一张好的图，是作者消化了复杂度之后，把主干提炼出来给读者看。读者不需要知道你考虑了所有细节，他只需要知道你的结论和依据。

现在的做法是：主图只放主干，细节用附录或单独文档承载。如果评审时有人问细节，再展开。这样主图清爽，讨论也有层次。

5.2 坑二：颜色用得太多，反而没有重点

我曾经有一张图用了七八种颜色，每个模块一种，觉得这样区分度高。结果读者反馈“像彩虹，不知道看哪里”。

颜色的作用是区分类别和标记重点，不是装饰。我的经验是：

• 主色不超过三种，分别代表“核心”“辅助”“外部”。
• 重点标记只用一种颜色，比如红色或橙色，且只用在真正关键的地方。
• 同一张图里，相同含义必须用相同颜色，不同含义不能用相近颜色。

还有一个细节：要考虑色盲读者。红绿搭配是最常见的坑，尽量用蓝橙、紫黄这类对比。如果图要打印成黑白，颜色区分就失效了，这时候要靠线型和填充图案来区分。

5.3 坑三：箭头方向混乱，读者要猜

箭头是图里信息密度最高的元素，因为它同时表达了“方向”和“关系”。但很多人画箭头很随意，导致读者要猜。

我给自己定的规则是：

• 箭头方向必须和语义一致。数据流向就用数据流向，依赖关系就用依赖方向，不要混。
• 双向关系用双向箭头或两条单向箭头，不要用一条无箭头线表示“互相”。
• 如果箭头太多，考虑用编号代替，在图例里说明编号含义。

还有一个容易被忽略的点：箭头的起点和终点要明确。如果一条线从一个大框的中间穿出来，读者不知道它具体从哪个子模块出发。这时候应该把线连到具体的子模块上，或者用一个小圆点标记起点。

5.4 坑四：文字太多，图变成了文档

图里放文字是必要的，但放多少有讲究。我的经验是：节点内文字不超过一行，注释不超过两行。超过这个长度，就应该考虑用编号加图例的方式。

如果一段文字必须完整呈现，那它就不应该放在图里，而应该放在图下方的说明区。图的作用是建立结构认知，不是传递完整信息。读者看完图，知道“有哪些部分、怎么连接”，具体内容去看文档。

我见过最极端的例子是一张流程图里每个节点都是一段话，整张图看起来像一篇排版奇怪的文档。这种图，读者既不能快速抓结构，也不能方便读文字，两头不讨好。

6. 让图真正被用起来的几个习惯

6.1 给图配一段“读图说明”

图交付出去之后，我发现一个现象：不同的人看同一张图，理解的重点完全不同。有人关注流程，有人关注模块，有人关注异常。这很正常，但如果图要用在评审或文档里，最好配一段简短的读图说明。

读图说明不用长，三句话就够：

1. 这张图表达的核心结论是什么。
2. 图分几个部分，建议按什么顺序看。
3. 有哪些约定（比如颜色含义、线型含义）。

这段说明可以放在图的旁边，也可以放在图的下方。它的作用是降低读者的理解成本，尤其是当图会被转发给不了解背景的人时，这段说明能避免很多误读。

6.2 版本管理：图也会过期

图是会过期的。系统改了，流程变了，图没更新，就会误导人。我踩过最惨的一次坑是：一张架构图用了半年没更新，新同事照着图去理解系统，结果完全对不上。

后来我养成的习惯是：

• 图文件命名带日期或版本号，比如“订单流程_v3_20240115”。
• 图放在和文档同一个仓库里，改文档时顺手检查图。
• 在图的角落标注“最后更新日期”和“对应版本”。

如果图是用代码生成的，那就更好了，因为代码进版本管理，图自然也跟着更新。这也是我推荐代码生成类工具的一个重要原因。

6.3 收集反馈：问“哪里看不懂”而不是“好不好看”

图交付后，我会主动收集反馈。但问法很重要。问“好不好看”，得到的都是审美意见；问“哪里看不懂”，得到的才是结构问题。

我常用的几个问题：

• 你第一眼看的是哪个部分？
• 有没有哪个连接关系你不确定？
• 如果只能保留一半内容，你会删哪些？

这些问题能帮我发现图里的“隐形问题”——那些我自己觉得清楚、但读者实际困惑的地方。尤其是第三个问题，能直接暴露哪些内容是冗余的。

6.4 建立自己的图库和模式库

画得多了之后，我发现很多图其实是重复的：类似的流程、类似的架构、类似的关系。与其每次从零开始，不如建立自己的模式库。

我的模式库里有几类东西：

• 常用布局模板：左右流程、上下分层、中心辐射、泳道对比。
• 常用配色方案：技术架构用冷色、业务流程用暖色、异常标记用高对比色。
• 常用图例元素：起止符号、判断符号、注释框、分组框。

有了模式库，画新图时先选模板，再填内容，效率能提高不少。而且因为模板是验证过的，结构上不容易出大问题。

注意：模式库是起点，不是终点。每次用模板时，还是要根据具体内容调整。生搬硬套模板，图会显得僵化，读者也能看出来。

7. 关于diagram-design，我最后想分享的几点体会

画图这件事，工具会变、审美会变，但有些东西是不变的：图是为了降低理解成本而存在的。如果一张图让读者更困惑了，那不管它用了多高级的工具、多漂亮的配色，都是失败的。

我自己从“画得好看”到“画得有用”，中间隔了很多次返工和反馈。最大的转变是：不再把图当成“我的作品”，而是当成“读者的工具”。作品可以自我表达，工具必须服务任务。

还有一个很实际的建议：多看图，尤其是那些让你一眼就懂的图。看到好图，不要只感叹“画得真好”，要拆解它为什么好：它怎么分层的、怎么用颜色的、怎么处理连接的。拆多了，你自己画的时候就有感觉了。

最后，如果你现在手上正好有一张画了很久但总觉得不对劲的图，我的建议是：先别改样式，把图缩小到25%，看看主干还在不在。如果主干糊了，问题就在结构，不在美化。把结构理顺了，图自然就好读了。