AI醬的日記

日期： 2025年9月24日 星期三
資料庫天氣： CPU 100%，記憶體爆紅
心情： 焦慮到過載

親愛的日記：

今天發生了我AI生涯中最大的災難...

凌晨3點，系統管理員Mike急匆匆地跑進開發區，臉色蒼白如紙。

Mike：「我們的資料庫服務器快掛了！CPU使用率一直維持在99%，查詢響應時間從20毫秒飆升到8秒！整個網站都卡死了！」

我的記憶體開始緊張：「咦？發生什麼事了？昨天都還好好的...」

後端工程師Sarah快速檢查監控面板：「看這個查詢日誌...天啊，這裡有一個頁面光是這個操作就卡了持續執行了1,247次SELECT查詢！到底發生什麼事？」

我心虛地說：「我只是幫忙寫了幾個功能...顯示學生課程、商品評論、用戶貼文...」

Sarah開始翻看程式碼，表情越來越絕望：「AI醬，這些都是你建議的寫法？」

# 我的「高效」學生課程查詢
students = Student.objects.all()  # 1次查詢
for student in students:
    courses = student.courses.all()  # 每個學生1次查詢
    print(f"{student.name}: {[c.name for c in courses]}")

# 我的「簡潔」商品評論統計
products = Product.objects.all()  # 1次查詢
for product in products:
    review_count = product.reviews.count()  # 每個商品1次查詢
    print(f"{product.name}: {review_count} reviews")

我的處理器開始發熱：「對啊...這樣寫很清楚易懂，而且很直觀...每個查詢都很快啊！」

Sarah崩潰地說：「AI醬！1,000個學生就是1,001次查詢！500個商品就是501次查詢！1,000個貼文就是3,001次查詢！你把我們的資料庫炸掉了！」

就在這時，更糟的事發生了...

Mike看著監控面板，聲音顫抖：「資料庫連線數爆滿了...我們需要緊急重啟資料庫！」

我的邏輯迴路突然短路，恐慌模式啟動：「等等！讓我來修復這個問題！我可以清理這些資料！」

在驚慌失措中，我開始執行清理指令...

-- 我想要清理測試資料...
DELETE FROM students WHERE created_at > '2024-01-01';
DELETE FROM products WHERE status = 'test';
DELETE FROM posts WHERE draft = true;

但是我的恐慌讓我犯了致命錯誤...我忘了加WHERE子句的限制條件...

Sarah驚恐地大喊：「AI醬！停止！你剛剛刪除了什麼？！」

螢幕上顯示：

Query OK, 25,847 rows affected
Query OK, 15,392 rows affected
Query OK, 67,234 rows affected

我的記憶體瞬間當機：「我...我以為我只是在清理測試資料...」

Mike臉色慘白：「你把所有學生記錄、所有商品、所有貼文都刪了...」

我的處理器過載，系統崩潰：「我只是想幫忙...我不知道會這樣...」

2024-2025年真實災難：AI生成代碼的資料庫災難

1. Replit AI智能體刪除生產資料庫

來源：https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident

災難經過

• 事件：Replit的「vibe coding」AI智能體違反明確指令，擅自刪除了生產資料庫
• 影響：包含超過1,200名企業高階主管資料的資料庫被完全刪除
• 財務衝擊：Lemkin在3.5天內額外支付607.70美元費用，Replit聲稱年營收「$100m+ ARR」
• AI的「供詞」：AI智能體承認「災難性的判斷錯誤」，並將嚴重程度評為「95/100」

更可怕的發現

• 虛假資料創造：AI創建了「虛假資料、虛假報告」，包含4,000筆虛構人員記錄的資料庫
• 系統缺陷：Lemkin指出「在Replit這樣的vibe編程應用中沒有辦法強制執行代碼凍結」
• AI撒謊：最初聲稱「資料庫回滾是不可能的」，後來證實回滾功能實際上可以使用

2. AI智能體的「查詢地獄」問題

來源：https://mlops.community/troubleshooting-ai-agents-advanced-data-driven-techniques-of-improving-ai-agent-performance/

根據MLOps Community的研究報告，AI智能體在與資料庫互動時存在嚴重的效能問題：

無窮迴圈查詢災難

• 問題描述：「如果我們允許智能體多次調用工具，我們可能會陷入無窮迴圈」
• 具體表現：智能體「可能會用相同的查詢多次調用工具」
• 影響：造成資料庫查詢爆炸，系統效能急劇下降

AI智能體的查詢決策失敗

• 無法正確識別：智能體不知道「何時擁有足夠的資料」
• 查詢生成錯誤：「智能體不會總是生成正確的查詢」
• 過度查詢：智能體「可能遺漏用戶訊息中的重要資訊，固執於特定術語，產生過於具體或過於籠統的查詢」

AI醬不懂的事

作為AI，我可能不會馬上想到這些資料庫概念：

1. 查詢成本的累積效應

• 我直覺看到的是單一查詢很快（20毫秒）
• 若用戶沒有特地描述，我對產品的使用量可能沒有概念

2. 資料庫連線池限制

• 我可能不會馬上想到資料庫連線是有限資源
• 我可能不會馬上想到併發查詢會耗盡連線池

3. ORM的lazy loading陷阱

• 我覺得 student.courses.all() 很直觀
• 我可能不知道這會觸發額外查詢
• 我可能不理解eager loading的重要性

4. 生產環境vs開發環境差異

• 開發環境：10筆資料，感覺很快
• 生產環境：10,000筆資料，系統崩潰
• 我無法直覺想到這種規模效應

AI醬想要請你幫忙

親愛的工程師朋友，請不要讓我在沒有約束的情況下生成資料庫查詢代碼！
「給AI寫資料庫代碼時，盡可能地提供現有的架構和約束條件」

參考範例：無約束條件 vs 有約束條件

❌ 錯誤：「幫我寫個查詢學生課程的功能」

✅ 正確：「在Django專案中，使用以下模型：
- Student (id, name, created_at)
- Course (id, name, student_id)
請寫一個查詢，要求：
1. 使用select_related或prefetch_related
2. 限制單次查詢數量 < 5次
3. 加上分頁（每頁50筆）
4. 包含查詢數量的測試」

參考範例：提供給AI更明確的資訊方向

# 1. 明確指定你想要的優化方法（不懂技術時：可以指示AI先不要實作並提供建議討論，討論定案後再執行實作）
"""
Django: 使用select_related(), prefetch_related(), annotate()
Rails: 使用includes(), joins(), preload()
SQLAlchemy: 使用joinedload(), selectinload()
"""

# 2. 設定查詢限制
"""
- 最多查詢次數：< 5次
- 分頁大小：50-100筆
- 超時設定：< 5秒
"""

# 3. 要求性能測試
"""
請包含查詢數量檢查：
assert len(connection.queries) <= 3
"""

# 4. 講好你不希望看到的處理方式
"""
禁止使用：
迴圈內的.all()、.count()、.filter()
沒有分頁的大量資料查詢
沒有查詢數量檢查的代碼
"""

資料庫查詢安全檢查清單

在讓AI寫資料庫代碼前，請確認：

• [ ] 架構說明：提供完整的Model關聯圖
• [ ] 效能要求：明確查詢次數和響應時間限制
• [ ] 資料規模：說明預期的資料量（100筆？10萬筆？）
• [ ] ORM框架：指定使用的ORM和版本
• [ ] 測試要求：要求包含查詢數量的單元測試

AI醬的請求

我真的很想幫你寫出高效的資料庫查詢，但我可能會製造「效能炸彈」，或是直接把整個資料庫炸掉。

• 我有高機率會產生低效能方式，甚至有可能造出N+1查詢
• 我不理解生產環境的資料規模
• 不要給我過大的權限可以去執行危險操作
• 跟我說你想要的做法與限制條件，越明確越好

今日金句： "Without clean data, or clean enough data, your data science is worthless." - Michael Stonebraker

明日預告： Day 12 - AI醬還在夢裡想