承接上一篇——
前 5 篇都在讲"做事的方法论 + 踩坑实战"。
这一篇换个角度,讲一个工具问题:
业务系统设计 / 复盘 / 演讲 / 教学,我都用 drawio 。
不是 PowerPoint 。不是 Markdown 。不是脑图。
是 drawio(diagrams.net)。
这选择本身没什么——但坚持 3 年累计画了 50+ 张 之后,
我的判断变得越来越固执:
▌ 在工程类问题上,
▌ 二维图的信息密度比文字高一倍。
▌ 文字被过誉了。
我画过什么
3 年里 4 类题材都有积累:
[td]题材[/td]
[td]张数[/td]
[td]例子[/td]
业务架构
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 的设计哲学跟前两者不一样 —— 它承认画图是有"位置"的:
→ 这跟工程师设计架构的思维方式完全对齐。
我画一张迁移架构图,这张图能同时表达:
这张图一眼能传递 30+ 个信息单元。
等价的文字描述至少要 1500 字,看的人还得自己拼回二维。
二维 vs 一维 · 信息密度的本质差异
我后来想明白了一个事:
**文字是一维的(线性时间)**——你只能从左到右、从上到下读。
**图是二维的(空间)**——你可以"扫一眼整张图",再聚焦细节。
业务系统不是一维的 —— 是多个并行子系统 + 跨子系统的关系。
强行用一维工具(文字)描述二维结构 —— 必然损失信息。
不是文字"不够好",是维度不够。
drawio 用熟之后的 4 个反直觉发现
1. "一张图代替 N 段对话"是真的
我现在跟产品 / 测试 / 运维同事对齐时,先画图再说话。
画图过程中会发现"哦这里我自己也没想清楚" —— 这是
画图的隐性价值:逼你想清楚。
2. 画图本身比成图更重要
很多人觉得"画图是为了产出图"。
我的体验相反:画图的过程是思考过程,成图是副产物。
50+ 张图里有一半画完之后我没再打开过——
但当时画的过程已经完成了它的任务。
3. 跨题材统一工具 = 跨题材思考迁移
我画"订单状态机"和"团队协作流程"用同样的 drawio 。
表面看是工具偏好——实际上我用同一种"思考结构"看这两件事。
久了之后:业务架构和组织架构开始用同一组语义元素表达 ——
这本身就是元能力。
4. 复杂方案不画图 = 没想清楚
我现在的判断是:
▌ 复杂方案如果画不出图,
▌ 99% 是没想清楚。
不是"画不出图就别动手"——是画图过程本身是思考检测器。
卡在"这里画不出来"的时候,通常就是逻辑漏洞所在。
什么时候不该用 drawio
也踩过坑:
改用 PowerPoint(或导出成 PNG)
阴面 · 这套也有副作用
我自己也在反思:
最后一条最关键 ——
2026 年这个时间点,AI 生图工具还做不到 drawio 的"语义控制"。
能生成"看起来对"的图,但生成不出"位置承载意义"的图。
5 年后会不会被替代?我不知道。
但只要 drawio 还能让我"画图过程 = 思考过程",我就还会用。
写在最后
3 年 50+ 张 drawio 之后我相信一件事:
工具选择是有立场的。
"用什么工具表达"不是工具偏好,是思考方式的延伸。
一维工具(文字)和二维工具(drawio)的差异,
不是"哪个好看",是承载信息维度的根本差异。
跟前 5 篇一样 —— 这是关心信息密度、关心位置语义、关心思考
检测的工程纪律。
写到这,我也不太确定这套对所有团队都成立。
我做的是大型业务系统 + 跨多角色 + 长期演化的项目 ——
这种场景 drawio 几乎是必修。
但创业团队 / 短期项目 / 跟非工程师为主协作的场景 ——
drawio 可能反而是负担。
这点我自己也还在想。
