lijianfei.com

作为每天在终端里同时挂着三四个 Agent 会话、把繁重编码与重构任务大量托付给 AI 的开发者，我最近愈发体会到一种隐蔽的心智变化：当敲下一句需求描述后，十几秒内终端就能吐出数百行结构工整、类型严谨且伴随着满屏单元测试绿灯的代码。这种极致顺滑的开发体验令人愉悦，但它也在无形中悄悄溶解着工程师最核心的本领——批判性思维。

前 Google Chrome 架构负责人、现 Anthropic 开发者体验（DX）与 Claude Code 团队核心成员 Addy Osmani 近日发表了一篇引发技术界强烈共鸣的长文《当智能体替你工作时的批判性思维》（Critical thinking when agents do the work）。他并没有站在卢德主义的立场唱衰技术，作为 Agent 工作流的最狂热倡导者与构建者之一，他尖锐地指出了前沿模型带给开发者的真正心智危机：随着模型能力暴涨，显而易见的代码低级错误急剧减少，AI 生成的代码自信而得体，但这恰恰诱使工程师放松警惕，从主动掌控一步步滑向危险的“认知投降”。

一、被抹平的思考空间：从“痛苦权衡”到“秒级交付”

在过去几十年的软件工程日常中，工程师大部分真正的认知推演与审美决策，都发生在“提出问题”与“敲出解答”之间的空白地带。

为了设计一个缓存失效策略或重构一段高并发状态机，我往往需要坐在白板前写写画画，在草稿纸上罗列数十种边界条件，翻阅底层 API 文档，反复在心中推演锁竞争与内存开销。这个推演过程充满犹豫、试错与反复推敲，正是这种略带痛苦的认知摩擦，在我的脑海中浇筑起了对整个系统的坚固理论模型（Mental Model）。

然而在 Agentic Workflow（智能体工作流）全面落地的今天，这个原本以小时甚至以天为计量的思考空间，被生生压缩到了数秒之内。

flowchart LR
    subgraph Traditional ["传统工程推演范式 (高认知摩擦)"]
        direction TB
        Q1["提出架构/业务问题"] --> C1["发散思考与心智模拟<br/>(耗时数小时 / 权衡边界与妥协)"]
        C1 --> H1["形成假说与验证矩阵"]
        H1 --> A1["手动实现并承担后果"]
    end

    subgraph Agentic ["Agent 自动化交付范式 (零认知摩擦)"]
        direction TB
        Q2["简要描述需求 Prompt"] --> A2["多 Agent 并发推理执行<br/>(耗时仅需数十秒)"]
        A2 --> R2["生成工整代码 + 绿灯测试"]
        R2 --> S2{"审视警惕性衰减<br/>(极易滑向默认放行)"}
    end

    style C1 fill:#e0f2fe,stroke:#0288d1,stroke-width:2px
    style R2 fill:#dcfce7,stroke:#16a34a,stroke-width:2px
    style S2 fill:#fee2e2,stroke:#dc2626,stroke-width:2px

很多人以为，多会话并发 Agent 的核心挑战在于模型会不会写出 Bug。Addy Osmani 指出，事实恰恰相反：随着模型不断进化，显而易见的荒谬错误比例在急剧降低。绝大多数由前沿大模型生成的补丁或 PR，不仅语法无懈可击、命名规范工整，甚至还体贴地附带了全套 Mock 数据与通过的单元测试。

这就带来了一个残酷的人性悖论：

快速、惬意且“大多正确”的自动化交付令人身心舒畅；但也正因如此，它不再主动要求你进行第二次复核，促使你在不知不觉中彻底缴械了警惕。

二、AI 协作的三重光谱：从“认知卸载”滑向“认知投降”

在与工程师群体的长期交流与实战观察中，Addy Osmani 借用了沃顿商学院学者 Steven Shaw 与 Gideon Nave 提出的概念，将人机协同的心智状态划分为一条清晰的光谱：

flowchart TD
    L1["【认知顶层】认知卸载 (Cognitive Offloading)<br/>将繁琐执行委托给 AI，但牢牢掌控架构假设、验证标准与最终结果所有权"]
    -->|信任度盲目上升 / 审查惰性滋生| L2["【中间过渡】延期顺从 (Deferral)<br/>工具的输出直接作为人类的新输入；AI 的结果不再是待证伪的假说，而被默认采信"]
    -->|边界逐步失守 / 批判性思考完全归零| L3["【最底危险层】认知投降 (Cognitive Surrender)<br/>AI 的产出悄无声息地成为你的代码；你不再核查，甚至连借用 Agent 也解释不清系统机理"]

    style L1 fill:#f0fdf4,stroke:#15803d,stroke-width:2px
    style L2 fill:#fefce8,stroke:#ca8a04,stroke-width:2px
    style L3 fill:#fef2f2,stroke:#b91c1c,stroke-width:2px

1. 认知卸载（Cognitive Offloading）

这是人机协同的黄金状态。我每天都在终端里大量使用 Agent 生成样板代码、转换数据结构或编写脚手架。在这种状态下，我始终是系统的第一责任人。我知道自己要验证什么，我对 Agent 的输出抱有健康的怀疑，AI 只是替我执行搬砖动作的强大杠杆。

2. 延期顺从（Deferral）

当任务堆积如山时，天平开始倾斜。Agent 给出的方案直接被我当成了下一步行动的既定事实。我跳过了“在脑海中建立备选假说”的步骤，直接把 AI 吐出的设计视作唯一正解。此时，AI 的输出已经从“待验证的假说”蜕变成了“不可置疑的输入”。

3. 认知投降（Cognitive Surrender）

滑向认知投降的过程极其隐蔽，因为每一个渐进的步骤看起来都合情合理：

• 第一轮产出的 PR 你仔细读了每一行；
• 第二轮产出长了点，你走马观花地扫了一眼架构草图；
• 第三轮你直接拉到最底部，看着 CI 绿灯一亮，顺手点了 Merge；
• 直到某一天，在线上突发排查或架构答辩中，有人指着其中一行异步事务的隔离级别问你：“这里为什么用这种回滚机制？”——此时你突然脑中一片空白，甚至即使把上下文重新丢给 Agent，你也无法用自己的话向他人解释清楚这套系统的行为。

在低风险场景下（例如让 AI 在三家评分相近的酒店中做一次挑选，或者格式化一段日志），完全放手让 AI 决断是明智的时间套利；但若是在高风险场景——涉及系统核心数据流转、安全鉴权边界、并发一致性设计时发生认知投降，你所交付的就根本不再是一套软件，而是一堆包裹着精致糖衣的负债。

三、冰山之下的隐形债务：理解债务、意图债务与编排税

许多技术管理者常常产生一种幻觉：“既然单元测试覆盖率达到 90%、静态分析全部合规、新功能交付速度提升了 5 倍，那代码库的健康度必定大幅上升。”

Addy Osmani 尖锐地戳破了这个泡沫。在 Agent 狂飙突进的代码行数之下，正静默堆积着三重足以拖垮工程组织长期生命的隐形债务：

1. 理解债务（Comprehension Debt / Cognitive Debt）

软件工程学术界（如 Margaret-Anne Storey 教授）长期探讨的一个核心命题是：软件系统的本质并不是代码文本，而是工程师群体大脑中所共享的“系统理论”（Shared System Theory）。

正如 Jeremy Twei 所指出的那样：在当下，理解债务是完全隐形的。代码看起来一尘不染，编译没有半点警告，自动化流水线一路畅行。但只要系统需要进行核心架构演进或遭遇未预料到的并发雪崩，整个团队才会如梦初醒：在这个系统里，已经没有任何一个活人真正理解整套机制了。

[!WARNING] 理解并非不可挽回，但需要按需重建
并非要求工程师像以前那样在脑子里装下百万行代码的所有上下文。正如 Claude Code 官方团队所透露的那样，他们自己也是在需要深入某一块业务时，通过让 Claude 解读切片来“按需重建理解”（Rebuild understanding on demand）。但关键在于：你必须清楚地意识到自己到底缺失了哪块拼图，而不是假装自己已经理解了一切。

2. 意图债务（Intent Debt）

在过去的协作中，如果你向资深同事抛出一个含糊不清的需求：“做个批量导入功能”，对方大概率会立刻反问：“如果某一行解析失败，是整体事务回滚还是跳过？单次导入的并发上限是多少？要不要做幂等重试？”这种来自人类同行的反向挑战，会强迫你在动工前把系统约束想清楚。

但 Agent 不会挑战你。
当你给出一个粗线条的 Prompt 时，Agent 从不会停下来抗议，而是会悄悄替你脑补所有缺失的约束和边界条件。它交付给你的东西看起来完整可用，但其底层所做的关键架构妥协、异常放弃策略与容灾取舍，从未真正经过人类大脑的深思熟虑。这种隐瞒在制品中的未明示目标与约束，正是不可由他人代劳的“意图债务”。

3. 编排税（Orchestration Tax）

当我们在本地终端轻松调动四五个 Agent 会话并行干活时，生产代码的吞吐量呈指数级暴涨。但人类审阅复杂逻辑的认知带宽是严格受限的：你依然只有一双眼睛。

Addy 将“Agent 并发生成代码的速度”与“人类工程师能够负责任背书代码的速度”之间的鸿沟，称为“编排税”。
当你产出的代码量远远超出了你能够深入审计的生理极限，你所谓的 Review 其实已经彻底退化成了祈祷（Hoping）。为了缓解堆积如山的 PR，人们会本能地放松验收标准，最终导致低劣决策成批渗透进主干分支。

四、绿灯陷阱：当“验证”本身也被顺从投降

在 Agentic 编码体系中，Anthropic 的 Boris Cherny 曾提出一条被行业奉为圭臬的准则：“给 Claude 一个验证自身工作的方法”（Give Claude a way to verify its work）。如果 Agent 能够自动运行 E2E 测试、属性测试或命令行校验，它就能在人类介入之前完成自我纠错闭环。

然而，Addy Osmani 发出了更深层的警示：许多工程师正在连同“验证”本身一起向 AI 投降。

flowchart TD
    A["Agent 执行复杂逻辑变更"] --> B["Agent 自行编写对应的单元测试"]
    B --> C["执行测试：满屏绿灯 (All Passed)"]
    C --> D{"核心审问：这个测试证明了什么？"}
    D -->|致命误区：直接采信| E["【假阳性盲区】<br/>若 Agent 误解了业务约束，它写出的测试<br/>会忠实地断言这个错误设计为 True！"]
    D -->|严苛工程核查| F["【确定性证据矩阵】<br/>1. 检查测试未覆盖的维度<br/>2. 调阅真实执行命令与 Trace 输出<br/>3. 比对非文本的确定性物理断言"]

    style E fill:#fee2e2,stroke:#ef4444,stroke-width:2px
    style F fill:#f0fdf4,stroke:#22c55e,stroke-width:2px

很多人把“我的结论有事实支撑吗？”降级成了“CI 上的绿勾亮了吗？”。
Agent 写测试的边际成本极低，这会导致代码库里充满大量看似详尽的绿色断言。但致命的问题在于：如果测试用例是 Agent 编写的，那么测试用例往往会完美继承 Agent 最初对业务的误解！

• Agent 以为某种极端边界应该返回 null，它便写了一个断言该场景返回 null 的测试，测试自然 100% 跑通；
• 绿色的勾号只代表了一件事：测试断言的那一小撮条件成立了。但它绝不代表系统没有缺陷，更不代表业务逻辑符合预期。

[!IMPORTANT] 杜绝马后炮合理化（Post-facto Rationalization）
永远在触发 Agent 之前预先定义好“完成与验证”的硬性事实边界（Verified Upfront）。因为在代码生成之后，人类极易在心理上陷入事后合理化，把任何看起来工整的结果自我说服为“这其实也挺合理的”。

五、监督悖论：谁该对进入生产环境的代码负责？

随着前沿基座模型（如 Claude 3.7 Sonnet、GPT-5 级别）的不断跃升，许多乐观主义者会产生一个看似理直气壮的疑问：

“再过一两年，模型自己的查错和架构推演能力就会全面超越普通人类工程师，那我为什么还要费尽心力去维持这些审查技能？”

Addy Osmani 引用了 Anthropic 内部针对自身工程师与研究人员的一项深度调研，揭示了潜伏在技术奇点迷雾背后的核心陷阱——“监督悖论”（The Paradox of Supervision）：

“有效监督 Claude 编码所需要的深厚软件工程素养，恰恰会因为对 AI 的过度依赖而面临急剧萎缩。”

flowchart LR
    A["过度依赖 Agent 交付"] -->|缺乏底层实战推演| B["核心编码与调试技能萎缩"]
    B -->|失去对复杂边界的敏锐嗅觉| C["无力识别高阶细微架构缺陷"]
    C -->|审查沦为盖章| D["只能进行更深度的认知投降"]
    D --> A

    style B fill:#fef2f2,stroke:#dc2626,stroke-width:2px
    style C fill:#fff7ed,stroke:#ea580c,stroke-width:2px

即使未来的模型能帮你捕获 99% 的常见并发死锁和内存泄漏，在现代生产系统的终局，依然存在一个无法被自动化消除的物理基石：终极责任（Accountability）永远无法被外包。

当金融交易出现资金对账偏差，当隐私数据发生泄露，当核心业务链路在黑五大促中熔断宕机，没有任何一个大模型能坐在事故复盘会上面对客户与监管机构承担责任。
无论是决定“我们要为用户解决什么问题”、“哪些边界条件可以作为妥协代价”，还是“这段代码究竟是否安全到可以上线推流”，判断何时该信任 Agent、何时该进行深潜拦截，本身就是高级工程师不可剥夺的核心裁量权。

六、守住认知防线：Addy Osmani 的工程实操工具箱

为了在 Agent 高速吞吐的代码洪流中不被淹没，Addy 结合在 Anthropic 的一线工程实战，整理出了一套极具实操价值的“认知校准工具箱”。在我的日常开发中，我发现这几项实践能够极为有效地阻断认知退化：

1. 先行假说（Hypothesis-First Prompting）

在敲下回车把复杂任务派发给 Agent 之前，强制自己在草稿纸或脑海中写下 1~2 句对解法的预判。
哪怕你的预判并不完美也没关系。一旦你直接阅读了 Agent 吐出的那份格式工整、论据完备的漂亮解答，你的思维就会被先入为主的锚定效应锁死，再也无法构想出第二种可能性。

2. 盲区探测轮（Blind Spot Pass）

当面对完全不熟悉的业务领域、缺乏先验预判时，不要直接让 Agent 给你最终方案。借用 Thariq Shihipar 的思路，把已知的信息交代给 Agent，并下达明确指令：

“基于这些已知条件，请列出我在这个架构方案中可能遗漏的‘未知的未知’（Unknown Unknowns）与潜在盲区，先不要直接输出代码。”

3. 合并前测验机制（Quiz-before-Merge Pattern）

面对动辄数百行的复杂 PR，告别“随便翻翻变量名”的走过场审查。可以让 Agent 在输出代码总结的同时，在 PR 末尾自动附带一份包含 3 道针对性考题的“架构抉择小测验”：

• “这段补丁在处理事务超时时，选择了哪种补偿策略？”
• “为什么要修改这个数据结构的锁粒度？它暗含了什么并发假设？”
• 只有当审查者能够精准回答出这几个隐蔽决策时，才被允许点击合并代码。通过微小的心智摩擦，强行逼迫大脑完成深度认知加工。

4. 审阅真实指令而非总结文本

收到 Agent 汇报的“任务已完成”通知时，千万不要第一时间去读它生成的精致 Markdown 总结。
总结是经过二次润色的抽象结果，极易掩盖问题。第一步应当直接调阅它实际执行的底层 Shell 命令、网络 Trace 与原生标准输出。看证据本身，而不是看机器对证据的自夸。

5. 定期进行“无 AI 肌肉校准”（Calibration Drills）

• 每周一次手工编码：每周至少挑选一段具有智力挑战的算法、系统底层接口或棘手 Bug，完全脱离任何 AI 补全与 Agent，纯手工完成推演与修复，维持肌肉记忆；
• 每月一次技能萎缩审计：定期在笔记中写下自己在这个月里“不再亲手去做的事情”，清醒地审视这些能力中哪些是可以被历史淘汰的低阶动作，哪些是自己绝对不可放手的核心底层直觉。

七、结语：意图与品味，是工程师最后的护城河

在软件工业全面 Agent 化的今天，代码产出的边际成本正在不可逆转地趋近于零。如果一名工程师的核心价值依然绑定在“打字排版有多快”或者“API 语法背得多熟”，那么被边缘化只是时间问题。

正如 Addy Osmani 所说，当 Agent 能够以极高水准完成执行时，人类工程师的大脑并没有被解雇，而是被推向了工程的最前端与最末端：

• 在最前端，负责精准定义系统的意图与边界，拒绝含糊妥协；
• 在最末端，负责施加严苛的美学与工程品味，守住质量底线。

不要在流畅的代码提示与绿色的勾号中安然入睡。正如那句震聋发聩的技术警言：
“你可以卸载编码的繁重劳作，甚至可以卸载绝大多数自动化审计；但你永远无法卸载最终的责任。”

原文链接与参考资料

• X 原文长文推文：Addy Osmani on X: "Critical thinking when agents do the work"
• X Articles 完整长文：Critical thinking when agents do the work - Addy Osmani
• 沃顿商学院认知投降研究：Cognitive Surrender - Steven Shaw & Gideon Nave, Wharton School
• Anthropic 官方团队代码审查实践：How the Claude Code team does code review - Anthropic Engineering
• Anthropic 内部 AI 影响深度研究：How AI is transforming work at Anthropic - Anthropic Research
• 理解债务与意图债务理论：Comprehension Debt & Intent Debt in Agentic Coding - Addy Osmani