企业官网建设流程全解析

1. 从一张草图到一套系统：diagram-design 到底在解决什么问题

第一次看到 diagram-design 这个标题，很多人会以为它只是一个画图工具的代称。但真正做过技术方案、写过设计文档、给团队讲过架构的人会明白，图从来不是“画出来好看”那么简单。一张架构图背后，藏着信息分层、关系表达、视觉引导、认知负荷控制这一整套设计逻辑。diagram-design 这个项目，本质上是在做一件事：把“画图”这件事从随手涂鸦，升级成一套可复用、可维护、可协作的视觉表达系统。

我在过去几年里参与过不少技术文档和方案评审的工作，见过太多让人抓狂的图。有的图信息密度极高，一张图塞了三十个模块，箭头像蜘蛛网一样交错，看五分钟都找不到入口；有的图又过于简陋，三个方框两条线，看完完全不知道系统边界在哪里。这两种极端背后其实是同一个问题：画图的人没有把“图”当成一种设计产物来对待，而是当成了一种随手记录。diagram-design 要解决的，就是这个认知层面的问题。

这个项目适合谁来参考？我的判断是三类人。第一类是技术写作者和文档工程师，他们需要把复杂的系统逻辑转化成读者能快速理解的视觉语言；第二类是产品经理和方案架构师，他们需要用图来对齐认知、推动决策；第三类是任何需要做知识梳理和表达的人，哪怕你只是想把一个流程讲清楚，图的设计逻辑都会直接影响沟通效率。不管你用的是哪种工具，是代码驱动还是拖拽式操作，diagram-design 的核心思路都是通用的。

我写这篇东西的出发点很简单：把我自己在 diagram-design 这个方向上踩过的坑、总结的方法、验证过的流程，完整地摊开来讲。不是教科书式的“第一步第二步”，而是带着实际场景和判断逻辑的实操记录。你可以直接抄作业，也可以根据自己的场景做调整。

2. 整体设计思路拆解：为什么图需要“设计”而不是“画”

2.1 图的本质是信息压缩，不是信息堆砌

很多人画图的时候有一个潜意识：把所有知道的信息都放上去，生怕漏了什么。这个思路在写文档的时候可能没问题，但在画图的时候是致命的。图的本质是信息压缩，它通过视觉元素的排列组合，把复杂的逻辑关系压缩成一眼能看懂的结构。压缩就意味着取舍，取舍就意味着你要判断什么信息是核心，什么信息是背景，什么信息可以放到图外的文字说明里。

diagram-design 的第一个核心原则就是：一张图只讲一件事。这个“一件事”可以是一个系统的主干流程，可以是一个模块的内部结构，也可以是一个数据从输入到输出的完整链路。但你不能在一张图里既讲部署架构又讲业务逻辑还讲数据流向，那只会让读者迷失。

我自己的做法是，在动手画之前先写一句话：这张图要让读者看完之后记住什么？如果这句话写不出来，说明你还没想清楚，那就先别画。这句话就是这张图的“设计目标”，后面所有的视觉决策都要围绕它来展开。

2.2 视觉层级决定阅读顺序

图和人一样，第一印象很重要。读者打开一张图，眼睛会本能地寻找一个入口。如果你没有给出明确的视觉层级，读者就会乱看，然后放弃。diagram-design 在视觉层级上的处理逻辑，我总结成三个维度：大小、位置、颜色。

大小是最直接的层级信号。核心模块画大一点，辅助模块画小一点，这是最朴素的视觉引导。位置也很关键，人眼习惯从左到右、从上到下阅读，所以主干流程通常放在中间偏左的位置，分支和补充信息放在右侧或下方。颜色是最容易被滥用的，很多人喜欢用五颜六色来区分模块，结果整张图像打翻了调色盘。我的经验是，一张图的主色调不要超过三种，其中一种作为强调色，只用在最关键的节点上。

注意：颜色不是用来“好看”的，是用来“区分”和“强调”的。如果你用颜色只是为了好看，那不如全部用灰度，把精力放在结构和布局上。

2.3 一致性比创意更重要

diagram-design 这个方向有一个反直觉的点：图的“设计感”不来自于每一张图的独特创意，而来自于一套图之间的一致性。如果你在一个项目里画了十张图，每张图的方框圆角不一样、箭头样式不一样、字体大小不一样，读者每看一张图都要重新适应一套视觉规则，认知成本极高。

所以我在做 diagram-design 的时候，第一件事不是画图，而是定规则。方框用什么形状、圆角多少、边框粗细多少、箭头用什么样式、字体用多大、间距怎么控制，这些规则定好之后，后面所有的图都在这套规则下产出。这样做的好处是，读者看第一张图的时候建立起来的认知，可以直接复用到后面所有的图上。

这套规则不需要很复杂，我通常用一个简单的表格来管理：

这张表看起来简单，但它能解决 80% 的视觉混乱问题。剩下的 20%，靠的是布局和间距的控制。

2.4 工具选型：代码驱动还是拖拽式

diagram-design 这个方向绕不开工具选型。我自己的判断逻辑是这样的：如果你的图需要频繁修改、需要版本管理、需要和代码一起维护，那就选代码驱动的方案；如果你的图是一次性的、偏演示性质的、需要快速出效果，那就选拖拽式工具。

代码驱动的方案有一个巨大的优势：可复用。你可以把常用的模块定义成组件，把常用的布局定义成模板，下次画类似的图直接调用就行。而且代码天然适合版本管理，每次修改都有记录，团队协作的时候也不会出现“谁把图改乱了”的问题。缺点是学习曲线陡峭，你需要花时间熟悉语法和布局逻辑。

拖拽式工具的优势是上手快，所见即所得，适合快速原型和演示。缺点是难以维护，图多了之后管理成本很高，而且不同人画出来的风格很难统一。

我自己的做法是混合使用：核心的、需要长期维护的架构图用代码驱动，一次性的、偏沟通性质的草图用拖拽式。两者不冲突，关键是你要清楚每张图的定位。

3. 核心细节解析与实操要点：从需求到成图的完整链路

3.1 需求拆解：先想清楚，再动手

我在 diagram-design 上最大的教训就是：不要拿到需求就开始画。画图之前的思考时间，至少应该和画图时间一样长。需求拆解的核心是回答三个问题：读者是谁、读者需要什么、读者看完之后要做什么。

读者是谁决定了图的专业深度和表达方式。给管理层看的图，重点在业务价值和整体结构，技术细节要弱化；给开发团队看的图，重点在模块边界和调用关系，业务背景可以简化。读者需要什么决定了信息的取舍，读者看完之后要做什么决定了图的引导方向。

我通常会用一张纸先把这三个问题的答案写下来，然后才开始考虑视觉呈现。这个习惯看起来浪费时间，但实际上能省下大量返工的时间。因为很多图之所以要改，不是因为画得不好，而是因为一开始就没想清楚要画什么。

3.2 信息架构：把逻辑关系翻译成视觉关系

信息架构是 diagram-design 里最核心也最难的部分。你需要把脑子里的逻辑关系，翻译成视觉上的位置关系和连接关系。这个过程我通常分三步走。

第一步是列出所有节点。把图里需要出现的所有模块、组件、角色、数据存储都列出来，不要考虑布局，先列全。第二步是定义关系。哪些节点之间有调用关系，哪些有数据流向，哪些是包含关系，哪些是依赖关系，用不同的连接方式区分开。第三步是分组和分层。把关系紧密的节点放在一起，把不同层级的节点用位置或视觉容器区分开。

这三步做完之后，你其实已经有了一张“逻辑图”，只是还没有视觉化。接下来的工作就是把这个逻辑图翻译成视觉图。翻译的过程中，你会发现有些节点可以合并，有些关系可以简化，有些层级可以调整。这些都是正常的，图的设计本来就是一个不断收敛的过程。

3.3 布局控制：间距、对齐、留白

布局是 diagram-design 里最考验功力的部分。我见过太多图，内容都对，但看起来就是不舒服，问题基本都出在布局上。布局的核心就三个词：间距、对齐、留白。

间距控制的是节奏感。模块之间的间距要一致，不能有的地方挤在一起，有的地方空一大片。我的经验是，同级模块之间的间距保持一致，不同级模块之间的间距要有明显差异，这样读者才能通过间距判断层级关系。

对齐控制的是秩序感。所有的模块应该对齐到某条隐形的网格线上，左对齐、居中对齐、顶对齐，选一种然后贯彻到底。对齐做得好，图看起来就是“整”的；对齐做不好，图看起来就是“散”的。

留白控制的是呼吸感。很多人舍不得留白，觉得空白就是浪费。但实际上，留白是图的重要组成部分，它给读者眼睛休息的空间，也给信息划分了边界。一张没有留白的图，就像一篇没有段落的文章，读起来累。

提示：如果你觉得图看起来“哪里不对”但又说不上来，先检查对齐和间距。80% 的视觉问题都出在这两个地方。

3.4 标注与说明：图内图外的信息分工

diagram-design 的一个关键决策是：什么信息放在图里，什么信息放在图外。我的原则是，图里只放“结构信息”，图外放“解释信息”。结构信息包括模块名称、关系类型、关键参数；解释信息包括背景说明、设计理由、注意事项。

这样做的好处是图保持干净，读者不会被大段文字打断视觉流。但图外的说明也要有组织，不能随便堆在图的旁边。我通常会用编号或者颜色标记，把图里的节点和图外的说明对应起来，读者看到图里的某个节点，可以快速找到对应的解释。

如果图里的某个节点确实需要一些说明，我会用简短的标注，控制在十个字以内。超过十个字的说明，一律放到图外。这个规则看起来很死板，但实际用起来非常有效，它能强迫你提炼信息的核心。

4. 实操过程与核心环节实现：一套可复用的画图流程

4.1 环境准备与工具链搭建

在开始画图之前，你需要把工具链准备好。我自己的工具链包括三个部分：绘图工具、版本管理、预览和导出。

绘图工具的选择取决于你的技术背景和图的类型。如果你熟悉代码，我建议用代码驱动的方案，比如基于文本描述生成图表的工具，或者用绘图库自己写脚本。如果你不熟悉代码，那就选一个支持组件化和样式管理的拖拽式工具。关键是这个工具要支持你定义可复用的样式和组件，否则图多了之后维护成本会很高。

版本管理这块，如果图是代码驱动的，直接跟代码一起放在版本控制里就行。如果是拖拽式工具，至少要保证每次修改都有导出备份，并且命名规范要统一。我见过太多团队，图改了十几版之后，没人知道哪版是最新的。

预览和导出这块，我建议至少准备两种格式：一种是矢量格式，用于嵌入文档和放大查看；一种是位图格式，用于快速分享和演示。矢量格式能保证放大不模糊，位图格式能保证兼容性。

4.2 从模板开始：建立你的图库

diagram-design 的效率提升，很大程度上来自于模板化。我自己的做法是，每画完一张图，就把里面可复用的部分抽出来，存到我的图库里。图库包括三类内容：样式模板、布局模板、组件模板。

样式模板定义的是视觉规则，比如颜色、字体、边框、箭头样式。布局模板定义的是常见的结构，比如三层架构、流水线、星型拓扑。组件模板定义的是常见的模块，比如数据库、缓存、消息队列、网关。

有了图库之后，画新图的时候就不是从零开始，而是从模板开始。你只需要把模板里的占位内容替换成实际内容，调整一下布局，一张图就出来了。这个过程可能只需要十几分钟，而不是几个小时。

我自己的图库已经积累了两年多，现在画一张中等复杂度的架构图，从需求拆解到成图，基本控制在一个小时以内。这个效率提升是实实在在的。

4.3 分步实操：画一张系统架构图的完整过程

下面我用一个模拟项目来演示完整的画图过程。假设我们要画一个“某跨平台系统的整体架构图”，读者是开发团队，目的是让新加入的成员快速理解系统结构。

第一步是需求拆解。读者是开发团队，需要了解系统的模块划分和调用关系，看完之后能知道每个模块的职责和边界。基于这个判断，图的重点应该放在模块划分和主干调用链上，部署细节和业务逻辑可以简化。

第二步是列出节点。这个系统大概包括：接入层、网关、业务服务、数据服务、缓存、消息队列、数据库、外部依赖。每个节点再往下拆一层，比如业务服务包括用户服务、订单服务、支付服务。

第三步是定义关系。接入层调用网关，网关路由到业务服务，业务服务调用数据服务和缓存，业务服务之间通过消息队列异步通信，数据服务读写数据库。

第四步是分组和分层。接入层和网关放在最上面，业务服务放在中间，数据服务和存储放在下面，外部依赖放在右侧。用不同的背景色或者边框区分不同的层。

第五步是视觉化。按照之前定好的样式规则，把节点画成对应的形状，用对应的箭头连接，调整间距和对齐，加上必要的标注。

第六步是检查和迭代。把图给一个不熟悉这个系统的同事看，问他能不能看懂。如果他有疑问，说明图里还有不清晰的地方，继续调整。

这个流程看起来步骤很多，但实际操作起来，熟练之后就是十几分钟的事。关键是每一步都要有明确的判断标准，不能凭感觉。

4.4 参数计算：间距和尺寸的量化控制

diagram-design 里有一个容易被忽略的点：参数是需要计算的，不是拍脑袋定的。我举几个例子。

模块的宽度怎么定？我的做法是先确定最长模块名称的字数，然后根据字号和字间距算出文本宽度，再加上左右内边距，就是模块的最小宽度。如果模块需要放图标，还要加上图标的宽度和间距。

模块之间的间距怎么定？同级模块之间的间距通常是模块宽度的 20% 到 30%，不同级模块之间的间距是同级间距的 1.5 到 2 倍。这个比例不是绝对的，但有一个量化的参考，比凭感觉调要靠谱得多。

字号怎么定？如果图是嵌入文档的，正文字号通常是文档正文字号的 80% 到 90%。如果图是独立展示的，正文字号要保证在正常观看距离下清晰可读，通常是 14px 到 16px。标题字号是正文字号的 1.2 到 1.5 倍。

这些参数不需要很精确，但需要有意识地去控制。当你把参数控制好了，图的“专业感”自然就出来了。

5. 常见问题与排查技巧实录：那些年我踩过的坑

5.1 图太乱怎么办：从信息密度入手

图太乱是最常见的问题。我的排查思路是：先看信息密度，再看视觉层级，最后看布局。

信息密度太高，通常是节点太多或者标注太多。解决办法是拆分，把一张图拆成两张，一张讲主干，一张讲细节。或者把一些节点合并，把一些标注移到图外。

视觉层级不清晰，通常是大小、位置、颜色没有区分度。解决办法是强化对比，核心节点放大、加粗、用强调色，辅助节点缩小、减淡、用中性色。

布局有问题，通常是对齐和间距没控制好。解决办法是拉辅助线，把所有模块对齐到网格上，统一间距。

5.2 读者看不懂怎么办：换位思考

读者看不懂，很多时候不是图的问题，而是你和读者之间的信息差。你觉得理所当然的东西，读者可能完全不知道。解决办法是找一个不了解这个系统的同事，让他看图，然后问他看到了什么。他的回答会告诉你图里哪些信息缺失，哪些关系不清晰。

我自己的习惯是，重要的图至少找两个人看，一个是熟悉系统的，一个是完全不了解的。熟悉系统的人能发现技术错误，不了解的人能发现表达问题。

5.3 图改不动怎么办：从源头解决

图改不动，通常是因为一开始的结构没设计好。比如你把所有节点都画死了，没有留出扩展空间，后面加一个节点就要重新布局。解决办法是在设计阶段就考虑扩展性，把布局做成模块化的，每个模块可以独立调整，不影响其他模块。

另一个原因是样式没有统一管理，改一个样式要改几十个地方。解决办法是使用样式模板，把样式和内容分离，改样式只需要改模板。

5.4 常见问题速查表

5.5 独家避坑技巧

第一个技巧是“灰度测试”。把图转成灰度，如果还能看清楚层级关系，说明你的视觉层级是靠结构和对比建立的，而不是靠颜色。这样的图更健壮，打印出来或者色觉障碍的读者也能看懂。

第二个技巧是“缩小测试”。把图缩小到 50%，如果还能看出主干结构，说明你的图在信息压缩上做得不错。如果缩小之后完全糊成一团，说明信息密度太高，需要拆分。

第三个技巧是“三秒测试”。把图给同事看三秒，然后问他看到了什么。如果他能说出核心结构，说明图的引导做得好。如果他说不出什么，说明图的视觉焦点不明确。

6. 从单张图到图体系：diagram-design 的进阶思路

6.1 建立图的分类体系

当你画的图多了之后，就需要建立一个分类体系。我自己的分类方式是按照“抽象层级”和“变化频率”两个维度来分。

抽象层级分为三层：业务架构图、应用架构图、技术架构图。业务架构图讲的是业务模块和业务流程，变化频率低；应用架构图讲的是系统模块和调用关系，变化频率中等；技术架构图讲的是部署单元和技术组件，变化频率高。

变化频率决定了图的维护策略。变化频率低的图，可以做得更精细，投入更多时间；变化频率高的图，要做成模板化的，方便快速更新。

6.2 图的版本管理与协作

图的版本管理是一个容易被忽略但非常重要的问题。我的做法是，每张图都有一个唯一的标识，每次修改都记录修改内容和修改人。如果是代码驱动的图，直接用版本控制工具管理；如果是拖拽式工具，至少要有导出备份和修改日志。

协作方面，最重要的是统一规范。团队里每个人画图的风格可以不同，但规范必须一致。规范包括样式规范、命名规范、布局规范。规范定好之后，新加入的人也能快速产出风格一致的图。

6.3 从图到文档：图的上下文建设

图很少单独存在，它通常是一篇文档的一部分。所以 diagram-design 不仅要考虑图本身，还要考虑图和文档的关系。我的做法是，每张图都有一个简短的说明，包括这张图讲什么、读者应该关注什么、有哪些相关的图可以一起看。

这个说明不需要很长，两三句话就行，但它能帮助读者快速定位图的作用，而不是打开图之后一脸茫然。如果图是嵌入在文档里的，说明可以放在图的上面或下面；如果图是独立展示的，说明可以放在图的旁边或者作为图的一部分。

6.4 持续迭代：图不是画完就结束了

图是有生命周期的。系统在变，图也要跟着变。我自己的习惯是，每次系统有重大变更，就检查相关的图是否需要更新。更新的原则是“小步快跑”，不要等到图完全过时了才大改，而是每次变更都顺手更新一下。

这样做的好处是，图始终和系统保持一致，读者看到的永远是最新的信息。而且小步更新的成本很低，不会成为负担。如果等到图完全过时了再改，那工作量就大了，而且很容易漏掉一些细节。

我在实际操作中的体会是，diagram-design 这件事，技术含量不在画图工具上，而在思维方式上。你把图当成一种设计产物，它就会回报你清晰和效率；你把它当成随手涂鸦，它就会回报你混乱和返工。这个道理，画过一百张图之后自然就懂了。