如何避免用 AI 用到失去技术判断力?

最近在社群中有一位在美国 Cornell 大学读计算机科学的博士生，在微软实习时遇到一个尴尬的状况。她提到「我的合作伙伴好像太依赖代理工具了，什么问题都想叫它修。结果他们自己也说不清楚系统到底怎么运作，甚至对于我卡在哪里，也缺乏一些基本理解」。

不仅如此，在要解决问题时「他们虽然有主动说可以约线下见面，帮我一起解决问题。但真的见面之后，情况就变成：他们在旁边提示自己的代理工具，而我尴尬地一起看；或者换成他们叫我提示我的代理工具，然后他们尴尬地一起看」。

什么是认知投降 (Cognitive Surrender)?

这让人想到前阵子宾州大学做的一个关于认知投降 (cognitive surrender) 的研究。所谓的认知投降，是指使用 AI 的人，直接把 AI 的输出当成自己的输出，在过程中没有去检验，也没有加入自己额外的观点。

具体来说，在这个研究中，研究者找了受试者来进行实验。在受试的过程中，他们请受试者完成一些不同的题目与任务，其中有一部分受试者可以使用 AI 助手，另一部分则不行。当然，这两个组别有做好随机控制，所以能够确保真正被介入的变量，就是过程中一组可以使用 AI，另一组不能使用 AI，其他条件基本上是均等的。

在实验过程中，实验者偷偷把 AI 提供的某些解答，通过提示词让 AI 回答成错误的答案。他们在这个过程中发现，当 AI 的答案是错误的时候，那些使用 AI 的人的答案也会跟着变错。

换句话说，这些人使用了 AI，也同时吸收了 AI 的错误。

但更让人担心的是，当他们回答了这个错误答案之后，研究者进一步评估他们对这个回答的信心程度有多高。结果发现，他们的信心程度反而比没有使用 AI 的人还要更高。这是因为 AI 往往会使用一种非常笃定的语气来做解释。而这些受试者在看完 AI 给出的、非常笃定又完整的解释之后，就相信了它的解释，并且因此觉得这个回答是正确的，所以他们会很有信心。

大家可以试想，如果这样的事情发生在实际工作中，会是非常可怕的。

以工程师的工作来说，假设你请 AI 代理帮忙写了某一段代码，然后出现像这个实验中提到的认知投降征兆。你直接把这段代码当成自己的输出，在过程中没有对这段代码做任何 code review。接着，因为 AI 在写这段代码时，它的输出与描述自己如何写的过程都非常笃定，所以你也就相信了。

最后，很可能你会提交一段错误的程序，然后自己还很有信心，觉得自己提交了一段质量非常好的程序。因此，有认知投降这样的征兆，是非常危险的。

越来越多工程师失去技术判断力

不仅是在微软，近期 Reddit 上有另一位网友分享，自己的技术主管以前是那种会在白板前花好几个小时，画复杂系统设计的人。他会解释每一个取舍，确保大家都理解每个决策背后的原因。结果现在都「直接贴进 ChatGPT，叫它解释就好」。

而在他的团队上周有一个竞争条件 (race condition) 的问题漏进了正式环境。当原 Po 指出这件事时，他的主管却回说「可是 AI 说它是线程安全的 (thread safe) 的」。

在这两个案例都能看到，即便 AI 代理能力越来越强，也不代表能完全什么都不管，让自己进入认知投降的状态。不过，从团队的角度来看，可以怎么做? 能建立什么机制，确保使用 AI 时有效率，从中该有的理解与学习却不会被牺牲?

如何避免认知投降?

要避免认知投降的方法有几种，其中最推荐之一的是一位曾在 Notion 工作的工程师分享的做法，非常值得推广。他在每次要提交 AI 写的代码之前，会请 AI 根据这次的改动出几道问题，除非他能答对这些问题，否则他不会提交。通过这个过程，他确保自己对 AI 产出的每个细节都真正理解，而不是在不明就里的状况下就把东西送出去。

这件事不只适合个人实践，更推荐引入到整个团队。现在很多团队会用 AI 来写 Git 提交信息，或直接让 AI 帮忙发 PR，可以把这个小测验机制直接整合进相关的指令中。每当成员要用 AI 发起提交或创建 PR，AI 会先提出几道问题，只有成员通过测验后，AI 才实际执行提交或发出 PR。通过这个机制，就能确保每位成员在提交 AI 写的代码之前，都真的弄懂了改动背后的细节。

另一个值得借鉴的做法，来自 Amazon 在经历上述事故后所采取的应对措施。他们导入了一个机制，任何 PR 合并之前，都必须经过人工签署的流程，类似于 code review 中要求特定人员核可才能合并的惯例。对于 AI 代理产生的改动，Amazon 要求必须有人类工程师实际审查并签署，才能让 PR 被合并进去。

这个签署机制和前面谈到的「负责任文化」互相呼应。光是口头要求大家为 AI 的产出负责，效果可能有限；但如果今天合并进去的改动上面印着你的名字，情况就不同了。一旦发生事故，所有人回头一看，就会清楚看到这个问题是由哪位工程师签署核可的。这个机制本身就会让成员更有意识地严格审查 AI 的产出，避免自己成为那个没有尽责把关的人。

阅读更多

除了上面提到的方法，如果对这个主题感兴趣，我们在 E+ 的 《AI Coding 201:从实战到最佳实践》 课程有详谈。欢迎加入 E+ 观看与交流。