当智能体替我们干活时，如何保持批判性思维
当智能体能在几秒内写出看起来正确的代码和文档，人们最容易松掉的恰恰是那份"多看一眼"的警惕。Addy Osmani 把人与智能体的关系拆成认知外包、让渡与认知投降三个阶段，指出理解力债务、意图债务和监督悖论如何悄悄累积，并给出一套可操作的日常做法：先形成假设、把验证变成习惯、读生成物时追问它替你做了哪些决定，以及始终记住责任无法外包。 原文：Critical thinking when agents do the work Addy Osmani｜2026 年 11 月 3 日 过去，批判性思维被教导成这样一种姿态：以谦逊的好奇心，加上适量的怀疑精神，去面对新信息——听取不同观点，形成自己的判断。这个说法依然成立，但如今，我的日常工作里有太多事情都交由智能体完成，已经越来越少有什么东西会逼着我动用批判性思维了。对于那些已经完全投入智能体工作流的工程师和产品人（同时跑多个会话、指望模型自己越改越好），我想说：我是这些工具的重度爱好者。我写这篇文章，并不是在主张少用智能体工作流。 我的目标是帮你在这个"什么都能外包给智能体"的世界里，守住批判性思维。 过去，我们大部分的认知加工和审美判断，都发生在"提出问题"和"得到答案"之间的那段空白里。那段空白现在被压缩到了以秒计。你越是用智能体工作流，这件难事就变得越隐蔽（不过并不是大家预想的那种难法）：随着模型变强，明显错误的占比在下降。很多（也许是大多数）输出都写得漂亮、大体正确，但它们不会再要求你多看一眼。 即便你同时开着多个智能体，盯着这些输出的，仍然只有你一双眼睛。 你必须把批判性思维设计进你的一天，因为默认情况下，没有任何东西会替你做这件事。 这件事之所以难以自我纠正，部分原因在于：智能体工作流很舒服。在忙碌的一天里，快速、顺滑、通常正确的答案令人神清气爽——而这恰恰是警惕心最容易松掉的原因。 外包、让渡与投降 和人聊这个话题时，我把它描述成一个光谱： 最上层是认知外包：把任务交给 AI，但保留对结果的所有权。我整天都在这么做，你也该这么做。中间是让渡：工具的输出变成了你的新输入，结果不再是待验证的假设。最下层是认知投降：AI 的输出悄悄变成了你自己的东西，你觉得没必要去核对。 “认知投降"这个词由沃顿商学院的 Steven Shaw 和 Gideon Nave 提出。它精准地描述了我一直看到的现象：随着信任（或者懒惰）增加，人们会沿着这个光谱往下滑。这种转变很少被人察觉，因为每一步都很渐进，而且看起来都挺合理。上一个答案你认真读了，所以下一个你就只扫了一眼；再下一个，你只看了个骨架。然后有人问你某一行是什么意思，你答不上来，哪怕智能体就在旁边帮你。 这就是认知投降，认知债务就是这样累积起来的。它通常在你试图套用某个系统的心智模型、却发现那个模型根本不存在时才会暴露。Margaret-Anne Storey 写过它在团队里的表现：大家对共享的系统理论的理解在持续侵蚀。我写过代码领域的对应物——“理解力债务”（comprehension debt，这个词由 Jeremy Twei 提出）。在当下，它完全隐形：代码库看起来干净清爽，测试全绿。直到你需要改动这个系统，才意识到已经没人真正理解它了。你只读了战略文档或规格说明的目录就签字认可，是同一回事。 说清楚一点，我并不主张去做不可能的事。要完整维持一个现代大型代码库的心智模型，是不可能的。Claude Code 团队公开说过，他们是"按需重建理解”：需要理解某一部分时，就让 Claude 解释那一块，而不是把整个模型都装进脑子里。正如我以前写过的，这类债务的可恢复性比多数工程师以为的要高。你不需要一直维持完整模型，只要能在需要时就地重建它。你只需要知道自己缺什么。 在代价很低的地方，尽管完全外包。但当一个问题你答不上来——哪怕借助智能体也答不上来——你就已经把所有权交出去了。 这也不总是问题。就在最近，我在录一门课，需要从三家评分相近的酒店里挑一个作为录制地点。我没时间逐条读评论，就把这个决定外包给了 AI。它管用了，我下次还会这么干。但如果是在决定怎么投资我们的钱、怎么给孩子建议职业方向，或者在工作里决定该做什么产品、哪些改动会影响哪些用户、能不能安全上线——我不会这么做。在"错了也无所谓"的地方可以放手；在"后果要由别人承担"的地方，推理必须留在自己手里。 我会问自己的问题 当我不确定自己在想什么时，我通常会回到一张很基础的问题清单：我怎么知道自己解决的是正确的问题？我怎么知道自己是用正确的方式在解决它？有什么证据支持我的结论？我怎么知道自己已经做完了？大多数时候，这就是谁、什么、哪里、为什么、何时、如何。写出来看着幼稚得可笑，但它逼你按那些你本来会忽略的类别去想。如今，跳过这一切、直接问智能体"你觉得我该怎么做"实在太容易了。下面是我现在问自己的、这些问题的"新版本"。 在提问之前，我有没有先形成一个假设？ 在让智能体做任何非琐碎的任务之前，我会先写下（哪怕只在脑子里）我认为答案可能是什么。猜得烂也没关系，你随时可以根据新信息改变想法。但一旦你读完一段写得漂亮的回答，就很难再想象还有别的可能性了。如果你完全没有方向，那就向模型要一个 Thariq Shihipar 所说的"盲区扫描"（blind spot pass）：把你已知的东西给它，让它帮你找出你的"未知的未知"。 我是在让它帮我思考，还是在让它替我思考？ 两者都可以，前提是你清楚自己在做哪一种。 要让这个结论是错的，什么必须成立？ 然后去把它查出来。模型对自身置信度的自评，远不如一个你真能跑起来的测试有价值——那就给它一个测试。 我有没有从另一个角度听过反方论证？ 当我在某个相对开放的问题上摆出强硬立场时，我会让不止一个模型去论证相反的一方，然后审阅输出、形成自己的判断。这更花时间，但我最终对这个主题的了解会多得多。 我敢不敢在"将来要维护它的人"面前为这个下注？ 这适用于代码，也适用于你交付的任何东西。我认为这就是"可回答性"（answerability）的门槛。 我现在不再练习的是什么？ 也许是某些日常调试。让其中一部分能力流失我可以接受，但我希望这是有意识的取舍。 把验证变成习惯 我最近写了很多关于验证的东西，因为我相信瓶颈已经从"写代码"转移到了"确认自己是对的"。当你给智能体提供验证手段——端到端测试、属性测试，或者真实的应用交互——它就能在你还没看一眼之前，完成修改、跑验证、读输出、然后再试一遍。这就是 Boris Cherny 说的"给 Claude 一条验证自己工作的途径"，我认为这是取得好结果最关键的一环。你不再逐行阅读，而是在搭建这些回路、审阅证据。...