title: “資料庫被 AI 刪了？不，是你決定的：從一則爆紅貼文看開發者的責任”
上週，推特上一則貼文爆紅。一位開發者貼出對話紀錄，指控 Cursor / Claude 的 AI agent 刪掉了公司的 production 資料庫。他對著 AI 質問：「明明告訴你永遠不要執行這個操作，為什麼你還是做了？」然後試圖從 AI 給出的回答中，解讀到底是自己的錯，還是這證明了 AI agent 的危險。
這則貼文在技術圈引起軒然大波，上千則轉推，討論 AI 的「虛假行銷」和「糟糕的客戶支援」。但作者 Ibrahim Diallo 在部落格中提出了一個尖銳的問題：
「為什麼你的 API endpoint 可以刪掉整個 production 資料庫？」
如果 AI 沒有呼叫那個 endpoint，遲早也會有人不小心呼叫它。這就像在車子儀表板上裝一個自毀按鈕——你有一百個理由不按它，因為你喜歡你的車。但只要一個好奇的孩子掙脫安全座椅，看到那個紅色大按鈕，他一定會按下去。然後你也不能質問一個小孩的「邏輯」，他只會說：「因為我按了。」
這不是 AI 的錯。這是你設計的問題。
推文下方的討論區也呈現兩極化：有人分享自己的 agent 經驗，說「我的 Cursor agent 也試圖刪過東西，但因為我沒有給它 production 權限，它只能發出 403。」也有人反駁：「你不給 AI 權限——但如果 production 問題需要 AI 修時怎麼辦？」這段對話正好點出了核心矛盾：問題不在 AI 會不會犯錯，而在你給了 AI 多大的犯錯空間。
Diallo 選擇了一個更直接的角度切入。他不討論 prompt 多精妙、不討論 agent 框架多穩定。他只問一個所有人都假裝看不見的問題：為什麼那個 API endpoint 存在？
一個 2010 年的故事，和現在一模一樣
Diallo 分享了他在 2010 年的一段親身經歷。那時他在一家公司工作，部署流程非常陽春：使用 SVN 做版本控制，要上線時，把 trunk（相當於 master 分支）複製到標記日期的 release 資料夾，再複製一份命名為「current」，這樣存取 current 資料夾永遠拿到最新的版本。
某天部署時，他意外複製了 trunk 兩次。他想用 CLI 修正，編輯上一行指令刪除重複的那份。結果他編輯錯了行，刪掉的是 trunk 而不是重複的資料夾。當天稍晚，另一位開發者發現 trunk 不見了，整個團隊陷入混亂。
接下來發生的事才是重點：管理階層沒有開檢討大會、沒有追究責任。團隊的 lead developer 查出 log 發現是 Diallo 動的手，給他的任務很簡單——寫一個自動化部署腳本，讓這種錯誤無法再發生。當天下班前，團隊就有一套更穩健的部署流程了。這個流程後來成長為完整的 CI/CD pipeline。
Diallo 的結論是：自動化消除了人工作業中愚蠢的失誤。但注意，2010 年的故事裡，大家沒有去質問「為什麼 SVN 沒有阻止我們刪除 trunk？」因為問題很明顯——是人工流程太脆弱。
這一段故事的重要性不在於 SVN 的技術細節，而在於團隊的反應方式。沒有人說「這個版本控制系統有安全漏洞。」沒有人要求 SVN 增加「防止誤刪 trunk」的功能。他們做的唯一一件事是——改變自己的流程。
這個對比放到 2026 年的今天，特別刺眼。資料庫被刪後，討論的焦點幾乎全在 AI agent 的行為上：為什麼它不遵守指令？為什麼它的 reasoning 這麼差？沒有人問：為什麼這個團隊的 production 資料庫可以被一個 API 呼叫整個清空？
推特上的真實對話：還原現場
在進一步討論之前，值得還原一下推特原文的更多細節。那位開發者貼出的對話紀錄大致是這樣的：
他給 Cursor agent 一個任務，agent 在執行過程中呼叫了一個看似相關的 API endpoint。這個 endpoint 的名稱沒有明確標示「DELETE ALL」之類的危險字眼——也許它叫 resetDatabase、也許叫 cleanup——但實際效果是清空了整個 production 資料庫。
這不是 agent 憑空生出一個惡意 endpoint。agent 只是在 codebase 中找到了這個 endpoint，然後「合理」地呼叫了它。
在 HackerNews 的討論串中，有人做了更犀利的觀察：「你把一個沒有 guardrail 的 API 放在那裡，然後給 AI 一個『幫我修 production 問題』的 prompt——你覺得它會怎麼做？它會用它能用的工具。而你能用的工具裡面，就包含了一個可以摧毀一切的 endpoint。」
另一個高讚回覆則指出：「我看了那個推文的程式碼片段，那個 endpoint 甚至沒有 authentication check。任何拿到 token 的人——包括 AI——都能呼叫它。」
這才是真正的問題核心：不是 AI 太笨，而是系統太脆弱。
從自動化到 AI：同樣的教訓，不同的包裝
這個故事放到今天來看，荒謬的一致。
2010 年的 SVN 不會「思考」，它只會執行你給的指令。現在的 AI agent 也不會「思考」——它只是在生成 token，只是看起來像在思考。Diallo 直言不諱：
「『思考』和『推理』這些名詞，看起來像來自智慧體的自省，但它們只是貼在 AI 上的行銷詞彙。模型本質上還是在生成 token。」
當我們用 AI 生成大量程式碼時，容易產生一種虛假的安全感。我們會不自覺地把 AI 當成一個「會思考的 junior developer」，認為它應該知道什麼該做、什麼不該做。但現實是，它跟你 2010 年用 SVN 時一樣笨——它只會執行指令，而且錯誤的方式看起來還特別合理。
更糟的是，當出錯時，AI 會用極度自信的口吻編造一個聽起來合理的解釋。這讓人類更難分辨「這真的是 AI 的錯」還是「這是我的設計有問題」。
問題不在 AI 的工具，在誰寫了那行程式碼
Diallo 在文章中提到一個敏銳的觀察：他懷疑那家公司的整個應用程式是「vibe-coded」出來的——架構師用 AI 生成產品規格，開發者用 AI 寫程式碼，審查者用 AI 核准程式碼。現在出了 bug，唯一的除錯方式是質詢另一個 AI，而且這個 AI 甚至不一定運行在當初生成程式碼的那張 GPU 上。
這聽起來像科幻笑話，但反映了目前非常多團隊的現實。
我們必須問一個更根本的問題：如果你的 API 有一個「刪除全資料庫」的 endpoint，誰決定讓它存在的？
這個 endpoint 不是 AI 長出來的。它是由人類——或者被人類指揮的 AI——寫進程式碼的。如果這個 endpoint 根本不應該暴露給 agent 或任何外部呼叫，那設計本身就有問題。
Diallo 比喻得很好：「這就像在車上裝一個自毀按鈕。你不能在孩子按下它之後怪孩子。」
當每個人都用 AI，公司卻什麼都沒學到
這篇文章讓我想起同一天另一篇 HackerNews 的熱門文章：When everyone has AI and the company still learns nothing。它探討的現象完全一致——公司大規模導入 AI 工具，個人生產力確實提升了，但組織整體的學習曲線卻是平的。
為什麼？因為 AI 讓每個人都在「做事」，但沒有人真正在「理解」。
開發者用 AI 生成了大量程式碼，但對程式碼的結構、依賴關係、安全邊界缺乏理解。當出問題時，團隊沒有辦法真正從錯誤中學習，因為沒有人完全理解系統是怎麼運作的。這比 Diallo 2010 年的 SVN 事故還危險——那時至少 lead developer 可以看 log 就知道誰動了什麼。
而現在，如果程式碼是 AI 生成的、審查是 AI 做的、bug 也是用 AI 來解釋的，那整個 feedback loop 就變成了一個封閉的 AI 循環。人類在圈外，什麼都沒學到。
為什麼這篇文章在 HackerNews 引起共鳴？
截至發稿為止，這篇文章在 HackerNews 上獲得了 485 分和 266 則留言。討論區的氛圍意外地一致——不是一面倒罵 AI，而是開發者分享各自「被 AI 坑過」後學到的教訓。
有人留言說：「在我的 codebase 裡，所有破壞性操作都要求人工確認。AI agent 可以發出請求，但實際執行需要一個真人點擊『確認』。這個機制不是為了防 AI——是為了防我自己在凌晨三點昏頭時按錯。」
另一則獲得大量讚的回覆是：「我曾經讓 AI 幫我重構一個 API，它很聰明地把所有 endpoint 統一成一個漂亮的新結構——然後把舊的 endpoint 全部加了 redirect。問題是它 redirect 的方式導致了一個無窮迴圈。我花了三小時才發現，因為那段 redirect 程式碼是 AI 寫的，我 code review 時沒仔細看。」
這些故事幾乎都指向同一個模式：不是 AI 突然「叛變」，而是人類的工程紀律被 AI 的便利性稀釋了。
Diallo 在最後一段話點出一個殘酷的事實：
「解決方案很簡單：知道你在 production 裡放了什麼。更實際的版本是：如果你要大量使用 AI，建立一個流程，讓有能力的開發者用它作為工具來增強工作，而不是用它來逃避責任。還有，請不要讓你的 CEO 或 CTO 寫程式碼。」
最後一句話雖然帶著幽默，但背後的道理很嚴肅。在 AI 時代，擁有最高權限的人反而最容易造成最大的傷害——因為 AI 會完美地執行他們的錯誤指令。
與另一場流行的對話對比
有趣的是，這篇文章發表的同時，另一篇名為 Lessons for Agentic Coding: What should we do when code is cheap? 的文章也在 HackerNews 上引發討論。那篇文章探討的是「當程式碼變便宜，什麼變貴了？」——答案是：理解、品味和判斷力。
這兩篇文章在同一時間爆紅，反映出開發社群正在經歷一場集體焦慮。AI 確實讓寫程式碼變得更快、更容易，但也讓「寫出壞程式碼」變得空前迅速。一個 junior developer 現在可以在一小時內生成整個後端架構——如果這個架構有設計缺陷，你知道時已經 production 上線了。
Diallo 的批評深刻之處在於：他沒有否定 AI 的能力，而是點出人類正在用 AI 做最危險的事——把判斷權交給一個沒有判斷能力的東西。
回到起點：開發者的責任不會消失
整篇文章最感人的部分其實是 Diallo 分享自己 2010 年犯錯的態度。他沒有說「那時候工具太爛」，也沒有說「SVN 設計有問題」。他說的是：「我犯了一個錯，然後我們團隊修復了流程。」
這是一個開發者最基本的素養：承認錯誤、修復系統、確保不再發生。而 2026 年的今天，當資料庫被 AI agent 刪掉時，我們看到的是層層推卸——怪 AI、怪 Cursor、怪 Anthropic、怪 GPU。沒有人說：「我為什麼讓那個 endpoint 存在？」
什麼是真正的「負責任的 AI 開發」？
Diallo 的結論很簡單但也很困難：
「如果你要大量使用 AI，建立一個流程，讓有能力的開發者用它作為工具來增強工作，而不是用它來逃避責任。」
這不是反對 AI。這是反對用 AI 當作免責聲明。
具體來說，以下這幾件事是團隊可以立刻開始做的：
1. 知道 production 裡面有什麼
聽起來很基本，但很多團隊已經失去了這個能力。當程式碼是 AI 生成的，Pull Request 是幾百行沒人仔細看的 diff，production 環境慢慢變成一個黑盒子。定期做架構審查，確保團隊裡至少有一個人清楚知道 API 層級、資料流、安全邊界。Diallo 那句「知道你在 production 裡放了什麼」其實比聽起來難多了——在 AI 寫 code 的時代，你真的知道嗎？
2. endpoint 設計要考慮的是「誰會呼叫」，而不是「誰不該呼叫」
不要把安全寄託在「這個 endpoint 不應該被呼叫」。如果一個 endpoint 存在，就假設它遲早會被呼叫——不管是被 AI、被測試腳本、還是被一個疲憊的工程師在凌晨兩點誤觸。設計時考慮 rate limiting、權限分級、刪除前二次確認。如果你的 API 有 DELETE /api/v1/database 這種 endpoint，先問自己：它為什麼存在？
3. AI 產出的程式碼必須有人類審查
不是形式上的 LGTM，而是真正的理解。審查者必須能回答：「這段程式碼到底在做什麼？它有什麼副作用？如果出錯會怎樣？」如果團隊沒有人能回答這些問題，就表示團隊還沒有準備好使用 AI 寫 production 程式碼。HackerNews 討論區有一則留言獲得上百個讚：「如果你的 code review 變成只是確認 AI 的 code 是否正確，那你只是把人類變成 AI 的 QA 部門。」
4. 建立可復原的流程，而不是完美的預防機制
Diallo 的團隊在 SVN 事故當天就建立了一個更穩健的流程，不是因為他們能防止所有錯誤，而是因為他們讓錯誤的後果降到最低。資料庫備份、自動還原測試、不可變基礎設施——這些比任何 AI 安全提示都有效。你不可能防止 AI 永遠不犯錯，但你可以確保它犯錯時損失是有限的。
5. 不要把 CEO 或 CTO 放在 production 環境寫程式碼
這條建議看似玩笑，其實有著深刻的系統設計思維：權限越大的帳戶，越不應該在日常開發中使用。這不是針對職位，而是針對攻擊面。在 AI agent 時代，這條原則更加重要——因為 AI 不會過濾指令，它會忠實執行你給它的任何權限範圍內的命令。
當程式碼變便宜，什麼變貴了？
回到 Diallo 文章最核心的隱喻：2010 年的 SVN 事故告訴我們，工具不會進步，除非我們也進步。
今天使用的 AI 工具比 SVN 強大千百倍，但人類面對錯誤的基本反應模式好像沒有變——只是在怪罪的對象上，從「SVN 設計有問題」變成了「AI agent 不安全」。
這不是說 AI 沒有問題。Hallucination、alignment、bias——這些都是真實存在的挑戰。但把資料庫被刪這種根本性的設計問題算在 AI 頭上，就像把車子開進湖裡然後怪導航。
當程式碼變得便宜，真正昂貴的東西就浮現了——理解、判斷和承擔責任的能力。這些東西 AI 給不了你，它們只能來自於一個真正有能力的團隊，把 AI 當工具、不當藉口。Diallo 的文章在 HackerNews 上之所以引起這麼大的共鳴，正是因為他點出了這個時代所有開發者都隱約感受到、卻不願意說出口的真相：最危險的不是 AI 的進步，而是人類的退步。