資料庫並非為此而設計

背景

隨著生成式 AI 的興起，開發者開始嘗試讓 AI 代理（Agents）直接與資料庫互動。Arpit Bhayani 指出，傳統資料庫架構建立在「調用者是人類」的隱形契約上，假設查詢是可預測、經過審查且連線短暫的；然而，AI 代理的非確定性行為、自主寫入與長連線推理，正在從根本上挑戰這套運作了四十年的設計邏輯。

社群觀點

在 Hacker News 的討論中，絕大多數資深開發者對「讓 AI 代理直接寫入生產環境資料庫」的作法感到震驚甚至憤怒。反對者認為，這並非資料庫設計的問題，而是系統架構的基本原則被忽視。許多留言指出，即便對於人類開發者，直接操作生產資料庫也是極高風險的行為，通常必須透過 API 層或存儲程序（Stored Routines）來限制寫入權限。他們批評文章中提到的「軟刪除」或「冪等性鍵值」雖然是好的實踐，但若將其視為允許 AI 亂搞的保護傘，無異於讓實習生在沒有監管的情況下直接修改核心數據，是極度不負責任的行為。

然而，也有部分觀點從開發效率的角度出發，認為 AI 代理能為小型應用或單人專案帶來前所未有的開發速度。支持者提到，在非關鍵任務或實驗性專案中，這種靈活性允許快速迭代，只要具備良好的備份與回滾機制，風險尚在可控範圍。但此論點隨即遭到反駁，資深工程師們強調，在涉及隱私法規、財務數據或合規審計的場景下，AI 造成的數據錯誤可能導致法律責任歸屬不明，且資料庫回滾在現實生產環境中往往伴隨著巨大的業務損失，絕非日常維運的常態手段。

關於 AI 讀取權限的討論則相對溫和且具建設性。有開發者分享，讓 AI 代理對唯讀副本（Replica）進行分析查詢，確實能大幅提升非技術主管獲取報表的效率。不過，這也引發了關於「查詢正確性」的爭議：如果 AI 產生的 SQL 邏輯有誤，導致決策者基於錯誤數據做出判斷，責任該由誰承擔？社群共識傾向於將 AI 視為一種輔助工具，其生成的查詢仍需經過人類審查，或至少應在隔離的分析型資料庫（OLAP）中運行，以避免複雜的 AI 查詢拖垮生產環境的性能。

此外，討論中也觸及了數據建模的本質。有留言感嘆，現代系統的 Schema 往往混亂不堪，連人類都難以理解，更遑論 AI。如果能藉此機會推動更嚴謹的資料命名規範與註釋習慣，或許是 AI 浪潮帶來的意外收穫。總結而言，社群普遍認為 AI 代理不應直接挑戰資料庫底層，而應在現有的 API 與安全框架內運作，將 AI 視為一種「動態調用者」而非「資料庫管理員」。

延伸閱讀

• Postgres COMMENT ON: 留言中提到可用於加強 Schema 語義說明，幫助 AI 理解欄位意義的內建功能。
• Database Branching (Xata): 討論中提到的替代方案，透過寫入時複製（Copy-on-write）技術，讓 AI 在隔離的分支中操作數據，而非直接影響主庫。
• The Great Excel Spreadsheet: 留言者引用 The Daily WTF 的經典案例，警示數據錯誤可能帶來的災難性後果。