当代码生成变得廉价，哪些技能会升值 — 贬值的与升值的

引言 — 把问题问对
机制 — 瓶颈不会消失，它只是移动
贬值的技能 — 它们本来就不是价值，而是价值的代理指标
升值的技能 (1) — 验证：不是扫 diff 的眼力，而是供给标准答案的能力
升值的技能 (2) — 生产环境调试：当上下文是隐性的
升值的技能 (3) — 系统设计与权衡的品味
升值的技能 (4) — 需求考古：知道该造什么
升值的技能 (5) — 主人翁：能挂上传呼机的那个人
反驳 —「验证最后不也是 AI 来做吗」
结语
参考资料

引言 — 把问题问对

「AI 会取代开发者吗」是一个提错了的问题。它把「开发者」当成一种单一技能。而现实中的开发者是十几种技能的组合，这个组合里的各项，此刻正 以不同的速度被重新定价。有的正在趋近于零，有的在上涨。

所以真正的问题是 — 这个组合里，哪些项正在变便宜，它们的价值又流向了哪里？这不是品味问题，而是一个相当枯燥的经济学问题，而答案的骨架早已存在。

机制 — 瓶颈不会消失，它只是移动

当一道工序变得廉价而充裕时，瓶颈并不会消灭，它会移动到下一道工序。而价值总是附着在瓶颈所在之处。生成变便宜了，价值就流向生成之后的环节 — 确认它是否正确，决定该造什么，把它接进别人的系统里。

在 AI 这一侧把这个直觉磨得最锋利的是 Jason Wei。他所说的 验证的不对称性(asymmetry of verification) 很简单 — 有些任务，验证起来远比求解容易。解一道数独要花不少时间，但一个填满的盘面对不对，一眼就能看出来。由此他推出了 验证者定律(verifier's law) — 「训练 AI 解决某个任务的难易程度，与该任务的可验证性成正比。」说得更锋利些：凡是可解、且易于验证的任务，最终都会被 AI 解决。

大多数人把这条定律读成「AI 将会擅长的事情清单」。但倒过来读要重要得多。如果易于验证的活儿都会被自动化，那么 留给人的，恰恰是那些验证昂贵、缓慢、主观，或者压根就没有标准答案的活儿。 这不是安慰奖，这是预测。

而瓶颈，事实上已经移动了。

DORA 2025 报告称约 90% 的技术从业者已经在工作中使用 AI。但结论很微妙 — AI 采用与吞吐量的关系已经转正，然而 交付的不稳定性仍在持续攀升。 DORA 自己的总结是：AI 是一台 放大器，把一个组织既有的长处和短处一起放大。只提速而不加强质量管控，瓶颈只会被推到下游去。
LinearB 的 2026 年基准报告 用数字指出了下游到底在哪儿。分析了 4,800 多个组织的 810 万个 PR 后发现，AI 生成的 PR 等待评审的时间要长 4.6 倍。 由智能体开出的 PR，其被接手的时间要长 5.3 倍。合入率更是远逊于人写的代码 — 32.7% 对 84.4%。 生成量暴涨的地方，评审之前排起了长队。
这条队为什么消化不掉，Stack Overflow 2025 给出了解释。84% 的开发者正在使用或计划使用 AI 工具，超过一半的人每天都在用。可是头号困扰是 「几乎正确、但又不完全正确的 AI 方案」(66%)，第二是 「调试 AI 生成的代码更费时间」(45.2%)。而对输出准确性表示高度信任的，只有 3.1%。

最后这一条是全文的枢纽。几乎正确的代码，比错误的代码更贵。 错误的代码会被当场筛掉；几乎正确的代码能通过扫一眼，通过评审，通过预发环境 — 然后在生产环境里炸开。生成越便宜，这类代码来得越多、越快。验证成本随生成量成比例上升，而验证能力不会。

贬值的技能 — 它们本来就不是价值，而是价值的代理指标

我把它们的名字直说出来。

背下来的框架 API。 模型比你读得更准、更全。记住函数签名这件事上的溢价，已经没了。
样板代码的吞吐量。 CRUD 脚手架、DTO 转换、配置文件、测试夹具 — 曾经拼「每分钟产量」的那片战场。
「我打字快」式的生产力。 打字速度其实从来就不是瓶颈，但它确实曾被标过价。

关键在这里 — 这些技能 从来就不是价值本身，而是价值的代理指标(proxy)。 它们之所以有价，只是因为在生成还是瓶颈的年代里，它们稀缺。稀缺一旦消失，价格随之消失。

但贬值不等于无用。读不懂的代码，你没法评审。 不懂语言、不懂框架，下面要讲的所有升值技能一个都启动不了。地基依然必需。只不过地基如今是 入场券，而不是优势。

升值的技能 (1) — 验证：不是扫 diff 的眼力，而是供给标准答案的能力

先破除一个误解。会升值的验证能力，不是「逐行细读 diff 的勤勉」。那件事机器已经做了相当大一部分。Linter、类型检查、静态分析、AI 评审机器人 — 漏掉的空指针检查、明显的竞态条件，都属于「易于验证」的那一侧，而按照验证者定律，那一侧会被持续自动化。

真正升值的，是机器无法供给的那一侧 — 标准答案(ground truth)本身。 在这个系统里、这门生意里、这个规模下，「正确」到底意味着什么，是需要 有人来决定 的。模型可以让测试通过，但它决定不了应该存在哪些测试 — 因为那是关于生意的事实，不是关于代码的事实。

如何刻意练习：

在模型写代码之前，先写下通过条件。 如果你没法用一句话说清通过条件，那你手里的就不是需求，而是愿望。
带着假设去评审。 打开 diff 之前，先写下「这个改动可能搞垮生产的三条路径」，然后去猎捕它们。没有假设的评审，等于查错别字。
记一本 bug 账。 每出一个生产 bug，用一行写下：什么样的检查本可以逮住它？那张清单，就是你缺的测试。
训练自己区分「测试通过」和「确实正确」。 设计评测本身就是一项技能，这与在 AI 编程模型评测中分辨信号与噪声里讨论的是同一个问题 — 只有大于噪声的差异才算信号。

升值的技能 (2) — 生产环境调试：当上下文是隐性的

这里最有用的证据是 METR 的随机对照试验。16 位资深开源开发者，在自己的仓库里(平均 2 万以上 star、100 万行以上代码)处理了 246 个真实 issue。开始前，他们预测会快 24%；结束后，他们感觉自己快了 20%。实际上，他们 慢了 19%。

原因才是决定性的。一个你浸淫多年的成熟仓库，对 AI 来说近乎最差的条件 — 需求与仓库之外的上下文缠绕在一起，而人这一侧积累了 大量从未被写下来的本地知识。 模型没有这些。

这就是护城河的形状。AI 最弱的地方，正是上下文隐性、失败涌现之处。 生产环境恰恰就是这样的地方。Bug 不在 diff 里，它在 diff 与六年间无人记录的一堆决定之间的相互作用里。

以我自己的经历来说 — 在 KubeVirt GPU 直通 VM 112 天无法被调度的尸检里，原因根本不在仓库里。任何只读仓库的东西都找不到它。用 CloudNativePG 把 Postgres 跑起来再杀掉也一样 — 故障转移到底做了什么，不是读出来的，是把主库杀掉、量出那 23 秒才知道的。

如何刻意练习：

把一次故障从头负责到尾，并亲手写复盘。 学习发生在写作里，而不在救火里。
在安全的地方，故意把东西弄坏。 杀掉主库，把磁盘写满，切断网络。先预测结果，再去测量。 预测与测量之间的落差，就是你脑中那个系统模型的误差 — 而公司真正付钱买的，正是这个模型。
练习读系统，而不是读代码。 指标、链路追踪、内核日志、事件。把「观察 → 假设 → 实验」这个循环练进身体里。
去调试不是你写的代码。 这就是往后的默认状态：代码是模型写的，责任是你的。

升值的技能 (3) — 系统设计与权衡的品味

任何设计问题，模型都能给出一个像模像样的答案。它做不到的，是替你挑出 你的组织在未来五年里扛得住的是哪一种权衡。 因为这个判断依赖的事实并不在仓库里 — 团队规模、on-call 的成熟度、你付不起的那次迁移、快到期的供应商合同、半年后要离职的那个人。

品味并不神秘。它是 关于「上次是什么炸了」的压缩记忆 — 一个由你亲身承受过的后果所构成的先验。

如何刻意练习： 去读别人的复盘(公开的多得是)。每份设计文档里，都明确写出 你放弃了什么。 至少写下两个被否决的备选方案，以及否决的理由。然后在 12 个月后重新打开自己的决定，给它打分 — 没有这个反馈回路，长出来的不会是品味，只会是固执。

一条规则 — 没有「被否决的备选方案」的设计文档，不是设计，是偏好。

升值的技能 (4) — 需求考古：知道该造什么

最贵的 bug，是 被完美实现了的错误东西。 AI 把「造」的成本压了下来。这同时意味着，你现在能以快得多的速度、大得多的规模，造出错误的东西。 所以「知道该造什么」这项能力，会严格按照建造成本变便宜的比例而升值。

需求考古，是从人们说出来的话里，把他们真正需要的东西挖出来。绝大多数真需求哪儿都没写。它们像化石一样嵌在一句 2019 年的、谁也不敢删的 if 语句里，嵌在某段古怪的异常处理里，嵌在你正要替换掉的旧系统的默认值里。

有些岗位，处理这种模糊性本身就是职责 — 正如我在 Forward Deployed Engineer 备战里整理的那样，在那里，模糊性不是副作用，它就是工作本身。

如何刻意练习： 坐到用户旁边，看他们实际怎么做(和他们嘴上说的不一样)。问一句「这个失败之后，你接下来会做什么？」— 真需求通常就藏在这个答案里。挑出代码库里最丑的那个分支，一路挖到你搞清楚它为什么存在(那通常不是失误，而是需求)。在写设计文档之前，先写 一页纸的问题定义。 而且要错就趁早错、便宜地错、出声地错。

升值的技能 (5) — 主人翁：能挂上传呼机的那个人

你没法让模型背传呼机。不是因为它不够聪明，而是因为 问责要求有一个承担后果的主体。 组织希望每个决定后面都挂着一个名字，需要有人在凌晨三点醒来说一句「这个我来回滚」。

这里必须诚实。这更像是 一个社会与法律层面的事实，而非能力层面的事实。 制度终有一天可能改变。但社会性的事实非常顽固，而且它确实在给劳动定价。

沟通也属于这一类。如果你没法把一个权衡讲给读不懂代码的人听，你就没法让这个决定被通过。生成越便宜，越稀缺的行为就越是 做决定 — 而做决定，本质上是一种社会行为。

如何刻意练习： 把传呼机接过来。在没人愿意接的迁移上举手。发布一样东西，然后 在它身上待满一年。 后果能真正抵达你本人的那个反馈回路 — 判断力只在那里生长。

反驳 —「验证最后不也是 AI 来做吗」

这个反驳值得被认真对待。把它塑造成一个弱小的版本再打赢它，是自欺欺人。

它最强的形态是这样的：验证者定律说 凡是易于验证的，AI 都会拿走 — 而评审里有相当大的一部分正是易于验证的。类型错误、空指针解引用、明显的竞态、代码风格 — AI 评审工具已经做得很好。再加上测试生成、模糊测试，以及真正会跑起代码并观察其行为的智能体，验证中相当大的一块确实会被自动化。不仅如此，我上面引用的 METR 结果，连 METR 自己都加了限定 — 在 2026 年 2 月的更新中，他们宣布要修改实验设计，并表示到 2026 年初，开发者 很可能比他们 2025 年初的估计提速更多(尽管他们承认，关于提速幅度的证据很弱)。所以别把「慢 19%」当成一条永恒定律拿着到处走。那是对某一个时刻的测量。

以上我都承认。机械性的验证会被自动化，而且多半应该被自动化。 如果你的「验证能力」不过是抓出一个漏掉的空指针检查，那它同样在贬值。

但仍有一条边界留了下来。验证正确性，需要 一份可供比对的标准答案。 这份标准答案从哪儿来？竞赛数学和 LeetCode 有答案册；你们公司的结算系统没有。总得有人来决定「正确」是什么。

这条边界真实存在的最干净的证据，来自 DeepMind 的那个结果 — 在没有外部反馈的情况下让模型修正自己的答案，这种 内在自我修正 并没有提升准确率，有时甚至让它变得更糟。只有在把标准答案(oracle)交到模型手上时，改善才出现。那是 2023 年那一代模型的结果，此后模型已经大幅进步 — 别把当时的具体数字直接套到今天。但 这个结构性论点并不是模型能力的函数。 一个只能用自己的信念去检验自己信念的系统，无法凭空造出它并不拥有的标准答案。

在这里我要诚实地标注不确定性。我 不知道这条边界会被推到多远。 如果有一天模型在「你的生意里什么才算正确」这件事上判断得比你还好，那本文的建议就作废了。我不认为那一天很近 — 因为我认为约束条件是 对后果的接触，而不是智能。但「我不认为」是一种信念，不是证据。请把它握松一点。

要我下注的话，我押这边 — 即便在一个 AI 验证了绝大多数事情的世界里，仍然需要有人为那个裁决负责，而所谓「工作」，其定义正是负责。

结语

拒绝两个极端。

「开发者已经完蛋了」是错的。它假定整个技能组合被重新定价到零，而事实上它只是被 不均匀地 重新定价了。「什么都没变」也是错的 — 因为很多人赖以立身的那些项，恰恰就是变便宜的那些项。

让我把不舒服的部分也留下。这轮重新定价对初级工程师尤其残酷，因为那些正在贬值的技能，一直以来是 梯子最下面的几级 — 靠敲样板代码来熟悉代码库的那条路，正在被封死。对此我没有漂亮的答案。我能给的最好建议是 更快地靠近后果 — 哪怕只是很小的一块，也要在生产环境里拥有它，并且早一点站到那个「它坏了会呼你」的位置上，早到让你觉得不太舒服为止。

所有升值的技能，都共享同一个性质：它们无一例外地要求 与后果发生接触。 验证要求你知道什么会炸；调试要求你被呼叫过；品味只能从你曾经犯过的错里长出来。所以它们下载不到。也正因如此，要把它们训练进一个从未被呼叫过的模型里，目前依然很难。

浓缩成一句话 — 写代码的价格跌了，判断代码是否正确的价格涨了。