企业官网建设流程全解析

最近评审一个跨团队文档，我又被一张架构图折磨了一回：三十多个模块方框挤在一屏里，七八种颜色的箭头横七竖八互相穿插，边上的注释小到要贴脸才能看清。这张图成功让评审会一半时间花在争论“这条虚线到底什么意思”上，业务问题一个没聊完。也正是这次经历，逼我把脑子里那堆碎片化的画图经验梳理成一个能沉淀、能复用的规范项目——diagram-design。

简单说，diagram-design 不是什么新工具，也不是某种高深理论，它是一套关于图的设计规则：画图之前先想清楚什么，画的时候形状、颜色、连线怎么用，画完之后怎么审查。它解决的核心问题是：让一张技术图在十秒内被读者抓住主干，在一分钟内读懂细节。这篇拆解适用于所有需要画图的人——后端开发、架构师、产品经理、技术文档工程师，哪怕只是被老板要求给方案配一张示意图的市场同学，里面的规则也完全通用。

1. 为什么大多数技术图让人看不懂：图的本质与三大误区

1.1 图不是文档的附庸，而是一种独立的表达语言

文字和图的差别，不是载体不同，而是信息组织方式完全不同。文字是线性推进的，读者必须沿着句子从头读到尾；图是空间铺开的，读者可以一眼看到全貌，再按自己的节奏选择阅读路径。正因为这样，图能表达文字很难表达的东西：多个对象之间的并行关系、层级关系、流向关系，可以同时呈现在一个平面上。

但这也意味着，把写文档的习惯带进画图，几乎必然出问题。写文档时，我们会把背景、原因、细节都交代清楚，唯恐漏掉信息；画图时如果也这么干，把所有模块、所有关系、所有注释全部平铺上去，图就会变成一张信息密集到无法呼吸的“墙纸”。读者面对墙纸，第一反应是撤退，不是阅读。

diagram-design 的第一条原则，就是承认图是一种独立的表达语言，它有自己的一套语法。空间位置代表层级和归属，连线代表关系和流向，颜色和形状代表分类与强调。读者能看懂图，不是因为图里的字他认识，而是因为他读懂了这套空间语法。画图的人如果自己都不清楚每个视觉元素承担什么语义，读者就更不可能清楚。

1.2 误区一：信息堆砌，把图当清单

最常见的翻车现场，是把架构图画成组件清单。每一个服务、每一个中间件、每一条依赖，全部画上去，整整齐齐排成一面墙，像一张目录。这种图的问题在于：它只回答了“系统里有什么”，完全没有回答“系统是怎么运转的”。而读者真正想知道的是后者。

我在 diagram-design 里反复强调一个取舍标准：如果删掉某个元素，读者仍然能理解这张图的核心命题，那这个元素就应该删。堆砌的信息不会让图更专业，只会让图更难读。真正专业的图，是敢于留白的图，是知道自己“不画什么”的图。

1.3 误区二：装饰过度，把图当海报

另一个极端是装饰过度。渐变底色、圆角阴影、图标素材、花哨箭头，看起来很美，但装饰元素会抢占注意力，干扰语义。读者看图时，注意力是稀缺资源，每多一分花在“这个圆角是什么意思”上，就少一分花在理解系统结构上。

装饰不是完全不能用，而是必须有节制、有意义。diagram-design 里有一条“装饰即语义”的规则：任何视觉美化，如果不能用“这样画表达了什么信息”来解释，就撤回。圆角可以是“这组元素属于同一层”，阴影可以是“这个是重点强调对象”，渐变除非表达状态变化，否则不要出现。

1.4 误区三：逻辑缺失，把图当拼盘

还有一种情况，更隐蔽也更致命：图里的每个元素单独看都合理，连起来却讲不出一个完整逻辑。模块两边排，箭头绕来绕去，一会儿从上往下，一会儿从左往右，读者找不到阅读起点，也找不到结束点。这种图本质上是把好几个不同视角的信息拼在了一张图里，没有一条清晰的叙事线。

叙事线是图的主心骨。画图之前，必须知道自己想让读者沿着什么顺序走：是数据从源头流到终点的方向，还是调用从入口逐层深入的层级。没有叙事线的图，就像没有章节的书，每一页都写满了字，却不知道故事是什么。

2. 画图前必须完成的四件事：读者、命题、取舍与草图

很多人一上来就打开绘图软件开画，这是效率最高的翻车方式。diagram-design 把画图前的准备工作分成四步，每一步都不能省。

2.1 先回答“给谁看、在什么场景看”

同样一套系统，给开发看的架构图和给老板看的架构图，完全是两张图。开发关注模块职责、依赖关系、接口边界；老板关注价值链条、成本构成、风险点。读者决定了图的详略、视角和语言。给开发看的图可以写技术名词，给业务看的图就必须把术语翻译成业务语言。

场景同样重要。评审会上投屏看的图，字号要大、分支要少，因为大屏会放大字号问题；写进文档里被人反复查阅的图，可以更密、更全。diagram-design 把场景分为三类：投屏讲解、文档阅读、快速交流（比如聊天里甩一张图）。投屏图重主干，文档图重完整，交流图重速度。画图之前先给这张图贴个场景标签，很多取舍就自动有了答案。

2.2 用一句话写出核心命题

第二步是强迫自己用一句话写清楚这张图想说明什么。比如“这张图说明用户从登录到下单经过哪些系统”——这就是核心命题。写不出来的话，说明自己还没想清楚，先别画。

这句话的作用有两个。一是当取舍的判据：任何元素如果和这句话无关，就可以不画。二是当叙事线的锚点：叙事线的终点，就是这句话的落点。我在实际执行中经常发现，写命题这句话比画图本身还难，但也比画图本身更值钱。

2.3 内容取舍：删掉一半，保住百分之二十的主干

我见过太多“什么都想画”的人。diagram-design 给的执行建议很粗暴：先把所有想画的元素列出来，然后删掉一半；再圈出和核心命题直接相关的，通常只剩百分之二十到三十，这些才是主干，剩下的要么不画，要么放到附录页。

这个比例听起来极端，执行下来其实是对的。图的表达力不是来自信息量，而是来自结构清晰度。一张图能让人在十秒内抓住“谁依赖谁、数据从哪到哪”，远比一张图让人研究十分钟才搞明白所有细节更有价值。细节不是不重要，而是应该放在另一张图、另一页文档里，而不是挤在同一张图里互相干扰。

2.4 先用纸笔草图验证结构，再开软件

第四步是画草图。不要打开绘图软件直接画成品，而是用纸笔或者白板，先把结构框出来。草图阶段的目的不是美观，而是验证叙事线和布局逻辑：入口在哪，主路径怎么走，分支怎么放，哪里需要分组。

软件有个坏毛病：它会让一切看起来都很正式。一旦在软件里画得有模有样，人就容易舍不得改。草图因为是潦草的，改起来毫无心理负担，反而能逼着你在结构上多花时间。我的经验是，草图阶段每多花十分钟，成品阶段能少改一小时。

3. 符号体系与视觉语法：形状、颜色、连线的底层规则

图的视觉元素就四样：形状、颜色、连线、文字。diagram-design 对每一类都定了明确的语义规则，目的只有一个——让读者不需要猜。

3.1 形状：语义单一，不可混用

形状是要有“词义”的。最常见的约定是：矩形代表实体或模块，圆角矩形代表功能或操作，圆形代表开始结束，菱形代表判断，平行四边形代表数据。这套约定来自经典流程图规范，成熟稳定，读者接受度高。

关键不是用什么形状，而是同一张图里，一种形状只能有一种语义，而且全图保持一致。很多人翻车的点在于：为了美观，同一个含义的模块今天用矩形，明天用六边形，后天用圆角矩形。读者嘴上不说，心里已经开始怀疑这张图是不是随手画的。diagram-design 的建议是：每种图类型固定一套形状词表，写进团队规范，画图时不临场发挥。

3.2 颜色：只做三件事——分层、分组、强调

颜色是最容易被滥用的元素，没有之一。我见过一张图用十几种颜色，每个模块一个色，最后画面五彩斑斓，语义全无。颜色在技术图里只应该承担三种职能：

一条硬规则：同一张图里，颜色数量控制在四种以内（灰度除外）。而且颜色要尽量少依赖色相区分信息，因为色盲读者真实存在。如果两个元素的区别只能靠红和绿来区分，那这张图对一部分人来说就是无效的。

3.3 连线：方向、虚实、曲直都是信息

连线是图的骨骼。diagram-design 对连线做了五条基本规定：第一，有方向的线必须画箭头，永不省略，因为“谁指向谁”是核心语义；第二，同一种线型只表达一种关系，实线代表确定调用或数据流，虚线代表异步、间接或未来规划；第三，线的走向尽量统一，主方向要么从左到右，要么从上到下，不要一会儿横着走一会儿竖着走；第四，尽量少让线穿过其他元素，不得不穿的时候，用跳线标记；第五，线的标签只写动词性质的内容，比如“调用”“写入”“回调”，名词信息放在节点里。

很多图让人看不懂，问题就出在连线上：箭头方向模棱两可、实线虚线乱用、线从图中间横穿一片元素。读者要花大量精力去追踪线条的走向，自然没力气理解内容。记住一句话：连线是图里的动词，动词混乱，句子就一定混乱。

3.4 文字：标签的精简与摆放

节点里的文字是读者获取信息的最后一步，也是最容易被忽略的一步。diagram-design 对文字有三条要求：节点标签尽量短，四到六个字为佳，能缩写就缩写，全称放到图例或文档正文；标签必须放在节点内部或紧邻节点，不要放在线的中间，更不要离节点十万八千里；同一张图里的字体、字号、粗细体系要统一，层级关系用字号和字重表达，而不是用颜色。

文字和图形是互补关系。图形负责结构，文字负责精确。如果节点里塞满了一整句话，节点本身就会膨胀，布局就会被撑乱。反过来，如果节点里什么都不写，只留一个图标，读者又要去猜图标含义。好的标签是“短到不占空间，准到不用猜”。

4. 四类高频技术图的套路拆解：架构、流程、时序、数据

diagram-design 里专门整理了一张“图型速查表”，把日常最高频的图分成四类，每类都有固定的画法套路。套路不是限制，而是让读者降低阅读成本的前提。

4.1 系统架构图：先分层，再画边界

架构图最容易画成“组件全家福”，正确的画法是先分层。所有架构图都可以按“用户层—接入层—业务层—数据层”这样的层次从上往下排，同一层的组件放在同一水平区域，层与层之间用明显的边界分隔。分层的好处是：读者第一眼就知道系统的高度和宽度，知道哪些组件是同级的。

其次要画边界。边界可以是虚线框，代表网络区域、团队归属或信任边界。边界内放置属于该区域的组件，边界外放置外部依赖。边界是架构图里最能传递信息的元素之一，它直接回答了“哪些责任在系统内、哪些在系统外”这个架构师最关心的问题。

最后才是连线。架构图的连线要克制，连线的密度往往最能反映图的成熟度。如果一张架构图里线多到分不清，说明架构本身就是乱的，或者图没有经过取舍。此时应该停下来，回到第二节讲的删减原则。

4.2 业务流程图：用泳道分清责任人

业务流程图的核心是“谁在什么状态下做了什么”。最容易犯的错是把所有动作画在一条线上，完全不管执行者是谁。diagram-design 强烈建议使用泳道图：每个参与者一条泳道，横向排开，动作画在对应的泳道里，流程线在泳道间穿梭。

泳道一加，三个信息立刻清晰：每一步由谁负责，哪些步骤是并行的，交接点在哪里。交接点是业务流程中最容易出问题的地方，泳道图能让交接点一目了然。另外，业务流程图要标出判断节点的出口条件，避免出现“是/否”后面跟两条都通向同一个终点的箭头。

4.3 时序图与状态图：把时间或状态作为主轴

时序图的主轴是时间，对象按横排，消息按时间从上往下发。时序图最需要注意的是消息的顺序和返回路径：请求和返回都要画，但返回可以用虚线，代表调用栈的回溯。另一个高频错误是把不在同一个生命周期里的对象硬放进同一张时序图，导致图被拉得很长，阅读困难。解决方法是切分场景：一次用户操作一张时序图，场景之间用文字衔接。

状态图的主轴是状态，而不是时间。它回答的是“一个对象在哪些状态之间迁移”。画状态图时，先列全部状态，再画迁移条件，最后检查每个状态是否有合法的进入和离开路径。最容易漏的是初始状态和终止状态，这两个虽然不起眼，却是状态图完整性的基石。

4.4 数据流图与ER图：让关系说话

数据流图关注“数据从哪里来到哪里去”，它和架构图的区别是：数据流图不画处理细节，只画数据的运动。画数据流图时要坚持一个原则：每个加工节点必须有输入和输出，数据存储必须明确写入和读取的加工节点。数据流图最怕画成“网状”，所有节点互联。好的数据流图应该像河流，有明确的主干和支流。

ER图关注“实体之间是什么关系”，它的核心是关系基数：一对一、一对多、多对多。很多人画ER图只画矩形和连线，不标基数，这样的图价值减半。diagram-design 的建议是，连线上必须标注基数，而且基数的表示要采用读者熟悉的记法，不要自创符号。

5. 布局与排版实操：网格、对齐、留白、密度控制

到了布局排版阶段，很多已经确定内容的图仍然会翻车。diagram-design 把布局看作是“视觉秩序的工程化”：让读者的眼睛有规律可循。

5.1 从主干到枝叶的布局顺序

布局最忌从头到尾一个一个元素摆放，那样摆完一定乱。正确顺序是：先摆主干，再摆分支，最后摆细节。用架构图举例：先画数据层的几个存储节点，再画业务层的服务节点，让它们上下对齐；然后画接入层的网关；最后才考虑那些次要的旁路组件。

主干确定之后，布局就成功了一半。因为主干决定了整张图的骨架和视觉流向，剩下的元素往骨架附近贴即可。顺序反过来的话，前面摆放得很精致，等到发现主干需要挪位置时，整个图都要重来。

5.2 网格与对齐：看不见的秩序

人眼对对齐极其敏感。元素没有对齐时，读者会感到莫名的“乱”，但说不上来哪里乱。几乎所有绘图工具都提供对齐辅助线和网格吸附功能，diagram-design 的要求很简单：所有节点要么左对齐、要么居中对齐、要么按同一垂直轴线排列，禁止“差一点点对齐”。

另外，同一层级的节点要等距。相邻节点的间距保持一致，观众的视线就能顺畅地沿着这一层移动。间距混乱会直接破坏“同一层级”这个视觉信号。网格不是束缚，而是降低读者认知负担的工具。

5.3 留白与密度：一屏内的信息上限

留白不是浪费，而是语义的一部分。元素之间的间距就是呼吸空间，间距太小时，读者会把独立的元素看成一组，反而产生错误的分组信息。反过来，间距太大，图会被拉散，读者无法建立元素间的关联。

diagram-design 对密度有一个实用建议：一张图如果必须滚动超过两屏才能看完，就应该拆图。单屏图的密度上限，大约在二十到三十个节点之间，再多就一定需要分组或者分层表达。这个数字不是绝对的，但它是个很好的预警线：超过它，先想拆，而不是想怎么压缩字号。

5.4 字体、字号、导出与打印细节

字体的选择要保守。技术图不是设计海报，标题用无衬线字体，正文用同族字体的常规字重就够了。字号有两档：节点标签字号和全图最小字号。全图最小字号必须保证在投屏场景下最后一排能看清，一般不低于正文的百分之七十。

导出细节同样重要。矢量格式优先于位图，因为文档缩放后不会糊；位图导出要设置足够的分辨率，不要用默认的压缩画质。线宽要在导出前检查一遍，太细的线在打印或投屏后几乎看不见。颜色要留意打印场景下的灰度化效果，必要时在导出前用灰度模式预览一次。

6. 从初稿到交付：冷却审查、自查清单与协作沉淀

画完不等于画好。diagram-design 把交付前的审查当成正式工序，而不是可选的加分项。

6.1 三十分钟冷却法与三种审查视角

初稿完成后，先放三十分钟再回来看。冷却期不是浪费时间，而是让自己从“画图者的自我陶醉”里出来，切换成“读者的茫然视角”。刚画完时，你对图上每个元素都了如指掌，自然觉得图很清楚；冷却之后再看，才能发现那些缺少语境、缺少标注、逻辑跳跃的地方。

审查时切换三种视角：读者视角——我能不能十秒内说出这张图的主干；对手视角——如果我是被这张图评审的对方，我会挑什么毛病；新人视角——如果我对这个系统毫无背景知识，我能看懂吗。三种视角里，新人视角最容易暴露问题，也最容易被忽视。

6.2 一张自查清单，十分钟扫完

diagram-design 内置了一张自查清单，交付前逐条过一遍：

这张清单看起来很基础，但我在实际项目里发现，绝大多数据说“很难懂”的图，至少要挂掉清单里三条以上。多数问题不是高深的设计缺陷，而是基础的纪律缺失。

6.3 工具选型与协作方式：别让工具绑架图

工具的选择应该服从图的类型和协作需求。架构图和流程图用支持图层的矢量类绘图工具更合适，因为图层能帮你把背景网格、边界框、节点、连线分开管理；在线协作白板适合头脑风暴阶段的草图，但不适合输出正式交付文档；代码生成的图适合需要频繁变更的场景，改代码重新生成即可，但排版容易不受控。

真正影响协作效率的不是工具本身，而是约定。diagram-design 建议每个团队至少定三条约定：文件命名带版本号；源文件必须和导出的图片放在同一目录；任何改动先在草图或注释里说明意图再动手。没有这三条，多人协作时图的变更历史很快就会变成一团乱麻。

6.4 把图纳入版本管理与沉淀复审

图的版本管理是很多团队忽略的事。图片文件默认情况下很难对比差异，所以源文件比导出图更重要。diagram-design 的做法是：源文件进版本库，导出图按用途单独维护；每次结构性的修改，在变更说明里写明改了什么、为什么改。

沉淀复审的意思是：每隔一段时间，把团队最近的图翻出来，对照自查清单重新审一遍，把反复出现的坏习惯记下来，补充进规范。diagram-design 本身就是这样长出来的——每踩一个坑，就多一条规则。对于个人来说，同样的逻辑适用：把你的图当作自己的产品，定期复盘，而不是画完就丢。

最后说一点个人的体会。diagram-design 做到现在，我最大的收获不是图变得好看了，而是画图前被迫把“我到底要表达什么”这个问题回答得更清楚了。很多次我发现自己画不下去，不是技术问题，而是就没想清楚那件事本身。所以如果你现在画的图总被人说看不懂，先别急着学更多画图技巧，回头把本文第二节那四步补上，多半问题就解决了。

如果让我再补一条小技巧，那就是：每次画完一张图，把它缩小到手机屏幕大小再扫一眼。如果缩小的图里还能看清主干流向，这张图就是合格的；如果缩小后成了一团色块，说明密度和层级还有大问题。这个方法用了很多年，简单粗暴，但非常有效。