Google Chrome 团队的工程负责人 Addy Osmani ，写了一篇文章，标题很直接：不要把学习外包出去。

他说现在有个很普遍的循环：你扔给 AI 一个报错信息，它给你一段代码，bug 修好了，你就发布了。在这个过程里，从问题到解决方案之间那种「挣扎着搞懂」的环节，彻底消失了。代码跑了，但你脑子里的模型一动没动。

他写过「认知投降」这个概念，说的是你慢慢让 AI 的判断替代了自己的判断。一个人的时候也一样。AI 比你快，你就不再试图在理解上跟它较劲。几千次这样的小交互下来，没有 AI 在旁边的时候，你能独立构建的东西一周比一周弱。

他引了三组研究。Anthropic 在 2026 年初做了一个随机试验，让工程师学一个新的 Python 库，一半用 AI，一半不用。两组完成速度一样，但 AI 组的理解测试得分只有 50%，裸写组 67%，差距在调试环节更大。AI 组内部也有分化：用 AI 问概念问题的人得分超过 65%，纯复制粘贴的人不到 40%。姿态决定了结果，工具本身没有。

MIT 的脑电研究发现，用大模型写文章的人，大脑连接最弱。写完以后，83% 的人连自己刚写了什么都复述不出一句。

CHI 2026 的研究补充了一个更有意思的发现：如果一开始就让大模型介入，它会框定整个问题的走向，哪怕后面全是人自己做的，决策质量也会显著下降。先问 AI 还是先自己想的顺序，比用了多少 AI 更重要。

但这些工具默认设计的目标只有一个，就是关掉任务。产品团队被合并变更数量和缩短周期时间驱动，不会被「让工程师更敏锐」驱动。那些被磨掉的摩擦，恰恰是学习发生的地方。

他给了几个很具体的姿态调整。形成假设再提问，先要解释再要代码，把 AI 的输出当实习生的 PR 来 review，偶尔用手重新推导一遍 AI 写出来的东西，让模型解释它刚做了什么。都不难，只是同一套工具换一种用法。

在最后，他问了自己一个问题：我今天学到了东西，还是只是关掉了几个 issue？他说交付代码和学习是两个不同的指标。你的老板和用户只会盯着第一个，问你怎么还没发。但第二个，你学到了多少，只有你自己在意。他宁愿交付能交付的八成，学会该学会的全部，也不愿反过来。因为经年累月，这两种策略会造出完全不同的工程师。

#How I AI##科技先锋官#