我曾在美国托莱多的一家创业公司 Heartland Information Services 工作。我们给全美一些大型医院提供转录服务，规模不小，在当时属于美国医疗转录行业的头部公司之一，也参与了那一波把转录业务外包到海外的浪潮。

这类服务听起来不复杂，但其实非常关键：一旦系统宕机，影响是实打实的。比如你可能正需要做紧急手术，但却必须等手术记录被转成文字版本才能继续推进，这种等待是不能接受的。

当时我们在印度的工程师团队非常优秀，公司采取的是“混合模式”：关键系统一部分在海外开发，一部分在美国本土部署。原因很简单——成本。海外开发便宜太多了，对于每一分钱都要算的创业公司来说，这种节省无法忽视。当时也是一种行业趋势，托马斯·弗里德曼提出“世界是平的”，很多美国开发者都开始担心自己的工作会不会被替代。

从结果看，代码质量其实不错，印度工程师也都很有能力。但在这种跨地域协作中，经常会出现一个问题：某个功能为什么这么设计，可能只存在于世界一端某个人的理解里，而维护它的人却在另一端。知识是存在的，但不一定在你需要的时候能找到。

最近我一直在想 Heartland 的经历，因为现在的情况有点熟悉。

这一次，代码变得更“便宜”了

现在，写代码的成本已经大幅下降。AI 工具可以快速生成看起来不错、能运行、通过测试的代码，速度和成本都是几年前无法想象的。

和当年外包浪潮一样，这一切都是经济理性选择——没人“做错了”。这些 AI 写出来的代码通常也没问题，能用，也能上线。

但历史已经告诉我们一个规律： 当“写代码”变便宜时，成本并不会消失，而是转移了。

它会从“写代码”转移到“理解代码”。

《Prediction Machines》里有个核心观点：当某个基础能力变便宜时，它的价值会转移到“互补能力”上。在软件里，这个互补能力一直是“理解”。

外包时代已经证明，真正贵的从来不是写代码，而是理解代码——理解它为什么这么设计，如何安全修改它，在紧急情况下如何调试它，以及如何向下一个人解释“为什么当初凌晨两点要这样写”。

这一次的不同点在于：可能没人真正“理解过”

外包时代，知识其实是存在的，只是分散在不同人脑子里。比如在班加罗尔或德里工作的开发者，通常是知道设计意图的，只是把这种理解传递到另一时区和组织边界很困难。

但 AI 生成代码的情况不同——很多时候，没有任何一个人真正完整理解过这段代码。它可能是“被生成出来的”，语法正确，但背后的意图并不在任何人的脑子里完整存在。

代码被提交了，但“理解”没有被一起提交。

这不是反对 AI 写代码

这不是在说不能用 AI。我自己每天也在用，而且确实提高了效率。

但如果我们只用“产出多少代码”来衡量生产力，那其实是一个早就被证明有问题的指标。

外包时代后来教会了行业一件事：解决办法不是停止分布式协作，而是刻意去建设“共享上下文”——文档、代码评审、沟通机制，以及让团队真正理解彼此的长期投入。

成功的公司，都是把“理解成本”当成核心工程问题来处理，而不是副产品。

接下来真正稀缺的是什么？

如果平均质量的代码变得很便宜，那么真正稀缺的就不再是“写代码能力”，而是能不能读懂代码？能不能在复杂系统中定位关键部分？ 能不能理解“为什么这里重要”？

早在 25 年前，Joel Spolsky 就说过一句话：“读代码比写代码更难。”当时是对的，现在更是如此。

下一代工具应该解决的问题

下一代开发工具不应该只帮我们“更快写代码”，而应该帮助我们：

• 更快理解已有代码

• 理解历史遗留系统

• 理解 AI 生成但没有人真正设计过的代码

因为现在真正的工作重心，正在从“创造代码”，转向“理解代码”。

而这，才是新的工程能力核心。