企业官网建设流程全解析

1. 从“diagram-design”这个标题能读出什么

第一次看到“diagram-design”这个标题，我脑子里蹦出来的不是某个具体工具，而是一类非常典型的工作场景：手里有一堆零散的信息——流程、层级、关系、时序、状态流转——需要用一张图把它们讲清楚，而且这张图还得好看、好懂、好维护。很多人以为画图就是拖拖拽拽，真做过项目的人都知道，图这东西一旦进入正式文档、技术方案、产品说明，它就不再是“随便画画”，而是一种信息压缩和认知传递的设计工作。

“diagram-design”拆开看，核心落在两个词上：diagram（图表/示意图）和 design（设计）。它指向的不是单纯的绘图技巧，而是“如何设计一张图”。这背后至少包含四层需求：第一层是选型，什么内容该用什么图；第二层是结构，图的节点、连线、分组怎么组织；第三层是视觉，颜色、字号、间距、对齐怎么处理；第四层是维护，图怎么跟着内容一起迭代而不至于每次重画。这四层里，前两层决定图对不对，后两层决定图好不好用。

我见过太多团队在这件事上翻车。有人用流程图去表达一个本质上是状态机的逻辑，结果图画得密密麻麻还是说不清；有人把架构图画成了“框框连连看”，每个框里塞满文字，读者看三秒就放弃；还有人图做得挺漂亮，但源文件丢了，改一个字段要重新画一遍。所以这篇内容我想聊的不是“哪个画图工具最好”，而是把 diagram-design 当成一个完整的设计问题来拆：从需求判断到图形选型，从结构搭建到视觉规范，再到工程化维护，把这条链路走通。

适合谁看？如果你是技术写作者、产品经理、架构师、设计师，或者任何需要把复杂信息可视化的人，这篇都能对上号。如果你只是偶尔画个简单示意图，也能从里面挑几招直接用。下面我按自己实际做项目的顺序，一层层往下拆。

2. 先判断“该不该画图”，再决定“画什么图”

2.1 什么内容值得用图表达

不是所有信息都适合画图。我踩过的第一个坑就是“为了画图而画图”——把一段本来三句话能说清的内容硬做成一张图，结果读者要花更多时间解读图形符号。判断标准其实很简单：当信息之间存在“关系”且这种关系用文字描述会变得冗长或容易歧义时，图才有价值。

具体来说，以下几类内容天然适合图形化：

• 流程与分支：多个步骤按顺序执行，中间有条件判断和回流。文字描述会变成“先做A，如果满足X则做B，否则做C，做完B或C之后再回到A”，读起来累，画成流程图一目了然。
• 层级与包含：组织架构、目录结构、模块划分。这类内容的核心是“谁在谁里面”，用嵌套矩形或树形图最直观。
• 时序与交互：多个角色之间按时间顺序交换消息。这类内容用文字写就是流水账，用时序图能同时表达“谁和谁”“先后顺序”“消息内容”三个维度。
• 状态与迁移：一个对象在不同状态之间切换，以及触发切换的条件。状态机图是这类内容的专属表达。
• 关系与拓扑：节点之间的连接关系，比如网络拓扑、依赖关系、数据流向。这类图的重点是“连接”，不是“顺序”。

反过来，如果内容只是并列的几条要点，没有顺序、没有层级、没有连接关系，那用列表就够了，硬画成图反而增加认知负担。我自己的经验法则是：如果一段文字里出现了“然后”“如果”“回到”“同时”“依赖于”这类关系词超过三次，就值得考虑画图。

2.2 图形选型对照表

确定要画图之后，下一步是选对图形类型。这一步错了，后面怎么调都别扭。我整理了一张常用图形与适用场景的对照表，基本覆盖了日常工作中八成以上的需求：

选型时还有一个容易被忽略的点：一张图只表达一个核心维度。我见过有人试图在一张图里同时表达流程、角色和时间，结果画出来像蜘蛛网。正确做法是拆成多张图，每张图聚焦一个维度，图与图之间用编号或引用关联。比如一个完整的下单系统，可以用一张架构图讲模块划分，一张时序图讲下单交互，一张状态机图讲订单状态流转，三张图各司其职，读者按需查阅。

2.3 先画草图再上工具

这一步很多人跳过，但它直接决定最终图的质量。我的习惯是：在打开任何绘图工具之前，先用纸笔或白板把节点和连线列出来。这个阶段只关心“有哪些元素”和“它们怎么连”，完全不考虑美观。

具体做法是：把所有节点写成短句或关键词，然后问自己三个问题——哪些节点是同一类、哪些节点之间有直接关系、哪些节点是起点和终点。回答完这三个问题，图的基本骨架就出来了。这时候再上工具，你是在“翻译”一个已经想清楚的结构，而不是在工具里一边想一边画。后者最容易出现的问题是：画到一半发现结构不对，推倒重来，时间全浪费在调整布局上。

提示：草图阶段用不同颜色的笔区分“确定的节点”和“待确认的节点”，能帮你快速识别信息缺口，避免把不确定的内容画进正式图里。

3. 结构设计：让图“读得下去”的底层逻辑

3.1 节点粒度：一个节点只装一件事

图读不下去，十有八九是节点粒度出了问题。最常见的错误是把一整段描述塞进一个框里，框比别的框大五倍，读者视线被它吸住，整个图的节奏就乱了。我的原则是：一个节点只承载一个概念，节点内的文字控制在两行以内。

如果某个节点的内容确实很多，说明它应该被拆成多个节点，或者把细节移到图外的注释里。举个例子，画一个“用户登录”流程，不要写“用户输入账号密码并点击登录按钮，系统校验账号密码是否正确”，而是拆成“输入凭证”“提交登录”“校验凭证”三个节点。拆开之后，每个节点都短，连线关系也清晰，读者一眼就能扫完。

节点粒度还影响图的扩展性。粒度粗的图，加一个新步骤就要动大手术；粒度细的图，加节点只是多一个框和一条线。所以从维护角度看，宁可拆细，不要合并。

3.2 连线规则：减少交叉，明确方向

连线是图的血管，血管乱了，图就废了。减少连线交叉有几个实用技巧：

• 分层布局：把节点按“阶段”或“层级”排成几行，连线尽量在相邻行之间走，避免跨行大跨度连接。
• 统一方向：流程图统一从上到下或从左到右，不要一会儿横一会儿竖。方向统一之后，读者不需要思考“这条线往哪走”。
• 合并同类连线：如果多个节点都指向同一个目标，可以用一条总线汇聚，而不是画多条平行线。
• 用颜色区分连线类型：比如实线表示主流程，虚线表示异常分支，不同颜色表示不同角色。但颜色不要超过三种，否则就变成彩虹图了。

方向性上，箭头是必须的，但箭头太多也会造成视觉噪音。一个折中方案是：主流程用箭头，辅助关系用无箭头连线或虚线。这样读者能快速区分“主要路径”和“次要关联”。

3.3 分组与边界：用容器表达“归属”

当图里的节点超过十五个，就需要分组了。分组的作用是告诉读者“这几个节点是一伙的”。常见的分组方式有：

• 矩形框：最直接，把相关节点框在一起，框上标组名。
• 背景色块：比矩形框更轻量，适合分组边界不需要强调的场景。
• 泳道：按时序图或流程图中的角色划分，每个角色一条泳道，节点放在对应泳道里。

分组的关键是边界要清晰，组名要具体。我见过有人用“其他”作为组名，这种分组等于没分。组名应该是一个有意义的概念，比如“认证模块”“数据层”“外部依赖”。另外，分组不要嵌套太深，两层基本是上限，三层以上读者就晕了。

3.4 一张图的信息密度控制

信息密度是图设计里最微妙的平衡。太稀疏，图显得空洞，读者觉得“这点东西也值得画图”；太密集，读者直接放弃。我的经验值是：一张图里的节点数量控制在 7 到 15 个之间，连线数量控制在节点数量的 1.5 倍以内。

超过这个范围，就要考虑拆图。拆图的方式有两种：一种是按维度拆，比如把“流程”和“状态”拆成两张图；另一种是按层级拆，先画一张总览图，每个模块再画一张细节图。总览图用编号标注模块，细节图用同样的编号，读者可以按图索骥。

注意：拆图之后一定要有“导航”，也就是告诉读者这几张图之间的关系。最简单的做法是在每张图下方写一句“本图是总览图中模块 3 的展开”。

4. 视觉规范：让图“看起来专业”的具体参数

4.1 字体与字号：可读性优先

图的视觉问题里，字体和字号是最容易被忽视的。很多人画完图觉得“哪里不对”，但又说不上来，往往就是字体在作祟。我的建议是：

• 字体统一：全图只用一种字体，中文用无衬线字体（如思源黑体、苹方），英文用对应的无衬线字体。不要混用衬线和无衬线。
• 字号分级：标题字号、节点字号、注释字号拉开差距。一般标题 16-20px，节点文字 12-14px，注释 10-12px。差距太小，层级出不来；差距太大，注释看不清。
• 行高适中：节点内多行文字的行高设为字号的 1.4 到 1.6 倍，太挤读起来累，太松显得散。

还有一个细节：节点内的文字对齐方式要统一。要么全部左对齐，要么全部居中，不要有的左对齐有的居中。左对齐适合文字较多的节点，居中适合短标签。

4.2 配色：三色原则与语义色

配色是图设计里最容易“用力过猛”的地方。我的原则是：主色不超过三种，每种颜色有明确的语义。

具体做法是：选一个主色用于主要节点，一个辅助色用于次要节点或强调，一个中性色（灰）用于背景和辅助线。如果还需要区分更多类别，用同色系的不同深浅，而不是引入新色相。比如主色是蓝色，可以用深蓝、中蓝、浅蓝区分三个层级，视觉上仍然统一。

语义色是进阶技巧：让颜色承载信息。比如绿色表示“正常/成功”，红色表示“异常/失败”，黄色表示“警告/待定”。这样读者不需要看图例就能理解节点含义。但语义色一旦确定，全图甚至全文档都要保持一致，不能这张图绿色表示成功，那张图绿色表示待办。

4.3 间距与对齐：专业感的来源

如果说配色决定图“好不好看”，那间距和对齐决定图“专不专业”。这两点做不好，图会显得很“业余”，但很多人又说不清问题在哪。

间距的核心是一致性：节点之间的水平间距一致，垂直间距一致，节点内文字与边框的间距一致。我通常用 8px 作为基础间距单位，所有间距都是 8 的倍数（8、16、24、32）。这样图看起来会有一种内在的节奏感。

对齐的核心是网格：把所有节点对齐到隐形的网格上。大多数绘图工具都有“对齐到网格”或“智能参考线”功能，一定要打开。对齐之后，即使节点大小不一，整体也会显得整齐。我见过最有效的改进就是：把一张图里所有节点的左边缘对齐，专业感立刻提升一个档次。

4.4 图例与标注：降低理解成本

图例不是每张图都需要，但如果图里用了颜色、线型、形状来区分含义，就必须有图例。图例的位置一般在图的右下角或下方，不要放在图中间干扰阅读。

标注比图例更灵活，用于解释特定节点或连线的细节。标注的写法有讲究：用短句，不用长句；用具体名词，不用代词。比如“此处超时重试三次”比“这里会做一些处理”有用得多。标注的引线要指向明确，不要指向空白区域让读者猜。

5. 工具选型：不同场景下的取舍

5.1 代码化绘图 vs 拖拽式绘图

工具选型上，最大的分水岭是“代码化绘图”和“拖拽式绘图”。两者没有绝对优劣，关键看场景。

代码化绘图（如 Mermaid、Graphviz、PlantUML 这类文本描述生成图形的方案）的优势是：

• 图的内容可以进版本控制，改动能追溯
• 批量修改方便，改一个定义全图生效
• 适合结构规整、节点多的图
• 和文档系统集成好，改文档时图自动更新

劣势是：

• 布局控制力弱，复杂图容易排得难看
• 学习成本高，需要记语法
• 不适合需要精细视觉调整的场景

拖拽式绘图（如各类在线白板和桌面绘图软件）的优势是：

• 所见即所得，布局完全可控
• 上手快，不需要学语法
• 适合视觉要求高、结构不规整的图

劣势是：

• 源文件容易丢，改图靠手动
• 多人协作时版本混乱
• 图多了之后维护成本高

我的实际做法是混合使用：结构规整、需要频繁更新的图（如流程图、时序图、状态机图）用代码化方案；视觉要求高、一次性或低频更新的图（如架构总览、宣传用图）用拖拽式方案。两者不是对立的，而是各管一段。

5.2 选型时容易忽略的三个维度

除了“代码还是拖拽”，选型时还有三个维度容易被忽略：

第一，导出格式。图最终要放到哪里？如果是文档，需要矢量格式（SVG、PDF）；如果是演示，需要高分辨率位图（PNG）；如果是网页，SVG 最合适。选工具前先确认它能不能导出你需要的格式。

第二，协作方式。是单人画还是多人改？多人改的话，工具是否支持实时协作、评论、版本历史？如果团队里有人不熟悉工具，学习成本也要算进去。

第三，长期维护。这张图三个月后还要改吗？如果要改，源文件在哪里？改的人能不能找到？我见过太多“图在文档里，源文件在某人电脑里，某人离职了”的悲剧。所以源文件必须和文档放在一起，或者用代码化方案让图本身成为文档的一部分。

5.3 我的工具组合与使用场景

说具体一点，我目前的组合是这样的：

• 流程图、时序图、状态机图：用文本描述生成，源文件直接写在 Markdown 里，和文档同源。改文档的时候顺手改图，不会出现图和文档不一致的情况。
• 架构图、部署图：用拖拽式工具画，导出 SVG 放进文档。这类图视觉要求高，且更新频率低，拖拽式更合适。
• 草图、讨论用图：用在线白板，快速画完截图发群里，不追求精度，追求速度。
• 复杂关系图：用自动布局的图形描述语言，让工具算布局，人只负责定义节点和关系。

这个组合的核心逻辑是：让图的维护成本跟它的更新频率匹配。更新频繁的用代码化，更新少的用拖拽式，一次性的用白板。

6. 从“画完”到“维护好”：图的工程化

6.1 源文件管理：图也要进版本控制

图最大的维护痛点是“源文件丢失”。解决办法只有一个：把图的源文件当成代码来管理。具体来说：

• 代码化方案的源文件本身就是文本，直接进版本控制，和文档放同一个仓库。
• 拖拽式方案的源文件（如 .drawio、.fig 等）也要进仓库，不要只存导出的图片。
• 导出的图片作为“产物”，可以进仓库也可以不进，但源文件必须在。

这样做的好处是：任何时候都能找到图的“可编辑版本”，改图不需要从零开始。而且版本控制能记录每次改动，出问题可以回滚。

6.2 命名与目录：让图能被找到

图多了之后，找图就成了问题。我的做法是给图建立命名规范：

• 文件名用“模块-图类型-版本”的格式，比如auth-flow-v2、order-state-v1。
• 所有图放在统一的diagrams目录下，按模块分子目录。
• 文档里引用图的时候，用相对路径，不要用绝对路径。

这样任何人拿到仓库，都能快速定位到需要的图。命名规范不需要复杂，关键是团队内统一，并且坚持执行。

6.3 图与文档的同步策略

图和文档不同步是另一个常见问题。文档改了，图没改，读者看到的是过时信息。解决办法有两个：

方案一：图内嵌在文档里。用代码化方案，图直接写在文档源文件中，改文档就是改图，天然同步。这是最省心的方案，适合结构规整的图。

方案二：图独立但建立检查机制。如果图必须独立（比如拖拽式画的），就在文档里标注图的版本号，并在每次文档更新时检查相关图是否需要同步。可以做一个简单的检查清单：文档改了哪些章节，对应哪些图，逐一确认。

我倾向于方案一，能用代码化就用代码化，把同步问题消灭在源头。实在不能用代码化的图，至少要做到“改文档时顺手看一眼相关图”。

6.4 常见维护坑与规避

最后列几个我在维护图的过程中踩过的坑，供你参考：

• 坑一：图里写死了具体数据。比如流程图中写了“最多重试 3 次”，后来改成 5 次，图忘了改。规避方法是把可变参数抽出来，图里只写“重试”，具体次数在文档正文里说明。
• 坑二：一张图承担太多职责。既想表达流程又想表达状态，结果两边都不清楚。规避方法是拆图，一张图一个维度。
• 坑三：图没有标题和说明。读者不知道这张图在讲什么。规避方法是每张图都加标题，必要时加一句说明。
• 坑四：颜色语义不一致。这张图红色表示错误，那张图红色表示重点。规避方法是建立全文档统一的颜色语义表，画图时对照使用。

提示：如果你刚开始做图的工程化管理，不要一次上太多规范。先从“源文件进版本控制”和“统一命名”这两条做起，跑顺了再加别的。

7. 我在这件事上的几个真实体会

做了这么多图，我最大的体会是：图的质量不取决于你用了多高级的工具，而取决于你在画之前想了多少。那些看起来干净利落的图，背后都是先把结构想清楚了才动手的。反过来，那些画得乱七八糟的图，往往是边画边想，最后结构失控。

第二个体会是：图是给人看的，不是给工具看的。很多人画图时盯着工具里的对齐线、网格、样式面板，却忘了读者会怎么读这张图。每次画完，我都会把图缩小到 50% 看一眼——如果缩小后还能看出主要结构，说明图是清晰的；如果缩小后变成一团糊，说明信息密度太高或者层级没拉开。

第三个体会是：维护成本要在画图之前就考虑。一张图如果三个月后要改，那它就不应该用“画完就丢”的方式来做。源文件、命名、版本控制这些事，看起来是“额外工作”，实际上是省未来的时间。我见过太多团队在“重画图”上浪费的时间，远超当初建立规范的成本。

最后一个体会是关于拆图的：宁可多画几张简单的图，也不要画一张复杂的图。读者的耐心是有限的，一张图如果三十秒内看不懂，大概率就不会再看了。拆成几张图，每张聚焦一个点，读者反而愿意逐张看下去。这个道理和写文档一样——长文档要分章节，复杂的图也要分层次。