研究数据：重度 AI 用户代码理解率仅 50%，调试能力下滑最显著

我们团队里有一位应届毕业生，只用了一个下午就提交了一个包含 400 行代码的 PR。代码改动很干净，所有测试都通过了，PR 随时可以发布。然而紧接着线上就出现了内存泄漏。没有弹窗，没有自动补全，只有一条往上走的曲线和一个压力爆棚的初级工程师。

没人想直说的那件事

r/ExperiencedDevs 上有一篇病毒帖子，讲的是一个同事因为用 AI 代替学习代码而被开除，引发了激烈争论。这篇帖子收获了 1000 多条评论，大家在讨论 AI 是否正在悄悄毁掉初级工程师应有的学习方式。两边都说对了一半，也都在回避真正的问题。我们招的不是会用 AI 的工程师，我们招的是 prompt 的操作员，然后还奇怪为什么他们离了 AI 就没法独立思考系统。

数据跟上了直觉

2026 年 1 月，Anthropic 发表了一项名为"AI 辅助如何影响编程技能"的研究，发现 AI 用户在理解测验中平均只得了 50 分。而手动编码组平均得了 67 分（Cohen's d=0.738，p=0.01）。最显著的差异不在语法或风格上，而在调试题上。🧠

情况对于重度用户来说更糟。那些持续依赖 AI 的"AI 委托"组得分不到 40%。他们完成任务最快，却表现出"更少的独立思考和更多的认知卸载"。

Anthropic 研究人员的原话是："如果初级工程师的技能发展从一开始就因使用 AI 而受阻，那么生产力上的收益可能是以验证 AI 编写代码所需的技能为代价的。"

需要两倍的阅读量。那些本该评估 AI 的人，恰恰是连评估任何东西的能力都不足的人。

代码库也在悄悄腐坏

GitClear 分析了 2020 年 1 月至 2024 年 12 月间产生的 2.11 亿行代码。重构从 2021 年占提交量的 25% 下降到 2024 年的不到 10%。2024 年，重复代码块的比例意外增长了 800%！这一年也是复制粘贴代码量首次超过重构代码量的一年。这不是技能问题，而是系统正在因为没有人真正统筹全局而逐渐堵塞。

为什么调试是那道墙

生成代码和理解系统是两种不同的运动。→ 写代码是局部的。你需要一个文件和明确的目标。→ 调试是全局的。你需要同时在脑中装下数百个文件。→ AI 擅长前者，在后者上直接跌落悬崖。你看过 SWE-bench 吗？那个基准测试里全是真实 GitHub 仓库的 bug。GPT-4 和 Claude 2 这样的通用模型甚至连 5% 都过不了。它们解决不了任何问题的原因和我们的初级工程师犹豫的原因一样。真正的故障需要一整幅相互关联的文档图景，而没有什么说明书能给你这个。

所以是谁的错？

我们不是掉进了陷阱，我们设好了陷阱然后引他们进去。我们奖励速度而非理解。我们表扬快速的 PR，却从不让人解释背后的逻辑。2025 年 4 月，Tuskira 的 CISO/CPO Om Moolchandani 说："初级资源的解决问题能力较弱，缺乏深层的系统级理解（比如在语言编译器/解释器、操作系统中剖析和解决问题的能力），而且这些概念最终取决于他们进入行业时的水平。很多人能生成可用的代码片段，却无法解释背后的逻辑，或是在现实攻击场景中保障其安全。"

这就是本质。可以创建，但无法论证。我们把学习曲线外包了，然后还假装学习没发生。

我实际上在做什么

我不再根据 pull request 的速度来评判初级团队成员。在我们这个小团队里，如果你不能用时间解释和讨论实现方案，快速合并代码就毫无意义。解决方案不是禁止 AI，而是确保人们值得那个快速的替代方案。→ 合入之前大声解释 diff。不是"AI 写的"。→ 每周关掉自动补全调试一个棘手的问题。→ 读那些不属于你的旧代码，直到系统不再像魔法一样。AI 可以惊人地加速事情，前提是你已经有一个框架可以加速。但它完全不能替代从头创建那个框架。那个惊慌失措、僵在原地的初级开发者并没有缺陷。他们只是从未被要求做过困难的事，然后困难的事就出现在了他们的实际工作中。我的问题是，如果你的顶级初级工程师因为 AI 工具不能用一周，他们还会是你的顶级初级工程师吗？