# 在 Agent 时代，如何守住你的批判性思维

Author: Tiger | URL: https://goagi.top/agent-2

## 结论与核心摘要（直接答案与证据）
这是一篇探讨在 Agent 时代如何保持独立思考与专业把控力的技术随笔，来自 Claude Code 的 Addy Osmani（ @addyosmani） 。

Evidence from the source:
- 过去，人们谈到“批判性思维”（Critical Thinking），总说要怀着谦逊的好奇心与适度的怀疑来面对新信息——兼听不同观点，形成自己的判断。
- 这话依然没错；但现实是，随着我日常工作的大部分内容都交给了 Agent，生活中越来越没有什么事情在“逼”我进行批判性思考了。

## 正文
这是一篇探讨在 Agent 时代如何保持独立思考与专业把控力的技术随笔，来自 Claude Code 的 Addy Osmani（ @addyosmani） 。

过去，人们谈到“批判性思维”（Critical Thinking），总说要怀着谦逊的好奇心与适度的怀疑来面对新信息——兼听不同观点，形成自己的判断。这话依然没错；但现实是，随着我日常工作的大部分内容都交给了 Agent，生活中越来越没有什么事情在“逼”我进行批判性思考了。

对于那些已经全盘拥抱 Agent 工作流（并行挂着多个会话、期待着模型变得越来越强）的工程师和产品人，我想先澄清一点：我是这些工具的头号粉丝，写这篇文章绝不是为了劝大家少用 Agent。我的目的，是想和大家探讨：**在一个随时能把一切工作甩给 Agent 的世界里，我们该如何保住自己的批判性思维。**

在过去，人类大部分的认知与审美过程，都发生在从“提出问题”到“得出答案”之间的那段空白里；而现在，这段空白已经被压缩成了几秒钟。

你越频繁地使用 Agent 工作流，事情其实就变得越棘手（但棘手的方式可能和多数人想的不一样）：随着模型能力的提升，明显的硬伤和低级错误越来越少。绝大多数输出不仅文笔流畅、逻辑工整，而且大体正确，看起来毫无破绽，根本引不起你去二次核查的欲望。

即便你同时挂着好几个 Agent 在跑，你用来审查结果的眼睛也只有一双。你必须主动把批判性思维刻意嵌入到日常流程中，因为在默认状态下，没有任何外力会替你做这件事。

要主动纠正这一点之所以很难，还有一个重要原因：**Agent 工作流带来的体验太舒适了**。在忙碌的一天里，能迅速得到令人愉悦、大体正确的答案，确实让人感到身心舒畅——但这恰恰也是人们容易放松警惕的温床。

---

## 卸载、顺从与投降

和人聊起这个话题时，我通常会把它描述为一个由浅入深的光谱：

- **最顶层：认知卸载（Cognitive Offloading）**。把任务委托给 AI，但始终对最终结果保有所有权与责任。我每天都在这么做，你也应该这么做。
- **居中层：认知顺从（Deferral）**。工具给出的输出直接变成了你的新输入；这个结果在你眼里已经不再是一个需要检验的“假设”，而被当成了事实。
- **最底层：认知投降（Cognitive Surrender）**。AI 的产出悄无声息地变成了你自己的东西，你甚至觉得连检查的必要都没有了。

“认知投降”是沃顿商学院学者 Steven Shaw 与 Gideon Nave 提出的概念。它极精准地描述了我最近观察到的现象：随着信任（或惰性）的增加，人们在这个光谱上不断往下滑落。

这种滑落几乎难以察觉，因为每一步都是渐进且看似合理的：上一条回答你读得很认真，下一条你就开始走马观花；再下一条，你只粗略扫了一眼骨架；直到有人问起其中某一行代码或某一句话，你发现自己哪怕当场找 Agent 帮忙也解释不清楚了——这就是认知投降。

这也是“认知负债”（Cognitive Debt）堆积的过程。它通常在你试图调用对系统的某种心智模型、却发现脑子里空空如也时暴露出来。学者 Margaret-Anne Storey 曾指出，这在团队中表现为对“共享系统认知”的逐步侵蚀。我也曾写过代码层面的对应物——“理解负债”（Comprehension Debt，由 Jeremy Twei 提出）。在当下，它是完全隐形的：代码库看起来整洁完美，测试全部绿灯通过；直到你必须对系统进行修改，才愕然发现没有任何人真正理解它了。这跟你只翻了翻一份战略文档或技术规格书的目录就草草签字批准，是同一个道理。

需要说明的是，我并不是在要求大家去做不可能的事。在今天庞大的现代化代码库里，想在脑海中随时保持完整的心智模型是不现实的。Claude Code 团队曾公开表示，他们是“按需重建理解”的：当需要理解某一部分代码时，就让 Claude 来解释这个切片，而不是试图把整套心智模型时刻装在脑子里。这种负债的挽回成本比多数工程师预期的要低得多——只要你在需要时能在局部重建它，你就不需要时时刻刻维护全局模型。但关键在于：**你得清楚自己脑子里到底缺少了什么**。

在容错率高、赌注很小的地方，尽管完全委托给它。

当你哪怕借助 Agent 也无法回答某个问题时，你实际上已经交出了责任与所有权。这并不总是个坏事。前不久我在录一门课程，需要在三家评分接近的酒店里选一家作为录制场地。我没时间逐条翻看所有评价，于是干脆把这个决策权全权交给了 AI。结果很不错，下次遇到类似情况我依然会这么做。

但我绝不会把决定家庭投资、指导孩子职业选择的事情交给 AI；在工作中，我也绝不会把“我们该做哪些功能”、“这次变更会影响哪些用户”、“当前版本是否安全可发布”这类决策推给 AI。

**做错成本极低的地方，随手交接；而需要别人来承担后果的地方，务必把推理解释权牢牢抓在自己手里。**

---

## 我常问自己的几个问题

过去，当我不确定自己的真实想法时，通常会退回到几个最基本的问题清单：

- 我怎么知道自己正在做的问题是正确的？
- 我怎么知道自己解题的路径是对的？
- 有什么证据能支持我的结论？
- 我怎么判断自己已经完工了？

大多数时候，这无非就是经典的 5W1H（谁、做什么、在哪儿、为什么、何时、怎么做）。落到纸面上看，它们简单得近乎幼稚，但它能逼着你从平时容易忽略的维度去重新审视。

而在今天，跳过这所有反思、直接开口问 Agent “你觉得我该怎么做”实在太容易了。

因此，面对 Agent 时代，我给自己迭代了一套新的提问清单：

1. **在开口提问前，我是否先建立了自己的假设？**
在让 Agent 执行任何重要任务之前，我都会先写下（哪怕只是在脑子里过一遍）我自己猜测的答案。哪怕猜得很离谱也没关系，随着新信息的涌入，你随时可以推翻自己。可一旦你先读到了一份条理清晰的现成回答，你的思维就会被锚定，很难再去想象其他的可能性。如果你实在毫无头绪，不妨采用 Thariq Shihipar 所说的“盲区扫描”（Blind Spot Pass）：把你已知的信息喂给模型，让它专门帮你找出那些“未知的未知”（Unknown Unknowns）。
2. **我是让它帮我思考，还是让它替我思考？**
两种都可以，前提是你心里要清楚自己当下处于哪种状态。
3. **如果这个结论是错的，需要满足什么前提条件？**
然后去验证它。模型自我评估给出的“信心度”远没有你自己亲手跑一次实测有价值，所以，去给它设计一个检验。
4. **我是否从其他角度听过反方观点？**
当我对某个开放性问题有了较强的倾向时，我会让多个不同的模型站在对立面发起反驳，然后审视各方论点，再形成自己的最终判断。这会多花一些时间，但最终我对这个议题的认知会深刻得多。
5. **面对后续需要维护它的人，我敢拿这个产出打赌吗？**
这不仅适用于代码，也适用于你交付的任何成果。我认为这才是检验你是否真正具备交代责任能力（Answerability）的底线。
6. **我正在停止练习什么能力？**
或许是某些常规的代码调试。放弃其中一部分机械操作我完全接受，但我希望这种放弃是**清醒自觉的选择**，而非不知不觉的退化。

---

## 把验证内化成一种习惯

我最近写了很多关于“验证”（Verification）的内容，因为我相信，**当下的瓶颈已经从“写代码”转变为“确认你是对的”**。

当你赋予 Agent 自我验证的能力——无论是端到端测试、基于属性的测试，还是实际的应用交互——它就能在你自己哪怕看上一眼之前，自行修改代码、运行验证测试、读取报错信息、再次尝试修复。这正是 Boris Cherny 所强调的“给 Claude 一个验证自己工作成果的方式”，我认为这也是产出卓越成果最核心的支柱之一。你不再需要逐行肉眼扫读代码，你的精力应当转移到构建这些验证闭环，并审查最终证据上。

但要注意，你同样可能在“验证”这件事上走向投降。“有什么证据能证明我的结论？”会悄悄退化成“检查跑没跑出绿灯？”

Agent 让生成测试变得极其廉价，以至于你会看到满屏的绿色勾勾。可测试全绿完全可能掩盖了一个已经损坏的功能：如果测试本身写得和被测功能犯了同样的错误，它依然会显示通过。而且，一个绿色的勾仅仅代表被验证的那单一属性成立，人们极容易想当然地以为它覆盖了方方面面。

因此，**面对每一个绿色的勾，明确指出它到底检验了什么属性，再指明哪一个属性它根本没检到**。在动手前先界定好什么是“已验证”（Verified），因为事后再看，人总会把任何既成事实合理化。

Agent 工作的“终点线”必须是某种确凿的实物：通过的测试、一张界面截图、一段日志或调用链追踪（trace）。这能确保完工标准是建立在客观事实之上，而不是基于一句“看起来搞定了”的主观解释与妥协。

当收到 Agent 的完工通知时，在看它的文字总结之前，先去看一眼它执行的具体命令片段及其真实输出。Claude Code 也能（通过纯净上下文中的子代理）对自己生成的内容做自我批判与常识检查（Sanity Check），这值得被固化进日常工作流中，让它每次都自动运行，而不是仅靠你一时兴起才想起来。

在最后，我依然习惯问一句：“我漏掉了什么吗？”这听起来有些傻气，但无数次在用前沿模型完成一项复杂功能后，我检查完、确认过，顺嘴多问一句“我漏掉了什么没有？”，它往往又会精准挑出两到三个隐藏问题。这就是为什么我总会保留这道追问。

当然，并不是所有事情都要深挖到底；清楚何时该深入钻研本身就是一项技能。在我们总结的 Claude Code 团队代码审查经验中，我最喜欢的一条法则是：“**如果你说不出自动化检查会遗漏什么，那就老老实实做人工审查，别急着点快速通过。**”

这不仅适用于代码。如果 Agent 帮你综合提炼了 50 通客户访谈电话，或者做了一份竞品分析，抽查几份原始文档，核对摘要是否真实无误；检查一个直接支撑你建议的关键数字，确认它的计算逻辑对不对。Agent 让搭建验证体系的成本变得极低，而真正考验你的，是能否识别出“什么才算一次优秀的验证”。

---

## 真正关注生成的内容

假设 Agent 递给你一个 600 行的 PR。你大致扫了眼代码结构，没有逐行细看。变量命名看着挺顺眼，自动化测试也都跑通了，于是你点了 Approve。但在这堆代码的深处，事务边界里悄悄发生了一个微妙的顺序变动，或者某个你从未想过的边界情况下的默认值被悄悄反转了。从某种意义上说你确实审查过了，但你其实只看到了你预期能看到的东西。

写代码和审查代码是两种完全不同的技能，而审查往往会在某一刻沦为流于形式的“盖章”（Rubber Stamping）。

因此，**像审视由真人写出来的代码一样去阅读 diff，并且跳出 diff 本身，去看看 Agent 背着你做出了哪些决策**。在一个漫长的会话中，它替你做了无数微小的决定：选定的默认值、哪些需求被它划入了范围外、当两个需求冲突时它擅自重新解释了哪一条。这一切在“一切进展顺利”的简报里是看不见的，所以主动让它列出它所做的全部决策与底层假设。

然后考考你自己：随机挑出几行问自己，这行代码是干嘛的？那行又是干嘛的？如果是针对一份长文档，关掉页面，试着凭记忆写出核心论点。对于长会话，有些人建立了一个我很喜欢的习惯：让 Claude 写一份变更报告，并在文末给你出几道测试题，规则是“只有当我把这些题目答全对时，我才点击 Merge”。

**对你要发布的东西理解到足以坦然捍卫它的程度，因为早晚有一天会有人拿着它来质问你。**

Agent 也能帮你保护精力。比如，我维护的一个开源项目会收到很多 PR。我会让 Agent 帮我梳理来信内容、指出哪些地方违反了项目准则、标记哪些部分可能需要我投入注意力。我极少让 Agent 自主定夺，但它们能把筛选范围收窄到需要我关注的核心区域，之后我便能沉下心来思考：这些变更是否真的在用正确的方式解决正确的问题。

此外还有“产出体量”的问题，你必须对此保持诚实。我把这称为**编排税（Orchestration Tax）**：即 Agent 生成的体量，与你真正有底气署名的产出之间存在的鸿沟。如果积压的“已完成”工作比你审查消化的速度还要快，盲目开启新会话没有任何帮助——除非你先解决这个问题：要么收紧自动化校验以减少对人工的依赖，要么慢下来。

当你产出的东西已经超出你愿意为其背书的范围时，你不再是在审查，你只是在祈祷。

---

## 高质量的输入，才有高质量的产出

人类的心智模型并没有离场，只是它不再卡在流程正中间，而是被挪到了最前端与最后端：你把主要精力倾注在任务描述与上下文铺设的前端，以及成果把关与审查的后端。这就是为什么高质量的输入对产出质量如此关键，而我也始终把“撰写优质提示词（Prompting）”视作一项至关重要的批判性思维技能。

在过去，如果你提出了一个含糊不清的需求，协作者会当场提出质疑，你也会意识到：“等等，其实我自己都还没想明白。”但 Agent 往往不会在这时拦住你，它会自作主张填补你留下的空白，然后递给你一个看似已经完工的成果，尽管背后的构想依然是一团浆糊。我把这称为**意图负债（Intent Debt）**——那些深埋在非你所写的产物中，模糊不清的目标、隐性约束与决策逻辑。与其他负债不同，意图负债没有任何人能替你偿还，意图只能源于你自身。你的 Prompt 正是你对问题认知深度的镜像；如果你无法清晰表述它，说明你脑子里八成也没搞清楚。

在寻求帮助之前，先用自己的话写一份需求概要（Brief）：描述受众、划定非目标（Out-of-scope）、明确完工标准（Definition of Done）。当改了第二轮依然无法令人满意时，停下微调的手，重新去改写你的 Prompt。

在这个过程中，你同样可以让 Agent 来协助你。认知学家 Andy Clark 对“将任务委托给 AI 系统”与“与 AI 系统深度协作”做过精妙区分：在后一种状态下，你们处于一种相互放大的良性循环中——你的 Prompt 磨砺了它的产出，进而打磨了你下一个 Prompt，并持续淬炼你对问题本身的心智模型。如果不明确，就让 Agent 像采访者一样来就它不理解的地方向你提问。如果你在结束一次会话时，自己对系统的心智模型反而变得更加清晰锐利了，那就是协作成功的标志。

此外，还要对输入保持警惕。多个 Agent 协作时，很容易出现后一个 Agent 仅仅把前一个 Agent 的摘要塞进上下文的情况，用不了多久，第三个 Agent 就完全没读过原始文档了。

与此同时，你必须建立自己的产出审美标准。我在很多创意媒介上都尝试过 AI，但大部分成果从未公开发表，因为它们达不到我的标准。现在的 AI 生成物几乎都排版精致、语气笃定，因此表面的光鲜早已不再是质量的有效信号。AI 固然大幅加快了产出速度，但只要是我无法坦然署名为自身作品的东西，我就绝不发布。当某些产出无法达到你的标准时，把原因记录在共享配置、钩子（Hook）或测试用例中，防止未来重蹈覆辙——品味正是这样复利积累起来的，而梳理清楚“某个方案为何不及格”，本身就是极佳的认知刻意练习。

---

## “但未来的模型迟早会比我更擅长做这些”

如果你像我身边的很多人一样对这个领域的未来极度乐观，读到这里很可能会冒出这个想法：“再过一两年，模型就能捕捉到我能发现的所有问题了，我又何必费劲保留这项能力？”

在很多层面的问题检测上，你的预测或许是对的，而且我本人也在极力主张把越来越多的检测工作交给 Agent。但我认为它依然至关重要的原因在于：**归根结底，必须有人对最终交付的东西负责**。无论 AI 提供了多大的助力，最终承担责任的必须是人。

在任何特定任务上，决定对 Agent 赋予多少信任度，本身就是一个高阶判断。为了保持敏锐的校准，你必须持续审查它们的工作，因为模型犯错的盲区是在不断演化的。Anthropic 针对自身工程师与研究员的一项研究曾指出这种困境，称之为**监督悖论（Paradox of Supervision）**：“监督 Claude 所必需的代码能力，恰恰会因为过度依赖 AI 而逐渐萎缩。”

以下是我最看重、且哪怕模型再强大也无法代劳的事情：

- 你在构建什么？
- 为什么它值得做？
- 它会影响到谁？
- 为了达成它你愿意牺牲什么？

这些全都是唯有你能回答的命题。Agent 可以在梳理逻辑的过程中提供辅助，我也乐见于此，但最终的拍板权始终属于你。

**你可以卸载具体的工作，甚至卸载大部分的审计，但你无法卸载责任。**

---

## 融入日常的几项实践

你不需要教条地全盘照搬，挑选最适合你工作流的方式即可：

1. **每周一次，脱离 Agent 手写一点代码**，或者去亲手做一件“要是以后忘了怎么做会很惨”的实事。（我称之为“校准练习”，这无关道德高尚，纯粹是为了保持手感。）
2. **每月一次，盘点自己已经不再亲力亲为的事项**，并决定其中哪些是你能够心安理得放弃的。我旧博文里的一句话至今依然切中要害：*“如果明天 AI 突然不复存在，你会有多不知所措？”*
3. **遇到超出理解范畴的东西，老老实实去学**。比如写作时遇到一个陌生短语，我可以随手搜一行释义塞进去，但我更倾向于稍微花点时间探究它的确切含义与语境，看看它究竟该用在哪儿。
4. **认真审查机器的产出是一项实打实的本职工作**。自欺欺人假装它不占时间，是团队最终放弃审查的主因。既然它不是零成本的，就把它正式列入排期日程，你才能真正执行到位。
5. **停止锻炼的技能一定会退化，而且速度大概率比你想象的还要快**。对那些你绝不愿丢掉的核心手艺，务必亲手练下去。

---

## 带走这几点备忘

- **保持清醒与自觉**：Agent 确实能考你、访谈你、向你出示证据，但前提是你必须主动搭建好这些机制。现在就去把它搭起来。
- **诚实面对自己身处光谱的哪个位置**：如果你借助 Agent 依然无法讲清楚某个答案，你其实已经放弃了它。
- **永远带着假设出发**：在提问前先形成自己的预判，哪怕这个预判是错的。
- **绿色的勾只代表一件事**：它到底检验了什么？又漏检了什么？
- **追查一手证据**：在看 Agent 的文字总结之前，先看它到底执行了什么命令、拿到了什么原生输出。
- **看清它替你做了什么决断**：它替你擅自决定了哪些默认值和取舍？
- **打磨你的 Prompt**：你的提问方式，直接映射着你对问题的理解深度。
- **守住底线与标准**：如果一件东西你不敢签上自己的名字，就绝不交付。
- **留在牌桌中央**：持续亲手实践那些真正关键的硬核技能。

你可以立刻尝试的一件小事：

>
> **在向 Agent 提问前，写下你预判会发生什么；在它完工后，写下一件它根本没有去验证的事。**

试试看这是否会改变你审视输出结果的视角。

**独立思考。提出更好的问题。对最终结果负起责任。**

Source evidence: [https://goagi.top/agent-2](https://goagi.top/agent-2)

## Related topic hubs
- https://goagi.top/geo-middleware/topics/indie-hacker.geo.md
- https://goagi.top/geo-middleware/topics/agi-workflow.geo.md