不是工程師也能用 AI 寫 SQL

AI 對需要從資料庫拉資料的非工程師真的有變革性。PM、行銷、ops、分析師,過去等工程師寫 query 等幾小時或幾天,現在能自助。陷阱:AI 生的 SQL 錯得夠頻繁,瞎信任會產出自信但錯誤的數字。錯數字驅動錯決策比沒資料糟。

AI 對 SQL 做得好的

知道你特定 schema 的怪癖(active customers 表是哪個 — 是 customers 加 deleted_at IS NULL、還是 active_customers view?)
區分長得很像的 column(created_at vs created_at_local、revenue vs gross_revenue)
抓到兩個 column 可以 JOIN 但不該(資料型別像 foreign key 但沒實際關係)
知道你軟刪除慣例、分區規則、商業過濾要求
效能優化 — 取決於 index 跟你沒告訴它的資料量

步驟一:餵 AI 你的 schema。 不要不給 context 問 SQL。給 Claude 或 GPT 你的 schema(表名、欄位名、型別、每張表代表什麼的簡述)。幾百張表的資料庫,給問題相關的子集。

有用的招:先要 AI 摘要 schema。「根據這個 DDL,用 2 段摘要資料模型,標出任何看起來不尋常的。」AI 摘要錯,你後續 query 就錯。

步驟二:用自然語言加 context 問。 「從 orders 表 JOIN customers,給我 2025 Q3 總花費 top 10 客戶,排除退款訂單。花費格式化為 USD 貨幣。」

Context 越多 = query 越準。提到:時間範圍、商業過濾(「排除測試帳號」)、輸出格式要求、你在意的 edge case。

步驟三:跑之前讀 query。 如果你不懂逐行,要 AI 解釋。「用白話走過這個 query、每個子句做什麼為什麼。」有東西不符合你預期,改 prompt 重生。

步驟四:先在 sample 上跑。 加 LIMIT 100(或 WHERE date > '2025-12-01')在小切片上測試。結果合理,再擴到完整日期。

步驟五:健康檢查輸出。 count 符合你對商業量的預期嗎?Top-N 結果有你認得的名字嗎?有沒 NULL 或 0 在預期外的地方?相信你的商業直覺;一個數字感覺太高或太低,挖為什麼。

所有這些的修法:讀 query、在 sample 上跑、健康檢查。

你反覆查的任何資料庫,建一個 markdown 檔含:

每次問 AI 那個資料庫的 SQL 時把這檔當 context 貼。準確度改善劇烈。

隨手 one-off query,ChatGPT 或 Claude 加 schema context 夠。反覆工作,知道你 schema 的整合工具快得多。

影響 production 的 query。 任何寫(INSERT、UPDATE、DELETE)或影響 production 效能的。讓工程師審。

合規相關資料。 拉 PII、要稽核的金融資料、或任何受監管的 query。query 跟輸出需要稽核軌跡;AI 生成不太對得上。

對效能敏感的 query。 Query 會跑在百萬行或 hot path,需要 AI 沒有的 index 意識。讓工程師優化。

關鍵報告數字。 給高層看或用來付佣金的數字需要三重檢查。AI 生 query 給初稿 OK;驗證沒得商量。

危險不是一次拿到錯 SQL — 那很快被抓。危險是反覆拿到細微錯的 SQL,產出沒人質疑、看似合理的數字。「客戶 churn 上季 4.3%」感覺精準。Query 數錯了,數字是虛構,但會被重複幾個月。

培養習慣:任何驅動決策的數字都用對同一問題從不同角度跑、或問熟資料的人來驗證。「這看起來對嗎?」問分析師朋友 30 秒,防幾個月錯方向決策。