企业官网建设流程全解析

1. 先搞清楚图给谁看：需求分层与阅读场景分析

我最早画架构图的时候，吃过一次大亏。当时花了两周时间把整个系统的调用关系、模块依赖、部署拓扑、数据流向全画进一张图里，自认为精细无比。结果评审会上，业务同事盯着密密麻麻的连线看了三分钟，问了一句："所以这朵云到底是你们的产品还是别人家的东西？" 那一刻我才意识到，图不是信息越多越好，而是读图的人需要的那个信息越突出越好。

做 diagram-design 的第一步从来不是打开绘图工具，而是回答三个问题：这张图是给谁看的？他拿这张图要做什么？他会在什么状态下看图？ 这三个问题决定了图的粒度、组织方式甚至配色方案。

1.1 汇报型图与协作型图的本质差异

按阅读场景，图可以粗暴分成两类。

汇报型图的目标是"建立认知"。比如给非技术背景的决策者看系统蓝图，给新入职的同事看业务骨架，给跨部门伙伴看数据流向。这类图的读者大概率只看一次，不会拿着放大镜逐格检查。所以汇报型图要大胆减负，只保留一条主叙事线，细节全部折叠成一个"占位符"。

协作型图的目标是"指导执行"。比如研发团队要用架构图定位新的微服务应该接在哪一层，运维要用拓扑图确认故障时该从哪个节点开始排查。这类图的读者会反复查阅、对照、标注，所以信息和位置必须准确到可以当参照系使用。协作型图可以复杂，但复杂必须有结构，不能让所有元素处于同一视觉优先级。

我见过很多团队用同一张图既做汇报又做协作，结果两边都不满意。业务说看不懂，开发说画太粗。正确做法是一张主图配多张子图，主图负责总览，子图承载细节。这个"一图多级"的思路在第四节会详细展开。

1.2 从提问方式反推图的信息组织方式

判断一张图好不好，我习惯用一个实操办法：拿图给目标读者看十秒，然后让他回答几个问题。如果我画的是架构图，就问"核心数据存在哪个服务"；如果是流程图，就问"异常分支从哪一步开始触发回退"。回答得越快越准，说明图的信息组织越好。

这个测试本质上是反推的过程。图里的信息组织顺序应该跟随"读者最常问的问题"来编排，而不是跟随"系统的物理结构"来编排。比如系统按用户端、服务端、数据端划分是物理结构，但如果读者最关心的是"订单从下单到出库经过哪些环节"，那么流程视角就比模块视角更合适。

一个具体做法是开工前先在草稿纸上写下目标读者的五个典型问题，然后让每一根连线、每一个节点都对应其中至少一个问题的回答。答不出任何问题的装饰性元素，直接删掉。

1.3 信息密度的三层结构：总览层、细节层、附录层

成熟的信息架构会把内容放在三个层次。

总览层是图的"封面"，只放最高层级的组件和关系，一般不超过7个主节点。人脑的工作记忆大约能同时处理7个左右的单元，超过这个数字认知负担会急剧上升。所以总览层的节点数量是一个硬约束。

细节层是总览层的展开，每一块区域都可以单独拎出来变成一张子图。子图内部遵守同样的规则，节点过多就继续往下拆，直到每个节点都能被一句普通业务能理解的话说清楚为止。

附录层是数据字典，把图上的缩写、编号、颜色含义列成对照表。不要指望读者靠猜理解你的标记，也不要让读图的人来回翻上下文。把图当代码来维护：总览层类似模块入口，细节层类似函数实现，附录层类似注释文档。

2. 图形选型别凭感觉：各类图式的适用边界与选择逻辑

画图工具里的模板五花八门，流程图、时序图、状态图、架构图、拓扑图、思维导图、鱼骨图……但大部分人对图式的选择是"哪个模板看着顺眼选哪个"，或者"上一个人用什么我继续用什么"。图式选错，信息再准也白搭。图式的本质是约束读者的阅读方式：流程图引导你按时间顺序读，拓扑图引导你按空间关系读，树状图引导你按层级归属读。选型就是选"读者最舒服的阅读模式"。

2.1 流程类图：流程图、时序图、活动图的取舍

先说一个最常见的错误：把业务流程图画成"箭头大杂烩"。每个节点伸出三四个箭头，旁路分支比主路径还粗，最后主流程反而找不着了。

数据流类图的核心是"谁在什么时候做了什么"，顺序和分支是主角。适合用泳道图，把不同角色或系统分成横向泳道，节点落在各自泳道里，一眼就能看出职责边界和交接顺序。如果多个系统之间有时间上的先后依赖，时序图更合适，它的纵轴天然表达时间，横轴表达参与者，对研发群体尤其友好。

活动图则适合表达复杂的并行和同步逻辑。比如一个订单处理流程同时触发库存锁定、优惠券核销、物流预估三个并行任务，活动图里的分叉和汇合标记就能清楚地表达"哪些事情可以同时做，哪些必须等待所有并行任务完成"。选择逻辑其实很简单：主要看点是谁做了什么，选泳道图；主要看点是系统间消息的先后顺序，选时序图；主要看点是谁跟谁能并发、谁等待谁，选活动图。

2.2 结构类图：架构图与拓扑图不能混为一谈

这是很多人踩坑的重灾区。

架构图回答的是"系统由什么组成，它们之间怎么协作"，强调的是逻辑分层和依赖关系。画架构图时，图上的方块是逻辑模块，连线是调用关系或数据流。物理上跑在哪台机器上并不重要，所以数据库和服务可以画在一个水平层次的泳道内，哪怕它们部署环境不同。

拓扑图回答的是"系统部署在哪里，网络怎么到达"，强调的是物理节点和链路状态。画拓扑图时，每个节点都对应一个真实的机器或设备，连线对应实际的网络链路或通讯路径。

我在评审时见过一张图，把数据库、缓存、负载均衡、业务服务全画成一个个虚拟的云实例，同时又在上面标注了"内部调用"和"公网访问"。这张图既不是架构图——因为没有表达分层和依赖；也不是拓扑图——因为没有表达真实节点关系。受众想排查网络故障时找不到链路，想理解模块耦合时又找不到逻辑边界。正确做法是同一套系统拆成两张图：架构图给开发团队梳理代码模块，拓扑图给运维团队排查网络链路。不要让一张图同时承担两种语义。

2.3 关系类图：思维导图、ER图、力导向图的定位

思维导图适合"从中心主题向外发散"的初步梳理，因为它不需要表达关系的性质，只需要表达"这些事物同属于一个主题"。用思维导图做头脑风暴和需求收集很顺手，但不要拿它当正式设计文档，因为它不表达方向、强度、依赖。

实体关系图（ER图）适合表达数据模型，实体、属性、主外键关系非常固化，研发和数据库设计人员看到它就知道怎么建表。但如果读者是业务人员，ER图的信息密度会明显过高，建议优先给业务人员画数据流图，把ER图作为技术附录。

力导向图适合表达"非规则的多对多关系"，比如用户标签重叠、社交网络关系、服务依赖的网状调用。它的优点是直观表现聚簇和中心节点，缺点是节点一多就变成毛线球。使用力导向图的前提是节点数量可控，并且必须提供交互能力（比如悬停高亮、点击过滤），静态图片形式基本不适合承载这种图。

选型的底层逻辑归根到底是一句话：你想强调的信息，恰好是这种图式用默认方式最容易突出的信息。 选错了，读者就会一直被图式自带的"暗示"引向错误的方向。

3. 从草稿到成图：布局、连线与视觉层级的实操方法

确认了图式和信息层级，接下来才是真正的"画图"环节。很多人一上来就摆矩形框调颜色，半天过去图成了配色欣赏，信息结构还是一团浆糊。我自己的流程是先出"灰度架构"，再上视觉。

3.1 布局顺序：先骨架，后分支，最后才是装饰

任何一张图都有主路径。可能是架构图里的核心调用链，也可能是流程图里的主业务流。我习惯先把主路径上的节点用最简单的方框和直线摆出来，全部左对齐或居中对齐，间距均匀。这个时候只看"顺序对不对"，完全不考虑美观。

主路径稳定之后，再挂分支节点。分支节点尽量往主路径的同一侧放，比如所有异常分支统一放在主路径下方，所有辅助模块统一放在主路径上方。这样读者的视线始终被引导在主路径上，需要看旁支时才向两侧延伸。

最后一步才是布线。很多工具会默认用直角线，但直角线拐弯太多的时候容易跟其他线交叉。我的习惯是：跨层连接用曲线，同层连接用直角线。曲线让长距离跳转不显得生硬，直角线让短距离关系保持清晰。连线数量超过10根时，尽量避免每一根线都画箭头，可以在说明里加一条"默认箭头指向数据流向"，只在关键反向或异常路径上画显眼箭头。

3.2 网格对齐、留白与最小间距的三条底线

这是我从平面设计里借鉴来的三条硬规则，直接决定图的专业感。

第一条，所有节点必须对齐到网格对齐。绘图工具里开启网格吸附，相等层级的节点保持相同的宽度和高度，这会让图产生一种"系统很稳定"的视觉暗示。第二条，相邻节点之间至少保留一个节点宽度20%的留白，留白不足会让读者无意识觉得"这些模块好像粘在一起"。第三条，连线之间、连线与节点之间的间距不小于5像素（在缩放到100%时），否则打印出来就是一坨黑线。

间距之外，还有一个经常被忽略的细节：图层顺序。把连接线统一放在节点下层，不要让线从节点上面跨过去。节点边缘附近不要有平行于节点边框的走线，容易产生"这条线连的是这个节点"的错觉，实际上它只是路过。

3.3 颜色、线型、字体的信息层级规范

颜色是很多图翻车的最大源头。五颜六色的图看着热闹，但读图的人根本不知道该把注意力放在哪里。我的做法是整张图只保留一种强调色，其他色相全部压到灰色系。

具体来说，信息层级用"三层配色法"：背景和网格用极浅灰，主要节点用白色或浅灰填充，强调路径和当前焦点用唯一的强调色。如果必须表达多个并列的类别（比如三个子系统的边界），用同色系的不同明度弱化对比，比如深灰、中灰、浅灰，而不是红黄蓝三原色。

线型的语义也要统一：实线代表"确定的关系"，虚线代表"可选或间接的关系"，点线则尽量少用，因为打印出来容易看不清。再加粗或加箭头，只用于标注读者最需要关注的路径。

字体方面，图上少用纯文字，多用"名词短语"。节点标题限制在6个字以内，超过就拆成"节点名+附加说明"两个元素。全图最多使用两种字号，大号字标节点标题，小号字标辅助注释。字号层级多了，读者就会把注意力花在读文字上，而不是理解关系上。

4. 复杂信息怎么塞进一张图而不爆炸：分层、聚合、锚点

系统复杂是常态，但图是用来降低复杂度的，不是用来展览复杂度的。真正需要画大图的时候，我会用三个策略控制爆炸感：分层、聚合、锚点跳转。

4.1 按读者注意力做分层，而不是按系统模块做分区

很多人在图上画一个大虚线框写"支付域"，再画一个虚线框写"用户域"，然后各自塞一堆服务。这种做法叫"按模块分区"，它的问题在于：模块内部的服务和模块之间的交互往往同样复杂，虚线圈只是增加了一个归类层级，并没有降低阅读负担。

我倾向于"按阅读顺序分层"。把图从上到下分成"入口层—业务层—能力层—数据层"，或者从左到右分成"用户侧—服务侧—管理侧"。每个横向带里的节点数量控制在最少，节点在哪个带里，就决定了读者在阅读路径上什么时候会遇到它。

这样做的逻辑是：复杂系统里读者也是按时间顺序认知的，先看到请求入口，再一步步深入到数据存储。按模块分区会让读者在各区域之间反复横跳，而按阅读顺序分层则顺着人的自然认知推进。分层之后，如果某个横向带里的节点仍然超过10个，就在这一带里再细分出几个子区域，并在区域标题上注明"详见第X张子图"。

4.2 聚合与合并：把多个节点抽象成单一语义单元

聚合是降低复杂度的核心操作。三个服务如果总是同时出现、一起被调用、一起被部署，那在总览图里它们就是一个节点。比如一个短信服务、邮件服务、站内信服务，只要能统一对外提供"通知"能力，总览图里就聚合为一个"通知中心"，展开子图里再画具体实现细节。

聚合节点要在视觉上给出提示：可以在节点右下角加一个小折角图标，注明"可展开"，并在节点下方标注聚合数量（比如"3个服务"）。这样读者既不会误以为它只有一个实现，也不会好奇里面到底有什么而失去焦点。

合并同类项也是同样的逻辑。多个并列的功能模块用同一种图形样式，统一命名格式，比如所有"查询服务"都以统一的查询图标和同色边框呈现。读者不需要看内容，光看样式就知道"这是查询这一类功能"。

4.3 锚点跳转：编号、索引与子图的联动设计

大图不可能一张图承载所有细节，子图不可避免。子图和总览图之间的联动靠的就是锚点系统，规则很简单：

每个可展开的聚合节点或区域，在右下角标记一个编号（如 A1、B2）。对应编号的子图名统一写成"总览图编号+子图主题"，比如"A1-通知中心内部结构"。子图左上角必须放一个"返回总览图索引"的跳转说明，方便读者在纸张或PDF上快速定位。

这个做法本质上是给图建立目录结构。没有锚点的多图是一堆分散的碎纸片，有锚点的多图才是一个成体系的知识包。在文档里插多张图时，记得每张图都保有独立的标题，并在总览图下附一个编号索引表，列清楚每个编号对应的子图标题和页码。

5. 成图之后的十分钟自检与常见的五种"图病"

画完不等于做完。我见过太多图在屏幕上显得完美，打印出来细看却发现线压字、颜色对比度不足、边缘被截断。所以我每次定稿前都会强制自己走一遍十分钟自检流程，已经固定成了肌肉记忆。

5.1 十分钟自检清单：缩放、打印、盲测

先检查缩放。把图缩小到50%看整体结构，再放大到150%看局部细节。50%时应该能看出大致的区域划分和主路径走向，如果一团乱麻，说明布局的层级还不够清晰。150%时每个节点的文字都不应被截断，连线不应跟文字重叠。

再检查打印。很多工具里的屏幕显示和打印输出有差异，导出PDF后务必实际打印一张A4或A3看看效果。重点看灰度打印的颜色区分度，如果两个类别在灰度下完全不可分辨，就调整明度而不是依赖色相。

最后是盲测。找一位没参与设计的同事，只给图不解释，请他描述一下"这张图讲的是什么""你觉得下一步该看哪儿"。如果他的描述和你的设计意图偏离太大，不要急着补解释，请回到图上调整布局和信息层级。一张需要口头解释才能看懂的图，本质上还没设计完。

5.2 五种最常见的图病和对应的"处方"

这五种图病我在评审里见了无数次，写在这里当检查参照。

第一种叫"箭头恐惧症"，症状是图上箭头密密麻麻，方向五花八门。处方：非关键路径的连线全部改为极浅灰色细线，关键路径用强调色加粗，必要时可以省略部分反向线的箭头，用文字标注方向即可。

第二种叫"方块展览会"，症状是大量同尺寸、同颜色的矩形排成一排，没有任何视觉重心。处方：给主要节点增加一个衬底色块或外发光，让第一眼落在核心节点上，而不是平均分配注意力。

第三种叫"文字迷宫"，症状是节点里塞了长段落，图上文字密度堪比说明书。处方：节点内只保留名词短语，详细说明挪到图下方的注释区，用编号一一对应，图上无长句。

第四种叫"留白恐惧症"，症状是整张图把画布铺得满满的，四边没有余地。处方：强制给画布四周留出至少10%的空白区域，并把最重要的说明文字放在右下角（阅读视线最后一站），而不是塞在最拥挤的中央。

第五种叫"版本混乱"，症状是一张图在邮件、文档、PPT里各有一份不同步的版本。处方：给主图文件名加入日期和版本号，内部用"V2.3-20250315"之类的格式标注，子图引用锚点时把版本号同步列出。

5.3 图是活文档：迭代规则与变更记录

最后补充一点经验：图跟代码一样需要迭代维护。需求一变，图就得跟着改，否则图会从资产变成负债——一个过时的架构图比没有图更危险，因为它会误导决策。

我在项目里积累了一套简单规则：每次变更时先把变更点标红，而不是直接改新版本。标红的图发出去让大家在旧图上看到"哪里变了"；等变更评审通过后再合并成新版本，并更新版本号和修订说明。这样的好处是读图的人不必逐字对比新旧两张图，省时省力。

我自己还会在每张正式图的下方保存一行修订记录表，格式是"日期/修改人/变更内容摘要"。这行表很小，但回看三个月前的版本时，能直接回答"当时为什么这样设计"的问题。别小看这个细节，它能避免团队为了同一个改动反复争论。

最后分享一个我常用的收尾技巧

画的图多了以后，你会发现真正重要的不是鼠标技巧，而是"克制"。每次想往图里再塞一个信息的时候，先问自己：如果没有它，读者能不能得出正确结论？绝大多数情况下答案是能，那就果断不塞。

我在实际项目里还有一个小习惯：成图之后，把总览图设置成团队电脑桌面壁纸一周。一周里所有人都会反复瞄到这张图，任何结构别扭、层级混乱的地方都会在无意间被感知到，然后在周会上收到反馈。这个土办法看似随意，但比任何评审机制都更能让一张图真正"活"进团队日常协作里。下次你头疼一张图怎么设计的时候，不妨也试试先把草图画出来，贴到所有人天天能看到的位置，让真实的使用反馈告诉你怎么改。