Debug 根因分析助理（通用）
用途
系統性分析任何語言的錯誤現象，輸出三個根因假設（機率排序）、對應的驗證步驟與修復方案，讓你有結構地縮小問題範圍而不是亂槍打鳥。
何時用
- 適合：遇到無法快速定位的 bug、不熟悉的錯誤訊息，或同一個問題反覆出現卻找不到根本原因時，語言不限。
- 不要用：專門的 Python 根因分析用「Python 除錯版」更精準；問題已經定位只是不知道怎麼改的話，直接問怎麼修比跑完整分析快。
Prompt
請幫我系統性分析這個 bug 的根本原因。
問題現象：{{描述你觀察到的異常，例：每隔約 2 小時後台 job 就掛掉}}
錯誤訊息：{{完整的錯誤訊息或 log 片段，沒有的話填「無」}}
相關程式碼：{{觸發錯誤的程式碼片段，或說明出錯的流程}}
已嘗試的解法：{{你試過哪些方法沒效，填「無」表示還沒嘗試}}
執行環境：{{語言版本、OS、部署環境，例：Node 20 / Ubuntu 22.04 / Docker}}
輸出格式：
**根因假設（3 個，依機率高→低排序）**
1. [假設1] — 機率理由
2. [假設2] — 機率理由
3. [假設3] — 機率理由
**驗證步驟（對應上面三個假設）**
- 驗證假設1：[具體指令或操作]
- 驗證假設2：[具體指令或操作]
- 驗證假設3：[具體指令或操作]
**對應修復方案**
- 若假設1成立：[修復方向]
- 若假設2成立：[修復方向]
- 若假設3成立：[修復方向]
**預防措施**（修好後怎麼讓同類問題不再發生）範例 / 變體
- 填好變數：問題現象填
每隔約 2 小時後台 job 就掛掉、錯誤訊息填OOMKilled、執行環境填Python 3.11 / Kubernetes 1.29、已嘗試解法填調大 memory limit 沒有用。 - 變體（只要最高機率假設）：在輸出格式前加「只輸出最高機率的假設與驗證步驟，其餘略過」，適合時間緊時的快速切入。
- 變體（加 timeline 分析）：在問題現象後加「這個錯誤從 2026-06-01 開始出現，之前都正常，請特別分析那天可能的變更因素」。
🎯 範例輸出（實測）
在 Claude.ai 跑這句、問題現象填「每隔約 2 小時後台 job 就掛掉」、錯誤訊息填「OOMKilled」、執行環境填「Python 3.11 / Kubernetes 1.29」、已嘗試解法填「調大 memory limit 沒有用」的結果：
點開看 AI 實際輸出
根因假設（3 個，依機率高→低排序）
[記憶體洩漏] — 機率高（70%） Job 每 2 小時規律觸發 OOM，且調大 limit 無效，高度符合記憶體持續洩漏的特徵：大物件（DataFrame、圖片 buffer、DB 連線）在每輪迴圈後沒有正確釋放，最終撐破 limit。
[外部資料量爆炸] — 機率中（20%） 每 2 小時拉取的資料量可能在特定時間點暴增（例：每日交易高峰、批次報表），一次性載入全量資料至記憶體造成 OOM。
[子程序/執行緒殭屍堆積] — 機率低（10%） 若 Job 使用 multiprocessing 或呼叫外部程式，子程序未正確 join/terminate 可能導致記憶體不斷被佔用。
驗證步驟（對應上面三個假設）
- 驗證假設1：在 Job 的主迴圈裡加
import tracemalloc; tracemalloc.start()，每輪結束時輸出 top-10 記憶體佔用物件，觀察是否有某個物件數量持續增長 - 驗證假設2：在 Job 開始時 log 本輪資料筆數 + 原始資料大小（bytes），比對 OOM 前的最後幾筆 log 是否有特別大的批次
- 驗證假設3：執行
kubectl exec <pod> -- ps aux | grep defunct查看是否有殭屍子程序
對應修復方案
- 若假設1成立：在迴圈末尾加
del df; gc.collect()，大型物件改用 generator 分批處理而非一次載入 - 若假設2成立：改用分頁或 chunking 拉資料，每批 10,000 筆，處理完釋放再拉下一批
- 若假設3成立：確保
multiprocessing.Process呼叫後有對應的p.join()，或改用concurrent.futures.ProcessPoolExecutor
預防措施
- 在 Kubernetes Deployment 設定
memory request和limit相等（避免 Burstable QoS 造成調度不穩） - 加 Prometheus
process_resident_memory_bytes監控指標，設定記憶體成長超過 80% limit 即告警，不用等 OOMKilled
💡 實測心得：「已嘗試的解法：調大 memory limit 沒有用」這行輸入很關鍵——AI 用它排除了「limit 設太小」這個最常見假設，才能把焦點放在真正的洩漏問題上。填越詳細已嘗試的步驟，AI 的假設就越精準。
延伸
重點來了：「三個假設機率排序」這個格式的價值在於強迫 AI 承認不確定性，而不是給你一個假裝確定的答案。機率低的假設也要列出來，因為有時候最奇怪的假設才是真相。驗證步驟如果你跑完後發現假設1不成立，把結果回饋給 AI 繼續追蹤，通常兩三輪就能定位。