AI编程争论焦点错了。写代码可以外包，理解系统不能。调试是构建心智模型的必经之路，AI反而把工程师推向架构角色。

关于AI与编程，有两种流行看法：一种说AI写出的代码糟糕，修它的错比自己写还费时，基本没用；另一种说AI代码好到终将让程序员失业。作者认为两者都抓错了重点，因为它们都盯着"谁写代码"。

记语法、背代码从来不是这份工作的核心。我(原文作者)一直靠文档、搜索引擎、Stack Overflow上的例子和同事的代码工作。现代系统绕不开这点，一个典型应用涉及TypeScript、Python、Go、YAML、Dockerfile、SQL、CI流水线等十几种技术，没人能把细节全记住。既然抄Stack Overflow历来合理，让机器生成代码为何就本质不同？

另一个理由：我们一直都在维护没写过的系统。接手别组服务，离职同事写了其中一半，你负责的部分三个人贡献过，你甚至记不清哪个函数是谁写的。一段时间后你仍会把它当作"自己的"，不是因为每行都出自你手，而是因为你理解它：它做什么，为何如此表现，边界和依赖在哪，出问题时怎样。这才是所有权的感觉。

AI编程的问题不在机器写代码，而在人容易连思考一起交出去。"我明白要做什么，你写给我"和"让它跑通"后照单全收，两者天差地别：前者外包了打字，后者外包了理解。写代码容易外包，调试很难不交出重要的东西。调试强迫你构建系统模型：你有一个预期结果，实际却不同，于是倒推本应发生什么，链条在哪一环偏离。反复练习后你会形成对系统行为的直觉，而AI让"甩错误、收补丁、再报错"的循环变得太容易，你可以在从未建立心智模型的情况下交付能跑的软件。表面上像胜任，实际上只是依赖机器维持幻觉，当机器解决不了问题或token耗尽时，没有模型的人立刻暴露。

所以放开用AI，让它写样板、提醒语法、探索陌生库、实现琐碎部分，但把关键留给自己：理解问题、决定系统行为、做架构决策、能解释各部件为何如此组合。要能解释系统为何失败，你才能真正成功改变它。如果每次挫败的调试都能甩给AI，就很少有人愿意花四个小时搞清楚系统为何如此表现，而那四个小时正是心智模型的来源。当写代码变廉价，差异化转向架构、集成、分布式系统、可观测性、失败模式与权衡。最好的工程师不会拒绝机器写码，而是借机器加深对系统的理解，同时牢牢掌握决策。

原文：https://var0.xyz/posts/beyond-recall-and-the-illusion-of-competence.html