AI 写代码越多，开发者反而越忙？硅谷开始反思“Token 崇拜”

如果你这两年常看程序员社区，大概会发现一种新型炫耀方式：不是晒键盘，不是晒工位，也不是晒年包，而是晒自己的 AI token 配额。

谁能一口气跑更多 Claude Code、Cursor、Codex，谁就像拿到了新时代的“无限续杯券”。在不少团队里，token 预算甚至成了某种身份象征：预算大，意味着你被信任、被重视、也更“先进”。但问题是，开发效率这件事，从来都不是靠烧预算烧出来的。

TechCrunch 最新一篇报道把这种现象命名为“Tokenmaxxing”——你可以把它理解成“把 token 用到极致”的工作文化。这个词听上去很互联网，也很硅谷，但它背后指向的，其实是一个老问题：当工具越来越强，我们到底该用什么来衡量效率？

代码在暴涨，价值却没有同步增长

管理学里有句老话：你衡量什么，就会得到什么。软件行业对这句话的体会尤其深。早年大家迷信“代码行数”，后来发现代码写得越多，不一定系统越好，反而可能只是 bug 越多。今天，AI 编程时代把这个问题重新包装了一遍：代码行数被 token 消耗量和 PR 数量取代了。

表面上看，AI 编程工具确实很能打。开发者借助 Claude Code、Cursor、Codex 这样的工具，产出速度明显提升，提交的代码更多，Pull Request 也更多。对老板来说，这些数字非常诱人：周报更好看，仪表盘更热闹，团队似乎正在“火力全开”。

可真正的麻烦出现在几周之后。Waydev 这家做开发者效能分析的公司发现，很多工程团队看到的 AI 代码接受率高达 80% 到 90%，也就是开发者当下会把大部分 AI 生成的代码收进去。但如果把时间线拉长，去看这些代码后来有没有被大面积修改、重写、删除，所谓“真实接受率”会掉到 10% 到 30%。

这就很像装修时为了赶工，先把墙刷白、灯装上、柜子摆好，拍照时非常像样；可住进去两周才发现，插座位置不对，柜门老卡住，水管还有点漏。看起来是完工了，实际上只是把返工推迟了。

AI 没有偷懒，它只是把“写代码”变成了“改代码”

这件事为什么重要？因为它正在改变开发工作的重心。过去工程师最痛苦的环节，往往是从零开始写；现在很多人最痛苦的，反而是接住 AI 疯狂吐出来的东西，再一点点辨认哪些能留、哪些该删、哪些会在三个月后炸雷。

GitClear 在今年 1 月的一份报告里提到，常规使用 AI 编程工具的开发者，代码 churn——也就是新增代码中后来被删除、修改的比例——平均是非 AI 用户的 9.4 倍。这个数字非常刺眼。因为它意味着 AI 并不是简单把人类工作量减少了一半，而是在很多场景下，把“创作成本”转移成了“维护成本”。

Faros AI 的数据更夸张：在高强度采用 AI 编程工具的团队中，代码 churn 增长了 861%。Jellyfish 则统计了 2026 年第一季度 7548 名工程师的数据，结论同样耐人寻味：token 预算最大的工程师，确实提交了最多 PR，但生产效率并没有等比例提升——他们大约获得了 2 倍吞吐量，却花掉了 10 倍 token 成本。

翻成大白话就是：AI 能让代码像自来水一样流出来，但流出来的未必都是能喝的水。

更微妙的是，这种“高产幻觉”特别容易误导管理层。因为 PR 数、提交量、代码生成量都属于非常容易被量化和展示的指标，而代码质量、架构一致性、长期可维护性、技术债积累速度，则通常要等上线后、迭代后，甚至事故后才会露出真相。很多团队正在经历一种典型的 AI 时代错觉：仪表盘越来越漂亮，工程系统却越来越难碰。

初级工程师最兴奋，也可能最容易掉坑里

和不少开发者聊过类似工具的人，大概都能感受到一个分化趋势：资深工程师对 AI 更像“带着戒心地使用”，初级工程师则更容易“先收下再说”。

这并不奇怪。越资深的人，越知道一段代码的问题不只在语法正确，而在边界条件、性能约束、历史包袱、团队约定和系统上下文。AI 最擅长补全局部任务，却未必真正理解一个大系统为什么会长成今天这样。于是，经验越少的人，越容易把“能跑”误当成“靠谱”。

这也解释了为什么很多团队最近一边高喊 AI 提效，一边又在抱怨代码评审变得更累。以前 review 是看同事的思路，现在常常变成在一大堆“看起来像那么回事”的 AI 代码里找隐藏问题。你很难一眼看出它错在哪，因为它通常不是离谱到不能运行，而是微妙地不符合系统设计、测试策略或未来扩展方向。

从这个角度看，AI 编程并没有消灭工程判断力，反而让判断力变得更贵了。真正稀缺的，不再是“会写代码的人”，而是“知道哪些代码不该被写进去的人”。

硅谷开始买“度量工具”，说明焦虑已经很真实

一个很有意思的信号是，围绕“开发者生产力洞察”的创业公司正在升温。Waydev、GitClear、Faros AI、Jellyfish 这类公司都在做同一件事：帮企业看清 AI 编程到底有没有创造真实价值，而不是只制造更热闹的数字。

Atlassian 去年用 10 亿美元收购工程智能公司 DX，也说明大公司已经意识到，问题不在于要不要上 AI，而在于怎么证明这笔钱花得值。毕竟 AI coding agent 不是免费插件，它背后是实打实的 token 成本、云算力成本、审查成本，以及最容易被忽略的返工成本。

这让我想到 SaaS 行业早年的一个共同教训：一个工具只要足够新，企业最初看重的总是“有没有用上”；等热潮退去，真正被追问的才是“有没有 ROI”。今天的 AI 编程也一样。部署很容易，停下来思考很难。因为没有哪家公司愿意承认自己在 AI 竞赛里慢了半拍，于是大家先上车，再在车上找刹车。

但这类分析平台也有自己的局限。它们天然会强调问题，因为问题越尖锐，客户越愿意为“洞察”付费。所以看这些报告时也要保持冷静：AI 编程并非无效，更不是一场注定失败的泡沫。它的问题更像是，人们太急着把它当作效率机器，却忘了软件开发本质上是一个长期主义行业。

真正该衡量的，不是 token，而是“留下来的代码”

我觉得这轮讨论里最关键的一点，不是 AI 会不会取代程序员，而是公司会不会被错误指标带偏。

如果一个团队今天把“每周消耗多少 token”“生成了多少代码”“开了多少 PR”当成核心绩效，那它几乎必然会鼓励更多表面繁荣。工程师会更倾向于让 AI 大量生成、快速合并，先把数字做上去，至于后面谁来擦屁股，往往是未来的自己，或者倒霉的同事。

真正更有意义的指标，可能恰恰是那些不那么性感的数据：三周后还存活的代码比例，AI 生成代码在事故工单中的占比，重构频率，review 时间，单个功能从需求到稳定上线的完整周期，甚至是开发者主观疲惫度。因为软件开发不是短跑，它更像维护一座城市的地下管网。你今天铺得再快，明天漏水也得你来修。

这件事在 2026 年尤其值得看，因为 AI 编程工具已经从“尝鲜阶段”进入“组织化部署阶段”。当个体开发者偶尔用 AI 写个脚本，返工代价还有限；当成千上万名工程师在企业内部用 agent 持续产出代码，任何一点微小的质量滑坡，都会被放大成昂贵的系统性成本。

所以，“Tokenmaxxing”真正暴露的，不是开发者爱炫技，而是整个行业还没学会如何和一个极其高产、却不总是可靠的搭档共事。AI 很可能已经成为软件开发的新基础设施，但基础设施的价值，从来不靠吞吐量单独定义，而要看它能否稳定、可控、可持续地服务业务。

硅谷现在的处境有点像刚拿到一台超大马力跑车，油门踩下去的那一刻当然爽，可如果方向盘、刹车和仪表盘都还没调好，开得越快，未必离目的地越近。