Tokenmaxxing 陷阱：Uber AI 支出危機的教訓

當 Uber 的營運長 Andrew Macdonald 指出，越來越難以為在「tokenmaxxing」上花費的金錢辯護時，他觸及了一根在整個軟體工程領域都能引起共鳴的神經。術語「tokenmaxxing」——即最大化使用大型語言模型（LLM）token 的做法——已成為 AI 採用的代名詞。然而，正如 Uber 所發現的，消耗資源與創造價值之間有著天壤之別。

此認識標誌著 AI 熱潮週期中的關鍵轉變：從「實驗階段」——將支出視為對未來能力的投資——過渡到「營運階段」，在此階段必須以交付的功能與管理的技術債來衡量投資回報率（ROI）。

把消耗當作生產力的謬誤

對許多組織而言，AI 工具的最初推廣伴隨著隱性或明示的「盡可能多使用」鼓勵。在某些極端情況下，這演變成一項危險的管理指標，將 token 使用量視為員工參與新技術的信號。

正如一位觀察者所指出，這類似於根據工程師的 AWS 支出來排名：

想像一下，如果工程師是根據他們的 AWS 支出來排名的。人們分配虛擬機，並在資料庫中填入數 TB 的隨機位元，只為爬上 AWS 排行榜的頂端……誰會預料到這不是成功之路？

當指標變成目標時，它就不再是好的指標（古德哈特定律）。當 token 使用被激勵時，工程師可能會從事「毫無意義的忙活」或過度設計簡單的修復以滿足配額，導致工具成本超過產出價值的情況。

AI 驅動開發的隱性成本

除了 API 點數的直接財務成本外，「tokenmaxxing」做法還會為程式碼庫帶來多項系統性風險：

1. 技術債的累積

AI 能加速路線圖的推進，但它常常透過產生人類作者未能完全內化的程式碼來實現。這會產生一種「合成技術債」，即功能交付更快，但長期可維護性受損，因為團隊中沒有人真正了解其底層邏輯。

2. 初級工程師指導的侵蝕

資深工程師最關鍵的職責之一就是提升初級工程師的技能。當初級工程師依賴 LLM 來解決每一個障礙時，他們會跳過成長所需的掙扎與批判性思考。這剝奪了公司通常透過初級開發者成長為資深工程師而獲得的「技能/薪資套利」。

3. 產品臃腫

AI 降低了新增功能的邊際成本。這可能導致「P2 功能」（低優先級）的加入，這些功能會使產品變得複雜卻未提供顯著的消費者價值，僅僅因為它們「容易」產生。

朝向永續的 AI 策略

如果最大化 token 是錯誤的做法，健康的 AI 整合應該是什麼樣子？工程社群的見解提出了幾種替代方案：

有意圖勝於過量

限制本身可以成為設計特性。透過謹慎管理 token 並清理上下文，工程師被迫對提示與所解決的問題保持有意圖。這可防止將 AI 視為「許願機」而非精確工具的「黑箱」心態。

分層資源分配

借鑒早期 Google 資料中心的管理方式，公司可以實施基於優先級的系統。

• Priority 0（實驗性）：在非工作時間或未使用的容量上進行探索與學習。
• Production/Everyday Tasks（生產/日常任務）：聚焦於 token 效率，對例行任務使用較小、較便宜的模型，將高推理模型（如 Claude Opus 或 GPT-4）保留給複雜的架構挑戰。

基於價值的指標

領導層不應僅追蹤 token 數量，而應根據結果評估 AI 的使用。使用大量 token 來自動化每週需要十小時的手動流程，是高價值的資源運用。相同數量的 token 用於在四小時內除錯一個微不足道的前端錯誤，則是浪費。

結論：投資回報率的現實檢驗

產業開始意識到，擁有無限制的 token 預算並不會讓「10 倍工程師」自動變成「1000 倍工程師」。AI 的真正收益不在於處理的 token 量，而在於人與 AI 協作的品質。隨著資金成本上升、成長放緩，「像水一樣燃燒 token」的時代即將結束，取而代之的是對營運槓桿與真正生產力的必要關注。