企业官网建设流程全解析

diagram-design，说白了就是把复杂关系画成一张让人能看懂、愿意看、看完还能记住的图。日常里，我们叫它画架构图、画流程图、画时序图，但“画出来”往往只是最后一公里，前面还有一大半工夫是把要表达什么、给谁看、用什么层次呈现想清楚。这几年我没少画图，也从“能画出来”一路折腾到“画完别人愿意主动引用”，中间踩了非常多坑，尤其是团队协作、导出交付、组件复用这几个环节。这篇文章就围绕 diagram-design 的完整工作流，把我整理出来的做法和教训一次讲透。

适合谁呢？工程师想整理系统方案，产品经理想梳理业务流程，技术顾问想画咨询演示图，甚至只是想写博客配一张清晰示意图的人，都能拿它当一份实操参考。

1. 先想清楚再打开画布：diagram-design 的第一步不是工具

很多人画图的顺序是打开软件、拖几个框、连线、导出，我也是这么过来的。直到有一次，同事指着我刚画完的架构图问“这图到底想让我看什么”，我才意识到自己犯了一个习惯性错误：本末倒置。

1.1 这张图给谁看，看完要做什么

画图前最该完成的工作，是画“读者画像”。不同读者对图的关注点完全不同，指望一张图通吃所有场景，基本只会让所有人都觉得不清晰。

• 给项目决策层看，重点是全局。你得突出边界、成本归属、风险依赖，技术细节要尽量砍掉，带宽多少、数据库用不用读写分离，这些信息放在评审图里只会稀释重点。
• 给一线开发看，重点是协议。模块之间怎么调用、数据如何流转、失败补偿谁来兜底，最好精确到方法语义和关键字段，接口名都写模糊了，图再好看也落不了地。
• 给新同学看，重点是顺序。先看哪、再经过哪、最后到哪，最好配上数字标号或阶段色块，让他在五分钟内建立起“路径感”。

不要试图一张图满足所有读者。我见过最典型的翻车，是把网络层加密策略、数据库索引设计、消息队列重试参数全部塞进一张“整体架构”图，结果箭头密到看不出主链路。最后大家都只截取自己关心的局部，另外百分之八十的内容沦为干扰。

一个好的做法是，先写下读者身份，再补一句“希望他看完后做出的动作”。比如“看完后确认网关是唯一入口”“看完后能定位下单链路故障点”。一旦有了动作预期，信息取舍就有了明确标准——凡是跟这个动作无关的内容，都可以大胆删掉。

另一个容易忽略的点是：技术评审图和生产运维图的信息口径是不一样的。评审图可以表达方向感和理想态，但运维维护图必须与线上真实组件一一对应，连版本号都要标清楚。不少团队长期只用一张所谓架构图，评审和排障都拿它，改来改去最后谁都不信。这本质上不是绘图问题，而是信息口径问题，但正好需要 diagram-design 来纠正。

1.2 一图一主题，别把所有信息塞进一张画布

读者定下来之后，下一步是把这张图的主题收敛成一句话。比如“这张图表达登录链路的高可用设计”，而不是“用户系统全貌”。主题越窄，读者的记忆锚点越清晰，你的表达压力也越小。

分享一个我一直在用的方法：把本次涉及的所有名词全部列出来，然后做三分类——核心名词、支撑名词、噪音名词。

• 核心名词必须出现在主图里，比如用户的注册、登录、状态流转。
• 支撑名词可以用角标、图例或备注轻轻带过。
• 噪音名词直接删掉，哪怕它真实存在。

大多数人的问题出在舍不得删，总担心漏了细节会被挑战。实际上，被问到的概率远小于读者因为干扰而放弃看懂的概率。记住一句话：你删掉的东西，读者永远不会怪你；你堆上去又讲不清楚的东西，读者一定会默默降低对你的评价。

更笨但更有效的做法是：先在手边快速画三版“信息草图”。每版只写核心模块名和它们之间的连线，完全不管边框对不齐、颜色好不好看。第一版画完退后两步看，通常连自己都觉得逻辑乱；第二版开始出现明显层次；第三版基本能把真正的边界锁定下来。三版画完再打开绘图工具，后面会顺利非常多。

1.3 信息分组：用容器表达系统边界

早期画图，我习惯用一堆独立方块表示模块，再用同样粗细的箭头连接它们。图一复杂就变成蜘蛛网，调半天也没用。后来学到一招：善用分组容器。

容器是 diagram-design 里最有说服力的边界工具。用一个大的圆角矩形表示“接入层”，里面放网关、限流器、鉴权器，读者一眼就能看出这些模块属于同一逻辑单元。容器的语义必须严格统一：要么都代表部署边界，要么都代表逻辑分层，要么都代表团队归属，千万别一会儿表示进程、一会儿表示机房、一会儿表示部门。容器语义混用是高级翻车，比配色混乱还要难救。

把边界画清楚后，连线会急剧减少，你需要处理的只剩下“跨边界调用”，整张图的复杂度会瞬间下降一个数量级。这个经验和工具无关，纯属思维转变，但效果立竿见影。

2. 视觉规范与空间纪律：让图从“能看”到“好用”

信息结构对了，图还只是“草稿”，离专业交付还有一段距离。这段距离主要由视觉规范决定。我把它拆成三块：空间秩序、色彩纪律、形状语义。

2.1 网格、间距与对齐：专业图的分水岭

大家都希望画得快，但“快”和“乱”往往是双胞胎。想让图具备专业感，最省力的办法就是强制对齐。

具体操作并不复杂：打开软件的网格吸附，把网格粒度设置为 10 或 8 像素；所有同类节点采用同一尺寸体系，比如业务模块统一 240×80，中间件统一 160×80，外部依赖统一 200×80；节点间距至少留 20 像素，分组容器内侧留 24 像素以上，给文字呼吸空间。听起来机械，但试一次就能感受到，多花五分钟对齐，整张图的可读性会立刻提升一个档次。

这里还要强调一个视觉心理：同层级节点高度一致、上下间距一致，读者会产生一种“可信赖”的直觉。就像排版里字距和行距均匀，阅读就不费力。反过来，哪怕架构完全合理，画得歪歪扭扭，读者也会下意识怀疑设计者是否认真。

别小看这个细节，很多资深评审其实一眼就能看出“这张图有没有经过整理”。一份整齐的图，在评审还没开始读内容之前，就已经赢下一半信任分了。

2.2 颜色、线型与字体：越克制越高级

配色第一原则是少。一整张图，我通常限制在四个颜色以内：

• 主色承担核心模块，让视线第一落点明确。
• 中性色承担支撑模块，安静不抢眼。
• 高亮色用于强调风险、异常流量或改造重点。
• 灰色系用于画布背景、分组容器等基础元素。

另外有一个非常推荐的习惯：先灰度后着色。把所有模块先用灰阶摆放好，确认层次完全清晰，再开始上色。这样做的好处是，就算最终导出灰度打印稿，或者有人用黑白屏幕看图，信息依然完整。很多人一上来就涂得五彩斑斓，结果灰度化之后所有模块糊成一团，这种坑我在项目交付时踩过不止一次。

连线同样要讲纪律。调用关系用实线，数据流转用带箭头的实线，异步或弱依赖用虚线，回退或可选路径用点划线。一套图从头到尾只贯彻一种线型语义，并在角落图例里写清楚。大多数图的混乱不在信息多，而在线条“说什么的都有”，读者每根线都要重新猜意思，阅读负担自然重。

字体方面，记住一个简单框架：标题用一个字重，正文用一个字号，标签类说明用最小字号，全图不超过三种字号。字体是信息等级的信号，切片切得越清楚，读者理解越快。别让标题和正文一样大，也别让注释比正文还显眼，这些都属于最基本的排版关系。

2.3 形状语义与图例：让图能自解释

diagram-design 做到高水平，应该追求“不需要在旁边配大段解释文字”。完善的形状语义，是达成这一目标的核心。

我常用的形状约定是：

• 圆角矩形：业务应用或服务
• 矩形：组件或中间件
• 椭圆形：外部系统或外部依赖
• 菱形：判断或分支节点
• 六边形：适配器、转换层

不同团队当然可以采用自己的约定，前提是全图形状语义一致，并且在图例中写清楚。很多人画图时不注意这一点，一会儿用圆角矩形代表服务，一会儿又用圆形，导致读者每看到一个形状都在猜测它“到底算什么”。

图例不必占C位，放在画布右下角即可。但它必须覆盖四项：颜色含义、线型含义、形状含义、特殊标记含义。比如某个标签表示“降级中”还是“灰度中”，必须在图例中说明。

自检时有一个很好的标准：把图发给一个完全不了解上下文的人，遮住你的解说，只看图和图例，如果他还能说出五六成内容含义，说明这图基本上已经能自解释了。

3. 工具选型与协作链路：从孤岛文件到团队资产

工具不是 diagram-design 的全部，但没有顺手的工具，流程很难跑得顺畅。这里先讲清楚选型逻辑，再讲协作与复用，因为后两者才是长期价值所在。

3.1 四类工具怎么选

按形态和适用场景，绘图工具大致可以分成四类，各有各的舒适区。

• 在线白板类：上手最快，多人同屏协作，适合方案讨论前期，画会议草稿或者临时梳理关系非常高效。缺点是导出格式比较有限，元素多了会卡顿，不适合做精细化交付。
• 桌面绘图类：免费、轻量、可离线，自带网格吸附、组件库、多格式导出，适合正式架构图和流程图交付，是大多数技术团队的日常主力。
• 文本绘图类：用文本语法描述节点和连线，好处是图可以进代码仓库、可以做 diff、可以自动生成，特别适合文档即代码的团队，也让评审更规范。
• 设计协作类：矢量精准、视觉表现力强，适合有设计师参与或需要对外展示的像素级精美图，但学习成本较高，日常快速修改反而没那么灵活。

我的策略是分阶段切换：创意期用在线白板，正式期用桌面绘图软件，需要入库的图用文本方案，对外宣传图才动用设计工具。很多团队只选一个工具走完所有流程，也不是不行，只是总有一项会受到妥协。

3.2 多人协作与版本管理：别再把文件名改成“最终版”

团队里最痛的场景，就是文件列表里出现“架构图_v1”“架构图_v2_最终”“架构图_真最终”这类命名。我经历过，也深受其害。后来定的规矩是：一张图只保留一份主文件，文件命名里不带版本号，版本交给工具自带的版本历史，或者导入代码仓库托管。

具体落地时可以这样做：

• 桌面绘图软件把主文件放置在共享盘，改动前先锁定，避免多人同时覆盖。
• 文本绘图方案直接提交到代码仓库，每次变更走代码评审流程。
• 在线白板里养成“只改活页，不做另存为”的习惯，控制页面数量。

版本化带来的隐性收益是：评论从“对整张图提感觉”变成了“对具体某个改动提意见”。评审质量随之上升，沟通成本明显下降。这个习惯越早养成越好，等图的数量大起来再改，会非常痛苦。

3.3 自建组件库：越画越快的唯一路径

好的 diagram-design，一定不是每次临场发挥。花一两天把团队常用组件沉淀成一套自用组件库，是我最推荐的投资之一。

组件库至少需要包含：固定容器样式、统一配色方案、常用图标、基础箭头样式、标题和图例模板。在做组件库时，有一个关键点：把组件做成可复用对象，只允许改文字、不允许改形状。字体大小、圆角、描边、阴影都应该固定，只开放文本变量。

这样做的收益很长尾：同一团队的新人，画出来的图也能跟老手保持七八分一致。实际体验是，有了组件库以后，团队里画一张新图的时间会从一两个小时缩短到二十分钟，剩下的工作只是选组件、改标题、连线。这也是我反复强调工具复用价值的根本原因。

4. 完整实操：以“某跨平台用户中心架构图”为例

理论说再多，不如完整走一遍。这里我虚拟一个“某跨平台用户中心架构图”的绘制过程，覆盖从需求收集到多场景交付的全链路。

4.1 需求收集与信息分组

假设这张图的目标读者是研发团队和运维团队，行动预期是“评审后能确认部署边界，并能在故障时快速定位链路”。基于这个目标，我先列出从业务方收集到的所有名词：统一登录、注册、账号绑定、实名认证、用户画像、消息中心、积分系统、短信网关、缓存集群、用户数据库、风控服务、审计日志、第三方开放平台……

然后执行三分类：

• 核心名词：统一登录、用户库、缓存、短信网关、风控、审计日志。
• 支撑名词：用户画像、消息中心、积分系统。
• 噪音名词：具体营销活动、券系统、个性化推荐策略。

核心名词被摆成三层结构：接入层、业务层、数据与基础设施层。这一步完全在纸上完成，不打开工具。图上画出来的内容，其实在纸面阶段就已经成型了。

4.2 布局规划与画布配置

打开绘图工具后，先花两分钟配置画布。

• 画布尺寸：宽 1600 像素、高 1000 像素左右，留足扩展空间。
• 网格吸附：开启，粒度设为 10 像素。
• 页面边框：关闭，避免导出时出现无关白边或裁切问题。

布局方向采用自上而下的分层：最上方是接入层，包含统一入口和网关；中间是业务层，包含用户中心和各类服务；下方是数据层，包含数据库、缓存、消息队列和外部依赖。

间距采用一组简单规则：层与层之间间隔 60 像素，同一层内部模块间距 20 像素，分组容器内侧 padding 预留 30 像素。层间距要大于模块间距，这样组的边界才能肉眼可辨。所有节点矩形都按 8 的倍数拖入网格，后面再想对齐，只需要吸附即可，非常省力。

4.3 绘制核心模块与连线

绘制顺序必须固定：先画容器，再画容器内节点，然后跨容器连线，最后补图例。这个顺序能让图面在任意阶段保持平衡，不会出现某一块画得特别密、另一块还空着的情况。

先从“用户中心”这个大容器开始，容器内放四个服务：登录服务、账号服务、用户信息服务、认证服务。容器外，接入层放网关和负载均衡；数据层放用户库、缓存集群、消息队列；右侧单独放外部依赖，包括短信网关、开放平台、风控服务。

连线执行统一规范。主调用流从接入层指向业务层、业务层指向数据层，用实线箭头；异步回调用虚线；对第三方开放平台的调用用点划线，并标注超时时间。每根线尽量只在两个容器之间出现，尽量避免跨层穿透。一旦出现跨层连线，先不要硬拉，而是重新考虑节点摆放位置，往往调整一下模块顺序，连线就自然顺了。

标注也有规则：容器标题使用最大字号，模块标题使用常规字号，端口和协议信息用小字号放在模块右下角。需要表达运行状态的信息不在模块内部改颜色，而是用独立小标签放在节点右上角，比如“降级中”“灰度中”。这样做的好处是模块颜色始终代表“归属与类型”，而不是临时状态，读者不会被颜色干扰。

4.4 导出与多场景交付

同一张图通常会投放到多个场景，导出策略必须提前想清楚。

• 文档使用，优先导出矢量格式，可无限缩放且文字锐利。
• PPT 演示，导出双倍像素的位图，避免投影时发虚。
• 打印评审，导出 PDF，线宽和字体不会意外变化。
• 快速预览或聊天窗口发送，单倍位图就够了。

导出前必须做一轮自检：全部文字是否溢出边界，所有连线是否压住文字，分组色块是否重叠，图例是否完整，最后全选一遍确认元素都在画布范围内。还有一个小细节，导出位图前关闭网格和辅助线显示，否则容易给交付稿留下虚线痕迹。

5. 高频翻车现场与排查清单

不管准备得多充分，画图过程中总会有一些反复出现的坑。这里直接整理成速查表和排查技巧，方便你遇到问题时快速对照。

5.1 高频问题速查表

5.2 三个亲测有效的排查技巧

排查不是靠肉眼死盯，多的是聪明办法。

第一个：小图显形。把整张图缩小到 30% 比例，很多对齐问题、间距不均、视觉重心偏移会立刻显现。眼睛在原始比例下会不自觉聚焦局部，缩小后反而能看到整体节奏。

第二个：局部截图放大。导出或截取某个区域放大，检查文字边缘、线头是否贴合节点边界、容器 padding 是否均匀。很多“总感觉哪里不对”的问题，最后都在这种检查里找到答案。

第三个：旋转 180 度再看。把画布倒过来看，新鲜视角能强迫大脑重新读图，很多被“熟悉感”掩盖的错位、倾斜、线头悬空问题，会一下子冒出来。这不是玄学，而是视觉注意力重启的有效手段。

5.3 那些容易被忽略的交付细节

除了一眼能看到的问题，还有几个藏在细节里的坑。

字体嵌入：如果团队里有人用你的原文件继续编辑，务必确认替换字体方案是一致的，否则对方的图一打开，排版全乱。

透明通道：导出位图用于深色背景 PPT 时，透明背景可能很合适；但用于普通文档或打印，白色背景更省心，需要在导出时明确选择。

时间戳和负责人：交付到生产环境的图，最好在角落注明更新日期和责任人。三周后再有人打开这张图，至少知道该找谁确认“这个版本还作不作数”。

尺寸单位统一：混合使用像素、厘米或百分比表达尺寸，会在后续修改时带来灾难。尽量让全图的尺寸单位口径一致。

这些细节单看都不起眼，但合在一起，决定了一张 diagram-design 是否经得起真正的生产环境考验。

最后分享一个我一直坚持的习惯：每次画完正式图，我都会把它打印成 A4 纸贴在工位旁放一晚上，第二天再看。纸面上的图没有辅助线、没有缩放、没有网格，是最接近读者真实观感的形态。很多在屏幕上觉得“还行”的图，放到纸面立刻原形毕露。

diagram-design 的本质，其实不是画图，而是信息管理。把信息分组、分层、排列、标注到位，再用一套稳定的视觉规范输出，剩下的不过是熟练工种而已。希望这篇文章能帮你少走一些弯路，把每一张图画得既清晰、又让人愿意看下去。