企业官网建设流程全解析

经常有同事拿着我画的架构图问我：你用的是什么工具？为什么同样一堆服务，你画出来大家一眼就能看懂，别人画的却要在评审会上被来回追问？其实我用到的绘图软件和大家没什么区别，真正起作用的是过去几年我慢慢沉淀下来的一套图表设计规范。我管它叫diagram-design。

这套东西不是某个具体软件，也不是一个模板库，而是一组关于“图应该怎么画”的约束：选什么图型、用什么形状、给什么颜色、线往哪边连、字写多长。它解决的是一个很现实的问题——技术团队每天都在产生大量流程图、架构图、时序图，但大部分图画完只有作者自己看得懂，换个人来读就像看天书。如果你也被这类问题烦过，不管是开发、架构师、产品经理还是技术写作者，这篇内容应该都能帮到你。我会从选型、规范、实操流程到避坑技巧，把diagram-design完整拆开讲清楚。

1. 图表设计为什么值得当成“正事”来做

1.1 一张烂图会吃掉团队多少时间

我印象很深的一次评审会，架构师准备了一张系统部署图投在屏幕上，从第一排开始讲，结果讲了十分钟还没说清楚核心链路。原因很简单：图上三十多个节点，一半用了同一种颜色，箭头方向有左有右有斜穿，数据库和服务器的图例完全没标，甚至连哪个是核心模块都要靠猜。那场会开了将近两个小时，最后只确认了图里最上面一层的三个模块。

这不是个例。很多团队每画出一张技术图，都对应着一次或多次评审、宣讲、交接。图本身画得不清楚，这些场合的沟通成本就会成倍上升。你可以把技术图理解成装修时的水电图：没有图纸，工人改一个插座可能都要凿开一面墙；有了清晰的图纸，后续所有改动都有据可依。架构图、流程图在软件团队里的作用完全一样，它们不是写文档时的装饰品，而是让信息从一个人脑中迁移到另一个人脑中的载具。

围绕这个场景，我慢慢把图表设计中的图形、颜色、排版、文字、图例这些要素收敛成了一组可检查的规则。执行这些规则之后，最明显的变化是：评审会很少有人再问“这个框是什么意思”“这条线为什么这么画”，大家把精力放回了业务判断本身。

1.2 diagram-design 是什么：不是画图工具，而是一套表达约束

diagram-design本质上是一套“表达约束集”。它不规定你必须用哪款软件，也不规定所有的图都必须长成一个样子。它只约定几件底层的事情：图形代表什么、颜色代表什么、连线方向怎么走、文字写到多长、图例怎么放。

为什么约束反而有用？因为人类阅读图形时依赖的是“预期”。我们看到一个圆角矩形，会预期它是个步骤；看到菱形，会预期这里要分叉。如果一张图里这些形状被随意使用，读者的预期就被不断打断，理解速度自然下降。反过来，当全团队都用同一套图形语义时，任何一张新图画出来，大家不需要重新学习它的符号系统。

这套规范的核心可以压缩成三句话：形状有固定语义、颜色只表语义不表装饰、连线方向必须可预期。在此基础上再考虑布局和文字粒度。它不追求让图变得多漂亮，而是追求让图“可被审阅”——像代码一样，能讲得出哪里对、哪里不对。

1.3 这套东西适合谁、不适合谁

从适用边界来看，diagram-design适合所有以“信息传递”为目的的技术图，具体包括：系统架构图、流程图、时序图、部署拓扑图、ER 图、状态图、以及产品路线图。这些图共同的特点是：有明确的节点和连线，有依赖关系或先后顺序，读者需要快速定位关键路径。

不太适合的是另一类图：数据可视化大屏、运营看板、品牌视觉海报。那些场景更注重视觉冲击和信息量，可以使用更自由的配色和创意布局，强行套用这套约束反而会束手束脚。

所以使用这套规范时应先做一道判断题：这张图是要让人“看图做决策”，还是让人“看图感受风格”。前者是diagram-design的适用场景，后者不在讨论范围内。

2. 选型先行：知道这张图要回答什么问题

2.1 六个高频业务场景和对应图型

很多团队画图乱，不是绘制能力不够，而是从一开始就选错了图型。流程图被画成架构图，架构图被画成泳道图，状态图被画成流程图——方向错了，后面的细节再标准也很难救回来。

我把日常工作中遇到的技术图场景归纳成六类，对应六种最常用的图型：

这套对应关系看似基础，但值得反复对照。我见过太多团队把“状态流转”画成了“操作流程”，把“模块依赖”画成了“时间顺序”，结果读者不断追问“这个流程为什么会有环”。本质上不是逻辑错误，而是图型表达不了作者想说的那句话。

2.2 选型上的三个坑

第一个坑：把状态图画成流程图。订单状态机里有“待支付、已支付、已发货、已取消”，状态之间靠“支付成功、超时关闭、用户取消”这些事件触发。你当然可以用流程图来描述一段业务操作，但如果你真正想表达的是“订单允许从哪些状态迁移到哪些状态”，那就必须用状态图。用流程图强画状态迁移，会出现大量多余的分支判断，图面迅速失控。

第二个坑：一张图想同时表达架构和时序。有人会把系统架构模块图直接加上调用箭头，箭头旁边再写“第1步、第2步”。架构图的空间布局本来服务于模块归属，硬塞时间顺序以后，连线会跨过多个模块，读者无法快速判断是结构关系还是调用顺序。正确做法是拆成一张架构图加一张时序图，两张图各回答一个问题。

第三个坑：不考虑读者是谁。给业务方看全量 ER 图，给开发看只有三个框的产品示意图，都属于选型错配。diagram-design的选型判断里最重要的一条是：读者要拿这张图做什么决策。如果读者只关心“某个功能在哪个系统里”，一张高层架构图就够；如果读者要排查接口依赖，那必须画到服务粒度。

2.3 从“草稿意图”到“正确图型”的快速判断流程

与其凭感觉选型，不如做一个简单归类。你可以把需求文档里的主语和动词分别列出来：名词多、结构多，比如“模块、服务、数据库、子系统”，优先考虑架构图；动词多、顺序多，比如“发送、处理、转发、回调”，优先考虑流程图；如果同时出现“先、后、同时”这种时间词，就要考虑时序图；如果反复出现“状态、变为、触发”这种词，则是状态图。

我自己的习惯是，拿到需求以后先在白板上画一个最丑的草图，不追求好看，只看内容属于哪种关系。草图里如果到处是分叉和回路，它大概率应该画成流程图；如果主要是父子容器和嵌套，它大概率是架构图；如果主要在排先后顺序，那就是时序图。这个判断动作画在正式成图之前，能省掉后面至少一半的返工。

3. diagram-design 的核心规范：形状、颜色、布局与文字

3.1 形状语义：每种图形只说一种意思

同一张图里，一种形状只能有一种语义。这是diagram-design的第一条铁律。矩形就是实体或模块，圆角矩形就是处理步骤，菱形就是判断分支，平行四边形是输入输出，圆柱是数据库，圆形节点是状态，带边框的方括号是备注或约束。

连线也有语义。实线箭头表示强依赖或同步调用，虚线箭头表示弱依赖、异步回调或事件通知，空心箭头通常表示继承或实现关系，如果不确定，就在图例里写清楚。很多混乱的架构图都栽在“所有线都画成实线”这件事上，读者分不清主链和旁路，图的信息量立刻减半。

3.2 颜色语义：少即是多，用颜色突出重点而不是装饰

颜色是图表里最容易被滥用的元素。很多人喜欢给每个模块配一个颜色，结果整张图像彩虹，读者以为不同颜色在传递某种额外信息，实际上没有。diagram-design对颜色的约束是：最多使用四种有彩色系加灰阶。

我常用的语义色是：主色用于核心模块或主链路，中性灰用于普通模块和辅助线，告警色用于高风险、异常或需要关注的点，扩展色用于变更范围、新增模块或异步依赖。举例来说，一张订单系统架构图里，订单服务是核心，用主色；数据库、缓存这些依赖用灰色；消息队列因为是异步解耦，用扩展色；如果有一个计划要改造的旧模块，用告警色标出来。

这里有一个容易被忽略的细节：不要试图用同一种颜色的深色和浅色区分“两层含义”。比如浅蓝和深蓝都算一个色系，读者自然会认为它们有关系，如果你本来只是想把两个不同层级的模块区分开，很容易被误读。正确的是用不同的边界框（父容器）做分组，颜色只保留语义作用。

3.3 布局与连线：让视线有秩序地移动

默认的阅读方向决定了图的骨架。对于流程图和状态图，我建议从上到下布局，因为人的视线天然往下走。对于系统架构图，可以选择从上到下分层，也可以选择从左到右按“用户侧、接入侧、业务侧、数据侧”排列，但同一个团队最好固定一种习惯，不要各画各的。

连线的质量往往决定一张图的专业程度。复杂图里，所有连线尽量横平竖直，避免斜线；如果出现跨层连线，尽量让它越过分组框的边缘而不是斜穿多个模块。更严格的方案是规定线从节点的同一侧进出，比如布局从左到右时，调用从右侧出、进入左侧，这样整张图的连线会形成一条清晰的视觉流。我自己在评审时也会用这条规则快速判断一张图是否规范——只要看到连线四处乱穿，就知道作者还没想清楚依赖关系。

布局的另一个重点是留白。节点间距至少要大于一个字符的宽度，画布四边留出空白，不要把图塞满边缘。分组用父容器实现，父容器本身可以有标题栏，不要靠一块块不同的底色分区，否则打印或投影时颜色一失真，分组关系就全乱了。

3.4 文字与字号：考虑“三米外能看清”的阅读场景

评审和宣讲场景里，图通常被投到幕布上，后排观众能看清的字体大小比你想象中要大。因此核心节点和核心连线的字号必须显著，普通节点可以略小一到两号，但不应小于页面能识别的最小可读字号。

节点内文字尽量控制在 12 个中文字以内，超过就拆句子或拆分节点。不要为了省图面把一段完整句子塞进一个框里，读者会因为阅读换行而漏掉关键信息。还有一个小技巧：当节点数量超过六七个时，给核心节点加上序号标签，比如“1-网关、2-订单服务、3-数据库”，并在图例或说明文字中强调阅读顺序。这个动作看起来简单，却能显著降低复杂图的认知负担。

4. 实操全流程：用 diagram-design 从零画一张系统架构图

4.1 第一步：收集信息，先列模块清单

很多人打开画图工具就直接开始拖框，这是最要命的一步。没有信息清单，你拖出来的每一个框都可能漏掉上下文。正确的做法是先列一张模块信息表，至少包含：模块名、职责、上游、下游、边界属性和异常点。

填这个表的过程本身就是需求梳理。很多团队画到一半发现依赖理不清，就是因为跳过了这个环节，直接在画布上凭印象连线。信息表填完，架构图的基本结构其实已经出来了。

4.2 第二步：先分层、再分区、后连线

系统架构图最常见的结构是三层：接入层、业务层、数据层。先在画布上画出三个横向边界框，把上一步整理的模块按层级放进对应的区域。注意不要把一个业务模块画到数据层里，更不能让数据库出现在业务层上方。

连线时先画主链路：客户端到网关，网关到订单服务，订单服务到数据库。这条线是读者首先应该看到的信息，可以用更粗的线宽或更深的颜色突出。然后再画支线：订单服务发消息给消息队列，消息队列再推给通知服务。异步支线用虚线，明确告诉读者它不是同步链路。

一个实用的自检是数每个节点的入边和出边。一个只有入边没有出边的节点，要么是整条链路的终点，要么是你还没画完它的下游；一个只有出边没有入边的节点，要么是起点，要么少了上游。技术图里最怕出现“孤儿节点”，它们往往是没理清的依赖关系的写照。

4.3 第三步：套用视觉规范并复核

模块矩形、数据库圆柱、消息队列用统一的队列图标，判断分支用菱形——这些形状要在一张图里贯彻到底。颜色方面，网关和订单服务这类核心模块用主色，数据库等基础设施用中性灰，消息队列用扩展色，如果某个模块处于改造或高风险状态，用告警色并配图例说明。

图面完成后，按下面的复核清单走一遍：每个模块是否有清晰的边界；连线是否横平竖直且方向统一；是否有图例解释形状、颜色、线型的含义；核心链路是否一眼可辨；节点内文字是否控制在合理长度；图的角落是否标注了版本号、更新时间和作者。这套清单基本就是一张高质量技术图的底线。

4.4 从白板到文档：团队协作与版本管理

在工作流上，我不建议直接在正式工具里从零画复杂图。更稳妥的顺序是：先在白板或纸上画出结构草图，大家快速对齐模块分层和主链路，确认没大的逻辑问题后，再把草图誊到正式绘图工具里做精细排版。

如果你的团队把图当作长期文档维护，可以考虑把图源文件保存成文本格式，并纳入工程仓库的文档目录。这样每次评审后修改，都像提交代码一样留下记录。只导出一张 PNG 截图贴在文档里是灾难性的做法，几个迭代之后，原图丢失，截图过期，最后没人敢信任那张图。我的原则是：图文件必须和它描绘的系统同步演进，不然它迟早会变成一张“历史文物”。

5. 踩过的坑：diagram-design 落地时的常见问题与排查技巧

5.1 问题：箭头满天飞，根本找不到主链路

画图时最常见的问题是铺完所有节点以后临时连线，连出来的箭头横七竖八，主链路被淹没在几十条细线里。这种情况通常不是因为逻辑复杂，而是没有先规划主链路再补充支线。

排查思路是先关掉所有辅助连线，只保留一条从入口到核心存储的链路，确认这条链路能不能用一句话描述出来。如果一句话说不出来，说明这张图的主流程是混乱的。接着启用网格对齐和吸附功能，把连线统一拉成水平或垂直方向。最后，用线宽或颜色把主链路加重，辅助线一律使用浅灰细线。这样处理后，读者第一眼看到的必然是核心路径，支线细节可以在需要时再逐条追踪。

5.2 问题：一张图塞二十个模块，评审时没人敢发言

评审会上如果出现沉默，往往不是因为大家没意见，而是因为信息太密，没人知道从哪开始看。高层架构图只适合展示模块和依赖方向，不适合展示每个模块内部的细节。

解决方案是拆图。一张高层架构图最多控制在十到十五个节点以内，高层的每个模块如果需要展开，就在附录或下一页放一张该模块的内部详细图。高层节点上可以加角标数字，对应后文的图编号，形成“总图+分图”的结构。另一个技巧是强制自己删掉非核心节点。画图时先问一句：如果删掉这个节点，读者是否还能理解系统如何工作？如果还能，就删。

5.3 问题：图和代码、需求不同步，过了两周就没人信了

做技术图最大的敌人是时间。系统一改版，图还在原地，几次之后团队就形成了一种默契：文档里的图都是过时的，别信。要打破这种默契，就要让图的管理方式向代码看齐。

我见过比较有效的做法是把图源文件放进工程仓库的 docs 目录，并在 README 里给出图的入口链接。需求变更评审时把图和代码变更一起过，更新代码的提交记录里同时带上图的修订记录。图上还要标注清晰的版本号、更新时间和负责人。这样虽然不能百分之百保证图永远最新，但至少让“更新图”成为有存在感的流程动作，而不是靠某个人自觉。

5.4 问题：团队各画各的，同一套系统配色五花八门

当团队超过几个人，又没有图例规范时，每个人都会按自己的偏好选色选形状。A 同学用红色画核心服务，B 同学用红色画告警模块，两张图放在一起看会互相打架。

解药只有一个：把图例规范做成团队可见的文档页，并约定评审时先看图例。一张图画得再漂亮，如果图例解释不清，在diagram-design里就不算合格。新人开始画图前，先给他一份团队往期的优质样图，他自己就能模仿出七八分。模板当然也可以用，但模板不应成为束缚。遇到现有规范表达不了的边缘情况，可以新增符号，但新增后必须同步更新团队图例页，否则过三个月又会冒出几种没人认识的形状。

5.5 快速自查表

这张表可以直接打印出来贴在工位旁边。每次画完一张图，花两分钟对照一遍，能避免绝大多数沟通灾难。

6. diagram-design 的影响范围：不同角色能得到什么

6.1 开发工程师：接手老系统时快速梳理依赖

对开发来说，diagram-design最直接的价值体现在接手陌生系统的时候。面对几万行代码，如果先通过接口入口一层层画出服务依赖图，就能快速看清系统的骨架。画图的过程会逼着你确认“这个模块到底依赖谁”“那个调用是同步还是异步”，这些信息比读实现代码更容易形成整体认知。

更实际的一点是，规范化之后的图可以直接成为代码评审的输入。涉及跨服务变更时，把改动点在图里标出来，评审人不需要一边看代码一边脑补系统连接关系，直接对着图就能指出影响面。这比写几十行文字说明更高效。

6.2 架构师：评审和方案对比的决策工具

架构师最常做的事是方案选型。两套设计方案画在同一套规范下，结构差异一目了然：谁多了一个依赖，谁的异步链路更简单，哪个模块有单点风险，图上直接用颜色和线条标出来。

把图当作评审记录保存下来，后续翻看时会非常清晰。有人问“为什么当初选了 A 方案而不是 B”，你直接翻出当时两张规范化对比图，结论就摆在图面上。这会显著提高架构决策的透明度，也减少了很多事后争论。

6.3 产品经理和技术写作者：把业务逻辑讲清楚

产品经理画业务流程图时，经常遇到一个尴尬：开发看流程图总是追问“这里异常分支呢”“超时怎么办”。如果按照diagram-design的形状和分支规则把主流程、备选流程、异常分支明确分色分线，业务逻辑的完整度会自然提升。

技术写作者受益更多。一份操作手册或故障排查文档里，如果所有架构图、流程图都遵循同一套图例，读者在翻不同章节时就不用反复重新理解符号。运维手册里的拓扑图尤其如此，统一规范后，值班同学的排查效率会有肉眼可见的提升。

6.4 长期影响：把制图从“个人审美”变成“团队工程能力”

diagram-design真正带来的长期影响，是让图表从一种依赖个人审美的自由发挥，变成一项可以被审查、被复用的团队工程能力。规范一旦存在，图就不再是“画得好看不好看”的问题，而是“对还是不对”的问题。

团队里一旦有一张被广泛认可的样板图，新成员会照着它画出风格接近的作品，评审会也不再需要从零解释规则。当图成为真正意义上被维护的工程资产，整个团队在沟通、交接、评审上的损耗都会往下走一个台阶。

我实际用下来最大的感受是：这套规范的意义不在于把图变漂亮，而是让图变得可以“判对错”。以前我们评审架构图，大家只会说“感觉有点乱”；现在可以直接指出“这个颜色不该出现在这里”“这条连线没有按规定走”“这个节点没有版本标注”。建议你先从团队里最常被翻出来看的那张图下手，按这套规范重新画一遍。不用急于全团队推广，只要有一张样板在，大家自然会照着一个样子画。