很多人用 Claude Code 寫程式，其實還停留在“哪裡壞了就讓它修哪裡”。

這也是最容易把專案搞爛的一種用法，我最近幾天也是借鑑大佬們的思路一直在不停的修改完善專案。
因為真實專案裡的 bug，通常不是一個孤立存在的小洞。
當你看到的報錯、頁面異常、某個按鈕失效，大概率只是系統問題冒出來的一個尖角。
如果你直接把這個尖角丟給 AI，說“幫我修一下”，它很可能真的只幫你把尖角磨平。
表面上好了，底層邏輯並沒做修改。
下一次換個場景，相同的問題又炸了。
再下一次，繼續補，其實都是相同的錯誤邏輯。
最後程式碼裡全是補丁，專案越來越能跑，但也越來越不敢動。
所以我現在用 Claude Code，有一個很重要的習慣：
不要一上來讓它改程式碼，先讓它判斷問題為什麼會發生。
我會更傾向於這樣問：
先不要修。
幫我分析這個問題背後的根因。
可能是哪一層設計、狀態流轉、資料結構或邊界條件出了問題？
這時候 AI 的角色就變了。
它不是一個“修 bug 的外包”，而是一個“幫你排查系統的人”。
這個區別很大。
你給它的也不應該只有一段報錯，而是要盡量給完整上下文：相關檔案、調用鏈、用戶操作路徑、期望結果、實際結果、之前改過什麼。
上下文越完整，它越有可能幫你看到真正的問題，而不是只在表面打補丁。