UNIT 03 · 120 MINUTES
Debug：從症狀到可靠修復
學習目標：用重現案例、證據和假設排除找出根因；完成最小修復，再用回歸測試守住這個行為。不要先猜一個看似合理的修補。
120 分鐘安排
10 分症狀分類
20 分建立 Repro
25 分證據式調查
35 分修復案例
20 分回歸驗證
10 分自評記錄
本單元計時00:00:00
DEBUG LOOP
除錯循環：觀察 → 假設 → 驗證 → 修補
觀察 Observation
記錄輸入、實際輸出、預期輸出、環境和錯誤訊息。避免用「偶爾壞掉」當完整描述。
假設 Hypothesis
列出可能原因及各自證據。先找最容易驗證且能解釋症狀的假設。
驗證 Experiment
讀程式、加最小診斷、重現 bug；每次實驗只改變一個因素。
修補 Fix
修真正的原因，而非只隱藏錯誤訊號；加入回歸測試，確認沒有破壞鄰近行為。
CASE / TIMEZONE BOUNDARY BUG
案例：週日深夜訂單沒有出現在週報
客服回報：台北時間週日 23:30 的訂單不會出現在本週報表，但同一時間建立的平日訂單正常。初步懷疑 UTC 轉換、日期區間上界或排程執行時間。
根因必須從輸入時間和查詢條件證明，不能單靠直覺。Codex 調查任務
請調查週報漏掉「週日 23:30 Asia/Taipei 建立的訂單」問題。先不要修改。追出排程入口、週區間計算、時區轉換、資料庫查詢和相關測試。用此案例算出預期 UTC 時間與查詢範圍，指出哪些條件能解釋漏單、需要什麼證據驗證。每項結論附檔案位置。
如何評估調查品質
- 是否找到實際生產路徑而不是類似但未使用的 helper？
- 是否確認資料庫儲存的時區規則和端點是否含括？
- 是否區分「時區假設」與程式碼中可證明的事實？
- 是否找到一個簡單輸入就能讓現有測試失敗？
PROMPT PATTERNS
兩階段 prompt：先診斷，再修復
LAB / YOUR BUG
練習：挑一個真實問題修好
選一個小 bug：手機版排版錯位、日期差一天、空欄位當掉、搜尋結果不準或測試偶發失敗。
- 記錄最小重現步驟；避免同時描述多個 bug。
- 讓 Codex 先調查並列假設。對每個假設問：「什麼證據可推翻它？」
- 讓 Codex 找到或建立能重現的測試；確認該測試在修復前會失敗。
- 採納最小修復後，執行目標測試，再執行受影響的測試集合。
- 看 diff，檢查測試有沒有真的鎖住原錯誤邊界。
RECAP
理解題
Codex 找出三個可能根因後，接下來最好的做法是？