Addy Osmani 发文探讨在大量使用 Agent 工作流后如何保持批判性思维。
他的身份背景值得注意。前 Google Chrome 工程主管，负责过开发者体验和云 AI 产品；现任 Anthropic Claude Code 核心团队，每天写几百行代码，让 Agent 跑测试、生成文档、修 bug。他不是旁观者，是深度使用者。
正是这个身份，让他观察到一个反直觉现象。AI 输出越来越准，人类却越来越不敢质疑。
1. 「认知投降」是什么，为什么 AI 越准越危险
Agent 时代的隐性代价
Osmani 把这种现象称为「认知投降」。他区分了两个阶段：第一阶段是「认知卸载」，你把信息收集、整理、初稿生成这些重复劳动外包给 Agent；第二阶段是「认知投降」，你连判断都不做了。
问题在于，这两个阶段之间没有明确的警示灯。
早期 Agent 会犯错。生成的代码跑不通，文档有事实错误，你需要花时间和它迭代。这个过程本身就是一种认知训练——你得知道为什么错了，才能改对。
现在 Agent 能跑通测试、生成完整 PR、写出一篇结构正确的文档。显性错误急剧减少，你不再需要每次都验证。
更准确地说，你甚至懒得去验证了。
这带来的代价是隐性的。你外包了执行，却没有保留判断。久而久之，你对系统的理解能力会下降。一个资深工程师可能写不出清晰的架构图，因为他习惯了让 Agent 生成，自己只做最终确认。
这不是能力衰退，是习惯退化。你的大脑适应了低摩擦的输入方式，批判性思考的肌肉群开始萎缩。
从「不会用」到「不敢不用」
技术采纳的曲线通常分为几个阶段：不会用、愿意学、熟练用、离不开。
Agent 工作流的普及正在把整个行业推向第四个阶段，但很多人还没意识到这一步的风险。
「不会用」的时候，你会小心翼翼。你问一个问题，会自己验证答案，会对比多个来源。
「离不开」的时候，你用 Agent 生成代码，直接合并；你让它写测试，直接跑；你让它总结文档，直接发。
你节省的是时间。你失去的是判断力。
从经验看，这个问题最隐蔽的场景是代码评审。Agent 生成一个看起来结构完整的 PR，你点进去看了一眼，变量命名规范、注释齐全、测试通过。你点了 approve。
但你有没有想过，这个 PR 解决的是原始问题，还是 Agent 理解的问题？
Agent 可以推断意图，但无法恢复从未记录的意图。这就是 Osmani 提出的「意图债务」概念——你把为什么做这件事的逻辑留在了 Prompt 里，而没有留在代码仓库里。
"The finish line for agent work should be something tangible: a test passing, a screenshot, a log or trace." — Addy Osmani
这不是抽象的建议，而是从实际工程中总结出来的判断。他见过太多团队把 Agent 当成终点，而不是过程。
Agent 跑完任务，人类还在检查边界条件
认知卸载到认知投降的演化路径
这条路径看起来平滑，但转折点难以察觉。你今天节省的 10 分钟验证时间，明天可能需要花 10 小时理解为什么这个系统出了错。
Osmani 的判断是：Agent 的 finish line 不应该是一句「看起来完成了」，而应该是一个可验证的断言。一条测试通过、一个截图证据、一段日志记录。
这句话值得反复读。因为它点出了问题的本质——你不是在对抗 AI，你是在对抗自己的惰性。
AI 越准，你越需要更强的判断力，而不是更少的。这是悖论，也是真相。
2. Addy Osmani给出的3个反制工具
2.1 设置可验证的finish line
Osmani的核心判断很直白：Agent的finish line不应该是一句「看起来完成了」，而应该是一个可验证的断言。
他在X帖子中明确写了：
The finish line for agent work should be something tangible: a test passing, a screenshot, a log or trace. This ensures that the criteria for finishing the work is factual, and not up for interpretation (and surrender) based on something like "it looks like it's done."
这意味着什么？意味着你需要在设计阶段就把验收标准写清楚。不是「帮我做个登录功能」，而是「跑完npm test后通过率100%，且截图显示登录页渲染正确」。
更狠的是，他要求在收到Agent完成通知时，先看命令执行的代码片段和输出，再看Agent生成的总结。
这个顺序有讲究。总结可以写得漂亮，但命令行的输出不会撒谎。
实际工作中，很多人把「Agent说做完了」当作终点。Osmani的逻辑是反过来的：先验证边界条件，再信任结论。
2.2 审计痕迹比结果更重要
有一个具体场景能说明问题。Osmani在substack上写过：
Your AI agent has database access. Can you tell what it did? Give an agent a Postgres login and it looks like any other role - a shared, long-lived credential with no real way to know which agent ran which query.
你给Agent一个数据库账号，它看起来和人类开发者没区别。问题来了：谁能证明这条查询是这个Agent跑的，还是另一个人？
答案是不能，除非你有审计轨迹。
现代解法是身份系统：权限绑定到任务，任务结束权限过期，每次查询都绑定到具体的Agent和背后的人类。Osmani提到Teleport就是按这个模型设计的。
这对你的日常意味着什么？
- 不要在共享账号上跑Agent任务
- 每个Agent会话应该有独立的凭证和作用域
- 输出日志必须关联到任务ID，而不是只写到全局日志
没有审计轨迹的工作流，本质上是把责任让渡给了不可追溯的黑箱。Agent跑崩了线上库，你连是谁、在什么状态下跑的都不知道。
2.3 保持「手动验证」的习惯
最后一个反制工具是最朴素的：你自己要动手验证关键路径。
Osmani在Mastery Still Comes From Doing the Reps这篇里提到一个观点：
Put the lesson where the next agent can find it.
意思是把经验沉淀下来，而不是把所有事外包给Agent。具体来说，他建议的是「Engineer the Loop, Not Just the Prompt」——可靠的工作流来自对循环的设计，而不仅仅是对模型的提示词工程。
这和前面的finish line是同一个逻辑的延伸。你要保留一段自己介入的路径，而不是一直站在输出端等结果。
一个可操作的落点：在你设计的Agent流程里，强制插入一个人工确认节点。不是每步都确认，而是在关键决策点——比如数据迁移前、生产配置变更时——停下来，自己过一遍。
更准确地说，这个确认节点应该对应之前定义的finish line，而不是随性插入。否则它就是一个形式主义的空档，起不到任何拦截作用。
这三个工具的共同点是：不否认Agent的价值，但也不把判断权完全让出去。它们是在效率和安全之间找一个你能守住底线的位置。
当Agent能自动跑通测试、生成文档，一个微妙的问题浮现：执行成本趋近于零时，判断力的价值反而上升。这不是技术衰退，是认知退化。判断力从来不是agent的专长，它属于那些还愿意亲自踩坑的人。
3. 当Agent接管工作，你的核心价值在哪
判断力是最后未被自动化的能力
Agent能把代码写出来，但它不知道这段代码为什么必要。它能让测试通过，但它看不出测试本身有没有遗漏场景。理解比完成更难替代，因为判断的根基建立在亲手做过的基础上——这一点，agent永远无法替你完成。
更危险的是技能衰减的静默性。Addy Osmani观察到，Mastery still comes from doing the reps。当你把代码审查、调试、架构决策全部交给agent，你不会立刻感受到损失，但几个月后你会发现，自己已经无法独立判断agent产出的质量。判断力的退化是渐进的，等到察觉时，根基本已被抽走。
Agent协作中的判断力分布
为什么「理解」比「完成」更难替代
「完成」是一个可度量的状态。测试通过、文档生成、接口跑通——这些都是硬指标。但「理解」是另一种维度的能力。它要求你知道agent为什么这样做，以及如果不这样做会怎样。
Addy Osmani在讨论agent审计时抛出一个具体问题：「你的Agent有数据库访问权限。你能说出它做了什么吗？」给一个Postgres登录凭证，Agent看起来和其他角色没有区别——共享的、长期的凭证，没人追踪是哪个agent跑了哪条查询。执行变得廉价，理解变得昂贵。
Agent的finish line不应该是一句「看起来完成了」，应该是一个可验证的断言。但这个断言本身也需要人来做——谁来决定什么值得验证？谁来判断验证是否充分？这些判断力无法外包。你买的旗舰款，瞬间变成平替套餐——前提是没人问你套餐里装的是什么。
Agent跑通了，但没人问为什么
判断力是工程师最后的护城河。当所有执行都可以外包，剩下的就是判断：这个方案对不对？这个边界有没有漏？这个trade-off值不值得？这些问题没有标准答案，也没有agent能替你回答。
{ "title": "AI越准人越懒？Anthropic工程师警告：小心这种「认知投降」", "summary": "Anthropic Claude Code团队成员Addy Osmani提出「认知投降」概念——当Agent能自动跑通测试、生成文档，人类很容易把「看起来对了」当成「真的对了」。本文进入选型决策层面，对比传统外包与AI Agent两套路径的实际成本结构与适用边界，并给出何时该保留人工环节的判断。", "opening_hook": "几天前，Addy Osmani发了一篇长文：随着Agent能自动跑通测试、生成文档，人们开始把「看起来对了」当成「真的对了」。", "outline_markdown": "## 1. 「认知投降」是什么，为什么 AI 越准越危险
4. 选型决策：传统外包 vs AI Agent
传统 SaaS 化方案的适用边界
Agent 方案的成本与风险
何时该保留人工环节",
"body_markdown": "
多个并行 Agent 同时跑的时候，真正的痛点不是算力，是不知道该相信谁
5. 落地Checklist：如何不丧失思考能力
每日5个必须手动过目的点
具体到可执行层面，Addy 给出的建议可以压缩成五个节点。不是五条大原则，是每天必须停下来的五个动作。
第一，收到Agent交付通知时，先看命令执行记录，再看结果摘要。摘要是Agent帮你总结的，命令记录才是它实际做了什么。两者不一致是常见信号。
第二，对非平凡变更（修改超过3处文件或涉及核心逻辑）强制做一次独立复现。让Agent再跑一次同样的输入，看输出是否稳定可复现——如果两次结果不同，说明你之前信任的那个「正确的」结果可能不稳定。
第三，每周至少手动完成一次该Agent正在做的工作的全部步骤，不用Agent。这一步不是效率问题，是能力锚定问题。你多久不亲手跑一遍，多久就会失去对细节的敏感。
第四，记录Agent的判断与你的判断出现分歧的地方。这不是为了证明Agent错了，而是为了追踪你自己哪类决策模式正在被它同化——或者反过来，你在哪类判断上正变得越来越依赖它。
第五，给Agent的输出打一个可追溯的身份标签。Claude Code、Cursor、Codex，每个工具的决策逻辑不同。混用多个Agent而不区分来源，是事故的高发路径。
这四个行为的核心逻辑是一样的：不是对抗Agent，是保护你作为最终责任人的判断回路不被静默绕过。
建立自己的Agent审计习惯
如果说上面的五条是每日防线，那么「审计习惯」是把防线变成基础设施的关键一步。
代码评审最痛苦的不是改代码，是看懂别人改了什么
真正的审计不是事后补救，而是让Agent的每一步都在一个你可以快速定位的上下文里。具体做法有三条。
首先是任务级别的身份隔离。给每个Agent分配临时凭证，任务完成后自动失效。不要用共享账号让所有Agent共用一个权限——身份不可追溯，问题发生时连责任都找不到人。这与Teleport等零信任访问框架的设计思路一致，本质上是把「谁在什么时间做了什么」变成可查的事实，而不是事后追问的悬案。
其次是决策链的外挂。不要只保存Agent的最终产出，保存它的推理链条：它看了哪些文件，问了什么问题，做了多少次回滚，最终为什么选择了这个方案。这些信息不需要人工阅读全部，但要保证在你需要追溯时能找到。
最后是定期复盘。每周抽30分钟，挑出本周最复杂的一个Agent任务，逐层还原：任务目标是什么，Agent走了哪几步，哪一步是你原本会做但Agent替代了，替代之后结果有什么不同。这个练习本身就是在维持你的判断力。
``mermaid
Agent审计闭环
这条闭环的价值不在于「拦住Agent」，而在于让每一次人机交互都变成可积累的经验，而不是单次消耗。
更狠的是，这套机制一旦建立，你对Agent的容忍阈值会越来越清晰——什么时候可以信任它，什么时候必须亲手过一遍，什么时候该换工具。这不是经验主义，是数据驱动的决策校准。
参考文献
- Addy Osmani, "Critical thinking when agents do the work," X (Twitter), 2025: https://x.com/addyosmani/status/2117512471930167377
- Addy Osmani, "Agentic Skill Decay," substack, 2025: https://addyo.substack.com/p/agentic-skill-decay
- Addy Osmani, "Audit your Agent files," substack: https://addyosmani.com/blog
- Addy Osmani, "When AI agents are done working, how do we stay critical?" TechFlowPost 编译: https://www.techflowpost.com/article/35077
- Antoine Buteau, "Lessons from Addy Osmani," 2025: https://www.antoinebuteau.com/lessons-from-addy-osmani
如果浏览器无法直接唤起微信，可在微信内打开公众号主页：计算机魔术师
