AI最危险的时候，不是它错得多，而是它错得少。 因为它一错，你还会检查；它很少错，你就懒得看了。微博
这几天，中文编程圈集体在聊一个词：认知投降（cognitive surrender）。提出这警告的不是唱衰派，而是Anthropic Claude Code团队的工程师 Addy Osmani——在Google干了14年、写过《JavaScript设计模式》的老兵。他发了一篇长文，给天天用这些工具的人提个醒。微博微博知乎
最扎心的是，他不是在劝你少用AI。他自己就同时跑好几个Agent会话。他描述的，是一条多数工程师已经踩上去的滑坡：上一个答案你认真读过，下一个就略读，再下一个只看骨架。直到有人指着一行代码问"为什么"，你发现连Agent帮忙都解释不出来。微博
他给这条滑坡分了三级：顶端是认知卸载——活交给AI，掌控和责任还在你手里；中间是判断让渡——AI的输出直接变成你的下一步输入，不再是待检验的假设；底端才是认知投降——AI的输出悄悄成了你自己的观点，而你觉得没必要核查。每一步都很慢，看起来都合情合理。微博
背后还有一组更残酷的事实。Anthropic对自家工程师的研究提出了"监督悖论"：监督Claude，恰恰需要那些可能因过度使用AI而退化的编程技能。代码库表面整洁、测试全绿，直到要改需求的那天，大家才发现没人真正理解它——这就是所谓的"理解债务"。微博微博微博
这种焦虑不是空穴来风。小红书那篇《被Codex养废后，我已经不敢单独用Claude》，赞400多、收藏600多。评论区里有人坦白，现在自己是用Claude Code出计划、Codex做检查——让两个AI互相放哨，已经是民间智慧了。小红书
Osmani的实在之处，是没停在讲道理，而是给了一份防身清单。几条性价比最高的：微博
提问前先有假设。 丢任务给Agent之前，写下你认为结果会是什么，猜得烂也行——读过一份写得漂亮的回答之后，你很难再想象其他可能性。
先看证据，再看总结。 先查它实际运行了什么命令、返回了什么输出，"一切顺利"的摘要放后面。一个绿色对勾，只证明它检查的那一项性质。
让它列出替你做过的决定。 一次长会话里，Agent默默替你定了不少事：默认值取什么、什么不在范围内、两个需求冲突时软化哪一个。这些不会出现在总结里，要主动问。
随机考自己。 挑几行代码问"这行是干嘛的"。他的玩法是让Claude写变更报告、末尾附一套测验，规则是：只有全部答对，我才合并。
每周做一次校准练习。 脱离Agent亲手写一小段代码。停止练习的技能会消失，而且比你想象的更快。
最后划一条底线，只有一句话：可以把工作和大部分审查交出去，但不能把责任交出去。出错代价低的事，放心交给AI；后果要别人承担的，推理和判断必须留在自己手里。微博
留一个自检问题：“如果AI不存在了，你会有多不知所措？” 诚实回答它，你的答案就是你此刻在认知连续谱上的位置。
