> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# AI 写的代码越多，审查越像盖章：你不再审，只在盼
- URL: https://www.hubwiz.com/blog/critical-thinking-when-agents-do-the-work/
- Published: 2026-11-03T17:01:45.000Z
- Updated: 2026-11-03T17:06:28.000Z
- Description: 模型越好，明显错误越少，于是没人看第二眼。卸载、推迟、投降是一条没人察觉的下滑线；一个绿勾只证明一件事。
- Author: admin
- Tags: AI 编程, Agent, 代码评审, 认知

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，自己仍是结果的所有者 | 结果的所有权 + 复核义务  | 你，且你讲得出来    |
| 推迟   | 把工具输出直接当成下一步输入      | 名义上的责任，实质上的假设权 | 你，但你已经不再怀疑它 |
| 认知投降 | 输出悄悄变成你自己的判断        | 几乎没有           | 你，而你已经解释不了它 |

三条可以马上用的判据：

1. **说不出检查会漏什么 → 就别点通过，去要一次真评审。** 这条对代码、对竞品分析、对客户访谈摘要同样成立。
2. **绿了要追问两句**：它证明了什么？它没证明什么？两个都答不上来，那个绿勾只是一个时间戳。
3. **产出的速度超过你签得动的速度 → 先修检查，再开新会话。** 这是编排税在收账，加一个 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/i/article/2116367635365695488?ref=hubwiz.com)（帖文：[https://x.com/addyosmani/status/2117512471930167377](https://x.com/addyosmani/status/2117512471930167377?ref=hubwiz.com)）
- 作者主页：[https://x.com/addyosmani](https://x.com/addyosmani?ref=hubwiz.com)

**同主题阅读**

- [Claude Code 团队怎么做代码评审：7 层防线，把人工时间压到最低](https://www.hubwiz.com/blog/claude-code-team-code-review/)
- [Agent 老是散架？该修的是 harness，不是提示词](https://www.hubwiz.com/blog/harness-engineering-agent-guide-lunar/)
- [Agent 上线复盘：重启失忆、重复退款、超时当失败](https://www.hubwiz.com/blog/agent-restart-replay-idempotency-retro/)

> **这是「AI 编程 / Vibe Coding」专题的一部分。**完整地图见：[AI 编程 / Vibe Coding 完全指南](https://www.hubwiz.com/blog/vibe-coding-stack/)