自建LLM軟體要價五到十倍：企業AI採購帳，先算誰來付治理那一欄

2026年10月3日，APPI News 刊出科技與 AI 產品設計工作者張饒輝（Lightman Chang）的長文，討論企業導入 AI 時該自建或外購。文中最具傳播力的數字，來自《科技新報》同日報導引述的工作流程軟體業者 Paul Fipps：依企業複雜度及其客戶經驗，自建大型語言模型（LLM）軟體的花費，通常是採用其公司工作流程自動化平臺的五至十倍。

這個倍數的出處輪廓必須先講清楚。Fipps 任職於平臺供應商，五至十倍是將自建 LLM 軟體與自家產品相比的經驗估計，報導未附獨立研究或通用成本模型。它反映的是一種產品銷售立場下的觀察，不能當作放諸四海的價格公式。但作為量級參考，它指向一個結構性事實：程式碼生成工具壓低了開發環節的單價，卻沒有壓縮整合、治理與維運的支出。

程式碼變便宜之後，成本往哪一段移動

文章的核心論點可以拆成成本結構語言。傳統軟體專案的成本大餅裡，寫程式只佔一段；需求確認、資料整理、系統介接、權限測試、例外處理與服務維運，構成另外幾段。AI 輔助開發壓縮的是第一段，其餘各段近乎原封不動。這與我們先前分析的三維大屏外包報價被 AI 重寫案例方向一致：當生成環節的邊際成本下降，總帳單的重心會往驗收與整合移動。

來源文中另有一個具體例子。原文作者回憶團隊投入數月開發一套儀表板，最終因機會成本改採現成方案。這是個人經驗，樣本數為一，但時間軸值得注意：數月級的開發投入對上現成方案的導入期，正是 TCO 比較裡最常被低估的時間成本。

四項條件：從策略差異到團隊承接

文章提出四項評估條件，逐項看它的帳。

第一是策略差異。當 AI 能運用企業特有的流程、資料或專業知識，支撐外部產品難以覆蓋的核心工作，自建的策略價值才值得進一步驗證。物流業者依多年累積的路線與貨物特性調度資源，屬於差異部分；新進員工報到、請假申請、一般文件分類，屬於共通部分，成熟產品可能更快滿足。判斷方式是把需求拆成共通與差異兩塊逐項檢查，若只有少數模組需要差異化，採購基礎平臺再自行開發周邊，可能比重做全部更省。

值得注意的是，文章明確指出「有專有資料」不足以證明該自建。資料能否合法穩定使用、品質是否支撐任務、更新與權限有無負責人，才決定它能否轉成能力。若資料長期缺漏或流程規則未統一，先投入模型開發只是把既有問題搬進新系統。

第二是總持有成本（TCO）。比較必須用相同期間、相同使用量、相同服務範圍。自建計入開發人力、模型與資料處理、監控、更新及事故處理；外購計入訂閱、導入、介接、資料移轉、供應商管理與合約終止後的轉換成本。原文點出一個常見錯誤：只拿一次性建置費對比年度訂閱費，會漏掉上線後持續發生的工作。企業自行管理權限、檢查 AI 輸出的工時也要計入。

第三是系統治理。NIST AI 風險管理框架（AI RMF）提醒先理解使用情境與預期目的，可作風險管理參考，但原文也強調它並非自建或採購的公式、認證或法規要求。

第四是團隊承接。自建不等於從頭訓練模型，外購也可能是平臺、雲端模型或委外開發，方案範圍不同，成本與責任歸屬也不同。程式生成工具再快，仍無法代替資料整理、介接、驗收與營運支持。

影響推演：誰受惠，誰承壓

傳導方向相當清楚。受惠端是工作流程自動化平臺與企業級 SaaS 供應商，五至十倍的敘事直接強化其「外購更省」的銷售論證，即使數字本身帶有立場。承壓端是企業內部主張自建的技術團隊，其提案將面臨更嚴格的 TCO 對帳要求，特別是被要求把治理工時、事故處理與轉換成本列入報價。

對企業採購方的實際影響，落在混合方案：共通部分採購、差異部分自建，配合分階段估算試行、擴大與維運費用。這種結構把資本支出從一次性大額開發，轉成訂閱費加周邊開發的組合，風險在於供應商鎖定成本會隨使用深度上升，合約終止後的轉換成本是 TCO 裡最難估的一欄。

收束判斷

這篇文章的價值不在給出答案，而在給出對帳框架：先定義要改善的流程與可衡量目標，再拆共通與差異，最後用同口徑算完整成本。五至十倍是一個有立場的量級參考，不是結論。可以確認的是，AI 降低的是寫程式的門檻，不是擁有並營運一套系統的門檻；後者的帳單，目前還沒有被任何工具壓下來。