AI 写的代码越多，审查越像盖章：你不再审，只在盼
模型越好，明显错误越少，于是没人看第二眼。卸载、推迟、投降是一条没人察觉的下滑线；一个绿勾只证明一件事。
Addy Osmani 每天同时开好几个 agent 会话，是这套工作流的重度用户。他写这篇长文不是为了劝人少用 agent，恰恰相反——他要说的是：模型越强，你越不会去看输出。
原因反直觉：明显错误在变少。以前 agent 的结果一眼能挑出毛病，现在大多数输出写得清楚、大体正确，但它们不再"值得第二眼"。而不管你并行开多少个会话，落在输出上的眼睛始终只有一双。
过去，认知与审美的大部分处理发生在"问题"和"答案"之间的那段空白里。这段空白现在被压缩到几秒钟。
你必须把批判性思维排进日程，因为默认情况下没有任何东西会替你做。
一、不是模型变笨，是愉快本身让人松了手
用 agent 越多，这件事越难（但不是大家预期的那种难法）。随着模型变好，明显错误的占比下降，于是"看一眼就放心"的性价比越来越低——你看到的每一份输出都合格，警惕自然会松。
作者把这个机制归到一个很朴素的来源：agentic 工作流是愉快的。在忙碌的一天里，快速、顺手、大体正确的答案很提神，而这正是它让人放松警惕的原因。
要让这件事变难，只需要记住一条算术：并行开五个会话，验证的人还是你一个。
二、卸载、推迟、投降：一条没人察觉的下滑线
和人讨论时，作者把它描述成一条谱系，三档：
- 认知卸载（offloading）：把任务交给 AI，但保留对结果的所有权。他整天在做，你也应该做。
- 推迟（deferral）：工具的输出变成了你的新输入；结果不再被当作一个假设看待。
- 认知投降（cognitive surrender）：AI 的输出悄悄变成你自己的判断，你觉得没有必要再查。
"认知投降"这个词来自沃顿的 Steven Shaw 与 Gideon Nave，它精准地描述了作者看到的现象：随着信任（或惰性）上升，人会顺着这条谱系往下滑。
下滑之所以难自察，是因为每一级都很渐进、都显得合理。你上一篇答案读得挺认真，于是下一篇只扫一遍；再下一篇只看骨架；然后有人问起其中某一行，你解释不出来——即使 agent 就在旁边帮你解释，你也解释不出来。
这就是认知投降，也是认知债务累积的方式。它通常在你试图调用某个系统的心智模型、却发现那个模型根本不存在时才被发现。Margaret-Anne Storey 写过它在团队里的样子：共享的系统理论被慢慢侵蚀。代码侧的同构版本叫理解债务（comprehension debt，Jeremy Twei 提出）——代码库看起来干净、测试全绿，直到你要改一处才发现没人懂它了。读一份战略文档或规格书时只看目录就签了字，是同一件事。
这里必须给一个边界，否则这套说法会变成"你必须在脑子里装下整个系统"。作者明确说：装不下，现代大型代码库的心智模型没人能全量维持。Claude Code 团队公开讲过他们的做法是按需重建——需要理解哪一片，就让 Claude 解释那一片，而不是把完整模型常驻在脑子里。
这类债务比多数工程师以为的更容易恢复：你不需要持有全模型，只需要能在需要时局部重建。前提是你知道自己缺哪一块。
那么哪里可以彻底放手？作者给了自己的判断法——把交接放在"错了很便宜"的地方，把推理留在"后果会落到别人身上"的地方。
他最近录一门课，要在三家评分相近的酒店里选一个当录制地点，没时间逐条读评论，于是把决定交给了 AI。这次成了，他下次还会这么做。但换成怎么投钱、怎么建议孩子选职业，或者工作里的"我们该做什么、这个改动影响哪些用户、现在上线安全吗"，他不会。
三、我每天自问的七个问题
作者说他以前不确定自己怎么想的时候，会退回一组很基础的问题：我怎么知道自己在解决正确的问题？我怎么知道方法是对的？有支持结论的证据吗？我怎么知道做完了？多数时候这就是 who / what / where / why / when / how。写出来幼稚得可笑，但它逼你按类别思考，而那些类别你平时会跳过。
现在太容易跳过这一切：直接问 agent"你觉得我该怎么做"。于是他换了一组新问题：
1. 提问之前，我先立了假设吗？ 任何非平凡任务，动手跑 agent 前先在心里（甚至纸上）写下你认为答案是什么。猜错没关系，有了新信息你随时可以改。问题是：读完一份写得漂亮的回答之后，你很难再想象出别的可能性。如果完全没有方向，就要一次"盲区巡检"（Thariq Shihipar 的叫法）：把你已知的交给模型，让它去找你不知道自己不知道的部分。
2. 我是让它帮我思考，还是让它替我想？ 两者都行，前提是你知道自己在做哪一个。
3. 要让这个结论成立，什么必须为真？ 然后去查。模型对自己置信度的自评，价值远低于一次真能执行的测试——所以给它一个测试。
4. 我从另一个角度听过反方论证吗？ 在某个相对开放的问题上站定立场后，他会让不止一个模型去论证反面，然后自己读、自己形成判断。这更慢，但他最后对这个题材知道得更多。
5. 我敢不敢在维护它的人面前打这个赌？ 代码和任何交付物都适用。这是他心里的"可回答性"门槛。
6. 我已经不再练的是什么？ 也许是某些常规调试。让位可以，但要是有意的。
7. 老四问还在用吗？ 正确的问题、对的方法、存在的证据、何时算完成——这四条没有过期，只是现在容易被一句"你看着办"盖掉。
四、把验证变成习惯，但别把"绿了"当成结论
作者最近写了很多关于验证的东西，因为瓶颈已经从写代码移到了"确认自己对"。
当你给 agent 验证手段——端到端测试、属性测试，或者真实应用里的交互——它就能改一处、跑一遍验证、读输出、再试一次，全部发生在你还没看任何东西之前。这是 Boris Cherny 说的"给 Claude 一条验证自己的路"，作者认为这是拿到好结果最关键的一环：你不再逐行读，你在搭循环、读证据。
但验证同样可以被投降。"有支持我结论的证据吗"会退化成"检查绿了吗"。
两条原因让绿勾不可靠。第一，agent 造测试太便宜，你会看到很多绿；而一个通过的测试完全可能抓不到一个坏掉的功能——如果测试和功能犯了同一个错，它会一起通过。第二，一个绿勾只传达一个属性，而人太容易想象它覆盖了全部。
所以：绿了之后要问它证明了什么，再问它没证明什么。并且要事前定义"已验证"，因为事后你一定会把任何结果合理化。
完成线应该是可触摸的东西：测试通过、一张截图、一段日志或 trace。这样"做完了"的判据是事实，不留给"看起来差不多了"来解释。收到 agent 的完成通知时，先看它执行的命令和输出，再看摘要。
Claude Code 还能用新上下文的子 agent 对自己的活做一次自查，值得把这一步固化进循环，而不是靠你记得。作者自己每次收尾还会问一句"我漏了什么吗？"——听起来很傻，但用前沿模型做完一段复杂功能、看过、审过之后再问这句，它经常还能再吐出两三件事。
这些不必成为常态，知道什么时候该深挖本身就是技能。他最喜欢的经验法则来自 Claude Code 团队关于代码评审的那篇：
如果你说不出这些检查会漏掉什么，那就去要一次真正的评审，而不是点一个快速的通过。
这条也不限于代码。如果 agent 替你汇总了五十通客户电话或一份竞品分析，去抽查两份原始文档；如果某个数字支撑着你的建议，自己重算一遍它算得对不对。
agent 让"搭验证"变便宜了；对你来说难的是知道好的验证长什么样。
五、真的去看它生成了什么
设想 agent 给你一个 600 行的 PR。你大致看了一眼结构，没逐行读，变量名看着合理，测试是绿的，于是你批准了。但中间某处，一个事务边界悄悄换了次序；或者某个你没想过的边角情况，默认值被翻了过来。
你确实审了——只审了你早就知道会看到的东西。
写代码和评审是两种技能，而评审再往前一步就是盖章。所以作者的读法是：把这份 diff 当作不是 AI 写的来读，然后在 diff 之外，看 agent 自己做了哪些决定。一段长会话里它会替你定很多小事：默认值、"这不在范围内"、两条需求冲突时它重新解释了哪一条。
这些在"一切顺利"的摘要里看不到，所以要让它把做过的决定和假设列出来，然后自己考自己：随便挑几行问"这行呢？那行呢？"；看文档就关掉它，凭记忆把主论点写出来。有人对长会话有个他喜欢的习惯：让 Claude 写一份变更报告，末尾出一道考卷，规则是考满分才合并。
理由很简单：你要能为自己交付的东西辩护，因为总有一天会有人问。
agent 也能帮你守注意力。作者有个开源项目会收到大量 PR，他用 agent 判断哪些在进来、哪些违反项目指南、哪里最需要他，再自己去想"这些改动是不是用对的方法解决了对的问题"。他很少让 agent 自己拍板，但让它把范围收窄是有用的。
然后就是量。他对这件事的叫法是编排税（orchestration tax）：你的 agent 产出的量，与你愿意署名的量之间的差。如果完成的工作堆得比你消化的速度快，再开一个会话不解决问题——要么把检查收紧到更少的东西需要你来兜，要么慢下来。
当你产出的量超过你能为之背书的量，你不再是在审，你只是在盼。
六、输入决定输出：人从中间挪到了两端
人的心智模型还在参与，只是位置变了：从中间挪到了前端和后端。你的精力花在任务描述与上下文的前端，以及评审输出的后端。这也是为什么好的提问本身就是一项批判性思维技能。
过去你给一个含糊的需求，会有人当场挑战它，你于是意识到："等等，这件事我其实没想清楚。" agent 通常不会在那个位置拦你。它会补齐你没说的部分，然后交回一个看起来已经完成的东西，而背后的想法仍然是模糊的。
作者把这个叫意图债务（intent debt）：隐含的目标、约束和理由，存在于一份不是你写的产物里。别的债可能有人替你还，这一笔只能你自己还。
提示词是你对问题理解的投影。如果你说不清，多半在你脑子里也不清。
具体做法：先用你自己的话写一份需求简报——受众是谁、什么不在范围内、"完成"的定义是什么。第二轮修改还没把你带到那儿，就停下改字，重写提示词。
也可以让 agent 帮你做这件事。作者喜欢 Andy Clark 区分过的那条线：委托给一个 AI 系统，还是与它协作。后者是一个互相放大的正循环——你的提示词打磨输出，输出打磨你的下一个提示词，也打磨你对这个问题的心智模型。不清楚的时候，让 agent 反过来面试你，问它不懂的地方。一场会话结束时，如果你的心智模型被磨得更准了，那就算成功。
还要小心输入链：每个 agent 顺手把上一个 agent 的摘要塞进上下文，传到第三个时，它根本没读过原始文档。
输出标准也得是你自己的。作者在很多创作媒介里试过 AI，大部分东西没被发出来，因为没达到他的标准。格式漂亮、语气自信已经不再是信号——所有东西都长得体面。AI 让生产变快了，但如果他不愿意把这个产出署上自己的名字，他就不会发。
没达到标准的东西，把"为什么"写进共享配置、hook 或测试里，让它下次不再发生。品味是这样复利的；而且记下"为什么没入选"本身就是一种好练习。
七、"可是模型以后会比我在行"
看到这里，多数对这条技术曲线乐观的人都会冒出同一个念头：一两年后模型能检出我能检出的东西，那我还维护这项技能干什么？
在"检出"这件事上，你可能大部分是对的。作者自己也在主张把越来越多的检测推给 agent。但他认为这两点仍然成立。
第一，最后总要有人为上线的东西负责。不管 AI 帮了多少，责任落在人身上。而"这个任务该给 agent 多少信任"本身就是一个判断——保持校准的一部分就是继续看活，因为模型出错的方式一直在变。
Anthropic 对自家工程师与研究员的内部研究把这件事叫监督悖论："监督 Claude 需要恰恰是那些可能因为过度使用 AI 而退化的编码能力。"
第二，有些问题换个更强的模型也不会消失：你在建什么、它为什么值得、它影响谁、你愿意牺牲什么。agent 可以帮你想清楚，甚至你希望它帮你想，但最终这些问题还是你的。
你可以把工作外包出去，甚至把大部分审计也外包出去，但问责不行。
八、每天都做得到的几件小事
不用每条都严格执行，挑对你工作流有用的插进去。
每周一次，不靠 agent 写一点代码，或者做一件"忘了怎么做会很难受"的事。作者把它叫校准练习，但强调这不是道德要求。
每月一次，写下你已经不再做的事，然后决定哪些"我可以不做"。他博客里那个老问题依然有效：如果 AI 不存在，你会多迷茫？
高于你理解范围的东西，去学。写作时碰到没见过的说法，查一行解释就贴上去是最省事的做法；他更愿意多查一点，真正搞明白它在整个体系里处在哪一格。
把"检查"当成一项工作排进行程。 认真核对机器产出是实打实的工作，它不免费；假装它免费，团队就会变成"其实没人做"。排成一条 line item，它才会真的被执行。
你停止练习的技能会消失，而且比你猜的更快。 那些你不愿意放手的能力，继续手动做。
九、带走这几条
- 有意图。agent 能考你、面试你、给你看证据，但前提是你先把它设置成会这么做。
- 对自己在这条谱系上的位置诚实。讲不出答案——哪怕借助 agent 也讲不出——那它就是交出去了。
- 先立假设，哪怕很糟。
- 一个绿勾只说明一件事。它查了什么？没查什么？
- 找证据：先读它跑了什么、返回了什么，再读摘要。
- 读它做了哪些决定：它替你定了什么？
- 认真写提示词。你怎么写，就说明你对这个问题理解了多少。
- 定一条线并守住：你不会署名的东西，不要发出去。
- 想留住什么技能，就手动做那件事。
原文最后给了一个可以今天就开始的具体动作：提问前写下你认为会发生什么；agent 完成后，写下它没有检查的一件事。 然后看看这有没有改变你读输出的方式。
我们的整理：三档对照与三条判据
原文的三档谱系，压成一张表更便于自检：
| 状态 | 你做的事 | 你保留什么 | 落到谁身上 |
|---|---|---|---|
| 认知卸载 | 把任务交给 AI，自己仍是结果的所有者 | 结果的所有权 + 复核义务 | 你，且你讲得出来 |
| 推迟 | 把工具输出直接当成下一步输入 | 名义上的责任，实质上的假设权 | 你，但你已经不再怀疑它 |
| 认知投降 | 输出悄悄变成你自己的判断 | 几乎没有 | 你，而你已经解释不了它 |
三条可以马上用的判据：
- 说不出检查会漏什么 → 就别点通过，去要一次真评审。 这条对代码、对竞品分析、对客户访谈摘要同样成立。
- 绿了要追问两句：它证明了什么？它没证明什么？两个都答不上来，那个绿勾只是一个时间戳。
- 产出的速度超过你签得动的速度 → 先修检查，再开新会话。 这是编排税在收账，加一个 agent 不会让它变便宜。
对工程交付来说，"可触摸的完成线"其实就是三样东西：编译结果、仿真或测试 trace、可审计的日志。这三样都不在你的记忆里，而在产物里——这正是原文那句"完成的标准应该是事实，而不是解释"的意思。
边界与披露
- 本文完整编译 Addy Osmani 于 2026-11-03 发布的 X 长文《Critical thinking when agents do the work》。原文是经验性方法论：没有基准测试、没有量化数据、没有对照实验，文中判断按"作者主张"处理，我们未做本地复测。
- 术语与引语均保留出处（Steven Shaw / Gideon Nave 的 cognitive surrender、Margaret-Anne Storey 的团队系统理论、Jeremy Twei 的 comprehension debt、Thariq Shihipar 的 blind spot pass、Boris Cherny 的"给 Claude 一条验证自己的路"、Andy Clark 的委托与协作、Anthropic 的监督悖论）。涉及"Claude Code 团队说过"的内容为原作者转述，我们未能独立核实原文出处。
- 原文结尾的"发布你自己的文章"等平台引流、以及末尾的标签列表已删去；其余要点按原文顺序完整保留。
- 本文由 Software 2.0 编译整理，转载请注明出处。
Sources
- 原文：Addy Osmani《Critical thinking when agents do the work》，X Article，2026-11-03 https://x.com/i/article/2116367635365695488（帖文：https://x.com/addyosmani/status/2117512471930167377）
- 作者主页：https://x.com/addyosmani
同主题阅读
这是「AI 编程 / Vibe Coding」专题的一部分。完整地图见：AI 编程 / Vibe Coding 完全指南
