FDE 前線部署工程怎麼計價?固定價、T&M、成效綁定三種合約模式比較
採購把三家 FDE 報價攤在桌上,一家報總價、一家報人天、一家報成效分潤——數字根本沒法直接比,因為它們賣的不是同一件事。這篇拆解固定價、T&M、成效綁定三種合約怎麼算、雷在哪,並回答選型時最實際的問題:哪一種,才真的把「上線沒人用」的風險綁回供應商身上。
Autor
Tenten AI FDE 團隊
前線部署工程
Publicado em
30 de maio de 2026
Tempo de leitura
5 分鐘

先講一個我們常被問到的場景。採購把三家 FDE 供應商的報價攤在桌上,一家寫「專案總價 480 萬」,一家寫「每人天 2.4 萬,實作實算」,第三家寫「基礎費 + 上線採用達標再拆分」。三份報價的數字沒法直接比,因為它們賣的根本不是同一件事。選型卡在這一關的,通常不是預算不夠,而是不知道每種FDE 計價合約模式背後,誰在扛「上線失敗」的風險。
這篇就把這件事講清楚:固定價、T&M、成效綁定,三種怎麼算、什麼時候用、雷在哪。
三種 FDE 計價合約模式怎麼算
固定價 (Fixed Price) 是把整個交付範圍打包成一個總價。合約簽下去,金額就定了,超時超工是供應商自己吸收。聽起來對甲方最安全,但代價是範圍必須先鎖死——而 AI 導入專案最不確定的,恰恰就是範圍。RAG 要接幾個資料源、Copilot 要覆蓋幾條工作流,往往做到一半才長出來。範圍一改,就進變更單、加錢、拖時程。
T&M (Time & Materials,時間與材料) 是按投入的人天計費,做多少算多少。它誠實地承認「需求會變」,適合探索期。缺點是甲方扛全部風險:做得慢、做不出來,錢照付。沒有清楚的驗收門檻,很容易變成無底洞。
成效綁定 (Outcome-based / 成效綁定) 把一部分報酬掛在可量測的結果上——不是「系統交付了」,而是「上線後月活覆蓋率達到 X%」「人工處理時數下降 Y%」。這是唯一一種把「有沒有人真的在用」的風險,實質綁回供應商身上的模式。
| 模式 | 計價方式 | 風險主要落在誰 | 範圍彈性 | 最適合的階段 |
|---|---|---|---|---|
| 固定價 | 總包一口價 | 供應商(超支自吸) | 低,需先鎖死 | 範圍明確、規格穩定的交付 |
| T&M | 按人天實作實算 | 甲方(投入照付) | 高 | 需求探索、PoC、長期共構 |
| 成效綁定 | 基礎費 + 達標分潤 | 供應商(綁上線採用) | 中 | 上線與採用本身就是目標時 |
為什麼「上線採用」該寫進合約
我們踩過的最痛的一種雷,是固定價專案在「系統驗收」那天就結案了。功能清單全部打勾,雙方簽字,款項結清。三個月後回訪,實際使用率個位數。合約上,供應商沒有違約——因為合約買的是「交付一套系統」,不是「讓人用起來」。
這正是 FDE 該存在的理由。Demo 很美不算數,上線且有人在用才算數。如果一份合約的驗收條件裡完全沒有「採用」這兩個字,那它在結構上就默許了「交付即結束」,把最難的最後一哩路整段推給甲方。
成效綁定之所以值得認真看,不是因為它便宜,而是因為它逼雙方在簽約當下就對齊「什麼叫成功」。要綁成效,就得先講清楚量什麼、怎麼量、多久內達標、達標與否誰認定。這場對話本身,往往就篩掉了只想賣一套系統、不想扛採用的供應商。
實務上怎麼混搭
真實專案很少純用一種。我們常見、也常用的組合是分階段換模式:探索期用 T&M 跑 PoC,把不確定性燒掉;範圍收斂後,主體交付轉 固定價 給甲方成本可預測性;再把上線後的採用指標,拆成一筆 成效綁定 的尾款或分潤。
這樣三種模式各自守住它最擅長的區間——彈性、可預測、責任綁定,而不是硬要一種模式撐完全程。
給正在選型的你一個實用的判斷點:別只比總價,去問每家供應商一個問題——「如果上線三個月後沒人用,你的報酬會不會少?」答案是「不會」的,你就知道那份看似便宜的報價,把風險留給了誰。
在 Tenten,我們傾向把採用指標寫進合約,而不是寫進簡報。工程師進場的目標從來不是交付一套會動的系統,是讓它在客戶的真實工作流裡活下來——所以我們願意把一部分報酬,壓在那件最難、也最該由我們扛的事情上。

Fluxos de trabalho com IA,
integrados à sua operação
Atuamos de forma incorporada (FDE e FDM) para construir os agentes e fluxos de trabalho de IA que sua equipe usa todos os dias. No ar em semanas, não em trimestres.