企业官网建设流程全解析

如果你和我一样，经常要写方案、做评审、带新人，那你一定体会过"图没设计好"带来的尴尬：一张架构图画得密密麻麻，汇报时没人看；一张流程图逻辑没问题，但别人一眼看不懂；明明工具用得挺熟，产出的图却总是显得很业余。

"diagram-design"不是什么高深词汇，它就是图与表的设计功夫——把复杂信息组织成一张能被人快速读懂的视觉作品。这篇文章我会从原则、实操、复盘到踩坑，完整拆解我这些年做diagram-design攒下来的方法。不管是刚接触绘图的新手，还是已经画了几年图但总觉得"差点意思"的老手，应该都能找到能直接用的东西。

1. Diagram Design到底是什么：一个被低估的设计领域

1.1 图和表的本质是"信息契约"

我做了这么多年技术方案和项目复盘，最大的感受是：很多人把图表当成"文档里的装饰品"，觉得图就是给文字配个插图，画画框、连几条线就算完成。但图真正的本质，是一份信息契约。

你画一张架构图，等于在向读者承诺：按我这种方式去理解系统，你能建立正确的心智模型。读者看图，本质上是信任你提供的结构。如果一张图画完，读者脑子里形成的模型跟实际系统对不上，或者根本不知道从哪看起，那这张图无论多漂亮都是失败品。

我见过一个20多人的团队，系统架构图挂在 wiki 上两年没人更新，新人入职全靠老员工口口相传。问为什么没人看图，答案出奇一致："看了也看不懂，不如直接问。"这就是信息契约破裂的典型症状——画图的人没把读者当回事，读者自然也不把图当回事。

所以我的第一个观点是：diagram-design 不是一种美术能力，而是一种沟通能力。你需要先想清楚"这张图到底要让谁看懂什么"，再考虑用什么形状什么颜色。

1.2 为什么单独把diagram-design当一门功夫

很多人觉得画图难在工具不熟。说实话，工具从来不是核心瓶颈。一个拖拽式绘图软件，正常人20分钟就能学会画框和连线；真正的瓶颈在于：信息怎么组织、层级怎么划分、哪些细节必须出现、哪些细节必须删掉、视觉元素怎么承载逻辑关系。

同样一块业务，新手画出来是一张蜘蛛网，密密麻麻全是交叉线；有经验的人画出来是一张分层地图，读者沿着主路径走一遍，就知道数据从哪来、经过哪、到哪去。差别不在工具，而在设计。

diagram-design 这门功夫，横跨了三个领域：信息架构（决定放什么、不放什么）、视觉设计（决定怎么排布、怎么编码）、领域知识（决定术语和逻辑是否正确）。这三者缺一不可。

这也是为什么很多程序员写代码很厉害，画出来的图却一塌糊涂——因为他只完成了"领域知识"这一层，完全没有做信息架构和视觉编码。反过来，设计师画的图虽然好看，但如果对业务逻辑理解不深，图里就会出现明显的逻辑漏洞。diagram-design 的价值，恰恰是把这两种能力补全结合起来。

2. 设计一张好图的四个底层原则

2.1 原则一：先定义读者和意图

我画图之前从来不直接打开工具，而是先在脑子里（或者白板上）回答一个问题：这张图是给谁看的？

给刚入职的新人看，你必须画出服务边界、模块职责、请求主链路，把"怎么理解这个系统"讲清楚。给后端工程师看，你可能需要画到接口级别、数据表级别、消息队列的 topic 级别。给决策层领导看，你反而要减少技术细节，突出成本、风险、依赖关系和关键路径。

读者不同，同样的业务会画出完全不同的图。我踩过的最大坑，就是画了一张"给所有人看的架构图"，结果在汇报时领导问"为什么这么多框"，在开发评审时同事又问"这个模块底层怎么实现的怎么没画"。一张图承载了两批读者的诉求，最后谁都没服务好。

后来我总结了一个自问清单，画图前必须过一遍：

• 谁在看这张图？他已有的背景知识是什么？
• 他在什么场合看？是汇报、评审、排障还是自学？
• 看完之后他需要做什么决定？
• 他能接受的细节深度是多少？
• 这张图里哪些信息可以暂时不出现？

不要小看这几个问题，它们直接决定了图的类型、复杂度和抽象层级。我曾经在画一张数据流转图时，默认读者都懂"消息队列"，结果评审时发现一半人不知道 topic 和 consumer 的区别，整场会议全在解释概念。后来我把图拆成两张：一张画业务数据流，一张专门画消息中间件的内部结构，会议效率立刻上来了。

2.2 原则二：用层次代替平铺

新手画图最常见的毛病是"平铺"：把所有模块、所有连线、所有注释一次性堆在一个平面上，一视同仁。结果就是读者完全抓不住重点。

好的图一定是有层次的。所谓层次，就是你有一个主叙事线，其余都是支撑信息。就像看地图一样，你先看到主干道，再逐层放大到街道、巷子。图也需要这种缩放能力。

具体做法上，我习惯把图画成三层：

• 第一层是主链路：核心流程、核心模块、核心数据走向。这一层是读者第一眼必须看到的。
• 第二层是支撑依赖：缓存、消息队列、定时任务、外部系统这些辅助模块，用弱化方式呈现。
• 第三层是细节标注：接口名、字段名、协议、超时时间这类内容，除非必要，否则放到附录或者注解里。

实际画图的时候，这个原则体现为几种可落地的操作。

第一步，把图里的元素按"必须现在看"和"以后再看"分开。第二步，用分组容器或者背景色块把支撑模块归拢到图的边缘，而不是散落在主链路中间。第三步，用线型区分关系强度：主链路的连线全部是实线，支撑依赖用虚线，外部系统的交互可以用带箭头的浅色线。

我见过一个反例：有人画系统流程图，把十几个微服务的调用关系全部用同一种颜色、同一种线型铺开，每个服务旁边还标注了端口号和数据库表名。图倒是信息齐全，但读者扫一眼只会产生一个想法：这图怎么这么乱。其实只要把主流程抽出来加粗，其他依赖后移，图立刻就有"骨架"了。

2.3 原则三：视觉编码要一致

视觉编码这个词听起来专业，说白了就是：你图里的形状、颜色、线型、箭头，必须一以贯之有稳定含义。

很多图的混乱是"视觉语义冲突"造成的。比如同一个颜色的框，在第一张图里代表"服务"，在第二张图里突然代表"数据库"，读者就得不断回头猜。又比如箭头，一会实线一会虚线，但没有任何规律，读者根本分不清哪个是强依赖、哪个是异步消息、哪个只是触发关系。

我自己的默认规则是这样的：

• 矩形：模块、服务、系统边界
• 圆角矩形：流程动作、处理步骤
• 菱形：判断分支
• 平行四边形：数据、文件、消息
• 灰色框：外部系统或不在本次范围内
• 实线箭头：强依赖或同步调用
• 虚线箭头：异步、弱依赖或可选路径

这套规则不一定是行业标准，但它足够简单、全图一致、读者容易建立心理模型。你的团队完全可以约定自己的一套，但无论如何都不能今天用方形明天用圆形，今天红色表示告警明天红色表示主链路。

另外，任何非直觉的符号都要配图例。图例放角落不占地方，却能省掉读者大量猜测成本。我甚至养成了一个习惯：图里颜色超过三种，就必须在图例里写清楚每种颜色的语义。别相信"颜色自己会说话"，颜色从来不会自己说话。

2.4 原则四：命名和注释是图的一半

这个原则是我近两年感受最深的。很多图即便结构合理、层次清晰，仍然让人看不懂，问题大多出在命名上。

图的模块名，本质上就是代码里的变量名。变量名叫a1，代码再精简也没人看得懂；模块名叫"处理模块"，读者依然一头雾水。我给团队做图评审时，一定会问一个问题：如果这个框里不写字，光靠形状和连线，你能猜出它是什么功能吗？猜不出来，说明命名没有传递信息。

命名策略上我的建议是：

• 实体类模块用"名词+职责"：订单服务、库存管理、用户中心。
• 流程动作用"动词开头"：校验登录态、计算价格、生成支付单。
• 避免纯技术缩写：能写"支付回调"就不要写"PayCB"。
• 控制在8到12个字，太长就拆出更细的图。

除了模块名，箭头旁边的动词注释同样重要。两个模块之间的连线写"调用"是弱注释，写"同步查询用户信息"是强注释。箭头靠标签点明关系，读者就不用自己脑补了。

我还有一个习惯，图里出现任何领域特定术语，都会在底部加一条"术语说明"。这不是啰嗦，而是降低阅读门槛。现在很多图直接面向跨职能团队，产品、测试、运维都会看，你以为的常识对别人来说可能就是天书。

3. 完整实操：从零设计一张系统架构图

3.1 第一步：画前四问

现在说点能直接上手的流程。我给自己定的规矩，是打开绘图工具之前先完成"画前四问"，全部写成文字答案，然后才开始动笔。

四问分别是：

• 给谁看？明确读者群体和知识背景。
• 看多久？是汇报时的两分钟，还是文档里被反复翻阅的十分钟。
• 看完要做什么决定？定位问题、评审方案、学习系统，决定了图的侧重。
• 哪些信息必须删掉？主动做减法，防止信息过载。

举个例子。如果我要给刚加入团队的三位新同学画"订单处理链路"的架构图，我的四问答案大概是：读者是后端新人，熟悉基本开发但不熟悉业务；这张图会贴在项目文档里，他们入职前两周会反复看；看完之后他们需要知道"一个订单从发起到落库经过了哪些服务"；可以删掉的内容包括数据库表结构、缓存淘汰策略、消息队列的 topic 明细。

有了这四条答案，后续所有设计决策都有据可依。别名：如果后面有人质疑"为什么这里没画数据库表"，我可以说：因为对这批读者、这个观看场景来说，它不是必要信息。

3.2 第二步：草图与模块划分

画前四问写完，先别急着上工具。我会找一张白纸，或者打开白板软件的无限画布，用最潦草的方式把模块画出来。这一步的意义，是把脑子里的结构"外化"出来，方便调整。

模块划分有一些相对好用的切入角度：

• 按职责分：每个模块做一件内聚的事，比如鉴权、订单、支付、库存。
• 按部署边界分：不同进程、不同机器、不同团队维护的模块天然分开。
• 按数据流分：顺着一次完整流程走一遍，经过哪些节点就画哪些节点。

模块划完之后，做一次"边界数统计"：理想情况是一张图里3到7个主要边界。如果超过7个，读者很难一次记住；如果超过10个，我基本会考虑拆图。

这一步我的经验是：草图上不追求美观，只追求结构正确。该画歪就画歪，该写错别字就写错别字，重点是让模块之间的关系在大脑中成型。很多人在这一步就打开工具，不但拖慢了速度，还会因为忙着调整格式而干扰结构思考。

3.3 第三步：确定图表类型

很多人的困惑是"我该画流程图还是架构图？"。其实图表类型不是凭感觉选的，而是由你想表达的"信息结构"决定的。

我做了一个粗略的决策参考：

• 如果核心信息是时间顺序、流程先后，选流程图或泳道图。
• 如果核心信息是模块层级、包含关系、系统边界，选架构图或分层图。
• 如果核心信息是对象之间的消息交互，选时序图或协作图。
• 如果核心信息是数据的实体关系，选 ER 图或类图。
• 如果核心信息是状态迁移与触发条件，选状态机图。

注意，一个系统往往需要多张图协作，而不是指望一张"超级图"解决所有问题。架构图负责全局结构，时序图负责一次具体交互，ER 图负责数据模型。把多张图放在文档的同一章节，各自负责一个维度，比把所有维度揉进一张图清晰得多。

判断标准很简单：如果这张图需要加图例说明"这部分去看另一个文档"，那它可能已经超载了。

3.4 第四步：选择工具并落地

工具选择上，我会同时考虑功能、协作、版本管理和复用成本。市面上的工具大致可以分为几类：

• 在线白板协作类：适合头脑风暴、早期草图，实时协作强，但版本管理弱。
• 矢量绘图软件类：适合精细打磨、交付对外材料，样式控制灵活，但不适合频繁改动。
• 文本绘图工具类：用 DSL 脚本描述图，可版本管理、可 diff，适合放进代码仓库，但布局控制相对受限。
• 代码内嵌图表语言类：适合生成随代码变化的图，比如接口文档里的调用关系图。

我个人在团队项目里越来越偏爱文本绘图。原因很简单：它可以被 Git 管理，每一次改动都有记录，评审时可以像看代码一样看 diff。比如下面的片段就是一种文本绘图工具的示意写法，描述三个组件之间的调用关系：

[用户端] -> [接入网关] : 发起订单请求 [接入网关] -> [订单服务] : RPC 创建订单 [订单服务] -> [支付服务] : 生成支付单 [订单服务] -> [(MySQL)] : 写订单记录 [订单服务] --> [消息队列] : 发送订单已创建事件

这种写法的好处是：模块名称、关系、注释全部以文本形式存在，不需要手动拖拽对齐，也不会出现"连线怎么都对不上"的情况。缺点是自动布局有时不符合你期望的阅读动线。我的应对办法是：先画草图确定叙事顺序，再在文本里通过分组和排序，让布局引擎大概按我的思路排布。

3.5 第五步：细节打磨

结构正确、类型选好、工具落地之后，最后一步是让图"看起来舒服"。有些设计师会把这步叫视觉润色，但对工程师来说，我更愿意叫它"消除阅读摩擦"。

配色方面，我的保守建议是：主色不超过三种。可以选同一个色系的不同深浅，再加一个强调色。别一上来就做彩虹图，那是图表大忌。颜色多不等于信息多，反而把读者注意力切得粉碎。

线型方面，实线虚线一定要有稳定语义。我习惯把"主链路"全部用实线，把"异步通知""后台同步""可选路径"全部用虚线。如果两类线看起来区分度不够，可以把实线加粗一档，或者把虚线改成点线。

对齐和间距方面，所有框体尽量落在同一套网格上。手动拖拽时打开对齐吸附，框间距保持相对统一。箭头标签紧贴线条但不要压线，字体大小分三级：图标题最大，模块名其次，注释最小。缩小到50%再看一眼，如果还能舒服地阅读，说明图的基本功到位了。

4. 一次完整案例的复盘：同一张图的两版对比

4.1 需求背景与读者分析

为了让你更直观地看到设计差异，我拿一个真实做过的模拟项目举例：某跨平台系统的订单处理链路。

需求是这样的：团队最近来了三位新人，需要快速理解"用户从下单到订单落库"这条链路。与此同时，技术导师要求我画一张图用于周会汇报，说明当前系统的整体架构完善度。

我的分析结果是：新人和导师是两类读者，诉求完全不同，因此不应该共用一张图。新人需要的是可反复研读的链路图，导师需要的是宏观完整度和风险点。所以我把任务拆成两张图，这里重点复盘给新人的那张"订单处理链路图"。

读者画像明确之后，我给自己定的目标是：新人看完这张图，5分钟之内能说出"请求经过哪几个服务、每个服务做了什么、数据最终存在哪里"。

4.2 第一版：信息全塞进去

我的第一版画得相当失败。现在回头看，那正是典型的"平铺式绘图"。

第一版我做了什么呢？我把所有相关模块全部堆上去，包括用户端、接入网关、订单服务、支付服务、库存服务、积分服务、消息推送服务、定时任务、后台管理系统，甚至把每个服务对应的数据库表、缓存 key、队列 topic 都写在旁边。每个模块用了不同的颜色，连线有几十条，箭头方向有单向有双向，还有几条线交叉穿过大半个图。

这一版的问题显而易见，但当时身在局中没有察觉：

• 视觉噪音太多：读者第一眼不知道主路径在哪，需要自己从几十个框里找。
• 没有一个明确的阅读起点：图没有自上而下的叙事顺序，从哪个框开始读都行，但读到哪里都感到困惑。
• 术语不一致，有些模块写的是"网关"，有些写的是"API 入口"，同一个东西换了三个名字。

后来我拿这张图给同事做测试，他盯着看了两分钟，第一句话是："我应该从哪里开始看？"那一刻我就知道，这张图从信息契约的角度已经失败了。

4.3 第二版：按阅读动线重构

第二版我没有在原来的图上做修改，而是推倒重画。这次我先确定了一条主轴：按请求生命周期展开，从上到下一次是"入口 -> 鉴权 -> 业务处理 -> 持久化 -> 异步处理"。

第二版的核心变化是：只画用户端、接入网关、订单服务、支付服务、库存服务和数据库，外加一个异步消息队列。其他所有模块，比如定时任务、后台管理、消息推送，全部移出主图，作为第二张补充图来画。

视觉处理上，主链路统一用一种颜色，外部依赖和异步路径用灰色和虚线。每个模块下方只注一行职责说明，不再堆细节。箭头旁边都用动词短语标注了关系，比如"校验登录态""创建订单并锁库存""写订单记录"。

第二版的结构可以用文本示意表达：

用户端 ↓ 提交订单（HTTPS） 接入网关 ↓ 校验登录态，按用户维度限流 订单服务 ↓ 创建订单、预占库存、生成支付单 [库存服务] ← 同步扣减库存 [支付服务] ← 生成支付凭证 订单服务 ↓ 事务提交 订单库（主库） ↓ 异步抓取 只读库（供查询）

从结构上能看出，读者沿箭头往下看，整个链路一目了然。每一段箭头都有语义标签，新增的"只读库"也解释了为什么要做读写分离。

4.4 前后对比与改动理由

两版图给同一批同事看，反馈差异非常明显。第一版平均需要两三分钟才能理清主路径，第二版基本三十秒内就能说出核心链路。

我把两版的关键差异列了一张表：

逐条说改动理由：

第一，为什么去掉定时任务和后台管理？因为这两个模块跟"一次订单请求"的链路没有强关系。它们属于支撑系统，不是请求路径上的节点。把它们留在图里，只会让读者误以为主请求会经过它们。

第二，为什么数据库只画"订单库"而不画每张表？因为新人的目标不是设计数据库，而是理解链路。库的粒度刚好够用，表的粒度放到了 ER 图里去讲。

第三，为什么箭头标签都要写成"动词+对象"？因为"调用"这个词太含糊，它不告诉你调用之后发生了什么。写成"创建订单并锁库存"，读者不需要猜测，节奏就快了。

我实测下来，第二版用在团队评审会上，讲解时间从二十分钟缩短到了十分钟，而且新人后续提问的数量也明显减少。这不是我嘴皮子变利索了，而是图本身把该讲的话讲完了。

5. 常见问题排查与团队规范建议

5.1 一张图"怎么画都乱"的排查路径

如果你画完一张图总觉得乱，但说不上来哪里有问题，我建议按下面的路径排查。

第一步，数边界。把图里的主要分组、模块、大框数一遍，如果超过7个，大概率超载了。这时候不要试图精简框里的文字，而是考虑拆图：把图拆成"主链路图"和"支撑依赖图"两张。

第二步，数连线。如果连线超过20条，读者很难保持清晰。可以考虑把多条细节连线汇总成一条"总线"箭头，用注释注明具体调用关系。微服务架构里常见的"网状调用"尤其需要这样处理。

第三步，查交叉。交叉线是降低可读性的头号杀手。如果两条主连线交叉，优先调整布局方向，比如把A模块挪到旁边，或者把连线改成正交折线。实在避免不了交叉，我会用"跨线跳线"符号标注，避免读者误以为两条线相连。

第四步，做阅读测试。把图给一个没参与画图的人看，计时让他说出主路径。如果超过5分钟才说清楚，这张图就该重构了。这个测试我几乎每次画完图都会做，成本极低，收益极高。

5.2 用代码生图时的对齐与布局问题

文本绘图工具最大的优点是可版本化，但布局引擎有时候会给你"惊喜"：明明想让A在B左边，它却排到了B下面；明明希望箭头从上往下，它偏从左往右。

我的解决办法有三条。

第一，在脚本里显式指定方向。多数文本绘图工具支持top to bottom或者left to right这类全局方向设置，先把主方向锁定。

第二，用分组和隐形节点控制相对位置。如果你希望某个模块在视觉上属于某个大区，就把它们放在同一个分组块里，或者用一个隐藏节点固定锚点位置。

第三，把大图拆成多个子图。布局引擎处理大图的能力通常弱于人手，动辄四五十个节点的图，它排出来一定乱。与其和引擎搏斗，不如拆成若干张有清晰边界的小图，再用主图把子图的入口串起来。

我自己踩过的坑是：试图让代码自动排出一张完美的多层架构图，结果花了三个小时调参，不如花半小时拆成三张图。记住，代码生图的真正价值不是排版，而是"可维护、可追踪、可复用"。

5.3 非技术读者看不懂图的破解方法

给非技术读者画图，第一条原则是术语降级。把"鉴权"写成"登录校验"，把"消息队列"写成"通知缓冲"，把"读写分离"写成"主库写入、查询库读取，防止慢查询拖垮主库"。术语降级不是撒谎，而是换一种读者能理解的编码方式。

第二条是控制层级深度。给非技术读者看的图，层级不要超过三层。你不需要让他们知道网关里做的是 JWT 校验还是 OAuth2，只需要让他们理解"所有请求先进统一的入口，再分发给后面的服务"。

第三条是增加导读。图的上方加一句"这张图告诉你……"，图的底部加一个图例。我甚至会在复杂图旁边写一小段"阅读路线"，比如"先看蓝色箭头，再看灰色箭头"。这些辅助信息看似多余，实际能把读者的理解时间压缩一半。

第四条是按需出多版本。同一套系统，我会准备一张"对外简化版"和一张"对内细节版"。"对外简化版"用于汇报和产品宣讲，"对内细节版"用于开发评审。两张图并存，各司其职，不会为了迁就一方而牺牲另一方的信息完整度。

5.4 团队协作：从个人技巧到团队规范

个人会画图不算厉害，团队能长期维持一致的图表语言才算厉害。我参与过的团队里，图表规范做得好的，普遍做对了这几件事：

第一，统一模板。模板不是让你只改文字就算完，而是规定好颜色语义、线型语义、模块命名风格。新成员照着模板画，画出来的图天然和团队风格一致。

第二，命名规范进文档。把模块命名规则写成一条条 checklist，比如"实体用名词短语，动作用动词短语，禁止使用拼音缩写"。评审图的时候逐条过，保证规则被执行。

第三，图进版本管理。用文本绘图工具的团队，图脚本跟着代码仓库走。改了代码顺手改图，diff 里能看到图和代码同步变更，不会出现"图已经过期三个月"的情况。

第四，图评审制度化。代码有 Code Review，图也应该有 Diagram Review。评审时重点看三件事：信息是否过时、读者是否能快速找到主路径、视觉编码是否一致。

一套好的团队图表规范，能把图从"某个人画的东西"变成"团队共同维护的资产"。这一点在跨职能协作频繁的团队里尤其明显。

5.5 图表设计自查速查表

最后整理一份自查速查表，画完图之后对照检查，基本能过滤掉八成常见问题：

这张表不用背，打印出来贴在工位旁边，画完图对照一遍，几秒钟的事，能避免大多数"图乱了"的尴尬。

我个人做 diagram-design 这几年，最大的体会是"好的图不是画出来的，是删出来的"。每次画完初稿，我都会强迫自己问一句：这张图再删掉什么，依然成立？删到不能再删，图才真正能派上用场。如果你也想把图设计好，不妨从下一次画图前花五分钟做读者分析开始。这五分钟看起来是慢了，实际上是在帮你看图的人，省下后面不知道多少个五分钟。