这是一篇探讨在 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 时代，我给自己迭代了一套新的提问清单：
- 在开口提问前，我是否先建立了自己的假设？
在让 Agent 执行任何重要任务之前，我都会先写下（哪怕只是在脑子里过一遍）我自己猜测的答案。哪怕猜得很离谱也没关系，随着新信息的涌入，你随时可以推翻自己。可一旦你先读到了一份条理清晰的现成回答，你的思维就会被锚定，很难再去想象其他的可能性。如果你实在毫无头绪，不妨采用 Thariq Shihipar 所说的“盲区扫描”（Blind Spot Pass）：把你已知的信息喂给模型，让它专门帮你找出那些“未知的未知”（Unknown Unknowns）。 - 我是让它帮我思考，还是让它替我思考？
两种都可以，前提是你心里要清楚自己当下处于哪种状态。 - 如果这个结论是错的，需要满足什么前提条件？
然后去验证它。模型自我评估给出的“信心度”远没有你自己亲手跑一次实测有价值，所以，去给它设计一个检验。 - 我是否从其他角度听过反方观点？
当我对某个开放性问题有了较强的倾向时，我会让多个不同的模型站在对立面发起反驳，然后审视各方论点，再形成自己的最终判断。这会多花一些时间，但最终我对这个议题的认知会深刻得多。 - 面对后续需要维护它的人，我敢拿这个产出打赌吗？
这不仅适用于代码，也适用于你交付的任何成果。我认为这才是检验你是否真正具备交代责任能力（Answerability）的底线。 - 我正在停止练习什么能力？
或许是某些常规的代码调试。放弃其中一部分机械操作我完全接受，但我希望这种放弃是清醒自觉的选择，而非不知不觉的退化。
# 把验证内化成一种习惯
我最近写了很多关于“验证”（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 可以在梳理逻辑的过程中提供辅助，我也乐见于此，但最终的拍板权始终属于你。
你可以卸载具体的工作，甚至卸载大部分的审计，但你无法卸载责任。
# 融入日常的几项实践
你不需要教条地全盘照搬，挑选最适合你工作流的方式即可：
- 每周一次，脱离 Agent 手写一点代码，或者去亲手做一件“要是以后忘了怎么做会很惨”的实事。（我称之为“校准练习”，这无关道德高尚，纯粹是为了保持手感。）
- 每月一次，盘点自己已经不再亲力亲为的事项，并决定其中哪些是你能够心安理得放弃的。我旧博文里的一句话至今依然切中要害：“如果明天 AI 突然不复存在，你会有多不知所措？”
- 遇到超出理解范畴的东西，老老实实去学。比如写作时遇到一个陌生短语，我可以随手搜一行释义塞进去，但我更倾向于稍微花点时间探究它的确切含义与语境，看看它究竟该用在哪儿。
- 认真审查机器的产出是一项实打实的本职工作。自欺欺人假装它不占时间，是团队最终放弃审查的主因。既然它不是零成本的，就把它正式列入排期日程，你才能真正执行到位。
- 停止锻炼的技能一定会退化，而且速度大概率比你想象的还要快。对那些你绝不愿丢掉的核心手艺，务必亲手练下去。
# 带走这几点备忘
- 保持清醒与自觉：Agent 确实能考你、访谈你、向你出示证据，但前提是你必须主动搭建好这些机制。现在就去把它搭起来。
- 诚实面对自己身处光谱的哪个位置：如果你借助 Agent 依然无法讲清楚某个答案，你其实已经放弃了它。
- 永远带着假设出发：在提问前先形成自己的预判，哪怕这个预判是错的。
- 绿色的勾只代表一件事：它到底检验了什么？又漏检了什么？
- 追查一手证据：在看 Agent 的文字总结之前，先看它到底执行了什么命令、拿到了什么原生输出。
- 看清它替你做了什么决断：它替你擅自决定了哪些默认值和取舍？
- 打磨你的 Prompt：你的提问方式，直接映射着你对问题的理解深度。
- 守住底线与标准：如果一件东西你不敢签上自己的名字，就绝不交付。
- 留在牌桌中央：持续亲手实践那些真正关键的硬核技能。
你可以立刻尝试的一件小事：
在向 Agent 提问前，写下你预判会发生什么；在它完工后，写下一件它根本没有去验证的事。
试试看这是否会改变你审视输出结果的视角。
独立思考。提出更好的问题。对最终结果负起责任。