AI 批評者喜歡抨擊這項技術無法產生有意義的商業成果，常常引用 MIT NANDA 的研究，該研究指出企業 AI 解決方案的失敗率高達 95%，或引用 IDC 的說法，「過去兩年來，只有 9% 的歐洲、中東與非洲組織能從大多數 AI 相關專案中獲得可衡量的商業成果。」

許多 AI 懷疑論者忽略了 AI 原型本質上屬於實驗性質；並非所有這些專案都真的打算超越測試階段。然而，5% 的成功率仍然令人難堪。

問題出在哪裡？

有兩個原因。首先，大多數組織在沙地上打造 AI 原型；也就是說，用來建置早期應用程式的資料基礎架構無法支援後續移轉至正式上線。同時，負責在正式環境中管理這些應用程式的營運團隊，往往缺乏足夠人力來因應工程團隊日益增加的產出。

原型基礎架構 ≠ 正式上線基礎架構的 4 個原因

當被問到為什麼這麼多 AI 原型無法進入正式上線階段時，Phillip Merrick（pgEdge 共同創辦人、CPO 暨董事長）告訴 The New Stack，資料基礎架構是主因。

他具體指出，原型環境無法滿足大型企業對正式上線的要求，並列出四個主要缺點。

首先，Merrick 表示原型環境缺乏組織從原型移轉至正式上線所需的部署彈性。

他承認，廠商管理的雲端平台看似是原型的顯而易見選擇，因為團隊可以快速上手。但他警告，這些平台缺乏支援 AI 應用正式上線所需的技術能力，尤其是在安全性、合規性與治理方面。特別是醫療、金融或其他受管制產業，廠商管理的雲端平台往往缺少自我管理雲端或本地環境所具備的嚴格管控。

「你必須能選擇最終要把這個 AI 原型部署在哪裡。」

Merrick 認為，彈性與安全性息息相關。「你必須能選擇最終要把這個 AI 原型部署在哪裡。」

同樣地，當要移轉至正式上線時，Merrick 表示廠商管理的雲端平台可能在企業與區域層級引發資料主權挑戰。

「你的資料層顯然是用來執行這項管控的地方，」Merrick 指出。但他表示，大多數團隊用於原型的環境會讓情況變得混亂：「如果是在不知名的雲端、不知名的地區的廠商管理平台上，那你就失去了資料主權。」

最後，Merrick 關注可靠性問題，指出 AI 原型若沒有高可用性的保障，就無法移轉至正式上線。例如，當需要升級資料庫或更換硬體時，能否做到零停機時間？

「在廠商管理的雲端世界裡，答案幾乎總是否定的，」Merrick 說，並重申他的觀點：將 AI 應用從原型移轉至正式上線需要企業級基礎架構。

那麼開發人員為什麼要在無法正式上線的地方進行原型開發？

如果資料基礎架構的選擇是阻礙開發人員將 AI 原型移轉至正式上線的原因，那麼他們為什麼還是一再從錯誤的地方起步？

如 Merrick 所言，許多人被廠商管理雲端平台的易用性所吸引。「這些原型環境確實讓人很容易上手，」他說。但原型捷徑似乎無法在長期帶來回報，因為最終還是得由其他人負責讓這些原型做好正式上線的準備。

不過，Merrick 並不責怪開發人員尋求捷徑。相反地，他表示原型遊樂場與正式上線戰場之間存在落差，導致開發人員無法理解後續將原型正式上線所需的條件。

更多 pgEdge 文章刊登於 The New Stack

多年前，他說，工具選擇主要由上而下決定，沒有開發人員的參與：「然後從 15–20 年前開始，開發人員相當合理地重新奪回了選擇自己工具的權力。」

Merrick 認為，現在的問題在於開發人員只針對原型環境做出工具選擇，而沒有預期正式上線的需求。內部分工意味著開發人員往往只負責打造原型，之後便將接力棒傳給完全不同的營運團隊來進行正式上線：

「結果就是，在某些組織裡，你真的沒有從開發人員做出初始選擇開始，一直到了解正式上線需求之間的貫穿線。」

對 Merrick 來說，這個落差正是 AI 專案開始崩解的地方，因為團隊試圖將 AI 原型從方便但不足的廠商管理雲端平台，移轉到符合部署彈性、安全性、資料主權與高可用性要求的企業級資料基礎架構。

「但如果你做出正確的資料基礎架構選擇，就不會有這個落差，」他說，「因為你會有從原型到正式上線的貫穿線。」

他指出 Postgres 是最能幫助開發人員跨越這個鴻溝的資料基礎架構，稱其為「資料庫界的瑞士刀」，因為它具有可擴展性、完全開源的特性，以及處理從非結構化資料到向量嵌入再到地理空間資料等多樣化資料管理問題的能力。

Merrick 也指出，Postgres 的執行位置與方式同樣重要，再次強調許多廠商管理雲端環境的限制，這些環境往往缺乏滿足資料需求所需的治理管控，以及移轉至合規本地或自帶雲端環境所需的部署彈性。

但選擇正確的資料基礎架構只能解決一半的問題

Merrick 表示，大多數組織忽略了另一半的問題：人力，或者更精確地說，資料庫管理員（DBA）及其日益增加的工作量。

根據 Stack Overflow 2025 開發者調查，84% 的受訪者使用 AI 工具，高於前一年的 76%。同時，Supabase 表示，其平台上超過 60% 的資料庫是由「某種 AI 工具」啟動的。Merrick 指出，這種生產力的爆炸性成長伴隨著一個問題：沒有足夠的 DBA 來跟上。

「開發人員的生產力出現了巨大、巨大的躍升，」他解釋。「但你必須有辦法在正式上線端進行管理；這些資料庫不能無人監控。」他表示，在代理式工程增加更多資料庫之前，營運與管理團隊已經在努力追蹤現有的 Postgres 資料庫：「誰來管理它們？」

他認為，是時候讓代理式營運趕上代理式工程了。

AI DBA 代理可賦予人類「超能力」

如果 Merrick 似乎建議組織尋求完全自主的 DBA 代理來接手，他表示產業還沒準備好：

「世界還沒有準備好由 AI DBA 代理管理的完全自主資料庫。但目前存在巨大的資源短缺與生產力問題，而 DBA 只能管理一定數量的資料庫，」他解釋。同時，「新的 AI 應用需要更多資料庫才能正式上線。」

「世界還沒有準備好由 AI DBA 代理管理的完全自主資料庫。」

那麼組織要如何增加營運能量？

Merrick 表示，DBA 應該尋求新的 AI DBA 代理，不是讓它們接管，而是賦予他們「超能力」，以更少的繁瑣手動工作來監控與管理更多資料庫。

pgEdge 的 Ellie 就是一個例子。作為 pgEdge AI DBA Workbench 的一部分，Ellie 是一個擁有 21 個 MCP 工具的 AI 代理，可以執行 EXPLAIN ANALYZE、檢查結構描述、查詢歷史指標，並逐步執行多步驟診斷流程。當資料庫出現問題時，Ellie 會找出問題、診斷問題，並以可供人類 DBA 審核的 SQL 程式碼形式提供解決方案。「當你審核後同意這是正確的行動方案時，你只要按下播放按鈕，代理就會將該 SQL 程式碼執行到資料庫中，問題就解決了，」Merrick 解釋。

透過這種方式，Ellie 應該能為營運團隊帶來更多能量，而 Merrick 堅稱組織正缺乏 DBA 專業人才。根據他的觀點，產業預測指出，41% 的現職資料庫專業人員打算在未來十年內離開這個產業，其中一半將退休，其餘則尋求其他工作。

「代理……實際上可以比人類更快、更有效地回應這些警示。」

Merrick 認為，如果沒有 AI 代理，DBA 的工作是繁瑣、勞累且耗時的。如他所言，資料庫可能原本運作正常，但當出現問題時，故障可能會影響多個應用程式；此時 DBA 必須瀏覽監控資料來觀察與診斷問題， essentially 在大海撈針。

「代理，」他說，「實際上可以比人類更快、更有效地回應這些警示。」

更好的基礎架構與人力：改善 AI 原型成功率需要兩者兼具

在幾乎任何情境中，AI 都會引發品質與數量的疑問，企業 AI 專案也不例外。代理式工程意味著開發人員現在可以產出更多，但所有這些原型並不會直接飛入正式上線。基礎架構與營運人力的限制正在製造障礙，導致許多 AI 原型失敗。

對 Merrick 來說，要順利從原型過渡到正式上線，不只需要優秀的 AI 工具，還需要可正式上線的資料基礎架構，以及能跟上代理式工程熱潮的代理式營運。

YOUTUBE.COM/THENEWSTACK

科技發展迅速，別錯過任何一集。訂閱我們的 YouTube 頻道，即可觀看所有 podcast、訪談、示範與更多內容。

Group Created with Sketch.