企业官网建设流程全解析

1. 图表不是画得漂亮，是把结构讲清楚

前阵子我帮同事救一张改到崩溃的图。那张架构图已经换了三版配色、调了两周间距，评审会上所有人还是皱着眉头——不是觉得丑，而是看不明白"这张图到底在说什么"。我接手后第一件事不是打开画布，而是坐下来问了一个问题："这张图要回答谁的什么疑问？"对方沉默了很久。这才是 diagram-design 最核心的真相：它不是视觉设计，是结构工程。你可以在线框里浪费一周调圆角，但真正决定图表生死的，是你有没有把逻辑关系用最省力的方式交到读者手里。

这个判断适用于所有领域的图：产品流程图、系统架构图、数据血缘图、甚至手工图解步骤图。所谓 diagram，本质是把一个复杂的、多维度的事实，压缩到一张能让大脑快速扫描的平面里。压缩的过程中必然有取舍，而取舍的标准只有一个——读者需要扫一眼就拿到什么信息。画图之前如果没有回答这个问题，后面所有的节点、连线、颜色都是在往一团乱麻上继续缠线。

这篇文章我就围绕 diagram-design 从结构到视觉到工具的完整链路，讲一讲我这些年画图、评图、返工之后沉淀下来的东西。它适合产品经理、前后端工程师、数据从业者，也适合任何需要把想法讲清楚的非专业画手。我不打算讲玄学式的"美感"，只讲可落地、可检查、可复现的规则。

1.1 一张图要不要画，先写四行字

我现在的习惯，动手前先在文档里写四行字，每行不超过二十个：

• 读者是谁（给领导看？给同组研发看？给新入职的同学看？）
• 这张图要回答什么问题（"缓存加在哪"和"整体模块有哪些"是完全不同的图）
• 信息粒度到哪一层（要细到方法级，还是粗到服务级）
• 呈现在什么介质上（投屏 PPT？写在文档里？打印出来贴墙上？）

别小看这四行字。很多"改不完的图"，本质是这四个问题没想清楚。给决策者看的图需要留白和结论先行，给执行者看的图需要路径清晰和节点可定位。介质也影响巨大：投屏用的图箭头至少 2px 粗，文档里的图可以做得密一些，打印的图要慎用浅底色。这四条没定，后面全是无根之木。

我见过一个最典型的返工场景：某同学给管理层汇报画了一张业务全景图，把所有门店、所有活动、所有支付渠道都放上去，想着"体现了业务复杂度"。结果评审会上领导只问了一句："我们现在的瓶颈在哪个环节？"图里没有任何一条路径能回答这个问题。后来我把图重画成三层的漏斗形态，把有数据支撑的转化率标注在连线上，问题立刻有了答案。多不是优点，聚焦才是。

1.2 定结构：把"我要讲什么"翻译成"图上有哪些东西"

四行字确定后，下一步是画"结构草图"——注意，这一步不许开画布工具，就在白纸上画圈和箭头。结构阶段只回答两件事：图上有哪些节点？节点之间的关系是哪一种？

关系本质上就三类：包含（A 是 B 的一部分）、依赖（A 需要 B 提供输入）、流转（事件从 A 到 B，再到 C）。想清楚每个关系属于哪一类，就决定了你后面用嵌套框、连线还是箭头。太多人在这里混着用——既用连线表示调用，又用连线表示时序，读者不懵才怪。

这个阶段我通常会用十分钟写一堆便签，每张便签一个节点，然后在桌面上来回挪位置。挪的过程中你会发现：有些节点根本不属于这张图，有些节点之间存在隐性的边界，有些节点需要拆成两层。结构草图的意义，是在零成本的情况下把所有错误犯一遍。等便签的位置稳定了，再打开工具落到画布上，剩下的只是体力活。

2. 三种基本图式与它们的边界，别硬融

结构确定之后，要选图的"骨架"。很多画图工具给了一堆模板，什么时间线、韦恩图、鱼骨图，但实际工作中 95% 的 diagram 逃不出三种基本图式：层次图、流程图、网状图。判断该用哪一种，不看你画得多花哨，看信息的原始形态。

2.1 层次图：天生适合"谁包含谁"的信息

组织架构、模块划分、目录结构、权限树，这类信息的特点是上下级明确、一个节点只有一个父节点。画法上用树形或同心圆都可以，但注意两点：层级深度尽量控制在四层以内，每层同级节点尽量均衡。超过四层，读者的工作记忆就满了，他会开始忘掉上面几层的内容；同级节点数量悬殊（一层只有 1 个、下一层却有 12 个），说明上一层的拆分粒度不对。

我画层次图时有个小技巧：先画"根的左孩子"，再画"根的右孩子"，不要从中间往两边展开。人的视线习惯是从左上角进入图的，把根节点放在左上角或者顶部居中，比放在正中间更容易建立"从上往下读"的预期。层级之间的垂直间距至少留出节点高度的 1.5 倍，不然连线会挤在一起，成了毛毛虫。

同心圆布局我一般只用在两种场合：一是不强调上下级的"生态位"展示（比如某个平台的数据生态），二是节点数量少（少于 12 个）且需要表达"中心—外围"的语义。同心圆有个天生的缺陷：圆环越往外，节点可用的水平空间越大，导致视觉重心偏下，而内部挤压严重。所以不是特殊情况我不用它。

2.2 流程图：一切有先后顺序的信息

流程图是最常见、也最容易画乱的图式。下单流程、审批流转、状态机、故障恢复步骤，都是流程。画流程图的铁律：主流向永远从上到下，或者从左到右，二选一，不要混。分支如果超过三个，先把主干拉通，分支往后放，而不是让分支和主干并排牵出一堆交叉线。

这里给一个经验值：一个流程图上，主干节点控制在 6 到 8 个之间。超过 8 个，读者一次看不完主链路，注意力就开始涣散。分支和异常路径（如超时、拒绝、降级）可以用独立的色块或虚线框区隔，但同一个流程图上分支不要超过 3 条。分支太多说明这个流程本身粒度太粗，考虑拆成多张子图，用"子流程"节点指引用另一张图去展开。

我见过最乱的流程图，是把"成功"和"失败"路径各画了一条长长的折线，然后在中途来回交叉。读者要拿手指沿着线走，走到一半就迷路了。处理这类问题有个简单方法：失败路径尽量往右回折，不要往左回折。人的阅读方向天然是左到右、上到下，回折方向顺着阅读方向，扫读成本会低很多。

2.3 网状图：关系密集时的最后选择

网状图用于表达多对多关系，比如数据血缘、服务调用链、社交关系。这类图的坑在于：一旦节点数超过 25 到 30 个、连线数超过 40 条，人的视觉系统就处理不过来了。节点和连线会挤成一团，业内戏称"毛线球"。毛线球不是图，是噪音。

当你发现图开始变成毛线球时，要做三件事：第一，分清主次关系，只保留核心路径，把次要关系用文字列表放到图下方；第二，用"枢纽节点"意识——多数网状图存在少数几个度数极高的节点，把它们放在图中心，其余节点往四周辐射，可以在视觉上天然形成聚类；第三，如果密集程度实在压不下来，果断放弃网状图，改用矩阵表格或交互式下钻列表，"一张图画完所有关系"本身是个伪需求。

3. 节点、连线、图例：语义比形式重要一百倍

骨架选好了，开始画实体。这一步是 diagram-design 里面最容易出现"精致但错误"的地方——形状、颜色、线型看似都用了，但语义互相打架。我下面给的规则，不是美术规范，是为了保证你所画的每个视觉元素，都只有一个确定的含义。

3.1 形状语言：同一个图里，形状不能有两种解读

常见做法是用形状区分节点类型：圆角矩形表示页面或模块，菱形表示判断，圆形表示数据存储，直角矩形表示处理器。这套约定本身没有对错，但你必须在一张图里自洽。最忌讳的是：用了三种以上含义模糊的"装饰形状"（比如不规则的云朵形、气泡形），读者完全不知道形状差别代表什么差别。

我有一个朴素标准：在一张图里，节点形状不要超过四种。超过四种，即使下图例，读者也懒得一一对照。如果你发现需要五种以上形状才能表达信息，说明你把太多类型塞进一张图了，需要拆图。形状的差别应该对应"读者最关心的分类维度"，而不是对应"我觉得这样好看"。

另外，形状不要和颜色同时承载同一个语义。例如你用蓝色表示"支付模块"、圆形也表示"支付模块"，那色弱的人看你的图，圆形也帮不上忙；反过来，你用圆形表示"支付模块"、又用圆形表示"活动模块"，那圆形这个形状就失去了意义。形状和颜色应该分别承载两个不同维度的分类——比如形状表示"类型"，颜色表示"状态"，互不干扰。

3.2 连线：箭头越多，阅读理解越慢

连线的语义密度比节点更难控制。我总结过连线的"四不原则"：

• 不要画双向箭头。除了极少数"双向关联"的语义（比如好友关系），绝大多数业务场景里"谁调用谁"是分方向的。双向箭头往往意味着画图的人自己没想清楚依赖方向。
• 不要用同一根线型表示不同关系。实线表示数据流、虚线表示控制流或异步消息，这是常见约定，但一个图里只能有这一套约定。不要在第二张图里换成实线表示调用、虚线表示依赖，读者跨图对照时会崩溃。
• 不要让线穿过节点。穿过节点意味着"这一步之后还有一步"的歧义，读者会误以为线连到了穿过的节点上。绕线或者挪节点，总会找到不穿过的布局。
• 不要让线在节点边缘的同一位置进出。进出点尽量错开，尤其是一个节点同时有多个入边和出边时，统一从左侧进、右侧出，能让流向一目了然。

连线旁边要不要写字，也值得斟酌。比较稳妥的做法是：连线标签只写"条件、金额、频次、触发时机"这类附加信息，不写动词。比如"用户点击"这个动作不应该写在连线上，应该体现在节点本身的描述里。连线上只写"余额不足时""每月账单日""超过 10 万元"这种限定词，让读者在动作之外快速抓到约束条件。

3.3 图例：读者抬头看你之前，把规则给他

图例不是可有可无的装饰，它是你形状和颜色约定的事后说明。我的习惯是：只要图里出现非字面意义的视觉编码（颜色、线型、图形），就必须带图例，并且图例放在图内右下角或左上角，字体比正文明细小一号，宽高不超过整张图面积的 8%。图例越长，说明你的视觉编码越复杂，这时候优先考虑压缩编码种类，而不是把图例布满整张图。

图例里的文字要写"读者能懂的语言"，不要写"画图人自己的黑话"。比如图例里写"蓝色 = OKR"，不如写"蓝色 = 部门目标"，因为阅读你图的人不一定熟悉你们内部的缩写体系。如果你发现图例里需要写两行以上解释才能说清一个颜色，那不如不用颜色，直接改成文字标注。

4. 视觉参数：颜色、字重、间距各自只干一件事

结构、语义都对了，才轮到"做得好看"。这一层我自己称之为"让逻辑看得见"——视觉参数不是用来装饰的，是用来强化结构信息的可扫读性的。三个最常用的视觉参数：颜色、字重、间距，我把它们的职责划分得很清楚。

4.1 颜色：一图不超过五个色相，记住色弱人群

颜色是图表设计里最容易被滥用、也最容易翻车的参数。我的强制规定是：整张图里语义性的色相不超过五个，另外灰色和白色不占用颜色额度。一个主色用于强调核心链路，两三个辅助色用于区分二级分类，一个告警色只用在异常和失败路径。超过这个数字，读者的注意力就被颜色本身吸引走了，你说的话反而没人听。

这里不得不提色弱的问题。中国男性中红绿色弱比例不低，你精心设计的红绿对比，在他们眼里可能是一片灰蒙蒙。为了兼容这个群体，我有一个非常实用的做法：重要的语义差别不能只靠颜色区分，必须同时叠加线型或形状的差别。比如"成功路径"用绿色实线加对钩图标，"失败路径"用红色虚线加乘号图标，这样即使有人分不清红绿，也能靠虚实和图标识别。颜色对比度方面，正文文字和底色之间最好达到 4.5:1 以上的对比度，小字号注释可以用 7:1 的高对比度。这组数字是借鉴无障碍阅读的经验值，实测下来非常稳。

4.2 字重：四个档位解决所有标题层级

我做 diagram 时，文字只分四个档位：

• 第一档：图标题，用于说明整张图是什么，字号 18 到 22，加粗；
• 第二档：模块名或节点名，字号 13 到 15，不加粗，偶尔用 500 字重；
• 第三档：节点内部说明文字，字号 11 到 12，灰色或常规色；
• 第四档：注释与图例，字号 9 到 10，浅灰色。

四档足够。很多图让人看着累，是因为字号档位太多，读者每读一个名字都要先判断"这行字是什么级别"，这个判断过程很耗神。字重档位少，视觉噪声就下来了，读者扫读时能快速抓大放小。特别注意：节点内部说明文字不要超过两行。超过两行说明这个节点的信息量超过了节点本身能承载的极限，考虑把它拆成子图。

4.3 间距：用 8px 的倍数做网格，用留白做分组

间距是图表里最不显眼但最影响"整齐感"的参数。我目前所有图都跑在 8px 的网格基准上：节点与节点之间最小间距 16px（两个网格单位），模块分组之间的间隔至少 32px（四个网格单位），图的外边距保持 24 到 32px。所有节点对齐到网格线，连线的折点也落在网格点上。这样出来的图自带一种"对齐感"，比手动微调整齐很多。

分组之间的边界，优先用留白，其次用浅色底框，最后才考虑用线条框。线条框是视觉负担最重的分组方式，一张图上如果出现超过两个嵌套的线框，读者会觉得图很"闷"。留白则完全无声，靠距离就能让人感知到"这一坨属于一组"。用留白分组的精髓是：同组内间距小于组间间距一倍以上。只要间距差够明显，无需一根边框线，读者的视觉系统也能自动把节点聚拢成组。

5. 同样一张业务，业务图和技术图画法相反

这几年我最大的体会是：diagram-design 没有一劳永逸的全能图。同一套业务逻辑，给业务方看和给技术方看，图画出来几乎是相反的。如果非要用一张图把大家都伺候好，结果往往是所有人都觉得它不够准。我干脆把常见场景拆成三种，分别说清楚它们的侧重点。

5.1 用户任务流程图：跟着时间轴走，少画系统边界

给产品经理、运营、交互设计师看的是用户视角的图。这类图的主线是"用户在什么时间、因为什么动机、做了一个什么动作"，系统内部的模块划分不是重点。我见过一张常见的用户登录流程图，画得非常标准：客户端发起请求，服务端校验、下发 token、刷新缓存、写入日志，六七个节点全是技术步骤，业务方看了直摇头，因为里面没有"用户忘记密码"和"用户手机收不到验证码"这两件他们最关心的事。

用户任务流程图的正确画法是：把用户能感知到的每个动作作为节点，把系统自动完成的动作尽量折叠成一行注释放在连线上。比如"输入手机号"一个节点，"点击获取验证码"一个节点，"输入验证码"一个节点，"进入首页"一个节点，中间服务端的校验过程写成"校验通过，自动登录"即可。这张图传达的重点是"用户的路径顺不顺、哪里会卡住"，而不是"系统在哪个函数上发生了什么"。

5.2 技术架构图：按职责边界走，少画业务分支

给研发、运维、架构评审看的图，侧重点完全反过来。技术架构图的核心是系统之间的职责边界、依赖关系和部署拓扑，业务细节（比如用户忘记密码的几种交互形态）应该收进模块内部，而不是画成节点。技术图最常见的错误，是把业务流程的 if-else 全都画到架构图里，结果架构图变成一张巨型业务流程图，评审的时候谁也没法在上面定位问题。

画技术架构图，我习惯先画"层"。一个典型的服务架构，从上到下是接入层、应用层、数据层、基础设施层，每层用一条横向的浅色底带区分。层与层之间的交互用纵向连线，层内的模块用横向排列的节点。纵向连线要尽量避免跨层，跨层连线通常意味着职责划分出了问题——这恰恰是架构评审最想暴露的问题。所以画架构图的时候，如果你发现自己正在画一根从最底层直接连到最顶层的线，先别急着绕线，停下来想想这个依赖本身是否合理。

5.3 数据可视化里的 diagram 边界：节点超过 30 个就投降

数据血缘、知识图谱、系统调用链这类场景经常被做成"大而全"的网状图。我的经验是：一旦节点数超过 30，无论你怎么优化布局，读者都记不住关系，图就只能作为概览，细节必须交给交互。数据可视化中的 diagram 设计，其实更该着眼于"如何通过交互下钻来隐藏细节"，而不是"如何把所有细节压进一张静态图"。

具体来说，静态图上只展示核心链路或聚合后的层级（比如按系统聚合服务、按表聚合字段），每个节点可以是一个聚合体；用户点击某个节点，才展开内部视图。这对我这种画图的人提出了额外的要求：静态图和展开图之间要保持一致的视觉语言，形状、颜色、连线规则不能变。否则用户每次展开就像进入了一张新图，认知成本很高。

6. 工具选型与出图工作流：别人的模板救不了你，流程可以

工具讨论总是很热闹，但我必须说一句：所有绘图工具的功能差异，远没有你想的那么大。真正决定图的成败的，是你有没有一套固定的出图工作流。工具只是让工作流落地的载体。我把主流工具分成三类，各有适用场景，我建议你根据团队协作方式选，而不是根据"哪个看起来炫酷"选。

6.1 三类工具的适用场景对比

我的建议很清楚：团队图建议用在线协作型，个人技术图用桌面/开源型，需要长期维护、频繁更新的图用代码生成型。一套流程里同时用两三种工具很正常——我用代码生成型画数据血缘的底层图，导出来之后放到在线协作型工具里加注释和评审，两种工具各干各擅长的活。千万别信"一个工具搞定所有图"的宣传，那通常意味着每个场景都只能做到六十分。

6.2 我的固定六步出图流程

不管用什么工具，我现在都按六步走，每一步都有检查项：

1. 写说明：完成开头说的四行字（读者、问题、粒度、介质），并发给相关的人确认。这一步省掉，后面全返工。
2. 画便签结构：不打开画布，用便签或纸笔画结构草图，只关心节点和关系类型，不关心位置和颜色。
3. 评审结构：把结构草图拍照发到群里，问三个问题——节点全不全？分类维度对不对？主路径是不是一眼能看出来？没有异议再继续。
4. 落到画布：打开工具，用统一网格、统一形状语言画出来，这一步纯体力活，不快但很稳。
5. 视觉检查：检查四件事——颜色是否超过五个色相？字重是否满足四档规则？间距是否落在 8px 网格上？图例是否够短够清楚？全部通过才保存。
6. 导出一份"图 + 源文件"：永远不要只导出 PNG。PNG 是给读者看的，源文件是给下一个人改的。没有源文件的图，三个月后就是一张没人敢动的死图。

这六步里，我反复确认过无数遍：最容易返工的环节永远是第二步和第三步。只要结构定了、大家都认可了，后面改的顶多是配色和微调位置，不会推翻重来。而我见过的大部分"改图改到想离职"的人，都是跳过了第二第三步，直接在画布上边想边画，于是"画着画着发现少一个节点，加；加了之后发现线乱了，调；调完之后发现分类维度不对，推倒重来"。

7. 复盘几个我踩过的坑，每个都是一次返工换来的

最后讲几个具体的坑。这些事我每次想起来都觉得丢人，但说完能帮读者省掉几晚加班，也算值得。

7.1 结构没定就调色，等于白调

有一次给一个数据平台画模块关系图，我花了一晚上把配色做得非常讲究：渐变色、投影、玻璃态，发出去之后同事礼貌地夸了一句"好看"。第二天产品经理来说："这个模块和那个模块的关系其实不是包含，是调用。"改一个关系类型，意味着图的整个走向变了。那一晚上的配色全部作废，唯一的价值是让我记住了：视觉永远排结构后面。现在我的习惯是，结构评审通过之前，整个图只用灰色和白色，连蓝色都不用。结构的正确性确认了，再开始上视觉参数，两三个小时就能把观感补回来。

7.2 把日志打点、监控指标都画进架构图

给一个老系统画架构图时，我总担心"画漏了会被问住"，于是把每个服务里埋的日志打点、每个关键指标都作为节点画进了图里。结果图越画越大，大到需要横向滚动才能看完。评审会上没人讨论架构，全在问"这个框代表日志的话那那个框为什么和它不一样"。痛定思痛，我认识到架构图的节点应该只画职责单元，日志打点和监控指标属于每个职责单元内部的实现细节，用一行注释放在模块下方或者干脆不画。需要展现监控体系？那就单独画一张监控链路图，不要硬塞进架构图里。

7.3 双向箭头造成的思维偷懒

早期我画依赖关系时，经常图省事，用一根双向箭头表示"这两个模块有联系"。表面上看信息丢了不多，实际上这完全是偷懒："有联系"是对关系的逃避，读者真正需要知道的是谁依赖谁、谁调谁。后来我强制自己每个箭头都必须说清方向，画不出来就说明我没搞懂业务，需要去问。这个习惯逼着我把每一条线都变成一次业务澄清，反而让我对系统的理解深了很多。如果你发现自己画了一张图上全是双向箭头，那这张图的准确性基本可以打五折。

7.4 图例缺失，让读者不断抬头看你

有一次线下评审，我投影了一张图，上面用了红黄绿三色表达服务状态。刚讲了半页 PPT，就有人举手问："绿色是正常对吧？那黄色是什么意思？"我解释了一分钟。过了十分钟，又有人问同样的问题。问题不在他们没认真听，在于我没有把图例放上去，却默认所有人都会像画图人一样花半秒钟内化这套配色规则。作为画图的人，你看自己的图自带滤镜，永远觉得那些编码规则理所当然；对第一次接触这张图的读者来说，每一处隐含规则都是一道需要额外处理的认知负担。从那以后，凡是用了非字面意义的视觉编码，我一定在图内放图例，并且字数能省则省。这个措施让评审效率提升得非常明显。

如果你是第一次系统性地想提升 diagram-design 这件事，我建议你不要急着收藏一堆模板，先把你最近要画的那张图的"四行字"写下来，发给对口的人看一眼。那四行字比任何工具技巧的优先级都高。试过一次你就知道，图能不能过关，在打开画布之前就基本决定了。