為什麼漂亮的 AI Demo 上不了生產線?拆解 7 個真實死因與對應解法

「這個 demo 太驚人了。」季度會議上,主管把那段兩分鐘的螢幕錄影放了三次,全場點頭,合約很快就簽了。三個月後,那套 PoC 一行程式碼都沒進到生產環境。

這不是個案。我們盤點過手上經手的導入案,「demo 驚艷、上線難產」幾乎是常態。Gartner 那句「多數 AI 專案進不了生產」被引用到爛,但真正有用的問題不是失敗率多少,而是:AI PoC 上不了線的原因到底是什麼。它們不神秘,而且每一個都能提前拆解。

AI PoC 上不了線的原因,從來不是模型不夠聰明

模型早就夠聰明了。卡住 PoC 的,是模型以外那一層現場工程。以下是我們反覆撞見的 7 個死因,以及各自的解法。

死因一:資料在 demo 裡是乾淨的,在生產線是髒的。 PoC 通常餵的是一份被人工挑過、去識別化、格式統一的樣本。上了生產,同一個客戶名稱有六種寫法,PDF 是掃描檔,欄位定義三年沒更新,還有一張沒人敢動的 Excel 是全公司的真相來源。RAG 的檢索品質瞬間崩掉。解法:別在乾淨資料上做 PoC,第一週就接真實資料的髒版本,把清洗、去重、chunking 策略當成專案主體,而不是上線前的雜務。

死因二:權限,demo 用一個 admin 帳號讀全世界。 展示時大家共用一個能讀所有資料的帳號,很爽。生產環境裡,業務不能看 HR 的薪資,A 區不能看 B 區的客戶。當你把 row-level 權限、稽核軌跡補回去,原本的檢索邏輯和成本結構全部要重算。解法:權限模型放進 day one 的架構,而不是上線前一週;每個 chunk 都要帶存取控制的 metadata。

死因三:邊角案例吃掉信任。 Demo 走的是 happy path,問的都是準備好的問題。真實使用者第三天就會丟一個你沒想過的問題,系統一本正經地胡說,信任就沒了。可靠度不是被平均值決定的,是被最糟的那 5% 決定的。解法:上線前先蒐集長尾問題集、建 eval 資料集,把「不知道就說不知道」做成硬約束。

死因四:沒有整合,PoC 是一座孤島。 PoC 跑在獨立沙盒裡很漂亮。要上生產,得接 SSO、ERP、CRM、內部 API,還要過資安、排 IT 檔期。這一段常常比模型本身難十倍,也是最多專案卡死的地方。解法:把整合當第一等公民,早期就拉 IT 和資安進來,而不是最後才把成品丟過牆。

死因五:沒人用,工作流沒被改。 系統上線了,實際使用率 4%。因為它要求使用者離開原本的環境,多開一個分頁、多學一套介面。人不會為了你的 AI 改變習慣。解法:把 AI 嵌進使用者已經在用的地方——他們的 CRM、他們的 Slack、他們的表單,而不是蓋一個新入口。採用率是設計出來的,不是靠教育訓練逼出來的。

死因六:沒有 eval 與可觀測性,合規不敢放行。 「它到底有多準?」你答不出來,法遵就不會簽字。沒有評估、沒有監控、沒有幻覺率的數字,系統在合規眼裡就是黑盒。解法:把評估指標和線上監控做進系統,讓準確率、拒答率、延遲都是每天看得到的儀表板數字。

死因七:算不出 ROI,續約時被砍。 PoC 階段沒人記錄基準線。半年後要續約,財務問「到底省了多少錢」,沒人答得出來,預算就被砍。解法:導入前先量 baseline——這件事現在要花多少人、多少時間;上線後對照,把省下的工時換算成金額。ROI 是從第一天就開始記帳的,不是事後才補。

一張表看完 7 個死因

這七個死因有個共通點:全都不是在 PoC 那天冒出來的,而是被推遲到「之後再說」的現場工程。我們在 Tenten 做前線部署工程 (FDE) 的理由就在這裡——與其交付一份會鼓掌的 demo,不如讓工程師直接進場,把資料、權限、整合、採用一路扛到有人每天在用。Demo 很美不算數,上線且有人在用才算數。