企业官网建设流程全解析

最近在整理某跨平台系统的架构文档时，我发现一个很有意思的现象：团队里几乎每个人都会画图，但把大家画的图放进同一份设计文档后，一眼就能看出不是同一个团队的产出。有的图配色像彩虹，有的节点文字挤成一团，有的箭头交叉到连作者本人都理不清。后来我花了两周时间，把团队里所有技术图统一梳理了一遍，沉淀出一套基于“diagram-design”的方法和模板库。所有架构图、流程图、时序图、部署图全部改成同一套视觉语言和绘制流程后，设计评审的效率明显上来了。

这篇文章，我会把这套方法完整拆开讲清楚。它不是单纯教你怎么操作某个画图工具，而是把图表设计从“信息结构梳理”到“视觉规范落地”到“工具链自动化”的完整链路串起来，适合架构师、前后端开发者、技术文档维护者以及需要经常画设计图的产品同学参考。文章里的规范和模板都是可以直接抄作业的。

1. 先想清楚：一张图到底要表达什么

1.1 图乱不是因为画得差，而是因为信息层级没分

我见过太多人打开绘图工具，第一件事就是拖一个矩形框出来，然后开始填文字。这是图表设计里最大的误区。画图跟写文章一样，动笔之前先得想清楚主题和结构。一张图看上去“乱”，九成以上不是配色问题、不是字体问题，而是信息层级堆在了一起。

举一个最典型的反面案例。有人画某支付网关的系统架构图，在一张图里既用虚线框画了部署环境（容器区、数据库区），又用箭头画了服务间的调用关系，还在角落里标注了团队组织架构。三个完全不同维度的信息叠在一起，结果就是看的人不知道该先看哪里，线条和容器互相穿插，逻辑关系全被视觉噪音淹没。

我在团队里定了一条规则：一张图最多承载三个信息层次。第一层是区域边界，用容器表达，比如“接入层”“核心业务域”“数据层”；第二层是组件或节点，用矩形表达，比如API网关、订单服务、用户服务；第三层是交互关系，用箭头和标签表达，比如调用、返回、读写。超过三个层次，就必须拆图。这条规则执行以后，图纸返工率降了一大截。

1.2 六步设计法：把“画图”变成“翻译信息”

我总结了一套六步法，每次画图前按顺序走一遍，能避开大多数常见问题。

第一步，明确读者。这张图是给谁看的，决定了抽象层级。给老板做汇报，只需要画三个大盒子外加几条主链路；给新入职同学做培训，就得把服务边界、外部依赖、基建环境都标清楚。同一套系统可以有不同的图，核心是别把两个读者塞进同一张图。

第二步，写出一句话结论。动笔画图前强制自己写一句话，这句话是“本图想让读者看到什么”。例如“来自开放平台的请求如何经过身份校验后进入订单域”。写不出来，说明你自己都没想明白这张图存在的意义，那就别急着画。

第三步，信息分层。把所有要表达的元素列成清单，分成主对象、辅助对象、背景装饰三类。主对象是图里必须出现的节点；辅助对象是帮助理解主链路的中间节点；背景装饰是那些“画上去显得专业”的墙纸，比如网格线、渐变背景、大批logo，统统删掉。

第四步，确定流向。箭头方向是读者理解图的主线索。技术上分为顺流、回流、旁路三类。一张图上主链路只能有一条，用最粗的颜色标识；支路超过三条就考虑拆图。很多图看着乱，就是因为把所有箭头都画成一样粗，读者根本无法判断哪个流程才是核心。

第五步，统一符号语义。矩形代表系统或组件，圆角矩形代表用户操作或状态节点，菱形代表判断分支，箭头代表依赖或者数据流。这套语义必须在团队内保持一致，并且写进规范文档里。否则A同学用圆形代表微服务，B同学用圆形代表数据库，图就失去通用性了。

第六步，套用视觉规范。把前面确定的颜色、间距、字号放进全局主题文件里，让所有图自动继承统一风格。关于视觉规范的具体数值，我在第3节会展开细说。

1.3 高频图表类型与各自的设计侧重点

不同图表的表达核心不一样，规范化的优先级也不一样。我整理了一个对照表，方便快速定位：

这里有件事值得单独拿出来说：上面这些图，本质上都可以用“确定性语法”来描述，也就是用代码来定义。这是它们适合代码化绘制的根本原因。既然如此，那工具选型的问题就变成了“用哪套代码化语法”，而不是“用哪个拖拽工具”。

2. 工具选型：从白板到代码化图表的迁移路径

2.1 三层能力模型：白板、拖拽工具与代码化绘制

我习惯把图表绘制能力分成三层。

第一层是白板随手画，对应灵感草稿阶段。这时候的目的是快速捕捉思路，不需要画得漂亮，用纸笔或者一块白板就够了。我强烈建议不要在这个阶段打开绘图软件，因为工具的对齐、吸附、调色功能会严重拖慢思路速度，人容易陷进“调格式”而不是“想逻辑”。

第二层是拖拽式绘图工具，对应一次性交付阶段。适合画那种不需要频繁修改、不需要多人协同编辑的图，比如给某个专项汇报临时画一张网络拓扑。优点在于所见即所得、上手快，缺点也很明显：源文件难以做文本对比，修改时对齐操作繁琐，多人同时编辑容易互相覆盖。一次性的图，用它没毛病；需要持续维护的图，风险就大了。

第三层是代码化绘制，对应长期维护阶段。画图用写代码的方式完成，图被定义为文本文件，可以被Git管理、被CI检查、被自动化导出。这层的学习曲线看着陡，实际用熟了以后效率反而最高。特别是团队协作场景下，代码化图表最大的优势是可diff、可review。别人改动了一个节点，提个合并请求就能做图形变更审查，这在拖拽工具里基本做不到。

我的建议是，草稿在白板上，正式交付用代码化，拖拽工具只用来做现场演示和快速临时图。按这个分配，既不会浪费时间，也不会埋下维护的地雷。

2.2 三个主流代码化方案怎么选

代码化绘图的方案不少，这里只说我用下来比较顺手的三套：PlantUML、Graphviz、D2。它们的定位差异很大，选错工具会带来很多不必要的痛苦。

PlantUML最大的优势是语法门槛极低，能以接近自然语言的方式写时序图、用例图、活动图，尤其适合UML家族。它还自带Java生态的集成能力，配合文档渲染插件很方便。代价是它对复杂布局的控制力比较弱，节点的精确位置基本不能自定义，稍微复杂的架构图容易排得“看运气”。

Graphviz是传统布局算法之王，核心能力是自动排版，尤其擅长表达网络拓扑、依赖关系这类网状结构，通过rankdir、cluster这些机制能表达比较丰富的布局语义。但它的语法上手略啰嗦，画节点和边需要记不少属性名。

D2是较新的方案，语法设计现代、类型清晰，定位偏基础设施与管线设计，写出来的声明式代码比Graphviz优雅不少，对复杂图的支持也逐步在完善。它的生态相对年轻，社区模板和现成示例还没有前两者多。

我现在的工具组合是这样的：UML时序图、活动图、用例图这类偏软件建模的图，统一用PlantUML；涉及网络分区、部署环境、多机房拓扑这类偏基础设施的图，统一用Graphviz；如果是团队里有人比较偏好现代语法，需要快速搭建管线类示意图，就引入D2。工具不追求唯一，追求的是每个场景选顺手的那一个。

这里有一条很重要的判断原则：不要在某个方案里硬塞它不擅长的图。比如非要用PlantUML画一张复杂的云上网络拓扑，连线会乱到你自己都不想看第二遍。图表的表达能力是工具选型的第一约束。

2.3 把工具链接到团队协作

选好工具只是第一步，真正让规范落地的是把工具链接进团队的日常协作里。我建议按下面三个步骤来做。

第一步是建立主题文件。把颜色、字体、线宽、箭头样式全部抽到一个公共主题文件里，其他所有图都通过include引入这个主题。这样改一次主题，全仓库的图同步更新，不需要逐张图去调样式。

第二步是约定目录结构。源文件统一放在src目录，按图的类型分子目录；产出的图片统一导出到out目录。源文件进版本控制，导出产物可以进也可以不进，取决于团队的交付要求。

第三步是把导出做成自动化脚本。建议写一个简单的批量导出脚本，每次有源码变更就执行一次，自动导出SVG和PNG两种格式。再进一步可以把导出脚本挂进CI流程，任何图源文件变更后，系统自动重新生成图片并附在变更记录里。这样能避免最常见的协作问题：“源码改了，导出的图忘了更新”。

3. 视觉规范：一套让人“不费脑”的图表设计体系

3.1 画布与网格：对齐是省力的核心

视觉规范的第一项不是颜色和字体，而是画布与对齐网格。我团队里所有图的默认画布都是1920乘1080，避免不同屏幕比例下导出效果不一致。网格步长统一设为8像素，所有节点的间距、边框的留白都按8的倍数取值。

为什么对齐能解决大半的“乱”？人的视觉系统对整齐的东西天然更容易处理。节点与节点之间如果出现6像素和13像素混合的间距，大脑会不自觉地花时间去分析这些细微差异，拖慢理解速度。统一用8像素网格后，图面会产生稳定的节奏感，读者可以把注意力全部放在箭头和数据流上。

在Graphviz里，可以通过nodesep和ranksep控制节点间距；在PlantUML里，通过skinparam的padding参数控制内部留白。只要把这些值固定成8的倍数，就能保证不同人画出来的图在间距风格上保持一致。

3.2 颜色三原则与可直接照抄的色板

图表配色不是靠审美，而是靠纪律。我定下三条原则：第一，颜色数量不超过7种，超过就会产生严重的视觉噪声；第二，颜色必须承担语义功能，不能只当装饰；第三，全图最多一个强调色，用来突出主链路或核心结论。

下面这套色板是我们在某跨平台系统文档里实际在用的，可以直接搬走：

这套色板的选取逻辑是：主体用中性灰蓝系，保证图面干净；唯一的高饱和蓝色留给最重要的信息；橙色和绿色只在表达异常与健康时出现，平时禁用。如果你发现某张图里出现了这7种之外的颜色，基本说明那个颜色是多余的。

3.3 字体、线宽与间距

视觉规范的下一项是字体与线宽。中文字体推荐直接用系统默认的无衬线字体，比如“Microsoft YaHei”或“PingFang SC”，不需要额外嵌入艺术字体。字号设置三档：图标题16像素、节点内文字14像素、细节注释12像素。图上最小字号不低于12像素，否则导出PPT或者打印出来会看不清。

线宽也分三档：普通连线用1像素，主链路用2像素，区域边框用1像素但配合底色来区分。为什么要这样分？因为线的粗细是图面层级最重要的视觉提示。所有线一样粗，读者就分不清主次。主链路加粗以后，一条图的阅读路径就非常明确，即便节点很多，视线也会自然沿着粗线走。

间距方面坚持8的倍数原则，但还有一个容易忽略的细节：容器内部的padding要大于容器之间的gap。比如一个分组容器内部的节点距离容器边至少16像素，而容器与容器之间的距离可以压缩到12像素。这个“内紧外松”的设置能让分组关系更明显。

3.4 命名与注释：让图自己会说话

图里所有节点的命名都应该遵循“名词短语”，比如“订单服务”“API网关”“用户库”；所有连线的标签都应该用“动宾短语”，比如“调用订单接口”“写入用户数据”“返回401”。这样做的目的是让读图的人能像读一句话一样理解图：主语是节点，谓语是连线，宾语是目标节点。

还有一个很容易被忽略的细节：图内一定要有图例。即便你的团队已经统一了符号语义，新同学第一次看你的图，仍然需要知道虚线箭头和实线箭头有什么区别。在一张图的右下角放一个迷你图例，标注“实线=同步调用，虚线=异步通知，橙色=降级路径”，能省掉大量口头解释。

4. 实操：搭建一套可直接复用的图表设计模板库

4.1 目录结构与主题分离

代码化图表的目录结构非常重要。我建议按下面的方式组织：

docs/ diagrams/ theme/ common.plantuml style.plantuml src/ system/ order-system.puml business/ refund-flow.puml infra/ deploy-topo.dot sequence/ login-sequence.puml out/ png/ svg/

src目录只放源文件，theme目录放所有公共样式，out目录放导出产物。源文件和导出产物分离，能避免图片和源码混在一起导致仓库体积膨胀，也能让自动化导出脚本只关注out目录，不用处理乱七八糟的中间文件。

4.2 写一个全局主题文件

以PlantUML为例，主题文件可以这样写：

' theme/common.plantuml skinparam backgroundColor #FFFFFF skinparam componentStyle rectangle skinparam defaultFontName "Microsoft YaHei, PingFang SC" skinparam defaultFontSize 14 skinparam linetype ortho skinparam ArrowColor #1F2937 skinparam BorderColor #9AA7B4 skinparam ArrowThickness 1 skinparam RectangleBorderThickness 1

注意这行：skinparam linetype ortho，它把连线强制设置为正交折线。正交连线意味着箭头只有水平或垂直方向的转折，没有斜线。这一点非常影响观感，斜线多的时候图会显得很“飘”，而正交连线会让结构感强很多，这也是很多专业架构图看起来稳的原因。

4.3 架构图模板落地

系统架构图是技术文档里出现频率最高的图。下面给出一个可直接扩展的模板：

@startuml !include theme/common.plantuml package "接入层" { component [API Gateway] as gw component [Web Console] as web } package "核心业务域" { component [Order Service] as order component [User Service] as user } package "数据层" { database "MySQL" as db } gw --> order : 同步调用 web --> order : 同步调用 order --> user : 校验用户 order --> db : 读写订单 @enduml

这个模板的关键在package的使用。package的作用是把节点按区域边界分组，避免了所有节点平铺在一张画布上的混乱感。读图的人第一眼看到的是三个大包，然后才进入每个包里看具体组件。这就是区域边界带来的层级感。

4.4 流程图模板落地

流程图与架构图不同，它要表达的是“谁在什么条件下做什么”。所以流程图设计的核心是泳道，也就是角色分区。用PlantUML的活动图语法可以这样写：

@startuml !include theme/common.plantuml |客户端| start :提交退款申请; |服务端| if (校验订单状态?) then (有效) :创建退款单; :调用支付通道; else (无效) :返回错误码; stop endif |支付通道| :受理退款; :结果回调; |服务端| if (回调成功?) then (是) :更新退款状态; stop else (否) :记录异常并告警; stop endif @enduml

把不同角色放进独立的泳道，可以非常直观地表达系统边界和职责范围。这个模板的变体可以覆盖支付、审批、工单等大量业务场景。分支编号很重要，如果分支超过两个，建议给每个分支加编号（分支1、分支2），这样在排查问题的时候，可以通过图中编号快速对齐日志上下文。

4.5 部署拓扑图模板落地

部署拓扑图的核心是表达分区与连通。用Graphviz来画这类图是合适的，cluster的机制天然适合表达安全域：

digraph infra { rankdir=TB; nodesep=0.6; ranksep=0.8; subgraph cluster_mz { label="服务区"; style="rounded"; app1 [label="应用节点-1"]; app2 [label="应用节点-2"]; } subgraph cluster_data { label="数据区"; style="rounded"; db [label="主库"]; dr [label="备库"]; } app1 -> db [label="JDBC 3306"]; app2 -> db [label="JDBC 3306"]; db -> dr [label="主备同步"]; }

Graphviz的rankdir=TB表示从上到下布局，cluster_mz和cluster_data把节点收进两个独立的安全区域。箭头标签直接标注端口和协议，网络策略人员看这张图的时候可以直接对照防火墙规则，非常实用。注意cluster子图的名字必须以cluster开头，否则Graphviz不会把它识别为区域容器，这是新手最容易踩的坑。

4.6 批量导出与自动化

模板库建好之后，需要一套可靠的导出脚本。我用一个bash脚本解决：

#!/usr/bin/env bash set -e # 导出所有PlantUML源文件 for f in src/system/*.puml src/business/*.puml; do plantuml -tsvg -o ../out/svg "$f" plantuml -tpng -scale 2 -o ../out/png "$f" done # 导出所有Graphviz源文件 for f in src/infra/*.dot; do dot -Tsvg "$f" -o "../out/svg/$(basename "$f" .dot).svg" dot -Tpng -Gdpi=200 "$f" -o "../out/png/$(basename "$f" .dot).png" done

这里的关键参数是-scale 2和-Gdpi=200，它们解决的是图片清晰度问题。如果直接导出1倍像素的PNG，插到文档里放大看会发虚。所有图片按2倍导出，在文档中按一半尺寸展示，实际显示效果会非常锐利。这个细节看起来小，但对阅读体验的影响很大。

5. 避坑清单：图表设计中那些高频返工现场

5.1 问题速查表

我把实际工作中遇到的高频问题整理成了一个速查表，遇到问题可以先对照这个表排查：

5.2 图标与Logo的使用边界

这是我在项目里踩过的一个坑。最初为了图面好看，有些同学给每个服务节点加了真实的软件Logo图标，比如数据库用某个熟悉的数据库Logo，缓存组件用某个缓存产品的Logo。结果一张图里图标风格五花八门，有扁平的有立体的，有彩色有黑白，反而显得很廉价。

后来我们定下规则：除非是面向客户演示且需要品牌背书，否则一律不用真实Logo。用统一风格的抽象图标代替，或者干脆用文字加一个小圆点标识。这样既保持了图面一致性，也避免了版权风险。如果你必须在图中使用某产品Logo，请确认来源和授权，不要随手从搜索引擎扒图，许多知名软件Logo的商用使用是有严格限制的。

5.3 方案选的图也要讲版本管理

代码化图表最大的收益是版本管理，但前提是拆分合理。如果几十张图全放在一个巨型文件里，每次编辑都可能产生大范围冲突，那版本管理的优势就被抵消了。

我建议按“一个上下文一个文件”来拆。某跨平台系统的图表库，我们拆成了三十多个文件，每个文件只描述一个子系统或者一个业务场景。多个同学同时改不同的文件，互不干扰。如果两个文件有公共的依赖关系，就把公共信息抽到theme或者include文件里，而不是两边各写一份。跨文件引用时，用注释标明来源，方便追溯。

5.4 图太大或者导出被截断

图内容太多时，不要试图把所有信息塞进一张大图。这里有一条经验法则：一张图如果超过15个节点，维护成本和理解成本都会急剧上升。处理办法是把图拆成“总览图+局部细节图”两层。总览图只画核心模块和它们之间的粗粒度连线；每个核心模块再单独出一张细节图，画它内部的组件和接口。两级图之间用相同的节点命名建立对应关系。

如果总览图还是太大，可以在图内部做“放大镜”约定：某个节点右上角画一个放大镜符号，表示这个节点在另一张图里有展开版本。这个约定配合目录结构，能让读者在多层图之间快速跳转。

6. 复盘与心得：这套方法真正值钱的地方

6.1 一致性的价值远比“好看”重要

把图表规范落地到某跨平台系统的文档体系之后，我最直观的感受是评审效率的变化。以前一张架构图拿出来，主讲人需要花十分钟解释各种框和线的含义，因为每个框的语义只有画图的人自己知道。现在图拿到手，所有人默认遵循同一套读图习惯：先看区域容器，再看节点，最后看连线颜色，就能直接理解图的逻辑。评审讨论的焦点从“这个框是什么意思”变成了“这个链路是否合理”，效率提升非常明显。

6.2 六步法真正改变的是流程，而不是画风

我最初以为这套工作的核心是模板和主题文件，复盘之后才意识到，真正有价值的是六步法里“先写一句话结论”和“信息分层”这两个动作。以前画图是看到工具就开画，现在变成了先梳理文本，再翻译成图。有时候整理完一句话结论和名词清单，甚至会发现方案本身有疏漏。一张图的问题往往是方案表述出来的症状，一个说不清楚的架构图背后，通常对应着一个还没想清楚的设计。

6.3 后续可以继续扩展的方向

图表设计体系跑顺之后，还可以往三个方向扩展。第一是动态化，把静态的SVG图升级成基于HTML的可点击图，节点可以展开子节点，链路可以过滤展示；第二是自动化生成，比如从接口定义文件自动生成服务依赖图的初始骨架，然后人工补充细节；第三是把图表检查接入CI流程，通过脚本检查每张图是否超出画布、是否缺少图例、是否出现了规范色板之外的颜色。这三件事做下来，图表维护成本还能进一步降低。

我自己实操下来的体会是，diagram-design最值钱的部分从来不是画出来的图多漂亮，而是它迫使每个画图的人在动手之前，先把信息结构想清楚。很多图反复返工，不是因为软件用得不好，而是动手前没想明白到底要表达哪个层次的内容。想明白这一点，你就会发现，画图这件小事，其实是技术表达里性价比最高的一项投资。