用 Claude Debug 的正確姿勢：不是貼 Error 等答案，而是讓它陪你系統化找問題

大多數開發者用 Claude Debug 的方式是：把錯誤訊息貼上去，等它給答案。這個方式能解決一部分問題，但在遇到複雜 bug、或者錯誤訊息根本沒有指向真正問題的情況下，效果很有限。

更好的方式是：把 Claude 當成你的 Debug 夥伴，而不是答案機器。

為什麼「貼 Error 等答案」常常不夠

錯誤訊息告訴你 bug 在哪裡報錯，但不一定告訴你問題的根源在哪裡。一個 NullPointerException 可能只是症狀，真正的問題可能是三層函數呼叫之前的一個假設沒有被驗證。如果你只把 NullPointerException 和它出現的那幾行貼給 Claude，它只能在那幾行的範圍內分析，而看不到更大的上下文。

另一個常見的情況是：你遇到的問題根本沒有明顯的錯誤訊息——程式能跑，但結果不對；或者在特定條件下才會出問題，平時很難復現。這種情況，光靠 Error 訊息完全沒用。

更好的 Debug 框架：診斷優先

在把任何東西貼給 Claude 之前，先做一個「診斷框架」：

我遇到了一個 [bug 類型] 的問題，具體表現是：[描述你觀察到的症狀，越具體越好]

我已經確認的事情：
- [你已經排除的可能原因]
- [你已經嘗試過的解法]

我不確定的地方：
- [你懷疑可能有問題的地方]

相關的代碼和錯誤訊息：
[貼上代碼和錯誤]

我的環境：[語言版本、框架版本、OS 等]

這個框架比直接貼 Error 強在哪裡？它迫使 Claude 在你已知的範圍之外思考，而不是重複你已經試過的方向。它也把問題的上下文告訴了 Claude，讓它能提出更有針對性的診斷方向。

讓 Claude 給你「診斷清單」，不是直接答案

對於複雜的 bug，比起讓 Claude 直接給答案，更有效的做法是讓它給你一個「可能原因清單」，然後你自己驗證：

根據以下信息，給我列出這個 bug 最可能的 3-5 個根本原因，以及驗證每個原因的最快方法。不要直接給我修復方案，先讓我確認原因。

這個方式有幾個好處：

• 你能學到 Claude 的診斷思路，而不只是拿到一個你不理解的答案
• 你能驗證 Claude 的猜測是否正確，而不是盲目採納
• 如果你的實際情況和 Claude 的假設不符，你能馬上告訴它，讓它調整方向

特別情況：沒有 Error 訊息的 Bug

「程式能跑但結果不對」是最難 Debug 的情況。這時候的 Claude 使用策略：

第一步：定義「正確」應該長什麼樣

我的程式在輸入 [具體輸入] 時，應該輸出 [預期輸出]，但實際輸出是 [實際輸出]。請幫我分析這兩個輸出的差異，以及可能導致這個差異的原因。

第二步：讓 Claude 設計測試案例

請幫我設計 5 個測試案例，能幫我縮小問題範圍，確定 bug 是出在 [模組 A] 還是 [模組 B]。

第三步：用 Rubber Duck 模式

我要向你解釋這段代碼的邏輯，請在我說明的過程中，如果你發現任何假設可能有問題，隨時打斷我。[開始逐步解釋你的代碼邏輯]

「向 Claude 解釋你的代碼」這個動作本身，常常能讓你在說明的過程中自己找到 bug——這就是 Rubber Duck Debugging 的 AI 增強版。

當 Claude 給的答案沒有解決問題

試了 Claude 的建議，問題還在？不要從頭再問一次。要說明你試了什麼，結果是什麼：

我試了你說的方法，具體做了 [說明你的操作]，但問題還是存在，現在的錯誤訊息變成了 [新的錯誤訊息]。這表示什麼？

這個「繼續對話」的方式，讓 Claude 能根據你的新信息調整它的診斷，而不是重新從頭開始。每一輪的試錯都讓 Claude 對你的問題有更多了解，診斷準確率也會隨之提升。