用 AI 寫 SQL 查詢：不會寫程式的行銷、營運、PM 也能自己撈資料庫

一分鐘重點：SQL 是跟資料庫要資料的語言，過去這件事卡在工程師手上，你想看個數字得排隊等三天。現在你可以把白話需求丟給 AI，讓它翻成 SQL，自己撈。但有三個動作不能省：一定要先把資料表結構（schema）貼給 AI，否則它連欄位名都用猜的；一定要在測試環境用小範圍先驗證，因為 AI 看不到你真實的資料；以及絕對不要讓 AI 幫你跑沒看懂的 DELETE 或 UPDATE，那是會把資料弄不見的操作。守住這三條，行銷、營運、PM 都能自己拿到數字。

為什麼非工程師也該學會「用 AI 撈資料」

先講清楚場景。你是電商營運，想知道「上週哪個行銷活動帶來的訂單最賺」。這個數字躺在公司的資料庫裡，但你打不開——你會的是後台介面，後台沒有這個現成報表。於是你開了一張需求單給 RD，RD 手上排了二十件事，三天後給你一個 Excel，你一看欄位算錯了，再來回兩次，一週過去了，行銷檔期都結束了。

問題的核心是：「我想知道什麼」和「怎麼跟資料庫要」中間，卡了一層叫 SQL 的語言。過去只有工程師會這層語言，現在 AI 就是你的即時翻譯。你用中文講需求，它翻成 SQL，你拿去資料庫跑。這不是要你變成工程師，而是讓你在「讀取資料」這件小事上不必再求人。

但這裡要先劃一條紅線：自己撈，只限於「讀」（SELECT）。讀資料頂多撈錯、看錯，重跑就好；但「寫」資料（新增、修改、刪除）一旦出錯，是會動到正式資料、可能救不回來的。這篇教你安心地自己讀，寫的部分永遠交給工程師覆核。

SQL 在做什麼？用一句話聽懂

你不需要學會寫 SQL，但要聽懂它在幹嘛，才知道 AI 給你的對不對。一個最常見的查詢就四個動作：

• SELECT：我要看哪些欄位（例如訂單編號、金額）。
• FROM：從哪張資料表撈（例如 orders 訂單表）。
• WHERE：篩選條件（例如只看上個月、只看已付款）。
• GROUP BY：分組加總（例如按通路分組，算每個通路的營收）。

翻成白話就是：「從訂單表，篩出上個月已付款的單，按通路分組，給我看每組的訂單數和營收總和。」你看，這跟你平常講需求的句子幾乎一樣，差別只在語法。所以用 AI 寫 SQL 的本質，就是把你腦中那句白話，補上資料表結構，讓 AI 填空。

下面是一段 AI 會幫你產出的典型查詢，你不用會寫，但要看得懂它在做你要的事：

SELECT channel AS 通路,
       COUNT(*) AS 訂單數,
       SUM(total_price) AS 營收
FROM orders
WHERE created_at >= '2026-05-01'
  AND created_at < '2026-06-01'
  AND status = 'paid'
GROUP BY channel
ORDER BY 營收 DESC;

最關鍵的一步：先把 schema 給 AI

九成的失敗，都敗在沒給 schema（資料表結構）。AI 看不到你的資料庫，它不知道你的訂單表叫 orders 還是 tb_order、金額欄位叫 amount、total 還是 total_price、付款狀態是用文字 'paid' 還是數字 1。沒給它這些，它只能拿訓練時看過的「最常見命名」來猜，猜錯欄位名，查詢不是報錯就是撈到莫名其妙的東西。

給 schema 最簡單的方法，是把資料表的 CREATE TABLE 語法整段貼給它。不會找？問你們 RD「可以給我這幾張表的建表語法嗎」，或在資料庫工具裡按一下就能匯出。長得像這樣：

CREATE TABLE orders (
  id            BIGINT PRIMARY KEY,
  member_id     BIGINT,            -- 對應 members.id
  channel       VARCHAR(20),       -- 通路：web / app / line
  status        VARCHAR(20),       -- pending / paid / shipped / refunded
  total_price   INT,               -- 訂單金額（含稅，新台幣）
  created_at    DATETIME
);

有了這個，AI 就知道欄位真名、型態、還有關聯（member_id 接到會員表）。如果你連欄位的中文意義、特殊編碼（例如 status 的每個值代表什麼）一起講，準確率會再高一截。記住一個原則：給 schema 不貼真實資料——欄位結構不是機密，但裡面的客戶姓名、電話是個資，那些不該貼進公開版 AI。

可複製的萬用 Prompt 模板

把下面這段存起來，每次撈資料就填空。中括號的部分換成你的內容：

你是一位資深資料工程師，請協助我把需求翻成 SQL 查詢。

【資料庫類型】
[填 MySQL / PostgreSQL / SQLite / BigQuery，不確定就問 RD]

【資料表結構】
[把相關資料表的 CREATE TABLE 語法或欄位清單貼這裡，
 包含欄位名、型態、特殊編碼意義、資料表之間的關聯]

【我想要的結果】
[用白話描述，例如：我想看 2026 年 5 月，每個通路（channel）
 的「已付款」訂單數與營收總和，營收由高到低排序]

【請你做到】
1. 寫出完整 SQL，欄位名只能用我上面 schema 提供的，不要自己發明。
2. 逐句用中文解釋每個 JOIN、WHERE、GROUP BY 在做什麼。
3. 若有可能因 JOIN 造成筆數重複放大，請特別提醒我。
4. 在查詢最後加上 LIMIT 100，方便我先小範圍驗證。
5. 只能產出 SELECT 查詢，不准出現 UPDATE / DELETE / DROP / TRUNCATE。

最後那兩條（加 LIMIT、禁止寫入操作）是給自己上的安全鎖。明確要求 AI 只產 SELECT，能大幅降低你不小心複製到一段危險語法的機率。

台灣電商實戰：營運自己撈出「假高效活動」

舉個真實感的例子。淑芬是一家台中保養品電商的營運專員，非技術背景。母親節檔期跑了三個行銷活動，老闆問哪個最值得明年再投。過去她要等 RD，這次她決定自己用 Claude 撈。

她先跟 RD 要了 orders 和 order_items 兩張表的建表語法，連同 coupon_code（活動代碼）欄位的意義一起貼進 Prompt，需求寫：「我想看母親節三個活動代碼 MOM_A、MOM_B、MOM_C，各自的訂單數、總營收、平均客單價，還有退貨（status = refunded）的筆數。」

AI 產出查詢，並提醒她一句關鍵的話：「因為要算客單價，建議用訂單表算就好，不要 JOIN 明細表，否則一張多品項的訂單會被算成多筆，營收會虛胖。」淑芬照做，先加 LIMIT 20 跑一遍，再拿活動 A 已知的某一天訂單數手動核對，數字對得上，才放心跑全量。

結果很有意思：活動 B 的「總營收」最高，老闆本來想砸更多錢在 B。但淑芬撈出的退貨欄位顯示，B 的退貨筆數是 A 的四倍，扣掉退貨後實際淨營收反而輸給 A。她把這個發現一頁報告丟給老闆，明年預算從 B 轉到 A。整件事她花了一個下午，沒麻煩到任何一位工程師。

這個案例的重點不是 SQL 多難，而是：她懂得驗證、懂得多撈一個「退貨」欄位去戳破表面數字。AI 給的第一版查詢只算了營收，是她追問「那退貨呢」，才挖出真相。AI 是工具，提問的人才是分析師。

三個會害你撈錯的常見錯誤

錯誤一：沒給 schema 就問，欄位全用猜的。 AI 回給你一段看起來很專業的 SQL，欄位叫 order_amount，你拿去跑，資料庫回「Unknown column」——因為你家根本沒這欄。每次都先給 schema，這是省不掉的成本。

錯誤二：直接信任 AI 跑 DELETE 或 UPDATE。 有人問 AI「幫我把測試訂單刪掉」，AI 給了 DELETE FROM orders WHERE ...，他沒看懂條件、直接在正式庫貼上去執行，結果條件寫太寬，刪掉的遠不只測試單。讀資料錯了能重來，刪資料錯了可能回不來。 任何會改動資料的操作，自己不要跑，交給工程師、而且要先備份。

錯誤三：JOIN 之後筆數爆掉還沒發現。 把訂單表接上訂單明細表（一張訂單有多個商品），如果你還用 COUNT(*) 算訂單數，一張三品項的單會被算成三筆，營收也跟著膨脹。這種錯最陰險，因為查詢「跑得出來」，只是數字悄悄錯了。所以 Prompt 裡要請 AI 主動提醒 JOIN 放大風險，自己也要對總數的合理性保持懷疑。

AI 的天花板：它看不到你的真實資料

要用得安心，得認清 AI 在這件事上的兩個根本限制。

第一，AI 看不到你資料庫裡真正長什麼樣。 它不知道你的 status 欄位其實有八成是空值、不知道某個通路三月才上線（所以更早的資料是 0）、不知道金額欄位有人手誤輸入過負數。這些「資料分布」的眉角，只有真的跑下去、看到結果才會浮現。所以 AI 給的查詢是「語法上合理」，不等於「符合你資料的真實狀況」。驗證這一步，永遠是人的責任。

第二，AI 不是計算機，邏輯對不代表結果對。 它很會寫出結構正確的查詢，但會不會因為時區、邊界日期（< 還是 <=）、null 值參與計算而偏差，得靠你用已知案例去對。養成習慣：任何要進報告、要給老闆看的數字，先用一個你心裡有答案的小案例驗一遍，對得上再相信。

最後一個務實提醒：先在測試環境或唯讀帳號上練。 跟 RD 要一個只能讀、不能寫的帳號，這樣就算 AI 給了危險語法、你不小心貼上去，資料庫也會直接擋下來。這是給非工程師最好的安全網。

現在就試一次

別等下一張需求單卡三天。挑一個你最近想知道、但懶得麻煩工程師的小問題——「上個月退貨率最高的商品前十名」「LINE 通路的回購率」之類——做三件事：跟 RD 要相關資料表的建表語法、把上面的萬用 Prompt 填好丟給 AI、拿一個你已知答案的小案例驗證結果。第一次可能要來回幾次，但跑通一次，你就有了一個一輩子受用的技能：自己跟資料對話，不再求人。

撈完數字下一步是解讀，建議接著看 用 AI 做資料分析，把撈出來的表變成能決策的洞察；想把 Prompt 寫得更精準，參考 寫程式的 Prompt 技巧。更多繁體中文 AI 實戰教學，都在 AgentAI 智庫（agentai.tw）。

常見問題 FAQ

延伸閱讀

• 用 AI 做資料分析
• 寫程式的 Prompt 技巧
• 用 AI 寫 Excel 公式
• ChatGPT 怎麼用？