过去，批判性思维的教法是：带着谦逊的好奇心和适度的怀疑接触新信息，听取不同观点，形成自己的看法。这依然没错。但如今，我的大量工作都交由智能体处理，日常工作越来越不会逼着我认真思考了。对于那些已经全面拥抱智能体工作流的工程师和产品人员——同时运行多个会话，也期待模型继续进步的人——我想先说明：我非常喜欢这些工具。写这篇文章，不是为了劝大家少用智能体。
我的目的是：在一个什么都能轻易交给智能体的世界里，帮助你保住批判性思维。
过去，我们的大部分认知活动和审美判断，发生在提出问题与得到答案之间。现在，这段时间只剩几秒。智能体工作流用得越多，保持批判性思维就越难，尽管原因可能和人们预想的不同：模型不断进步，明显错误的比例越来越低。许多输出，甚至大多数输出，都写得很好，也基本正确，让人觉得没必要再看一遍。
哪怕你同时运行许多智能体，审阅输出的仍然只有你这一双眼睛。
你必须主动把批判性思维安排进日常工作，因为默认情况下，没有什么会替你做到这一点。
难以自行纠偏的一个原因是，智能体工作流用起来很舒服。忙碌的一天里，快速、顺心、通常还正确的回答让人精神一振；也正因为如此，我们很容易放松警惕。
认知卸载、让渡判断与认知投降
和别人讨论这件事时，我会把它描述为一个连续谱：
最上端是认知卸载：把任务交给 AI，但仍然对结果负责。我整天都在这么做，你也应该如此。中间是让渡判断：工具的输出直接成为你的新输入，其结果不再被当成一个有待验证的假设。最下端是认知投降：AI 的输出不知不觉变成了你自己的观点，你觉得没必要再检查。
“认知投降”这个术语由沃顿商学院的 Steven Shaw 和 Gideon Nave 提出。它很贴切地描述了我的观察：随着信任增加，或者人变懒，大家会沿着这个连续谱逐渐下滑。这种转变往往不易察觉，因为每一步都很小，看起来也合情合理。上一份回答你读得很仔细，下一份就略读一下；再下一份只扫一眼框架。直到有人问起其中一句，你却解释不出来，即便有智能体帮忙也不行。
这就是认知投降，也是认知债务积累的方式。通常，要等到你试图调用脑中对系统的理解，却发现根本没有这样的心智模型时，才会意识到问题。Margaret-Anne Storey 写过，这在团队中表现为对系统共同认知的逐渐瓦解。我也写过代码领域的对应问题：理解债务，这个术语由 Jeremy Twei 提出。在当下，它完全不可见：代码库看起来干干净净，测试全部通过。直到你需要修改系统，才发现已经没人理解它了。如果你只看了策略文档或规格说明的目录就签字认可，道理也是一样。
说清楚一点，我并不是在要求不可能的事。对一个庞大的现代代码库，没人能在脑中维持完整的心智模型。Claude Code 团队曾公开表示，他们会按需重建理解：需要了解某一部分时，就请 Claude 解释那一块，而不是把整个模型装在脑中。正如我之前写过的，这种债务比大多数工程师想象的更容易偿还。只要能在需要时重建局部理解，就不必一直维持完整模型。你只需要知道，哪些理解是自己目前没有的。
风险低的地方，尽管全权委托。但如果你连借助智能体都无法解释一个问题的答案，就意味着你已经放弃了对结果的掌控和责任。
这也并不总是问题。就在前不久，我录制一门课程，需要从三家评分相近的酒店里挑一家作为录制地点。我没时间逐条阅读所有评价，就把决定交给了 AI。结果不错，再来一次我还会这么做。但在决定如何投资家里的钱、如何为孩子的职业发展提供建议，或是工作中的这些问题时，我不会如此：我们该做什么产品，哪些变化会影响哪些用户，是否可以安全发布。犯错代价低时，可以交出去；后果需要别人承担时，就把推理和判断留在自己手中。
我会问自己的问题
以前，当我不清楚自己的想法时，通常会回到一些最基本的问题：我怎么知道自己在处理正确的问题？怎么知道解决方式是对的？有没有证据支持我的结论？怎么知道已经做完了？大多数时候，这不过是谁、什么、哪里、为什么、何时、如何。写出来看着幼稚得可笑，却会迫使你从那些平时容易忽略的角度思考。如今，跳过这一切，直接问智能体“你觉得我该怎么办”，实在太容易了。下面是我现在会问自己的新版问题。
提问前，我有没有先形成一个假设？在让智能体执行任何不简单的任务前，我都会记下自己认为答案可能是什么，哪怕只是在脑中想一遍。猜得不好也没关系。获得新信息后，随时可以改变想法。但一旦读过一份写得很好的回答，就很难再想象其他可能。如果你完全没有头绪，可以请模型做一次 Thariq Shihipar 所说的盲区排查：把你知道的告诉它，请它找出那些你连自己不知道都没意识到的东西。
我是在请它帮助我思考，还是让它替我思考？两者都可以，只要你知道自己正在做哪一种。
要在什么条件下，这个答案才会是错的？然后去查清楚。模型对自己有多大把握的评估，远不如你实际能做的检验有价值，那就让它接受一次检验。
我有没有从不同角度听过反对意见？对于那些没有唯一答案的问题，如果我已经持有很强的立场，就会让不止一个模型站在对立面论证，再审阅它们的输出，形成自己的看法。这更花时间，但最后我会对这个主题了解得多得多。
面对日后要维护它的人，我敢不敢为这个结果打包票？这适用于代码，也适用于你交付的其他任何东西。我认为，这就是能否为结果作出解释、承担责任的标准。
哪些能力，我已经不再练习了？也许是某些日常调试。我可以接受放下一部分，但我希望这是有意识的取舍。
把验证变成习惯
最近我写了很多关于验证的文章，因为我认为，瓶颈已经从编写代码转移到了确认自己做对了。如果给智能体提供验证工作的手段，无论是端到端测试、性质测试，还是实际操作应用，它就能修改代码、运行验证测试、阅读输出、再次尝试，而你甚至还没开始看。这就是 Boris Cherny 所说的“让 Claude 有办法验证自己的工作”。我认为，这是取得出色结果最关键的因素之一。你要做的不再是逐行阅读，而是搭建这些验证闭环，再审阅证据。
你也可能在验证这件事上投降。“有没有证据支持我的结论？”变成了“检查是不是绿了？”智能体让编写测试变得极其便宜，所以你会看到很多绿色勾号，但测试通过并不意味着它能发现功能已经坏了。如果测试和功能犯的是同一个错误，测试就会通过。而一个绿色勾号只能说明某一项性质，很容易让人误以为它涵盖了一切。
检查通过时，问问它证明了什么，再问问它没有证明什么。
提前定义什么叫“已验证”，否则事后你会为任何结果找到合理解释。
智能体任务的终点应该是具体、可见的东西：通过的测试、截图、日志或追踪记录。这样，完成标准就是事实，而不会因“看起来做完了”之类的感觉，留下解释乃至放弃判断的空间。收到智能体的完成通知时，先别看总结，先查看它实际执行的命令片段及其输出。
Claude Code 也能通过一个处于全新上下文中的子智能体，对自己的工作做自我评审，检查有没有明显问题。这值得直接纳入验证闭环，让它每次都运行，而不只是等你想起来。我仍然会在最后问一句：“我有没有漏掉什么？”听起来有点傻，但很多时候，我用前沿模型完成复杂功能开发后，已经检查过、评审过，再问这句话，它还是会找出两三件遗漏。所以我总会问。
当然，没必要每件事都做到这个程度；知道什么时候该深入，本身就是一种能力。我最喜欢的一条经验，来自我们介绍 Claude Code 团队如何做代码评审的文章：“如果你说不清这些检查会漏掉什么，就要求一次真正的评审，而不是快速批准。”
这也适用于代码之外的工作。如果智能体为你综合整理了五十次客户访谈，或者做了一份竞品分析，就抽查几份原始文档，确认总结准确。对于建议赖以成立的某个数字，检查它是否计算正确。
智能体已经让搭建验证流程变得便宜。对你而言，难的是知道什么才算好的验证。
真正留意生成的内容
假设智能体交给你一个 600 行的 PR。你大致看了结构，没有逐行读。变量名看起来合理，测试也通过了，于是你批准了。但在中间某处，事务边界内的执行顺序发生了一点微妙变化，或者某个你从未考虑过的边界情况下，默认值被反转了。我想，你确实做了评审，只不过只检查了那些你本来就知道该找什么的地方。
写代码和评审代码是两种不同的技能，而评审会在某个节点退化成走过场的盖章。所以，读差异时，就当代码不是 AI 写的；然后跳出差异本身，看看智能体作出了哪些决定。一个长会话里，它会替你作出许多小决定：默认值怎么选，哪些内容不在范围内，两条需求冲突时重新解释哪一条。
一句“一切顺利”的总结不会告诉你这些。所以，请它列出自己作出的决定和假设，再考考自己。随机选几行，问：这一行是怎么回事？那一行呢？如果是一份文档，就把它关掉，试着凭记忆写出主要论点。有些人处理长会话时有个习惯，我很喜欢：让 Claude 写一份变更报告，在末尾附一套测验，并立下规矩：“只有测验全答对，我才合并。”
对自己要交付的东西，要理解到足以为它辩护。因为总有一天，可能会有人来问。
智能体也能帮你守住注意力。比如，我有一个开源项目，会收到大量拉取请求。我会借助智能体了解有哪些请求进来，哪些违反我们的准则，以及哪些地方可能需要我关注。我很少让智能体独自作出这些判断，但它们可以缩小需要关注的范围，让我真正去思考：这些变更是不是在用正确的方法解决正确的问题。
还有产出量的问题，你必须对自己诚实。我把它称作编排税：智能体生成的内容，与那些你放心署上自己名字的内容之间，存在一道差距。如果已完成的工作堆积得比你审阅得还快，在解决这个问题前，多开一个会话也没有用：要么加强检查，让更少的事情需要你亲自过目；要么慢下来。
当你的产出多到自己已经无法为之负责时，你就不再是在评审，而是在祈祷。
好输入，才有好输出
人的心智模型依然参与其中，只是从中间转移到了首尾。你的精力，一部分花在前端的任务描述和上下文，另一部分花在后端的输出评审。这就是为什么输入对输出质量如此重要，也正因此，我把写好提示词视作一种批判性思维能力。
过去，如果你的要求含糊不清，别人会质疑，你可能因此意识到：“等等，其实我还没想明白。”智能体往往不会在这里拦住你。它会补齐你没说的部分，交回一份看似完成的东西，尽管背后的想法仍然模糊。我把这称作意图债务：那些存在于非你亲自编写的产物中的隐含目标、约束和理由。和其他债务不同，这一种没人能替你偿还。意图必须来自你。
提示词反映了你对问题的理解。如果你无法清楚地表达，也许你自己心里还没想清楚。
求助前，先用自己的话写一份任务说明。描述受众、明确不做什么，以及怎样才算完成。如果第二轮纠正后仍然没达到目标，就别继续小修小补了，重写提示词。
这件事也可以请智能体帮忙。我喜欢 Andy Clark 对两件事的区分：把任务委托给 AI 系统，以及与它协作。在后一种情况下，你们处于相互增强的良性循环：提示词让输出更好，输出又让下一次提示词更准确，也让你对问题的心智模型更清晰。如果哪里不清楚，就让智能体针对它不理解的地方采访你。如果结束会话时，你自己的心智模型得到了完善，这就是成功的信号。
同时，也要留意输入。每个智能体都很容易把上一个智能体的总结直接放进自己的上下文，没过多久，第三个智能体就根本没读过原始文档了。
你还需要有自己的输出标准。我在许多不同的创作媒介里尝试过 AI，其中大部分作品从未展示过，因为达不到我的标准。如今，产出看起来都排版整齐、语气自信，所以表面精致已经不再是有用的判断信号。
AI 或许让产出更快了，但如果我不愿意把成果署在自己名下，我就不会把它发出去。
如果某个结果达不到标准，就把原因记在共享配置、钩子或测试里，避免重蹈覆辙。品味就是这样积累、产生复利的；而记下某个结果为什么没能过关，本身也是很好的练习。
“可模型会比我更擅长这些”
如果你像我身边许多人一样看好这个领域的未来，读到前几节时，大概已经冒出过这个念头：再过一两年，模型就能发现我能发现的问题，那为什么还要费心维持这种能力？
在很多问题的识别上，你可能是对的，我自己也一直主张，把越来越多的问题检测交给智能体。但我认为它依然重要，原因是：归根结底，得有人为最终交付的东西负责。无论 AI 帮了多少忙，都必须由人承担责任。
对于某项具体任务，应该信任智能体到什么程度，这本身就需要判断。要让自己的判断保持准确，就得审阅它们的工作，因为模型犯错的地方一直在变。Anthropic 对自家工程师和研究人员所做的研究，指出了这个陷阱，称之为监督悖论：“监督 Claude，恰恰需要那些可能因过度使用 AI 而退化的编程技能。”
有几件事对我尤其重要，也不是更好的模型能替你解决的：你在构建什么，为什么值得做，会影响谁，以及你愿意牺牲什么？这些问题都需要你回答。智能体可以帮助梳理，我也希望它能帮忙，但最终，这些仍然是你的问题。
你可以把工作和大部分审核外包，却不能把最终责任外包。
日常可以做的练习
你不必一丝不苟地践行所有建议。把适合自己工作流的部分用起来就好。
每周，写一点不用智能体的代码，或者亲手做一件你真不愿意忘掉怎么做的事。（我把这称作校准练习，但它不是道德考验。）每月，写下自己已经不再做的事情，决定其中哪些是你可以接受不再做的。我很早以前的一篇博文里提出的问题，到现在仍然成立：如果没有 AI，你会有多不知所措？
如果有什么超出了你的理解，就去学。如果写作时遇到一个没见过的说法，我可以搜一下，拿一行解释直接放进去。但我更愿意做一点研究，真正理解它，这样才能知道它应该放在什么位置。
认真检查机器的工作，本身就是一项实实在在的工作。假装它不算工作，最后团队就不会去做。它不是免费的，所以把它单独列进日程，你才会真正完成。
不再练习的技能会消失，而且很可能比你想象得更快。那些你不愿失去的，就继续用。
你可以带走的要点
- 主动安排。智能体可以考你、采访你、向你展示证据，但前提是你设置了这些环节。那就设置好。
- 诚实面对自己在连续谱上的位置。如果连借助智能体都解释不了答案，你就已经放弃了判断。
- 先有假设。提问前先形成一个，哪怕猜得不好。
- 一个绿色勾号只说明一件事。它检查了什么？没检查什么？
- 找证据。先看它运行了什么、返回了什么，再读总结。
- 阅读时，要弄清楚它作出了什么决定。哪些事是它替你决定的？
- 打磨提示词。你如何表述请求，体现了你对问题理解有多深。
- 设定标准，并守住它。如果你不愿署上自己的名字，就别发布。
亲手运用那些重要的技能，让自己继续参与其中。你可以试一件事：提问前，写下自己预计会发生什么；智能体完成后，写下它没有检查的一件事。试试看，这会不会改变你阅读输出的方式，也欢迎告诉我。独立思考，问更好的问题，为结果负责。
