认知投降

作者: Addy Osmani 原文链接:https://addyosmani.com/blog/cognitive-surrender

认知卸载(Cognitive offloading), 是将任务委托给AI, 但答案的主权仍在自己手中。

认知投降(Cognitive surrender), 则是AI的输出悄然成为你的输出, 而你已毫无检验的欲望。

对于软件工程师而言, 这两者之间的界线几乎每天都在脚下位移, 而我们中的大多数人, 正在不知不觉中越过它。

---

昨天我听到一个词, 让我深有触动：认知投降（cognitive surrender）。这个词来自宾夕法尼亚大学沃顿商学院的一篇近期论文——

史蒂文·肖与吉迪恩·纳夫合著的《思考：快、慢与人工智能——AI如何重塑人类推理, 以及认知投降的兴起》。

这一概念本有神学渊源, 但用于AI语境则是崭新的, 对任何一个身边常驻AI助手、每天写代码的人来说, 都直击要害。 他们的核心区分, 值得铭记于心：

• 认知卸载: 如计算器、搜索引擎、导航仪。你把"如何做"交出去, 但"做什么"仍由自己掌控。你仍会判断结果是否合理, 并在必要时出手干预。
• 认知投降: 是你彻底停止自主构建答案的那一刻。AI的输出变成了你的输出, 无从推翻——因为你从未形成过独立的看法, 无从比较。

肖和纳夫通过三项实验、1372名参与者发现：仅仅是AI的存在, 就足以令人缴械投降。在AI给出错误答案的情形中, 73%的参与者照单全收。

更令人忧虑的是：当AI可用时, 参与者的自信心反而上升——尽管有一半答案是刻意设置的错误。他们借用了模型的自信（模型总是信心满满）, 并将其当作自己的自信。

这种"借来的自信"效应, 让这个问题从普通认知科学的命题, 演变成了一个关乎软件工程的命题。

投降在我们工作中的面目

在轻松的事情上，我们大多不会投降。当AI凭空捏造一个API或虚构一个导入语句时，我们能察觉。

真正的投降，发生在更深处——在那些独立判断的成本显得与任务不相称的当口。

以下是我亲眼目睹的几种情形，大多发生在我自己身上：

看差异比对（diff）。 AI生成了一个600行的PR。你扫了一眼，变量名看起来还行，测试也是绿的，于是你批准了。

但其中某处，有一个事务边界的微妙顺序变动，或者一个你没想到要检查的边缘情况默认值被悄悄改掉了。你没有审查代码，你只是背书盖章。这次投降，是决策的缺席。

调试一个你未必真懂的错误。 堆栈追踪看起来触目惊心。你把它粘给AI，它返回一个修复方案，有效。你继续前行。

两周后，类似的症状再度浮现，你才意识到：你从未真正理解那个原始的Bug，你只是消除了它的表象。你脑海中关于这个系统的心智模型，早在你毫不知情时，就已悄然出错。

做一个架构决策。 你不确定两个服务之间该用消息队列还是直接调用。你问了AI，它给出一段听起来理由充分的段落并选了其中一种。你照做了。

你没有思考自己的吞吐量、失败模式、重放语义——你用一个动作，同时接受了模型对问题的框架，以及模型的答案。

学习新知识。 这是Anthropic技能养成论文有数据支撑的发现。工程师在学习新库时，若用AI生成代码，事后的理解测验成绩比对照组低17%；

而用AI进行概念探究（提问、探讨权衡）的工程师，则不相上下。同一个工具，姿态不同，结果迥异。

贯穿所有这些情形的，是同一条线索：模型给出了一个完整的答案，而我们接受了它，而非构建出自己平行的视角。

有时这是正确的，有时这是投降。两者从内部感受起来，别无二致。

与"理解债务"的关联

我曾写过"理解债务"——系统中存在的代码量与任何一个人真正理解的代码量之间日益扩大的鸿沟。认知投降，正是理解债务不断积累的机制。

每一次投降，都是一笔微小的借贷。

代码库又多了一个你不甚了解的补丁，架构又吸收了一个不是你做出的决定，测试套件又多了一个你没有主动设定的测试用例。这些在发生的当天，都不像问题。但它们会复利滋生。

MIT的《你的大脑遇上ChatGPT》论文在神经层面呈现了同样的规律：依赖AI写作的人，神经连接度可测量地下降，对自己刚刚产出内容的记忆更弱，重建自身推理过程的能力也更差。作者将其称为"认知债务"——借鉴自技术债务的概念——短期获益，长期复利偿还。

将两个框架合并来看：认知投降是你举债的方式。理解债务是那张账单，以失落的心智模型为单位计价。下一次系统出问题、团队中没有人能从第一性原理重建这个系统时，利息便会一并结清。

AI本身不制造债务。你带着什么姿态使用它，才是关键。同一个模型，能让一位工程师的心智模型日益空洞，也能让另一位工程师愈加敏锐——取决于他是用它来思考，还是用它来代替思考。

为何软件工程师格外脆弱

我们工作的若干特性，使我们比普通知识工作者更易暴露于这一风险之下。

表面信号默认看起来是正确的

生成的代码能编译，能过 linter，能运行，风格与文件其余部分一致。

大多数领域，AI输出不会有如此强烈的"看起来合理"滤镜。我们的领域有，而这是个错误的滤镜。

表面正确，不等于系统正确——两者之间的缝隙，恰恰是投降藏匿的地方。

吞吐量是可见的指标

合并的PR、上线的功能、关闭的票据——这些无法区分"我构建了这个并且理解它"与"AI构建了这个而我审批了它"。

组织在短期内对两者等价奖励。投降，在仪表板上是隐形的。

自信可以干净地转移

模型说话用陈述句。代码审查往往将陈述句视为权威。

当AI写下"此处使用300毫秒的防抖以避免卡顿"，听起来像是积累了多年的机构知识——即便那个数字是模型当场编造的。

你继承了它的确信，却没有继承它（根本不存在的）推理。

工作是可以累积复合的

每一次投降都为下一次铺路。一旦你接受了某个你没有完全理解的代码块，对那个块的下一次修改几乎必然又是一次投降——

因为形成独立判断，如今需要先重建你当初跳过的那部分。投降，具有路径依赖性。

我并不是在反对AI编程工具。姿态比工具更重要，而我们至今还未养成足够多应有的习惯。

校准的问题

肖本人谨慎地避免危言耸听。他的表述，是我愿意原封不动转述给所有认真使用这些工具之人的：

认知投降并不等于说AI是坏的，或使用AI是不理性的；在很多场景下，AI能提升判断力。

关键问题在于校准：知道AI何时在帮助你思考，何时在悄悄替你思考。

要不断问自己：我是在对这个答案形成独立的判断，还是只是在全盘采纳AI的观点？ 这是两种不同的心理行为，从外部看却如出一辙。

以下是我开始使用的几个启发法，让自己保持在卸载而非投降的一侧：

在读输出之前，先构建一个预期。 在对非简单任务运行AI之前，我会写下（哪怕只是在脑海中）我认为答案应该是什么样的：

三行还是五十行，队列还是直接调用，Bug在这个模块还是那个模块。当AI的答案与我的预期吻合，说明我在正轨上； 当它不吻合，我才有真正的选择可做：是我错了，还是它错了？而这个选择，正是投降所跳过的。

像AI没有写它一样审查差异比对

假设是你团队里一位初级工程师提交了这个PR。

你会仅凭"测试通过"就合并吗？不会。作者是模型时，同样的标准理应适用。

工作的性质没有改变，改变的只是作者。"看起来没问题"，依然不算审查。

要求模型反驳自己

大多数模型会给出一个充满自信的答案，然后——当被提示时——又能给出一个同样充满自信的反驳。

这第二步几乎不费力气，却能打破借来的自信效应。如果你无法判断哪个答案才是对的，你已经找到了一处你正要投降的地方。

留意自己疲惫的时刻。 投降是疲劳现象。当天第一个PR，你会认真审查；第五个，你只会扫一眼。

我信任的那些资深工程师，都不约而同地形成了某种版本的原则："当我太累而无法做出评判时，就停止让AI生成。"

这种自我认知，如今已是工作的一部分。

追踪自信从何而来

如果你在会议上为某个设计决策辩护，却无法真正重建为什么要这样做，只知道AI建议了这个而且当时看起来合理——

那你已经继承了模型的自信，却没有继承它之下任何的推理。这是投降留下的痕迹。趁对话结束前，回到代码中，重建这个"为什么"。

工程层面的抵御之道

个人启发法固然重要，但也有结构性的应对方式。我过去几个月写的大部分内容（关于Agent技能、AI驱动工程、理解债务），本质上都是关于如何搭建让投降更难发生的脚手架。

以下是几个经得住检验的做法：

以验证作为硬性完成标准

每一项AI完成的任务，都应以具体证据作为终结：一个运行通过的测试、一张截图、一段日志、一条运行时追踪、一位审查者的确认。"看起来完成了"是亲近投降的出口；"这是它正常工作的证据"是抵御投降的出口。将证据要求内嵌进工作流程，你便封堵了通往投降的最易捷径。

反合理化清单

Agent技能框架最独特的设计，是将每种跳过某个工作流步骤的常见借口，都配以书面反驳。这本身也是一种投降防御机制。"这个任务太简单，不需要写规格说明"→"验收标准依然适用"。你在预先写好反驳——针对那个模型（或你周五下午的疲惫自我）尚未说出口的合理化理由。模型擅长为跳过严谨步骤生成可信的理由；反合理化清单拒绝在当天与之争辩。

更小的范围，更小的PR

投降随规模而放大。50行的改动你能真正通读；600行的改动你做不到。谷歌约100行PR的规范有其人的理由，对抵御AI投降同样有效。审查的单元，是理解的单元。把单元做得足够小，小到能够真正理解。

学习时，先问概念，后要生成

这是技能养成论文的发现，重新表述为一种习惯：当你初识一个库或系统时，先让AI解释，再让它生成。同一个工具，用于追问而非产出，能够构建而非侵蚀你的心智模型。数据对此已无歧义，切换模式的成本微乎其微。

以摩擦为设计

一篇关于"认知代理投降"的论文提出了"脚手架式认知摩擦"的概念：刻意引入阻力，打断对启发式接受的惯性。以工程语言而言，就是：生成前先写设计文档，合并前设置确认步骤，部署前核对检查清单。摩擦在生产力话语中名声不佳——但它也恰恰是卸载与投降之间的那道关卡。

独自坐在键盘前的时间。 每周写一些不用AI的代码。不是道德操练，而是校准练习。

那一天——当你发现自己没有AI辅助便无法从容写出简单的东西——就是卸载已悄然变为投降而你浑然未觉的那一天。

相互放大，而非委托外包

我想以一个不那么悲观的框架作结。哲学家安迪·克拉克在谈及这项研究时，做出了恰当的区分：

把任务委托给AI，与协同AI，是两件不同的事。委托产生投降；协同产生他所谓的相互放大——

一个循环，在这个循环中，你的提示打磨了模型的输出，而模型的输出又打磨了你的下一个提示，进而打磨了你对问题的心智模型。

你能感受到其中的差异。在相互放大的状态下，你会发现自己透过对话来掌握领域知识，而非尽管有对话。

你在对话结束时，拥有的心智模型比开始时更清晰，而非更模糊。你依然有能力自己完成这件事；你只是选择了一条更快的路径。AI是房间里的第二位工程师，而不是唯一的那一位。

投降的姿态恰恰相反——对话结束时，AI对这个问题的理解比你更深。你无法重建这个设计，你无法在没有AI帮助的情况下调试这段代码。

你把本应让你成长的那部分工作，外包了出去。

两种姿态使用相同的工具，产出的代码都能上线交付。从外部看，在某一个单独的迭代周期里，它们无从分辨。

区别在六个月后浮现——当某处出了问题，两位工程师中，一位能从第一性原理入手修复，另一位不能。

我最希望这篇文章能做到的

我不是要大家对AI工具望而却步。过去一年，我用这些工具的产出远超以往任何一个时期。我相信，完全拒绝它们才是更大的错误。

但姿态至关重要，而我们谈论它的时候远远不够。对话的重心，大多是模型能做什么。我们至少应该同等关注：

我们在用它们做什么，以及答案究竟是"与之共同思考"，还是"压根没有思考"。

认知卸载，是一种超能力。认知投降，是我们在不知不觉中让这种超能力失效的模式。

这份工作的核心，越来越在于：时刻保持对自己站在那条线的哪一侧的清醒校准。

如果你的代码在上线，而你对系统的理解在萎缩，你正在用认知债务付账。

如果你的代码在上线，而你对系统的理解在增长，你正在做这份真正的工作——只是速度比以前更快了。

两种情况使用的工具相同。

不同的，是姿态。而那一部分，始终完全属于你。