承接上一篇——
前 5 篇都在讲"做事的方法论 + 踩坑实战"。 这一篇换个角度,讲一个工具问题:
业务系统设计 / 复盘 / 演讲 / 教学,我都用 drawio 。
不是 PowerPoint 。不是 Markdown 。不是脑图。 是 drawio(diagrams.net)。
这选择本身没什么——但坚持 3 年累计画了 50+ 张 之后, 我的判断变得越来越固执:
▌ 在工程类问题上, ▌ 二维图的信息密度比文字高一倍。 ▌ 文字被过誉了。
3 年里 4 类题材都有积累:
| 题材 | 张数 | 例子 |
|---|---|---|
| 业务架构 | 28 | 财务领域拆分 / 订单处理架构 / 预付结算逻辑 |
| 工程方法论 | 14 | 系统治理 / 灰度发布 / 监控模型 |
| 故障分析 | 4 | RootCause 复盘 / 调度脑裂 |
| 团队工作 | 6 | 协作模式 / 项目周期 |
合计 50+ 张。 有些图我反复改了 6-7 版,有些只画过 1 次就用了 2 年。
主流的工程师选 PowerPoint —— 因为:
但 PowerPoint 有 3 个我接受不了的代价:
PowerPoint 的设计哲学是一页一论点 —— 第 N 页讲第 N 件事, 第 N+1 页讲第 N+1 件事。
但业务架构本质上是网状的 —— 第 N 个节点跟第 N+M 个节点 有关系,这种关系只能在同一张图里展示。
PowerPoint 强行把网状结构线性化 —— 看的人需要在脑子里重新拼。
一张 PowerPoint 平均承载 3-5 个核心信息单元。 一张 drawio 我能放 30-50 个(节点 + 边 + 颜色 + 分组)。
不是为了密集而密集 —— 是因为业务系统本身的结构密度高。 强行降密度 = 信息丢失。
业务系统迁移期间,架构图每周要改。 PowerPoint 改一处布局会带动整页重排。 drawio 改一处节点,其他节点和连线自动适应。
主流的另一派工程师选 Markdown(嵌入 Mermaid / PlantUML)。
我也试过——但有 2 个具体痛点:
Mermaid 的"自动布局"听起来好,实际是对画图者控制权的剥夺。
我画一张订单状态机图,节点之间的位置本身就传递信息:
Mermaid 自动布局会把这些位置语义全打乱。 最后画出来的图"看着对",但信息维度比手画少一半。
graph LR
A --> B --> C
这能描述拓扑,但**画不出"节点 B 是核心 / 节点 C 是兜底"**这种语义。 要在 Mermaid 里加颜色 / 加形状 / 加分组 —— 语法越来越复杂, 写起来比画还慢。
drawio 的设计哲学跟前两者不一样 —— 它承认画图是有"位置"的:
→ 这跟工程师设计架构的思维方式完全对齐。
我画一张迁移架构图,这张图能同时表达:
这张图一眼能传递 30+ 个信息单元。 等价的文字描述至少要 1500 字,看的人还得自己拼回二维。
我后来想明白了一个事:
**文字是一维的(线性时间)**——你只能从左到右、从上到下读。 **图是二维的(空间)**——你可以"扫一眼整张图",再聚焦细节。
业务系统不是一维的 —— 是多个并行子系统 + 跨子系统的关系。
强行用一维工具(文字)描述二维结构 —— 必然损失信息。 不是文字"不够好",是维度不够。
我现在跟产品 / 测试 / 运维同事对齐时,先画图再说话。 画图过程中会发现"哦这里我自己也没想清楚" —— 这是 画图的隐性价值:逼你想清楚。
很多人觉得"画图是为了产出图"。 我的体验相反:画图的过程是思考过程,成图是副产物。
50+ 张图里有一半画完之后我没再打开过—— 但当时画的过程已经完成了它的任务。
我画"订单状态机"和"团队协作流程"用同样的 drawio 。 表面看是工具偏好——实际上我用同一种"思考结构"看这两件事。
久了之后:业务架构和组织架构开始用同一组语义元素表达 —— 这本身就是元能力。
我现在的判断是:
▌ 复杂方案如果画不出图, ▌ 99% 是没想清楚。
不是"画不出图就别动手"——是画图过程本身是思考检测器。 卡在"这里画不出来"的时候,通常就是逻辑漏洞所在。
也踩过坑:
我自己也在反思:
最后一条最关键 ——
2026 年这个时间点,AI 生图工具还做不到 drawio 的"语义控制"。 能生成"看起来对"的图,但生成不出"位置承载意义"的图。
5 年后会不会被替代?我不知道。 但只要 drawio 还能让我"画图过程 = 思考过程",我就还会用。
3 年 50+ 张 drawio 之后我相信一件事:
工具选择是有立场的。 "用什么工具表达"不是工具偏好,是思考方式的延伸。
一维工具(文字)和二维工具(drawio)的差异, 不是"哪个好看",是承载信息维度的根本差异。
跟前 5 篇一样 —— 这是关心信息密度、关心位置语义、关心思考 检测的工程纪律。
写到这,我也不太确定这套对所有团队都成立。
我做的是大型业务系统 + 跨多角色 + 长期演化的项目 —— 这种场景 drawio 几乎是必修。 但创业团队 / 短期项目 / 跟非工程师为主协作的场景 —— drawio 可能反而是负担。
这点我自己也还在想。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。