AI 程式設計工具普及了兩年，有一種現象開始浮出水面：有些團隊的程式碼提交量翻倍了，產品交付沒有變快，bug 卻變多了。
TechCrunch 最近報導了一個詞：Tokenmaxxing。意思是，開發者開始把 AI 工具的 token 預算當成一種身份標誌——誰的 token 配額越大，誰就越 productive。但數據說的是另一回事。
Token 越多，程式碼刪得越快
先看數字：
- GitClear 2026 年 1 月：使用 AI 工具的開發者程式碼 churn（刪改量／新增量）是不用 AI 的同事的 9.4 倍
- Faros AI 2026 年 3 月：分析兩年客戶數據，高 AI 採用率下程式碼 churn 增加了 861%
- Jellyfish Q1 2026：token 預算最大的工程師，吞吐量是普通人的 2 倍，但成本高達 10 倍
這不是說 AI 工具沒用。而是說，那些被計入「生產力提升」的大量程式碼，很多都活不過幾週。
80% 接受率背後的真相
工程師平均會接受 AI 生成程式碼的 80%-90%，這個數字看起來很高，被很多公司當成「AI ROI」的核心指標。
但 Waydev 的 CEO Alex Circei 對 50 多家企業、超過一萬名工程師的數據做了追蹤分析，發現了一個規律：
初始接受率是 80-90%，但幾週後再看，真正留下來的程式碼只有 10-30%。
也就是說，工程師按下「接受」，不代表這段程式碼真的有用。大量 AI 生成的程式碼在後續迭代中被悄悄刪掉、重寫，這些刪除動作不會被統計進「AI 幫我節省了多少時間」的報告裡。
當 token 預算變成了 KPI
Tokenmaxxing 這個詞的出現，說明一件事：AI 工具的採用已經從技術問題變成了組織管理問題。
當工程團隊開始把「每月消耗了多少 AI token」當成績效指標，問題就來了。工程師開始主動用 AI 生成大量程式碼來展示工作量，而不是認真判斷哪些程式碼真正應該由 AI 來寫。
Atlassian 花 10 億美元收購了開發者分析平台 DX，就是因為看到了這個趨勢——企業需要工具來搞清楚 AI 投資的真實 ROI，而不是靠 token 消耗量自欺欺人。
生產力瓶頸已經轉移了
AI 程式設計工具確實有用。McKinsey 2026 年 2 月的研究顯示，AI 工具把例行編碼任務的時間平均壓縮了 46%。
但壓縮的是「寫」的時間，不是「改」和「刪」的時間。
Jellyfish 的數據顯示，工程師每週花在審查 AI 程式碼上的時間是 11.4 小時，而花在寫新程式碼上的時間只有 9.8 小時——這個比例在 2024 年是反過來的。
程式碼生成變快了，程式碼審查變成了新瓶頸。把速度當品質，是 Tokenmaxxing 最核心的錯誤。
參考來源：CocoLoop、'Tokenmaxxing' is making developers less productive than they think（TechCrunch）