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%。

哈哈，前面苦口婆心劝大家别把脑子外包给AI，他自己倒也没忘记亲自交作业：

放心，这篇劝你们动脑子的文章，我真是动了脑子写的！

好好好，真·知行合一。（doge）

参考链接：[1]https://x.com/addyosmani/status/2117512471930167377