AI写代码时，你不是在偷懒，是在重新分配大脑带宽

你有没有过这种体验：改一段三年前自己写的代码，第一反应不是看逻辑，而是先翻文档、查Git历史、问同事——哪怕代码就在眼前？你不是忘了，是当初就没把所有细节装进脑子。因为人脑从来就不是硬盘，它只存‘够用的模型’。

Peter Naur在1985年就指出：程序员真正的产出，不是跑起来的程序，而是脑子里那个关于“这系统怎么运转”的理论。代码只是这个理论的快照，而且常常是过期的快照。 这意味着：所谓“读懂代码”，本质是重建一个临时理论——而AI工具正在悄悄改变这个重建的成本结构。

现在，你让AI写一个API路由处理器，它可能生成80行代码。你扫一眼，发现它漏了权限校验的钩子，立刻否决。这个“一眼看出不对”的能力，恰恰证明你脑中那个理论依然在运行——只是它不再需要记住钩子该插在哪一行，只需要知道“这里必须有钩子”。 这意味着：你没丢掉理论，只是把记忆负担，换成了判断负担。

更关键的是，AI本身并不构建Naur理论——它不理解“为什么要有钩子”，它只匹配“有钩子的代码长什么样”。但它迫使你更频繁地 articulate（说清楚）自己的理论：你得把模糊的直觉翻译成提示词，得在AI输出里快速验证一致性，得亲手挑出那10%可用的部分。 这意味着：AI没替代理论建设，它把理论建设从后台日志，推到了前台操作界面。

所以真正发生的变化不是“工程师变浅了”，而是“理论的颗粒度开始可调节”：你可以选择深挖某一层（比如数据库事务隔离级别），同时放心跳过另一层（比如某个JSON序列化库的内部重试逻辑）。 这背后的逻辑是：工程知识从来不是均匀分布的晶体，而是一张有焦点、有雾区、有快捷路径的活地图。

下次你否决AI生成的代码时，别想“我又没搞懂”，试试问自己：我刚刚捍卫的，是哪一部分理论边界？