跳到主要内容

技能萎缩陷阱:AI 辅助如何悄无声息地侵蚀那些最依赖它的工程师

· 阅读需 12 分钟
Tian Pan
Software Engineer

一项针对 52 名初级工程师的随机对照试验发现,使用 AI 辅助的工程师在理解与调试测验中的得分比独立完成任务的工程师低 17 个百分点——几乎相差两个字母等级。调试能力——恰恰是 AI 应该增强的技能——呈现出最大的差距。而这仅仅发生在一次学习课程之后。将此推演至一年的日常 AI 辅助使用,你就能理解,为何几家公司的资深工程师悄悄反映,团队推理复杂问题的方式已悄然改变。

AI 工具带来的技能萎缩问题是真实存在的,可以量化的,且对中级工程师的冲击最为显著。以下是研究所揭示的规律,以及你可以采取的应对措施。

感知偏差是第一个预警信号

在讨论哪些能力正在退化之前,有必要先明确一点:大多数工程师对此毫无察觉。

一项针对 16 名经验丰富的开发者的研究——他们平均在同一成熟开源项目上工作了五年——分别测量了有无 AI 辅助时的实际任务完成时间。开发者预测自己使用 AI 后会快 24%,完成每项任务后自评快了 20%,而客观测量结果却是慢了 19%。

感知表现与实际表现之间存在 40 个百分点的差距。而这些都是在自己熟悉的代码库上工作多年的资深工程师,并非在陌生领域摸索的初学者。

这种感知偏差从结构上来说极具危险性。如果你感觉越来越快,实际上却越来越慢,你就没有任何内部信号可以用来自我纠偏。你会更加依赖 AI,加速底层技能的退化,同时感觉愈发自信。

航空业数十年前就发现了同样的规律。当长途自动驾驶仪成为标准配置后,飞行员的手动飞行时间减少了。法航的内部调查发现,机组人员普遍出现"常识和通用飞行知识的丧失"。当 AF447 的自动驾驶仪在 38,000 英尺高空断开时,那些多年来每月手动飞行不足几小时的飞行员无力恢复控制。他们需要的手动技能已经萎缩,而自动化系统将这一切掩盖得严严实实——直到它断开的那一刻。

哪些技能正在退化(以及为何难以察觉)

Anthropic 研究的细节至关重要,因为它表明退化恰恰集中在对资深工程师最为关键的技能上。

理解差距在所有问题类型中均有体现,但在调试方面最为突出。这在机制上合情合理:当你使用 AI 修复错误时,你打断了"遭遇错误—诊断—解决"这一构建调试直觉的循环。错误仍然被修复了——甚至更快——但通过亲历并克服错误所获得的学习并未发生。对照组参与者每次课程平均遭遇三个错误,AI 使用者只遇到一个。对照组那些"额外"的错误,正是在 AI 使用者身上从未发生的认知工作。

2026 年一项针对开发者的调查印证了这一规律在生产环境中的存在。96% 的开发者表示不完全信任 AI 生成的代码,但只有 48% 的人表示在提交前始终会验证代码。与此同时,AI 已占已提交代码的 42%,预计到 2027 年将达到 65%。这种在宣称的怀疑态度与实际行为之间的落差,正是技能萎缩引擎全速运转的驱动力:工程师知道应该更仔细地审查,但审查能力恰恰是在不独立练习时最难维持的技能。

系统设计呈现出不同但相关的模式。当 AI 随时可用时,工程师倾向于在 AI 建议的基础上迭代,而非从第一原则出发进行综合推演。随着时间推移,在没有初始脚手架的情况下从约束条件推演到架构设计的能力逐渐弱化。工作从综合推演转向评估,而对看似合理的 AI 输出进行评估,所需的专业判断力甚至比综合推演更强,而非更弱。

微软研究院针对 319 名知识工作者的调查(在 CHI 2025 上发表)发现,对 AI 工具的信心越高,批判性思维反而越少;而自信心越强,批判性思维则越多。这其中的讽刺是结构性的:AI 通过出色地处理常规任务,消除了那些本可培养专家判断力的练习机会。常规,恰恰是训练场。

为何中级工程师最易暴露于风险之中

初级工程师同样面临风险,但有一个特定原因使中级工程师——大约工作了五到十五年的人——面临复合性问题。

他们有足够的能力有效地使用 AI。他们具备足够的领域熟悉度,使 AI 工具真正发挥作用,并拥有足够的项目背景知识,能将 AI 引导到富有成效的方向。这意味着他们委托给 AI 的工作更多,且质量更高,超过了初级工程师的水平。

但他们还没有积累足够长时间来形成强大的元认知验证能力——即面对一个看似合理的 AI 输出,能够从系统设计权衡的层面自信地评估它,而非仅从语法层面。这种能力需要多年亲历第一原则决策并观察其下游影响才能积累。如果过去两三年的练习窗口被 AI 辅助的捷径所填满,这种能力就没能以应有的方式发展。

这造成了一种特定的失败模式:中级工程师在审查 AI 生成的代码时感到自信,因为代码看起来正确,而他们有足够的经验辨别出"正确的样子"。但他们已失去了一部分深层推理能力——即思考"为什么"是正确的那种推理——这种推理能够捕捉架构错误、微妙的安全漏洞,以及那些不会以明显方式暴露自身的集成问题。

组织维度使情况更加严峻。2026 年一项关于 AI 采用激励机制的分析发现,时间视野较短的管理者比着眼于自身十年职业轨迹的员工更倾向于推动更高的 AI 使用率。短期生产力信号(AI 输出看起来既快又整洁)压过了长期能力信号(团队独立推理能力正在下降)。中级工程师恰好处于管理层压力最大、自身对技能退化感知最低的区间。

一项分析对 AI 依赖导致的技能恢复轨迹进行了建模,在典型的学习与遗忘速率下,估计恢复半衰期约为 2.3 年。这并非危言耸听——它意味着技能恢复是可能的——但确实意味着,如果你在两年内将诊断工作大量委托给 AI,在不进行刻意练习的情况下,恢复到之前的基线水平所需的时间,大约与退化所花的时间相当。

哪些交互模式预示着最大的风险

Anthropic 的研究识别出工程师使用 AI 辅助的六种截然不同的方式,这些模式与理解能力结果高度相关:

高绩效交互模式:

  • 概念性询问 — 仅向 AI 提问概念性问题,独立解决错误(测验得分 65–86%)
  • 生成后理解 — 生成代码后,在继续之前提出跟进问题以理解代码
  • 代码与解释混合 — 同时请求解释与代码,而非仅索取代码

低绩效交互模式:

  • AI 委托 — 完全依赖生成的代码,几乎不进行独立推理(测验得分 24–39%)
  • 渐进式依赖 — 随着课程的进行,逐渐将更多工作交给 AI
  • 迭代调试 — 使用 AI 来解决问题,而非厘清问题

高低模式之间的理解能力差距约为 40 个百分点。交互模式——而非仅仅是否使用 AI——决定了技能是提升还是退化。

维持专家判断力的工作流模式

研究指向了一套保持技能敏锐度同时使用 AI 工具的一致性设计原则。

先尝试,再求助。 在咨询 AI 之前,先独立处理问题 15–30 分钟。挣扎本身——那些走入死胡同、重新表述问题的过程——正是构建持久理解的认知工作。这不是为了低效而低效;而是在解决问题的初期阶段将时间用于刻意练习,然后再借助 AI 加速。

要求解释。 当 AI 生成代码时,不要仅仅检查其正确性——要求解释它为什么有效、它基于哪些假设,以及什么情况下会出错。"如果输入为空会怎样"或"为什么选择这个数据结构而不是 X"这样的问题,迫使人进行主动推理而非被动接受。

在验证点引入摩擦。 MIT/埃森哲的一项研究发现,添加定向摩擦——要求用户在接受 AI 输出之前停下来并高亮特定部分——在不显著增加时间成本的情况下,大幅提升了错误检测率。适度摩擦的效果优于零摩擦和高摩擦两种情况。最优设计既不是"信任 AI",也不是"不信任 AI"——而是在关键时刻激活批判性审视的结构化提示。

设置无 AI 练习窗口。 定期进行无辅助工作的练习——不用自动补全调试、从零开始设计系统而不借助 AI 脚手架、不用 AI 解释阅读陌生代码——其作用如同体能锻炼中的力量训练。这些技能不会被动地保持敏锐;它们需要激活。

诊断日志。 记录你经常向 AI 求助的问题类型。如果这个清单持续扩大——比如六个月前你还能自如地阅读堆栈跟踪,而现在却先去找 AI——这是技能萎缩模式的领先指标。日志让漂移在变得严重之前变得可见。

产品设计维度

这不仅仅是个人行为问题。AI 工具本身的设计,可以加速或减缓技能退化。

那些只呈现单一自信答案而不展示推理链的工具,会加速委托和萎缩。那些展示推理步骤、呈现不确定性,或在揭示答案前要求用户先作出预测的工具,则能激活更多的元认知肌肉。

基于交互模式证据,最优的 AI 编程工作流更像结对编程而非自动补全:工程师定义问题,AI 提供候选方案,工程师质疑方案并识别边界情况,AI 回应约束条件,工程师作出最终架构决策。这种工作流能维持技能,因为工程师始终在进行综合推演与评估。"只管接受建议"的模式,才是导致退化的那个。

关心长期工程能力——而非仅仅关心季度速度——的团队,应该审视自己的 AI 工具配置实际上在鼓励什么行为。如果默认工作流是几乎没有审查摩擦的委托模式,那你是在用未来的能力换取当前的产出,而这笔账在任何仪表板上都不会显现。

现在可以做什么

证据指向了一些值得立即推行的具体改变:

对于个人工程师:追踪你一周内的 AI 交互模式。记录每一次你要求 AI 解决问题与厘清问题的时间。如果解决与厘清的比例超过 70/30,你就处于预示理解能力下降的委托区间。转向厘清模式和先尝试默认行为。

对于工程负责人:停止将 AI 采用率作为生产力的代理指标。衡量团队在没有 AI 辅助时解决复杂问题的能力——通过代码审查、架构会议、调试复盘。如果这些能力在 AI 采用率上升的同时下降,你面临的是一个领先指标问题,产出数字要等到代价高昂时才会反映出来。

对于工具设计者:维持专家判断力的模型,需要刻意抵制阻力最小路径的设计选择。如果最简单的工作流是纯粹的委托,那就是用户会采用的方式。添加解释要求,呈现不确定性,并为工程师的长期能力而设计,而非仅仅为即时会话的输出而设计。

三年后最有价值的工程师,不是那些使用 AI 最多的人。而是那些以保持独立推理能力敏锐的方式使用 AI 的人——以及那些因持续练习支撑验证意义的底层技能,而能自信地验证 AI 输出的人。

萎缩是悄无声息的。恢复是刻意为之的。

References:Let's stay in touch and Follow me for more thoughts and updates