3 年画了 50+ 张 drawio,我的判断:文字过誉了

承接上一篇——

前 5 篇都在讲"做事的方法论 + 踩坑实战"。这一篇换个角度,讲一个工具问题:

业务系统设计 / 复盘 / 演讲 / 教学,我都用 drawio 。

不是 PowerPoint 。不是 Markdown 。不是脑图。是 drawio(diagrams.net)。

这选择本身没什么——但坚持 3 年累计画了 50+ 张 之后, 我的判断变得越来越固执:

▌ 在工程类问题上, ▌ 二维图的信息密度比文字高一倍。 ▌ 文字被过誉了。

我画过什么

3 年里 4 类题材都有积累:

题材	张数	例子
业务架构	28	财务领域拆分 / 订单处理架构 / 预付结算逻辑
工程方法论	14	系统治理 / 灰度发布 / 监控模型
故障分析	4	RootCause 复盘 / 调度脑裂
团队工作	6	协作模式 / 项目周期

合计 50+ 张。有些图我反复改了 6-7 版,有些只画过 1 次就用了 2 年。

为什么不是 PowerPoint?

主流的工程师选 PowerPoint —— 因为:

公司有授权
跨部门通用
演示效果好
老板都用

但 PowerPoint 有 3 个我接受不了的代价:

1. 一页只能放一件事

PowerPoint 的设计哲学是一页一论点 —— 第 N 页讲第 N 件事, 第 N+1 页讲第 N+1 件事。

但业务架构本质上是网状的 —— 第 N 个节点跟第 N+M 个节点有关系,这种关系只能在同一张图里展示。

PowerPoint 强行把网状结构线性化 —— 看的人需要在脑子里重新拼。

2. 信息密度低

一张 PowerPoint 平均承载 3-5 个核心信息单元。一张 drawio 我能放 30-50 个(节点 + 边 + 颜色 + 分组)。

不是为了密集而密集 —— 是因为业务系统本身的结构密度高。强行降密度 = 信息丢失。

3. 修改成本高

业务系统迁移期间,架构图每周要改。 PowerPoint 改一处布局会带动整页重排。 drawio 改一处节点,其他节点和连线自动适应。

为什么不是 Markdown?

主流的另一派工程师选 Markdown(嵌入 Mermaid / PlantUML)。

我也试过——但有 2 个具体痛点:

1. 自动布局是诅咒

Mermaid 的"自动布局"听起来好,实际是对画图者控制权的剥夺。

我画一张订单状态机图,节点之间的位置本身就传递信息:

重要节点居中
异常节点放下方
补偿路径放右侧

Mermaid 自动布局会把这些位置语义全打乱。最后画出来的图"看着对",但信息维度比手画少一半。

2. 文字描述的图 ≠ 图

graph LR
A --> B --> C

这能描述拓扑,但**画不出"节点 B 是核心 / 节点 C 是兜底"**这种语义。要在 Mermaid 里加颜色 / 加形状 / 加分组 —— 语法越来越复杂, 写起来比画还慢。

为什么是 drawio

drawio 的设计哲学跟前两者不一样 —— 它承认画图是有"位置"的:

节点位置可以传递语义
颜色 / 形状 / 大小都是表达维度
分组 / 边的样式都是信息

→ 这跟工程师设计架构的思维方式完全对齐。

我画一张迁移架构图,这张图能同时表达:

上游有几个数据源(节点位置:左上)
主链路 7 个节点(中间纵向)
4 类闭环(每类一种连线颜色)
监控埋点位置(蓝色虚线)
跨业务复用部分(灰色背景标注)

这张图一眼能传递 30+ 个信息单元。等价的文字描述至少要 1500 字,看的人还得自己拼回二维。

二维 vs 一维 · 信息密度的本质差异

我后来想明白了一个事:

**文字是一维的(线性时间)**——你只能从左到右、从上到下读。 **图是二维的(空间)**——你可以"扫一眼整张图",再聚焦细节。

业务系统不是一维的 —— 是多个并行子系统 + 跨子系统的关系。

强行用一维工具(文字)描述二维结构 —— 必然损失信息。不是文字"不够好",是维度不够。

drawio 用熟之后的 4 个反直觉发现

1. "一张图代替 N 段对话"是真的

我现在跟产品 / 测试 / 运维同事对齐时,先画图再说话。画图过程中会发现"哦这里我自己也没想清楚" —— 这是 画图的隐性价值:逼你想清楚。

2. 画图本身比成图更重要

很多人觉得"画图是为了产出图"。我的体验相反:画图的过程是思考过程,成图是副产物。

50+ 张图里有一半画完之后我没再打开过—— 但当时画的过程已经完成了它的任务。

3. 跨题材统一工具 = 跨题材思考迁移

我画"订单状态机"和"团队协作流程"用同样的 drawio 。表面看是工具偏好——实际上我用同一种"思考结构"看这两件事。

久了之后:业务架构和组织架构开始用同一组语义元素表达 —— 这本身就是元能力。

4. 复杂方案不画图 = 没想清楚

我现在的判断是:

▌ 复杂方案如果画不出图, ▌ 99% 是没想清楚。

不是"画不出图就别动手"——是画图过程本身是思考检测器。卡在"这里画不出来"的时候,通常就是逻辑漏洞所在。

什么时候不该用 drawio

也踩过坑:

跟非工程师协作时 —— drawio 文件别人打不开 / 看不懂 → 改用 PowerPoint(或导出成 PNG)
移动端阅读 —— drawio 在手机上体验差 → 改用文字摘要
一次性沟通 —— 一句话能说清的事,别画图(过度工程)
演讲时 —— drawio 信息密度太高,听众跟不上 → 演讲用简化版

阴面 · 这套也有副作用

我自己也在反思:

跨群体沟通成本高 —— 看不懂 drawio 的人需要解释成本
可能让"文字表达能力"退化 —— 长期不用文字组织复杂思维
AI 时代风险 —— 如果 AI 生图工具够好,手画 drawio 可能被替代

最后一条最关键 ——

2026 年这个时间点,AI 生图工具还做不到 drawio 的"语义控制"。能生成"看起来对"的图,但生成不出"位置承载意义"的图。

5 年后会不会被替代?我不知道。但只要 drawio 还能让我"画图过程 = 思考过程",我就还会用。

写在最后

3 年 50+ 张 drawio 之后我相信一件事:

工具选择是有立场的。 "用什么工具表达"不是工具偏好,是思考方式的延伸。

一维工具(文字)和二维工具(drawio)的差异, 不是"哪个好看",是承载信息维度的根本差异。

跟前 5 篇一样 —— 这是关心信息密度、关心位置语义、关心思考检测的工程纪律。

写到这,我也不太确定这套对所有团队都成立。

我做的是大型业务系统 + 跨多角色 + 长期演化的项目 —— 这种场景 drawio 几乎是必修。但创业团队 / 短期项目 / 跟非工程师为主协作的场景 —— drawio 可能反而是负担。

这点我自己也还在想。