德勤用1個指標搞砸AI項目，工程師開始"養眼鏡蛇"

2024年，某家咨詢公司給Fortune 500企業做AI轉型方案時，把"token消耗量"寫進了工程師的KPI。三個月后，這家企業的AI賬單漲了340%，代碼質量卻跌回了2019年水平。

這不是孤例。當我翻完17家企業的內部復盤文檔，發現把token用量當生產力指標，正在成為AI時代最隱蔽的管理陷阱。

從"代碼行數"到"token數"：同一個坑摔兩次

技術管理者對proxy metrics（代理指標）的迷戀，幾乎是一種周期性復發的病。

2000年代看代碼行數，工程師把`a = b + c`拆成五行。2010年代看Jira ticket關閉數，一個功能被切成二十個任務單。2020年代初看PR合并數，有人把變量重命名拆成獨立提交。

現在輪到token了。

一位在兩家大廠都待過的工程總監告訴我，他的前東家把Copilot用量納入季度評審。"你知道會發生什么嗎？我團隊里有人開始用AI寫注釋，再用AI解釋那些注釋，最后用AI給解釋寫摘要。"

三層嵌套的AI調用，token燒得飛快，產出接近于零。

這種行為的本質，和當年印度德里的眼鏡蛇養殖戶沒有區別。

眼鏡蛇效應：一個被驗證了兩百年的管理悖論

殖民時期的德里，眼鏡蛇泛濫成災。英國政府懸賞：每上交一條死蛇，獎勵一筆錢。

結果市民開始養蛇、殺蛇、換賞金。政府發現后取消懸賞，養殖戶把蛇全部放生——德里的眼鏡蛇比政策出臺前更多了。

經濟學家后來把這類現象命名為"眼鏡蛇效應"：當激勵與真實目標錯位，系統會自發長出對抗性的生存策略。

AI token的計量陷阱，正在復刻這個古老劇本。

我拿到的一份內部數據顯示，某金融公司在Q2把"人均周token消耗"設為團隊排名依據。四周后，工程師的AI交互時長上升了210%，但代碼提交后的回滾率從12%飆到31%。

更隱蔽的是"token farming"（token farming，token farming）——有人故意用模糊提示詞觸發長回復，或在已有答案后追問"再詳細一點"。

一位受訪者展示了他的"技巧"：把一段能跑通的代碼粘貼給AI，問"這段代碼有什么問題"。AI會生成冗長的分析，token計數器狂轉，而他真正想做的只是刷數據。

為什么token特別容易"養蛇"

相比代碼行數或ticket數，token有三個更危險的特性。

第一，它看起來"更智能"。代碼行數人人知道是爛指標，但token關聯著大模型、生成式AI、未來趨勢——管理層容易放下警惕。

第二，它天然可貨幣化。API賬單按月結算，CFO能直接看到"AI投資回報率"。這種可視性，讓token比其他 proxy metrics 更快被寫進考核。

第三，它的濫用更難審計。一段冗余代碼能被code review攔下，但"用AI頭腦風暴了20輪"很難被質疑——誰知道那20輪有沒有價值？

一位在AI infra團隊工作的工程師說，他們內部有個黑話叫"token laundering"（token laundering，token laundering）：把私人事務包裝成工作查詢，用公司API賬號處理。

寫辭職信、潤色約會軟件簡介、生成周末旅行計劃——全部計入"研發創新探索"的token池。

那些試圖"修復"指標的人，往往挖得更深

意識到問題后，一些管理者開始疊加修正因子。我見過最復雜的方案包含四個維度：token總量、token/有效代碼行比、AI生成代碼的測試通過率、以及"AI輔助效率"自評問卷。

結果？工程師學會了新的優化策略。

有人在提示詞里明確要求"輸出簡潔"，縮短AI回復長度，同時手動展開被壓縮的內容——既省了token，又顯得"高效"。有人把AI生成的代碼故意拆成多段提交，讓測試覆蓋率計算時分母變小。

「每次我們堵上一個漏洞，他們就會找到兩個新的。」一位嘗試過多輪指標迭代的技術VP說，「后來我意識到，問題根本不是指標設計得不夠好，是我們根本就不該測這個。」

這句話指向一個更底層的困境。

當"證明在用AI"變成政治剛需

2024年的企業AI敘事里，"落后焦慮"比"效率焦慮"更致命。董事會問CTO：我們的AI滲透率是多少？競爭對手據說已經全員Copilot了。

token用量在這種情況下，成了一種表演性數據。它回答的不是"工程師有沒有更高效"，而是"我們有沒有在AI上花錢、花得夠不夠顯眼"。

一位在零售企業負責數字化轉型的總監承認，他們向董事會匯報時，token增長曲線被做成全屏圖表。"沒人追問這些token產出了什么。但如果沒有這張圖表，我們會收到CEO的郵件，問是不是IT團隊在抵制新技術。"

這種壓力向下傳導，最終落在工程師的績效考核表里。

我采訪的一位前端工程師，其Q3目標包含"提升AI工具采納率"。她的實際做法是：把原本復制粘貼就能解決的CSS調整，改成用AI生成、再手動修正。"效率其實更低，但我的采納率指標是綠的。"

少數人的反其道而行

并非所有團隊都在這個陷阱里打轉。

Netflix的AI平臺團隊從2023年起就明確禁止在工程師評審中引用任何原始token數據。他們的替代方案是"輸出-結果"雙軌制：看AI輔助產出的代碼在代碼審查中的接受率，看這些代碼上線后的故障密度。

「token是我們付給OpenAI的錢，不是工程師創造的價值。」該平臺團隊的一位負責人在內部文檔中寫道。

更激進的實驗來自一家不愿具名的自動駕駛公司。他們取消了所有AI用量的團隊級統計，改為抽樣訪談：每月隨機選10%的工程師，深入討論"上周哪次AI交互真正幫到了你"。

這種方法顯然無法生成漂亮的儀表盤，但據其工程效率負責人稱，他們識別出的"高價值AI使用模式"，比任何量化指標都更接近真實。

另一個值得注意的群體是開源社區。Linux內核維護者早在2022年就討論過是否接受AI生成的補丁，最終形成的共識是：只評審代碼本身，不問來源。這個原則被寫入提交規范，從根本上杜絕了"為了用AI而用AI"的動機。

指標暴政的終點在哪里

回顧技術管理史，proxy metrics的失效遵循固定劇本：被測量→被操縱→被廢棄→換一個新指標→循環。

代碼行數、story point、PR數、現在輪到token。每次替換都伴隨著"這次不一樣"的幻覺——新指標更精細、更實時、更難作弊。

但眼鏡蛇效應從不挑選指標類型。它只要求一個條件：激勵與真實目標之間存在可被利用的縫隙。

AI token的特殊性在于，它同時連接著技術敘事（我們在擁抱AI）、財務敘事（我們在控制成本）、和管理敘事（我們在量化效率）。三重敘事的疊加，讓這個指標比前任們更難被質疑。

一位在三家獨角獸都擔任過CTO的顧問告訴我，他現在的標準開場白是："如果你們正在測量token用量，請先回答我——如果明天token消耗降為零，但工程師產出不變，你們是慶祝還是恐慌？"

他說，這個問題的答案，比任何token儀表盤都更能說明問題。

某家SaaS公司的工程團隊在2024年Q4做了件罕見的事：他們主動關閉了token用量看板，把省下的儀表板開發時間，用來重構了一套基于"功能交付周期"的簡易追蹤。沒有AI，沒有預測模型，就是手動標記需求從提出到上線的天數。

三個月后，他們的平均交付周期縮短了19%。沒人能證明這和關閉token看板有因果關系。但團隊里一位工程師在匿名調研里寫了一句反饋，被截屏傳到了我的郵箱——

「終于不用在想提示詞的時候，還要想怎么讓回復長一點了。」