企业官网建设流程全解析

先说一个我自己的观察：在一个技术团队里，最容易被随便对待的交付物，往往就是图。代码要过Review，文档要校稿，但流程图、架构图、时序图经常是谁有空谁画，画完没人再看。直到有一天，一位刚入职的同学拿着我给的架构图，指着角落一处虚线箭头来问“这个到底是什么意思”，我才意识到，diagram-design这件事，远不是打开画板拖几个框那么简单。

图是沟通工具，不是交差用的附件。同一个模块，画给老板看、画给后端同学看、画给新同学看，信息量和表达方式完全不同。这篇内容适合正在做软件架构、技术方案、产品设计，或者经常要把复杂逻辑讲清楚的人。我整理了过去几年做图表设计的思路，包括图类型的选型、信息层次的编排、从草稿到交付的工作流，以及实际维护中反复踩过的坑，希望能帮你在下次画图时少走弯路。

1. 先搞清楚：diagram-design不是画图，是设计信息结构

很多人把画图理解为“把想到的东西放到画布上”，所以一开始就在纠结用哪种箭头、哪个颜色、要不要加阴影。这是本末倒置。diagram-design 的核心，是先决定这张图要传递什么观点，再决定哪些信息出现在图里、哪些信息必须被拿掉。

1.1 为什么大多数图“画完了却没人看懂”

我见过太多这样的图：一张 A4 画布里塞满了二三十个框，箭头交叉得像毛线团，角落还有一大段说明文字。画图的人觉得“我表达得很完整”，看的人却完全抓不住重点。问题出在哪？通常是三个原因叠在一起。

第一，缺少阅读顺序。人眼看图天然是从上到下、从左到右的，但图里的元素如果随意摆放，视线就会到处跳。第二，层级没有拉开。核心路径和辅助分支用完全一样的线宽和颜色，看的人分不清哪个是主线、哪个是异常处理。第三，信息颗粒度失控。一张图把业务流程图、技术架构、部署节点全揉在一起，结果哪个层面都没讲清楚。

图之所以“看不懂”，通常不是读者理解力不够，而是信息结构没有设计好。画图的第一步，不是“我要表达什么”，而是“读者需要从这张图里拿走什么结论”。

1.2 图的第一任务是“让观点显形”

图不是数据库转储，不是为了把所有事实都摆放出来给别人慢慢看。图的最大价值，是把一个本来要靠大段文字才能说清的结构关系，压缩成一眼就能接住的信息。

举个例子。给订单系统画流程图，你脑子里可能有几十个节点：下单、拆单、库存扣减、支付、回调、超时关单、退款……如果全部画出来，这张图一定臃肿。但如果你问自己“这张图要支持什么讨论”，答案就清楚了。如果是讨论“超时未支付关单”这个异常链路，那主流程只需要一条很粗的方向，剩下注意力全部放在超时检测、状态扭转、补偿操作上。读者看完能立刻抓住这次改动的核心，而不是在一个庞然大物里自己找重点。

所以我在动手前一定会把这句话写在便利贴上：这张图存在的理由是什么。写在屏幕边缘都可以，画着画着发现偏了，就拉回来。

1.3 区分记录图、决策图、表达图

按使用场景，我习惯把图分成三类，它们的设计目标和维护方式都不一样。

• 记录图：目的是完整保留系统当时的真实结构，细节可以非常多，甚至可以像说明书一样。它放在项目文档附录里，不追求一眼看懂，但追求准确、可追溯。
• 决策图：目的是在一个讨论现场帮大家对齐输入、输出、分支和取舍。这种图必须小，最好一张图只容纳一个决策点，字可以稍微多一点，但绝不允许把多个决策塞进同一张图。
• 表达图：目的是讲给不在场的读者听，比如新人培训、方案评审、对外分享。这种图最考验叙事能力，它要有明确的主线，初始信息要少，必要时用分图推进。

同样是画订单流程，给生产环境排障用的记录图，和给新同学培训用的表达图，完全可以画成两张完全不同的图。很多人只画一张“万能图”，结果就是每个场景都不好用。

这个分类帮了我很大的忙。以前我总想把所有图都维护成“永不腐烂”的交付物，压力很大。后来想通了：只要图还在支撑某个讨论，它就是有价值的；讨论结束后，该归档归档，该删除删除。

2. 图类型选型：别把状态图硬画成流程图

“图表”是一个很宽泛的词。你打开绘图工具时，第一件事不是选模板，而是确认业务问题的本质结构是什么。选错类型，后面画得越工整，读者越糊涂。

2.1 流程图与泳道图：先分清“事情按什么顺序发生”和“谁负责什么”

流程图是最常见、也最容易用错的类型。它的本质是表达一组活动在时间上的先后顺序，核心符号只有三种：圆角矩形表示开始/结束，矩形表示处理动作，菱形表示判断分支。很多人的错误是恨不得把矩形、菱形、文档、数据库符号全用上，结果读者先要记忆一套符号系统，才能理解内容。

当流程涉及多个角色或系统时，我会升级成泳道图。泳道图跟流程图的区别，是把参与方按泳道分开，每个动作落在对应泳道里。这样“谁在什么阶段做什么事”一目了然，比在流程图里给每个节点标“由订单中心负责”清楚得多。

我在实际画图中发现，凡是跨三个以上系统或岗位的流程，都值得先问一句：要不要用泳道图？因为跨系统流程的沟通常常发生在“交接点”，而交接点刚好就是泳道的边界。泳道列出来，交接的两个节点天然地在视觉上相邻，矛盾就藏不住了。

2.2 架构图与部署图：别把层次结构和运行环境混着画

架构图表达的是系统的逻辑结构，比如前端、网关、业务服务、数据存储之间的调用关系。它更像一张城市的“功能分区图”。部署图表达的是这些逻辑组件实际跑在哪台机器、哪个环境里，更像“具体哪栋楼在哪个街道”。

这两类图经常会出现在同一份方案文档里，但它们是不同视角。把逻辑架构和服务节点画在一张图里，短期内看很全面，长期看非常难维护。某层服务一扩缩容，部署图位置全变，逻辑架构图的调用关系却完全没变，强行塞在一起，一次小变更就要重画整张图。

我现在的做法是：一张架构图只画逻辑分层和调用关系，部署环境、实例数量、中间件地址这些信息放到单独的部署章节里去。图不是越全越好，而是每一张图都要有自己清晰的服务边界。

2.3 状态图与时序图：抓住“状态流转”和“消息顺序”的本质差异

状态图适合描述一个对象在生命周期里经历的所有状态，以及触发状态迁移的事件。它特别适合订单、工单、设备、账号这类有明确生命周期的业务对象。

时序图关注的则是多个参与者之间按时间顺序发送的消息。它回答的问题是“在某个场景下，谁调了谁的哪个接口，顺序是什么”。两者的差别，一句话总结：状态图关注“一个对象变成什么样”，时序图关注“一组对象做了什么”。

选择时有一个小方法：如果你想画的图里，每个节点旁边都要写“当……时，转入……”这种描述，那大概率是状态图；如果你想画的是横向的一条条生命线，上面飘着请求箭头，那应该是时序图。把状态图硬画成流程图，会让状态之间的复杂转换变得极其啰嗦。

2.4 选型速查表

这张表不是标准答案，但能解决我大部分“不知道画什么类型”的纠结。选型对了，设计工作就成功了一半。

3. 设计原则：把信息层次做出来，而不是把图填满

定好类型之后，进入真正的 diagram-design 环节。这时候最该操心的不是哪个颜色好看，而是图上信息的层级关系。原则其实就一句：让读者第一眼看到最重要的东西，第二眼理解结构，第三眼才去看细节。

3.1 先定阅读顺序，再用粗细引导视线

人眼扫图是有自然路径的，中文环境下一般从左到右、从上到下。所以主干流程尽量按这个方向布置，分支和异常路径再想办法放在次要区域。

我会把“主路径”的线宽加粗到 2px 或 3px，分支线保持 1px。这样离远一点也能看清“故事主线”在哪。这个方法成本极低，收益立竿见影，尤其是跨屏展示的时候，粗线是唯一还能被抓住的东西。

节点的编号也能极大改善阅读顺序。比如主流程从上往下走，节点标成 1、2、3，分支节点标成 3a、3b。读者即使不看线，也能根据编号重新拼出顺序。这在打印出来、黑白展示的时候尤其有用。

3.2 分组与对齐：空间上的靠近就是逻辑上的亲近

图里没有物理意义，但有空间暗示。离得近的节点，读者默认它们属于同一组关系。所以设计时要主动利用空间位置来表达“哪些元素是同一个域”。

• 属于同一模块的节点，用一个大圆角矩形框起来，模块名称写在左上角。
• 不同分组之间保持明显间距，留白不是浪费，是分隔。
• 同一层级的节点，对齐比绝对正确更重要。能上对齐就上对齐，边界能靠齐就靠齐。

一个我之前常犯的错，是只分组不命名。框画了，但不说这个框代表什么，读者还是要靠猜。现在我会强制自己给每个分组写一个不超过六个字的标题，比如“支付域”“数据层”“外部依赖”。写不出标题的分组，说明分组本身没有意义。

3.3 颜色和样式的克制：最多三种主色

我见过一张架构图用了红、橙、黄、绿、蓝、紫六种纯色，每个元素一种颜色，作者可能是为了区分不同系统。但读者记住的感觉只有两个字：花哨。

颜色应该用来表达“同一个维度下的差异”，而不是东一榔头西一棒子地装饰。比如用三种逻辑色：蓝色统一表示业务系统，灰色表示外部依赖，橙色专门高亮本次要说明的模块。其他辅助信息全部用黑白灰。

同一种元素永远只用一种样式也很重要。所有“服务节点”都用矩形+蓝色填充，所有“外部系统”都用圆角矩形+灰色边框，所有“数据库”都用圆柱形。一旦定了规则，整张图里不能有例外。样式就是图例，风格混乱等于图例失效。

还有一个小提醒：不要把颜色作为唯一的信息编码方式。色弱读者、黑白打印、夜间模式的读者都看不懂“蓝色表示正常、红色表示异常”这种设计。重要的区分条件，要同时用线型、粗细或者文字来表达。

3.4 文字标注与图例：能放链接放链接，不要写论文

节点上的文字应该短，最好只是一个名词，比如“库存服务”“消息队列”。必要的补充说明放到备注区，或者做成文档里的链接。图上塞大段文字，图表应有的“一屏概览”功能就丧失了。

如果图上用了特殊符号，比如虚线箭头表示异步消息、实线箭头表示同步调用、菱形表示判断，请在图例里写清楚。图例放在右下角，字号比正文小一号，用最朴素的文字描述，不要画蛇添足。

一图一义，图例两三行足够。如果图例超过五行，说明这张图用了太多特殊符号，先考虑简化。

4. 从草稿到交付：一套可以抄走的diagram-design工作流

很多人的画图流程是：打开工具，边想边画，哪里不对改哪里，画完立刻导出。这个流程最大的问题是没有“草稿评审”环节，导致正式图反复涂改，越改越乱。我现在的工作流分四步，前两步根本不用绘图软件。

4.1 先用纸笔或白板做无样式草稿

我强烈建议先在草稿纸上画可能的模块框和箭头。这个阶段不选颜色、不对齐、不美化，唯一的任务是确认信息结构。你会很清楚明自身的信息流是什么，模块之间的依赖是什么，哪里断线了。

这一步最关键的问题逐条问自己：“读者要做什么决策？”“这个分支是主流程必须的吗？”“删掉这个节点，图还成立吗？”信息结构在这个阶段调整，成本几乎为零；等到了绘图软件里再调整，光是重新连线和对齐就够烦了。

如果团队在一起，白板是神器。几个人边画边聊，能当场发现很多“我以为你知道了，其实你没说”的盲区。草稿不满意，直接擦掉重来，没有任何心理负担。

4.2 识别主路径，决定“分图还是合图”

草稿阶段结束后，我会拿笔把主路径描一遍。这个动作的价值，是逼自己明确图里哪些线最重要。

如果主路径已经复杂到需要“描线五分钟”，我就直接拆图。拆图策略通常是：主图保留骨架，细节分支单独成一张局部图，局部图通过编号回链主图。宁可用三张简单图解释清楚，也不要一张巨图让人放弃理解。

很多读者会担心拆图后失去上下文。我的解法是在主图里用一个高亮节点标注“详见图 5-2”，局部图开头也反标所属主图。这样可以来回跳读，并不会迷路。

4.3 进入工具，先搭结构再调样式

草稿确认后，再打开绘图工具。这一遍我按固定顺序操作：拖入全部节点框，不连线；按草稿布局摆位置，只保证分组和大致对齐；然后再连线，线走最短路径，不在中途拐弯；最后才统一字体、颜色、粗细。

这顺序分明是因为连线过程中会影响对空间的感知。先摆盒子，你能看清整体密度，知道哪里需要压缩、哪里需要留白。我就吃过很多次亏，先在工具里连好线，再动布局，结果线全部打结，只能重连。

4.4 自检与10秒测试

图定稿后，我会运行一个“10秒测试”：找一位不了解原理的同事，只让他看图10秒，然后说出三个词。如果他说的词里有“乱”“看不懂”“不知道看哪”，这张图必须返工。

再做一个静态自检清单对照：

• 主路径是否可以通过线宽或编号立刻识别？
• 所有框都有清晰标题，没有“模块1”“组件2”这类占位名？
• 虚线、实线、箭头、特殊符号是否都有图例？
• 颜色是否克制？能不能在灰度模式下无损阅读？
• 源的注释信息是否保留在文档而非图内？

这套自检花费不到三分钟，但每次都能发现一两个之前没注意的问题。

5. 工具选型：图形编辑器、代码生成还是白板式协作

做图不能只靠一个工具走天下。因为图的用途不同，生命周期不同，团队协作方式也不同。这一节我聊聊当前比较常用的几类方案，以及我是怎么搭配使用的。

5.1 图形编辑器类：适合精细排版的交付图

这类工具包括 draw.io、Excalidraw、Figma、Lucidchart 等。它们的优点是所见即所得，布局完全可控，适合做正式交付图、架构图、对外表达图。

我个人在“正式架构图”场景更倾向 draw.io，它免费、支持离线、源文件可以进 Git 仓库，而且模板比较全。Excalidraw 适合画手绘风格的快速图，松弛感强，适合想法整理和内部讨论，但精细排版能力弱一些。

这类工具的代价是：源文件和导出图容易出现两份不一致的情况。我给出的心法是：源文件必须和导出图保存在同一目录，文件名一致，后缀区分。否则三个月后你会面对一堆 PNG，根本无法编辑。

5.2 代码化图表：适合嵌进文档和版本管理

文本描述式图表工具，比如 Mermaid、PlantUML，是用代码文本表达图表，然后渲染成图。它们的核心优势不是“免费用”，而是“可版本化”。

图的内容以文本形式存在，随代码一起走 Git，Review 时可以按文本 diff 看到底改了哪个节点；文档里内嵌代码块，渲染结果自动同步，再也不会出现“文档里的图已过期三个月，源文件却找不到”的悲剧。

代价是布局不受控制。文本引擎会自动排布节点，复杂图的布局经常不尽如人意。所以在多节点、强定制场景下，我仍会用回图形编辑器；简单流程、状态图、时序图，我几乎都用文本化方案。Mermaid 语法形如 graph TD 加节点和箭头的描述，学习成本很低，但别指望它能替你设计信息层次。

5.3 白板式协作工具：适合脑暴和评审

在线白板，比如 Whimsical、Miro、Figma Jam 这类，适合多人实时协作。做中期评审时，大家直接在图旁边贴便利贴、画箭头、发评论，效率比“截图到群里提意见”高很多。

白板图的缺点也明显：信息往往很乱、很临时。东西越多越难维护，所以我的策略是：脑暴用白板，一旦讨论收敛，立刻把最终结论重画成正式交付图，绝不直接在草图上“整理格式”。草图的生命周期就应该是短暂的，整理过后的图才进文档。

5.4 我的组合推荐

工具选型本来就很看团队习惯，没有标准答案。但有一个底线：任何一张“要长期维护”的图，源文件必须放在团队能访问、能版本管理的地方。如果团队协作靠把 PNG 传来传去，那再好的工具都救不了。

6. 案例拆解：一张订单处理架构图的完整设计过程

前面讲了不少原则，这里用一个我实际做过的模拟项目案例，把流程从头到尾走一遍。项目背景是某团队要对现有订单处理逻辑做重构，我需要画一张图，让刚加入的三位同学在最短时间里理解系统全局。

6.1 先问清楚：这张图到底给谁看、回答什么问题

我一开始的想法是画一张“订单系统全景图”，把下单、支付、履约、售后、对账全画进去。但实际聊下来，新同学最需要的不是全景，而是对“一笔订单从创建到完成，经历了哪些核心阶段，每个阶段由哪个模块负责”的认知。

所以图的定位被锁定为“订单主流程架构图”，它回答的问题只有一个：一笔正常订单如何流经各个服务。至于异常补偿、对账差异、异步重试，这些不在主图范围内。

这一步的结论写下来，整张图的所有取舍都有了依据。后面再有人问“怎么没画退款”，我可以明确回答：那张图专门负责退款，主图不承担这个信息。

6.2 纸上草稿：先只画大框

我在白板上写了六个词：订单入口、校验库存、支付、履约、通知、完成。连接顺序是一笔订单常规路径。画完一看，这六个框只描述了一个理想世界，真实系统里每个环节都可能有分支。

我决定，分支细节不在主图出现，而是用“拆图”解决。第一张主图画六步主流程；第二张图画“支付异常处理”；第三张图画“履约取消与退款”。三张图的分工就清晰了。

这一步的启发：不要在草稿阶段追求“涵盖所有真实情况”。如果一张图的草稿需要靠分支把每个角落都填满，请直接拆图。

6.3 细化节点，砍掉视觉噪音

定位三张图之后，我逐一给节点起名。主图节点叫做“订单校验”“库存扣减”“支付网关”“履约调度”。每个节点名控制在四到六个字，不写“调用库存中心进行库存可用性判断”这种长句，长句全部放到图的备注里。

样式规则：主流程节点统一蓝色填充、白色文字，外部依赖统一灰色；支付网关节点因为这次重构要重点改造，我用橙色高亮。图例放在右下角，三行讲完。

配色定完才发现，当时我第一个版本用了四种颜色，后来统一压缩成蓝灰橙三种。再加上主流程线宽加粗，整体图面立刻干净了很多。

6.4 交付前评审：看图的人能复述主流程吗

我拿三张图分别找了团队成员做10秒测试。主图反馈基本准确，但第二张支付异常图有个问题：线上红字写了“重复回调幂等处理”，读者却找不到“回调消息从哪里来”。后来我补了一条虚线，并更新了图例说明，问题就消失了。

最后导出时，主图用 PNG 嵌入文档，源文件放进了 SVN 对应的 diagrams 目录。文档里主图下面放了一句话：“主图更新请同时修改 diagrams 下的源文件”。这样后续有人想改，也不会对着死图发愁。

整个案例说明一件事：一张好图不是“画出来的”，是“剪裁出来的”。剪掉的信息越多，留下来的信息越有价值。

7. 实际维护中反复踩的坑与我的解法

再好的设计方法，在真实维护环境里都会遇到阻力。这一节写的是我在项目里反复踩过、也逐步找到对策的坑。

7.1 图的版本管理：源文件和导出图的“两跑”

图的最大坑不是画不出来，而是画完之后三个月，图已经与现实不符，却没人发现。原因多半是：源文件不知道丢在哪里，PNG 已经贴进文档，于是修改成本极高，大家都选择不修改。

我的解法是：一张图必须有一个可编辑的源文件，源文件路径写进文档页脚；能存版本库的尽量存。代码化图表天然规避这个问题，所以能在文档内嵌的简单图，我全部改用代码化方案。

7.2 没人指定“维护人”，图一定会腐烂

比版本管理更隐蔽的坑，是责任缺失。团队里每个人都可以改文档，但最终没人对该图负责。过了一段时间，任何人看到过时的图，都不知道该找谁去更新。

给每张重要图表指定一个明确的维护人，这个维护人不一定是绘图的原作者，但一定要是当前最了解该系统变化的人。我一般在图下加一行“维护人：某某”。换人维护时，顺手改掉这行文字。

7.3 什么都要画的冲动

有一段时间，我觉得任何逻辑都可以图解，所以把所有方案文档都塞满图，结果是文档体积翻倍，读者的负担也翻倍。后来才意识到，图适合表现“结构关系”和“时序关系”，而纯粹的规则列表、参数对比，用表格反而更清晰。

现在我的判断标准是：如果一段信息用三行文字能讲清楚，而画图要加框、连箭头、配图例，那就写文字。图贵精不贵多。

7.4 嵌入文档时的尺寸与分辨率

很多人画图时只盯着画布，导出一张超宽 PNG，塞进文档后拉伸得模糊不清。我常用的做法是：正式文档里导出 SVG；在不支持 SVG 的场景，导出 2x 分辨率的 PNG；并顺手控制图片宽度不超过正文阅读区域。

还有深色模式的问题。有些团队文档支持深色主题，如果你的图底色是白色、白色框、白色文字，在深色模式下会非常刺眼。我会在交付前检查一下图在深浅两套主题下的效果，至少保证文字可读。

这几个坑没有特别高深的技术含量，但由于它们每天都在消耗团队心智，解决它们带来的顺畅感，有时候比改一个 bug 还明显。

最后再分享一个我自己的习惯。现在每拿到一个绘图需求，我不会第一句就问“用什么工具”，而是先问：“这张图要回答什么问题？”这个问题回答不出来，我不会碰画布。回答得出来，后面每一项设计决策——选类型、定层级、配颜色、拆图还是合图——都有了明确的判断依据。diagram-design 说到底不是“画得好不好看”的手艺，而是“想清楚了没有”的思考方式。你下次画图前不妨也先问自己一遍，说不定能省下不少返工的功夫。