AI 專案為什麼失敗?我們看過的五種死法

先講一個不太舒服的事實:AI 專案的失敗率,遠比供應商的簡報和媒體的成功案例讓你以為的高。我們的位置比較特別——既是接案團隊,也自己經營 AI 產品線(行銷工具、影片自動剪輯引擎、訂閱服務),所以我們看過的失敗是雙面的:客戶專案的失敗,和我們自己產品的失敗。摔過的跤夠多,才敢寫這篇。

好消息是,這些失敗高度重複。看多了之後你會發現,AI 專案的死法翻來覆去就那五種,而且每一種都在動工前就看得出徵兆、都可以預防。這篇把五種死法攤開來講,附上我們自己的解法。

死法一:目標模糊——「我們也想用 AI」

最常見的開場白:「競爭對手都在做 AI,我們也要做點什麼。」這種專案從第一天就注定失敗,因為它沒有可以驗收的目標。做出來的東西不管好壞,都沒人說得出「這算成功嗎」,於是專案在示範完 demo 之後就安靜地死掉,預算變成一次昂貴的公關活動。

解法很老派:動工前必須把目標寫成一句可以量測的話。「客服首次回覆時間從 4 小時降到 10 分鐘」「報價單產出從 3 天縮到半天」——寫不出這句話,就代表還沒想清楚,先回去盤點流程,不要動工。我們接案時如果客戶說不出這句話,會直接把訪談當成第一階段交付物,先幫他找到這句話再談開發。

死法二:資料太髒——AI 只是把混亂放大

「我們有很多資料」是我們聽過最危險的一句話。實際打開來看:客戶資料散在三個系統、欄位定義各自表述、歷史紀錄一半是空的、知識文件最後更新是四年前。AI 不會修理你的資料,它只會忠實地把資料的問題放大成輸出的問題——知識庫過時,機器人就理直氣壯地講過時的答案。

解法是把「資料整備」當成專案的正式階段,而不是開發前順便做的雜事。我們的經驗值:多數 AI 專案裡,資料清理與整理佔掉三到五成的工時。如果供應商的報價裡完全沒有這一塊,不是他有魔法,是他還沒發現,或者打算發現的時候跟你追加。

死法三:期待錯位——把 AI 當成不會出錯的員工

這一種死得最冤。專案其實做得不差,準確率九成,但決策者的預期是「全自動、不出錯」,於是那一成的錯誤變成否定整個專案的理由,不了了之。反過來的版本也有:基層被告知「AI 會取代你們的工作」,於是消極抵制,系統上了沒人用,數據爛掉,專案自然死亡。

解法是在動工前就把兩件事講清楚。對決策者:LLM 是機率性系統,一定會犯錯,所以設計重點是「錯誤發生時有沒有被接住」——人工覆核、信心門檻、升級路徑,這些防護網是規格的一部分,不是選配。對使用者:明確定義 AI 接手的是哪些雜事、人的角色怎麼升級,讓第一線覺得這是幫手不是刑具。期待管理不是溝通技巧,是專案設計的一部分。

死法四:沒人負責——AI 專案的孤兒化

AI 專案有個結構性的尷尬:IT 說這是業務需求,業務說這是技術專案,老闆說大家配合一下。結果就是沒有一個人的績效跟這個專案綁在一起。上線之後,知識庫沒人更新、錯誤回報沒人看、模型帳單沒人管,系統半年後變成沒人敢關也沒人在用的殭屍。

解法只有一個:指定一個有名字的 Owner,而且是業務端的人,不是 IT。因為 AI 系統的品質來自業務知識的持續餵養——客服主管才知道知識庫哪條答案過時了,IT 不會知道。這個 Owner 要有明確的維運時間配額,「請大家有空幫忙看一下」等於沒人看。

死法五:成本失控——上線那天才開始付錢

傳統系統開發完就是維護費,AI 系統不一樣:每一次呼叫都在燒模型費用。我們看過的失控案例都是同一個劇本——PoC 階段用量小,帳單可愛;正式上線用量放大百倍,月帳單直接把商業模式打穿。尤其是每次都用最強模型、提示詞塞滿整份文件的粗暴設計,錢燒得又快又冤。

我們自己的產品線每個月都在付模型帳單,所以這件事我們管得很細:依任務難度分級用模型、快取重複查詢、控制上下文長度、離峰批次處理。這些手法在LLM 成本控管實戰裡有完整展開。原則是:上線前就要算出「單次服務成本 × 預估用量」,確認商業上撐得住,而不是上線後看帳單驚嚇。

AI 專案很少死於技術不行,幾乎都死於工程以外的地方:沒想清楚、資料沒整、期待沒對齊、沒人認領、帳單沒算。

動工前的五個問題

成功的定義能不能寫成一句可量測的話?
需要的資料存在嗎?乾淨嗎?誰負責整理?
決策者知道 AI 會出錯嗎?錯誤的接手機制設計了嗎?
上線後誰是 Owner?他的時間從哪裡來?
單次成本乘上預估用量,商業上算得過來嗎?

五題都答得出來,失敗率就砍掉一大半。答不出來也沒關係,那正是該停下來補功課的訊號——停在動工前,比停在燒完預算後便宜太多了。如果你想找人一起把這五題想清楚,這正是我們AI 應用開發服務每個案子的起手式。