每月燒5萬美元token的工程師是不是浪費，沒人答得上來

那個一個月燒掉五萬美元的工程師，該怎麼辦

Rippling有一位工程師一個月在token上花了5萬美元。放到公司層面，AI token支出以每月80%的速度膨脹，一度衝上燒掉研發人力預算40%的軌道，高峰月流過6,050億token。10%到15%的員工製造了60%的總支出（TechCrunch）。

難的不是把支出壓下去，而是決定怎麼處置那位燒5萬美元的工程師。如果是浪費，就該擋；如果產出對得起這筆錢，正確動作恰恰相反：讓其他人學著他那樣用。只靠支出排行榜分不出這兩種情況，而大多數公司手裡恰恰只有排行榜。

Rippling為了回答這個問題自研了內部工具，隨後把它做成產品AI Spend Console（Rippling）。它把員工、團隊、職務粒度的支出，和GitHub、Salesforce這類業務系統的訊號接在一起：PR數量、程式碼交付速度、程式碼審查裡被要求重工的頻率，甚至貢獻的營收（Business Wire）。結果很說明問題。治理之後，Rippling七月的token用量是6,000億個，接近峰值，成本卻只有四月的37%。用量沒有降，被拿掉的只有浪費。

一家公司因為自己的痛自研的工具，本身就是品類成立的證明。不過Rippling的產品綁在自家HR套件上，重心也偏支出管控。把歸因測量本身當產品賣的中立層，位置還空著。以台灣科技業的工程組織密度來看，這層空隙正好落在買得起AI卻養不起自研平台的公司身上。

在包月時代，這個問題根本不成立

去年之前這種測量根本不成立。按席次包月時，所有員工的AI成本一樣，沒有按人看的理由。轉成按量計費後，同一職務內個人支出拉開幾十倍差距，「這個差距有沒有體現在產出上」這個問題才第一次問得出口。

第一波應對已經過去了。預算上限、低價模型路由、團隊額度，管控工具已經出齊，落地也完成了。管控一到位，下一個問題立刻到來：留下的支出裡，哪些該保護，哪些該加碼。Rippling的順序就是如此，先擋住，再造測量工具。

產出資料也終於以可關聯的形態存在了。工程組織的PR、週期時間、審查重工率全都有API，銷售組織的管線沉在CRM裡。支出日誌有，產出日誌也有，缺的只是兩者之間的一次關聯。缺的那次關聯，就是產品。

把支出日誌和產出日誌接起來的那一次連接

flowchart LR
  A[閘道·SSO<br/>使用日誌] --> C[歸因引擎]
  B[GitHub·Jira·CRM<br/>產出訊號] --> C
  C --> D[團隊·同組<br/>ROI視圖]
  D --> E[該加碼的地方<br/>和該削減的地方]
  E --> F[頭部用戶模式<br/>的內部推廣]

採集層不用新建。多數公司已經用LLM閘道或代理收攏呼叫，身分、模型、token從這些日誌裡拿，GitHub、Jira、CRM走現成API。難的不是管線而是對照設計：按同職務、相近年資組隊列，展示AI使用強度不同的人產出差在哪裡。如果一上來就發個人排行榜，產品會被讀成監控工具，第一線馬上開始污染資料。預設呈現團隊和隊列，個人下鑽放在權限後面。

第二層才是這個產品真正的差異點。把產出效率最好的頭部用戶在什麼任務上用什麼模型的模式提煉出來，變成其餘組織可以照抄的手冊。走到這一步，買單的人就變了。省錢是CFO的事，人怎麼工作是CTO和人資部門的事。這個產品的站位是FinOps工具和人才分析之間的空格，不綁任何一家HRIS的中立性就是對Rippling的護城河。

把相關當因果賣，第一次資料複盤就垮

最危險的假設，是把支出和產出的相關性當因果賣。如果只是本來就強的工程師恰好也重度用AI，這個工具的建議在第一次認真的資料審查上就會垮。隊列設計要保守，克制到只說「在這個團隊這個時間窗觀察到這個差異」，這份克制就是產品信譽的全部。

第二是古德哈特定律。PR數量一進考核，PR馬上被切碎。要混入難灌水的指標，重工率、週期時間、事故率，並定期輪換指標構成。最後是擴張順序：從產出可測的工程側起步，急著擴到測量模糊的職務，數字的公信力會全盤崩掉。Rippling那個40%究竟是一家公司的事故，還是明年所有公司的預設值，答案決定這個市場有多大。