Tokenmaxxing 的興起：當 AI 指標成為目標時

生成式 AI 整合進企業世界已不再僅止於簡單的實驗。公司現在正試圖量化其員工的「AI 轉型」。然而，一份關於 Amazon 員工參與「tokenmaxxing」的近期報告——即刻意增加 AI 提示詞（prompts）與回應中所使用的 token 數量——凸顯了管理不善與大型語言模型（LLMs）炒作週期之間危險的交集。

當管理層開始透過原始的 token 使用量來衡量 AI 的採用率時，他們衡量的並非生產力，而是一個成本中心。這種現象是古德哈特定律（Goodhart's Law）的典型體現：「當一個指標變成目標時，它就不再是一個好的指標。」

Tokenmaxxing 的機制

對於一般的工程師而言，目標是效率：以最小的摩擦力獲得正確答案。但當績效評估與 AI 使用量的 KPI 掛鉤時，激勵結構就會發生翻轉。員工不再被激勵去追求效率，而是被激勵去浪費資源。

正如一位 Hacker News 的評論者所指出的，這種行為是理性的：

"You measure employees in stupid ways, you're going to get stupid behaviour as a consequence."

「tokenmaxxing」的技術從微妙到荒謬不等。有些員工可能會使用過於冗長的提示詞，提供重複的上下文（context），或要求 AI 在簡單的任務上「思考得更深入」。其他人則可能採取更激進的做法，正如一位使用者所描述：

"Each day I send the AI on a fruitless mission like 'summarize the entire codebase' while I do my actual work..."

「我每天都會讓 AI 去執行一些徒勞無功的任務，例如『總結整個程式碼庫』，而我則在做我實際的工作..."

與傳統指標的平行關係

這在軟體工程領域並非新問題。數十年來，管理層一直難以衡量開發者的生產力，經常退而求其次，使用錯誤的指標，例如「新增的程式碼行數（LOC）」或每日提交（commits）的次數。Tokenmaxxing 僅僅是這種謬誤在現代、AI 驅動下的版本。

將 token 使用量作為生產力指標，正如一位批評者所說，「就像是在衡量按鍵次數」。它忽略了實際產出的價值——程式碼的品質、系統的穩定性，以及工程師解決問題的能力。事實上，膨脹的 token 使用量實際上可能導致更低的產出品質，因為過多的上下文（context）有時會降低某些模型的效能。

管理層的落差：炒作 vs. 現實

非技術領導層的期望與工程現場的現實之間存在著顯著的脫節。雖然領導層可能認為 AI 會為生產力帶來「10x」的提升，但實際的增益可能更為溫和——或許只有 40-60%。

這種落差創造了一種恐懼文化。工程師可能會感到被迫偽裝成正在使用這些工具，以避免被視為「落後者」，或者更糟，為了避免裁員。這導致了一種「績效表演」，其主要目標不再是解決技術問題，而是為了滿足儀表板（dashboard）。

未來的路徑：基於結果的指標

為了避免 tokenmaxxing 的陷阱，組織必須將焦點從輸入（使用的 tokens）轉移到結果（交付的價值）。

與其追蹤發送了多少次提示詞，管理層應該詢問：

• 程式碼是否交付得更快且品質更高？
• 是否在更短的時間內修復了更多的 bug？
• 整體系統的可靠性是否正在提高？

正如一位業界資深人士所建議，衡量 AI 是否真正為組織帶來效益的唯一方法，就是簡單地「show me the result」。這需要判斷力與品味——區分「工作的外表」與「實際價值」的能力——而這正是原始指標無法提供的。

結論

對於任何急於將 AI 整合進工作流程的公司來說，tokenmaxxing 都是一個警示故事。危險不在於技術本身，而是在於圍繞它所建立的激勵結構。當我們獎勵手段而非目的時，我們就創造了一個系統，讓員工激勵去浪費資源並假裝很生產力，而實際的工作卻毫然未變。