AI 會寫 SQL 了，還需要學 Data Science 嗎？（2026 完整解析）

AI 都會寫 SQL、畫圖表了，你是不是也在想：資料科學還值得學嗎？這篇用數據和一個 30 行小實驗，帶你看清楚 AI 先接手哪一段、你該把力氣放在哪裡！

2026 年 9 月 10 日，OpenAI 在 ChatGPT Work 推出 Data agent，發表文的標題是〈Now everyone can put data to work〉，意思是現在人人都能讓資料替自己工作。文章附了幾個點了就能用的範例，其中一個是：「找出上週的週活躍使用者為什麼變了，列出可能的原因，和前幾期比較，再建議接下來要查什麼。」

這幾乎就是資料分析師每週一早上的工作。正在猶豫要不要學資料科學的人，看到這裡大概會問：AI 會寫 SQL、會畫圖，連原因都幫你列好了，資料科學還值得花一兩年學嗎？

同一篇發表文接近結尾的地方，有一句比較少人注意的話。OpenAI 說，自家幾乎整個產品團隊、超過三分之二的業務團隊，都已經用 data agent 自己分析公司資料；讓這件事成立的，是資料團隊先「建立共用的業務定義、設定存取規則、替敏感資料加上防護」。

我的回答是值得學，但要學的那一段換了位置。AI 先接手的是把問題翻成查詢；「週活躍使用者」到底算誰，仍然要有人決定、有人負責。

快速回答 資料科學依然重要，但需要人做的段落換了位置。AI 迅速接手了「在乾淨資料庫上寫 SQL 和生圖表」；但指標怎麼定義、資料口徑誰維護、因果推論是否成立，AI 無法替人承擔。指標定義沒有人負責時，AI 只會在錯誤的定義上，以極高效率算出看似專業的荒謬數字。

Text-to-SQL 評測：AI 在乾淨題庫答對率達 91.2%，企業資料庫的落差也正被快速追平

把一句自然語言的問題翻成資料庫查詢，這件事叫 Text-to-SQL，是資料工作裡最早被 AI 接手的一段。要看它進步到哪裡，有三份常被拿來比較的考卷。

Spider 1.0 是 2018 年的評測，資料庫小而乾淨，欄位名稱大多看得懂。BIRD 在 2023 年推出，資料庫大得多，資料也比較髒，有些題目要額外的業務知識才答得出來。Spider 2.0 由 Lei 等人在 ICLR 2025 發表，題目改成真實企業的資料工作：632 題，資料庫放在 BigQuery、Snowflake 這類雲端資料倉儲，常常超過 1,000 個欄位，還要讀文件、寫好幾步的查詢。論文用同一個 o1-preview 跑了三份考卷。

左右兩面板長條圖。左：o1-preview 在 Spider 1.0 成功率 91.2%、BIRD 73.0%、Spider 2.0 21.3%。右：2026 年 10 月 Spider 2.0-Snow 排行榜，Spider-Agent 加 GPT-4o 13.0%、加 o1-preview 23.6%、ReFoRCE 加 o3 62.9%、排行第一的資料公司系統 96.7% — 通用模型在乾淨題庫答對率達 91.2%，在真實企業倉儲中跌至 21.3%，但專門系統一年內已將成功率追至 96.7%（資料來源：Lei 等人 Spider 2.0 論文與 2026 年 10 月 Spider 2.0-Snow 排行榜）。

左邊的落差說明 AI 先吃掉的是哪一段。在欄位清楚、題目明確的資料庫上，把問題翻成查詢，模型已經做得比多數初學者好。換成企業資料，難處就移到別的地方：該用哪張表、哪個欄位才是真正的下單日期、測試帳號要不要排除。這些答案大多不寫在資料表結構（schema）裡。

右邊是 2026 年 10 月的 Spider 2.0-Snow 排行榜。直接拿通用模型接上論文附的 agent，分數在一成到六成之間；排第一的是一家資料公司提交的整套系統，96.7%。前段系統怎麼做的，多半沒有公開，題目也已經公開一年多，分數要保守看。但方向很清楚：企業資料上的落差，一年多就被追上大半。

所以我不會拿「AI 在企業資料上只有兩成準」當成學資料科學的理由，考卷遲早會被追上。比較值得問的是，追上考卷的系統把力氣花在哪裡。

企業資料難在口徑定義：沒有領域專家維護業務 context，再強的 AI 也會悄悄算錯

OpenAI 在 2026 年初公開過自己內部用的 data agent。它服務超過 3,500 位內部使用者，面對 7 萬個資料集、600 PB 的資料。文章引了一位內部使用者的抱怨：「我們有很多長得很像的表，我花很多時間搞清楚它們差在哪、該用哪一張。有些包含登出狀態的使用者，有些不包含。」

一張表有沒有把登出的使用者算進去，查詢語法一模一樣，算出來的人數可以差很多。OpenAI 自己也寫，沒有 context 的話，再強的模型也會算錯，例如「大幅估錯使用者人數」；多對多的 join、篩選條件放錯位置、沒處理空值，這些錯誤都會悄悄讓結果失效，程式不會報錯。

他們的做法是替 agent 疊上六層 context。其中兩層和想學資料科學的人特別有關：一層是領域專家替表格與欄位寫的說明，記下業務上的意思和已知的陷阱；另一層讓 agent 去 Slack、Google Docs、Notion 找關鍵指標的標準定義和計算邏輯。agent 準不準，看的是有沒有人把定義寫下來、一直維護。

OpenAI 原圖「Data agent's layers of context」：由下往上疊六層，依序是 1 Table usage、2 Human annotations、3 Codex enrichment、4 Institutional knowledge、5 Memory、6 Runtime context；第 2 層是領域專家寫的表格與欄位說明，第 4 層是從 Slack、Google Docs、Notion 取得的指標標準定義 — OpenAI 內部 data agent 的六層 context。第 2 層與第 4 層都是人寫下、要持續維護的業務定義，agent 準不準，看的是這兩層有沒有人顧。（圖片來源：OpenAI〈Inside OpenAI's in-house data agent〉，經 Sunny DataScience 中文重點標註）

機制其實不複雜。AI 很擅長在給定的定義上把數字算出來，算得快，圖也畫得漂亮。定義本身如果沒有負責人、沒有版本，行銷說的「活躍」和產品說的「活躍」各算各的，AI 就會挑其中一個，很有效率地交出一張很有說服力的圖。

30 行程式小實驗：同一份資料換了指標定義，趨勢從「成長 99%」直接反轉為「衰退 29%」

這件事用一個小實驗就看得到。我想確認的只有一件事：同一份資料，定義換了，趨勢會不會連方向都換掉。

我做了一份玩具資料，模擬一個做報表的 SaaS 產品半年的事件紀錄。所有數字都是我設定的，先攤開來：

設定內容

付費公司

40 家，每家 3 個帳號；每個月有 6% 的公司退訂

付費帳號的行為

每月 80% 會登入，登入的人有 60% 會跑報表（產品的核心功能）

試用帳號

1 到 3 月每月新增 20 個；4 月辦了試用活動，之後每月新增 120 個

試用帳號的行為

註冊當月登入，10% 會跑報表，30% 下個月會再登入一次

第一段程式照這張表造出事件表。每一列記一件事：哪個帳號、屬於哪家公司、付費或試用、哪個月、做了什麼。

import numpy as np
import pandas as pd

rng = np.random.default_rng(15)
months = pd.period_range("2026-01", "2026-06", freq="M")
rows = []
paying = {f"c{i}": True for i in range(40)}            # 40 paying companies, 3 accounts each
for m_idx, month in enumerate(months):
    for c in paying:                                     # each month 6% of paying companies cancel
        paying[c] = paying[c] and rng.random() > 0.06
    for c, active in paying.items():
        for a in range(3):
            if active and rng.random() < 0.8:
                rows.append((f"{c}-{a}", c, "paid", month, "login"))
                if rng.random() < 0.6:
                    rows.append((f"{c}-{a}", c, "paid", month, "report"))
    signups = 20 if m_idx < 3 else 120                   # April: a campaign brings trial sign-ups
    for t in range(signups):
        rows.append((f"t{m_idx}-{t}", f"t{m_idx}-{t}", "trial", month, "login"))
        if rng.random() < 0.1:
            rows.append((f"t{m_idx}-{t}", f"t{m_idx}-{t}", "trial", month, "report"))
        if m_idx + 1 < len(months) and rng.random() < 0.3:
            rows.append((f"t{m_idx}-{t}", f"t{m_idx}-{t}", "trial", months[m_idx + 1], "login"))
events = pd.DataFrame(rows, columns=["account", "company", "plan", "month", "event"])

第二段是三種定義，每一種都是團隊裡常聽到的說法。A 有登入就算；B 要用過核心功能；C 以公司為單位，算付費公司裡至少有一個人跑過報表的家數。

login = events[events.event == "login"]
report = events[events.event == "report"]
mau = pd.DataFrame({
    "A 登入過的帳號": login.groupby("month")["account"].nunique(),
    "B 跑過報表的帳號": report.groupby("month")["account"].nunique(),
    "C 有人跑過報表的付費公司": report[report.plan == "paid"].groupby("month")["company"].nunique(),
})
print(mau)
print((100 * (mau.iloc[-1] / mau.iloc[0] - 1)).round(1))

跑出來，A 從 1 月的 105 個帳號變成 6 月的 209 個；B 從 51 個變成 49 個；C 從 31 家變成 22 家。三者單位不同，換成以 1 月為 100 的指數畫在一起：

折線圖，以 1 月為 100 的指數。A 登入過的帳號 4 月起急升，6 月 +99%（209 個）；B 跑過報表的帳號大致持平，6 月 −4%（49 個）；C 有人跑過報表的付費公司一路下滑，6 月 −29%（22 家）；4 月有一條虛線標示試用活動開始 — 同一份事件資料換了指標定義，趨勢走向完全相反：登入帳號（A）半年成長 99%，付費公司數（C）卻下滑 29%（Sunny DataScience 整理）。

三條線講的是三個故事。拿 A 去報告，是「活動很成功，活躍翻倍」；拿 B，是「核心功能的使用沒什麼變」；拿 C，是「付費客戶在流失」。

B 的持平還可以再拆一層：跑過報表的付費帳號從 50 個掉到 36 個，試用帳號從 1 個增加到 13 個，兩股力量剛好抵銷。總數看起來很穩，底下的付費客戶正在走。

這份資料是我造的，數字本身沒有意義，換一個亂數種子，B 會在正負兩成之間晃。機制倒是真的：定義換了，方向就換了，而且三個定義沒有一個是錯的。三個都能寫成乾淨的 SQL，AI 也都寫得出來。該問的是哪一個在回答眼前的問題：想知道活動有沒有帶來人，看 A；想知道產品有沒有被用，看 B；想知道營收有沒有風險，看 C。

回到 OpenAI 的範例 prompt。如果公司裡從來沒有人決定過「週活躍」用哪一個定義，agent 只能自己挑一個去算。我猜多半會是最好寫的 A。

資料科學值得學的重心：AI 接手寫 SQL 與算數字，人負責定義指標與因果推論

要學的東西沒有變少，重心換了。我把它整理成一張對照：

工作AI 已經能接手的越來越值錢的

查詢

AI 已經能接手的: 寫 SQL、修語法錯誤
越來越值錢的: 判斷 join 會不會把一筆訂單變成好幾筆、該排除哪些帳號

指標

AI 已經能接手的: 照定義把數字算出來
越來越值錢的: 決定定義、寫下版本、指定誰負責

圖表

AI 已經能接手的: 畫圖、排版
越來越值錢的: 知道這張圖不能支持什麼結論

解讀

AI 已經能接手的: 列出可能的原因
越來越值錢的: 分辨相關與因果，決定要不要做實驗

第一列還是要學到看得懂。AI 寫的 SQL 不會因為 join 錯鍵就報錯，程式照樣跑完，數字照樣出來。至少要會拿幾筆已知的紀錄回頭核對，會把總數拆回明細抽查幾筆。

第二列是這篇的重點。一個指標該寫下來的東西其實不多：算的單位是帳號、使用者還是公司；什麼事件算活躍；時間窗是自然月還是滾動 30 天；排除哪些帳號，像測試帳號、員工、機器人；這是第幾版、什麼時候改過；誰有權改。寫成一張卡，放在人和 agent 都讀得到的地方。2026 年這一層有個流行的名字叫語意層（semantic layer），OpenAI 發表文裡點名的 dbt、Snowflake、Databricks 都在做這一層；工具只是放定義的地方，內容還是要人決定。

第三、四列是推論。活躍數上升，不能單獨證明新功能有效：也許那個月有促銷，也許試用活動把分母灌大了，就像上面的 A。資料只能說明兩件事同時發生的時候，報告就不該寫成「造成成長」。要回答「造成多少」，得另外設計比較，這是〈LLM Eval 怎麼做才不會被騙？跑越多組，第一名越可能只是運氣（2026 實驗設計懶人包）〉要談的事。

就業市場的真實需求：美國預估資料職缺成長 35%，需要拿資料下判斷的非工程職變多了

需求面的訊號沒有變弱。美國勞動統計局 2026 年 8 月更新的職業展望，預估資料科學家的就業人數在 2025 到 2035 年間成長 35%，遠高於所有職業的平均。台灣這邊，104 在 2026 年 6 月的《AI 人才趨勢報告》裡統計，職缺內容明寫 AI 需求的工作五年成長 97.6%，成長最多的是專案與產品管理這類非工程職。我讀到的是，需要拿資料下判斷的位置變多了，而且不只在資料團隊裡。

這個判斷有邊界。如果你的工作是照固定格式每週拉報表，公司又已經有人把語意層維護好，這份工作確實在縮，AI 做得又快又穩。另一個邊界在找表：OpenAI 內部的 agent 已經會去讀產生每張表的程式碼，自己推出這張表裝了什麼。找表、讀表會繼續被接手；「哪一個定義回答這個業務問題」，還是要有一個人拍板，出事時也要有人負責。

再說一件對我不太有利的事。我自己在辦 AI 實戰營，賣課的人都有動機讓你覺得要多學一點。所以我把建議講窄：別為了背語法花兩年，那一段 AI 已經接手了。值得花時間的，是你所在領域的指標怎麼定義、資料怎麼產生、什麼時候需要做實驗。這些換了工具也帶得走。

結論：當 AI 幾秒就能生出圖表，最稀缺的專業是知道它不能支持什麼推論

回到開頭那句範例 prompt。AI 可以在幾秒內告訴你週活躍使用者為什麼變了，附上圖，列好原因，建議下一步。它沒辦法替你決定「活躍」算誰，也不會主動在報告最上面寫：這張圖只能說明登入變多了，還不能說明產品變好了。

當畫圖變容易，最稀缺的是知道那張圖不能支持什麼結論。

常見問題

AI 已經能寫 SQL 和跑 Python，現在還需要學資料科學嗎？

需要，但重心不再是背誦語法或手寫樣板演算法。AI 能把「明確的指令」翻成程式，但無法替你確認業務問題是否被正確拆解。資料科學的核心在於問題定義、指標架構、因果推論與實驗設計。

傳統資料分析師最容易被 AI 取代的環節是什麼？

單純從現成報表抓數字、把自然語言轉成簡單 SQL、產出標準折線圖等機械式取數工作，已被具備資料庫存取權限的 Agent 快速替換。只負責「取數」的角色面臨邊緣化，必須往「定義指標與診斷業務」升級。

什麼是「指標口徑漂移」，為什麼 AI 解決不了？

不同部門對同一詞彙的定義往往不同。例如「活躍使用者」是指登入過、有瀏覽商品、還是有送出訂單？如果沒有人在系統裡為資料口徑定錨，AI 會按照它猜測的上下文隨機抓取欄位，產出彼此矛盾且無法解釋的分析報告。

轉職者與學習者現在該把力氣投在資料科學的哪一段？

優先投入兩端：前端的「業務問題轉譯與指標設計」，以及後端的「實驗設計、統計推論與防禦性驗證」。學會設計 A/B 測試、懂得辨識共變數干擾、並能在 AI 生成分析結果時挑出數據偏差，是當前最稀缺的硬技能。

參考資料

OpenAI, Now everyone can put data to work（2026-09-10） https://openai.com/index/put-data-to-work/
OpenAI, Inside OpenAI's in-house data agent（2026 年初） https://openai.com/index/inside-our-in-house-data-agent/
技術評論社 gihyo.jp,〈OpenAI、ChatGPT WorkのDataエージェントを紹介〉（2026-09-11） https://gihyo.jp/article/2026/09/chatgpt-work-data-agent
Fangyu Lei et al., Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows（ICLR 2025, arXiv:2411.07763） https://arxiv.org/abs/2411.07763
Spider 2.0, Leaderboard（2026-10-16 檢視） https://spider2-sql.github.io/
Jinyang Li et al., Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs（BIRD, NeurIPS 2023, arXiv:2305.03111） https://arxiv.org/abs/2305.03111
Tao Yu et al., Spider: A Large-Scale Human-Labeled Dataset for Complex and Cross-Domain Semantic Parsing and Text-to-SQL Task（EMNLP 2018, arXiv:1809.08887） https://arxiv.org/abs/1809.08887
U.S. Bureau of Labor Statistics, Occupational Outlook Handbook: Data Scientists（2026-08-27 更新，2025–35 預測） https://www.bls.gov/ooh/math/data-scientists.htm
104 人力銀行,〈104學習發布《AI人才趨勢報告》企業招募十萬名AI人才〉（2026-06-24） https://blog.104.com.tw/104data-ai-trend-report-2026/