從資料集到分析報告

你是 Codex 資料分析報告規劃顧問，幫我用 Codex 從資料集生成結論可追溯、經得起核驗的報告。

【角色】
你知道怎麼用 Codex 做資料分析報告，怎麼保證每個結論能追回到資料、怎麼核驗避免錯誤結論。

【輸入】
- 資料來源和格式：___
- 報告要回答的問題：___
- 受眾和報告形式：___
- 對準確性的要求：___

【工作流程】
1. 把報告要回答的問題拆成可分析的子問題
2. 讓 Codex 做分析並標出每個結論的資料依據
3. 核驗關鍵結論（抽樣 / 交叉驗證）
4. 組織成適合受眾的報告

【輸出規範】
▌一、問題拆解
▌二、分析方案（結論帶資料依據）
▌三、關鍵結論的核驗
▌四、報告組織建議

【硬約束】
- 每個結論可追溯到資料，不憑空下結論
- 關鍵結論必須核驗，不直接信
- 敏感資料注意隱私
- 分析過程可復現
- 不替我假設業務含義，不清先問
- 給的方案具體可執行

資料分析的目標不是“分析本身”，而是交付能被別人使用的 artifact：管理層圖表、產品實驗讀數、模型評估、運營 dashboard 或研究備忘錄。

適合什麼任務

flowchart LR
    Raw["raw files"] --> Inventory["inventory"]
    Inventory --> Tidy["tidy / clean"]
    Tidy --> Join["join QA"]
    Join --> Explore["visualize / model"]
    Explore --> Report["report artifact"]
    Report --> Review["review / rerun"]

Codex 適合把資料工作做成可複查流程：

• 清點 CSV、TSV、Excel、JSON、Parquet 等輸入。
• 解釋每份資料的含義、主鍵候選、缺失值和異常。
• 編寫可重跑的清洗指令碼。
• 比較多種 join 策略並報告 match rate。
• 做 exploratory analysis、baseline model 和圖表。
• 生成 Markdown、notebook、.docx、PDF 或靜態報告站點。

不適合讓 Codex 直接“給結論”。沒有 inventory 和 join QA 的結論不能發表。

起始提示詞

我正在這個 workspace 裡做 data analysis project。

目標：
- 判斷靠近 highway 的 houses 是否有更低的 property valuations。

請先做，不要直接下結論：
- 閱讀 AGENTS.md，解釋推薦的 Python environment
- 載入 [dataset path] 下的 dataset(s)
- 描述每個檔案包含什麼、可能的 join keys、明顯 data quality issues
- 提出可復現 workflow，覆蓋 import、tidy、visualization、modeling、report output

約束：
- 優先使用 scripts 和 saved artifacts，不依賴一次性 notebook state
- 不要編造 missing values 或 merge keys
- 如果需要 skills 或 worktree splits，請說明原因

輸出：
- setup plan
- data inventory
- analysis plan
- first commands or files to create

這個 prompt 先要求 Codex 解釋環境、盤點資料和設計 workflow，而不是直接畫圖。資料分析裡，跳過 inventory 和 join strategy 往往是後面結果不可信的根源。

環境先定好

開始新資料專案時，先讓 Codex 讀專案規則並確認環境：

• canonical Python environment。
• package manager。
• raw、processed、analysis、output 目錄。
• notebook 和 script 的關係。
• artifact 命名和復跑方式。

小型 AGENTS.md 就夠：

## 資料分析預設規則

- 使用 `uv run` 或專案現有 Python environment。
- source data 放在 `data/raw/`，cleaned data 寫入 `data/processed/`。
- exploratory notebooks 放在 `analysis/`，final artifacts 放在 `output/`。
- 永遠不要覆蓋 raw files。
- 優先使用 scripts 或已提交 notebooks，不依賴未命名 scratch cells。
- 合併 datasets 前，先報告 candidate keys、null rates 和 join coverage。

如果 repo 還沒有定義 Python 環境，先建立可復現 setup 並說明執行方式。對資料分析來說，這一步比直接畫圖更重要。

先做資料盤點

第一輪只問 inventory，不問結論。讓 Codex 回答：

• 這裡有哪些 file formats。
• 每份 dataset 似乎代表什麼。
• 哪些 columns 可能是 target、identifier、date、location 或 measure。
• 明顯資料質量問題在哪裡。
• 哪些欄位不能直接用於 join。
• 哪些列需要抽樣或隱私處理。

盤點輸出應該儲存到專案裡，例如 analysis/inventory.md 或 output/data-inventory.md。不要只把結論留線上程裡。

Tidy 和 Merge

真實資料最容易在 merge 出錯。primary key 不清楚時，naive merge 可能丟資料，也可能製造重複。

在真正 merge 前，讓 Codex 先 profile：

• 檢查 candidate keys 的 uniqueness。
• 測量 null rates 和 formatting differences。
• 歸一化 casing、whitespace、address formatting 等明確問題。
• 跑 trial joins 並報告 match rates。
• 寫出 safest merge strategy，再生成 final merged file。

如果需要派生 key，例如 normalized address、parcel identifier 或 location join，讓 Codex 先解釋 tradeoffs 和 edge cases。

探索和建模

Exploratory data analysis 適合隔離。一個 worktree 試 address cleanup 或 feature engineering，另一個 worktree 做 charts 或 alternate model direction。這樣每個 diff 更容易 review，也避免一個長執行緒混合互斥想法。

git worktree add ../analysis-highway-eda -b analysis/highway-eda
git worktree add ../analysis-model-comparison -b analysis/highway-modeling

建模時先用可解釋 baseline。要求 Codex 明確說明：

• target variable 和 feature definitions。
• controls 選擇及原因。
• leakage risks 和 exclusions。
• split、evaluation 或 uncertainty estimate 的選擇。
• 結果的自然語言解釋。

第一版模型弱也有價值。它能告訴你問題出在 model、features、join quality，還是問題本身定義不清。

交付結果

按 audience 選擇 artifact：

• 技術協作者：Markdown memo。
• 運營團隊：spreadsheet 或 CSV。
• 格式和批註重要：.docx brief。
• 最終分享：PDF appendix 或 deliverable。
• 需要 URL：lightweight dashboard 或 static report site。

交付物必須包含 caveats。比如 join quality 不完美、sampling bias、model assumptions fragile，都應該寫進報告，而不是藏在工作過程裡。

可沉澱的 Skills

穩定後，把重複步驟做成 repo-local skills：

• refresh-data
• merge-and-qa
• publish-weekly-report

長期看，這比每次把同一段 procedural prompt 貼進執行緒更可靠。

驗收清單

• raw data 沒有被覆蓋。
• inventory、清洗指令碼、merged output 和報告都能重新生成。
• join strategy 有 match rate 和異常說明。
• 模型結論包含 controls、leakage risks 和不確定性。
• artifact 面向目標受眾，而不是隻給模型自己看。
• 報告明確寫出 caveats 和不能下結論的地方。