拆解上不了線的企業 AI PoC:7 個真實死因與對應解法

去年第四季,一家做工業零件的客戶把我們找去。會議桌上攤著六份 AI PoC 的結案報告,每一份的 Demo 當天都被主管點頭通過。真正上生產線的,是零個。

這不是他們特別倒楣。我們接手過的失敗案子裡,PoC 死掉的原因幾乎都不是「模型不夠聰明」。企業 AI PoC 上不了生產線,九成是死在工程細節與組織縫隙,而不是死在演算法。 Demo 環境是溫室,生產環境是野外。兩邊的資料、權限、流量、責任歸屬,根本是兩回事。

下面是我們反覆踩到、也反覆解掉的七個死因。每個後面,配一個可以馬上動手的解法。

為什麼 AI PoC 上不了生產線:七個真實死因

大多數 PoC 沒有可量測的上線門檻,所謂「成功」等於「主管看了滿意」。等要正式驗收,雙方對「夠好」的定義差了十萬八千里。

解法:動工前先把驗收寫成數字。例如「客服場景 top-20 意圖答對率 ≥ 90%、平均回應 < 3 秒、專員採納率 ≥ 60%」。沒達到,就不算上線。

PoC 用的是精挑細選、乾乾淨淨的問題。上線第一週,使用者丟進來的是錯字、中英混雜、掃描歪掉的 PDF、跨了兩年的合約版本。

解法:PoC 階段就從客戶真實工單裡抽一份「髒資料壓測集」,把最醜的那 20% 案例納進評測。先看它怎麼壞,再談上線。

Demo 常常用一份匯出的 Excel,人人看得到全部。上線要接真實系統:業務 A 不能看業務 B 的客戶、分行不能跨區。權限一進來,RAG 的檢索邏輯往往整段重寫。

解法:第一天就接真實的 row-level 權限模型,讓檢索帶著使用者身分跑,而不是等上線前才補。

PoC 是一個獨立網頁,做得很好看,卻沒人願意每天多開一個分頁。真正的工作流在 CRM、ERP、Teams 裡。

解法:PoC 就嵌進使用者已經在用的介面。在 CRM 裡按一個鈕、在 Teams 裡 @ 一下就能用,而不是另闢戰場。

上線那天沒人被指派當 owner。模型漂移、知識庫過期、上游 API 改版,幾個月後準確率無聲下滑,掉到沒人敢用。

解法:上線前就定好 owner、監控儀表板與回饋回收機制,把「誰在半夜收到告警」寫進交付清單。

我到某個現場時,系統一切正常,實際使用率 4%。因為它要求使用者改變習慣,卻沒讓任何一步變得更省事。

解法:別加一個工具,去改造一段既有流程。讓 AI 承接原本最煩的那一步,讓「不用它」反而比較麻煩。

Demo 跑一次查詢很美,也沒人算錢。放大到每天上萬次,token 成本和延遲直接讓專案在財務會議上被砍掉。

解法:PoC 階段就做單位經濟。算清每次查詢的成本、設好延遲預算,早早決定哪些走大模型、哪些用小模型或快取。

死因	Demo 時的假象	上線時的真相	對應解法
驗收模糊	主管滿意	沒人說得清「夠好」	先寫數字化上線門檻
邊角案例	精選乾淨題	錯字、混語、爛檔案	用真實髒資料壓測集
資料權限	一份 Excel 全看	分權限、分區域	第一天接 row-level 權限
整合孤島	獨立漂亮網頁	沒人特地打開	嵌進 CRM／Teams 現有介面
無人維運	上線就結案	準確率悄悄下滑	指定 owner + 監控 + 回饋
沒人用	技術指標全綠	使用率 4%	改造流程,而非新增工具
成本延遲	單次查詢很美	規模化成本爆表	早做單位經濟與延遲預算

這七個死因有個共通點:全部都不是「跑一次 Demo」能發現的,而是要有人真的把系統推到生產、扛到有人天天在用,才會浮出來。

我們做 FDE(前線部署工程),就是把工程師派進客戶現場,從第一天起就把這七個縫隙當成交付的一部分,而不是上線後的意外。說到底,Demo 很美不算數;上線,而且有人天天在用,才算數。