💡 TL;DR：工作越交给智能体，越要主动建批判性思考——提问前先写假设、给智能体搭验证闭环、读懂它替你做的每个决定。活儿可以外包，责任不能。

Addy Osmani · X · 2026-11-03 · 原文

---

Addy Osmani · 2026-11-03 · X 长文（原文无标题，中文标题为译者所加）

早年，批判性思考是这样教的：带着谦逊的好奇和适度的怀疑去接触新信息——听取不同观点，形成自己的判断。这个道理今天依然成立。但我的日常越来越逼不着我这么做了——因为太多的工作直接跑在智能体（agent）上。致那些已经全盘接受智能体工作流（agentic workflows）的人。并行开着好几个会话、笃信模型会越来越好——工程师也好，产品人也罢。我想先把话说清楚：我是这些工具的铁杆粉丝。写这篇东西，不是劝你少用智能体工作流。

我想帮你在这样一个世界里保住批判性思考：在那里，把任何事外包给一个智能体，都太容易了。

过去，我们大部分的认知加工和审美判断，发生在提问与答案之间的那段时间里。现在，这段时间以秒计。智能体工作流用得越多，保住批判性思考就越难（但难的方式可能和你想的不一样）：模型越好，明显错误的比例更低。很多（甚至大多数？）输出写得漂亮、大体正确，但它不会逼你再看第二眼。

哪怕你同时跑着十个智能体，盯着输出的，还是只有你这一双眼睛。

你必须主动把批判性思考安排进每天，因为默认情况下，没有任何东西会替你做这件事。

这事难以自我纠正，部分原因是智能体工作流实在太舒服了。又快、又舒服、常常还挺正确的答案，在忙碌的一天里令人神清气爽——但也正因为如此，你很容易松懈。

外包、转交与投降

和人聊起这个话题时，我会把它描述成一条光谱：

• 顶端：认知外包（cognitive offloading）——把任务交给 AI，但结果的所有权还在自己手里。我整天都在这么干。你也应该。
• 中间：转交（deferral）——工具的输出变成了你的新输入；结果不再是待验证的假设。
• 底端：认知投降（cognitive surrender）——AI 的输出悄悄变成了你的观点，你连查都不想查了。 “认知投降”这个词，是沃顿商学院的 Steven Shaw 和 Gideon Nave 提出来的。它精确对上了我一直在观察的现象：随着信任（或者说懒惰）加深，人会沿着光谱往下漂。这个下滑几乎无从察觉，因为每一步都很渐进、都显得合理。上一个答案你认真读了，下一个就开始略读，再下一个只扫了个骨架。然后有人问起其中某一行，你解释不了——连让智能体帮着解释都解释不了。

这就是认知投降。认知负债（cognitive debt）就是这样积累起来的。它通常是在你试图调用关于系统的心智模型时暴露的——那个模型根本不存在。Margaret-Anne Storey 写过它在团队中的表现：对共享系统理论的理解被逐渐侵蚀。我写过它在代码上的对应物：理解负债（comprehension debt，Jeremy Twei 创造的词）。事发当下，它完全隐形。代码库看着干干净净，测试全是绿的。直到你要动手改系统，才发现已经没人看得懂它了。你读完一份战略文档或需求规格的目录就签了字——同样的债也就欠下了。

说清楚，我不是在提倡不可能的事。一个大型现代代码库的完整心智模型，没人维持得了。Claude Code 团队公开说过，他们的做法是按需重建理解：需要弄懂哪一块，就让 Claude 解释哪一块，而不是把完整模型装在脑子里。我以前写过：这种债的可挽回程度，超出多数工程师的想象。只要能按需在局部重建，你不必维持完整模型。你只需要知道自己缺什么。

风险低的地方，尽管全权委托。当你连借助智能体都解释不了一个答案时，所有权已经易主了。

这也不总是个问题。就在最近，我录一门课，要从三家评分不相上下的酒店里挑一家当录制场地。我没时间逐条看完所有评价，就把这个决定外包给了 AI。效果很好，下次我还这么干。但在另一些事上我不会这么做：家里钱怎么投、孩子的职业怎么建议；还有工作中——我们该做什么、哪些改动会影响哪些用户、能不能安全上线。错起来便宜的地方，把活儿交出去；要别人承担后果的地方，把推理留下来。

我问自己的问题

过去我不知道自己的想法时，通常会回到一组最基本的问题：我怎么知道自己在做对的问题？我怎么知道自己解法是对的？有没有证据支撑我的结论？我怎么知道自己做完了？多数时候，这就是 5W1H——谁、什么、哪里、为什么、什么时候、怎么。写出来幼稚得可笑，但它逼你按那些你平时会无视的类别去思考。如今，跳过这一切、直接问智能体”你觉得我该干嘛”，太容易了。下面是我现在问自己的新版本。

• 提问之前，我先有假设了吗？ 在任何非琐碎任务上让智能体跑之前，我会先写下——哪怕只在脑子里——我认为答案可能是什么。猜错了没关系，有了新信息随时可以改主意。但一旦读完一份写得漂亮的回答，你就很难再想象别的可能性。如果你毫无头绪，可以要一份 Thariq Shihipar 所说的”盲区扫描”（blind spot pass）：把你已知的喂给模型，让它找出你的未知之未知。
• 我是在请它帮我思考，还是在请它替我思考？ 两种都可以，前提是你清楚自己在干哪一种。
• 什么条件成立，这个结论才是错的？ 然后去把它找出来。模型对自身置信度的评估，远不如一个你真正能做的测试值钱——那就给它安排一个。
• 我从不同角度听过反方意见吗？ 在某个开放式问题上站了硬立场之后，我会让不止一个模型去论证相反的一面，然后审阅输出、形成自己的观点。这样更花时间，但我对这个题目的理解会深得多。
• 敢在将来要维护它的人面前，为这个下注吗？ 代码如此，你交付的其他一切也如此。我认为这就是”答得上来”的底线。
• 我不再练习的是什么？ 可能是某些日常调试。放手一些没关系，但我要它出于有意，而非不知不觉。

验证成为习惯

我最近写验证写得多，因为我相信瓶颈已经从”把代码写出来”转移到了”确认你是对的”。当你给了智能体验证自身工作的手段——端到端测试、属性测试，或者真实操作应用——它就能在你还没看任何东西之前，完成改代码、跑验证、读输出、再来一轮的全部循环。这就是 Boris Cherny 说的”给 Claude 一个验证自己工作的途径”。我相信这是拿到好结果最关键的一环。你不再逐行读代码，而是在搭这些循环、审阅它们产生的证据。

验证本身也会被投降。“有没有证据支撑我的结论？“会退化成”检查变绿了吗？“智能体让写测试便宜到你会看到满屏的绿——而一个通过的测试，可能根本没抓住坏掉的功能。如果测试是带着和功能相同的错误写出来的，它会通过。绿勾只证明一件事，你却太容易想象它证明了一切。

检查变绿时，问它证明了什么。再问它没证明什么。

提前定义什么叫”已验证”——事后的话，你能把任何结果都解释圆。

智能体工作的终点线必须是个看得见摸得着的东西：一个通过的测试、一张截图、一份日志或调用链路。这样”做完了”的标准才是事实性的，才不会被人解释成”看起来做完了”而投降。收到智能体的完成通知时，先别看总结，先审它执行了什么命令、输出是什么。

Claude Code 还能（通过一个全新上下文里的子代理）对自己的工作做合理性抽查。值得把它固化进流程，让它每次都跑，而不是想起来才跑。我最后仍会问一句”我漏了什么吗？“听着挺傻，但常常是：我用前沿模型做完一个复杂功能，看过、审过，再问”我漏了什么吗？“它就会又端出两三件来。所以我总问。

当然，这些不必都成为常态；知道何时该深挖，本身就是一门手艺。我们写过一篇 Claude Code 团队怎么做代码评审的文章，我最喜欢的一条经验是：“如果你说不出检查会漏掉什么，那就要求一次真正的评审，而不是走个快速批准。”

代码之外也一样。智能体替你汇总了 50 个客户电话，或者一份竞品分析——抽几份原始材料核对摘要准不准；再挑一个你的建议所依赖的数字，确认它算得对。

搭验证这件事，智能体已经把它变便宜了。难的是你：得知道好的验证长什么样。

认真看它生成了什么

比如智能体递给你一个 600 行的 PR（合并请求）。你大致看了看结构，没有逐行读。变量名看着合理，测试也过了，于是你点了批准。但就在中间某处，有一个事务边界里的微妙顺序改动，或者一个你从没想过的边界情况上被翻转的默认值。你算是审过了——但只审了你本来就预期会发现的东西。

写代码和审代码是两种技能，审着审着会退化成盖章式过目。所以，读 diff（改动差异）时要当作不是 AI 写的；读完 diff，再看 diff 之外它替你决定了什么。一次长会话里，它会替你做很多小决定：默认值、什么不在范围内、两条需求打架时改写哪一条。

这些在一封”一切顺利”的总结里都看不到，所以要让它列出自己做的决定和假设。然后考自己。随机挑几行，问：这一行为什么这样？那一行呢？文档的话，合上它，凭记忆把主论点写出来。有人有个我喜欢的长会话习惯：让 Claude 就这次改动写一份报告，末尾附一套小测验——规则是”测验全对，我才合并”。

对你要发布的东西，理解到能为之辩护的程度。因为总有一天，会有人来问。

智能体也能帮你守注意力。比如我有个开源项目，收很多 PR。我用智能体帮忙判断：进来的是什么、哪些违反了我们的准则、哪些地方可能需要我亲自过目。我很少让智能体自行拍板，但它们能把我该聚焦的范围收窄，然后我才有余力真正去想：这些改动，是不是在用对的方法解决对的问题。

还有量的问题，这点你必须对自己诚实。我称之为编排税（orchestration tax）：你的智能体生成的东西，和你敢署名的东西之间的缺口。如果成品堆起来的速度超过了你能消化的速度，再开一个会话也没用——先解决这个：收紧检查，让更少的东西需要你；或者放慢。

当你产出的多到自己兜不住时，你就不是在审了。你是在赌。

好输入，好输出

人的心智模型仍然在场，只是从中间挪到了头尾。你的精力投向两头：前端是任务描述和上下文，后端是审阅输出。这就是为什么好的输入对输出质量如此重要——我把写好提示词（prompt）视为一种批判性思考技能。

放在从前，你提一个含糊的需求，会有人来挑战你，你可能这才意识到：“等等，其实我自己还没想清楚。“智能体通常不会拦你。它会把你漏掉的填上，交回一个看起来做完的东西——尽管背后的想法还是一团浆糊。我把这叫作意图负债（intent debt）：那些藏在不是你写的产物里的隐含目标、约束和理由。和别的债不同，这一种没人能替你还。意图必须来自你自己。

你的提示词，就是你对这个问题的理解水平的镜子。如果你表达不清楚，多半是你自己脑子里就不清楚。

求助之前，先用自己的话写一份需求简报：给谁用、什么不在范围内、做到什么程度算完。如果第二轮修改还没到位，别再微调了，重写提示词。

这件事也能让智能体搭把手。Andy Clark 区分过”委托给 AI 系统”和”与 AI 协作”，我喜欢这个区分。在后者里，你们进入一个相互放大的良性循环：提示词让输出更锋利，输出让下一个提示词更锋利，也让你的心智模型更锋利。如果哪里不清楚，让智能体反过来采访你：它哪里没听懂。如果一个会话结束时，你对问题的理解变得更精炼了——这就是成功的标志。

输入也要当心。每个智能体都把上一个智能体的总结塞进自己的上下文，用不了多久，第三个智能体已经没读过原始文档了。

你还需要自己的输出标准。我在很多创作媒介里都玩过 AI，其中大部分从没示人，因为够不上我的标准。现在东西出来都是排版漂亮、语气笃定，精致不再是有效信号。

AI 或许让生产更快了，但如果一样东西署上我的名我都不踏实，那它就不会从我手里出去。

一样东西够不上标准时，把原因写进共享配置、hook（钩子脚本）或测试里，让它不再发生。品味就是这样复利的。而写下”它为什么被刷掉”，本身就是好练习。

“但模型在这方面会比我做得更好”

如果你和我身边很多人一样，看好这个领域的前景，那从前面几节起你大概就在想了：一两年后，我能察觉的模型都能察觉，那还费劲维持这门手艺干什么？

在”察觉”这件事上，你可能对了一大部分；我自己也一直在主张把越来越多的察觉交给智能体。但我认为它依然重要的原因是：说到底，发布出去的东西总要有人负责。不管 AI 帮了多少忙，最后承担责任的得是一个人。

一个具体任务上该信任智能体到什么程度——这个问题本身就是一种判断。而保持判断校准的一部分，就是亲自审工作，因为模型会错什么一直在变。Anthropic 对自家工程师和研究员的研究，把这个陷阱点名为监督悖论（paradox of supervision）：“监督 Claude 所需要的编程能力，恰恰可能因为过度使用 AI 而萎缩。”

有些东西对我最重要，也不是更好的模型能替你解决的：你在造什么、它为什么值得、它影响谁、你愿意牺牲什么？这些问题都得你来回答。智能体可以帮你把这些问题想透——我也希望它帮——但归根结底，它们是你的。

活儿可以外包，大部分审计也可以，唯独责任不能。

日常可做的

这些不必全部严格执行。挑对你工作流管用的，插进去就行。

• 每周一次，不用智能体写一小段代码，或者做一件”要是忘了怎么做会很惨”的实事。（我叫它校准练习（calibration exercise），但它不是什么道德义务。）
• 每月一次，写下你不再亲手做的事，然后决定哪些你可以接受不再做。
• 我在一篇旧博客里问过一个问题，今天依然成立：如果 AI 从未存在，你会多手足无措？ 有东西超出你的理解，就去学。我写作时碰到没见过的说法，可以搜一行解释塞进去；但我更愿意花点工夫真正弄懂它，这样我才知道它放在哪儿合适。

认真检查机器是真活儿。假装它不是，团队最后就不会去做。它不免费。把它当成日程表里单独立项的固定条目排进去，你才会真做。

你停止练习的技能会消失，而且多半比你想的快。不愿意放掉的，就继续练。

带走的清单

• 有意图。智能体可以考你、采访你、给你看它的证据——但前提是你搭了这个机制。那就去搭。
• 对自己的位置诚实。一个答案你解释不了——连智能体帮你都解释不了——那你已经投降了。
• 先有假设。提问之前先拟一个，哪怕是烂的。
• 绿勾只意味着一件事。它检查了什么？没检查什么？
• 找证据。读总结之前，先读它跑了什么、返回了什么。
• 读懂它替你做的决定。它决定了什么？
• 打磨提示词。你怎么写提示词，暴露你对问题理解了多少。
• 设一条底线，守住它。署不上你的名的，就不发出去。
• 亲手用那些重要的技能，让自己留在场上。一个可做的动作：提问之前，写下你认为会发生什么；智能体做完之后，写下它没检查的一件事。如果这改变了你读输出的方式，告诉我。 独立思考。问更好的问题。为结果负责。