#模型时代# 当智能体替你工作，如何保持批判性思维

---
作者是 Addy Osmani（阿迪·奥斯马尼），X 账号为 addyosmani。他目前在 Anthropic 的 Claude Code 团队工作，此前在 Google 任职超过 14 年，曾负责 Chrome 开发者体验，并担任 Google Cloud AI 总监。也是《JavaScript 设计模式》等技术书籍的作者。原文之下，他特意注明文章是人类所写，非AI生成。

他讲的是工程是Coding。我类比到文字创作。自己的体会是，一定要小心AI写的情绪反应和价值判断。不过，现实来看，用AI写这种内容的推文（X上的中文推文），流量是很高的。

个人网站：addyosmani.com

---

过去，我们接受的批判性思维教育，是在面对新信息时保持谦逊、好奇，以及适度的怀疑：听取不同观点，形成自己的看法。这些道理依然成立。但如今，我的大量工作都通过智能体完成，日常工作中越来越少有事情会迫使我进行批判性思考。对于那些已经全面拥抱智能体工作流的工程师和产品人员——同时运行多个会话，并期待模型不断进步的人——我想先说清楚：我非常喜欢这些工具。我写这篇文章，并不是为了劝大家少用智能体工作流。

我的目的是帮助你在一个什么都可以轻易交给智能体的世界里，保持批判性思维。

过去，我们的大部分认知加工和审美判断，都发生在提出问题与得到答案之间的那段时间里。现在，这段时间已经缩短到以秒计。你越多地使用智能体工作流，保持批判性思维就越困难，不过原因可能与人们原先的预想不同：随着模型进步，明显错误的比例越来越低。许多输出，甚至可能是大多数输出，都会写得很好，而且基本正确，却不会让你觉得有必要再看一遍。

即便你同时运行着许多个智能体，审视这些输出的，也依然只有你这一双眼睛。

你必须主动把批判性思维安排进每天的工作，因为默认情况下，没有什么会替你做到这一点。

之所以很难自行纠正这种倾向，部分原因在于智能体工作流用起来很舒服。在忙碌的一天中，快速获得令人满意、通常又正确的答案，让人感觉轻松。但也正因为如此，你很容易放松警惕。

卸载、让渡与投降

和别人讨论这件事时，我会把它描述为一个连续谱：

最上端是认知卸载：把任务委托给 AI，但仍然保有对结果的掌控和责任。我整天都在这么做，你也应该这样做。中间是判断让渡：工具的输出直接成为你的下一步输入，它给出的结果已经不再被当作一个有待检验的假设。最下端则是认知投降：AI 的输出悄然变成了你自己的观点，而你觉得没有必要核查。

“认知投降”是沃顿商学院的 Steven Shaw 和 Gideon Nave 提出的术语。它非常贴切地描述了我观察到的现象：随着信任增加，或者随着人变懒，大家会沿着这条连续谱逐渐下滑。这种转变很少被察觉，因为每一步都很缓慢，看起来也都合情合理。上一个答案你认真读过了，于是下一个就略读一下；再下一个，你只扫一眼框架。直到有人问起其中某一行，你才发现自己解释不清，甚至连智能体帮忙也解释不清。

这就是认知投降，也是认知债务积累的方式。通常，只有当你试图调用自己对系统的心智模型，却发现它根本不存在时，问题才会暴露。Margaret-Anne Storey 写过，这种现象在团队中表现为：大家对系统如何运作的共同理解逐渐流失。我也写过它在代码层面的对应现象——理解债务，这个术语由 Jeremy Twei 提出。它在当下完全不可见：代码库看起来整洁无瑕，测试全部通过。直到你需要修改系统，才发现已经没有人真正理解它，问题这时才显现出来。如果你只看了一份战略文档或规格说明的目录，就批准了它，情况也是一样。

需要说明的是，我并不是要求大家做到不可能的事。面对一个庞大的现代代码库，没人能在头脑中完整保留它的心智模型。Claude Code 团队曾公开表示，他们会按需重建理解：需要理解某一部分时，就让 Claude 解释那一块，而不是始终把整个系统的模型装在脑子里。正如我以前写过的，这类债务比大多数工程师想象的更容易补回来。只要你能在需要时重建对局部的理解，就不必始终保有完整模型。你只需要知道，自己缺少哪些理解。

对于出错代价较低的事情，完全可以放心交出去。但如果一个问题的答案连你自己都解释不了，即便借助智能体也不行，那么你就已经让出了对结果的掌控。

这也不一定总是问题。就在不久前，我录制一门课程，需要从三家评分相近的酒店中选一家作为录制地点。我没时间逐条查看所有评论，就把这个决定交给了 AI。结果不错，下次我还会这么做。但在决定如何投资家里的钱、如何给孩子提供职业建议，或者在工作中决定应该做什么产品、哪些改动会影响哪些用户、能否安全发布时，我不会这么做。出错代价低的事情，可以交出去；如果后果需要别人承担，就要保留自己的推理和判断。

我会问自己的问题

过去，当我不清楚自己究竟怎么想时，通常会回到一组最基本的问题：我怎么知道自己正在处理的是正确的问题？我怎么知道解决方式是对的？有没有证据支持我的结论？我怎么知道工作已经完成了？大多数时候，无非就是谁、什么、哪里、为什么、何时，以及如何。

把这些问题写出来，看着简直像小孩子的提问，但它们会迫使你从一些原本可能忽略的角度思考。如今，我们太容易跳过这一切，直接问智能体它认为我们该怎么做。下面这些，是我现在会问自己的新版问题。

提问之前，我有没有先形成一个假设？ 在让智能体处理任何不那么简单的任务之前，我会先记下自己认为答案可能是什么，哪怕只是在脑子里想一下。猜得不好也没关系。获得新信息之后，随时可以改变主意。但一旦读过一个写得很好的回答，你就很难再想象其他可能性了。如果你完全没有方向，可以请模型做一次 Thariq Shihipar 所说的“盲点检查”：把你知道的告诉它，让它找出那些“你不知道自己不知道”的事情。

我是在请它帮助我思考，还是把思考交给它？ 两种做法都可以，前提是你知道自己正在做哪一种。

什么情况一旦成立，就意味着这个结论是错的？ 然后去查清楚。模型对自身信心的评估，远不如一个你能实际执行的检验有价值，所以，给它安排这样的检验。

我有没有从另一个角度听过反方意见？ 当我在一个相对开放的问题上持有强烈立场时，我会请不止一个模型站到对立面进行论证，然后审视它们的输出，再形成自己的判断。这样更费时间，但最终我会对这个话题了解得多得多。

当着今后要维护这项成果的人的面，我敢为这个结果下注吗？ 这既适用于代码，也适用于你交付的任何其他东西。我认为，能够对交付负责，至少应该达到这个标准。

我正在停止练习哪些能力？ 可能是某些日常调试技能。我可以接受放下一部分，但我希望这是有意识的选择。

把验证变成习惯

最近，我写了很多关于验证的文章，因为我相信，瓶颈已经从编写代码转移到了确认自己是否做对。

当你给智能体提供验证自身工作的手段，无论是端到端测试、基于属性的测试，还是与实际应用交互，它就能完成修改、运行验证、读取输出，然后再次尝试，而这一切都可以发生在你开始查看之前。这就是 Boris Cherny 所说的“给 Claude 一种验证自己工作的办法”。我认为，这是获得出色结果最关键的要素之一。你的工作将更多地变成建立这些循环、审查证据，而不再是逐行阅读。

但验证本身也可能被你交出去。“有没有证据支持我的结论？”会变成“检查是不是亮绿灯了？”智能体让编写测试的成本变得很低，所以你会看到很多绿灯，但一个通过的测试，可能根本发现不了某项功能已经坏了。如果测试和功能犯了同样的错误，测试就会通过。而且，一个绿色对勾只说明某一项性质得到了验证。我们却很容易想当然地认为，它覆盖了一切。

当检查亮起绿灯时，问问它证明了什么。然后再问，它没有证明什么。

提前定义什么叫“验证通过”，因为事后你总能为任何结果找到合理化的解释。

智能体工作的完成标准，应该是某种具体可查的东西：一个通过的测试、一张截图、一份日志或一段追踪记录。这样，工作的完成标准就建立在事实之上，而不是根据“看起来已经做完了”之类的感觉来解释，乃至放弃判断。当你收到智能体的完成通知时，先别看总结，先看它实际执行的命令片段，以及命令的输出。

Claude Code 也可以通过一个使用全新上下文的子智能体，对自己的工作进行自我审查，检查是否存在明显问题。值得把这一步固定纳入工作循环，让它每次都执行，而不是只在你想起来时才做。

最后，我仍然会问一句：“我有没有遗漏什么？”这听起来很傻，但很多时候，我用前沿模型完成一个复杂功能，自己看过、审查过，再问一句“我有没有遗漏什么？”，它就会回来告诉我还有两三件事。这就是我为什么每次都要问。

当然，你不必每次都做到这个程度；知道什么时候应该深入检查，本身就是一种能力。在我们介绍 Claude Code 团队如何做代码审查的文章里，我最喜欢的一条经验是：“如果你说不清这些检查会漏掉什么，就请人做一次真正的审查，而不是走个快速批准的流程。”

这也适用于代码之外的工作。如果智能体替你汇总了五十次客户通话，或者完成了一份竞品分析，就抽查几份原始材料，确认总结是否准确。如果你的建议依赖某个数字，就检查一下它是否计算正确。

智能体已经让建立验证机制变得很便宜。对你来说，难的是判断什么样的验证才算好。

真正关注生成的内容

假设智能体交给你一个涉及六百行代码的拉取请求（PR）。你大致看了一下结构，没有逐行阅读。变量命名看起来合理，测试也都通过，于是你批准了它。但在中间某个地方，事务边界上的执行顺序发生了细微变化，或者在一个你从未考虑过的边界情形中，某个默认值被改成了相反的值。你大概也算审查过了吧，但你关注的，只是那些你原本就预想到会看到的东西。

写代码和审查代码是两种不同的能力，而审查越过某个界限，就会变成例行盖章。所以，把代码差异当作不是 AI 写的那样去阅读，然后再跳出差异本身，看看智能体究竟替你作出了哪些决定。在一次长时间会话中，它会替你作出许多小决定：默认值是什么，哪些事情不在范围内，两项要求冲突时，它选择重新解释哪一项。

这些东西不会出现在一份“一切顺利”的总结里，所以要让它列出自己作出的决定和采用的假设。然后考考自己。随机挑几行，问问：这一行是怎么回事？那一行呢？如果是一份文档，就把它关掉，试着凭记忆写出主要论点。

有些人处理长会话时有一个习惯，我很喜欢：让 Claude 写一份变更报告，并在报告末尾出一套测验，规则是：“只有全部答对，我才合并。”

你应该充分理解自己要交付的东西，理解到足以为它作出解释、为它辩护。因为总有一天，可能会有人问起。

智能体也能帮助你守住注意力。比如，我有一个开源项目，会收到大量拉取请求。我会用智能体帮助判断：收到了哪些改动，哪些不符合我们的规范，哪里可能需要我关注。我很少让智能体自行拍板，但它们可以缩小范围，指出我应该把注意力放在哪里。然后，我才能真正思考这些改动是否在用正确的方式解决正确的问题。

还有一个问题是数量，你必须诚实地面对自己的承受能力。我把它称为“编排税”：智能体生成的工作量，与那些你愿意放心署上自己名字的成果之间，存在一道差距。如果完成的工作堆积得比你审查得还快，那么在解决这个问题之前，再开一个会话也没有帮助。你要么加强检查机制，让更少的内容需要你亲自介入，要么放慢速度。

当你产出的东西多到自己无法为之负责时，你就已经不是在审查，而是在寄希望于它没出问题。

高质量输入，才能带来高质量输出

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

过去，如果你提出一个含糊的要求，别人会追问，你也许会意识到：“等等，这件事其实我还没想清楚。”智能体往往不会在这里叫停。它会补上你遗漏的部分，然后交还一个看起来已经完成的结果，即便这个结果背后的想法仍然模糊不清。

我曾把这种现象称为“意图债务”：那些并非由你亲手写成的产物中，可能包含着隐含的目标、约束和理由。与其他类型的债务不同，这一种没人能替你解决。意图必须来自你自己。

你的提示词反映了你对问题的理解。如果你无法清晰地表达它，也许它在你自己脑子里就还不清楚。

在寻求帮助之前，先用自己的话写一份需求简述。说明受众是谁，哪些事情不在范围内，以及怎样才算完成。如果第二轮纠正之后仍然没达到要求，就别再小修小补了，重写提示词。

这件事也可以让智能体帮忙。我很喜欢 Andy Clark 对“把任务委托给 AI 系统”和“与 AI 系统合作”所作的区分。在后一种情况下，你会进入一个彼此促进的良性循环：提示词让输出更准确，输出帮助你改进下一条提示词，也让你对问题的心智模型更加清晰。如果事情还不明确，就让智能体围绕它不理解的部分来采访你。如果结束会话时，你对问题的心智模型得到了完善，这就是成功的迹象。

同时，也要留意输入材料。让每个智能体直接把上一个智能体的总结放进自己的上下文，实在太容易了。没过多久，第三个智能体可能就已经完全没读过原始文档。

你还需要为输出建立自己的标准。我尝试过用 AI 进行许多不同媒介的创作，其中大部分从未公开展示，因为它们达不到我的标准。如今，所有东西都能以漂亮的格式、自信的口吻呈现出来，所以，表面的精致已经不再是一个有用的质量信号。

AI 或许加快了生产速度，但如果我无法安心地把某个结果署在自己名下，我就不会把它发布出去。

当某个结果不符合你的标准时，把原因写进共享配置、钩子（hook）或测试中，避免同样的问题再次出现。品味就是这样不断积累的，而记录某个结果为什么没有过关，本身也是一种很好的练习。

“但模型会比我更擅长这些”

如果你像我身边许多人一样看好这个领域的未来，那么读到前面几节时，你可能就已经在想：再过一两年，模型就能发现所有我能发现的问题了，为什么还要费力保留这项能力？

在许多问题的识别上，你可能是对的。我自己也一直主张，把越来越多的检查工作交给智能体。但我认为，这项能力依然重要，原因在于：归根结底，必须有人为最终交付的东西负责。无论 AI 帮了多少忙，都得有人承担责任。

对于某一项具体任务，究竟该在多大程度上信任智能体，这本身就需要判断。要持续校准这种判断，审查它的工作就是其中一环，因为模型会犯什么错，一直在变化。Anthropic 对自家工程师和研究人员的研究，也指出了这个陷阱，并称之为“监督悖论”：“监督 Claude，恰恰需要那些可能因过度使用 AI 而退化的编程技能。”

有些问题对我来说最为重要，而更好的模型也无法替我解决：你在构建什么？为什么值得做？它会影响谁？你愿意为此牺牲什么？这些问题都需要你自己回答。智能体可以帮助你想清楚，我也希望它能帮忙，但最终，这些问题仍然属于你。

你可以把工作和大部分审查交出去，但不能把责任交出去。

日常可以做的练习

你不必严格执行这里的每一项。把适合自己工作流的做法加进去就好。

每周，脱离智能体写一点代码，或者亲手做一件一旦忘了怎么做就会让你很难受的实际工作。我把这叫作“校准练习”，但它不是一种道德上的自我检验。每个月，写下你已经不再亲自做的事情，然后决定其中哪些是你可以接受不再做的。我在一篇旧博客里提出的问题，至今依然有效：如果 AI 不存在了，你会有多不知所措？

如果某件事超出了你的理解，就去学。我在写作时，如果遇到一个以前没见过的说法，当然可以用 Google 搜一句话的解释，然后直接写进文章。但我更愿意稍微研究一下，真正理解它，这样才能知道它应该放在什么位置。

认真检查机器的工作，本身就是一项实实在在的工作。假装它不是，正是团队最终不做这件事的原因。它不是零成本的，所以把它作为一个独立事项安排进日程，你才会真正完成它。

停止练习的技能会逐渐消失，而且很可能比你想象得更快。那些你不愿失去的能力，就要继续使用。

你可以带走的几点提醒

有意识地安排。 智能体可以考你、采访你，也可以向你展示证据，但前提是你作了这样的安排。那就把它安排好。

诚实地判断自己处在连续谱的什么位置。 如果你连借助智能体都解释不清答案，就已经放弃了对它的掌控。

先有一个假设。 在提问之前先形成一个，哪怕猜得不好。

一个绿色对勾只说明一件事。 它检查了什么？又没检查什么？

寻找证据。 先看它运行了什么、返回了什么，再看总结。

阅读时，要弄清它作出了哪些决定。 它替你决定了什么？

认真打磨提示词。 你如何写出请求，反映了你对问题理解到什么程度。

设定标准，并坚持下去。 如果你不愿意在上面署名，就不要把它交付出去。

通过亲自运用那些重要技能，让自己始终参与其中。 你可以试一件事：提问之前，写下你认为会发生什么；智能体完成之后，写下它没有检查的一件事。试试看，这是否会改变你阅读输出的方式，也欢迎告诉我结果。独立思考，提出更好的问题，为结果承担责任。