Agent 把活干了，批判性思维去哪儿了

以前讲批判性思维，说的是拿谦逊的好奇心加一点必要的怀疑去看新信息：多听几种说法，然后形成自己的判断。这话现在依然成立。但随着我大部分工作都从 agent 里过一遍，日常里已经没什么东西逼着我批判性思考了。

对已经全面拥抱 agentic 工作流的工程师和产品同学（同时开好几个会话、指望模型一轮比一轮好），我先把话说清楚：我很喜欢这些工具，写这篇不是要劝你少用。我的目的是帮你在一个人人都很容易把任何事甩给 agent 的世界里，保住批判性思维。

过去，我们大部分认知加工和审美判断发生在提问和回答之间的那段时间里。这段时间现在以秒计。而 agentic 工作流用得越多，事情越麻烦，而且麻烦的方式和多数人想的不一样：模型变强之后，明显错误的比例在下降。很多（也许大多数）输出写得漂亮、大体正确，它们不要求你再看一眼。

就算你同时开着很多个 agent，看输出的还是只有你这一双眼睛。

所以你必须把批判性思维塞进日程里。默认状态下，没有东西会替你做这件事。

这事之所以难自纠，还因为 agentic 工作流很舒服。在忙碌的一天里拿到快速、顺滑、通常正确的答案，确实提神；而这恰恰也是你更容易放松警惕的原因。

一、卸载、转交、投降

跟人聊这个话题时，我把它说成一条光谱：

最上面是认知卸载：把任务委派给 AI，但结果的所有权还在你手里。我整天这么干，你也该这么干。中间是转交：工具的输出变成了你的新输入，一个结果从此不再是假设。最下面是认知投降：AI 的输出悄悄变成了你自己的，你觉得没必要再查。

「认知投降」这个词是沃顿的 Steven Shaw 和 Gideon Nave 造的，跟我看到的现象严丝合缝：随着信任（或者懒）增加，人会沿着这条光谱往下滑。这个过渡很少被察觉，因为每一小步都很平缓，看起来都合理。上一份答案你读得很细，下一份就略读了；再下一份你只扫了骨架；然后有人问你某一行，你说不清，就算 agent 在场也说不清。

这就是认知投降，认知债就是这么攒起来的。它通常在你试图调用某个关于系统的思维模型、却发现模型根本不存在的时候才暴露。Margaret-Anne Storey 写过这在团队里怎么表现为「对共享的系统理论的理解不断被侵蚀」。我写过代码侧的版本，理解债（这个词是 Jeremy Twei 造的）。在发生的当下，它完全隐形：代码库看着干净，测试全绿。直到你要改动系统，才意识到已经没人懂它了。你读了策略文档或规格的目录然后签字，是一模一样的机制。

说清楚，我不主张做不可能的事。要在大规模现代代码库里维持完整的心智模型，本来就不可能。Claude Code 团队公开说过，他们是按需重建理解：需要懂某一块时，让 Claude 讲那一块，而不是把整个模型揣在脑子里。我也写过，这类债比多数工程师以为的更可回收。你不需要一直持有完整模型，只要能在需要时就地重建。你只需要知道自己「没有」什么。

赌注低的地方，尽管完全委派。而当一个问题你连借 agent 的力都解释不了，那说明所有权已经交出去了。

这也不总是问题。前阵子我录一门课，要从三家评分差不多的酒店里挑一个当录制场地，我没时间逐条翻评论，就把这个决定交给了 AI。它办成了，我下次还会这么做。但换到投资、换到给孩子建议职业、换到工作上的「我们该做什么」「这个改动影响哪些用户」「能不能安全上线」，我就不会这么做。错得起的地方，可以交出去；后果要别人接着承担的地方，推理得留在你手上。

二、我现在问自己的问题

拿不准的时候，我以前会回到一张很基础的问题清单：我怎么知道我解决的是对的问题？我怎么知道我用的方法对？有什么证据支持我的结论？我怎么知道我完事了？多数时候，这就是谁、什么、哪里、为什么、何时、如何。写出来幼稚得可笑，但它逼你按那些平时会忽略的类别去想。如今跳过这一切、直接问 agent「你觉得我该怎么办」太容易了。下面是我现在问自己的新版问题。

提问之前，我立假设了吗？ 让 agent 处理任何非琐碎任务之前，我先写下（哪怕只在脑子里）我认为答案可能是什么。猜得烂没关系，见到新信息改主意随时欢迎。可一旦你读完一段写得漂亮的回答，就很难再想象别的可能性了。如果完全没头绪，就找 Thariq Shihipar 说的那种盲区扫描：把你知道的给它，让它去找你不知道的未知。

我是在让它帮我思考，还是让它替我思考？ 两者都行，前提是你知道自己在做哪一种。

这件事要成立，哪些前提必须为真？ 然后去查。模型对自己置信度的自评，远不如一个你真能跑的实验，所以给它一个实验。

我从另一个角度听过反方吗？ 当我在某个本来就开放的问题上态度很硬，我会让不止一个模型去论证反面，然后看它们的输出，自己下判断。这更慢，但最后我对这件事的了解多得多。

我敢不敢当着维护这段东西的人下这个赌注？ 代码如此，你交付的任何东西都如此。我认为这就是「可解释性」的门槛。

我正在不再练的是什么？ 可能是某些例行调试。让一部分走掉没关系，但我要这是我自己选的。

三、把验证变成习惯

最近我写了很多关于验证的东西，因为我相信瓶颈已经从「写代码」挪到了「确认自己是对的」。当你给 agent 一个能验证自己动作的手段——端到端测试、属性测试、真的去操作应用——它就能在你还没看任何东西之前，自己改、自己跑、自己读输出、自己重试。这就是 Boris Cherny 说的「给 Claude 一条验证自己工作的路」，我认为这是拿到好结果最关键的环节之一。你要做的不是逐行读，而是把这些循环搭起来，然后审证据。

验证也可以「投降」：「有证据支持我的结论吗」变成「检查是不是绿的」。agent 造测试太便宜了，你会看到大片绿色，而一个通过的测试完全可能没覆盖到一个坏掉的功能。如果测试和功能犯的是同一个错，它就会通过。而且一个绿灯只传达一条性质，人太容易想象它覆盖了一切。

绿灯亮的时候，问它证明了什么，再问它没证明什么。

「已验证」要在开始前就定义，否则事后你会为任何结果找理由。

agent 干活的终点应该是可触摸的东西：一个通过的测试、一张截图、一段日志或 trace。这样「完成」的标准是事实，而不是「看起来像是做完了」这种靠解释（和靠投降）的判断。收到 agent 的完成通知时，先别看它的总结，先看它执行的那条命令和命令的输出。

Claude Code 还能（用一个全新上下文的 subagent）自我批评，作为一次旁路体检，值得固定进循环里，让它每次跑，而不是你记得才跑。我到最后还是习惯问一句「我漏了什么吗」。听着傻，但经常是这样：我用前沿模型做完一个复杂功能，看了看，审了审，然后问「我漏了什么吗」，它会再补两三件出来。这就是我每次都问的原因。

当然，这些不必成为常态，知道什么时候该深挖本身就是一种技能。我最喜欢的一条经验法则，来自我们写 Claude Code 团队怎么做代码评审的那篇：「如果你说不清这些检查会漏掉什么，就要求一次真正的评审，而不是一次快速批准。」

这条在代码之外同样成立。如果 agent 替你综合了五十通客户电话或者一份竞品分析，去抽两份原始文档核对摘要准不准；去查一个你的建议所依赖的数字，看它算得对不对。

agent 让「搭验证」变便宜了。对你来说真正难的，是知道好的验证长什么样。

四、真的去看它生成了什么

假设 agent 给你一个 600 行的 PR。你大致看了下结构，没逐行读。变量名看着合理，测试也过了，于是你批了。但中间某个事务边界上有一处细微的顺序调整，或者某个你从没想过的边界情况上默认值被翻转了。你确实「评审」了，只不过你只在你已经知道会看到什么的地方看过。

写代码和读代码是两种不同的技能，而评审到某个点就变成了盖章。所以要像「这 diff 不是 AI 写的」那样去读，然后再越过 diff，去看 agent 替你做了哪些决定。在一个长会话里，它替你做了一堆小决定：默认值、哪些不在范围内、两条需求冲突时它改写了哪一条。

这些在一个「一切顺利」的总结里都看不到，所以要让它列出它做的决定和假设。然后考自己。随便挑几行问：这行是干嘛的？这行呢？如果是文档，把文档关掉，试着凭记忆把主要论点写出来。有个我喜欢的习惯，适合长会话：让 Claude 写一份关于这次改动的报告，然后在末尾给你出一份小测，规矩是「我只在小测全对之后才合并」。

你要懂到能为自己交付的东西辩护的程度。因为总有某个时刻，会有人来问。

agent 也能帮你管注意力。比如我有一个开源项目收到大量 PR，我会用 agent 帮我判断哪些是新的、哪些违背了我们的准则、哪里大概需要我亲自看。我很少让 agent 自己定这件事，但它可以把范围收窄到我真正该投入注意力的地方，然后我才能真的去想：这些改动是不是在用对的方法解决对的问题。

然后是量的问题，这一点你得对自己诚实。我把它叫编排税：你的 agent 生成的东西，和你愿意署名认可的东西之间，有一个差额。如果完成的工作堆积得比你看得快，再开一个会话也没用——要么把检查收紧，让需要你的部分变少，要么慢下来。

当你产出的东西多于你能背书的范围，你就不在评审了。你在祈祷。

五、输入的质量决定输出的质量

人的心智模型依然在场，只是位置变了：它从中间挪到了开头和结尾。你的精力投在任务描述和上下文这一头，以及审输出那一头。所以好的输入对输出的质量如此关键，而我把「会写提示词」当成一项批判性思维技能。

以前你提一个含糊的需求，会有人顶回来，你可能会意识到「哦，其实我自己也没想清楚」。agent 通常不会在那儿拦你。它会把你省掉的部分补齐，交回一个看起来完成的东西，哪怕背后那个主意还是糊的。我把这个叫意图债：那些隐含的目标、约束和理由，存在于你没亲手写的产出物里。跟别的债不同，这一种没人能替你还。意图必须来自你。

你的提示词是你对问题理解的镜像。如果你说不清，可能它在你心里本来就没清楚。

在求助之前，用你自己的话写一份需求说明：说清受众、范围外的东西、什么算做完。当第二轮修改还没把你带到那儿，别再抠细节，重写提示词。

这件事也可以让 agent 帮你。我喜欢 Andy Clark 的一个区分：把任务委派给一个 AI 系统，和与它协作。后一种情况里，你在一个互相放大的良性循环里：你的提示词让输出更锋利，更锋利的输出让下一个提示词更锋利，再让你对问题的理解更锋利。如果不清楚，就让 agent 来采访你，问它不懂的地方。如果你结束会话时发现自己的心智模型被磨得更清楚了，那就是成功的信号。

输入本身也要当心。很容易出现每个 agent 都把上一个 agent 的摘要塞进自己的上下文，没几轮，第三个 agent 根本没读过原始文档。

输出还得有你自己的一套标准。我在各种创作媒介里玩过 AI，大部分成果从没给人看过，因为它们没达到我的标准。现在东西出来都排版整齐、语气自信，所以「精致」不再是有效信号。

AI 让生产变快了，但如果我不愿意把这份产出算作自己的，我就不发它。

当某样东西没达到你的标准，把原因写进共享配置、hook 或者一个测试里，让它别再发生。这就是品味复利的方式；而且就算只看记录「为什么这个没过关」本身，这也是个好习惯。

六、「可是模型以后会比我强」

如果你对这条赛道的未来和我身边很多人一样乐观，那你读到这里大概已经想过：一两年之后，模型能察觉的我也能察觉，那还费劲维持这个能力干嘛？

在「察觉」这件事上，你可能是对的，而且我自己也一直在主张把越来越多的检测交给 agent。但这件事依然要紧，理由是这样：东西上线之后，总要有人负责。不管 AI 帮了多少，责任得由人来扛。

「某个任务该多信任 agent」本身就是个判断题。保持校准的一部分就是去评审，因为模型搞错的方式一直在变。Anthropic 对自家工程师和研究员的研究点出了这个陷阱，叫监督悖论：「监督 Claude 所需要的，正是那些可能因过度使用 AI 而退化的编码能力。」

下面这些是我最在意、也是更强的模型解决不了的：你在造什么，它为什么值得，它影响谁，你愿意为此牺牲什么。这些都得你自己回答。agent 可以帮你想清楚，我也希望它帮，但答案终究是你的。

你可以把活卸出去，也可以把大部分审计卸出去，但责任卸不掉。

七、日常可执行的几条

不需要样样都做得一丝不苟，拣能进你工作流的就行。

每周写一点不带 agent 的代码，或者做一件「忘了怎么做会很惨」的真事。（我把这叫校准练习，但这不是道德要求。）每月写一下你已经不再做的事，然后决定哪些你接受不再做。我早年一篇博客里的问题依然有效：如果 AI 不存在，你会多茫然？

有东西超出你的理解，就去学。我写东西碰到没见过的词组，本可以搜一行解释贴进去；我更愿意多查一点真正搞懂它，这样才知道它该放在哪儿。

认真检查机器是实打实的工作，假装它不是，就是团队最后干脆不检查的方式。它不免费，所以把它当成一个正式条目排进日程，你才真的会做。

你不再练的技能会消失，而且可能比你猜的更快。那些你不愿意放手的，继续练。

八、随身带走的东西

• 要有意图。 agent 可以考你、采访你、给你看证据，但前提是你把这套搭起来。那就搭起来。
• 对自己在光谱上的位置诚实。 如果一个问题连借 agent 的力都解释不了，你已经把它交出去了。
• 先有假设。 提问之前先立一个，哪怕很差。
• 一个绿灯只说明一件事。 它查了什么？没查什么？
• 找证据。 先读它跑了什么、返回了什么，再读总结。
• 读，是为了知道它做了哪些决定。 它替你决定了什么？
• 打磨你的提示词。 你怎么写提示，说明你对问题理解了多少。
• 定一条线，守住它。 你不愿意署名的东西，就别发出去。

靠手动去做那些要紧的技能，把自己留在场上。有件事你可以试试：提问之前，写下你认为会发生什么；agent 做完之后，写下一样它没检查的东西。如果这改变了你读输出的方式，告诉我。独立思考，问更好的问题，对结果负责。