買 Token 不等於創造價值:Palantir 為何把 FDE 放在商業模式中央
模型是原料,Ontology 是企業語境,FDE 是把兩者接進決策與行動的人。真正的收入,不在呼叫模型,而在縮短從問題到成果的距離。
Token 如何穿過四層,才進入損益表
任何一層斷掉,模型能力都可能停在 Demo。
| 比較 | 平台型 FDE | 一次性客製案 |
|---|---|---|
| 核心產出 | 企業本體、共通元件、產品回饋 | 現場功能與專案驗收 |
| 客戶目標 | 業務結果與持續採用 | 完成需求清單 |
| 公司資產 | 平台能力隨部署增加 | 知識散在個人與專案 |
| 成長方式 | 部署更快、重用率提高 | 人數隨營收等比例增加 |
依研報第 5 頁與 Palantir Ontology 官方文件重製;這是分析框架,不是會計分類。
AI 產業最容易被誤解的一件事,是把模型用量當成企業價值。Token 的確是成本與收入單位,卻不是客戶的損益單位。客戶真正關心的是少花多少工時、降低多少錯誤、提高多少成交、縮短多少週期。兩者之間差的那一段,正是 Palantir 長年經營的 FDE 模式。
從資料平台,走到企業的決策語言
Palantir 強調 Ontology,中文常譯為本體。它不是一份資料字典,而是把企業裡的對象、關係、規則、權限與可採取行動建成一個共同語境。例如設備不只是一筆資料,還連著維修紀錄、庫存、產線、責任人與停機風險。模型若看不到這些關係,只能回答;接上本體之後,才有機會參與決策。
FDE 的工作,是在現場把這個語境建出來。他要知道『準時交貨』背後有哪些資料、『高風險客戶』由誰定義、某個建議能不能被系統執行,以及發生例外時誰有最後決定權。這些知識多半不在規格書,而在資深員工的經驗、跨部門默契與歷史例外裡。
Palantir 模式和一般專案公司的分水嶺
一般客製案也會派工程師進場,但專案結束後,程式碼和知識常留在客戶的一座孤島。Palantir 要追求的則是第二條曲線:先解決一個具體問題,再把其中共通的資料模型、工作流與工具沉澱回平台,讓下一個客戶部署更快。
這使 FDE 不只是成本中心。第一個案子看起來像高強度服務,若能成功抽象化,後面就會轉成產品能力、標準元件與更短的交付週期。服務收入與軟體毛利之間原本互相拉扯,FDE 的任務就是把客製經驗轉成產品資產。
商業模式可以拆成四層
- 模型層:推理、生成、工具使用與多模態能力。
- 語境層:企業資料、對象、規則、權限和組織知識。
- 執行層:FDE 把模型與語境接入工作流,處理例外與治理。
- 價值層:營收、成本、風險、速度或服務品質的可衡量變化。
對投資人來說,Token 成長可以證明需求,卻不能單獨證明護城河。更重要的問題是:每次部署是否產生更多可重用資產?客戶更換模型時,平台與流程是否仍留下?如果答案是肯定的,價值就不再綁在某一顆模型上。
最好的 FDE,不是讓客戶永遠依賴工程師,而是把工程師的經驗逐步變成平台能力。
這也是為什麼 FDE 被稱為 AI 商業模式的黏合劑。它黏住的不是兩段程式,而是模型能力與企業損益表。
資料來源與閱讀邊界
本文以 華西證券《FDE:AI 商業模式黏合劑》(2026-08-11)第 5、7 頁為導讀。本站未公開或直接重製原始研報頁面;文中圖表依可辨識資料重製,約數、指數與預測均明確標示。
研報是資料起點,不是本站結論。本文為產業研究與個人觀點,不構成投資、交易、招募或法律建議。
這是「FDE × 企業 AI 落地」第 2 篇。整套策展只追一個問題:AI 如何從模型能力,變成企業每天可驗證的營運能力?