Claude Code工程师发文：AI写代码越靠谱，人越容易"认知投降"
万物皆可外包，但脑子不行啊！
AI一天比一天聪明，人反倒越来越不愿意动脑子了。
前Google Cloud AI总监、如今在
Claude Code项目做工程师的Addy Osmani，刚专门写了一篇文章，聊的就是这个挺扎心的问题。
他的看法是，那些成天指挥Agent写代码的工程师，恐怕已经在不知不觉中滑进了一种状态——认知投降（Cognitive Surrender）。
说白了一句话：AI写什么，你就信什么。
代码跑得通，测试全绿，手一挥，"批准！"
可真有人问起这段代码为什么这么写，自己却答不上来。
于是这位亲手参与打造AI编程工具的工程师，想出了个挺有意思的办法给大家支招：
让Agent写完代码之后，再出几道题反过来考你。
答不上来？那先别急着合并代码。（doge）
AI越聪明，人越容易被"养废"
Addy Osmani是什么来头？
他在英国华威大学读完硕士，之后在Google干了14年多，Chrome DevTools、Lighthouse这些开发者工具项目都有他的份，现在则加入
Anthropic，做Claude Code相关的工作。
△
另外，他还是圈里出了名的热门教程高产作者。
Claude Code的使用技巧、Agent工作流、代码审查，几乎隔三差五就能看到他发新教程。
这一回，他把视线转向了一个越来越现实的问题：
AI生成的东西越来越靠谱，人还会认真去检查吗？
搁以前写代码，资料得自己哼哧哼哧查，方案得自己琢磨，调试也得自己动手。
但现在呢？
现在一句Prompt丢过去，Agent可能几分钟就把活干完了。
更麻烦的是，模型能力往上走，AI写出来的代码也越来越像那么回事。
变量命名规范，逻辑看着也顺，测试还一片绿。
结果大家慢慢就习惯了：第一次认真检查，第二次扫两眼，第三次直接点通过……
时间一长，人就从亲自写代码的那一方，变成了给Agent盖章的那一方。
△
Addy把这种情况叫作认知投降（Cognitive Surrender）。
它不是一夜之间发生的，而是一个逐步加深的过程。
一开始多半只是“认知卸载”——具体活儿交给AI，任务本身我们照样理解，结果对不对也还能判断。
再往下走，就变成“判断让渡”了，AI给出的答案慢慢成了下一步工作的默认依据。
到最后，则是“认知投降”：
算了算了，AI说的肯定有道理，听它的吧。
到了这一步，本该自己做的判断，也一并交了出去。
△
Addy举的例子很典型：
假设Agent一次就提交了一个600行代码的PR（拉取请求）。
开发者扫一眼，结构清楚、测试也过了，行，放心合并。
可Agent也许在某个不起眼的角落，把事务处理顺序悄悄动了，或者改了某个边界条件。
这些改动当时并不会立刻报错。
等到系统真出了故障，开发者才猛然发现，这段代码为什么这样跑，自己根本讲不清楚。
更麻烦的还在后头。
Addy认为，长期这么用Agent，会攒出一种新的技术债务——理解债（Comprehension Debt）：
代码越写越多，系统功能也越来越复杂。
但开发者对代码的理解，并没有跟着一起长。
结果就是，真要改某个功能时才发觉，这座代码大厦是盖起来了，可内部结构越来越没人摸得透，大家只能干瞪眼，实在闹心。
当然，这不等于AI生成的每一行代码都得亲自读一遍。
Addy也说了，Claude Code团队并不要求工程师时刻记住整个代码库，需要改哪一块时，借Claude把相关逻辑重新弄明白就行。
不过有个前提：
你得清楚自己懂哪些，还有哪些没搞懂。
不然，代码写得越快，理解债可能欠得越重。
防沉迷小妙招：让Agent反过来考咱们
那么问题就来了。
Agent现在这么能写，咱们到底怎么才能跟上它的速度？
Addy在那篇长文里讲了不少自己实际操作的招数。最有趣的一手，是把Agent变成出题考官。
设想一下，Claude刚做完一次大范围的代码改动，别急着点通过。可以先让它把这次改了哪些地方、为什么这么改讲清楚，再照着改动内容给自己出几道题，同时定下一条死规矩：测验全部答对，代码才允许合并。
这么走一遍，自己究竟批准了什么，心里就真有数了，也能少犯些本可避免的错。
另外几招Addy也一并分享了，我整理在下面。
妙招1：写Prompt前，先自己动脑把需求列成清单
Addy说，眼下Agent补全需求的本事确实太强。哪怕我们还没想清楚要什么，它也能拿出一份看着挺像样的成果。
麻烦恰恰在这儿：需求里那些没讲明白的目标、限制和取舍，很可能就这么被AI替你定了。
Addy给这种状况起了个名字，叫“意图债”（Intent Debt）。
因此他的建议是，派活之前先用自个儿的话写一小段需求说明：给谁用、要解决什么、哪些事不用做、做到什么程度算完。想明白了，再放Agent开工。
要是连着两轮Prompt调下来还是不对味，那就该停下来重新捋需求，而不是继续往提示词上摞东西。
妙招2：让Agent主动交代它瞒着你做了哪些决定
这一招对跑得久的任务尤其管用。Agent干活时可能自己挑了默认参数、改了实现范围，甚至几条需求打架时自作主张做了取舍。这些决定它未必会写进最后的总结，有时候自然得根本察觉不到。
所以别只丢一句“完成了吗”，Addy建议接着往下问：哪些决定是我没明确授权你做的？哪些地方是你按自己的假设来的？
还有哪些地方没验证过？哪些改动会波及别的功能？
这么问下来，Agent在干活时做了哪些取舍，至少能看个大概；再对着代码和测试结果，一条条核实它自己交代的内容。
妙招3：测试全绿不算数，得追问它漏测了什么
Addy专门提醒过，绿色的测试结果只说明测试覆盖到的那些条件过了关。边界情况要是压根没写进测试，Agent照样能交出一份漂漂亮亮的报告。
所以他建议，先看清楚实际跑了哪些测试、返回了什么结果，再去读AI写的总结。碰上高风险的修改，还可以再加一道独立检查，让另一个Agent换个角度挑毛病。
妙招4：Agent可以多开，但重要任务得留住原始材料和验证依据
现在估计不少人已经同时指挥好几个Agent了：一个写前端，一个改后端，还有一个管测试。效率确实是芜湖起飞。
可人跟人传话会走样，多个Agent协作也一样——一个Agent的总结很容易直接变成下一个Agent的输入。传着传着，整个工作流离原始资料越来越远，原始信息里的关键细节可能早就丢了…
△
Addy因此提醒，重要任务必须保留原始材料和验证依据。至于那些多到根本审不过来的任务，要么补上自动化检查，要么先把并行数量减下来。
不然，Agent数量继续加，只会让待审核的内容越堆越高。Addy对此的判断相当犀利：
当你生成的内容已经多到无法负责时，你做的就不再是审查，而是在赌它没问题。
妙招5：每周留点时间，回归古法手搓代码
这招听上去甚至有点复古。都2026年了，Claude工程师居然还劝大家偶尔别用Claude？
但Addy认为，技能长期不用，确实可能一点点退化；偶尔脱离Agent独立把任务做完，也能帮大家随时校准自己当前的真实水平。
于是他的建议是，每周抽出至少一次，完全不借助Agent，自己动手写代码练一练。
每个月还不妨花点时间盘一盘：哪些技能已经交到AI手里了？哪些能力可以安心外包出去，哪些又非得自己攥着不可？
这么做还另有一层好处——离开AI之后，好歹能知道自己眼下究竟还会干点啥。
Addy在文章末尾还给了一个特别省事的自测法子：每次向Agent发问之前，先把自己预期会出现什么结果写下来。
等AI把活交上来，再努力找出至少一件它或许没顾上检查的事。
这样至少能保证，整个干活过程里，脑子也跟着转了两下。
干货讲完之后，Addy还抛出一个问题，所有重度的AI用户都该认真琢磨琢磨：
大家伙儿说句实话，假如明天AI全都罢工了，你觉得自己能扛几天不崩？
嘶……对啊，能扛几天呢？
别人怎么样不好说，反正在我这种选择困难症晚期患者这儿，多少有点天塌下来的意思。（泪目）
毕竟出门得靠AI规划行程，找路要问AI，就连去餐厅吃顿饭，都巴不得先让豆包它帮我研究研究菜单，看看哪道菜最值得点。
这么一想，AI要是真集体罢工，我怕是连今天午饭吃啥都得从头学起了。（捂脸）
One More Thing
最有节目效果的，果然还是留到了最后。
前头洋洋洒洒教完大家怎么防止被AI养废，Addy转头就在文章末尾得意地贴出一张AI检测报告；
Pangram的检测结果写着：
人类撰写90%，AI生成10%，AI辅助0%。
哈哈，合着前面苦口婆心劝大家别把脑子外包出去，最后自己也没忘亲自把作业交了：
放心，这篇劝你们动脑子的文章，我也是真动了脑子写的！
好好好，真·知行合一。（doge）
参考链接：[1]https://x.com/addyosmani/status/2117512471930167377
