AI 一分钟能写完的代码,我学了三年的编程还有必要吗?

上周我在一个上百万行的老仓库里让 Agent 修一个 bug。

它四十秒就给出了改动，很小，看着也对。我花了两个小时才敢按下合并。

不是它写得难看——恰恰相反，写得很整齐。时间全花在确认它没有顺手动到别的地方。那两个小时里我读的代码，比它写的多了十倍。

这就是这篇文章想说的全部：AI 把写代码的价钱压下去了，把读代码的价钱抬起来了。 所以问题不是"还要不要学"，而是"该学的那部分挪到哪去了"。

这话听着挺绝对，边界我会在第 05 节划清楚——不是所有代码都值得读，远不是。

▲ 它写得快，你读得慢——钱就在这个差价里

一份覆盖 6.23 亿次代码变更、跨度 2023 到 2026 年的行业分析（GitClear，2026 年 6 月）给了这样一组对照：

把这张表读完，结论有点不客气：产量涨了四分之一，账面上的债涨得更快。

重复的代码不会当场咬人。它会在某处逻辑要改的那天咬人——你改了五份里的三份，剩下两份在别的地方，你既不知道是谁写的，也找不到当初为什么这么写。AI 生成的代码还有一层麻烦：它写出来的样子是对的，所以你不会怀疑它。这个成本不会出现在本周的交付里，它会出现在第十八个月。

另一组数据更扎心。研究机构 METR 做过一次随机对照实验：16 名资深开源开发者，246 个他们自己仓库里的真实任务，随机分成"可以用 AI"和"不能用 AI"两组。

结果：允许用 AI 的那一组，平均慢了 19%。

真正值得琢磨的是前后两个数字。开工之前，这些人预测自己会快 24%；做完之后，他们仍然觉得自己快了 20%。

慢是真的，感觉快也是真的。研究者把它叫作感知差：AI 带来的摩擦太碎了——等它输出、读它的建议、判断能不能用、把它塞进一个它并不真正理解的代码库——每一处都只有几十秒，碎到你根本不会记在账上。

今年 2 月，这个团队想重测一次，结果测不下去了。一半的开发者不愿意被分到"不用 AI"那一组，对照组消失了。

这件事本身比结论更能说明问题：工具已经撤不回去了，而现在连"它到底让你快了还是慢了"，都已经很难用实验回答。

因为瓶颈换位置了。

写代码的时间被压到接近零之后，剩下的时间全是"判断这段代码到底对不对"。而判断这件事，没法外包给那个给出答案的东西——它给出的答案永远看起来是对的。

同一个模型，在你自己写熟的代码里是加速器；在你不熟的代码里，它是一台更快的盲写机，它让你更快地产生你不理解的改动。

所以那句老话要改一改：你能用 AI 跑多快，取决于你能把代码读多懂。 提示词技巧的天花板，从来不是模型，是你的理解力。

写到这里，最自然的反驳来了：让 AI 把代码给我讲一遍不就行了？解释两百行代码的 token 只要几分钱，我何必自己读？

这个反驳的前半句是对的：讲，确实便宜了。 错的是后半句——它把"讲给你听"和"你听得懂"当成了同一件事。

AI 把两百行代码讲成一页文字，这页文字进了你的脑子，还得拿你已有的东西去对：这个变量为什么存在，这条分支在防什么，这两段为什么长得这么像。你脑子里有这张地图，它讲的三分钟能一一对上，讲错的那一句你会当场起疑；你没有这张地图，它讲的三分钟就只是另一篇看起来对的文字——你只能点头。点头不是理解，是相信。

而"相信"的下场，02 里已经用数字摆过了：慢了两成还觉得自己快了两成，给出的答案永远长得像对的。token 便宜下去的是"讲"，一点没便宜的是"发现它讲错了"。 后者没有任何 API 可以调，能调用的生产资料只剩一样：你脑子里那张地图。

这也是我说"要读代码"的真正原因，跟情怀无关：检索解决的是信息在哪，理解解决的是信息对不对。前者的价格在跳水，后者的价格在上涨——不是因为这活变难了，而是因为用的人多了、会的人没变多。

这条反驳比前一条更硬，而且它有一半是对的。

编译报错、单测失败、类型不匹配——凡是机器能判定的错，AI 的自纠循环收敛得比人快得多，还不会赌气。你把报错贴回去，它改，再跑，再改，三五轮就绿了。这类错，人去逐行读纯属浪费时间。

麻烦在另一类错身上。业务逻辑写反、边界漏掉、并发下的竞态、一次迁移把数据改坏、一个 catch 把异常吞掉——这些不报错。它们的特征恰恰是 CI 全绿、页面正常、所有人都觉得没事，然后在某个你没想到的时刻一次性结算。01 那张表里的静默异常 +47%、错误掩盖 +47%，说的就是这一类：不是它写错了被抓到，是它写错了没被抓到。

自纠循环还有个容易被忽略的前提：它改到 CI 绿为止，而 CI 是你写的。 测试只能证明代码符合测试，证明不了测试符合你真正想要的东西。你把验证整个交出去，等于把"什么叫对"也一起交出去了——而需求最不清楚的那一段，它不会停下来问你，它会挑一个看起来合理的假设继续往下写。

所以真正的分界线不是"要不要读代码"，是错了之后能不能回滚。一次性的脚本、原型、内部小工具、改错了能一键还原的东西，让 AI 写完跑通就走，完全合理，我自己也这么干。要读的只有一类：你得长期背着、别人会来问你、出事那天要你签字的那部分。

看招聘侧的数字。多家招聘数据机构的汇总口径并不完全一致，所以看趋势、别看小数：

同期，一家公开披露财报的软件公司把支持团队从约九千人压到约五千人，并说明本财年没有新招工程师。

这组数字常被读成"编程没用了"。更准确的说法是：被搬走的是"把已经写清楚的需求翻译成代码"这一段——也就是过去十年里初级工程师的练习场。

没被搬走的是"需求根本写不清楚的时候做判断"这一段。而后者从来不是听课学会的，是在前者里泡出来的。

练习场拆了，不等于手艺作废，意味着你得自己找地方练。

▲ 它交上来的是代码，你得交出的是判断

三件事，按优先级排：

七条里勾不到四条，就要警惕了——尤其是最后一条，那是 AI 最容易留下的痕迹。

所以要看外部指标。我写了个三十来行的脚本，扫自己的代码库，输出三个数——重复块密度、静默异常数、调用密度。在自己的仓库上跑出来是这样：

扫描目录：技术公众号文章Python 文件：10 个   代码总行数：979| 指标 | 计数 | 每千行 ||---|---|---|| 重复代码块（≥5 行） | 4 | 4.09 || 静默异常处理 | 0 | 0.00 || 函数调用 | 543 | 554.6 |

顺手又拿两个更大的目录做了量级对照：

这里必须说清楚：这三个目录里的代码是不是 AI 写的，我无法确认，所以这不是归因，只是给你看指标的算法和量级。但有一个规律是常识也认的——代码规模上去之后，重复密度涨得更快，因为债是复利。

另一个外部指标来自每年发布的那份 DevOps 行业研究（DORA）：每多四分之一的 AI 使用量，交付的稳定性大约下降 7%。速度看起来是白拿的，稳定性是有人在后面付账。

回到那个问题：AI 一分钟能写完的代码，我学了三年的编程还有必要吗？

因为要学的部分挪了位置。写的手艺在变便宜，读的手艺、判断的手艺、清理的手艺在变贵。你不需要跟模型比谁敲得快——那是必输的；你需要的是能一眼看出哪儿不对，这个能力模型暂时给不了你，而且它写得越多，市场越缺这种人。

AI 能替你交付一个功能，也能把报错改到不报为止，但它交付不了"我知道这个功能是对的"这句话——毕竟什么叫对，是你定的。而这句话，恰好是别人付你钱的原因。