程序员拒绝不用 AI 工作：Tokenmaxxing 的泡沫与隐忧

原文来源：TechCrunch — Coders are refusing to work without AI — and that could come back to bite them — TechCrunch 记者 Julie Bort 报道了 2026 年 AI 编程的一个怪现状：开发者已无法离开 AI 工作，而 Tokenmaxxing 的泡沫正在破裂。

开发者拒绝"无 AI"实验

2026 年的一个发现令人警醒：你几乎无法让开发者关掉 AI 编程工具来工作了。

这不是谁的推测，而是来自知名 AI 研究机构METR的真实经历。2025 年，METR 发布了一项标志性研究，测量开源开发者用"手工"和"AI"完成相同任务的时间差。结果出人意料：开发者觉得 AI 让自己更高效了，但实际测量显示AI 反而拖慢了他们的速度——AI 确实更快地生成了代码，但开发者花了额外的时间来发现和修复错误、纠正 AI 的方向，以及等待它完成任务。

当 METR 在 2026 年希望复现这个实验来测试新进展时，他们遇到了一个尴尬的情况：**找不到志愿者了。**开发者"不愿意参与，因为他们不希望在工作时没有 AI"——即使只是为了一项研究。

METR 最终只好转为发布调查报告，让技术人员自行评估 AI 对生产力的影响。不出所料，大多数人认为 AI 让他们的价值翻了一倍。

Tokenmaxxing：2026 年的新泡沫

但这种自我感知和一个正在破裂的行业趋势形成了鲜明对比——Tokenmaxxing。

Tokenmaxxing 是 2026 年最热门的"生产力指标"：用一个人消耗的 token 数量来衡量其 AI 使用效率和产出。但这个指标正在引发严重的会计问题。

亚马逊已经关闭了内部的 token 追踪排行榜 Kirorank。原因？员工们通过滥用 AI Agent来刷排名，疯狂消耗 token，导致成本飙升。《金融时报》报道称，这些员工用自己的行为证明了——消耗 tokens 多并不等于产出高。

Uber的情况更触目惊心。Uber 在 2026 年前四个月就烧光了全年的 AI 预算。COO Andrew Macdonald 在播客中坦言：这并没有带来可衡量的项目增长或生产力提升。

AI 生成代码的维护成本黑洞

AI 写代码很快，但维护成本呢？

著名程序员和敏捷方法论专家 James Shore 在 Hacker News 上爆火的分析文章给出了一个数学模型。他的核心发现是：

你写代码快了两倍？你最好希望维护成本也砍半了。否则你就麻烦了——你在拿短期的速度提升换永久的债务。

这不是孤例。AI 可靠性工程公司 Entelligence AI 的 CEO Aiswarya Sankar 在 X 上分享了一个令人震惊的数据：企业平均把 44% 的 token 花在修复 AI 生成的 bug 上。

代码审查工具公司 CodeRabbit 分析了开源项目的 PR 后发现，AI 代码产生的问题比人类代码多 1.7 倍。（虽然这些数据来自卖 AI 审查工具的公司，但独立研究也支持同样的结论。）

新加坡管理大学在 2026 年 4 月发表的一篇研究报告警告说："AI 生成的代码会给真实的软件项目引入长期的维护成本。"

是什么在驱动这一切？

这个悖论的根源在于：AI 编程工具确实让"写代码"这个环节变快了，但软件工程的瓶颈从来不在"打字速度"上。

AI 让开发者可以更快地产出代码，但这会导致几个连锁问题：

1. 代码审查过载——PR 数量爆炸，开发者没有足够精力去认真审查每一行 AI 代码
2. 质量下降——评审质量下降，更多有问题的代码被合并到主分支
3. 维护压力倍增——低质量代码的积累让未来的每一次改动都更加困难
4. 技术债务加速——原本需要几年积累的技术债务，现在几个月就堆上来了

各方给出的"解药"

面对这个困局，不同玩家给出了不同的答案：

**Cognition（Devin 的开发公司）**的创始人 Scott Wu 认为：开发者应该继续用 AI 编程，但同时用 AI Agent 来做修复代码的苦力活。不过他承认，当前 Devin 的能力介于初级和中级程序员之间——"不是放手不管就能解决的事情"。

新加坡管理大学的研究者给出了更人性化的建议：程序员需要像了解自己最爱的编程语言一样深入了解 AI 擅长什么、不擅长什么。他们需要为 AI 建立严格的质量保障体系，并像对待初级开发者一样仔细审查 AI 的产出。同时，架构设计、安全规划这些"大局观"工作，仍然应该由人类把控。

对独立开发者的启示

这篇文章指向一个核心提醒：AI 工具的效率不是由"写代码的速度"决定的，而是由"写完代码后的总成本"决定的。

对于独立开发者来说，这意味着：

• 不要用 token 消耗量来衡量自己的效率——那是虚荣指标
• AI 适合做探索性编程和原型验证，但核心代码的质量把关不能省
• 在评估 AI 工具时，优先考虑那些能帮你降低维护负担的，而不是单纯增加代码产出的
• 每月复盘一下自己的时间分配：有多少是花在修复 AI 生成的 bug 上？如果超过了 30%，说明 AI 的使用策略需要调整

2026 的 AI 编程工具已经发展到不可或缺的地步，但关键是学会和它共处的方式——不是更快地堆代码，而是更聪明地管理由它带来的技术债务。