為什麼企業 AI 導入需要 FDE?從「Demo 很美卻上不了線」談起

FDE(Forward-Deployed Engineering,前線部署工程)是一種把工程師直接派進客戶現場、對「系統真正上線且被使用」負責到底的企業 AI 導入交付模式——它的驗收標準不是 Demo 通過,而是生產環境裡每天有人在用。

上個月我們接手一個案子。客戶花了一季做完 PoC,模型準確率 92%、簡報那天全場點頭,董事會拍板全面推。三個月後我們進場,打開後台一看:日活躍使用者是零。不是模型不準,是它從頭到尾沒被接進任何一條真實的業務流程。

這不是特例。我們看過太多企業 AI 導入停在同一個地方:Demo 很美,卻上不了線。而「企業 AI 導入為什麼需要 FDE」這個問題,答案就藏在這個斷層裡。

PoC 過關,生產線卻沒動:落地失敗的四個結構性原因

PoC 失敗很少是因為模型爛。真正卡住的地方,幾乎都在模型以外——那些 Demo 環境刻意迴避、但生產環境無法迴避的東西。

這四件事有個共同點:沒有一件能靠「買一套更好的產品」解決。資料要有人一張表一張表去對;流程要有人蹲在專員旁邊看他到底怎麼點;責任邊界要有人跟法遵、跟資安一條一條談。它們都需要有人站在客戶的現場,把系統一寸一寸接進真實流程。這正是標準產品交付永遠補不齊的那一哩。

企業 AI 導入為什麼需要 FDE

因為前面那四道坎,本質上都不是產品問題,是部署問題。

傳統軟體交付把「賣產品」和「用起來」切成兩段:廠商負責交付一個通過驗收的系統,客戶自己想辦法用起來。這套邏輯在 SaaS 時代還勉強成立,因為功能相對標準。但企業 AI 不一樣——同樣一套 RAG 知識系統,放進金融法遵和放進製造排程,要接的資料、要守的規則、要說服的人,完全是兩回事。標準產品的最後一哩,永遠得有人在現場走完。

FDE 就是把這一哩收進交付責任裡。工程師不是交完 Demo 就走人,而是進駐客戶現場,直接改資料管線、改流程、改權限,盯著使用率從個位數往上爬。我們給自己畫的驗收線很簡單:上線,而且有人每天在用。做不到,這個案子就沒交付完。

回到開頭那個日活為零的案子。我們沒有換模型。做的是把它接進客服工單系統、讓答案直接出現在專員原本的操作介面裡、再陪著客服主管重寫三版標準話術。六週後,日活躍從 0 長到 68 位專員,平均處理時間少了四成。系統沒變聰明,是它終於被放到對的位置、對的流程上。

「上線且有人在用」才是唯一驗收標準

這句話聽起來像口號,但它其實是一個很硬的篩選器。

用這個標準,你會問出完全不同的問題:不是「模型準不準」,而是「錯的時候誰負責」;不是「功能多不多」,而是「員工願不願意每天打開它」;不是「Demo 順不順」,而是「三個月後還有多少人在用」。這些問題在 PoC 階段全都問不出來,因為 PoC 的設計初衷,就是繞過它們。

所以企業 AI 導入真正的風險,從來不是選錯模型,而是把「通過 Demo」誤當成「完成導入」。這兩者之間隔著的工——資料、流程、責任、信任——正是 FDE 這個類別要補上的。承認這一點,你採購的方式就會變:你要找的不是一套最漂亮的 Demo,而是一組願意跟你一起把上線扛完的人。

我們在 Tenten 做企業 AI 導入時,習慣一開始就把驗收線畫在上線之後:讓工程師進場,把 AI Copilot 和 Agentic 工作流真正接進客戶每天在跑的系統,盯到採用率長出來為止。Demo 很美不算數,上線且有人在用,才算。