[翻译] 智能体时代的批判性思维

这篇文章想翻译 Addy Osmani 的文章 Critical thinking when agents do the work。

把代码和文档交给智能体的情况越来越多，却不确定自己是否真的读了返回结果的开发者，就是这篇文章的读者。它并不主张减少委托。文章讲的是：作者为了在委托的同时不丢掉判断而向自己提出的六个问题，不对绿色对勾照单全收的验证习惯，以及每周、每月都能做的练习。

Addy Osmani 在 Google 工作了 14 年以上，负责 Chrome、DevTools、Lighthouse 和 Core Web Vitals 的开发者体验，也是《Learning JavaScript Design Patterns》的作者。他现在在 Anthropic 打造 Claude Code。原文于 2026 年 11 月 3 日以 X 文章的形式发布。

术语保留了原文。像 cognitive surrender 这样作者从其他研究者那里借来的概念，只在第一次出现时附上中文释义。原文的链接都保留了，指向同一篇文章的链接只在第一次出现时添加。正文中引用的句子，笔者都回到对应出处重新核对过措辞。下面是原文的译文，文中的“我”指作者。

批判性思维为何变难了

过去我们学到的批判性思维是这样的：以谦逊的好奇心和适度的怀疑面对新信息，听取不同的观点，然后形成自己的看法。这话今天依然成立。但如今相当一部分工作都要经过智能体，我的日常里能逼我进行批判性思考的东西越来越少了。对于已经全面拥抱 agentic workflow 的工程师和产品人(同时并行跑多个会话，并期待模型不断变好的那些人)，我想先说一句：我非常喜欢这些工具。我写这篇文章，并不是为了劝大家少用智能体。

我的目标，是在什么都很容易交给智能体的世界里，帮助你保持批判性思维。

过去，认知上和审美上的判断，大多发生在问题和答案之间的那段时间里。如今那段时间缩短到了以秒计。越是使用 agentic workflow，这件事就越难(不过我认为，它变难的方式和人们预想的不同)。因为模型越好，显眼错误的比例就越低。很多(大多数？)输出写得很好，而且大体正确。但它们不会让你想再看一遍。

即使同时运行很多个智能体，盯着输出的眼睛依然只有一双。

批判性思维必须由你亲手嵌进每天的工作里，因为默认情况下，没有任何东西会替你做这件事。之所以很难自我纠正，原因之一在于 agentic workflow 让人很舒服。在忙碌的一天里，得到又快又省心、而且常常正确的答案，是件畅快的事。也正因为如此，人很容易放松警惕。

委托、托付判断与投降

和别人聊到这件事时，我会把它描述成一条光谱。

最上端是 cognitive offloading(认知委托)。把任务交给 AI，但结果的主人仍然是自己。我整天都是这样工作的，也建议你这样做。中间是 deferral(托付判断)。工具的输出直接成为你的下一个输入，结果不再被当作假设来对待。最下端是 cognitive surrender(认知投降)。AI 的输出悄无声息地变成了你自己的想法，你甚至不觉得有必要去核实。

cognitive surrender 是沃顿商学院的 Steven Shaw 和 Gideon Nave 提出的说法，和我一直以来看到的情况完全吻合。信任(或者说懒惰)越多，人就越会顺着光谱往下滑。这种移动很少被察觉，因为每一步都很平缓，看起来也都合情合理。上一个答案认真读过了，这一个就扫一眼。下一个只看骨架。然后有人指着某一行问你时，即使借助智能体，你也解释不出来。

这就是认知投降。cognitive debt(认知债务)就是这样积累起来的。通常是在你想调用对系统的心智模型时，才发现根本没有这样的模型，问题由此暴露出来。Margaret-Anne Storey 写过，这在团队中表现为大家对系统共同建立的理论(shared system theory)被一点点侵蚀。我曾用 comprehension debt(理解债务，由 Jeremy Twei 提出)这个名字，写过代码方面的同一种现象。在当下，它完全看不见。代码库看起来干干净净，测试也都通过。直到需要修改系统时，才会发现已经没有人理解它了。只读了战略文档或规格说明的目录就签字批准时，也是一样。

说清楚一点，我并不是要求做不可能的事。把一个大型现代代码库的心智模型完整装在脑子里，是不可能的。Claude Code 团队公开说过，他们会在需要时重新建立理解。需要了解某个部分时，他们不是把完整模型装在脑子里，而是请 Claude 解释那一小块。正如我以前写过的，这类债务比大多数工程师预想的更容易偿还。只要能在需要时把那一部分重新建立起来，就没有必要维持完整的模型。只是你得知道自己缺了什么。

如果出错也没什么损失，大可以放心地整个交出去。如果借助智能体也解释不了那个答案，你就已经让出了主人的位置。这也不总是问题。前不久我录制课程时，需要从三家评分差不多的酒店里选一家作为拍摄地点。我没有时间一条条去读评论，就把这个决定交给了 AI。结果没问题，遇到同样的情况我还会这么做。但在决定把家里的钱投到哪里、怎么给孩子们的职业方向提建议，或者在工作中决定做什么、哪些改动会影响哪些用户、发布是否安全时，我不会这样做。出错代价小的事情就交出去，后果要由别人承担的事情，就把推理握在自己手里。

我问自己的问题

连我自己都不知道自己怎么想的时候，我通常会回到这样一份基本问题清单。我怎么知道自己在解决正确的问题？我怎么知道自己在用正确的方式解决它？有证据支持我的结论吗？我怎么知道自己已经做完了？大多数时候，这不过就是 谁、什么、哪里、为什么、何时、如何。写下来看幼稚得可笑，但它会让你去思考平时会忽略的那些范畴。如今，跳过这一切、直接问智能体我该做什么，实在太容易了。下面是我现在问自己的新版问题。

提问之前，我有没有先提出假设？在把任何不简单的任务交给智能体之前，我会先写下答案可能是什么，哪怕只是在脑子里。猜得离谱也没关系。看到新信息后改变想法，任何时候都是好事。但一旦读过一个写得很好的回答，就很难再想象其他可能性了。如果完全没有头绪，就请求 Thariq Shihipar 所说的 blind spot pass(盲点排查)。把你知道的东西交给模型，让它去找出你不知道自己不知道的东西。

我是在让它帮我思考，还是在让它替我卸下思考？两者都可以。只要知道自己此刻在做哪一种就行。

要是什么为真，这个结论就是错的？然后亲自去查明。模型给自己打的置信度，远不如一个能实际运行的测试有价值。所以，给模型一个测试。

我有没有从不同角度听过反方的论证？在没有明确标准答案的问题上，当我采取了强硬立场时，会让两个以上的模型去论证相反的一方，读完结果后再形成自己的看法。这要花更多时间，但我会对这个主题了解得多得多。

当着要维护它的那个人，我敢打赌它是对的吗？这适用于代码，也适用于你交付的其他一切。我认为，这就是能为自己的工作负责作答的底线。

我不再练习的是什么？也许是一部分日常调试。其中一些放下也没关系。只是我希望那是有意为之的。

把验证变成习惯

我最近写了很多关于验证的东西，因为我相信 瓶颈已经从写代码转移到了确信自己是对的。如果给智能体提供验证自己工作的手段(无论是 end-to-end 测试、property 测试，还是实际操作应用)，它就能在你看任何东西之前做出修改、运行验证、读取输出、再次尝试。这就是 Boris Cherny 所说的 “给 Claude 一个验证自己工作的方法”，我认为这是取得好结果最关键的要素之一。你不再逐行阅读，而是搭建这样的循环，并审查它留下的证据。

在验证上也会投降。“有证据支持我的结论吗？”变成了“检查变绿了吗？”智能体让写测试变得非常便宜，你会看到大量绿色，但一个抓不住功能损坏的测试，也可能正在通过。如果测试和功能里写进了同一个错误，测试就会通过。而且一个绿色对勾只能告诉你一种性质。可是想象它覆盖了一切，实在太容易了。

检查变绿时，问问它证明了什么。再问问它没有证明什么。“已验证”的定义要事先定好。等结果出来再定，你会为任何结果找到合理化的理由。

智能体工作的终点线应该是摸得着的东西：通过的测试、截图、日志或 trace。这样，完成的标准就是事实，而不会交给“看起来差不多做完了”这类解读(以及投降)。收到智能体的完成通知后，在看摘要之前，先检查实际执行的命令代码及其输出。

Claude Code 还可以通过在全新上下文中启动的 subagent，对自己的工作进行批判性审查，做一次基本的健全性检查。值得把它放进循环里，让它每次都运行，而不是只在你想起来时才运行。我在最后仍然会问：“我漏掉了什么吗？”这听起来有点傻，但每当我用 frontier 模型完成一项复杂的功能开发，亲自看过、审查过之后再问“我漏掉了什么吗？”，它真的经常会再给出两三条。所以我总是会问。

当然，这些都不必每次都做。知道什么时候该深入，本身也是一种技能。在我们整理 Claude Code 团队如何做代码审查的文章里，我最喜欢的一条经验法则是：“如果说不出检查会漏掉什么，就请求一次真正的审查，而不是快速批准。”

这同样适用于代码之外。如果智能体为你综合了五十通客户电话或一份竞品分析，就亲自打开两三份原始文档，确认摘要是否准确。挑一个你的建议所依赖的数字，确认它算得对不对。智能体让搭建验证变得便宜了。难的是知道好的验证应该是什么样子。

真正去看生成的东西

假设智能体给了你一个 600 行的 PR。你大致扫一眼结构，没有逐行阅读。变量名看起来合理，测试也通过了，于是你批准了。但在中间的某个地方，事务边界的顺序发生了微妙的变化，或者一个你从没想过的 edge case 的默认值被翻转了。你确实审查过了，算是吧。只不过只看了你本来就知道会找到的东西。

写代码和审查代码是两种不同的技能，而且 审查有一个会变成 rubber stamping(走过场的批准)的临界点。所以，读 diff 时要当作它不是 AI 写的，然后越过 diff，看看智能体做了哪些决定。在一个长会话里，它会替你做出很多小决定：默认值定成什么，哪些放在范围之外，两个需求冲突时重新解读哪一个。

在一份写着“一切顺利”的摘要里，这些你一样也看不到。所以，让智能体列出它做出的决定和假设。然后给自己出题。随便挑几行，问“这一行呢？”“那一行呢？”如果是文档，就把它关掉，凭记忆写出核心论点。有些人在长会话里有一个我很喜欢的习惯：让 Claude 写一份关于这次改动的报告，在报告末尾给你出一份测验，并定下“测验满分通过才合并”的规则。对你要发布的东西，理解到足以为它辩护的程度。因为总有一天，可能会有人问起。

智能体也可以用来守护你的注意力。比如我维护的一个开源项目会收到很多 PR。我借助智能体来分辨进来的是什么、哪些违反了我们的准则、哪里可能需要我的注意。我很少让智能体独自做出这个判断，但它可以帮我缩小需要集中注意力的范围。这样我才能真正去思考，这些改动是否在用正确的方式解决正确的问题。

然后是数量的问题。在这一点上你必须对自己诚实。我把它称为 orchestration tax(协调成本)。它是智能体产出的量，与你愿意署上自己名字的量之间的差距。如果完成的工作堆积的速度比你消化的速度还快，那么在解决这个问题之前，再开一个会话也无济于事。要么收紧检查，减少需要你看的量，要么放慢速度。当你产出的东西多于你能负责的东西，那就不再是审查了。那是在碰运气。

好的输入，好的输出

人的心智模型仍然参与其中，只是位置从中间移到了前端和末端。你把精力投入到前端的任务描述和上下文，以及后端的输出审查上。这就是好的输入对输出质量如此重要的原因，我把写好提示词视为一种批判性思维技能。

过去，如果你提出一个含糊的请求，总有人会追问，于是你可能会意识到：“啊，其实我还没想清楚。”智能体往往不会在那里拦住你。它会自行补上你漏掉的部分，交回一个看起来已经完成的结果，尽管背后的想法依然模糊。我曾用 intent debt(意图债务)这个名字写过这件事。它指的是可能存在于并非你亲手写的产出物中的隐含目标、约束和依据。和其他债务不同，这笔债谁也替你还不了。意图必须来自你自己。

提示词反映了你对问题的理解程度。如果你说不清楚，那它在你脑子里可能也不清楚。在寻求帮助之前，先用自己的话写一份请求简述。写下目标读者、范围之外的内容，以及完成的定义。如果第二轮修改请求仍然没能达到你想要的效果，就停止零敲碎打的修改，重写提示词。

这件事也可以借助智能体。我喜欢 Andy Clark 对“委托给 AI 系统”和“与 AI 系统 协作”所做的区分。在协作中，你会进入一个相互放大的良性循环：提示词打磨输出，输出打磨下一个提示词，也打磨你对问题的心智模型。如果还没想清楚，就让智能体针对它不理解的地方来采访你。如果关闭会话时你的心智模型变得更清晰了，那就是成功的信号。

也要小心输入。智能体很容易只把上一个智能体的摘要当作自己的上下文接过来。这样下去，第三个智能体就会处在从没读过原始文档的状态。

你还需要自己对输出的标准。我在各种创作媒介里尝试过 AI，其中大部分因为达不到我的标准，从来没给任何人看过。所有东西出来时都格式整洁、语气自信，所以光洁程度已经不再是有用的信号了。AI 也许让产出变快了。但如果我不愿意把这份产出署上自己的名字，我就不会把它拿出去。

如果有东西没达到你的标准，就把原因写进共享配置、hook 或测试里，让它不再发生。品味就是这样积累起来的。而且，写下什么因为什么被淘汰，这件事本身就是很好的练习。

“可模型终究会比我做得更好”

如果你和我身边的许多人一样看好这个领域的未来，那么读前面几节时，你大概会这样想：再过一两年，我能发现的东西模型也都能发现，为什么还要费劲维持这项技能？

在这类发现的很大一部分上，你也许是对的。我自己也一直主张把发现工作越来越多地交给智能体。但我认为它仍然重要的理由是这样的：说到底，发布出去的东西总得有人负责。不管 AI 帮了多少忙，都必须由人来承担责任。

在某项任务上该在多大程度上信任智能体，这本身就是一个判断问题。审查工作，就是让这种判断保持校准的一部分，因为模型出错的地方一直在变。Anthropic 针对自家工程师和研究人员所做的研究，也 点出了这个陷阱，称之为 paradox of supervision(监督悖论)：“监督 Claude 恰恰需要那些编程技能，而这些技能可能会因为过度使用 AI 而退化。”

有些东西对我来说最重要，而更好的模型也解决不了：你在做什么，为什么值得做，它会影响谁，你愿意牺牲什么。这些都是需要你来回答的问题。智能体可以帮你一步步想清楚，我也希望它能做到。但归根结底，这些问题仍然是你的。工作可以交出去，大部分审查也可以交出去。但责任交不出去。

日常练习

这些都不必严格照做。只要把适合自己工作方式的部分放进去就行。

每周一次，不用智能体写一点代码，或者亲手做一件一旦忘了怎么做就会很麻烦的实际工作(我把这称为 calibration exercise(校准练习)，但并不是想说教)。每月一次，写下自己已经不再做的事，并决定其中哪些不做也没关系。我以前一篇博客文章里的一个问题，至今依然有效：如果没有 AI，我会迷失到什么程度？

遇到理解不了的东西，就去学。写作时碰到一个没见过的说法，可以用 Google 查一句解释塞进去。我更愿意多做一点调查，把它真正弄懂。这样才能看清它放在哪里才合适。

好好检查机器做的事，是实实在在的工作。假装不是，团队最终就不会去做。它不是免费的，所以把它作为一个条目排进日程。这样你才会真的去做。

不用的技能会消失，而且可能比你想的更快。不想放手的技能，就继续用。

值得带走的

• 有意识地设置: 智能体可以给你出题、采访你、给你看证据，但前提是你这样设置了。所以去设置吧。
• 对自己在光谱上的位置保持诚实: 如果借助智能体也解释不了那个答案，你就已经向它投降了。
• 先提出假设: 哪怕很离谱，也要在提问前先提出一个。
• 绿色对勾只意味着一件事: 它检查了什么？它没有检查什么？
• 寻找证据: 在读摘要之前，先读它运行了什么、返回了什么。
• 读懂它做了哪些决定: 智能体替你决定了什么？
• 打磨提示词: 你怎么写提示词，反映了你对问题理解了多少。
• 定好标准并坚守: 不能署上自己名字的东西，就不拿出去。

通过亲手运用那些重要的技能，让自己留在场上。推荐一件值得一试的事：提问前写下你认为会发生什么，智能体完成后，写下一件它没有检查的事。告诉我这是否改变了你阅读输出的方式。独立思考。提出更好的问题。为结果负责。

笔者的想法

AI 很重要，这一点毋庸置疑。但笔者现在想优先选择的，不是拓宽技术栈，而是培养思考的能力和判断的标准。

作者所警惕的 cognitive surrender，就是把判断交给智能体。笔者也会积极使用 AI 和自动化工具，但比起把思考本身交出去，更想用它们来提高思考的效率。为什么这样排定优先顺序，笔者另外写在了 证明思考的过程 里。