企业官网建设流程全解析

"diagram-design" 这个名字，乍听起来像是给设计师准备的画册项目。但在实际团队协作里，凡是接手过跨系统架构梳理、业务流程梳理、技术方案评审的人，都会对它有一种复杂的感情：图一旦画不好，大家宁可直接去看代码或者文档。

我最初接触这一类事情，是在一次技术方案评审会上。某同事把系统交互图投到屏幕上，满屏都是不同颜色的框和线，光图例就占了半边，台下的人花了十分钟也没搞清哪个模块是入口。那次会议之后，我开始认真思考一个问题：图示设计到底在设计什么？后来我慢慢意识到，真正值得做一套 diagram-design 规范的项目，目标不是把图变漂亮，而是把关系理清楚，再让关系以最低的认知成本被看见。这篇文章想分享的，就是我从草稿到成稿、从单图到规范的完整经验，适合需要在文档、评审、汇报里画架构图、流程图、状态图的产品经理、开发者和技术文档工程师。

1. 从问题出发：为什么图表设计值得单独做一个项目

1.1 没有设计的图表通常长什么样

我见过太多“没有设计”的图，它们的特点是：信息很全，但完全没法看。节点之间的连线密密麻麻，颜色随心情分配，同一个概念在这张图里叫“服务”，在另一张图里叫“模块”，图例写在画布右下角，字体小到要放大三倍才能认出来。这种图往往在画的时候花掉不少精力，但交付之后的利用率非常低，读者宁愿去读文字也不愿意看它。

更麻烦的是，这种图会误导判断。我在梳理某个跨平台系统的调用关系时，曾经被一张拓扑图困住：图上有十几台服务器节点，所有设备都用同一种形状表示，只有线的粗细不一样。结果评审会上，一半人以为虚线表示“已经下线”，另一半人以为虚线表示“可选的备用链路”，双方争论了很久，最后才发现画图的人只是随手选了一种线型，没有任何语义。这样的图不仅没有降低沟通成本，反而制造了新的分歧。

所以我说，没有设计的图不是“丑”的问题，而是“不可读”的问题。一张图如果不能让人在十秒内判断出主入口、主方向、主结果，那它就不适合出现在正式文档里。diagram-design 要做的第一件事，就是把这种不可读的状态改成可读，再把可读的状态变成一致。

1.2 图表设计要解决的三类痛点

我把实际项目中反复出现的问题归纳成三类，这三类几乎覆盖了百分之九十的“画图灾难”。

第一类是信息过载。画图的人总想把所有背景、所有接口、所有备选分支都塞进一张图里，认为这样才完整。但人眼的注意力是有限的，一张普通电脑屏幕上同时出现超过七个需要记忆的信息块，读者就开始丢失上下文。信息过载的直接后果是“图越看越乱”，最后没人愿意为它负责。

第二类是结构混乱。结构混乱表现为没有主线，节点的排布完全按画图时的临时思路来，左边放一个入口，右边突然出现一个返回箭头，底部又冒出一个异常分支。读者顺着连线走，经常走到一半发现前面是一条死路，又得折回来。结构混乱的本质是画图前没有先想清楚关系类型，把流程、层级、依赖三种关系混在了同一个画布上。

第三类是表达不一致。同样的框，在这张图里表示一个服务，在另一张图里表示一个数据库；同样的箭头，在这张图里表示数据流向，在另一张图里表示函数调用。表达不一致对团队协作是致命的，因为每次看图都需要读者猜测作者的真实意图。这个问题的根源不是画图技术，而是缺少一套统一的视觉语义表。

1.3 确定适用范围和产出物

做 diagram-design 项目之前，我先和团队确认了范围：不是只画一张图，而是建立一套画图的规矩。我们覆盖的图型包括系统架构图、业务流程图、时序图、状态图、网络拓扑图这五类，因为日常文档和评审用到的基本就是这些。

确认范围后，我规划了四类产出物。第一是样式规范，定义线宽、箭头、间距、色板、字阶，确保任何人画出来都像同一套体系。第二是模板库，把常用的布局骨架做成可复用模板，比如横向分层架构模板、纵向泳道流程模板，避免每次从零开始。第三是检查清单，用来在画完后逐项自检，比如“每个连线是否都有方向”“同类节点是否同色”“是否包含图例”。第四是示例图，用真实业务场景画出高质量的样板，让人知道“标准答案”长什么样。

这套产出物的核心思路是“把规范落到模板里，把合理性落到检查清单里”。单纯的文字规范几乎不会有人看，但是模板和清单可以直接嵌入日常工作流，效果要好得多。

2. 核心设计思路拆解：结构先行，视觉跟上

2.1 读图逻辑：从主线到分支

我第一次认真研究“读图逻辑”，是在一次用户访谈里。当时请几位同事看图找主流程，他们无一例外地先把视线落在画布左上角，然后顺着最大的那条连线往右下走，遇到颜色更重的节点会停下来多看一会儿。这个现象说明，人看图是有天然顺序的：大形状先于小形状，强色彩先于弱色彩，连续线先于断线。

所以，设计图表的第一步不是选颜色，而是决定“主线”。主线可以是从上到下的业务流，也可以是从左到右的调用链，或者从外到内的层级关系。确定主线后，所有其他元素都要围绕它展开，分支不要比主线更显眼，背景不要比前景更抢眼。就像城市地铁图，主线是最粗的几条线路，换乘站被重点标注，周边小站只保留必要信息，这样乘客才能快速规划路线。

在实际操作里，我通常先用一句话描述这张图的核心：“这张图说明了订单从创建到支付完成的路径”。然后根据这句话，把所有节点沿着一条主路径摆好。如果一句话说不清楚，那说明这张图的范围太大了，应该拆成两张图，而不是把所有内容压在一起。

2.2 元素分层：容器、节点、连线、标注

图表设计可以被拆成四个基础层：容器层、节点层、连线层、标注层。每一层承担一种职责，不能混着用。

容器层用来表达边界，比如系统边界、业务域边界、环境边界。我在画跨平台系统架构时，会用一个大圆角矩形代表“订单中心”，里面再放订单服务、库存服务、支付服务等节点。容器最重要的作用是让读者一眼看到“哪些东西属于同一个归属”，所以容器的命名要清晰，边框要足够淡，不能和节点抢注意力。

节点层是图中真正的主角，它可以是服务、模块、角色、状态、步骤。节点设计的关键是形状语义固定：矩形代表系统组件，圆角矩形代表功能模块，圆形代表外部角色，椭圆代表状态。一旦固定下来，就不要在同一张图里随意更换。

连线层表达关系，包括依赖、调用、流转、数据流向等。连线要比节点更细，箭头方向必须清晰，同方向的多条线要尽量保持平行。标注层则是补充说明，包括文字标签、图例、注释、版本号。标注要克制，能不上就不上，需要上时统一放在固定位置。

四层分离的好处是便于后期维护。当我需要调整一个节点位置时，不用担心连线会乱跑；当我需要给一组节点增加说明时，只要在标注层添加，不用重画整个布局。这也是为什么我建议先用一个支持分层的工具来画图，而不是直接在图片上加字。

2.3 排版与对齐的底层规则

图表排版最容易被忽视，却也最影响体验。我总结出三条底层规则，可以应对绝大多数图表场景。

第一条是网格对齐。所有节点和间距都锚定在 4 的倍数上，大间距用 16、24、32，小间距用 4、8。网格对齐的好处是让图看起来整齐，也方便后期调整尺寸。很多绘图工具都自带网格吸附，一定要开起来，不要靠肉眼去猜位置。

第二条是小组长不超过七个。视觉上，一个节点如果宽高差异过大，会破坏整体节奏。我通常的做法是，先计算节点内最长文本所需的宽度，然后把它作为这一类节点的统一宽度，再根据文本行数固定高度。同类节点宽高一致，图会立刻显得专业。

第三条是保持方向一致性。连线统一走水平或垂直方向，尽量不用斜线；箭头方向统一向左到右、上到下。方向一致性配合网格，可以让复杂拓扑图变得清爽。我见过很多图，节点连得密密麻麻，就是因为有人随手拉斜线，破坏了视觉秩序。修改时先调整网格，再处理斜线，问题就解决了一大半。

2.4 配色策略：用颜色表达含义，而不是装饰

很多新手画图会把每个节点刷成不同的颜色，觉得五彩缤纷等于好看。但图表不是海报，颜色是信息编码的一部分。diagram-design 里我始终坚持一个原则：颜色只用来表达语义，不用来装饰。

我把颜色分成三类用途。第一类标识分组，比如一个业务域内的节点全部用同一种浅色打底，另一个域用另一种浅色，这样读者不看容器也能快速区分归属。第二类标识状态，比如正常节点用中性色，异常节点用警示色，待处理节点用强调色，状态含义必须配合图例。第三类标识重要度，主线上的核心节点用高饱和度颜色，辅助节点用低饱和度颜色。

同时要注意，颜色不能作为唯一的信息通道。色盲用户很难区分红绿，所以我要求同一种语义至少通过两种通道表达：比如“异常”不仅用红色，还要用虚线边框；“核心”不仅用高饱和色，还要用更粗的形状。这样即使颜色显示不正确，读者依然能从形状和线型上获得信息。

我常对团队说一句话：如果一张图里去掉了颜色之后，读者依然能理解所有关系，那说明配色是成功的；如果去掉颜色就分不清节点归属，那说明颜色被当成了拐杖。

3. 实操过程：从草稿到标准产出，手把手做一遍

3.1 收集信息，圈定对象与关系

我每次接到画图需求，会先做一次“信息预整理”，而不是直接打开工具。这个步骤通常强迫自己在一张白纸上把词汇写出来：有哪些实体、哪些过程、哪些外部依赖。写不出来就去看文档、看代码、问同事，直到能列出一张清单。

然后我会画一张最粗糙的关系草稿，不是正式的图，有点像头脑风暴涂鸦。先不关心对齐和颜色，只关心“什么东西和什么东西有关”。这个阶段的目标是把隐藏的关系找出来，尤其是那些容易被遗忘的异常分支、回退路径、超时处理。很多图之所以后来反复改，就是因为一开始没把这些关系纳入视野。

最后我会标记每个对象的优先级。主流程上的对象标为高优先级，次要支撑对象标为中优先级，纯背景信息标为低优先级。低优先级对象在正式图里可以选择性省略，这样信息量就会得到控制。

3.2 确定图表类型：架构图、流程图、时序图还是状态图

信息清单有了之后，下一步是选对图型。这个选择直接影响阅读效率，选错了图型，再好看的样式也白搭。

判断方法很简单：如果核心问题是“系统里有哪些模块，模块属于谁”，就画架构图；如果核心问题是“一件事按什么顺序做，有哪些分支”，就画流程图；如果核心问题是“多个对象之间按时间先后发送了什么消息”，就画时序图；如果核心问题是“一个对象在什么条件下切换成什么状态”，就画状态图。

我在一次订单流程梳理中，一开始直接画了流程图，结果越画越长，把支付回调、库存锁定、超时取消全塞进去，整张图变得无法阅读。后来我把范围缩小成“订单状态流向”，改画状态图，把支付、锁定、取消、完成作为状态转移，问题立刻清楚了很多。所以选图型时要先问自己“我想让读者关注什么”，而不是“我手头有什么模板”。

3.3 用网格和间距搭建骨架

确定图型后，就可以开始正式画图。我习惯把画布分成三个区域：顶部放标题和版本信息，左侧或右侧留出图例区，中间大部分区域放主图。主图内部的布局从一个大网格开始，先拉出几条等距辅助线，再把主要模块放到对应位置上。

搭建骨架时，我优先确定主线节点的位置。比如架构图，我会先放最上层的入口网关，再放中间的业务逻辑层，最后放底部的数据存储层。每条泳道之间留出至少一倍节点高度的空白，避免文字挤压。这个阶段不用太精细，先摆出大的块状结构，确保整体平衡。

然后我会给每个节点分配合理尺寸。方法前面说过，先以最长文本为基准设宽度，统一同类节点的高度。间距建议保持偶数，节点间隔 16 或 24，分组间隔 32 或 48。这样后期无论是在屏幕上阅读还是打印出来，视觉节奏都不会太挤。

3.4 连线与拐角处理

连线是图表设计里最容易被低估的部分。我见过很多图，节点摆得很整齐，连线却像一团乱麻，原因是没有对连线做规划。

我的做法是，先定主线路径，再连分支线。主线上的连线一定是最粗、最直的那条，可以用稍粗的实线；分支线用同样颜色但更细的线，保持直角拐弯，不要画弧线。同方向的多条分支线尽量平行，彼此间距至少 6 个像素，避免糊在一起。

如果遇到两条线必须交叉，优先调整节点的位置来避免交叉，而不是直接在交叉处加一个跳线符号。实在避不开时，可以加一个“绕行”拐点，让其中一条线沿着网格走外围。还有一个技巧：把不同类型的连线拆分到不同的区域，比如业务流走上方，数据流走下方，这样即使节点很多，也不会产生大规模交叉。

3.5 文字与标注规范

图表里的文字属于标注层，但它的重要性不亚于任何图形元素。我把文字分成五级：图表标题、模块标题、节点名称、关系标签、注释文本。每一级都有固定的字号和字重，不允许随手使用其他字号。

节点名称要遵守“短语优先”原则，能写“订单服务”就绝不写“负责处理订单创建、更新、删除等操作的服务”。关系标签放在连线的中段，旁边用空白让出位置，避免压线。注释文本如果不是关键信息，就放到图例区或页脚，不要漂浮在画布中央。

图例要不要画，我的经验是：面向不熟悉该系统的外部读者时，必须有图例；面向团队内部且图型很常见时，可以省略；但一旦图中出现了超过三种连线类型或超过四种节点类型，图例就必须补齐。图例本身也是设计的一部分，要和主图使用同样的颜色和形状，而不是随便画几个方块。

3.6 导出与交付格式

图画完之后，交付方式会直接影响它是否被使用。我吃过亏，把图导成一张低分辨率位图发给团队，结果分享会上投到大屏上一片模糊，很多标签都看不清楚。从那以后，我总结出三条交付原则。

第一，必须有可编辑源文件。因为图很难一次画对，评审之后一定会改。如果有人只能在图片上加备注，等于把维护成本转移给了所有人。第二，导出时要区分场景：放在文档里用高清位图，放在网页上用 SVG 或 PDF，只有临时聊天才发普通图片。第三，封面或者页脚要写清楚版本号和更新时间，避免多人手上拿着不同版本的图开会。

关于字体，交付时务必注意字库差异。在本地显示正常的字体，换一台机器可能变成乱码或者替换成系统默认字体，导致布局错位。稳妥的做法是导出为矢量格式时勾选嵌入字体，或者把字体转成路径，绝不要指望所有观众电脑里都有同一套字体。

4. 工具选型与方案对比

4.1 手绘草稿、通用绘图工具与代码化绘图

很多人在工具选型上纠结很久，其实核心只有三条路：手绘草稿、通用绘图工具、代码化绘图。每条路都有自己的适用场景。

手绘草稿是最快的，适合前期梳理思路。一张纸、一支笔，十分钟就能把核心关系理清楚，不用考虑对齐、颜色和模板。但它不适合协作和交付，因为手绘稿很难编辑，而且每个人的笔迹和理解都不一样。

通用绘图工具是大多数团队的主流选择。它上手快，拖拽节点、连线、添加文字都非常直观，支持多人协作和评论。缺点是在图变得很大时，维护成本会上升，比如你改了 A 节点位置，B 节点的连线可能不会自动跟着优化，需要手动调整。

代码化绘图则是用文本来描述图表结构，再通过工具渲染成图。它的最大优点是与代码一起版本管理，变更记录一目了然；缺点是有一定的学习成本，且复杂的美化操作不如图形界面方便。我见过不少团队用代码画系统架构图，核心原因是他们的图需要随代码仓库持续演进，用代码维护最省力。

4.2 选型考虑的四个维度

不管选哪种工具，我都建议从四个维度做判断：上手成本、协作效率、可维护性、适用场景。

上手成本决定团队愿不愿意用。如果工具需要大量学习时间，很多人会绕开它，直接在文档里画 ASCII 示意图，最终整个团队产出的图风格五花八门。协作效率看的是实时评论、多人编辑、审阅流程是否顺畅，尤其是跨部门协作，一条评论能附在一个节点上，比在聊天里发一大段文字高效得多。

可维护性是最容易忽略的。很多图画完之后三个月没动，再改时发现当初没有源文件，只能重新画。所以在选工具时，我至少会确认它能不能导出标准格式、能不能被版本管理工具跟踪、能不能在不同环境中打开同一个文件。适用场景则取决于团队主要画什么图：如果以流程图为多，通用工具足够；如果要以图驱动文档，代码化方案更合适。

4.3 我的建议组合

我不主张把鸡蛋放在一个篮子里，反而建议按工作阶段用不同的工具组合。

前期梳理信息阶段，我用手绘或在线白板，重点是快。中期正式画图阶段，我用通用绘图工具，因为要对齐网格、统一样式、添加图例，这比在白板上涂鸦更可控。后期需要长期维护的阶段，如果图是写在技术文档里的架构图，我会考虑把图定义转化成代码化方案，这样每次提交代码时，图也会跟着版本一起更新。

工具组合的另一个好处是减少“工具锁定”风险。即使某一天某个工具不再维护，我们已经导出了标准格式的源文件，迁移成本也不会太高。记住，diagram-design 的核心不是依赖某个工具，而是拥有一套可以迁移的设计方法和一套稳定的视觉语义。

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

5.1 图越改越乱，如何止损

这是我在项目里遇到最多的问题。一张图从初稿到终版，往往要经历邮件反馈、会议讨论、临时调整，改到后面，连画图的人自己都说不清楚为什么这里多了一个框。

我的止损方法很直接：回到白纸，重新画主线。不要试图在乱图上做增量修补，因为每补一次，视觉复杂度就会上升一档。可以把当前图打印出来，用荧光笔标出真正重要的节点，然后扔掉其他信息，重新布局。我发现，每次重新画主线，通常只会保留原来三分之一的节点，但这三分之一的节点讲清楚了核心问题。

5.2 连线交叉怎么处理

连线交叉的根源往往是布局顺序不合理，而不是“线太多”。我处理时会先看主线方向，如果主线是从左到右，那就尽量让所有分支也从左到右，避免出现从右向左的回头路线。实在需要有回头路线时，可以把它放在画布底部单独一条通道上。

另一个技巧是给每类连线分配专属区域。比如调用关系走节点之间的空白区域，数据流走画布最外围，消息事件走时间轴选项卡。分开布线后，交叉点会显著减少。如果节点太多无法避免交叉，那就简化关系，在图上只保留最重要的关系，把次要关系写进旁边的文字说明。

5.3 不同屏幕尺寸下看不清楚

这张图在共享屏幕上投出来没问题，换到手机上就变成蚂蚁图，这是一个很现实的痛点。原因通常出在画布尺寸和字号设置上。

建议从一开始就把画布尺寸定成 16:9 横向布局，不要用默认的竖向画布。字号最小不要低于 10 磅，节点名称建议 12 磅以上，关系标签可以稍小，但不能低于 8 磅。导出时按 2 倍以上分辨率导出位图，保证在大屏或缩放时依然清晰。还有一种做法是提供文字版摘要，把图里最关键的信息用一两段话说明，这样即使图看不清，读者也能抓住核心。

5.4 团队不按规范画图怎么办

规范写了，模板做了，但还是有人自成一派。这种问题靠“强调”解决不了，只能靠机制。

我的做法是，把检查清单嵌进评审流程。任何图在评审前都要先过一遍清单，不符合规范的先返回修改，再进入评审。同时我会提供一批可以直接复制改写的模板，让人不需要从头学习规范，只需要替换文字和节点。这两件事叠加之后，团队出图的风格会迅速收敛。

还有一个细节：不要惩罚不合规，而是奖励合规。我每次看到有人用了新模板或者主动补了图例，都会在周会上点名表扬。慢慢地，大家会感觉到遵循规范是一种省力而不是负担。

5.5 图表问题排查速查表

为了方便查看，我把上面的经验整理成一个简表，遇到问题可以对照定位。

这张表不是万能的，但它能帮你快速定位多数问题。排查完之后，如果图依然不清晰，我建议停下来问一句：这张图到底想表达什么？如果答不上来，问题就不在绘图技巧，而在需求本身。

6. 后续还可以怎么扩展

6.1 从静态图表到动态演示

静态图表适合阅读，但在技术评审和汇报场景里，动态演示往往更能引导注意力。同一个架构图，让读者自己扫描所有节点，效果远不如按顺序逐步展开核心模块。

我的做法是，把一张已经完成的架构图拆成几个步骤：第一步展示整体边界，第二步展示核心模块，第三步展示主要调用链，第四步展示异常分支。演示时按这个顺序逐层出现，配合讲解节奏，读者会更容易跟上。很多绘图工具已经支持逐层显示，或者可以导出成多帧图片，在演示软件里做成动画。

6.2 图表即代码的团队实践

我对“图表随代码一起版本化”这个方向越来越看重。当架构调整时，代码变了，图也应该自动变化，而不是靠某个人记得去更新文档。

实现方式是把图表描述文本化，纳入仓库管理。每次变更都走提交评审，图中每一个节点、每一条连线都有迹可循。对于需要频繁演进的系统，这种做法的维护成本远低于手工画图。

推行“图表即代码”时，不必一上来就全量推广。可以先选一个稳定子系统作为试点，把它的架构图从图形工具迁移到代码化描述，观察两个迭代的效果。团队习惯了提交与图同步的节奏后，再逐步扩展到更多模块。

6.3 定期复盘图表的真实使用情况

图不是画完就结束了。我每隔一段时间会抽查几份文档里的图，问自己三个问题：读者真的会看吗？看完之后能复述出核心关系吗？这张图和当前系统状态一致吗？如果答案是否定的，那说明这张图已经失去价值，应该及时更新或者移除。

有一次我复盘旧文档，发现一张半年前的调用链图还在被新人当作入门资料，但它涉及的两个服务已经下线了。新人按照旧图去排查问题，白忙了一下午。那之后，我把“图表有效性检查”加入文档更新流程，每次需求变更都要顺手确认相关图是否仍然准确。

我个人在实际项目中收获最大的一个习惯，是永远把 diagram-design 当成一套流程而不是一张图。信息收集、图型选择、骨架搭建、连线规划、标注规范、评审复检，每一步都有明确的产出物。走得越完整，出来的图越经得起时间考验。即使你只是临时画一张流程图，只要把主线想清楚、把同类节点统一样式、把必要的图例放好，它也会比大多数随意涂鸦更容易被团队接受。