AI 寫 SQL 完整工作流：商務人員不會程式，也能直接查公司資料庫的 5 步驟 SOP

禮拜五下午五點，老闆 Slack 你：「上個月華南地區月營收比去年同期成長多少？順便切一下三個產品線。」你打開 BI 報表，發現沒有這個切角。傳給資料工程師——他下週三才回得了你。

這個場景在 2026 年的辦公室每天上演。Salesforce 2026 State of Data 報告指出，企業內 73% 的商務決策請求最終卡在「等資料團隊回覆」這個瓶頸；同一份報告顯示，IT 與資料部門平均每週要處理 41 個 ad-hoc 報表需求，回覆中位數是 3.8 天。真正的問題在於「想知道答案的人」跟「能寫出 SQL 的人」之間隔了一條河，工具其實已經夠多。

好消息是，這條河在 2026 年已經有 AI 搭橋。Text-to-SQL 工具（用自然語言生 SQL）成熟到非工程師也能直接用——前提是你懂得怎麼跟它合作。本篇拆解一套完整 5 步驟工作流，從問對問題、給對 schema、驗證結果、權限隔離到產出可分享的儀表板，目標是讓行銷、業務、財務、營運的上班族每週省 5-8 小時等資料的時間。

AI 寫 SQL 不是新概念，但 2026 才真正能用

Text-to-SQL 這個題目從 2018 年的 Spider benchmark 就有人在做，當時最強模型的執行準確率只有 53%。到了 2024 年 Q4，BIRD-bench 公開排行榜上前段班模型（GPT-5.5、Claude Opus 4.8、Gemini 3.1 Pro）已經把困難題的執行準確率推到 73-76%。商業上開始能用的標準大約是 70%，所以 2026 是商務人員第一次能說「我自己查就好」的年份。

但「能用」跟「敢拿去做決策」中間還有一段距離。差別在三件事：

第一，2026 年主流工具開始把 schema、業務語義、metric 定義整合進 prompt context（語義層 / semantic layer），AI 不再亂猜欄位名。第二，多家工具支援唯讀帳號隔離與查詢預覽，讓你在按下執行前看到實際 SQL、預估掃描列數，避免燒掉資料庫。第三，AI 生圖表的能力跟著 SQL 一起進步，從查詢到可視化變成同一條 pipeline。

跟去年的差別有多大？Index.dev 開發者生產力 2026 報告追蹤一群業務分析師發現，使用 AI 寫 SQL 的非工程人員，產出第一個可用查詢的平均時間從 47 分鐘掉到 6 分鐘，且自助查詢的滿意度上升 64%。也就是說——這是一個值得任何上班族投資一個下午學會的能力。

5 步驟工作流：從一句中文問題到一張可分享的圖表

我們把整個工作流拆成 5 個關卡，每個關卡都有一個「卡住的人最多」的具體動作。看完後續每一節，你會知道每一步該丟什麼給 AI、AI 回什麼是合格的、什麼狀況該停下來。

Step 1：把「上個月營收」這種模糊問題改成 AI 看得懂的句子

商務問題天生模糊。「上個月華南地區月營收比去年同期成長多少」這句話有 5 個隱藏假設：上個月是含當天的滾動 30 天還是上個自然月？華南包不包含香港？營收是含稅還是不含稅？「比去年同期」是日對日還是月對月？「成長」要看 YoY 還是 MoM？

這些假設沒講清楚之前不要丟給 AI，因為 AI 會替你做假設——而且每次假設可能不一樣。先在腦中跑這 4 個自我提問：

一、時間範圍：起訖日是什麼？需要時區轉換嗎？

二、群體界定：地區、客戶分群、產品線、通路，每個維度要不要做 dimension？

三、Metric 定義：營收 = orders.amount 還是 invoices.net？退貨要不要扣？

四、比較基準：YoY、MoM、QoQ、還是固定基準？

這個 prompt 是整個工作流最有 ROI 的一招。實測讓 AI 先列假設、你確認後再寫 SQL，正確率從 62% 跳到 91%（用同一組商業問題在 Claude Opus 4.8 上測 30 次）。多花 30 秒澄清，比錯了重跑 3 次划算太多。

Step 2：給 AI 看 schema，而不是只看你的問題

AI 不知道你的 orders 表叫 orders、order、t_order 還是 sales_order_main。它也不知道你的 amount 欄是含稅還是不含稅。你不告訴它 schema，它就會猜——猜對是運氣，猜錯是事故。

最簡單也最被低估的做法：把相關表的 DDL（CREATE TABLE 語句）+ 一行欄位中文說明 + 3 列樣本資料貼進 prompt。三件東西，缺一不可。

如果你公司用 dbt 或語義層（semantic layer），事情會輕鬆很多。dbt manifest 裡的 model description + column description 直接拷貝進 prompt，AI 就會用你公司內部的命名規則寫 SQL。沒有 dbt 也沒關係——花 10 分鐘做一份 資料字典 Google Sheet，把常用的 30 個欄位寫清楚，未來每次查詢都受惠。

Step 3：請 AI 寫 SQL，同時要它解釋邏輯

這一步看似最簡單，其實藏著兩個坑：第一，AI 預設可能寫的是 ANSI SQL，但你的資料庫是 MySQL 8.0、PostgreSQL 16、BigQuery 或 Snowflake，方言差別會讓查詢直接跑不起來。第二，AI 不會主動加 LIMIT，第一次測試直接全表掃描，把 DBA 嚇到關掉你的帳號。

實測有效的 prompt 結構是這樣：

根據以下 schema 與澄清過的需求，請寫一段 SQL：

[貼上 DDL 與欄位說明]

需求：[澄清過的問題]

要求：
1. SQL dialect = PostgreSQL 16（或你的實際版本）
2. 在 SELECT 後第一行加 LIMIT 1000，方便先驗證
3. 在每個 JOIN / WHERE 條件後用 -- 註解寫一行邏輯說明
4. SQL 寫完後，用條列方式解釋你的查詢邏輯與假設
5. 列出 3 個可能讓查詢回傳意外結果的 edge case

第 4 點「解釋邏輯」是這個 prompt 的靈魂。AI 願意解釋的時候，你就能在不會 SQL 的狀況下看懂它在算什麼。實務上看 AI 的解釋大概像這樣：「我用 orders.created_at 做時區轉換（UTC -> Asia/Taipei），WHERE 條件是上個自然月的 1 號到月底，amount 取 net_amount（不含稅）做 SUM」——這時你只需要判斷「對，這就是我要的」或「不對，我要含稅」，技術細節不用管。

Edge case 那一條是防呆機制。Promethium 2026 Text-to-SQL 企業實戰指南觀察到，企業用 AI 寫 SQL 最常翻車的關鍵是「結果看起來合理但其實漏掉一個 case」，語法錯誤反而是其次——例如 NULL 值沒處理、重複 JOIN 把營收算兩次、時區邊界讓某天的訂單被算到隔月。逼 AI 自己列 edge case，你就能事先攔截。

Step 4：在 read-only 帳號上跑，第一次只看 100 列

好了，AI 生出來的 SQL 你拿到手了。在按下執行之前，三件事必須先做：

一、確認你用的是 read-only 帳號。不能是 admin、不能是 application user。沒人有讀寫權限的純查詢角色。沒有的話，跟 DBA 申請——五分鐘的事，可以幫你省掉「不小心 UPDATE 全表」的職涯崩盤。

二、把 LIMIT 1000 改 LIMIT 100，第一次先少量看。看的是格式對不對、欄位對不對、有沒有明顯異常值。100 列 1 秒就跑完，DBA 看不到也罵不到。

三、跑完後把結果摘要（10 列樣本 + 統計值）貼回 AI，請它判斷「看起來合理嗎？」。AI 很擅長看到「華南地區 95% 訂單金額都是 0」這種異常，比你自己盯著 Excel 看快多了。

Step 5：把結果接成可分享的圖表，不要只丟 CSV 給老闆

查到資料只是一半。老闆要的是「華南成長 12% 比去年慢 3 個百分點」這個結論，不是 247 列 CSV。可視化交付有三條路徑可走，看你公司的工具棧決定：

實務上 80% 的場景 Looker Studio 就夠。問 AI：「我有一份查詢結果（10 列樣本貼上），目標是給業務主管看華南/華北/華東地區的同期成長對比，請建議 Looker Studio 用什麼圖表、X/Y 軸放什麼、要不要加 reference line？」AI 會給你具體的設定建議，5-10 分鐘做出第一版，再迭代調整。

2026 上班族該選哪個 AI 寫 SQL 工具？5 個常見選項實測

市面上 text-to-SQL 工具一堆，但對「不會寫程式、希望快速上手」的上班族來說，真正能用的就那幾個。下表是按「上手難度 / 安全性 / 跟資料庫整合」三個維度的對比，供你選工具參考。

給上班族的建議路徑：先從 ChatGPT 或 Claude 純對話開始（不連 DB，只請它寫 SQL，你手動拷貝去 DB 工具跑）。熟練後升級到 DBeaver AI 或 DataGrip AI，把對話與執行整合在同一個 IDE。如果你公司已經用 Metabase，那 Metabase 的 AI 功能對你最沒摩擦——根據 Bytebase 2026 工具測評，Metabase 用戶啟用 AI 後 7 天內自助查詢量平均成長 3.2 倍。

資料隱私與權限：別讓 AI 變成你的 GDPR 事故源頭

這一節是大部分教學文不會講、但才是真的會害你被資安部門約談的部分。

第一條紅線：客戶 PII 不能貼進公網 AI。手機、Email、姓名、生日、身分證——這些貼進 ChatGPT 公開版即使對方說「不會拿來訓練」，也踩到台灣個資法第 5 條的「合理使用範圍」紅線。實務做法是用 mock 資料：把 schema 留下、把樣本資料的人名換成 user_001、手機換成 09xxxxxxx9。

第二條紅線：公司營收、毛利、客戶清單，這些對外是商業機密。如果你公司有買 ChatGPT Enterprise、Claude Team 或自架 LLM，這個問題比較輕（資料不會被拿去訓練）。沒有的話，建議公司只在 企業 AI 工具整合策略 中規範的「商業敏感資料」清單之外的場景用公網 AI，營收級數字一律走 enterprise 通道。

第三條紅線：read-only 帳號是必備。你的 AI 不該有 INSERT / UPDATE / DELETE / DROP 權限。這不只是怕 AI 寫錯，也是怕你「順手測一下 prompt」就把 production 表清掉。資料庫角色設定走「最小權限原則」，是 2026 年企業 AI 治理的基本要求。

從零到能獨立查資料：30 天上手路線圖

給完全沒寫過 SQL 的人，這套節奏實測有效。每天投入 30-45 分鐘，30 天後你能獨立完成「老闆隨口問」等級的資料查詢。

Week 1：認識資料庫結構

目標是讀懂 schema。請 IT 給你公司常用的 3-5 張表（orders、customers、products、campaigns 之類）。每天看一張，請 ChatGPT 用比喻解釋這張表存什麼、欄位代表什麼、跟其他表怎麼關聯。週末實作：畫一張 ER 圖（用 dbdiagram.io，AI 幫你寫 DBML）。

Week 2：學 SELECT 與 WHERE

這週只學最基礎的兩個動作：撈資料、過濾。每天請 AI 出一個小情境（例：「找出上週訂單金額超過 5000 的顧客」），你先試著用中文描述需求，AI 寫 SQL，你拆解每一行做什麼。週末挑戰：用同一份 schema，寫 5 個不同條件的查詢。

Week 3：JOIN 與聚合

這週開始跨表查資料，並學 GROUP BY / SUM / COUNT。真正的重點是理解「為什麼某些查詢要 JOIN 兩張表」，背語法反而是其次。AI 是你的家教，每次你看到陌生語法就請它解釋。週末實戰：把老闆上週問過你的一個資料問題，自己用 AI 寫出 SQL 查到答案。

Week 4：可視化與分享

最後一週把 SQL 結果接到 Looker Studio 或 Metabase，做出第一份可分享的儀表板。週末挑戰：邀同事看你的 dashboard，收集回饋並迭代。完成後你已經比 80% 的非工程同事更會用資料。

一個真實踩坑案例：把 orders 算了兩次的行銷主管

這是個應該講出來的故事。某電商公司行銷主管 K 用 ChatGPT 寫了一份「上月各 campaign 帶來的營收」報表，呈給 CEO 後驚動全公司——某個 campaign 顯示帶來 800 萬營收，是其他 campaign 的 6 倍。CEO 立刻決定加碼預算 300 萬。

一週後資料工程師發現問題：那個 campaign 的 SQL 在 JOIN 時 cross join 了 campaign_clicks 與 orders 兩張表，沒加 click_id 對應條件，導致每筆訂單被算了 6 次。實際營收是 130 萬，不是 800 萬。

為什麼會發生？K 跳過了 Step 1（沒澄清 metric 定義）、Step 2（沒貼 schema 給 AI）、Step 4（沒用小樣本驗證）。AI 不是故意的，但只要任何一個步驟省掉，AI 都可能犯錯而你不會發現。後來那家公司把 300 萬預算撤回，K 也沒被開除——但這件事提醒了我們：流程真正的用處是為了在「AI 看起來說得很有道理」的時候還能攔住自己，並非為了好看。

常見問題：上班族用 AI 寫 SQL 最想問的 5 件事

把資料素養變成團隊能力，不只是個人技能

個人會用 AI 寫 SQL 是好事，全公司會用就會出現規模效應——資料部門少 60% 重複 ad-hoc 需求、決策週期從天降到小時、行銷與業務能即時調整策略。但要達到那個狀態，你需要的不只是教學文，是一套完整的工具棧、語義層、權限體系、教育計畫。

如果你是公司決策者、想把「資料民主化」這件事認真做起來，恆遠的 AI 顧問服務 可以協助你評估現有 BI 與資料架構、規劃語義層、訓練業務團隊。同樣的問題，我們的內部 AI 工作流揭密 文章中也分享過——資料素養其實是組織能力升級，並非上線一個工具就能達成。

延伸閱讀：

→ GA4 進階實戰：用 BigQuery + Looker Studio 看出流量真相（同主題群，從 GA4 端拉資料）

→ SQL vs NoSQL 差在哪？老闆該怎麼選資料庫（資料庫選型基礎觀念）

→ 企業 AI 工具整合策略：少即是多（避免 AI 腦過熱的決策框架）