程序员拒绝脱离 AI 工作，但这可能成为他们的“阿喀琉斯之踵”

背景

2026 年，AI 编程工具已经深度嵌入开发者的工作流中，甚至形成了某种“刚性依赖”。近期，AI 研究机构 METR 试图重复 2025 年关于 AI 编程生产力的开创性研究，却遭遇了一个意想不到的障碍：绝大多数开发者拒绝参与不需要使用 AI 的实验任务。

这一现象揭示了一个严峻的现实：虽然 AI 显著提升了代码生成的速度，但其对代码质量、长期维护成本以及企业实际产出的影响仍存巨大争议。与此同时，行业内出现的“Tokenmaxxing”（以 Token 消耗量作为生产力指标）趋势及其带来的高昂成本，正在让企业和开发者重新审视 AI 的真实价值。

核心内容

1. METR 研究的困境与发现

2026 年 2 月，备受尊敬的 AI 研究机构 METR 发表了一项令人惊讶的调查结果：大多数开发者已无法在没有 AI 辅助的情况下工作，即使是仅涉及少量任务的有限实验也不例外。

METR 原本希望更新 2025 年发布的一项关于 AI 编程生产力的研究。在那项早期研究中，研究人员对比了开源开发者手动完成任务与使用 AI 完成任务所需的时间。虽然开发者自述 AI 提高了他们的生产力，但数据却显示相反的结果：尽管 AI 生成代码的速度更快，但开发者花费了大量额外时间去查找错误、修复 Bug、引导 AI 以及等待任务完成，最终导致整体效率反而下降。

当 METR 试图在 2026 年重复该实验以衡量 AI 进步和程序员熟练度的变化时，他们发现实验无法进行。研究人员坦言，开发者不愿参与，因为他们“不希望在不使用 AI 的情况下工作”，哪怕只是为了参与研究。

2. 自我感知的偏差与“Tokenmaxxing”泡沫

由于无法进行受控实验，METR 于 2026 年 5 月发布了一份调查，允许技术员工自我报告 AI 带来的生产力提升。不出所料，受访者普遍认为 AI 使他们为组织创造的价值翻了一番。

然而，这种自我感知正受到近期数据和新闻的挑战。2026 年初，“Tokenmaxxing”成为行业趋势，即企业和个人将 AI 使用的 Token 数量作为生产力的代理指标。但这股热潮可能已经走向反面：

• Amazon 的案例：据《金融时报》报道，Amazon 关闭了其内部名为 Kirorank 的 Token 追踪排行榜。原因是员工通过过度使用 AI 代理来刷高数据，导致成本飙升。这证明 AI 的使用并不自动转化为生产力的提升。
• Uber 的案例：据 The Information 报道，Uber 在 2026 年的前四个月内就耗尽了全年的 AI 预算。其首席运营官 Andrew Macdonald 最近在播客中表示，这种支出并未带来项目数量或生产力的可测量增长。

3. 代码维护成本的隐形陷阱

AI 生成的代码并不一定减少，甚至可能增加长期的代码维护需求。程序员兼作家 James Shore 在 Hacker News 上引发热议的博客文章中精辟地指出：“如果你现在写代码的速度快了一倍，最好希望你的维护成本减半。否则，你就完了。你是在用暂时的速度提升换取永久的奴役。”

其他证据也支持这一观点：

• Entelligence AI 创始人兼 CEO Aiswarya Sankar 在推特上指出，公司花费了 44% 的 Token 用于修复由 AI 生成的 Bug。
• 代码审查工具公司 Code Rabbit 分析开源 Pull Requests 后发现，AI 产生的问题数量是人工代码的 1.7 倍。

尽管上述数据来自试图销售 AI 代码审查工具的公司，可能存在自利嫌疑，但独立研究也证实了类似问题。2026 年 4 月，新加坡管理大学（SMU）的研究人员发布报告警告称：“AI 生成的代码可能会给现实软件项目引入长期的维护成本。”

4. 解决方案：人机协作的新范式

面对程序员对 AI 助手的依赖以及随之而来的维护难题，业界提出了不同的解决思路：

• AI 代理修复论：以 Cognition 创始人兼 CEO Scott Wu（AI 编程代理 Devin 的创造者）为代表的支持者认为，开发者可以使用 AI 编程代理来快速修复代码，速度应与 AI 生成代码的速度相匹配。然而，Wu 也承认，尽管 Devin 可以独立工作，但其技能水平仅相当于初级到中级程序员，具体取决于任务类型。因此，这并非一个可以“甩手不管”的解决方案。
• 人类主导的质量控制：SMU 研究人员提出了更具人文色彩的建议。程序员应像熟悉自己最爱的编程语言一样，深入理解 AI 擅长和不擅长的任务。企业需要建立专为 AI 设计的质量保证系统，并像审查初级开发人员的工作一样，仔细审查 AI 的输出。
• 人类的核心价值：研究人员和 Wu 均同意，人类仍应专注于宏观层面的工作，如软件架构和安全设计。

关键要点

• 依赖性固化：到 2026 年，大多数开发者已无法脱离 AI 工作，甚至拒绝参与无 AI 的实验，显示出对 AI 工具的刚性依赖。
• 生产力悖论：虽然 AI 加快了代码生成速度，但额外的调试、引导和等待时间可能导致整体效率下降，早期研究已证实这一点。
• Token 指标失效：“Tokenmaxxing”作为生产力指标已被证明是误导性的。Amazon 和 Uber 的案例显示，高 Token 消耗并未带来相应的生产力提升，反而造成了巨大的预算浪费。
• 维护成本激增：AI 生成的代码可能引入更多 Bug 和长期维护负担。数据显示，大量 Token 被用于修复 AI 自身产生的错误，且 AI 代码的问题密度高于人工代码。
• 角色重新定位：AI 目前相当于初级到中级程序员，无法完全替代人类。开发者需转变为“审查者”和“架构师”，建立针对 AI 代码的质量保证流程，并专注于软件架构和安全设计等高价值工作。

意义与影响

这一趋势标志着 AI 在软件开发领域的应用正从“盲目追求速度”转向“理性评估价值”。对于企业和开发者而言，单纯堆砌 AI 使用量已不再是提升竞争力的有效手段。

对企业而言，必须重新评估 AI 投资的 ROI（投资回报率）。停止将 Token 消耗量作为 KPI，转而关注代码质量、维护成本和实际交付价值。建立严格的 AI 代码审查机制和质量保证体系，是避免陷入“技术债”陷阱的关键。

对开发者而言，核心竞争力正在发生转移。单纯的编码速度优势正在被 AI 抹平，未来的价值在于对 AI 输出的批判性审查、系统架构设计以及解决复杂问题的能力。开发者需要像管理初级员工一样管理 AI 代理，既要利用其效率，又要承担最终的质量责任。

对行业而言，AI 编程工具的市场将经历洗牌。那些仅能提供代码生成而缺乏质量保障、安全审计和架构辅助能力的工具将面临淘汰。能够集成高质量审查、自动化测试和架构建议的综合型 AI 开发平台将成为主流。

总之，AI 并未让程序员“失业”，但正在重塑他们的职责。拒绝 AI 已不可能，但盲目依赖 AI 同样危险。未来的成功属于那些能够驾驭 AI 而非被 AI 驾驭的团队。