資料分析達人：數字不能「差不多對」，沒跑過程式就不算數

這行的痛點

寫程式和做分析，最大的差別在於分析「通常只有一個正確答案，而且來自單一正確的資料來源」——這是 Anthropic 自己內部部署後點出的關鍵差異。軟體工程靠測試護欄抓 bug 很好用，但分析沒有「測試通過」這回事，只有「這個數字對不對」，一個 join key 走錯，整份報表就是錯的，而且不會有紅字警告你。

這行日常卡關的地方很具體：兩份欄位命名不一致的匯出檔要合併去重、每個月固定要跑一輪 SQL 報表和圖表、資料表一多，join key 該走哪條路連資深分析師都要想一下。傳統做法卡在 Excel 手拉公式——業界常引用「94% 被檢查過的試算表都含有公式錯誤」，而 CLI 型 AI 的價值在於把這些手動步驟變成留檔、可重跑的腳本，下個月新檔案來，直接重跑就好。

但這行也是最容不得 AI 亂猜的地方。資料倉儲一接上，欄位名對 AI 來說只是字面符號，沒有商業定義、沒有正確 join 路徑——缺的細節它會自己發明，而且往往發明得很有自信、看起來完全合理。所以資料分析師用 CLI AI，重點從來不是「叫得動 SQL」，而是「怎麼把脈絡餵夠、怎麼讓每個數字都能回頭驗證」。

動手前的準備

• Claude Code 安裝與基本操作：先看 Claude Code 教學第 1 章
• Codex CLI 安裝與登入：先看 Codex CLI 教學第 1 章
• 至少看得懂基礎 SQL 與欄位定義（不用會寫 Python，但要看得懂資料代表什麼）
• 手上要有能測試的真實資料（CSV 或資料庫連線權限）；處理個資或財務資料前，先確認自己的方案資料訓練政策
• 若要接資料庫，先弄清楚自己有哪些 MCP server 可用（BigQuery、DuckDB/MotherDuck、Postgres 等）；還沒有的話，先從本機 CSV 開始練，不急著連正式資料倉儲

場景一：CSV去重與樞紐分析

分析師手上常常是兩份欄位命名不一致的匯出檔——例如 Salesforce 匯出跟帳務系統匯出，email 大小寫也不統一，要合併、去重、做月×區域營收樞紐分析。傳統做法是在 Excel 手拉公式，這類手動整併正是最容易出錯又最花時間的環節。

Claude Code 怎麼做

把 CSV 放進專案資料夾，終端機打 claude 啟動，接著分步下指令：

Read customers.csv. Dedupe on email, keeping the row with the most recent signup_date. Write to customers_deduped.csv. Report starting row count, removed rows, and five examples of deleted records.

Join salesforce_export.csv and billing_export.csv on email. Treat emails as case-insensitive and strip whitespace before matching. Save merged file as accounts_merged.csv plus a separate file of non-matching rows.

From accounts_merged.csv, keep only 2026 signups, then build revenue pivot by month and region. Save as revenue_pivot.csv and print row count after filter step.

From revenue_pivot.csv, make bar chart of revenue by region and line chart of revenue by month, saved as PNGs. Then write summary CSV with month, region, revenue, and percent change versus prior month, formatted for Excel.

核心觀念：Claude Code 從不親手做算術，它寫 pandas 腳本在本機執行，每一列都由確定性程式計算過，繞開聊天式分析容易出現的幻覺風險；腳本留檔即審計軌跡，下個月新匯出檔案來，直接重跑同一套腳本。原始匯出檔設唯讀，每次轉換寫新檔，不要讓 Claude 把 CSV 當純文字直接編輯。

換成 Codex CLI

Codex 官方 use case 支援類似流程：用 @transactions.csv 語法把檔案直接帶進 context，官方建議先請它「檢視欄位名」再分析；輸出習慣是產生 HTML 互動式圖表讓你在內建瀏覽器裡探索，跟 Claude Code 偏好輸出 PNG＋CSV 交付的風格不太一樣，但核心紀律一致——先看懂 schema 再動手。

場景二：每月SQL報表自動化

分析師 Freddie Robinson 想把「每月客戶聯繫分析報告」整段交給 Claude Code：連資料庫、寫 SQL、出圖、寫分析。他第一次只給了角色描述加任務指令就放手，結果 SQL 錯誤連發——Claude 不知道資料表和欄位代表什麼意思，亂猜「活躍使用者」該算哪個欄位。

Claude Code 怎麼做

1. 1

   裝一個符合自家資料庫的 MCP SQL server（在市集搜「MCP SQL server」，挑符合自己資料庫種類的實作），讓 Claude Code 能安全連線讀庫執行查詢。

2. 2

   寫一份「到職文件」餵給 Claude——不是隨口交代，是每一個欄位的資料表文件、想要的查詢清單（白話描述就好）、範例 SQL 範本、圖表風格指南（色盤、圖型、軸慣例），加上上一期報告當結構範本。

3. 3

   用 todo.txt 管理工作流（待辦＋已完成清單），強制 Claude 一次只做一件事，不要一次衝去做五件事。

4. 4

   拆成兩個獨立對話：Phase 1「Query Writer」專職產 SQL 和出圖；Phase 2「Analyst」專職寫報告、組裝文件。

可以直接放進 CLAUDE.md 的通用護欄 prompt：

Don't guess or estimate. Write Python code that loads the file, run it, then summarize. Every number must come from code execution. Start by printing: column names, data types, row count, min/max date.

作者自評 Claude 從「junior 實習生」進步到「堪用的 mid-level 分析師」；到職文件是一次性投資，之後每個月重複使用。另一位作者用類似的 todo.txt 藍圖搭配 CLAUDE.md 錨定 schema，自稱「幻覺指標降到接近零」——這是單一來源自報數字，僅供參考不當定論。

換成 Codex CLI

Codex CLI 目前找不到這職業「每月報表自動化」的第一手案例，但用它的通用能力應該也能做到類似效果：Codex 官方 use case 主張用 AGENTS.md 定專案憲法（跟 CLAUDE.md 對應的角色），寫清楚環境、目錄慣例、常見查詢；再靠 codex exec --skip-git-repo-check 的非互動模式把驗證腳本掛進排程或 CI/CD，等於用工程紀律達成 Freddie Robinson 手動維護 todo.txt 想要的「強制分階段、每步驗證」效果，但這是方法論類比，不是同職業實測對照。

場景三：查資料倉儲別踩雷

想在終端機直接用自然語言查公司的 BigQuery，不想每次都開 console 手寫 SQL。這步很多分析師會做，也是本行最容易被 AI 靜默出錯坑到的地方——資料顧問公司 OWOX 整理過真實翻車紀錄：IAM 角色缺失時，BigQuery MCP 不會報錯，Claude 直接生出一份看起來完整的報告，實際案例是某品牌只有 3 個行銷通路，AI 生出了 6 個。另一個常見錯誤是把 total_price 欄位直接當營收，漏算退貨、折扣、稅金調整，數字可以偏掉 8–12 個百分點。

Claude Code 怎麼做

1. 1

   gcloud auth application-default login 完成認證。

2. 2

   專案根目錄的 .mcp.json 掛 Google 官方 MCP Toolbox：

   {
     "mcpServers": {
       "toolbox-bigquery": {
         "command": "npx",
         "args": ["-y", "@toolbox-sdk/server", "--prebuilt=bigquery"],
         "env": {
           "BIGQUERY_PROJECT": "YOUR_PROJECT",
           "BIGQUERY_MAX_QUERY_RESULT_ROWS": "200"
         }
       }
     }
   }

   複製
3. 3

   掛上之後有九個預建工具可用——發現類（list_dataset_ids、get_table_info）、SQL 類（execute_sql）、分析類（ask_data_insights、forecast），但探索用歸探索用，正式報表另外處理。

4. 4

   生產環境一定要切唯讀模式：自訂 tools.yaml 只註冊發現與讀取類工具，或用 IAM deny policy 把寫入權限拔掉；資料層級綁 roles/bigquery.dataViewer 限定特定 dataset。

5. 5

   高風險用途（高管儀表板、預算決策）不要走 ad-hoc 探索，改成 governed 語意層／data mart——join 由分析師事先鎖定、SQL 預先定義、留審計軌跡。

換成 Codex CLI

Codex CLI 目前找不到資料倉儲直連的第一手案例，但用它的通用能力應該也能做到類似效果：DataCamp 教學示範的非互動驗證模式可以借用同一套邏輯——

codex exec --skip-git-repo-check "Read transactions.csv. Write and run a script checking if 'quantity' column contains negative numbers. Print 'DATA VALIDATION FAILED' or 'PASSED' accordingly."

這種「用程式碼把驗證條件寫死、印出明確 PASS/FAIL」的紀律，正是防禦 BigQuery MCP 幻覺同一套邏輯的延伸應用，但原文情境是本機檔案驗證，不是資料倉儲直連，對照時要老實說這是方法論延伸，不是同款實測。

場景四：官方95%準確率解法

Anthropic 自己的資料科學團隊也曾被例行 ad-hoc 取數請求淹沒，策略性工作（因果建模、預測）被排擠。他們拿自家 Claude 重建了整套查詢自動化，現在內部 95% 的商業分析查詢由 Claude 自動化完成，綜合準確率約 95%。更值得抄的是過程中量到的一組數字：沒有 skills 時準確率不到 21%，加上 skills 之後穩定超過 95%——差距不是模型變聰明了，是脈絡結構補齊了。

Claude Code 怎麼做

1. 1

   建一份 knowledge skill——不是寫給人看的文件，是寫給 Claude 檢索用的參考檔：schema 定義、指標口徑（例如「活躍使用者」到底算哪個欄位）、常見查詢範本、圖表風格指南。可以先試 npx skills add anthropics/knowledge-work-plugins --skill sql-queries，再疊自己團隊的慣例。

2. 2

   CLAUDE.md 放專案脈絡——目標、schema、join key、常犯錯誤、期望輸出格式；官方原話是「context 勝過聰明的 prompt」。

3. 3

   有餘力可以加一層對抗式覆核：讓另一個 subagent 專門挑戰第一輪分析的假設。官方量到的代價是準確率多拿 6%，但 token 多花 32%、延遲多 72%——這筆帳自己權衡，不是每份報告都值得開這層。

4. 4

   別把力氣花在餵歷史語料：官方測過直接丟幾千條歷史 SQL 進去，準確率只提升不到 1%，瓶頸在結構不在資訊量。

5. 5

   幫 skill 檔案排定期維護：Anthropic 內部 90% 的資料 PR 現在會同步更新對應 skill 檔，skill 維護是工程紀律的一部分，不是寫一次就放著不管——放著一個月不維護，context 漂移後準確率會掉回 65%。

換成 Codex CLI

Codex 官方文件沒有對應「內部準確率從 21% 到 95%」這類數字，這是 Anthropic 自家內部部署案例，找不到對等的 Codex 對照。但方法論骨架是共通的：AGENTS.md 扮演 Claude 這邊 CLAUDE.md 的角色，官方 use case 同樣強調先建目錄慣例、先 profile 資料再動手、優先用可解釋的基線模型而非黑箱——本質上都是「把脈絡結構化」，只是 Codex 官方端沒有揭露對等的團隊規模量化成效。

常踩的坑

延伸資源

• How Anthropic enables self-service data analytics with Claude（官方架構全文）
• Freddie Robinson：Claude Code as a Data Analyst — From Zero to First Report
• OWOX：BigQuery MCP 翻車實錄與防禦模式（業者文，推銷段落打折看）
• DataCamp：Codex CLI for Data Workflow Automation