当 Agent 替我们完成工作：不要在获得能力的同时，失去思考能力

原创

jishuzhain
jishuzhain

OnionSec

2026年11月8日 23:45
广东

去阅读

— ◆ —

最近读到 Addy Osmani 的一篇文章，标题是《Critical thinking when agents do the work》。

作者是 Anthropic Claude Code 团队的工程师。这篇文章没有讨论如何让 AI 写出更多代码，也没有讨论如何通过多 Agent 并行进一步提高生产效率，而是提出了一个值得所有 AI 使用者认真思考的问题：

当 Agent 越来越擅长替我们完成工作，我们是否正在逐渐丧失独立思考的能力？

我很喜欢这篇文章的切入角度。

因为它没有站在传统工程师的立场上，担心 AI 抢走自己的工作，也没有试图证明人类永远比 AI 更聪明。恰恰相反，作者非常支持 Agent 工作流。他希望工程师和产品人员尽可能利用这些工具，只是提醒我们：不要因为工作可以被委托，就连自己的判断也一并委托出去。

这让我想起最近一段时间自己的实践。

• • •

01

一、最危险的不是 AI 犯错，而是它越来越少犯明显的错误

过去使用 AI，我们很容易保持警惕。

因为模型经常一本正经地胡说八道，代码可能无法运行，技术解释可能存在明显漏洞，给出的解决方案也可能根本不符合实际需求。

这些错误反而迫使我们检查、质疑和验证。

但现在情况正在发生变化。

随着模型能力提升，AI 输出的内容越来越流畅，代码越来越完整，分析越来越有条理。很多时候，它给出的答案不仅看起来合理，而且确实能够解决问题。

问题也恰恰出现在这里。

当一个工具经常正确，人就容易逐渐放松警惕。第一次，我们认真检查它的输出；第二次，我们大致浏览一下；第三次，可能只看一眼最终结果。

再往后，我们甚至不再关心它是怎么得出结论的。

作者指出，Agent 工作流有一种特殊的舒适感：快速、愉悦，而且通常能够给出正确答案。正是这种体验，让人更容易放弃原本应该进行的思考。

我觉得这个观察非常准确。

过去，完成一项复杂工作，需要经历需求分析、方案设计、技术实现、调试和验证。大量思考自然发生在这些环节之间。

现在，Agent 可以在很短的时间内完成其中相当一部分工作。

人的认知活动并没有消失，只是原本必须发生的思考过程，开始变成了一种需要主动安排的事情。

当思考不再是完成工作的必要步骤，人就必须主动决定自己是否还要思考。

• • •

02

二、从认知卸载，到认知让渡，再到认知投降

文章中有一个我认为非常重要的概念框架。

作者把人与 AI 的协作关系描述成一条连续的光谱。

第一层：Cognitive Offloading，认知卸载。

把任务交给 AI 执行，但自己仍然拥有结果。

例如，让 Agent 帮忙编写程序、整理资料、分析数据，甚至完成一项过去需要数天才能完成的工程任务。

这没有任何问题。

人类本来就在不断创造工具，把重复性工作交给机器完成。计算器没有让数学家消失，编译器也没有让程序员失去存在价值。

关键在于，你仍然知道自己要解决什么问题，为什么选择这个方案，以及最终如何判断它是否正确。

第二层：Deferral，认知让渡。

这时，AI 的输出开始成为自己下一步思考的基础。

你不再先形成自己的判断，而是先阅读 AI 的结论，再围绕它继续工作。

这种方式并不一定错误。很多时候，我们确实需要借助外部信息修正自己的认知。

但这里存在一个隐患：AI 最初给出的假设、约束和解释，可能在后续工作中逐渐变成未经检验的事实。

你开始在一个可能存在错误的前提上，不断构建新的结论。

第三层：Cognitive Surrender，认知投降。

这是作者最担心的状态。

AI 的输出已经悄悄变成了自己的观点，自己甚至不再觉得有必要检查。

文章提到一个很有意思的现象：当别人询问你某一行代码为什么这样写，或者某项决策为什么这样制定时，你竟然无法解释，甚至需要再次求助于那个替你完成工作的 Agent。

这时候，问题已经不只是 AI 是否正确。

而是你已经失去了对自己交付成果的理解和所有权。

作者将这种现象与 Cognitive Debt（认知债务）联系起来。

它和软件工程中的技术债务有相似之处：短期内，工作看起来已经完成，代码可以运行，文档也很漂亮，但系统内部的理解能力正在逐渐退化。

直到某一天需要修改、维护或者解释这个系统，才发现没有人真正理解它。

我觉得这里还有一个值得注意的区别：

认知卸载并不意味着必须掌握所有细节。

现代软件系统如此复杂，任何工程师都不可能在脑子里保存整个代码库的完整模型。作者也承认这一点。

真正重要的是，知道自己目前不理解什么，以及需要时能否重新建立对局部系统的理解。

不需要永远知道所有事情，但不能失去重新弄明白事情的能力。

• • •

03

三、AI 越强，验证能力反而越重要

文章有相当大的篇幅讨论 Verification（验证）。

作者认为，随着 Agent 能够承担越来越多的编码工作，工程效率的瓶颈正在从代码编写转向确认结果是否正确。

这句话值得认真理解。

假设一个 Agent 在几分钟内生成了 600 行代码，完成了功能实现，还运行了测试，最终告诉你所有检查均已通过。

你是否就可以放心合并？

显然不行。

因为测试通过，只能说明它通过了已经设计的测试，并不意味着功能一定正确。

如果测试本身就包含了与实现相同的错误，那么代码和测试完全可能一起犯错。

因此，作者提出了几个非常实用的习惯：

1.在开始工作之前，先定义什么才算完成，以及如何验证。

2.不要只看 Agent 的总结，要查看它实际执行了什么命令、获得了什么结果。

3.测试通过之后，继续追问它证明了什么，又没有证明什么。

4.要求 Agent 列出它在实现过程中自行作出的决策和假设。

5.对重要交付物进行独立审查，必要时让另一个 Agent 从全新的上下文进行反向检查。

其中有一句话让我印象很深：

当检查结果变成绿色时，应该问自己：它究竟证明了什么？又没有证明什么？

我认为这甚至可以作为 AI 时代的一条基本工程原则。

验证不应该只是一个最终步骤，而应该成为 Agent 工作流的一部分。

例如，Agent 完成程序后，可以自行运行测试、检查日志、分析异常，再根据结果修正实现。人不必盯着每一行代码，但必须能够审查这些验证证据，并判断验证范围是否足够。

不过，这里还有一个容易被忽略的问题：

验证本身也可能被自动化，但验证标准不能因此失去独立性。

如果需求理解错了，实现错了，测试标准也跟着错了，那么整个自动化闭环可能只是更高效率地证明自己是正确的。

所以，验证不仅需要执行，还需要有人审视验证机制本身。

• • •

04

四、我们可能正在支付一种新的成本：Orchestration Tax

作者还提出了一个很有意思的概念：Orchestration Tax，编排税。

它描述的是 Agent 生成的工作成果，与人真正愿意以自己的名义交付的成果之间的差距。

假设你同时运行五个 Agent，每个 Agent 都能独立完成任务。

表面上，你的生产效率提高了五倍。

但问题是，你仍然只有一双眼睛。

五个 Agent 同时生成代码、分析报告和技术方案，你能否及时审查？能否理解它们作出的决策？能否确认它们之间没有相互矛盾？

如果产出速度远远超过了审查能力，那么增加 Agent 数量并不会继续提高有效生产力。

你只是在制造更多等待审核的工作。

作者有一句话表达得非常直接：

当你产出的东西已经超过自己能够承担和解释的范围，你就不再是在审查，而是在碰运气。

我觉得这对当前热衷于多 Agent 协作的人尤其有价值。

过去，我们经常讨论如何提高 AI 的执行效率。

现在可能还需要增加一个指标：

有效交付能力 = 生成能力 × 验证能力 × 理解能力。

这不是严格的数学定律，而是一种工程上的提醒。任何一项能力严重不足，都可能使最终交付质量受到限制。

模型能够生成多少内容，并不等于一个人能够可靠地交付多少内容。

• • •

05

五、Prompt 不只是指令，也是自己理解问题的体现

文章还有一部分讨论 Intent Debt（意图债务）。

我觉得这一部分特别容易被忽略。

过去，当我们向其他工程师提出需求时，如果需求不明确，对方可能会主动询问：

—为什么要做这个功能？

—真正需要解决的问题是什么？

—有哪些约束？

—什么情况才算完成？

这些问题会迫使需求提出者重新思考自己的目标。

但是，Agent 往往不会停下来。

你给它一个模糊的要求，它会自动补全缺失的信息，选择默认方案，甚至替你决定一些原本没有明确表达的需求。

最后交付出来的东西可能非常完整。

但它解决的，未必是你真正想解决的问题。

这就是意图债务。

作者建议，在向 Agent 提出复杂任务之前，先用自己的语言写清楚需求，包括目标用户、范围边界、排除事项以及完成标准。

如果经过两轮修改仍然无法达到预期，不要一直修补原来的 Prompt，而应该停下来重新描述问题。

我很认同这个观点。

因为 Prompt 并不是某种神秘的咒语。

它实际上是人对问题的理解，通过自然语言传递给模型。

如果自己都不能说清楚问题是什么，就很难期待 Agent 准确地解决它。

当然，这也不是要求人必须在开始之前就拥有完整答案。

恰恰相反，可以让 Agent 反过来采访自己，提出它无法确定的问题，帮助自己补全需求。

如果一轮协作结束后，自己对问题的理解比开始时更加清晰，那么这次 AI 协作本身就产生了价值。

作者引用了 Andy Clark 关于委托与协作的区别：真正的协作应该形成一个相互增强的循环。

人的问题帮助 AI 改善输出，AI 的输出又帮助人完善下一轮问题，双方不断提升对任务的理解。

这与单纯把任务丢给 AI，等待一个答案，是完全不同的工作方式。

• • •

06

六、模型未来可能比我们更擅长发现错误，那还需要自己练习吗？

我认为这是全文最值得讨论的问题。

如果未来模型足够强大，能够发现人类工程师都发现不了的错误，甚至能够独立完成代码审查、系统验证和安全分析，那么我们为什么还要刻意保持自己的技术能力？

作者给出了一个很现实的理由：最终总有人需要对交付结果负责。

他提到 Anthropic 内部研究所讨论的一个现象：Paradox of Supervision（监督悖论）。

监督 Claude 需要一定的编程能力，而这些能力又可能因为过度使用 AI 而逐渐退化。

这就形成了一个循环：

人越来越依赖 AI 完成工作，于是减少了相关技能的练习；随着技能退化，人又越来越难以判断 AI 是否正确，最终只能更加依赖 AI。

这并不是说人必须坚持手写所有代码。

作者也没有提出这样的要求。

他建议的是有意识地保留那些自己不愿意失去的能力。

例如，每周安排一些不使用 Agent 的编程练习，每个月回顾自己已经不再亲自完成哪些工作，判断哪些技能可以放心交给机器，哪些仍然需要保持。

其中还有一个很好的自我检查问题：

如果 AI 不存在，你会有多么无所适从？

我觉得这不是在要求人回到过去，而是在提醒自己不要把所有能力都建立在工具始终可用的假设之上。

• • •

07

七、回到自己的实践：我究竟是在使用 AI，还是在获得新的能力？

最近一段时间，我开始尝试把本地模型真正用于解决生活和工作中的问题。

例如，使用 RTX 2060 运行本地模型，完成英文 EPUB 的双语翻译，尽可能保留原始章节结构、排版和内容。

整个过程并不是简单地问模型几个问题，而是让模型参与一项完整工程任务的实现。

我需要考虑 EPUB 的文件结构、文本提取、翻译分段、上下文长度、异常处理、结果回填以及最终文件验证。

模型承担了大量过去需要自己编写代码、查阅资料和反复调试的工作。

后来，我又开始思考 PDF 文档应该如何处理，以及如何让 Agent 帮助自己完成更加复杂的工程任务。

还有更早之前的 FPGA 项目。

2016 年参加全国大学生电子设计竞赛时，我做过脉冲信号参数测量仪。由于时间过去太久，很多工程细节已经遗忘。

但最近借助 AI，我重新开始梳理当时的设计方案、技术逻辑和可能存在的问题。

这让我意识到，AI 不只是帮助我完成一项任务，它还能够帮助我重新进入过去没有能力深入理解的工程领域。

这两种体验让我产生了一个疑问：

如果一个人过去没有能力独立完成某项工作，但现在能够借助 AI 完成，并且能够理解关键原理、验证结果、发现问题，那么这究竟算不算获得了一项新的能力？

我倾向于认为，当然算。

人类获得能力的方式，本来就不应该只有亲自从零开始掌握所有技术细节这一条路径。

我们使用编译器，不需要自己设计 CPU；使用数据库，不需要自己实现存储引擎；使用数学软件，也不需要每次都手工完成复杂计算。

工具的价值就在于扩大人的能力边界。

但这里有一个重要前提：工具帮助我们完成了工作，不代表我们已经理解了工作。

我认为应该区分三个层次：

第一，任务完成。

AI 帮助你把事情做出来，结果能够运行，文件能够打开，功能能够使用。

第二，结果理解。

你知道系统为什么这样设计，关键环节如何工作，哪些地方存在局限，以及结果依赖什么假设。

第三，独立判断。

当结果出现异常，或者外部条件发生变化时，你能够识别问题，重新分析，提出验证方案，必要时修正原有实现。

这三个层次并不要求所有任务都达到同样的深度。

一个低风险、一次性的文件格式转换，没有必要花费大量时间研究底层实现。

但是，如果涉及资金、安全、生产系统或者其他人需要长期维护的工程交付，就不能仅仅满足于任务完成。

投入多少理解和验证成本，应该与错误可能造成的后果相匹配。

• • •

08

八、AI 时代，真正需要保留的可能不是执行能力，而是判断能力

读完这篇文章，我最大的感受是：

过去，我们经常把专业能力理解为知识储备、技术经验和执行能力。

谁掌握更多知识，谁能够解决更多问题，谁就更有竞争力。

但 Agent 正在改变这些能力的获取成本。

很多过去需要专业人员投入大量时间完成的工作，现在可以通过自然语言交互和自动化工作流快速完成。

这不意味着专业知识失去价值，而是专业知识与实际执行之间的关系正在改变。

未来，一个人可能不需要亲自完成所有工作，但仍然需要知道：

—我们为什么要做这件事？

—真正需要解决的问题是什么？

—AI 给出的方案依赖哪些前提？

—什么证据能够证明结果正确？

—还有哪些问题没有被验证？

—如果出现错误，谁来承担后果？

这些问题不会因为模型变得更强大而自动消失。

甚至可能变得更加重要。

当然，我也不认为人类必须永远保留所有技能。技术进步本身就是不断把低价值、重复性的劳动交给工具。

我们没有必要为了证明自己有能力，而拒绝使用更好的工具。

真正需要警惕的，是在没有意识到的情况下，连自己原本拥有的判断能力也一并放弃。

Addy Osmani 在文章最后总结了几个实践原则：提问前先形成假设；让 Agent 展示证据；弄清楚检查究竟覆盖了什么；理解它替你作出的决策；设定自己的交付标准；持续练习那些不愿意失去的技能。

我尤其认同最后一层意思。

你可以把工作交给 AI，把大量执行和审计过程交给 AI，但不能轻易把最终责任也交出去。

我想，这也是我最近不断尝试使用 AI 解决实际问题的原因。

不是为了证明自己能够用 AI 做出多少东西，也不是为了追逐某种生产力焦虑。

而是想看看，一个普通人能否借助这些工具，重新获得过去受限于知识、经验、时间和资源而无法实现的能力。

如果 AI 让我们能够做更多事情，却让我们越来越不知道自己究竟做了什么，那么这种生产力提升可能并没有想象中那么美好。

但如果 AI 让我们能够进入更多领域，理解更多问题，建立更多工程实践，并且仍然保留独立判断和验证的能力，那么它带来的就不只是效率提升。

而是人的能力边界发生了变化。

不要为了证明自己不需要 AI 而拒绝 AI，也不要因为 AI 无所不能的假象，而忘记自己为什么需要思考。

工具可以越来越聪明。

但至少在现阶段，我仍然希望自己是那个知道为什么要做、如何判断做得对不对，以及什么时候应该停下来重新思考的人。

◆

原文：

Addy Osmani — Critical thinking when agents do the work

2026 年 11 月 3 日

https://x.com/i/article/2116367635365695488

本文为个人阅读后的理解与实践思考，并非原文逐字翻译。