Nwaneri 那篇帖子真正该看的不是“又一个开发者被 AI 改写了工作流”，而是他说的一句话：他现在让 AI agent 找 bug、改代码、提交、开 PR，自己做的是“读 git log 搞清楚发生了什么”。话到这里，问题已经不在代码生成那一侧了。
翻译成人话就是：他让一个自己信不过的东西改他的代码库，然后靠考古来确认到底改了什么。他自己说 AI 生成的改动“不是很好”，又说这样能同时打三个 hackathon，“只靠自己的大脑满载是不可能的”。这两句放在一起，账就已经对不上了。
先不急着下对错。同时打三个 hackathon 这件事本身就得拆一下。hackathon 的产出物是什么？一个 demo，能在评审面前跑起来，能讲个故事。评价标准从来就是“看起来行”，不是“代码真好”。所以“同时参加三个 hackathon”这个生产力指标，它衡量的不是代码质量，是项目数量。AI 堆出三个 demo，只说明它在低验证成本、高演示价值的场景里能打，说明不了太多编程能力的事。
这条先放一放。
真正让我觉得值得写的是 Nwaneri 这层对比。他说 C 程序员不需要逐行验证编译器输出，而他现在还要读 AI agent 产生的每一个 diff。他觉得这个差距只说明自己还没走到“干净抽象”那一层，还在被 AI 的不可靠拖着。
他把对比的方向搞反了。
C 程序员不验证编译器输出，不是因为编译器比 AI 聪明，是因为编译器背后有一套几十年一点点建起来的信任链条。编译器有明确可验证的行为，每一层转换都能溯源，错误能稳定复现，而且编译器本身就是代码，实在不行你把编译器自己再编译一遍。这个信任厚到什么程度？厚到整个软件行业默认编译器可靠，没人去读机器码。这是制度性信任，不是能力问题。
AI 不是这个位置的东西。AI 的每次输出都是概率采样，同样的输入给同一个模型，不同时间可以给你不同结果。它没有一个稳定、可被检查的转换规则。Nwaneri 还在读每一个 diff，不是旧习惯没改掉，是 AI 目前处在“做完编译器认证”之前的状态。拿编译器类比 AI，最大的错误在于：编译器恰恰是 AI 现在最不敢做成的形态。
所以他说“还在读 diff”是个待解决的过渡状态，我不同意。在 AI 的验证问题被某套类似编译器认证的体系解决之前，逐行读 diff 就是唯一可信的工作流。这不是过渡，是常态，而且很可能长期是常态。他当成一种临时性的不适，但这才是 AI 编程工具现阶段最深的结构特征。
评论区 leob 说的另一件事也戳中了。他说如果开发者只写 prompt 而不知道底层手艺，就会变成“大脑袋但基本不用的 prompt monkey”。这个比喻糙，但糙得准。真正会退化的还不是那些底层知识，而是 Nwaneri 和 Andrew R 都提到的那个：读自己 diff 的能力。
Andrew R 说得更具体：技能里最先退化的是读自己的 diff，因为 prompt 绕过了构建这项能力的训练循环。Nwaneri 同意，说它像肌肉一样需要练。这条观察成立，但我比他俩更悲观。
读 diff 表面上是在看代码改动，往深里看，是在大脑里维护一份代码库的因果模型。你看见一处改动，能判断它对别处的连锁影响，不靠写代码时的人工智能，靠的是你对这个系统运行逻辑的把握。这个因果模型怎么一点一点建？一行一行写、一遍一遍改。用 prompt 生成代码，绕过的不是打键盘，恰恰是这套因果认知模型的训练过程。
所以 Nwaneri 说“读 git log 搞清楚发生了什么”，这是什么信号？认知模型已经开始和代码库脱钩。健康的工作流里，代码库状态应该是大脑模型的一个投影：你改了什么、为什么改、哪里可能出问题，脑子里都有对应。当你需要靠 git log 去考古 AI 改了什么，你就不再是代码库的主人，是代码库的观察者。角色的这个变化，才是那篇帖子真正在暴露的东西。
Nwaneri 还承认了一件事，很关键：他会看 AI 产出的 diff，但这个动作最终会败给时间。“我同时在做其他几条线”的时候，逐行读 diff 是第一个被砍掉的。为什么？因为逐行读 diff 是纯粹的验证活动，它不产生新的可见进度。在三个 hackathon 的进度压力下，验证永远最先被压缩。验证被压缩，认知模型继续脱钩，然后你更依赖 AI 做本该由认知模型完成的判断，再然后你更没时间验证。
这是负反馈。
Mudassir Khan 提了一个我觉得评论里最有建设性的做法：强制在接收 AI 生成的 patch 之前加一个解释步骤。AI 必须解释改了哪、为什么改，然后他才接这个 patch。这个做法不复杂，但它直接顶在那个负反馈循环的核心上：把验证从“事后自己读”变成“事前让 AI 陈述因果”。等于要求 AI 在你大脑之外维护一份代码库因果模型的双份记录，再逼你动脑审查它。
但这里有个绕不开的问题：AI 解释自己改了什么，这个解释本身也是生成的。它可以生成一个漂亮、合理、与真实改动逻辑无关的解释。这个机制成立的前提，是解释环节真的多出一层人脑参与，而不是变成另一个被压力跳过的步骤。如果进度够紧，解释也就是走过场。
所以回到三个 hackathon。用它证明“编程能力提升”，这是生产率幻觉的样本。真正在增长的工程量没有变，验证负担不过是从写代码时前移到了读 diff 时。验证环节一旦被压缩——而且它必然被压缩——这三个 hackathon 的代码质量就是拿“能跑通”定义的。能跑通是底线。把底线当成果，这个账里的窟窿就太大了。
有一个被普遍忽略的事实：AI 编程工具现在解决的其实不是验证成本，是产出成本。写代码的时间被压缩了，但验证代码是否正确、验证 AI 理解是否准确，这部分成本反而因为 AI 介入变得更隐蔽，也更容易被整个跳过。
我再算一笔账。一个人一天能高质量读 diff 的时间是有限的，假设四五个小时的高强度审查，那 AI 生成速度再快，瓶颈不会消失，只会转移。生产力的真正上限从来不是代码生成速率，是人对系统复杂度的心智承载上限。目前没有任何 AI 编程工具在帮你提高这个上限，它只是帮你更快撞上去。
换句话说，AI 让你更快到达那个心智承载上限，但不会把上限推高。你从“三天写一个项目”变成“一天写三个项目”，增长的只是项目数，不是你对系统复杂度的承载能力。这个能力不去刻意练，就会退化。
落判断。
我的判断摆在这儿：这股“从写代码转到写 prompt”的叙述，把两件事混在一起了。代码产出提速，这是真的。软件工程能力被放大，这件事没发生，或者只在低验证成本、高展示价值的场景里成立。Nwaneri 说的“我还在读每一个 diff”，恰恰证明第二件事没发生。而三个 hackathon 又恰好是低验证成本、高展示价值的典型场景。所以他的证据链是反的：它证明 AI 在这些场景里好用，没证明 AI 在需要长期维护的软件工程里改变了什么。
评论区 leob 还有一句：AI 越进步，开发者的检查环节可能越小，最后把开发者挤进很小的缝里，再一转头看见电工木匠因为 AI 数据中心热潮需求涨了。Nwaneri 回的是：如果检查也自动化了，总得有东西去验证那个自动化检查器，所以工作不会消失，只是往上移一层。
这个判断我基本不认。检查如果被自动化，那个“验证检查器”的工作不会自动落在现有开发者身上，它会落在一套新系统上，而这套系统的构建方式和现在开发者的技能栈未必有直接关系。往上移的是工具链的缔造者，不是所有开发者都会跟着移上去。这中间有一次筛选，筛掉的就是只停在 prompt 层、没有底层因果认知模型的人。
证伪条件也很具体。如果哪天出现一个 AI 编程工具的验证层，它能像编译器一样通过某种系统化的可验证性认证——稳定、可复现、可被独立审计，且它的验证结论不需要人脑抽检——那我关于“验证成本是 AI 编程工具真正瓶颈”的判断就作废。那个东西出现之前，我不改口。
在它出现之前，所有关于 AI 编程工具生产力的承诺，默认打七折来听。这三折是做验证的钱。它没有被省掉，只是被换了个地方藏着。Nwaneri 那篇帖子值得写，不是因为他想清楚了，而是因为他把藏钱的地方无意间露了出来。