企业官网建设流程全解析

我见过太多张在评审会上被反复质问的图。质问通常不是因为图丑，而是因为没人看得懂。所以在聊 diagram-design 之前，我想先把一个反直觉的结论放在前面：图表设计最重要的从来不是配色、不是工具、不是炫酷的立体效果，而是信息架构——你把哪些节点画在一起、哪些连线可以省掉、读者第一眼看到什么，这些才是一张图真正成败的地方。

diagram-design 直译过来是图表设计，但认真做这件事的人都知道，它是一套从需求判断、类型选型、布局规划到视觉规范的工作流。它能解决的问题非常具体：为什么图画了一大堆却没人看、为什么评审时每个人指的节点都不一样、为什么同一张图换个读者就完全失效。适合读这篇内容的人，不限于工程师——产品经理、架构师、技术写作者，以及所有需要用图把复杂事情讲清楚的人，应该都能找到可以直接套用的方法。

1. 图失败的真实原因：不是审美问题，是信息架构先错了

每次有人拿着图来找我帮忙"调好看点"，我基本都会先问一句：这张图是给谁看的？十次里有八次，对方会愣住。这就是问题所在——大多数图压根没想清楚自己的读者是谁，就忙着往画布上堆内容了。

1.1 三个高频翻车现场

第一个翻车现场，叫做"信息过载"。我见过有人画系统架构，把数据库表字段、缓存键设计、日志文件路径全部塞进一张图里，节点超过三十个，连线纵横交错。画的人很满足，觉得我把真相都给你们了。但看的人需要的是"能指导行动的图"，不是一个静态的存档全集。评审时所有人都在追问各种边缘细节，核心的决策问题反而没时间讨论。

第二个翻车现场，是"语义混乱"。所有节点框大小一样、颜色随便选、实线虚线轮换着用、箭头方向全看心情。读者被迫花精力做解码工作：这个颜色到底代表什么？这个箭头是数据流还是调用关系？同一个信息层次，你用了三种样式来表达，读者会以为它们有三种含义。信息架构要求"一致"，不是要求"丰富"。

第三个翻车现场，是"没有边界"。"孤儿节点"四处可见——一个孤零零的方块悬在画布角落，没有进入箭头也没有输出箭头；或者一条虚线指向空白，让人不知道它还连着什么东西。这说明画图的人自己对结构的理解也没闭环。图里暴露的含糊，往往是思考本身的含糊。

把这三种现场叠在一起看，根子只有一个：图被当成了"画布涂鸦"，而不是被当成一个需要设计的信息产品。

1.2 图的四种职能：先搞清楚这张图是干什么的

我习惯把一张图的职能分成四类，不同职能对应完全不同的画法。

第一类是"梳理想法"。这种图是画给自己看的，出现在你刚开始思考某个问题时。它的目标是用箭头把碎片串起来，让你看到结构。这种图不需要美化，甚至越丑越说明你在真实思考。第二类是"沟通协作"。这种图给团队或者客户看，目标是达成共识。它需要明确边界、完整图例、最少必要信息——三者缺一不可。第三类是"记录留存"。这种图给未来的维护者看，可能是半年后接手你工作的同事。它的核心要求是稳定，接口变化时能不能快速更新，版本号有没有写清楚。第四类是"辅助决策"。这种图给决策者看，重点是结论、风险、路径，而不是一堆内部技术细节。

我在实际项目里经常发现，六成以上的图根本不需要画成"成品"，停留在第一类就够了。很多人把草稿阶段的图硬生生打磨成作品，还拖慢了项目节奏，这是最隐蔽的浪费。所以动手之前，先用一个轻量的问题校准一下自己：这张图发出去之后，别人要有能力做什么？如果答案是"看一眼就懂"，那它就是沟通图；如果答案是"照着实施"，那它就是规范图；如果答案是"以后查资料用"，那就得带版本管理。不同答案，画的详略完全不同。

2. 选型：拿到需求先别开画，先回答三个问题

工具和模板容易让人变懒。很多人打开软件的第一反应是从模板库挑一个最接近的，然后往里填内容。这是一种很危险的启动方式，因为它跳过了最关键的思考环节：我要表达的到底是什么。我的建议是，动手前先把三个问题写在纸面上。

2.1 给谁看、在哪看、看完要做什么

第一个问题：给谁看。读者决定详略和抽象层次。给研发看模块划分，你需要的是服务边界和依赖关系；给运维看部署拓扑，你需要的是故障域和流量路径；给管理层看方案全景，你需要的是成本和风险，而不是类名和接口名。同一套系统，至少三种不同画法，这太正常了。

第二个问题：在哪看。是投在会议室大屏上，还是塞在文档里？是发到 IM 群里被同事用手机翻，还是打印出来贴白板？我见过不少设计精美的图，字体小到手机屏幕根本看不清，在大屏上也勉强。每个呈现场景都有自己的阅读约束，选型时必须提前考虑。

第三个问题：看完要做什么。这是最容易被忽略的。如果读者看完需要批准这个方案，你的图要有清晰的层次，让他可以在五分钟内抓住结论。如果读者看完需要动手写代码，你的图就要有足够的边界信息，节点之间不能有模糊地带。如果读者只是路过扫一眼，那你连图例都可以省掉，重点只留一句话的视觉冲击。

2.2 常见的图类型速查

下面的表是我这些年用得比较多也比较顺手的选型参考，你可以直接抄走贴在手边。

选类型的原则不是越专业越好，而是越贴近读者的心智模型越好。给业务方看流程，流程图天然比时序图友好；给数据库负责人看表结构，ER 图天然比架构图精确。你的读者脑子里本来用什么方式组织这件事，你就用对应的图型去匹配它。

2.3 一句话判断选型有没有错

我自己有一个很灵的判断测试：画完或者画到一半时，把图拿给一个没有参与过这件事的人，让他看十秒钟，然后请他说出"这张图在讲什么主题"。如果他支支吾吾，或者指着一个角落说"这块好复杂"，选型几乎肯定出了问题——要么类型不对，要么一张图塞了太多件事。

还有一种更隐蔽的错：选型没错，但图的复杂度远超预期。你明明画的是流程图，画到一半发现需要表达并发和不确定性，流程图画了整整一屏还是说不清。这时候别再硬撑了。正确做法是把这一张图拆成一张主图加若干子图，主图保留主干判断，子图承接异常分支。很多图不是画砸的，是"贪多"撑爆的。

3. 布局、连线和视觉层级：diagram-design 的排版学

选对了图类型，只是骨架对了。下一层要处理的是排版——节点放哪里、连线怎么走、怎么引导读者视线。这一层做得好的图，读者几乎不需要思考就能顺着视觉走下去；做得不好，读者视线在画布上无规则乱跳，看三遍还记不住结构。

3.1 布局第一原则：最小交叉，第二原则：单向流向

很多懂设计的说法是"画面要平衡"，但我做 diagtam-design 这么多年，体会最深的第一原则其实就四个字：最小交叉。为什么？因为人的阅读是线性的，交叉的连线会强迫视线来回跳跃。你可以想象自己在走一条路，路上到处是十字路口和天桥，你走三步就要停下来判断方向，很累。图的阅读负担大半来自连线交叉。

要做到最小交叉，最直接的手段是改变布局而不是改变连线。两个强关联的节点，先检查它们是不是隔着大半个画布。如果是，应该把它们挪近，或者用一个容器把它们垒在一起，连线自然就短了。画主干时尽量从左到右、从上到下，比如流程图就按"S 形"排布，第一行从左到右，第二行从右到左，这样视觉距离最短。

第二原则是单向流向。图里的主导方向最好只有一个：数据流、调用链、时间轴都要尽量保持同向。如果一张图里既有从左到右的调用，又有右下到左上的回调，读者会非常累。我在现实项目里如果发现反向连线冒出来好几条，第一反应不是调线，而是反思这张图是不是漏了一个层级。很多"反向箭头"本质上是"我该画子图了"的信号，别硬怼在一个平面上。

3.2 线型、箭头和颜色，先约定再动手

很多没受过训练的"随手画"会把线型和颜色变成装饰品：心情好用实线，随手换成虚线，再给某个要突出的节点加个荧光色。这样读者根本不知道线型之间是否有区别。正确做法是先约定语义，再动手画。我常用的约定很简单：实线代表强依赖或直接调用；虚线代表弱关联、异步通知或可选路径；单向箭头表示调用或数据流向；双向箭头表示消息往返或协同调用。

颜色比线型更容易失控。我见过一个同事画的架构图，一张图用了十一种颜色，每个模块一种，结果整张图像彩色迷宫。我的经验是：一张图里同时出现的填充色控制在三到五种。其中一种色做主要模块的背景，一种色做关键链路的高亮，一种色作为警示或异常提示，剩下的模块全部交给灰度。这就像穿衣服，全身不超过三个颜色，形象反而最清晰。

另外，不要只靠颜色传递信息。色盲用户在人群中占比不低，黑白打印的场景也经常出现。所以高危模块最好同时用"高亮色 + 虚线边框 + 文字提示"三重表达。我在汇报材料里经常要出黑白版，这一条救过我好几次。

3.3 视觉层级：让读者一眼找到重点

视觉层级是一张图的阅读节奏。我的通常做法是先定五个大家闰层级：容器标题大于主节点，主节点大于子节点，子节点大于说明文字。字号、边框粗细、背景填充这三样东西把层级立起来。

容器标题用最大字号，比如十六像素加粗；主节点用十四像素加粗、带淡淡的填充色；子节点用十二像素常规、白色背景；说明文字用十到十一像素灰字。边框粗细也一样：容器边框两像素，主节点一像素，子节点可以更细甚至只靠背景分区。这样读者扫一眼就知道，大框是模块边界，深色块是重点对象，浅色块是支撑信息。

留白同样重要。很多丑图不是因为信息太多，而是因为节点间距太近，整个画布闷成一团。我会保证同组节点之间的间距至少等于节点高度的一半，不同模块之间的间距再翻一倍。模块之间越疏，边界感就越强。这也是为什么分组建模远比逐节点调整位置省力——先调组间距离，再微调组内位置，顺序对了效率翻倍。

4. 从草稿到成图：我自己走顺的一整套工作流

聊完设计原则，得说说怎么落地。我见过太多人直接用工具开始画，然后在一个下午里反复拖拽对齐、改颜色、调线形，最后画出一张逻辑仍然混乱但配色很漂亮的图。问题出在哪？出在跳过了草图阶段。

4.1 先画草图再上工具，逻辑先于美观

草图阶段我推荐用纸笔或者白板，而不是专用的绘图软件。原因很简单：绘图软件的工具面板会持续吸引你的注意力，让你忍不住去调整框的大小、对齐、配色，结果你的大脑资源全被视觉任务占用了，逻辑思考反而不充分。纸笔没有这些干扰，你只能潦草地写节点名字、画箭头，丑没关系，结构对了才是目的。

我做复杂架构时，会先在纸上列一遍节点清单，然后确定分组。通常分组做完，一张图的骨架已经定了一半。接着用箭头把关系连一遍，如果发现某个节点有三四条外部依赖，它大概率应该被拆成多个小节点，或者挪到另一个分组里。草图阶段不要恋战，十五分钟足够了，否则你会陷入细节推演。目标是得到一个"即使画得很乱，旁人也能听懂你在讲什么"的骨架。

然后才打开绘图工具。这时候你会发现自己快得惊人，因为你只是在誊清，不是在创作。我见过很多所谓的"绘图很慢"的人，真正原因其实是逻辑没想清时就开始对齐坐标了。这个顺序一换，效率差好几倍。

4.2 三类工具的取舍，不用纠结太多

工具没有绝对的好坏，只有适配的场景。我把常用工具粗分成三类，你对照场景挑就行。

第一类：在线协作白板。优点是多人实时编辑很顺畅、适合评审和远程会议，门槛低。缺点是画布一大就卡，导出格式往往不多。这类工具适合项目前期的头脑风暴和交互式评审。第二类：开源桌面绘图软件。功能全、模板多、能导出 SVG、PNG、PDF 这些通用格式，最关键的是对复杂大图的支持稳定。缺点是多人协作弱一些，需要每隔一阵子手动同步。这类工具适合正式交付的架构图、ER 图等最终产物。第三类：文本生成图表的工具。你维护一段描述节点和关系的文本，让工具渲染成图。最大好处是可以放进代码仓库做版本管理，跟着代码一起变更，最适合长期维护的架构图、时序图和状态机图。缺点是布局控制能力弱，复杂图很难精细调表达。

我的取舍逻辑很简单：需要快速碰撞想法，用在线白板；需要正式对外交付，用开源桌面软件；需要跟着代码走的图，用文本渲染工具。三者不是竞争关系，而是同一个工作流里不同阶段的搭档。

4.3 交付前的检查清单

图画完不等于能发出去。我建议你养成一个习惯，发图之前照着下面这份清单过一遍，整个过程十分钟以内。

• 有没有孤儿节点？孤立方块必须删除或补充关联。
• 有没有悬空箭头？箭头指向空白是极大的阅读伤害。
• 同一层级的信息，样式是否统一？不同层级的信息，样式是否拉得开？
• 图例是否齐全？颜色、线型、箭头方向的含义要写清楚。
• 字体是否过大或过小？按大屏和手机两种屏幕分别检查一遍。
• 能否经受住黑白打印的考验？灰度下重点还能不能看出来。
• 导出格式是否满足使用场景？网页用 SVG，正式文档用 PDF，图片分享用高分辨率 PNG。
• 是否写明了版本和时间？作为长期资料保存的图，这是必填项。

这份清单是我吃过亏以后总结出来的。有一回我把一张精心绘制的架构图导出成 PNG 放进方案文档，结果会议室投影一放大全是锯齿，所有文字边缘有毛刺。后来我固定用 SVG 做演示，用高分辨率 PNG 做分享，再没翻过车。

5. 一次真实复盘：一张系统架构图从 v1 改到 v6

前面讲的都是方法，可能不如一个完整案例直观。这几年我改图改得最多的一个场景，是某个内部系统的架构图。它从第一版到最终版本经历了六次修改，里面有典型的踩坑过程，也有一条清晰的变好路径。

5.1 v1 的问题：信息太全，等于没说

第一版几乎是灾难。当时我为了"把系统讲完整"，把服务、数据库、缓存、消息队列、定时任务、日志文件、外部依赖全画进了一张图。节点超过三十个，连线粗算一下也有五十多条。最左边还列了数据库表清单，右下角加了日志路径说明。

评审会开了二十分钟，前十五分钟大家都在追问仓储字段为什么这么建模、某个日志文件在哪个路径、为什么缓存键设计成这样。真正需要评审的服务拆分方案反而没有机会深入。事后我自己复盘，问题本质不是"图画得不好看"，而是我没有在画之前回答那两个问题：给谁看，看完要做什么。这张图当时该服务的是"决策评审"，而不是"全量真相存档"。

5.2 中间版本：开始做减法，但视觉失焦

第二版我大幅删了细节，数据库字段、日志路径全部拿掉，节点降到十八个。这次评审顺利了很多，但又暴露出新问题：所有节点大小一样、层级扁平，核心链路和其他路径的颜色差异太小，读者每看一次都要从头到尾重新扫一遍才能找到重点。

更麻烦的是没有做容器分组。服务之间的边界要靠连线去猜，有的模块明明是一组，在图上却散落各处。有位同事当时直接说："这张图我只看得出有很多方块和线，但哪个是入口、哪个是依赖，我得找半天。"这就是典型的视觉层级缺失。我在那个版本之后，才把"容器边界"这四个字当成一等公民来对待。

5.3 最终版：分层表达，一图一主题

最终版的核心改动，是拆图。一张总览图讲清楚全局，三张子图分别承载服务细节、数据依赖和部署关系。总览图从上到下分成入口层、服务层、数据层、支撑层，入口层的对外服务端放在最上，服务按调用关系横向排列，中间件统一收进支撑层，数据库放在数据层。然后用一种强调色标出主链路，其余路径全部用灰色弱化。

这一版评审的效率高到出乎意料：大家先花五分钟看总览，立刻定位到"这里是入口、这里是核心链路、这里是数据依赖"，然后按需要下钻到对应子图。我自己刚开始画的时候很舍不得拆图，觉得一张图很完整很爽，但拆完之后才想明白：图的分层就是代码的分层，职责不清，拆分就会出问题。

6. 一些文档里写不出来的图表细节

原理和工作流都讲完了，最后补充几个散落在日常实践里的颗粒。这些细节很难从官方文档里学来，但每一条都帮我避过不少坑。

6.1 节点命名、主键和标注，把它们当代码写

图纸上的节点名称和代码里的变量命名一样重要。我的规范是：节点名用"对象/职责"的方式，比如"订单服务""支付回调"，尽量避免只有一个穷人式的缩写"PO""TO"之类，除非团队统一维护了缩写表。多张图里会重复出现的节点，命名前缀要一致，否则读者会怀疑自己是不是看漏了。

跨图引用时，最好给每张图加编号，子图被主图引用时也把编号写进去。比如主图某个容器右下角标个"[S-01]"，下面注释里再写"详见子图 S-01：订单异步处理链路"。这个习惯相当于给图做了交叉索引，和代码里跳转函数定义一样，非常提升可维护性。最后，版本号写在标题右下方，变更日期一起标注。别小看这两行信息，半年后你自己都会忘记哪张图是最新的。

6.2 导出、字体与打印场景的适配经验

这部分容易翻车，但很少被留意。首当其冲的是字体。有些桌面软件在你电脑上显示得很好，换一台机器打开文件就乱码，通常是因为字体没有嵌入。如果交付场景是发给别人编辑，一定要在导出设置里勾选"嵌入字体"，或者干脆选择跨平台的开源字体。中文混排时这个问题尤其明显，常见宋体、微软雅黑在目标机器上不一定存在。

其次是背景。很多人画图默认白色背景，但如果图要放到深色主题的网页或演示文稿里，白色背景会突兀得像贴了一块补丁。正确做法是按场景调整画布背景，或者导出透明背景的 SVG，到目标环境里再设置。最后是打印测试。我强烈建议每张正式交付的图都做一次灰度打印预览，重点检查高亮色是否还有区别、浅色节点是否浅到看不见。截图分享时分辨率至少 150dpi，正式打印用 300dpi，千万别把网页预览级别的图直接丢进印刷稿件。

6.3 评审图的时候，用这几个问题戳穿薄弱环节

最后送你一份在图评审会上非常好用的提问清单。不管是评审别人的图，还是别人评审你的图，这几个问题都能快速暴露薄弱点：

• 如果这个节点挂了，哪些链路会受影响？这个问题能测出依赖表达是否完整。
• 这张图由谁维护？什么时候更新？没有归属的图，三个月后必成废图。
• 信息与当前代码、配置对得上吗？维护滞后是很多图失效的元凶。
• 图的边界是什么？哪些部分被刻意省略了？边界不清，读者的联想就停不下来。
• 新成员看图，十秒内能不能定位核心模块？如果可以，视觉层级基本及格。

我发现一个很有趣的规律：能回答好这几个问题的人，通常并不需要太华丽的绘图技巧，他在画之前的思考就已经决定了图的质量。

最后再分享一个我用了很多年的小习惯。每次图稿定稿或者评审完之后，我会强制做一次"删一半"练习——把不直接影响决策的节点、连线、颜色统统删掉。第一次删完心里会慌，觉得图是不是太简单了。但发出去之后往往会发现，读者不仅没觉得信息缺失，反而能在更短时间内抓住重点。diagram-design 的门槛从来不在工具和技巧，而在你有没有勇气做减法。从下一张图开始，你可以先试着把节点数量减掉三成，再让同事看十秒，看看效果会不会比你想象中更好。