第一步·把客戶付的錢和其他的錢分開

一個專案可以同時擺出很漂亮的現金流入,又在每一個任務上虧錢。所以第一步不是計算,而是分開:哪些錢是因為服務真的交付了才進來的,哪些錢來自別的地方。

算進產品收入自己單獨列一行
客戶為服務支付、扣除退款與付款成本後的金額Token 出售與新增發行
與服務直接相關的合作夥伴分潤投資款、補助與生態基金
預付款,但只限已經交付服務的那一部分國庫資產增值
—關聯方轉帳

預付款是最容易出錯的地方。已經進到帳戶的錢不一定是本期的收入;服務還沒交付的那部分仍是負債,把它挪到收入那一行,會讓這一期看起來好很多,代價是掏空了下一期。

來源追不回去的款項不硬塞進任何一欄。它維持「未分類」的狀態,而這個狀態本身也要一起報告。

第二步·在被接受的任務上算變動成本

變動成本是會隨量增加的成本:模型推理、工具呼叫、RPC、gas、付款手續費,以及每個任務用掉的人工工時。它的單位必須和收入一樣,也就是「通過接受標準的一個任務」。

單位貢獻 = 每個被接受任務的淨收入 - 每個被接受任務的完整變動成本

這條公式誠不誠實,取決於兩件事。第一,失敗嘗試的成本照樣要算,並分攤到最後被接受的那些任務上;少了這一步,失敗率上升會看起來像成本下降。第二,包月最低額要拆成兩半:真正用掉的部分進變動成本,付了卻沒用到的容量留到下一步進固定成本。

各個成本科目的細節、有日期的費率該怎麼保存、鏈上 gas 怎麼歸到觸發它的任務,另見Crypto AI Agent 的推理與營運成本。

第三步·把固定支出完整攤在桌面上

單位貢獻為正,並不代表公司賺錢。人員、已經承諾的雲端保留量、安全、法務、客服與資料授權,不管這個月進來幾個任務都照樣在跑。

所以固定成本要以同一期間的完整總額呈現,分攤規則不在期間中途更動。一次性項目——稽核、遷移、事件處理——標註為一次性,免得趨勢看起來比實情更差或更好。

要報告的始終是兩個分開的數字:貢獻毛利與營業結果。合成一個數字會藏住兩個答案可能相反的問題——每個任務可以是賺的,而公司同時是虧的,反過來也成立。

第四步·用單位貢獻去除,而不是用比率

損益平衡是一個除法,而除數必須是每個任務的單位貢獻。營收對成本的比率代替不了它:即使每個任務都在虧,那個比率仍然可以看起來在改善。

損益平衡量 = 期間固定成本總額 ÷ 每個被接受任務的單位貢獻

如果單位貢獻是零或負的,這個除法沒有答案:再多的量只會把虧損放大。這個結論最常被繞開,卻最關鍵,因為成長計畫並不會修好負的單位毛利——它只會讓現金燒得更快。

單位貢獻為正時,損益平衡量還要拿去對三個真實上限:模型與基礎設施的吞吐上限、做覆核的人工產能,以及在那個價格下能觸及的市場規模。超過其中任何一項的損益平衡量,是算術結果,不是能執行的計畫。

哪些跡象代表好數字是補貼撐起來的

數字可以是真的,同時並不可持續——如果撐住它的是有期限的激勵。下面五個跡象通常會先露出來:

  • 售價低於完整變動成本;
  • 用量大部分來自領取獎勵的使用者;
  • 款項是以專案自己的 Token 支付,而不是現金;
  • 關聯方之間有循環轉帳,並以收入的形式出現;
  • 激勵方案一停,留存就急速下滑。

檢查的方法是為同一期間做兩份報表:一份含補貼,一份不含。兩者的差額就是依賴程度;激勵停止後的留存曲線則顯示需求能不能自己站住。

補貼不是欺詐的證據。它是常見的買時間策略;需要講清楚的只有資金來源、規模,以及預算到什麼時候。

什麼情況下這份計算就失效了

以上四步的結果,綁在計算當時的期間、價格與客戶結構上。下面四種變化會讓它失效,而每一種都只要求重算被碰到的那幾列,不是整份報表:

  • 供應商費率或使用的模型清單變了;
  • 售價或方案結構變了;
  • 補貼方案開始或停止;
  • 一個大客戶進來或離開,集中度因此移動。

拿不到的資料不以單一數字填補。結果以區間連同最壞假設一起呈現;在沒有別人能重算的數字之前,不使用「已損益平衡」這個說法。

驗證工作簿

這一節把上面四步改寫成檢查:每一步各給一件該找的東西、一件會推翻它的東西。其中沒有任何一條會產生建議。

第一步——該找什麼
能連回該期間確實交付之服務的付款
第一步——什麼會推翻
融資、補助或補貼被併進同一行收入
第二步——該找什麼
可從任務 trace 聚合出來的成本,含失敗嘗試
第二步——什麼會推翻
只算成功的呼叫,或只算主模型
第三步——該找什麼
該期間的固定支出總額,且分攤規則未變更
第三步——什麼會推翻
公布毛利卻省略營運團隊與容量承諾
第四步——該找什麼
可由已公布數字重算的損益平衡公式輸入
第四步——什麼會推翻
用營收對成本的比率取代單位貢獻
補貼跡象——該找什麼
獎勵停掉之後仍然存在的付費使用
補貼跡象——什麼會推翻
把激勵支付算成自然需求

若其中任何一條「什麼會推翻」被證實,要報告的是資料的邊界,而不是把結論講得圓一些。補貼依賴限制的是可持續性;它不是欺詐的認定,也不該那樣寫。

最常見的正確答案,是一個在一端跨過損益平衡、在另一端沒跨過的區間。那是合法的答案,比一個為了看起來完成而四捨五入的單一數字更有用。

常見問題

鏈上手續費由使用者另付,還算成本嗎?

至少應揭露總交易成本;是否列入公司成本取決於誰負擔,但不能從使用者經濟中消失。

沒有公開收入能否估算?

可以做具名假設的情境分析,但不能稱為實際營收或已驗證毛利。

正毛利是否代表可持續?

不一定,還要看固定支出、留存、集中客戶、補貼和容量限制。

本檔案使用的來源

  1. AI x Crypto: Exploring Use Cases and Possibilities — 用於核對範圍、版本、行為或控制的一手資料;使用時仍須確認頁面日期與上下文。
  2. Building effective agents — 用於核對範圍、版本、行為或控制的一手資料;使用時仍須確認頁面日期與上下文。
  3. OpenAI Agents SDK — 用於核對範圍、版本、行為或控制的一手資料;使用時仍須確認頁面日期與上下文。
  4. Ethereum JSON-RPC API — 用於核對範圍、版本、行為或控制的一手資料;使用時仍須確認頁面日期與上下文。
  5. AI agent quickstarts for Safe Smart Account — 用於核對範圍、版本、行為或控制的一手資料;使用時仍須確認頁面日期與上下文。
  6. NIST AI 600-1: Generative AI Profile — 用於核對範圍、版本、行為或控制的一手資料;使用時仍須確認頁面日期與上下文。
  7. Viewing activity and data for a repository — 用於核對範圍、版本、行為或控制的一手資料;使用時仍須確認頁面日期與上下文。