企业官网建设流程全解析

不用画得像艺术品，但要画得让人一眼看懂。做技术这些年，我见过太多团队栽在“图”上：方案评审时白板上画得热火朝天，散会后就成了一堆没人能看懂的线条；系统文档里贴的架构图，连原作者过俩月都得重新猜线是什么意思。diagram-design这件事，说到底不是画图技巧问题，而是思维方法问题。这篇东西写给所有需要画架构图、流程图、时序图、思维导图的人——不管是程序员、产品经理还是运维同学，只要你想把脑子里的复杂东西表达清楚，这篇就适合你。

1. 核心思路：图的本质是传递信息，不是堆素材

1.1 先搞清楚图和漂亮图之间的区别

很多人画图有个误区，一上来就调色、加阴影、找图标，忙活半天做出来一个花花绿绿的漂亮东西。但读者看了之后，脑子里什么都留不下。图的本质是信息传达，不是视觉展示。一张好的架构图，哪怕是用框线和文字拼出来的，只要逻辑清晰，就比那些花里胡哨但逻辑混乱的图有价值得多。

我在评审方案时看过不少图，有的图排版精细、配色考究，但信息层级是乱的，主流程看不出来，边界模糊，最后大家讨论半天还在问“这个模块到底是前端还是后端”。反过来，有人用纯文本框和箭头画出的部署关系图，一眼就能看懂数据从哪里进来、经过哪些处理、最终落在哪里。

所以diagram-design的核心第一步不是打开工具，而是想清楚这张图要让读者"得到什么"。信息传达效率是唯一指标。美观只是手段，可读才是目的。

1.2 按读者和用途决定信息密度

同一套系统，画给不同的人看，图的画法完全不同。画给决策层看，突出模块划分、资源投入、风险点，不需要细节；画给研发同事看，要画清楚接口关系、数据流向、部署边界，细节越多越好；画给新人做入门文档，则要一步步来，循序渐进，不能一张图把所有信息全塞进去。

很多图上画了一堆东西，是因为作者没有明确"这张图给谁用"。

我自己常用的判断方法：先给自己提三个问题，这张图的主视角是谁，这个视角最关心什么，哪些信息对他来说是噪音。

回答完这三个问题，信息清单就出来了，主次也分清了。这个步骤一定要在动手画图之前完成，我不止一次省掉这个步骤直接开画，结果画到一半发现方向不对，推翻重来。

1.3 一张图只讲一件事

这个原则听起来简单，执行起来最容易破功。画微服务部署图的时候，画着画着就想把调用链也塞进去，再把数据表关系也塞进去，图最后变成一团乱麻。

正确的做法是：如果要表达部署拓扑、服务调用和数据模型，就拆成三张图，分别画。每张图讲清楚一件事，加起来就是一套清晰完整的文档。这比一张大而全的图效果要好得多。

一张图只讲一件事，不是说一张图只能有一个模块，而是说一张图只能有一个核心问题的答案，读者看完这张图能回答的问题是单一的，比如"服务怎么部署"或者"请求怎么流转"。

2. 工具选型：没有最好的工具，只有最顺手的工具

2.1 轻量在线工具：适合快速协作和临时沟通

这类工具的特点是打开浏览器就能用，支持多人实时编辑，通过链接分享，不需要安装客户端。我用它最多的场景是方案讨论初期：会上拉一个画布，把大家说的模块和关系随手摆上去，随时调整，参与的人都能即时看到。

优点是上手快、协作方便、图形控件丰富；缺点是画布太大时容易乱，而且图存在别人的服务器上，敏感系统的架构图不建议往这类工具里放。对于日常沟通和初步方案梳理，它非常高效。

2.2 专业桌面软件：适合复杂系统的正式设计

如果需要画的是大型系统架构、网络拓扑、机房部署这类复杂度高、需要反复修改打磨并且最终要沉淀到文档中的图，建议用专业桌面绘图软件。这类软件通常有完整的符号库、网格对齐、图层管理、批量对齐和自动路由连线功能。

我画复杂架构图时的一个体会是：网格和对齐功能是关键。手绘感的图在草稿阶段没问题，但它经不起细看，连线歪歪扭扭、框不对齐，读者潜意识里会觉得这东西不严谨。用专业工具可以做到每条线和每个框都对齐到网格，整个图看起来干净、专业，信任感完全不同。

桌面工具体积大、学习曲线陡，适合重度使用场景。如果一个月画不了几次图，不一定非得用它。

2.3 代码驱动绘图：适合版本管理和团队标准化

还用一种很特别的工具类别：通过写代码、写脚本，用文本描述来生成图表。图的定义是一段文本，可以存进代码仓库，做版本管理、做代码审查、做自动生成。改动一行文本，图就变了，diff干净清晰，不会出现"图片更新了但文档没同步"的尴尬。

这种方式特别适合需要频繁维护的图，比如微服务架构图。架构在演进，图也得跟着变，如果把图存在git里，每次改动都有记录，谁改了什么一目了然，比在文件管理器里放一堆"架构图_v2_最终版.png"要靠谱太多。

缺点是复杂布局需要手动调整，有些自动布局出来的连线不够理想。对技术团队来说，这种可维护性带来的收益远超布局调整的成本。

2.4 不同场景下的选型参考

我的建议是：不要迷信工具，每个工具都有适用边界。换工具的时间成本往往比你想象的高，真正舒服的状态是用熟一两款工具，形成肌肉记忆，把注意力集中在内容逻辑而不是操作上。

3. 实操过程：一套可以复用的图表设计流程

3.1 第一步：先列信息清单，不要急着开画

拿到一个画图任务，比如"画出这个系统的部署架构"，我先做的是把脑中所有相关信息倒出来，一一列出：

• 有哪些服务模块
• 每个模块部署在哪台机器上
• 机器之间是否有网络隔离
• 对外暴露哪些接口
• 依赖哪些外部服务
• 数据存储在哪个地方
• 鉴权是怎么做的

这一步是纯文本的，不涉及任何图形表达。列完清单之后，再去给这些元素分层次：

• 顶层：用户入口、接入层
• 中间层：业务服务、公共服务
• 底层：存储、中间件

层次分出来之后，图形结构就基本定形了。"先列信息再谈图形"这个习惯是我试错多次后总结的。以前我也跳过这一步直接开画，结果画到一半发现某个模块没考虑进去，又要给图打补丁，最终布局乱得没法看。先列清单看起来慢，实际上是快。信息不完整才是画图过程中最耗时间的坑。

3.2 第二步：确定核心链路和视觉流向

信息清单有了，层次有了，接下来要解决"读者视线怎么走"的问题。

人眼的阅读习惯是固定的：从左到右，从上到下。画图时,主流程就应该顺着这个方向展开。

如果是业务流程图：主流程取自上而下，分支判断可以左右展开。如果是架构图：底层设施放底部，上层应用放顶部，或者是"入口在左、依赖在右"的横向流向。如果是时序图：参与对象按时间顺序排成几列，消息箭头在列之间横向流动。

我画过一张订单处理流程图，一开始把主流程从左到右画，结果异常处理分支把主流程的下一环节挡住了，只能绕线，图特别扭。后来把主流程改成从上到下，异常分支往右侧展开，整个图就顺了很多。视觉流向的确定不是玄学，它决定了读者理解这张图的成本和顺畅度。

3.3 第三步：统一形状语义和连线规则

图形语言的一致性也很重要。同一个形状在同一张图里只能代表一种含义。我自己常用的语义体系是这样的：

• 圆角矩形：开始/结束
• 矩形：处理步骤、模块、组件
• 菱形：判断/分支
• 平行四边形：输入/输出
• 圆柱体：数据库、存储
• 箭头线：流程方向、数据流、调用关系

这套语义来源于通用的流程图规范，读者有天然的认知基础，不需要额外解读。有些非标准的图形表达，比如用花朵表示成功、用三角表示警告，看着有趣，但本质上增加了读者的认知负担，图不是用来炫耀创意的。

连线的规则同样要统一。实线表示"必须走"的主流程或调用链，虚线表示"可选"或"异步"关系，不同粗细的线用来区分核心链路和辅助链路。连线能正交就正交，不要有斜线，更不要有半圆形绕线。如果图里面出现了一段绕来绕去的线，说明布局有问题，应该调整模块位置。

3.4 第四步：用颜色和字体做信息分层

颜色在图表设计里起的是"分层"作用，不是"装饰"作用。一张图里颜色数量建议控制在三个以内。比如：

• 蓝色系：核心模块、主流程
• 灰色系：辅助模块、外部依赖
• 橙色系：需要重点关注的内容

这样读者第一眼就能通过颜色区分出"哪些是重点、哪些是背景"。如果把所有模块都画成彩色的，全部是重点，就等于没有重点。我见过一些图上红黄蓝绿青蓝紫全齐了，看起来热闹，但信息层级彻底被色彩淹没了，读图的人不知道眼睛往哪里放。

字体方面，标题和正文至少要有字号区分，同一层级文字大小一致，不用花体字，不用下划线。中文用黑体或思源类字体，英文用无衬线字体，保持统一。一个实用的小技巧：画完图之后把它转成灰度图看看，如果去掉颜色后还能清晰表达结构，说明信息层级是正确的；如果去掉颜色后全都糊在一起了，说明你在用颜色“撑场面”，结构本身还不合格。

3.5 第五步：对齐、间距、留白

最后一步是细节调整，这一看就是专业和业余的分水岭。

• 所有节点箱体对齐到统一网格，同一列宽度一致，同一行高度一致
• 节点间距保持统一，不要太挤也不要太散
• 边界留白要够，不要让图怼到画布边缘

间距统一看起来很微小，但读者能感受到那种"秩序感"。相反，间距忽大忽小、框体宽窄不一，读者会产生一种隐约的不适感，虽然他自己可能说不出哪里有问题，但就是觉得"这张图不够专业"。

我在画图的时候会用到一个习惯：所有框的宽度尽量取2的倍数，间距固定为8或16的倍数。这个习惯是从UI设计规范延伸过来的，用在图表上效果也同样明显。

4. 常见问题与排错经验：那些年我踩过的坑

4.1 图太乱是信息密度失控，不是工具问题

这是最常见的问题。画到一半发现布局乱了、线绕了，很多人第一反应是换工具或者重开一张画布，但实际上问题出在信息清单没有分层。

处理方法是：停下来，把已经画的模块列个清单，重新分组。如果一张图的节点超过20个，就该考虑拆分。我个人的经验阈值是：功能性图表最多不要超过20个节点，超过这个数量，布局和理解的难度都会指数级上升。

拆分的维度有很多种：按层次拆（接入层一张、业务层一张）、按功能域拆（交易一张、用户一张）、按场景拆（正常流程一张、异常流程一张）。核心原则还是那张图只讲一件事。

4.2 别人看不懂不一定是图的问题，但多数时候就是图的问题

如果你画完图给别人看，对方的反应是"嗯……这个模块是干嘛的？" "这条线什么意思？"，别急着解释。图的作用就是降低沟通成本，如果还需要你解释才能懂，那图的价值就没有发挥出来。

我有一个屡试不爽的经验：画完图之后，找团队里一个不熟悉这个业务的人，让他看30秒，然后描述他看到了什么。如果他的描述接近你想要的表达，说明图是合格的。如果南辕北辙，说明图的表达有问题。

这跟代码评审一个道理，代码不是写给自己看的，是写给所有维护者看的。图也一样。我在团队里推了一个做法：新图画完之后，主动在群里发一句"这张图帮忙看一眼，30秒就行"，收集几个人的反馈再定稿。这个习惯帮我在交付前发现了大量逻辑和表达问题。

4.3 常见问题速查表

4.4 关于图形复用和模板沉淀

画图多了一定会积累一些重复的图形结构，比如微服务架构的外层边界、数据流向的箭头样式、模块的阴影和圆角规格。这些应该固化成模板，每次新建图直接套用，不要每次重画一遍。

我自己的做法是维护一套个人图形模板库，包含常用配色、常用组件样式、常见架构图的整体布局。新图画出来，大体框架都不用重新设计，重点放在逻辑和内容上。这就像前端开发的组件化思想：把常用的东西抽出来复用，把注意力留给真正有差异化的部分。

团队成员之间也可以共享这套模板。一个团队如果各画各的，风格五花八门，整个项目的文档体系就会显得散乱。统一模板之后，虽然不至于每个人画的图一模一样，但至少基础元素、配色逻辑、连线语义是一致的，读者从一个图切换到另一个图时不需要重新学习规则，这种一致性本身就是效率。

4.5 保留源文件，别只存导出的图片

这是我吃过不少亏之后才养成的习惯。图导出成PNG，贴进文档里、发到群里，看着都完成了。但过了一个月，突然需要改一个模块加一条线，翻遍文件夹只找到一张不能再编辑的图片，只能对着图片重新画一遍，时间成本翻倍。

现在我的规则是：项目资料目录里永远保留图的源文件，并且导出文件和源文件放在同一个位置，文件名带上日期和版本。比如"order-flow_20250122_v1.drawio"和"order-flow_20250122_v1.png"放一起。这样任何时候拿到图，都能找到可编辑的源文件。

如果用的是代码驱动方式画图，源文件管理天然就是代码仓库里的事，更不存在这个问题。这也是我越来越倾向于用代码驱动方式来画维护型图的原因之一。图片适合最终展示，源文件适合持续维护，两者缺一不可。

4.6 画完图之后自己重新读一遍

这是最后一道工序，很多人跳过了。刚画完图的时候，脑子里的上下文还在，怎么看怎么顺。但是隔半天再看，上下文冷却了，再读这张图，才能发现哪里容易误解、哪里信息缺失、哪里线连错了。

我一般上午画完图，下午会专门花5分钟重新读一遍，模拟一个陌生人的视角。这5分钟经常能找到一两个真正的问题——比如一个箭头方向画反了，牵涉到的误解还挺大。如果时间紧迫，也可以把图发给别人看一眼，效果类似。

5. 一点个人体会

画了这么多年图，我最大的感触是"好看"从来不是第一目标，"看懂"才是。每次觉得一张图需要大改的时候，问题往往不在画图技巧上，而是背后的逻辑还没理顺。图是思维的镜子，脑子里乱，图就是乱的。反过来，图画的规整，往往说明作者已经把问题想得比较透。

diagram-design这件事，本质上是逻辑能力和换位思考能力的综合体现。多画、多给人看、多接收反馈，比多研究配色和排版成长更快。我现在看一张图的水平，基本能判断出作者的专业程度和思维清晰度，这个判断标准很简单——干净、清楚、信息分层合理，每一个元素都有存在的原因。画图不复杂，按着流程走，注意上文那些细节，你的下一张图就会比现在这张好得多。