路径依赖：历史的选择比理性更强大
你现在为什么用 QWERTY 键盘？不是因为它是打字最快的布局——而是因为历史。路径依赖告诉我们：现在的选择往往不是"最优的"，而是"历史上被选中的"——然后锁定住了。
**预计时间：**25 分钟读完 + 25 分钟做练习 = 50 分钟。
一、路径依赖的经典例子
1.1 QWERTY 键盘
QWERTY 布局最初的设计是为了降低打字速度（防止机械打字机卡键）。电子打字机出现后，卡键问题不存在了——理论上应该切换到更快的布局（如 Dvorak）。但全体用户已经习惯了 QWERTY → 切换的成本（重新学习、硬件更换）远大于留在 QWERTY 的好处 → 锁定了。到现在所有人还在用 19 世纪为了”变慢”而设计的键盘。
1.2 VHS vs Betamax
技术上 Betamax 更好（更清晰的画质）。但 VHS 的录制时间更长，更适合录电影。一旦 VHS 在市场上占据了早期优势 → 更多电影发行 VHS → 更多用户买 VHS 播放器 → 更多内容商发 VHS → Betamax 死了。不是技术最优的赢了——是占据了早期路径的赢了。
1.3 Java 的时间类库
Java 早期的时间类库（java.util.Date）设计有严重问题（可变、线程不安全、月份从 0 开始）。但 Java 8 之前的每一次改进都不能太激进——因为几百万 Java 项目已经依赖了旧的 API。最终只能在 Java 8 中新加一套全新的时间 API（java.time），和旧 API 共存。
二、路径依赖在科技项目中的表现
| 场景 | 路径依赖表现 | 影响 |
|---|---|---|
| 技术栈选型 | 早期选了某个框架 → 团队都熟练了 → 即使更好的框架出现也不换 | 技术债务积累，团队缺少对新技术的了解 |
| 数据库选型 | MySQL 能满足需求 → 所有项目都用 MySQL → 某天项目需要非关系型数据 → 但团队不会别的 → 用 MySQL 硬撑 | 架构限制，长期维护成本上升 |
| 业务规则 | ”我们一直这么做的” → 没人问”为什么这么做” | 流程僵化，业务规则和实际需求脱节 |
| API 接口 | 一个接口设计得不好 → 但已经被多个客户端用了 → 改不动了 → 一直留着反面接口 | 维护多个版本的 API，复杂度增加 |
| 团队分工 | ”一直是交易团队做这个模块的” → 即使换了组织也没调整 | 资源分配不合理 |
三、如何对抗路径依赖
3.1 定期做”零基审查”（Zero-Based Review）
问自己：如果今天是 Day 0，给我无限自由，我会怎么设计这个系统/流程/规则？然后对比现在的状态——差距就是”路径债务”。
3.2 计算”切换成本”完整的 TCO
很多时候我们能换——但我们低估了不换的长期成本。做一个完整的对比：(a) 留在原路径的 3 年总成本；(b) 切换到新路径的 1 次性切换成本 + 3 年维护成本。你会惊讶地发现，很多路径的切换成本看起来高，但 3 年 ROI 是正的。
3.3 建立”历史包袱”清单
记录团队的每个”历史决策”——包括当时为什么做这个决策、当时的约束条件是什么、那些约束条件现在还在不在。很多时候约束条件已经变了——但大家还在按旧路径走。
3.4 刻意引入”外部视角”
新加入团队的成员是路径依赖的天然对抗者——因为他们没有被旧路径”锁定”。他们的”为什么我们要这么做？“是最宝贵的问题。鼓励新人提问，不要用”我们一直这样”来回答。
四、实战案例
4.1 案例 1：一个”一直这么做的”审批流程
某金融公司有一个”所有交易对手方变更必须经过三层审批”的规则——10 年前设计时是为了防止操作风险。10 年后，交易系统已经自动化了大部分风控检查——但审批流程还在。每个变更仍然要走 3 周审批。
零基审查：如果今天设计这个流程——“自动风控检查 + 异常情况人工复审”就够了。
结果：审批流程从 3 周降到 1 天——而且风险水平没有变化（因为自动风控检查比 10 年前的人工检查更可靠）。
4.2 案例 2：API 版本兼容性
某 OTP 系统的 API 在 5 年前设计时，交易记录列表接口返回了一个叫 status 的字段，值是”0/1/2”（没有解释）。5 年下来，至少有 8 个外部系统依赖了这些 magic number。任何人想加一个新的状态（如 3=已冻结），都得先确认这 8 个系统不会崩溃。
路径彻底锁死了——不是技术原因，是”切换成本”（通知 8 个系统、测试、同步上线）太高。
缓解方案：新的 API 版本（v2）从一开始就设计为返回字符串（如 “ACTIVE”/“PENDING”）——但即使这样，老客户也没动力迁移，因为运行着好好的。
4.3 案例 3：早期的”选一个”锁定
创业公司早期为了快，选了一个轻量级的数据库（SQLite）。产品成功了，用户量暴增。现在要迁移到 PostgreSQL——但是所有 SQL 查询、ORM 配置、存储过程都是 SQLite 语法。迁移成本极高。创始团队后悔没在一开始就选 PostgreSQL——虽然当时 SQLite “也够用”。
教训：早期选择时要考虑”未来的切换成本”——即使你现在不需要 PostgreSQL 的能力。
五、测验（11 题）
路径依赖的核心含义是？
QWERTY 键盘的例子说明了？
VHS 打败 Betamax 的根本原因是？
对抗路径依赖最有效的方法是？
"我们一直这么做的"——这句话在路径依赖视角下意味着？
创业公司早期应该怎么对抗路径依赖？
公司的一个 API 接口"status 返回 0/1/2"——5 年后还在用，因为外部系统依赖了——这是？
新人的"为什么我们要这么做"的问题为什么重要？
路径依赖和"沉没成本谬误"的区别？
芒格的"保持选择权（optionality）"在路径依赖下是什么意思？
场景题
R1. 场景：你加入了一个新公司，发现他们用 5 年前的 Spring Boot 版本 + Java 8，所有新项目也强制用这个组合。开发效率低，但大家说"一直这么用的"。你的路径依赖分析？
R2. 场景：业务方说"我们的结算流程是 8 年前设计的一直没改过，现在业务复杂了，流程撑不住了"。怎么做？
六、答题提示
展开提示
- Q1-3 核心：初始选择 → 锁定 → 切换成本 > 切换收益。
- Q4-5 零基审查是抗路径依赖的王牌方法。
- Q6-7 早期选型要考虑”退出成本”。“一直这么做”是最危险的词。
- Q8-10 新人是天然破锁者；不要混淆路径依赖（成本锁定）和沉没成本（心理锁定）。
- R1-R2 渐进式解绑路径依赖——不要试图一次性解决所有锁定。
七、本课行动清单
- 找出你当前项目中”一直这么做”的三个事情——做零基审查，看它们是不是路径依赖。
- 对团队的技术栈做一次”切换成本评估”：如果今天重新选，会选什么？切换到新方案的代价是什么？值不值得？
- 建立一个”技术债务 + 路径依赖”清单——不是所有旧的都是路径依赖（有些旧的是经过验证的好）。把真正的路径依赖标识出来。
- 下次做任何早期选型时（框架、工具、流程），不仅问”现在够不够”——也问”如果未来要换，成本高不高”。
八、参考来源
- ② 经典：Paul A. David，“Clio and the Economics of QWERTY”（1985）——路径依赖经济学的经典论文
- ③ 严肃著作：W. Brian Arthur，《Increasing Returns and Path Dependence in the Economy》——路径依赖在市场经济中的系统运作
- ③ 严肃著作：Jared Diamond，《Guns, Germs, and Steel》——文明层面的路径依赖分析
- ④ 实用读物：Shane Parrish，《The Great Mental Models》——路径依赖作为决策模型的实用介绍
**下一步：**看 Lesson 0013 · 网络效应与临界点。