問大多數工程主管上個月團隊花了多少 AI Token，他們能給你一個數字。再問那些花費產生了什麼——驅動了哪些工作流程、改變了什麼、值不值得——答案就開始模糊了。

這種模糊是有代價的。不只是因為 Token 並不便宜（在規模化之後確實不便宜），而是因為你說不清楚的支出，就是你無法辯護的支出。而無法辯護的支出，是優先順序轉變時第一個被砍的東西。

Token 預算就是工程預算。它值得你用對待運算資源支出、人力成本或工具合約的同等嚴謹態度來管理。早點想通這件事的團隊，在其他人還在為 AI 預算項目苦苦辯護時，已經有了結構性的優勢。

Token 是可變運算成本，不是訂閱費

第一個需要調整的心智模型：Token 不是 SaaS 訂閱費，你不是付了一筆固定費用就能存取 AI 能力。你付的是消耗——每一個輸入、每一個輸出、每一次模型呼叫、每次任何工作流程觸及 AI 系統，都在計費。

這讓 Token 支出的行為模式和雲端運算一樣：隨使用量線性增長，也就是說，它會同等地放大你的成功和你的浪費。一個設計良好、每月處理一萬件事故的 AI 工作流程，成本就是處理一百件的一百倍。一個帶著 bug 在迴圈中執行的 AI Agent，不只是產出錯誤——它還在製造帳單。

這和工程從雲端學到的教訓完全一樣：沒有對消耗的可觀測性，就無法優化、無法治理、無法辯護。把 AI API 費用當成雲端帳單中一個單一項目的團隊，正在犯他們 2015 年面對未打標籤的 EC2 實例時犯過的同樣錯誤——而且兩年後會有一模一樣的財務對話。

價值對應的難題

更難的挑戰不是追蹤 Token 的成本，而是把 Token 的成本和它產生的結果連結起來。

大多數團隊用「節省的時間」衡量 AI 的價值——「我們的工程師在某件事上花的時間減少了」。這個指標感覺直覺，但經不起細究。節省的時間鮮少能轉換成多出貨的功能或減少的人力。它會擴散：工程師把回收的工時填進其他工作裡，而生產力提升對團隊以外的任何人都變得看不見。

更能被辯護的框架是結果對應：追蹤 Token 消耗到工作流程輸出，再從工作流程輸出追蹤到財務真正在意的業務結果。

三個類別涵蓋了工程 AI 使用的大部分場景：

運營自動化。用於 AIOps、自動化 Runbook 和事故處理的 Token，可以直接對應到平均修復時間（MTTR）和 On-call 負擔。如果你的 AI 輔助事故處理將 MTTR 從 45 分鐘縮短到 12 分鐘，這個差異有可計算的價值：更少的 SLA 違反、更少的客戶影響，以及工程師不必在凌晨兩點醒來的時間。每次事故處理的 Token 成本，是一個真實的單位經濟數字。

開發加速。用於程式碼生成、Review 自動化和測試覆蓋的 Token，對應到開發週期時間和缺陷逃逸率。這些更難單獨量化——AI 只是 PR 過程中眾多輸入之一——但方向上是可測量的。AI 輔助 Review 前後的 PR 週期時間，是一個可以直接比較的數字。AI Review 過的程式碼和未經 Review 的程式碼的缺陷率，是另一個。

知識與文件。用於內部搜尋、文件生成和知識萃取的 Token，最難量化，但往往也是最被低估的。要追蹤的指標是重工率和搜尋到答案的時間：工程師有多常在解決他們已經解決過的問題，只因為之前的解法找不到？AI 在三十秒而不是三十分鐘內找到正確答案——或者省去了一次升級——有可量化的價值，即使它比較難放進試算表。

如何建立有效的預算論證

當你去找財務或領導層申請 AI 預算——或者辯護你已經在花的費用——論證必須用他們的語言，而不是你的語言。掌控預算的人在意三件事：成本是多少、回報是多少，以及你對那個估算有多大把握。

從試點開始，不要從平台開始。最糟糕的 AI 預算對話，發生在有人申請廣泛的平台存取權限卻無法回答「這具體會做什麼？」的時候。最成功的對話，從一個範圍清楚、有明確前後對比指標的單一工作流程開始。跑試點，測量結果，呈現單位經濟數字，然後申請擴大規模的預算。這不只是更好的政治策略——這是更好的工程。你在承諾一整年支出之前，先確認這個工作流程真的能從 AI 中受益。

建立 Token 到結果的對帳表。對每個使用 AI 的工作流程，維護一份簡單的記錄：每單位工作消耗的 Token、每單位成本，以及它影響的業務指標。這不需要很複雜。一份追蹤「每次事故處理的 Token 數」和每月「平均 MTTR」的試算表，就足以呈現趨勢。目標是讓支出和結果之間的關係可見——對你自己，也對任何問起的人。

設定 Token SLO。就像你為可靠性設定錯誤預算，也為 AI 工作流程設定效率目標。每次事故處理可接受的 Token 成本是多少？每次 PR Review？每次文件查詢？當消耗超過目標，那是一個需要調查的信號——不一定是要削減，而是要理解。Token 用量失控通常意味著工作流程出現了意外行為：一個沒有終止的迴圈、一個不必要地膨脹的 Context Window、一個在可以用更便宜模型的情況下仍呼叫昂貴模型的設計。

大多數團隊跳過的治理層

一旦 AI 支出變得可見並對應到結果，下一個問題是分配：在固定的 AI 預算下，哪些工作流程值得更多投資，哪些應該被合理化？

這是一個真實的工程優先順序問題，值得和任何其他資源分配決策同等的對待。不是所有 Token 支出都相同。一個每月處理五百件事故、有明確 MTTR 改善的 AI 工作流程，比一個產生沒有人閱讀的文件的工作流程更有價值。

一個實用的框架：按可量化結果與 Token 成本的比率，為你的 AI 工作流程排名。高結果、低成本的工作流程是你的錨點——保護並擴大它們。高成本、結果不清楚的工作流程是你的調查對象——要嘛找到其價值，要嘛削減支出。中間地帶才是大多數真實決策發生的地方：有真實價值但有優化空間的工作流程，或者價值論證需要被磨得更銳利的工作流程。

這樣的審查不需要每週進行——每季通常就足夠了。重點是讓 AI 支出成為一個有意識的資源分配決策，而不是從沒有人一起退後一步評估過的個別工作流程選擇的累積。

真正有效的預算對話

成功擴大 AI 預算的工程主管，往往有一個共同特徵：在任何人要求他們說明之前，他們就已經做了把技術結果翻譯成財務語言的工作。

這意味著帶著具體數字進入預算對話：「上季我們在 Token 上花了 X。這驅動了 Y 件自動化事故處理，平均 MTTR 為 Z，相比之前的 W。這個改善換算成工程師時間，以我們的完全成本費率計算，大約等於 V 小時。」財務是否認同計算中的每一個假設，不如計算存在本身重要。它傳遞出一個訊號：你在像管理資本配置一樣管理這筆支出，而不是像管理水電費一樣。

失去 AI 預算的團隊，通常不是那些沒有產生價值的——而是那些沒有讓價值可見的，並且發現自己無法回答每個 CFO 最終都會問的問題：「如果我們把這個砍掉一半，會發生什麼？」

那個問題的答案，應該是你已經算好的。不一定是「什麼都不會改變」——也許是「MTTR 會上升 40%，On-call 負擔會急劇增加」。但知道答案、能夠清楚地說出來，才是 AI 投資和 AI 費用之間的差別。

在 AIDARIS，這是我們協助工程組織為他們正在建構的系統建立論證的方式之一。如果你正在思考自己的 AI 支出實際上產生了什麼，以及如何讓這件事對組織其他人來說清晰可見，歡迎與我們聊聊。