Agent 把活干完了，签字的人看懂了吗

Addy Osmani 是 Google Chrome 团队的工程负责人。他最近写了一篇长文《Critical thinking when agents do the work》，讨论一个具体问题：当 Agent 接管越来越多工作，人怎么保住独立思考。他不打算劝人少用 Agent，自己也在用。他担心的是另一件事：Agent 越顺手，人越容易把判断力交出去，过程还很安静。

他给了一条滑坡。最上面是认知卸载，把任务交给 AI，但结果仍归自己。中间是推迟，工具输出变成新的输入，结果不再只是假设。最下面是认知投降，AI 的输出悄悄变成你的，你觉得没必要检查。认知投降这个说法来自 Wharton 的 Steven Shaw 和 Gideon Nave。滑坡的每一步都合理：上一条回答不错，下一条就扫一眼；再下一条只看骨架；然后有人问某行代码，你解释不了，哪怕 Agent 就在旁边。

这样积累的是认知债务。Margaret-Anne Storey 写过它在团队里的样子：共享系统理论被侵蚀。代码世界有对应词，comprehension debt，由 Jeremy Twei 提出。现场很干净，测试全绿，代码库看起来没问题。等到要改系统，才发现没人理解它。策略文档和 spec 也一样，你读了目录就签字，后面没人能解释关键假设。

Addy 不是要人维护完整心智模型，那不可能。Claude Code 团队公开说，他们按需重建理解：需要懂哪块，就让 Claude 解释哪块。债务比多数工程师想得可恢复。前提是你知道自己不知道什么。低风险的事可以全交。录课时他要从三家评分相近的酒店里选一个，没时间看评论，交给 AI，结果能用。投资、孩子职业建议、公司该做什么、发布是否安全，这些不能这么干。错得便宜的地方可以放手，后果要别人承担的地方，推理得留在自己手里。

验证也是。Agent 能自己跑测试、读输出、再试一次，效率很高。但绿色勾只证明一件事。Addy 会问：这个检查证明了什么，没证明什么。测试可能和功能犯同一个错，照样绿。绿色只覆盖一个属性。完成标准最好具体：测试通过、截图、日志、trace。Agent 发来完成通知，先看执行命令和输出，再看总结。Claude Code 可以用新上下文里的子 agent 自评，值得固定进循环。他还会在最后问一句“Did I miss anything?”，经常能问出两三个漏掉的东西。

600 行 PR 是另一种现场。变量名合理，测试通过，你批准。中间可能有事务边界的顺序变化，或者边缘情况的默认值被翻转。你看过 diff，但只看见自己预期会看见的东西。写代码和审代码是两种技能，审到某个点就变成盖章。读 diff 时假设 AI 没写它，再看 diff 之外 Agent 替你做了哪些决定：默认值、范围、需求冲突时它重解释了哪条。总结不会写这些。让它列出决定和假设，再随机挑几行问自己。长会话可以要一份变更报告，附小测验，规则是满分才合并。

评论里有人问，junior 如果没手写过代码，怎么建立判断力。也有人问，你读 diff 还是只读 summary。问题都扎在同一个地方：监督需要的能力，可能正好被 AI 过度使用磨掉。Anthropic 对自家工程师和研究员的研究把这个叫监督悖论。Addy 的答案不轻巧：总得有人对发布的东西负责。工作可以外包，审计可以外包很多，问责不能。

日常做法不用全套。每周不用 Agent 写一点代码，或者做一件忘了会麻烦的事。每月写下自己停掉了什么，决定哪些可以接受。问一句老问题：如果 AI 不存在，你会多迷失。验证是工作，不是免费动作。把它排进日程，才会真发生。

Addy 文章结尾给了一串可带走的东西：有假设再问；绿色勾只说明一件事；先读它跑了什么返回什么，再读总结；读 diff 是为了知道它替你做了哪些决定；提示词写清楚，那是你对问题的理解；设一条底线，不愿署名的东西不发布；手动练那些不愿丢的技能。Agent 可以帮你工作，也可以帮你检查，但最后签字的人得知道自己在签什么。