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

「這上週 Demo 明明還好好的。」專案經理把筆電轉向我,螢幕上是三個月前驚艷全場的問答介面。現在它每問十次錯四次,團隊早就沒人再登入。

這不是特例。我們接手的救火案裡,超過一半是同一個劇本:PoC 在會議室裡光鮮亮麗,一推上生產線就崩。所以先講結論——AI PoC 上不了生產線的原因,幾乎從來不是模型不夠聰明,而是 Demo 從第一天就沒有為「真實資料、真實系統、真實使用者」設計。 以下是我們反覆踩到的 7 個死因,以及每一個對應的解法。

死因一:Demo 餵的是乾淨資料,生產線餵的是髒資料

Demo 那天用的是精挑細選的十筆漂亮樣本。生產環境呢?欄位缺一半、同一個客戶名有五種寫法、關鍵資訊藏在掃描 PDF 和某個離職同事的 Excel 裡。RAG 答得準不準,八成取決於資料品質,不是模型。

解法:PoC 第一週就接真實資料的「髒版本」,別接美化過的樣本。先做資料盤點與清洗管線,把「資料就緒度」當成上線的硬門檻,不到標就不排上線日。

死因二:Demo 講給老闆聽,系統卻要給第一線用

決策者在 Demo 上點頭,不代表現場員工會用。我們見過簽約很快、使用率卻只有 4% 的系統——不是產品爛,是它多開了一個要另外登入的網頁,沒人想繞路。

解法:做採用設計。鎖定 3 到 5 個第一線的高頻痛點,把 AI 嵌進他們本來就在用的介面裡,少一次點擊就多一分採用。

死因三:85% 準確率在 Demo 過關,在產線是事故

Demo 錯一題,大家笑一笑。放款、病歷、報價單上錯一題,是賠償與信任崩盤。

解法:給每個答案配信心分數,低於門檻自動轉人工覆核,並把「我不知道」設計成合法輸出。寧可少答,不要自信地答錯。

死因四:Demo 是一個獨立網頁,生產是一張系統網

Demo 只要能跑就好。生產要接 ERP、CRM、SSO、權限控管、稽核軌跡,任何一個接不上都能讓專案卡死。

解法:在 kickoff 當天就畫出整合清單與資料流,把每一條串接列為驗收項,而不是上線前才發現要打通六個系統。

死因五:沒人在 Demo 問資安,一到生產全都跳出來

PoC 現場沒人問 PII 怎麼處理、資料會不會送到外部 API、稽核怎麼查。等法遵和資安介入,往往整個架構要重來。

解法:讓資安與法遵在專案第一天就進場,把資料落地、遮罩、稽核當成設計前提,而不是上線前的補丁。

死因六:一次查一筆很快,一天幾萬筆就爆

Demo 查一筆,零點幾秒、幾乎免費。生產每天幾萬筆,token 成本與延遲同時失控,財務和使用者都受不了。

解法:上線前先算清成本模型,加上快取,並做分層——簡單案例交給小模型,複雜案例才動用大模型。省下的常是一個數量級。

死因七:上線不是終點,沒有維運迴路就會慢慢爛

模型會漂移、知識會過期、新產品上市舊答案就錯了。沒有人負責監控,三個月後系統自己爛給你看。

解法:建立監控儀表板與使用者回饋迴路,明確指派維運負責人,把再訓練與知識更新排進固定節奏。

死因總表:AI PoC 上不了生產線的原因一次看

看得出來,這七題沒有一題是「換更強的模型」能解的。它們是工程、流程與人的問題,而這些問題只有人真的進到現場才看得見。

我們在 Tenten 做 FDE(前線部署工程)時,判斷一個案子能不能上線,從來不是看 Demo 多漂亮,而是看這七題有沒有人認領。工程師直接進客戶現場,把資料、整合、採用一起扛到有人每天在用為止——因為 Demo 很美不算數,上線且有人在用才算數。