中小企 AI 項目為何失敗：六個反覆出現的模式

問題極少出在模型本身，幾乎全部出在項目結構。

AI項目管理 AI導入中小企AI 項目風險

過去兩年，以獨立 AI 工程師身分為企業交付自動化工具，同時營運自己的 LLM 平台。接觸過的導入案例中，失敗的項目有一個共通點：問題極少出在模型本身，幾乎全部出在項目結構。以下六個模式，在不同企業身上反覆出現。

一、目標定義在「導入 AI」，而非「解決哪個流程」

失敗項目的起點常常是一句「我們也要用 AI」。這句話缺少受詞——用在哪個流程、取代哪段人力、以什麼標準算成功，全部未定義。結果是項目做出了一個「AI 功能」，而業務流程原封未動。

可行的起點是一個具體問題：「同事每天花兩小時整理郵件附件裡的報告」。這句話自帶範圍、自帶成功標準、自帶投資回報的計算基礎。

「既然做了 A，順便加 B 吧」——每一次「順便」都在延後交付日，並稀釋原有預算。按時計費的合作模式會放大這個問題：範圍膨脹對承包方是收入，對買方是失控。

預防方法是在動工前把交付物寫成清單，清單以外的需求進入「第二期」討論，而非塞進當期。關於計價模式的完整分析，見固定範圍計價與按時計費一文。

AI 自動化的原料是企業自己的資料：郵件、報告、表格、歷史紀錄。常見情況是資料散落在個人電腦、多個雲端帳號、紙本與掃描檔之間，格式互不相容。項目啟動後，前期時間全部消耗在找資料、清資料，買方看見的進度是零，信心隨之流失。

在簽約前先回答一個問題：這個流程的輸入資料，現在放在哪裡、誰能取用、格式是否一致。答案模糊，項目時程就會模糊。

大型語言模型的輸出帶有機率性質，偶發錯誤是系統特性，並非工程失誤。成熟的設計把這個特性納入流程：高風險環節保留人工覆核，低風險環節全自動，錯誤發生時系統主動標示而非靜默通過。

期望零錯誤的項目，會在第一次錯誤出現時被判定為失敗——即使整體效率已提升數倍。驗收標準應該定義「錯誤如何被發現與處理」，而非「錯誤不存在」。

展示用的 demo 與生產環境之間有一段距離：demo 使用精選資料、理想流程、無並發壓力。判斷方法很簡單——要求對方用你自己的資料跑一次，並且同一份輸入跑多次，觀察輸出是否穩定。完整的評估方法，見如何評估 AI 服務商的提案。

工具上線那天，項目才走到一半。API 費用誰付、系統掛了誰看、供應商倒閉或轉行了怎麼辦——這些問題在簽約時無人提起，在交付後半年變成真實成本。原始碼移交與知識轉移是這個問題的結構性解法。

六個模式的共通解法，是把「AI 項目」還原成「流程改造項目」：先定義流程與成功標準，再談技術。技術選型是第五步，而多數失敗項目把它當成第一步。

先縮範圍。挑資料最完整的一個子流程先交付，其餘列入第二期。停損點應該以「里程碑」為單位，而非以「整個項目」為單位——這也是里程碑付款結構的價值所在。

三個條件：重複發生、輸入輸出可以用文字描述清楚、偶發錯誤的代價可承受（或可用人工覆核攔截）。三者齊備，自動化的成功率會高很多。

Levi係駐香港嘅獨立AI工程師，為香港推動AI數碼轉型嘅中小企構建生產級LLM應用、RAG pipeline及文件智能系統。