认知负载倒置：为什么 AI 建议让你感觉有帮助却精疲力竭

AI 生产力研究中有一个几乎无人提及的数字：39 个百分点。一项针对有经验开发者的研究中，参与者预测 AI 工具会让他们快 24%。完成任务后，他们仍然认为自己快了 20%。实际测量结果：他们慢了 19%。感知差距是 39 个百分点——而且每次迭代、每次代码审查、每个交付的功能都在累积。

这就是认知负载倒置。AI 工具擅长卸载廉价的认知工作——编写语法正确的代码、起草模板、建议函数名——同时产生了一类更难的认知工作：对不确定输出的持续评估。你并没有消除认知努力，而是将简单的一半自动化了，然后把困难的一半留给了自己。

"大脑过载"究竟是什么

研究人员最近将开发者描述了两年的一种状态正式化：持续 AI 辅助工作带来的认知疲惫。其底层机制是结构性的，而非偶然的。

当 AI 建议到达时，它会创造一个强制性的审查时刻。你可以接受或拒绝，但在不违背使用工具前提的情况下，你无法忽略它。每条建议都是一个微任务。单独来看，每个微任务都是微不足道的。但以现代编程助手生成建议的速度——每小时数十条——这些微任务变成了叠加在主要工作之上的持续中断流。

问题不在于建议本身，而在于中断节奏与验证的不对称认知成本的结合。有经验的开发者可以在部分心流状态下编写代码，依靠肌肉记忆和模式识别。审查 AI 输出需要不同的模式：刻意的、怀疑的、注意力密集的。这个工具隐性地要求你每 30 到 90 秒切换一次认知模式。

这种碎片化攻击尤为有害，因为重新进入心流状态代价高昂。保守估计重新进入时间为 15 到 20 分钟。激进的中断计划不会造成 15 分钟的损失——它们会彻底阻止心流状态的形成。

验证瓶颈

真正的生产力故事不在于生成速度，而在于工作转移到了哪里。

采用高 AI 编码的团队合并的拉取请求多 98%——但在代码审查上花费的时间多 91%。拉取请求大小增加 154%，而审查吞吐量下降。算术很简单：你大幅增加了需要审查的代码量，同时将其生产分散到人机配对中，而不是集中在深刻理解自己所写内容的工程师身上。

一个令人不安的事实使问题更加复杂：AI 生成的代码比人类编写的代码更难审查，而不是更容易。表面上它干净、符合惯用法、注释完善。错误埋得更深。人类编写的函数可能有明显的变量命名不一致，暗示"仔细看这里"；而 AI 输出表面上均匀精良，以一种压制该信号的方式。审查者必须对每个函数深入检查，而不是浅尝即止。

Sonar 的调查直接捕获了由此产生的认知失调：

• 96% 的开发者不完全信任 AI 生成的代码
• 48% 在没有验证的情况下提交它
• 38% 表示审查 AI 代码比审查人类编写的代码花费更长时间
• 59% 将他们的验证工作评为中等到大量

这不是漠不关心，而是过载。当每个拉取请求都包含 AI 生成的部分，而你的审查队列增长了 98% 时，对每个部分保持深度审查在认知上是不可能的。开发者不是选择跳过验证，而是在压力下做出分诊决策，而 AI 代码在视觉上与值得较少审查的代码没有区别。

建议层的决策疲劳

代码审查是可见的瓶颈。决策疲劳在更上游积累，在建议交付的那一刻。

每条内联建议呈现一个二元选择：接受或忽略。接受有下游验证成本。忽略有可能做出错误判断的风险。两种选择都没有自然的认知锚点。好的代码审查积累了规范——命名约定、测试覆盖要求、架构模式——让有经验的审查者能够快速形成判断。内联 AI 建议先于这些规范。你在实时评估半成品想法，没有建立什么使建议值得接受的标准。

学术评审 AI 辅助同行评审的研究发现，AI 辅助评审将论文接受率提高了 3.1 个百分点，对于边界提交上升至 4.9 个点。AI 辅助评审在 53.4% 的比较中得分优于人类评审。这不是成功的故事，而是揭示了当评估者在认知负载下运作时，他们会默认接受看起来最自信和连贯的输入——而 AI 输出经过校准看起来两者兼具。

同样的动态在代码审查中上演。一个表述良好的 AI 生成函数通过审查，不是因为它正确，而是因为审查者的决策疲劳默认接受看起来自信的输出。生产事故随之而来。

多任务陷阱

加载中…