企业官网建设流程全解析

刚接到"给业务画一张架构图"这个需求时，我第一反应是打开绘图工具，拖几个方块就开始连线。但等图真正画完交付，对方盯着屏幕问了一句"这里为什么用虚线"，我才意识到：diagram-design，也就是图表设计，远不是把形状拖到画布上那么简单。这个项目真正要解决的问题只有一个：如何让一张图在十秒钟内被看懂，并且中途不产生任何歧义。它覆盖从信息梳理、表达选型、版式布局到配色细节的完整链路，适合产品、研发、运营、文档写作者，以及所有需要把复杂逻辑讲清楚的从业者。

1. diagram-design 解决的到底是什么问题

1.1 先把边界划清楚：图表设计和数据可视化不是一回事

很多人一听"图表设计"，第一反应是柱状图、折线图、饼图。这是数据可视化，不是 diagram-design。两者确实都叫"图"，但处理的对象和思考方式差别非常大。

数据可视化的核心是数值，工作重点是选择合适的几何映射：用柱子的高度表达数量，用面积表达占比，用折线趋势表达变化。读者关心的核心是"多少""涨了还是跌了""哪一块最大"。

diagram-design 的核心是关系和结构。流程图表达步骤的前后顺序，架构图表达系统的分层与依赖，时序图表达对象之间的消息往来，思维导图表达概念的从属与发散。读者要在这张图里读到的，是一个逻辑、一条链路、一套边界，而不是一个数字。

如果分不清这条边界，很容易用"画数据图"的思路去做结构图。最常见的翻车现场是：为了好看，给每个节点加了一堆阴影、渐变和立体效果，结果读者盯着装饰看了半天，没看懂节点之间的依赖关系。diagram-design 的美学标准是"表达清晰优先"，装饰永远要让位于信息传递。

1.2 从原始需求到视觉表达，中间隔着四层

我见过很多图纸画的乱，不是绘图水平差，而是跳步了。从一段文字需求到一张合格的图表，中间至少要经过四层处理。

第一层是需求理解。你要搞清楚这张图是给谁看的、解决什么问题、读者已经知道多少背景。给老板看的架构图和给开发看的部署图，虽然都是"架构图"，但内容颗粒度完全不同。

第二层是信息分类。把原始需求里涉及的所有要素列出来，然后归类：哪些是角色，哪些是系统，哪些是动作，哪些是数据流，哪些是决策分支。这一步相当于给信息打标签，后面画图时才知道应该把哪个要素放到哪个层次。

第三层是结构建模。把分类好的信息组织成一个有方向、有层次的骨架。这一步不需要考虑配色和形状，只需要确定节点之间的逻辑关系，是顺序、是分支、是循环、是依赖还是聚合。

第四层才是视觉编码。把结构模型翻译成具体的图形语言：用矩形还是圆形，用实线还是虚线，用冷色还是暖色，放在画布的上方还是下方。

绝大多数人画图跳过了中间两层，直接从需求跳到视觉编码，于是只能跟着感觉走。图看起来"差不多"，但节点之间有没有依赖、箭头方向代表什么、分层依据是什么，全都说不清楚。后续只要需求有微调，整张图就得推翻重来。

1.3 一张图能不能交付，就看三个验收标准

经过大量实践，我把图表设计的验收收敛成三个标准，每次交付前过一遍，能挡住八成返工。

第一个标准叫十秒原则。一个陌生人看到这张图，十秒内能不能说出这张图在讲什么？如果看了十秒还在问"这个箭头是啥意思""这块阴影代表什么"，说明图的主干不清晰。处理办法是削弱次级信息，把最核心的一条链路突出出来。

第二个标准叫语义一致性。在一张图里，同一种线型、同一种颜色、同一种形状必须表达同一种含义。实线表示同步调用，那所有同步调用都画实线；虚线表示异步通知，那所有异步通知都画虚线。不能这张图里虚线表示异步，下一张图虚线又表示可选流程。图表设计的本质是一种局部语言系统，语言没有一致性，读者就只能靠猜。

第三个标准叫可维护性。需求变更时，这张图的改动成本是十分钟还是一小时？如果改一个节点位置导致八条连线要重排，说明布局设计不合理。好的图表设计应该让常见变更只影响局部，而不是牵一发动全身。

这三个标准，前两个面向读者，第三个面向作者自己。读者读起来省力，作者后期维护也不痛苦，这才是 diagram-design 的完整闭环。

2. 动手之前，先做类型选型与信息分层

2.1 六种常见图表形态与适用场景对照

我平时接触最多的图表形态有六种，每种解决一种关系类型。选型选对了，图就成功了一半；选型选错，后面怎么画都觉得别扭。

这里面有一个容易被忽略的点：图形名称往往比内容更早影响读者预期。你告诉别人"这是一张流程图"，他们就会期待看到时间先后；你告诉别人"这是一张架构图"，他们就会期待看到层级关系。如果一张图里有流程又有架构，最好是拆成两张，或者明确主次，否则读者会拿着错误的预期去读图，越读越困惑。

2.2 同样一段信息，为什么选架构图而不是流程图

有一次我要表达"订单系统涉及网关、订单服务、库存服务、支付服务、消息队列和数据存储"这段内容。如果按流程图来画，只能画成"网关 -> 订单服务 -> 库存服务 -> 支付服务"这样的线性序列。但实际系统里这些模块之间的关系不是一条直线，而是分层的：网关在接入层，服务在业务层，数据存储和数据层绑定，消息队列穿插在业务层和数据层之间做异步解耦。

用流程图硬画，会出现两个问题。第一，把分层关系压成了先后关系，读者会误以为"库存服务跑完才轮到支付服务"，但实际它们可能是并行调用；第二，数据存储和数据层的关系表达不出来，只能堆在末尾，看着像个多余的尾巴。

换成架构图，按"客户端 -> 接入层 -> 业务层 -> 数据层 -> 外部依赖"分层摆放，每个模块各归其位，消息队列单独画成横跨业务和数据两层的虚线连接，语义立刻清楚。所以选型的核心判断标准不是"这张图好看不好看"，而是信息的结构关系是否与图形的组织方式同构。顺序关系用流程图，从属关系用架构图，发散关系用思维导图，这是 diagram-design 的第一性原理。

2.3 实操：把一段文字需求拆成可画的图表语言

下面我用一个真实处理过的需求演示一下"信息分层"这一步怎么落地。原始需求文字大概是这样的：

"用户下单后，订单服务先校验库存，库存不足直接返回失败，库存充足则创建订单，然后调用支付服务。支付成功后发送消息通知仓储系统发货，同时更新订单状态。"

第一次接触这段文字，很容易直接上手画图。更稳妥的做法是先把里面的信息要素拆成四类：角色、动作、决策、数据流。

拆解结果如下：

• 角色：用户、订单服务、库存服务、支付服务、仓储系统
• 动作：下单、校验库存、创建订单、调用支付、发送消息、更新状态、发货
• 决策：库存是否充足
• 数据流：库存查询请求、库存结果、支付请求、支付结果、发货通知、订单状态更新

拆完之后，关系结构就自动浮出来了。这是一个带决策分支的流程，主链路是"成功路径"，分支是"库存不足返回失败"。角色之间是同步调用还是异步通知，文字里已经给了线索：支付成功后"发送消息"是异步，"调用支付服务"是同步。

到这一步，画图只是把拆好的要素摆进合适的布局里，构图思路完全是被信息结构牵着走的，而不是靠临场灵感。我把这个拆解过程沉淀成了一张自查表：先列角色，再列动作，标出决策点，最后画数据流，四步走完，任何一段文字需求都能变成图表语言。

3. 核心细节：布局、连线、配色与标注怎么定

3.1 布局选型的三种基本型

信息分层完成之后，接下来是布局。布局不是排版美学问题，而是认知效率问题。人的视线有天然的扫描路径，布局必须顺应这个路径，否则读者会觉得"图很乱，但说不清哪里乱"。

我常用三种基本布局型：

单向流布局，适合表达顺序逻辑。节点从上到下或从左到右排开，主链路是一条贯穿全图的线，分支往两侧延展。注意主链路必须比其他分支更突出，否则读者会被分支带偏。操作上，主链路的节点用实底填充，分支节点用浅色描边，视觉重量一眼就拉开差距。

分层堆叠布局，适合表达架构和归属。从上到下划分若干大层，每层内部放若干模块。读者阅读顺序是先整体后局部，先记住"接入层下面有业务层，业务层下面有数据层"，再深入看每个层内的模块关系。这里最大的坑是跨层连线。跨层线一多，整个层次结构就被视觉割裂。经验做法是让跨层连接统一从层间预留的通道走，不要直接穿过模块。

中心辐射布局，适合表达发散和从属。中心节点放核心概念，一级分支向外扩展，二级分支挂在分支上。这种布局在思维导图里最常见，视觉上形成一张网，但线的走向必须保持从内到外的一致性，不要内外交叉。

选布局的原则其实只有一条：布局结构要与本章节 2.2 里面确定的信息结构同构。顺序结构用单向流，层级结构用分层堆叠，发散结构用中心辐射。

3.2 连线的语义设计，比想象中更重要

连线是 diagram-design 里信息密度最高、也最容易被忽略的元素。很多人把它当作"两个框之间接一根线"就完事了，但线才是表达关系的核心手段。

我建议在一张图动笔之前，先把连线语义表定下来，并且在图例里明确写出。下面是我最常用的一套语义约定：

这套约定不是业界强制标准，但一旦定下来，必须在全图范围内强制执行。我吃过一次亏：在一张架构图里用虚线表示"异步消息"，又在同一张图的另一侧用虚线表示"可选调用"。读者问"同一根虚线，为什么这边是异步那边是可选"，我只能承认语义混淆。从那以后，所有图在动笔前都先花一分钟写线型语义表，贴在图例区。

连线还有个容易出问题的点：箭头方向。方向混乱的图，等于同时给了读者两套阅读语法。流程图按时间方向走，架构图按调用方向走，一旦选定方向，所有箭头都必须指向前进方向，回调和反向通知要么单独分层，要么跨层绕行，不能用一条倒转的箭头打断整个阅读节奏。

3.3 配色不靠感觉：三个参数和一套色板

图表设计的配色，很多人以为要懂色彩理论才做得好。其实不用，记住一个三层结构和一组比例就够了。

三层结构是：主色、辅助色、强调色。主色用于表达图中最主要的实体类别，比如架构图中的"业务服务"；辅助色用于表达次要实体类别，比如"数据存储"和"外部依赖"；强调色只用于突出需要读者特别注意的内容，比如报警链路、异常分支、正在变更的模块。

比例上，我参考设计领域常用的"60-30-10"法则。主色覆盖约百分之六十的视觉面积，辅助色约百分之三十，强调色不超过百分之十。如果画面里大面积出现强调色，说明强调色被滥用了，读者的注意力会被平均掉，等于没有重点。

具体到色值选择，我有三个参数：色相、饱和度、明度。同层级模块尽量使用同一色相，靠明度区分模块层级。比如业务层的模块都用蓝色系，但不同模块用不同明度，读者看到的是一组同色系的整体，而不是一块块互不相关的色斑。

另外要注意深色背景和浅色背景的适配。深色背景适合做演示图和汇报图，视觉冲击力强，但文字对比度要做好，正文文字尽量用浅色，不能用黑色；浅色背景适合做文档插图，打印友好，缺点是层次感弱一些，可以用浅灰底色做容器层，用实色做节点层来弥补。我个人的习惯是：文档插图一律浅色背景，演示大图才考虑深色。

3.4 文字、图例与注释的细节规范

连线和配色解决的是"关系"，文字解决的是"名字"。很多图表翻车，不是结构错，是文字摆放和层级出了问题。

第一，框内文字和框外标签要区分。模块名称放框内，说明性注释放框外，箭头上的动作标签放在线中段的上方。不要把说明文字也堆进框里，一个框塞五六个词之后，节点形状就会被撑得大小不一，整个布局跟着乱。

第二，字号要有层级。图表里至少要有三个字号层级：图标题最大，层标题次之，节点文字再次之。如果所有文字都同样大小，图就像一篇没有小标题的文档，读者只能逐字阅读，无法扫读。

第三，图例不是可选项。只要图里用了超过三种形状、三种线型或三种颜色，就必须配图例。图例放在图的右下角，不和主体抢视线。图例的措辞要具体，写成"实线：同步调用，虚线：异步通知"，不要只写一个"图例"两个字。

第四，注释编号化。需要额外解释的内容，只写短标题放图上，编号对应到图下方的注释区。一张图的注释不要超过五条，超过五条说明图本身太重了，需要拆图。

4. 实操全流程：从草图到一张能交付的成稿

4.1 工具选型：轻量协作、专业画布与代码化绘图怎么选

工具选择直接影响工作流。我不认为存在"最好"的图表工具，只存在"最匹配当前场景"的工具。按使用场景，我分为三类。

第一类是轻量在线协作画布，适合多人在同一张图上实时修改、讨论。优点是门槛极低、实时同步方便，缺点是画布自由度太高，容易变成不受控的"草稿纸"，样式统一性差。

第二类是专业绘图软件，适合做复杂大图和精细交付物。优点是组件库丰富、连线吸附、网格对齐这些机制非常成熟，图层和样式管理严格，缺点是学习成本稍高，不适合快速随手画。

第三类是代码化绘图语言，把图表当作代码来写，渲染结果由定义自动生成。这类方案有一个很独特的优势：图表可以进版本管理，可以做 diff 对比，非常适合团队协作中的文档型图表。修改图形就像改代码一样有记录可查。

我的选择逻辑是：团队头脑风暴和方案讨论用在线协作画布，正式对外交付的架构图和流程图用专业绘图软件，文档内嵌的、需要长期维护的图用代码化语言。三者各司其职，而不是只认准一个工具走到底。

4.2 分步实操：一个订单核心链路架构图的完整过程

下面我用一个"订单核心链路"架构图作为示例，带大家走一遍全部实操步骤。目标读者是研发团队，所以信息颗粒度要到服务级别。

第一步，确定画布和方向。浅色背景，画布比例十六比九，布局方向选分层堆叠，从上到下排五层：客户端、接入层、业务层、数据层、外部依赖。画布右上角留出图例位置。

第二步，定义信息要素。按章节 2.3 的拆法，角色是：用户端 APP、网关、订单服务、库存服务、支付服务、仓储系统、消息队列、数据库。决策点是库存是否充足。数据流是同步调用和异步通知两种。

第三步，先用结构化文本把构图想法落实，这一步相当于草图阶段。至少要把层级和节点归属写清楚：

layer 客户端 node 用户端 APP layer 接入层 node 网关 layer 业务层 node 订单服务 node 库存服务 node 支付服务 layer 消息层 node 消息队列 layer 数据层 node 订单库 node 库存库 layer 外部依赖 node 仓储系统 WMS

写出来之后，思路就顺了：这是一个五层架构，业务层是核心，消息队列单独成层，外部依赖放在最底部。

第四步，画容器和节点。每一层用一个浅色圆角矩形作为容器，层名标在容器左上角。节点用实心圆角矩形，主链路上的节点用主色填充，非主链路的辅助组件用浅色描边。

第五步，画连线。用户端 APP 到网关画实线单向箭头，网关到订单服务画实线单向箭头，订单服务到库存服务画实线箭头并标注"校验库存"。库存充足时订单服务创建订单，然后调用支付服务，实线箭头标"支付"。支付成功之后，订单服务向消息队列发异步消息，这一段画虚线箭头。消息队列到仓储系统之间再画一条虚线，表示发通知。

第六步，处理决策分支。库存不足这条分支不进入主链路，用一条浅色实线从库存服务侧边引出，指向一个"返回失败"的浅色节点。为了让读者注意力保留在主链路上，这条分支的节点饱和度要明显低于主链路。

第七步，统一检查。所有节点名称完整，所有箭头有方向，实线虚线的语义和图例一致。最后关掉网格线，缩小画布看整体结构是否平衡。

这张图做完之后，最明显的收益是：读者第一眼看到的是五层容器，十秒内能说出"这是一个从客户端到外部的分层架构"；深入读的时候，顺着实线主链路就能看懂下单流程；再看虚线才能理解异步通知部分。整个阅读路径被人为设计过了。

4.3 模板库与图层规范，让复用变成习惯

图表设计的效率瓶颈，很多时候不在于画一张图，而在于每张图都从零开始。我建议个人和团队都建立一个可复用的图表资产库，里面至少包含三样东西。

第一是模板文件。按图表类型建模板，每个模板里预设好页面尺寸、色板变量、线型定义、字号层级、图例位置。新图画好结构后，直接在模板上替换内容，样式永远不会跑偏。

第二是组件库。把常用的节点样式、容器样式、箭头样式、状态样式全部制作成可复用的组件，统一命名。命名规范我坚持"类型_用途_状态"三段式，比如"node_service_primary"表示主服务节点，"container_layer_bg"表示层容器背景。命名规范看起来麻烦，但图层数量一多，检索效率的差距立刻就出来了。

第三是色板文件。把主色、辅助色、强调色以及对应的浅色变体全部做成色板变量。所有模板和组件都引用变量，后面想换主题色，改一处变量全局生效，不用一个个节点去吸管取色。

建这套资产库前期要花一些时间，但后续收益非常大。我自己统计过，在资产库建立之前，一张中等复杂度的架构图从零到交付大约需要三小时；建立之后，同样的图通常一小时出头就能完成，而且交付质量更稳定。

5. 常见问题与排查技巧实录

5.1 图一放大全是字，根本没法看

这是新手做 diagram-design 最容易踩的坑：信息密度失控。一张图里塞了上百个节点，每个节点里都写了详细描述，最终成品只能在百分之一百二十的缩放比例下阅读，缩到整页就全是色块。

问题根源不是"信息太多"，而是没有分层承载。一张图的表达能力是有限的，把所有信息塞进同一张图，必然导致清晰度崩坏。排查和处理的建议如下：

• 确认这张图的核心使命。一张图只讲一件事，比如"订单主链路的调用关系"，其他内容拆出去。
• 把大图拆成总览图和细节图两级。总览图画到模块级，细节图针对某个模块展开到方法和数据字段级。
• 删除重复的视觉元素。同一个概念不要既在架构图里出现，又在旁边用注释文字解释一遍，图里出现一次的要素解释成本更低。
• 考虑折叠。"可展开/可折叠"的交互式画布是现代工具的标配，把次要细节收进折叠层，默认状态只展示主干。

如果一张图已经画完才发现过载，最快的补救方式是：把当前图定级为"总览"，复制一份作为"细节图"，然后把总览图里超过十五个字的节点描述删掉，只留名称。

5.2 连线满天飞，交叉到怀疑人生

连线交叉是图表设计里最影响观感的硬伤。两条线在画布中间交错，读者的视线会被打断一次，整张图如果存在多处交叉，阅读节奏基本就毁了。

交叉多的根因通常是布局时没有给连线预留通道。节点摆放得随意，导致连线必须绕来绕去才能接上。要从根本上解决，建议做三件事。

第一，调整布局方向一致性。所有节点尽量按同一方向流式排列，避免出现"第一行的节点接到第三行，第三行又拉回来接到第一行"这种走回头路的连线。

第二，使用正交连线。直线斜射连线虽然距离短，但视觉上刺眼；正交连线（先水平后垂直，或先垂直后水平）更容易和网格对齐，交叉区域也更容易控制。

第三，引入泳道或总线机制。如果多个消费者都要连同一个强依赖，不要每个节点单独画一根线出去，而是连到一条公共总线上，再从总线连到目标。这个思路和电路设计里的电源线画法很像，既能减少连线数量，又能表达"这是公共依赖"。

还有一个小技巧：连线上如果有文字标注，文字要放在水平段中间，不要放在拐角处。拐角处是视线拐弯的地方，文字放在那里最容易让人读串行。

5.3 多人协作改出来的图，风格像拼盘

团队多人协作时，最大的问题不是"谁改坏了内容"，而是样式漂移。同样一个服务节点，一个人画成蓝色实心，另一个人说"我这里是绿色，因为我在另一张图里用的绿色"；同一种虚线，一个人在两张图里语义都不一样。最后合并出来的成品，像几个不同风格的人分别画完再贴到一起。

这个问题靠"约定"解决不了，必须有机制兜底。我的实践是四条铁律：

• 所有样式必须引用模板里的共享样式变量，禁止手动填色值。
• 新增节点时只能从组件库拖拽，禁止直接复制基础形状自绘。
• 每次改图结束、交付之前，跑一遍样式检查清单：检查线型语义表、检查色板使用范围、检查字号层级。
• 有人偏离规范修改了样式，保留修改记录，评审时说明理由。

这套机制在执行初期会让一些人觉得"画个图而已，搞这么严格干什么"。但风格统一带来的收益很实在：读者在多个文档之间切换时，不需要重新学习每张图的图形语言。这就像同一个团队给出的代码都遵循同一套格式规范一样，降低了所有人的认知成本。

5.4 导出图片模糊、被截断、有白边

图表设计最后一步是导出交付。这一关翻车的概率非常高。给文档嵌图，导出的文件缩略图看不清；印刷预览，线的粗细和文字大小完全不对；发到群里，图片边缘被平台裁掉一块。

几个关键参数，建议每次导出前都检查一遍。

• 分辨率：文档用一张普通屏幕截图肯定不行。至少设置两倍尺寸导出，也就是画布分辨率乘以二，这样在 Retina 屏上才不会有发虚感。
• 安全边距：画布四周留出至少五十像素的空白。很多平台预览时会轻微裁切边缘，没有边距，最外层的框和箭头就被切掉了。
• 文字尺寸：导出的成品图如果会被缩略显示，最小文字的字号不能低于 10 点。缩略后小于 8 点的文字基本不可读，这部分信息等于无效。
• 格式选择：交付给文档用 SVG 这类矢量格式优先，缩放不失真；发到聊天工具或网页里，用常见位图格式，注意白底浅色图导出时选白背景，透明 PNG 在某些深色界面上会看不清。

还有一个容易被忽略的点：导出前先做一次"远距离测试"。把导出文件缩小到百分之二十看一下整体，再放大到百分之两百看一下细节。远看能看出布局是否平衡，近看能看出线条和文字是否清晰。两道检查都过了，再往外发，基本不会出大问题。

最后分享一个个人习惯

做了这么久的图表设计，我养成的最有价值的一个习惯其实特别简单：图快做完的时候，把画布缩到最小比例，闭上一只眼，用另一只眼"虚着"扫一下整张图。这个动作能让你暂时抛开细节，只感受视觉结构和重心分布。哪里太满、哪里太空、注意力是不是被拉到了非重点区域，在虚焦状态下一目了然。

还有一个每次画图前都会做的小动作：先给图起个标题。不是"订单流程图"这种泛泛的名字，而是"订单创建阶段库存校验与支付通知链路"。标题定了，图的边界就定了，后续所有信息取舍都有了依据。这个习惯帮我挡掉了无数次"画到一半发现方向错了"的返工。如果你只记一条建议，记这条就好。