第一步·把客戶付的錢和其他的錢分開
一個專案可以同時擺出很漂亮的現金流入,又在每一個任務上虧錢。所以第一步不是計算,而是分開:哪些錢是因為服務真的交付了才進來的,哪些錢來自別的地方。
| 算進產品收入 | 自己單獨列一行 |
|---|---|
| 客戶為服務支付、扣除退款與付款成本後的金額 | Token 出售與新增發行 |
| 與服務直接相關的合作夥伴分潤 | 投資款、補助與生態基金 |
| 預付款,但只限已經交付服務的那一部分 | 國庫資產增值 |
| — | 關聯方轉帳 |
預付款是最容易出錯的地方。已經進到帳戶的錢不一定是本期的收入;服務還沒交付的那部分仍是負債,把它挪到收入那一行,會讓這一期看起來好很多,代價是掏空了下一期。
來源追不回去的款項不硬塞進任何一欄。它維持「未分類」的狀態,而這個狀態本身也要一起報告。
第二步·在被接受的任務上算變動成本
變動成本是會隨量增加的成本:模型推理、工具呼叫、RPC、gas、付款手續費,以及每個任務用掉的人工工時。它的單位必須和收入一樣,也就是「通過接受標準的一個任務」。
單位貢獻 = 每個被接受任務的淨收入 - 每個被接受任務的完整變動成本
這條公式誠不誠實,取決於兩件事。第一,失敗嘗試的成本照樣要算,並分攤到最後被接受的那些任務上;少了這一步,失敗率上升會看起來像成本下降。第二,包月最低額要拆成兩半:真正用掉的部分進變動成本,付了卻沒用到的容量留到下一步進固定成本。
各個成本科目的細節、有日期的費率該怎麼保存、鏈上 gas 怎麼歸到觸發它的任務,另見Crypto AI Agent 的推理與營運成本。
第三步·把固定支出完整攤在桌面上
單位貢獻為正,並不代表公司賺錢。人員、已經承諾的雲端保留量、安全、法務、客服與資料授權,不管這個月進來幾個任務都照樣在跑。
所以固定成本要以同一期間的完整總額呈現,分攤規則不在期間中途更動。一次性項目——稽核、遷移、事件處理——標註為一次性,免得趨勢看起來比實情更差或更好。
要報告的始終是兩個分開的數字:貢獻毛利與營業結果。合成一個數字會藏住兩個答案可能相反的問題——每個任務可以是賺的,而公司同時是虧的,反過來也成立。
第四步·用單位貢獻去除,而不是用比率
損益平衡是一個除法,而除數必須是每個任務的單位貢獻。營收對成本的比率代替不了它:即使每個任務都在虧,那個比率仍然可以看起來在改善。
損益平衡量 = 期間固定成本總額 ÷ 每個被接受任務的單位貢獻
如果單位貢獻是零或負的,這個除法沒有答案:再多的量只會把虧損放大。這個結論最常被繞開,卻最關鍵,因為成長計畫並不會修好負的單位毛利——它只會讓現金燒得更快。
單位貢獻為正時,損益平衡量還要拿去對三個真實上限:模型與基礎設施的吞吐上限、做覆核的人工產能,以及在那個價格下能觸及的市場規模。超過其中任何一項的損益平衡量,是算術結果,不是能執行的計畫。
哪些跡象代表好數字是補貼撐起來的
數字可以是真的,同時並不可持續——如果撐住它的是有期限的激勵。下面五個跡象通常會先露出來:
- 售價低於完整變動成本;
- 用量大部分來自領取獎勵的使用者;
- 款項是以專案自己的 Token 支付,而不是現金;
- 關聯方之間有循環轉帳,並以收入的形式出現;
- 激勵方案一停,留存就急速下滑。
檢查的方法是為同一期間做兩份報表:一份含補貼,一份不含。兩者的差額就是依賴程度;激勵停止後的留存曲線則顯示需求能不能自己站住。
補貼不是欺詐的證據。它是常見的買時間策略;需要講清楚的只有資金來源、規模,以及預算到什麼時候。
什麼情況下這份計算就失效了
以上四步的結果,綁在計算當時的期間、價格與客戶結構上。下面四種變化會讓它失效,而每一種都只要求重算被碰到的那幾列,不是整份報表:
- 供應商費率或使用的模型清單變了;
- 售價或方案結構變了;
- 補貼方案開始或停止;
- 一個大客戶進來或離開,集中度因此移動。
拿不到的資料不以單一數字填補。結果以區間連同最壞假設一起呈現;在沒有別人能重算的數字之前,不使用「已損益平衡」這個說法。
驗證工作簿
這一節把上面四步改寫成檢查:每一步各給一件該找的東西、一件會推翻它的東西。其中沒有任何一條會產生建議。
- 第一步——該找什麼
- 能連回該期間確實交付之服務的付款
- 第一步——什麼會推翻
- 融資、補助或補貼被併進同一行收入
- 第二步——該找什麼
- 可從任務 trace 聚合出來的成本,含失敗嘗試
- 第二步——什麼會推翻
- 只算成功的呼叫,或只算主模型
- 第三步——該找什麼
- 該期間的固定支出總額,且分攤規則未變更
- 第三步——什麼會推翻
- 公布毛利卻省略營運團隊與容量承諾
- 第四步——該找什麼
- 可由已公布數字重算的損益平衡公式輸入
- 第四步——什麼會推翻
- 用營收對成本的比率取代單位貢獻
- 補貼跡象——該找什麼
- 獎勵停掉之後仍然存在的付費使用
- 補貼跡象——什麼會推翻
- 把激勵支付算成自然需求
若其中任何一條「什麼會推翻」被證實,要報告的是資料的邊界,而不是把結論講得圓一些。補貼依賴限制的是可持續性;它不是欺詐的認定,也不該那樣寫。
最常見的正確答案,是一個在一端跨過損益平衡、在另一端沒跨過的區間。那是合法的答案,比一個為了看起來完成而四捨五入的單一數字更有用。
常見問題
鏈上手續費由使用者另付,還算成本嗎?
至少應揭露總交易成本;是否列入公司成本取決於誰負擔,但不能從使用者經濟中消失。
沒有公開收入能否估算?
可以做具名假設的情境分析,但不能稱為實際營收或已驗證毛利。
正毛利是否代表可持續?
不一定,還要看固定支出、留存、集中客戶、補貼和容量限制。
本檔案使用的來源
- AI x Crypto: Exploring Use Cases and Possibilities — 用於核對範圍、版本、行為或控制的一手資料;使用時仍須確認頁面日期與上下文。
- Building effective agents — 用於核對範圍、版本、行為或控制的一手資料;使用時仍須確認頁面日期與上下文。
- OpenAI Agents SDK — 用於核對範圍、版本、行為或控制的一手資料;使用時仍須確認頁面日期與上下文。
- Ethereum JSON-RPC API — 用於核對範圍、版本、行為或控制的一手資料;使用時仍須確認頁面日期與上下文。
- AI agent quickstarts for Safe Smart Account — 用於核對範圍、版本、行為或控制的一手資料;使用時仍須確認頁面日期與上下文。
- NIST AI 600-1: Generative AI Profile — 用於核對範圍、版本、行為或控制的一手資料;使用時仍須確認頁面日期與上下文。
- Viewing activity and data for a repository — 用於核對範圍、版本、行為或控制的一手資料;使用時仍須確認頁面日期與上下文。
