你以为 AI 只是让程序员写代码更快？那是最低级的叙事

你以为 AI 编程工具最大的影响是让程序员写得更快？

错了。

AI 编程工具最大的影响，是让程序员开始做以前根本不敢做的事。

这两个判断听起来差不多，但它们之间的距离，比马车和火车之间的距离还远。因为一个是量变，一个是质变。一个是爬坡，一个是跳崖再起飞。

咱们来拆这件事。

一、效率提升是最低级的叙事

Cursor 在 2025 年发了一份《开发者习惯报告》，里面有一个数字被所有媒体当标题用，开发者的周均代码产出从 3600 行涨到了 8600 行，涨幅 2.4 倍。

GitHub Copilot 那边也有一组数字被反复引用，开发者完成任务的速度提升了 55%。

好，数字很漂亮。

然后呢？

然后所有讨论就停在了「效率提升」这四个字上。

但你往深处看一眼。Cursor 的报告里还有三个数字，没上标题，但比那 2.4 倍重要得多。

• 报告还显示，AI 生成代码的 60 分钟留存率达 81%，大部分代码没有被删掉重写，说明这些代码是真的有用，不是垃圾填充；
• 开发者提交的 PR 平均规模明显变大，每次提交解决更大的问题；
• Agent 工具调用增幅约 30%，开发者在让 AI 去完成以前需要多人协作才能推进的任务链。

这三个数字拼在一起，讲的不是「同一件事做得更快」，而是「不同的事开始被做了」。

用人话讲，以前一个人一次搬一块砖，现在能一次搬十块。但他没有用十次搬完原来那堆砖，他去开工了一栋以前根本不敢动的楼。

这就不是效率问题了。

这是维度问题。

二、你需要的不是爬得更快，而是换一座山

适应性景观（Fitness Landscape），由进化生物学家 Sewall Wright 在 1932 年提出。想象一片连绵起伏的山地，每一座山丘代表一种适应度更高的状态，山丘之间是低谷。进化的目标不是在当前山丘上爬到顶，而是找到更高的山丘。

但问题在于，要从当前山丘去更高的山丘，你必须先下坡，穿过低谷。

这个模型解释了一个反直觉的现象，局部最优恰恰是全局进步的最大障碍。

你在当前山丘上爬得越快、爬得越高，你就越不愿意下山去寻找更高的山丘。因为下山意味着短期适应度下降，意味着你已经建立的优势暂时失效。

这不就是现在正在发生的事吗？

AI 之前的程序员，他们的适应性景观是，写代码能力越强，山丘越高。所以他们拼命提升编码技能，学新框架，刷算法题，在「写代码」这座山上不断攀登。

然后 AI 来了，直接把「写代码」这座山的海拔压低了。不是因为写代码不重要了，而是因为这件事的门槛被大幅降低了，山还是山，但没以前那么高了。

真正的机会在于，AI 在旁边造了一座新的山丘，叫「问题定义与系统判断」。

这座山以前也存在，但它的海拔被「你必须先会写代码」这个硬约束压着，大多数人根本爬不上去。现在约束松动了，这座山的海拔突然显露出来。

2025 年 2 月，Andrej Karpathy 提出了「vibe coding」，你完全沉浸在意流的氛围里，把意图告诉 AI，AI 去实现，你几乎不看生成的代码，感受整体走向对不对，往前推就行。

很多人读了不舒服，不看代码？这还叫工程师吗？

但 Karpathy 说的关键不在「不看代码」，而在「敢于开始以前不敢做的项目」。以前有多少想法死在「这太复杂了，一个人搞不定」这句话上？vibe coding 改变的不是写代码的速度，而是「谁敢开始做什么」。

从适应性景观的角度看，vibe coding 就是下山的勇气，你放弃了在「逐行编码」这座山上的局部最优，穿过低谷，去爬那座叫「系统设计与问题定义」的更高的山。

YC W25 这一批次的创业公司，大约 25% 的公司代码几乎全部由 AI 生成。更有意思的是，这些公司里有相当一部分的创始人不是技术背景，非技术创始人在构建复杂产品。这在以前几乎不可能发生。

为什么？因为「不会写代码」这座低谷，以前太深了，跨不过去。AI 把谷底垫高了，非技术出身的创业者终于可以翻过去，爬上另一座山。

三、这不是线性增长，这是状态跃迁

相变（Phase Transition），统计物理的核心概念，最早由保罗·埃伦费斯特（Paul Ehrenfest）在 1933 年系统阐述。当系统的某个参数跨过临界值时，系统的性质不是渐变的，而是突变的。

拿水做类比。0°C 到 99°C 的水，和 101°C 的水蒸气，不是量的差异，是质的断裂。水在 100°C 以下是液体，在 100°C 以上是气体，不是「更流动的液体」，而是一个全新的物态。

AI 编程工具带来的变化，不是 0°C 到 99°C 的加热，而是 99°C 到 101°C 的相变。

咱们来算一笔账。

在 AI 之前，程序员的工作模式是这样的。想清楚一个模块的逻辑，手写代码，调试，测试，提交。每个环节都需要时间和认知资源。一个人的执行容量就这么大，所以你只能选择规模可控的问题。

AI 之后，执行环节被大幅压缩。你想清楚逻辑，告诉 AI，AI 生成代码，你审查和调整。关键是，这个压缩不是线性的。它改变了「什么规模的问题可以被一个人处理」这个硬约束的边界。

Shopify 的 CEO Tobi Lütke 在 2025 年 4 月发了一份内部备忘录，以后每次有人说「我们需要增加人手」，必须先证明这件事 AI 做不到，否则这个请求不成立。

听起来残酷，但他在点一件重要的事。工具变了，问题的定价方式就变了。以前「这个问题需要五个工程师」是一种硬约束，现在这个约束在松动。问题的界限在哪里，变成了一个真正需要思考的问题。

Sam Altman 说，我们将看到一个人公司达到 10 亿美元估值。很多人把这句话当鸡汤，但你如果理解了相变，就知道他不是在打鸡血，他在描述一个结构性事实。

一个人公司过去做不大，根本原因是执行容量的限制。你能想的事情可以很多，但你能做出来的事情被时间卡死了。雇人是突破上限的方式，但雇人意味着组织，意味着沟通成本，意味着你花大量时间在管理上而不是在解决问题本身。

AI 把执行容量这个变量动了。

执行容量一旦不再是瓶颈，什么变成了瓶颈？

是你能不能判断「做什么」比「怎么做」更重要。以前问题绑定了人手，因为做不出来就没意义。现在执行门槛被 AI 压低了，瓶颈从「能不能做」转移到了「做什么」。问题开始和「你有多少人」脱钩，和「你有多好的问题意识」挂钩。

物态已经变了。

历史上有过完全一样的相变。1982 年 AutoCAD 发布，外行看到的是「画图变快了」。但工程师经历的真正变化不是这个。用 CAD 之前，工程设计的一大部分工作是「画图」本身，你的工作时间里有相当一部分用在图纸的物理生产上。CAD 之后，这部分基本不需要了，工程师开始做更复杂的系统设计。波音 777 是第一架完全在计算机上设计的飞机，没有一张纸质图纸，它的复杂程度放在手绘图纸时代根本不可能实现。

再往前，1950 年代，Grace Hopper 在 1952 年发明了最早的编译器 A-0，她创建的 FLOW-MATIC 语言直接催生了 COBOL 的诞生。当时有人预言程序员要失业了。结果呢？程序员的工作升维了，不再跟机器底层逻辑打交道，而是去处理更高层的逻辑、更大的系统、更复杂的架构。

CAD 没有让工程师「画图更快」，编译器没有让程序员「写代码更快」。它们做的是同一件事。引发相变，让工作进入一个全新的物态。

四、你的比较优势已经转移了

好，相变发生了，新物态来了。那在这个新物态里，人的位置在哪？

这就需要第三个模型。不过严格说，这个模型比前两个古老得多，但它在这件事上的解释力极强。

比较优势（Comparative Advantage），由经济学家大卫·李嘉图（David Ricardo）在 1817 年的《政治经济学及赋税原理》中提出。即使一方在所有事情上都比另一方更强，双方仍然可以通过各自专注于自己相对更擅长的领域来获得最大收益。

比较优势不在绝对能力，而在机会成本。你做这件事的代价，是你放弃的其他事情。

把这个模型搬到 AI 和人的关系上，结论非常清晰。

AI 在常规编码任务上对人拥有压倒性优势，但这恰恰意味着人在判断力上的比较优势被放大了。

直说吧，AI 写代码又快又多，你跟它拼编码速度是死路一条。但你有一个它永远没有的东西，你对真实世界的理解。你对用户痛点的感知，你对行业走向的判断，你对「这件事值不值得做」的直觉，这些是 AI 的机会成本无限大的领域，因为 AI 根本不具备这些能力。

有人可能会问，AI 会不会连判断力也替代？不会。判断力依赖的是对真实世界的具身理解（embodied understanding），你需要亲历过行业的失败、感受过用户的挫败、在不确定性中做过不可逆的决策。这不是数据训练能获得的，因为数据里没有「痛感」。

一个工程师用 AI 写出了以前不敢写的系统，上线跑起来了，但跑了三个月发现方向是错的，因为他对自己服务的用户理解不够深。工具给了他执行力，但没给他方向感。

GitHub Copilot 的研究里有一个被忽略的发现，开发者开始尝试以前不会尝试的复杂任务。注意这个措辞，不是「完成复杂任务更快」，而是「开始尝试」。这是两个完全不同的动作。前者是效率，后者是勇气，而勇气来自判断力，你判断这件事值得试。

再来看那个被争议的数字。GitClear 2024 年的报告说，AI 生成代码的 churn rate（提交后短期内被修改或删除的比率）显著上升，接近翻倍。有人拿这个说 AI 代码不靠谱。

这个解读方向错了。

churn rate 上升，恰恰说明开发者在试更多从来没试过的东西。你在熟悉的地方做事，第一次就做对了。你跑到边界之外，当然要多改几次。你在探索，不是在复现。报告显示，越复杂的任务 churn rate 越高。这说明不是工具不行，是人在探索新的边界。

代码质量争议，是边界扩张的阵痛，不是工具失败的证据。就好像你第一次用 CAD 设计复杂系统，出错率肯定比手绘一张已经熟悉的图纸要高。但你选择了做那个复杂系统。这本身就是进步，只是这种进步需要一个适应期。

五、升维时代的生存策略

模型讲完了，咱们说点实际的。面对这场相变，你该怎么办？

问题定价的相变法则。 工具变了，问题的定价方式就变了。以前编码能力是稀缺资源，谁能写谁就定价高。现在 AI 把编码的稀缺性打掉了，定价权转移到了「你能不能判断什么问题值得解决」。

从「我怎么做得更快」切换到「我该做什么」。速度不再是护城河，产能不再是护城河。以前你跟同行比谁代码写得快，现在 AI 把所有人的编码速度拉平了。你快，AI 更快。真正的竞争转移到了，谁能在更大的问题上保持清醒，谁在 AI 帮你做完一百件事之后，知道第一百零一件事应该是什么。

判断力的机会成本计算。 用比较优势的视角审视你自己的位置。你现在花时间提升的每一项能力，都有机会成本。你在「写代码更快」上每投入一小时，就少了一小时去理解用户、理解行业、做出更好的判断。AI 在编码上的比较优势越来越大，你在这条赛道上的相对收益越来越低。

你需要问自己，我能下坡吗？我能穿过低谷，去爬那座叫「问题定义与系统判断」的山吗？

适应性景观的下坡策略。 判断力不是玄学，它是有方法可练的。

第一，多做「该不该做」的决策，少做「怎么做」的执行。每次面对一个任务，先问「这件事值不值得做」，而不是「这件事怎么做」。

第二，扩展你对用户和行业的理解边界。写代码的能力 AI 可以替代，但理解一个行业为什么这么运转、用户为什么这么行为，这种理解需要你在真实世界里泡足够长的时间。

第三，主动去做那些让你不舒服的项目。churn rate 高的项目，方向不确定的项目，需要你做判断而不是做执行的项目。不舒服恰恰说明你在穿越适应性景观的低谷，你在下山，去往更高的山丘。

六、地图之外

程序员的周均代码产出从 3600 行涨到 8600 行，这个数字很大，很好报道，很好传播。

但那多出来的 5000 行在做什么，才是真正的问题。

是在把原来两周的项目压缩到一周？那你在已知的地图上开得更快。

还是在做以前根本不会启动的项目？那你在地图之外开始画新的地图。

历史上每一次工具的相变，都有一批人讨论效率提升了多少。这是最容易量化的维度，也是最无聊的维度。波音的工程师没有用 CAD 把手绘图纸的效率提高三倍，他们造了一架手绘时代根本造不出来的飞机。编译器的发明者没有让汇编程序员写汇编更快，他们创造了一种全新的编程范式。

真正的故事从来不在速度。在于这之后，人们选择去做什么。

如果你对领域的理解足够深，对用户的洞察足够准，对方向的判断足够稳，AI 会帮你做到的规模，是以前你一个人根本无法企及的。

而如果你只是用 AI 把以前的活儿干得更快，恭喜，你是一台更高效的马车。

相变已经发生了。你是在旧物态里加速，还是进入新物态？这个选择，比任何工具都重要。