AI 采用率断崖：为什么资深用户最先关掉 AI 功能

2025 年初，METR 组织了一项研究，邀请 16 名经验丰富的开源开发者使用他们惯用的 AI 编程工具完成真实的 GitHub 问题。结果令人意外：他们比没有使用 AI 的对照组慢了 19%。更令人震惊的是，这些开发者自我估计快了 20%。感知与现实之间的落差接近 40 个百分点。

这并非孤例。跨公司、跨工具、跨级别，一种规律正在浮现：最有能力评估 AI 的工程师，也是最可能关掉它的人。

关于 AI 工具的惯常叙事是一条采用曲线——随着工具成熟，怀疑者会变为信徒。AI 采用率断崖恰恰相反：资深用户最先到达、投入最深、退出也最快。理解这背后的原因，对正在经历这一现象的工程师和开发工具的团队都至关重要。

生产力悖论的实际表现

METR 的结果最初令人费解。参与研究的不是 AI 怀疑论者——他们来自主流开源项目，对自己的代码库有深厚的上下文积累。然而整组人普遍变慢，即便参与者自我感觉效率更高。

研究者追踪了时间损耗的去向：

• 在 AI 工具界面与实际代码库导航之间频繁切换
• 阅读、核验和修正 AI 生成的代码（看似合理，却常常引入微妙的回归缺陷）
• 提示词工程的额外开销——为了获得可用输出，需要解释大量上下文
• 生成后的清理工作：重新格式化、去重、补充文档

研究中只有一位开发者实现了预期的生产力提升——速度提升了 38%——而他在 Cursor 上专门投入了超过 50 小时。在复杂的、长期维护的代码库中从 AI 获益，其学习曲线是以数十小时计的，而非几天。

PR 审查数据从另一个角度印证了这一点。在使用 AI 编程助手的团队研究中，开发者完成的任务数量增加了 21%——但 PR 审查时间增加了 91%。吞吐量上升了，实际交付速度却没有。瓶颈从写代码转移到了有经验的工程师无法跳过的人工审查环节。

为什么专家最先选择退出

新手和专家使用 AI 工具的方式截然不同，而这些工具大多是为新手优化的。

对初级开发者来说，AI 自动补全是加法。它填补了知识空白，提供了尚未记住的模式，加速了原本需要查文档的工作。错误输出的代价有限——他们本来也不处于做高影响力架构决策的位置。

对高级开发者来说，这个算法反转了。他们已经有了模式库，已经知道该怎么做。他们需要的不是生成，而是执行。而在复杂代码库中执行，需要的上下文很难通过提示词传递给 AI。

专家的额外负担是核验。每一个 AI 输出都产生一个审查义务。专家有足够的品味判断哪里不对，也有足够的警惕性去检查。这种核验税——施加在每一个建议、每一次补全、每一个生成的测试上——最终会积累到不可忽视的量级。

一位记录了构建 15 万行 AI 生成代码全程的高级开发者发现自己反复运行 git reset 来放弃整个会话。代码在语法上是正确的，功能上也看似合理——但在架构上是不连贯的。他把推理能力托付了出去，而不只是打字。

技能退化是更长远的风险

除了生产力，有经验的工程师还担忧一件更难量化的事：不自己动手，他们在失去什么。

Anthropic 自己关于 AI 辅助与编程技能的研究发现了一个惊人的差距。在一项随机对照试验中，使用 AI 的开发者在理解力测验中得分为 50%，而手写代码的开发者得分为 67%——相差近两个字母等级。差距最大的地方在于调试：识别代码何时出错以及原因。

这是一项具体而重要的能力。调试需要在脑中构建执行的心智模型，保持中间状态，对故障模式进行推理。这恰恰是 AI 所卸载的那种推理——也恰恰是停止练习后会退化的那种能力。

自动化悖论会随时间加剧这一效应。当 AI 工具 99% 的时候是正确的，人类就会停止仔细检查。捕捉那 1% 的能力——在软件中，这往往表现为看似合理但语义错误的输出——会因为不用而退化。高级开发者理解这种动态，很多人认为这个风险不值得承担。

自动化偏见不放过专家

一个常见的假设是，专业知识能防止自动化偏见——有经验的从业者会发现新手忽略的 AI 错误。但研究给出了更复杂的答案。

在医疗 AI 决策支持的研究中，即便是非常有经验的放射科医生和病理学家也表现出可测量的自动化偏见。他们接受了与自己先验判断相符的 AI 建议，而抵制那些与直觉相悖的建议。专业知识没有消除偏见，只是通过先验判断对其进行了过滤。一个与看似合理案例恰好吻合的、自信地给出错误建议的 AI，依然是危险的。

对工程师来说，这对应于一种具体的失效模式：AI 生成的代码与你对解决方案的第一直觉相符，但在你没有考虑到的边缘情况中包含了微妙的 bug。专业知识缩小了 AI 出错的搜索空间，但并未关闭它。

有经验的用户真正需要什么

能够留住专家用户的工具，具备一些大多数 AI 功能默认缺失的特性。

关于不确定性的透明度。 专家用户不希望 AI 展现它并不具备的自信。他们想要信号——哪里是模型在外推，哪里上下文稀薄，哪里的输出应该接受更仔细的审查。一个写着"我在猜测这里的预期行为"的补全，对高级工程师来说比一个自信地给出错误答案的补全更有价值。

对自主程度的实质性控制。 "AI 开/AI 关"这种二元选项没有用。专家想要校准——对模板代码和测试脚手架给予高自主度，对核心业务逻辑给予低自主度。提供自主度调节器、让用户按任务类型设置阈值的工具，比全有或全无的默认设置更能留住专家用户。

审计追踪与撤销。 专家与 AI 的关系在有建设性的意义上是对抗性的——他们在寻找错误。按时间顺序记录 AI 操作、并支持逐步回滚的日志，恰好支持这种积极的怀疑主义。没有它，接受 AI 建议就像信任一个黑盒，而有经验的工程师不信任黑盒。

可解释的理由。 当 AI 做出选择——选择某种方案而非另一种、省略某个考量、重新排列逻辑——专家想知道为什么。"我选择 X 是因为你的代码库一贯使用模式 Y"是可审查的。"这是代码"则不然。

隐私与数据控制。 专家开发者是会阅读服务条款的人。当 AI 工具改变数据训练默认设置——正如 GitHub 在 2025 年 4 月对 Copilot 交互数据所做的——有经验的工程师会注意到，在内部标记它，并绕开它。透明的、按仓库设置的数据控制对资深用户来说不是锦上添花，而是先决条件。

设计启示

Notion 的 AI 采用故事提供了一个有用的框架。Notion AI 在第一周内达到了 90% 的用户采用率，不是因为 AI 比其他工具好多少，而是因为集成方式。AI 命令存在于熟悉的斜杠菜单中——不是独立的工具，不是插件，而是编织进专家已经有肌肉记忆的界面里。定制深度足够，专业人员可以让它适应自己的工作流，而不必让工作流去适应 AI。

那些在专家用户中失败的产品，倾向于为演示体验优化：在干净输入上快速、令人印象深刻的输出。那些在专家用户中成功的产品，则为协作体验优化：渐进式、可控、可解释、可逆。

专家从糟糕的 AI 输出中失去的东西比新手更多。他们有更多上下文需要核验，有更多系统依赖他们的判断，有更多 AI 无法复制的积累品味。那些承认这一点的工具——将专家参与视为对抗性审查而非无摩擦接受——最终会吸引到做最有趣工作的用户。

展望

AI 采用率断崖并非不可避免。它是一种产品失效模式，而非技术的根本局限。

突破它的路径是为房间里最怀疑、最有能力的用户设计 AI 功能，而不是最轻信的那位。这意味着对信心的透明度、对范围的实质性控制、对每项操作的审计机制，以及明确的隐私保障。这意味着将专家的抵制视为信号，而非抗拒变革。

METR 研究中 19% 的速度下降不是反对 AI 工具的论据。它是以不同方式构建它们的论据——让收益流向最有能力提取它的人，而不是最不可能注意到代价的人。