晚上 11 點,你的錯誤追蹤系統一直跳警報,你盯著一個 8 個月沒碰過的服務的 stack trace。寫程式教學裡那種「跟模型聊天、迭代提示詞」的文化假設你有時間慢慢來。你沒有。你有一個客戶在等、一個 Sentry 警報一直 ping。
這篇談真實生產環境的除錯,不是綠地寫新東西。pattern 不一樣。速度比優雅重要。目標是「理解 → 修 → 驗證 → ship」,不是「寫最漂亮的程式碼」。
最有用的單一工作流:把 trace 餵給它
最大的槓桿動作也最沒人在用:把實際的 stack trace、實際的錯誤訊息、實際相關的程式碼一次貼給 LLM。不要說「我有 TypeError 你能幫忙嗎」 — 整段 trace 全文,加上 trace 指到的檔案。
Claude 4.5 / 4.6 Sonnet 和 GPT-5 在常見的 production case(off-by-one、null 處理、型別混淆、race condition 訊號、async 計時、regex bug)能可靠地從中找到 bug,命中率 60-80%。即使沒直接修好,也會大幅縮小搜尋空間。
關鍵洞察:LLM 讀 stack trace 比讀你的專案厲害很多。所以你給的失敗具體 context(log、trace、錯誤文字)越多越好。給太少,它會編出聽起來合理的胡說。
四種生產環境 bug,LLM 各自處理得如何
純邏輯 bug(off-by-one、null deref、型別混淆)。LLM 找得很快。貼上函式加失敗輸入加錯誤,大多數情況幾分鐘內解決。
分散式 / 並行 bug(race condition、deadlock、最終一致性問題)。LLM 在這方面普通。它能建議 pattern 去找,但很少能從你的特定程式碼裡診斷出真正原因,沒有 runtime instrumentation 不行。用它來產出假設,再每個測。不要相信第一個「看起來是這個問題」的答案。
效能 bug(慢 query、N+1、memory leak)。給它 profiler 輸出、慢 query log、或 memory snapshot,LLM 處理得很好。只說「這個很慢」就處理得很爛。永遠要貼數字。
環境 bug(本地 work、production 爛掉)。LLM 在這方面弱,因為差異通常在它看不到的地方 — 你特定的 Docker image、你的環境變數、你的 DNS、你的 IAM policy。用它來列出可能原因(「本地跟 production 對 S3 SignatureDoesNotMatch 錯誤可能差在哪些地方?」),然後一個個檢查。
LLM 錯的時候,錯得很有自信
這是 production 用法最重要的教訓。LLM 除錯有時會很有自信地指出一個 bug,但那不是真正的 bug。它會寫出看起來合理的修法。你 deploy 下去。錯誤繼續發生,因為真正的 bug 在別的地方。
對策:在 deploy 修法之前,一定要在本地或 staging 重現 bug。修法只有在「壞掉的案例變成 work 的案例」這個重現流程裡才算驗證。「看起來對」不是驗證。
本地重現不出來(間歇性 / 資料相依 / 負載相依的 bug)就先加觀測性,再修。把失敗函式的輸入 log 起來。加一個你可以在 log 裡 grep 的結構化事件。等它再次失敗、拿到資料、有資料在手再修。跳過這步你會修錯三次才修對。
真正在事故中有效的提示詞 pattern
**「先懷疑最簡單的。」**加這句到你的提示詞裡。LLM 預設會建議精緻的 root cause。叫它先懷疑最簡單的(打字錯誤、剛 deploy、設定),會更快接近真相。
**「給我三個可能,不要只給一個。」**原因不明的時候,要求三個有嚴重度排序的鑑別假設,比要求「答案」有用。你想要的是清單去檢查,不是有自信但錯的宣稱。
**「先不要寫修法 — 只解釋發生什麼事。」**資深除錯 pattern:把診斷跟修法分開。叫 LLM 走過呼叫路徑、先解釋失敗。常常你會比它先發現真正問題。
**「你會加什麼 log 來確認這個假設?」**比修法更好的是「修之前先驗證的方法」。讓模型建議能證明或推翻它理論的最小 logging 或 instrumentation。
真的有幫助的工具 vs 只是宣稱有幫助的工具
Cursor 和載入你 repo 的 Claude Code 對「找呼叫點」/「這個函式還用在哪」這類問題很強。當 codebase 大的時候比 grep 省真實時間。
Sentry 的 AI 建議和類似的錯誤追蹤 AI 功能是中等。它們傾向建議防禦性程式碼,不修 root cause。當作「提示去查」而不是「套用這個修法」。
GitHub Copilot Chat 在 IDE 裡對「修這個小東西」夠用,但 production 級除錯需要的 context 不夠,除非你貼 trace 進去。
純終端機 LLM CLI 工具(Aider、Claude Code、Codex CLI)出乎意料的強,因為你可以直接 pipe log、trace、指令輸出。事故時 kubectl logs ... | claude 是個 power move。
什麼時候不適合用 LLM 除生產 bug
**真有時間壓力、而你本來就不會這種除錯,就不要用。**客戶在尖叫、你從沒除過這類 bug 的話,LLM 可能帶你走錯路而你評估不出來。讓資深 on-call 處理。
安全事故不要用,除非是你公司核可的 sandboxed 模型。在事故中把 auth token、客戶資料、敏感 log 貼到第三方 API 是另外一個合規事件,壞處比好處大。
**事後檢討不要用 LLM 寫。**post-incident write-up 必須是你誠實的推理,不是模型的合理重建。用它整理 log 或時間線可以,不要用它起草「為什麼會發生」。
下一步
- 怎麼挑 coding agent — Cursor vs Claude Code vs 其他,特別考慮除錯
- LLM observability — 把觀測性建進你的 LLM 系統,以後除錯更容易
- 幻覺 — 模型有自信地說錯原因的時候在發生什麼