AI 導入前，先問你的基礎設施撐不撐得住

上個月，全球最大的程式碼託管平台 GitHub 的可用性跌到了九成。

九成聽起來還好？換個說法：每天有將近兩個半小時，你的工程師可能推不了程式碼、跑不了自動測試、看不到最新版本。如果你正在導入 AI 輔助開發，這個數字會更痛，因為 AI 不會等。

這件事值得每一個正在規劃 AI 導入的決策者注意。不是因為 GitHub，而是因為它揭示了一個大多數人還沒意識到的結構性問題。

發生了什麼事

GitHub 的技術長公開承認了三起重大事故。根因不是伺服器不夠，而是一個更根本的問題：AI 編程工具產生的流量模式，跟人類工程師完全不同。

人類一天推幾次程式碼，有上下班、有週末。AI 代理是 24 小時不間斷、每秒大量呼叫、同時操作多個專案。三個月內，光一個 AI 工具的流量就成長了六倍。

GitHub 的基礎設施是為人類設計的。當使用者變成 AI，流量不只是變大，而是形狀完全變了。就像一條設計給轎車走的公路，突然湧入大量聯結車，問題不是車太多，是路的結構不對。

你可能覺得「我又不用 GitHub」。但請想一下：

你正在導入的每一個 AI 工具，都依賴某個基礎設施。 雲端運算、資料庫、API 服務、網路頻寬。這些基礎設施的設計者，在規劃容量時假設的使用者是人類。

當你讓 AI 代理接手一部分工作，流量模式會改變。AI 不會只在上班時間運作，不會累了休息，不會「先看一下再說」。它會持續、密集、大量地存取你的系統。

如果你的 IT 基礎設施沒有為這個改變做準備，你會碰到的不是「AI 不準」的問題，而是「AI 很準但跑不動」的問題。

這不是假設性的風險。我們在協助客戶評估 AI 導入可行性時，超過半數的案例在基礎設施盤點階段就發現瓶頸：資料庫的連線池是十年前按人工查詢頻率設定的、網路頻寬只夠應付辦公室的日常使用、MES 系統的 API 根本沒有為高頻自動化呼叫做過壓力測試。

這些問題不會在廠商的 demo 裡出現，因為 demo 環境是乾淨的。它們只會在你真正把 AI 接上生產系統的那一天爆發。

GitHub 的困境有一個組織面的教訓。

被微軟收購後，GitHub 失去了獨立的執行長，被併入微軟的 AI 部門。結果是：沒有人拍板做「基礎設施全面重新設計」這種大決策，團隊只能做最安全的短期修補。

每一季的修補都是合理的。但合理的季度決策加起來，就是戰略性的落後。

這個模式在製造業裡太常見了。數位轉型推了一年，每個月的進度報告都是綠燈，但整體離目標越來越遠。因為沒有人願意停下來說：「我們的方向可能根本就錯了，需要重新設計。」

如果你正在規劃或執行 AI 導入，建議把這三個問題加進你的檢查清單：

一、你的基礎設施是為誰設計的？

現有的 ERP、MES、資料庫、網路架構，當初設計時假設的使用者是人類操作員。AI 代理接手後，存取模式會不會改變？你的系統撐得住嗎？

二、你的 AI 供應商有沒有告訴你這件事？

大多數 AI 廠商在 demo 時展示的是模型的能力，不會告訴你部署後對基礎設施的衝擊。這不是他們的惡意，是他們的盲區。但這是你的風險。

三、你的轉型計畫有沒有「停下來重新評估」的機制？

GitHub 的教訓是：持續修補不等於持續進步。你的轉型計畫裡，有沒有定期回頭問「方向對嗎」的機制？還是只有問「進度到哪了」？

AI 工具越來越強，這是事實。但「工具很強」不等於「導入會順利」。

在工具和你的工廠之間，有一整層基礎設施。這層東西不性感、不會出現在廠商的簡報裡、也不會是你的 AI 顧問主動提起的話題。

但它會決定你的 AI 專案最後是真的落地，還是卡在「技術驗證成功、正式上線遙遙無期」的尷尬狀態。

技術的問題，往往不是技術本身。

延伸閱讀：如果你對 AI 導入的組織面挑戰有興趣，可以看為什麼 AI 導入失敗率超過七成。關於轉型結束後的持續進化問題，這篇也值得一讀。