AI 没有让编程变容易，它只是让编程变得以不同的方式更难

原文来源：Communications of the ACM — ACM 的这篇观点文章用认知科学的框架分析了 AI 编程助手对开发者认知的影响，结论是：困难并没有消失，只是从"怎么写出这段代码"变成了"这段代码到底对不对"。

如果你在过去两年里用过 Copilot、Cursor 或者 Claude 写代码，你一定有过这种体验：代码生成得又快又好，但接下来你花了同样多的时间——甚至更多——去检查它是不是真的对。

这种感觉不是错觉，它是 AI 编程时代最根本的认知转变。

一篇发表在《Communications of the ACM》上的观点文章给出了一个有力的框架：AI 没有让编程变容易。它只是让编程变得以不同的方式更难。

编程的认知负荷，从何而来？

要理解 AI 改变了什么，先要知道编程原本为什么那么难。

几十年的认知科学研究（Brooks、Pennington、Soloway 等人的工作，以及 Siegmund 团队的功能性磁共振成像研究）一致表明：编程对人的认知系统提出了极其严苛的要求。

具体来说，它同时压榨着两种记忆系统：

工作记忆——你正在处理的信息，比如当前函数的逻辑、变量的状态、循环的边界条件。工作记忆的容量极其有限，普通人大概只能同时记住 7±2 件事。
长期记忆——你需要调用的知识，比如 Python 的列表推导式怎么写、React 的 useEffect 依赖数组怎么传、某个 API 的签名是什么。

编程的难度在于，你必须同时维护多个相互依赖的抽象概念（控制流、数据流、对象关系），而且这些抽象模型非常脆弱——一次上下文切换就能让你的"心理模型"灰飞烟灭。这也是为什么程序员最讨厌被中途打断。

—— 广告 ——

AI 做了什么：外部记忆系统

AI 编程助手正在改变的是这个认知结构中的第一环：它充当了一个非常高效的外部记忆系统。

当你想不起某个 API 的签名时，Copilot 帮你补全了。当你需要一段样板代码时，Claude 帮你生成了。这在认知科学上对应着三个理论框架的支持：

分布式认知（Hutchins 提出）：认知活动不仅仅发生在大脑里，还延伸到外部环境和工具中。AI 成为这个系统的一部分。
认知负荷理论：AI 降低了"外在认知负荷"（语法回忆、样板代码），让你有更多工作记忆用于"内在推理"。
扩展心智假说：如果一个工具可靠、随手可用、你信任它，它就会成为你认知架构的组成部分——就像你不需要思考笔在哪里就能写字。

Barke、James 和 Polikarpova 的实证研究证实了这一点：使用 Copilot 的开发者确实把更多精力从写代码转移到了验证和集成生成的代码上。

移除了什么，保留了什么

把编程的认知负荷拆开来看，AI 移除了这些部分：

语法回忆不完美的代价
API 查阅和样板代码生成的时间
低级别的记忆瓶颈

但它没有移除这些，甚至可能增加了：

概念推理的需求——你需要知道要构建什么、为什么要这样构建
调试和重构的能力——AI 生成的代码不保证正确，它只是看起来像对的
架构决策和影响分析——在大型代码库中改一行代码的影响范围，AI 没有上下文
验证和集成的时间——审查、测试、理解 AI 生成代码所花的时间，现在是你的主要工作

论文作者的一个关键洞察是：如果开发者把太多思考外包给 AI，他们内心的"心理模型"会变弱。 而稳定的心理模型恰恰是在大代码库中导航和推理的基础。

四个重大转变

1. 编程的门槛降低了，但质量门槛可能更高了

进入编程的门槛降低了——你不必花三个月背语法。但要写出好的代码，你需要更好的判断力。这是一个悖论：产出代码的门槛降低了，但产出好代码的门槛反而可能提高了， 因为判断力比记忆力更难培养。

2. 工作的困难从"怎么写"变成"这样写对吗"

新手的困难从语法错误转向判断 AI 生成的解决方案是否合适、可维护、符合系统约束。这需要更深的软件工程理解，而不仅仅是表面的语言特性。

3. 教育必须转型

课程重心应该从语法记忆转向：架构设计、接口设计、状态管理、故障模式、测试构建、安全管理、长期可维护性。代码成为思想的多种表现形式之一，开发者仍然需要分析、调整和修改 AI 的输出。

4. 程序员的角色从"知识容器"变成"编排者"

最优秀的开发者不再是打字最快的或记忆最牢的，而是那些能在保持深层心理模型的同时，把所有干扰性的低层次工作外包出去的人。

为什么这篇文章值得你读

我不认识你，但这篇文章我反复读了三遍，因为它说的每一句话都戳中了我使用 AI 编程的真实感受。

上周我用 Claude 写一个前端组件，它 30 秒就生成好了。但我花了 40 分钟看完它的代码，改了三个边界条件的 bug，重构了两个逻辑分支，加了一堆测试。最后我算了一下——没有 AI，我自己写这段代码可能也只要一个半小时。

快了吗？快了。但快的不在中段。

以前编程的瓶颈是"写不出来"——你知道要什么，但语法没记熟、API 不熟悉、样板代码写到手酸。

现在编程的瓶颈是"不确定对不对"——代码跑起来了，但你真的理解它背后的逻辑吗？它处理了所有的边界条件吗？下次有人改这里的时候会出问题吗？

AI 没有消除编程的困难。它只是把困难从"怎么表达"转移到了"怎么判断"。

对于新手来说，这可能是更难的转变——因为"不会写"的困难是可见的，你会知道自己不会；而"不会判断"的困难是隐性的，你可能都不知道自己做出了错误的判断。

对于有经验的开发者来说，这可能是好消息——你的架构能力、判断力、系统思维不仅没有贬值，反而更值钱了。AI 把低层次的工作剥离了，留下的全是智力密集型的判断。

写在最后

这篇文章发表在 CACM 上，属于学术刊物的观点栏目，引用格调相当高。它的核心观点其实很简单：编程的认知负担没有消失，它只是从检索转移到了推理。

对这个观点我还有一个补充——AI 带来的不是简单地"转移认知负担"，而是创造了一种新的认知不平等：那些本来就善于判断和架构的人，得到了一个超级放大器；而那些连基本判断能力还没有建立的新手，可能会被困在一个"看起来在进步、实际上在绕路"的循环里。

所以，如果你是一个正在学编程的人，我的建议是：用 AI 加速学习，但不要让它替你思考。 每次它生成一段代码，多问自己一句：我理解为什么这段代码是对的吗？

如果你已经是一个有经验的开发者，那你应该已经发现了——这一年多来，你花在"读代码"上的时间，可能已经超过了"写代码"的时间。这很正常。这就是编程在 AI 时代的新常态。