AI 的程式除錯：為什麼它改一個壞兩個
對策四：上下文工程，給 AI 一張正確的地圖
既然 AI 的盲點是「看不到全域」，那你的任務就是幫它補上地圖。在請它除錯之前，先給它這幾樣東西：這個函式的呼叫端有誰、相關的資料模型長什麼樣、有什麼專案慣例或限制（例如「本專案禁止使用 optional chaining，因為要支援舊版瀏覽器」）、以及完整的錯誤堆疊與重現步驟。
進階一點，你可以用工具把 repository 的結構、相關檔案一起餵進去，或使用支援專案索引的 AI 開發工具。但即使工具再強，你口頭補充的「地方知識」仍然是 AI 最缺的那一塊。花三分鐘寫清楚限制條件，往往能省下三小時的來回除錯。
對策五：程式碼審查的「三問法」
面對 AI 的每一個修改建議，養成問三個問題的習慣。第一問：「這個修改解決的是根因還是症狀？」如果它只是加了 try/catch 或預設值，那大概率是症狀。第二問：「這個修改會影響哪些其他呼叫端或資料流？」如果它答不出來，你就自己 grep。第三問：「如果這個修改是錯的，我要怎麼最快發現？」如果答案是「等使用者回報」，那你就該補測試了。
這三問不需要很深的功力，卻能過濾掉大部分的危險修改。AI 是很會說話的助手，但它不會主動提醒你風險；風險意識必須由你來補。
五、工具與流程：把 AI 放進對的位置
除了心法，流程與工具的自動化防線也很重要。以下三層設計，可以有效降低 AI 修改造成的連鎖災難。
三層防線：靜態分析、CI、覆蓋率
第一層是靜態分析。ESLint、Pylint、golangci-lint 這類工具能在幾秒內抓出未使用的變數、可疑的 await、遺漏的錯誤處理。把 lint 設成 pre-commit hook，AI 的修改連提交都過不了，問題當場現形。第二層是 CI。每次 push 自動跑完整測試與型別檢查，確保「改一個壞兩個」在合併前就被擋下。第三層是覆蓋率監控，不是看總數字，而是看「這次修改的區塊有沒有被測試覆蓋」。如果 AI 改了某個函式，而那個函式沒有對應測試，這就是一個紅色警訊。
版本控制與小步提交
前面提過小步提交，這裡再強調一次它的戰略價值。AI 除錯很容易陷入「補丁疊補丁」的狀態，如果你把所有修改擠在一個巨大的 commit 裡，事後要釐清「哪一行造成哪個問題」幾乎不可能。相反地，每個邏輯修改一個 commit，並且在 commit message 裡寫清楚「這個修改的假設是什麼」，你就擁有了一條可回溯的除錯軌跡。當「壞兩個」發生，你可以用 bisect 快速定位，而不是從頭重來。
讓 AI 寫測試，而不是只讓它改程式
這是很多人的盲點：與其讓 AI 修改產品程式碼，不如先讓它寫測試。你可以說：「這是目前的程式碼與預期行為，請幫我寫一組測試，涵蓋正常路徑、邊界條件與錯誤情境。」有了測試之後，你再讓 AI 去修改程式碼，並且要求它「修改後必須讓所有測試通過」。這時候測試就成了約束條件，AI 的修改空間被限縮，回歸風險大幅下降。
更進一步，你可以讓 AI 先寫「重現 bug 的測試」，確認測試紅了，再讓它修。修完之後測試綠了，你就有了一個永久性的回歸防護。這個「先紅後綠」的流程，是人類 TDD 的精髓，用在 AI 協作上同樣有效，而且能逼 AI 把「根因」想清楚，而不是亂槍打鳥。
六、心法總結：AI 是除錯的放大器，不是除錯的替代品
回到最初的問題：為什麼 AI 改一個壞兩個？因為它是一個「局部推理極強、全域理解極弱、自信程度極高」的工具。它在你看得到的那一小塊程式碼裡，往往能給出漂亮答案；但真實系統的複雜度，藏在它看不到的依賴、慣例與歷史裡。當你把它的局部答案直接當成全域解答，災難就發生了。
所以正確的心態不是「AI 不可靠，別用」，也不是「AI 好神，照抄」，而是把它當成一個「需要你提供地圖、需要你設定護欄、需要你驗收成果」的協作夥伴。它幫你快速產生假設、閱讀陌生程式碼、補齊測試；你負責判斷根因、確認影響範圍、守住系統邊界。它放大你的除錯速度，但方向盤仍然在你手上。
當你建立起「小步修改、測試護欄、上下文補齊、三問審查」這套流程後，你會發現 AI 的除錯價值其實很高。它不再是那個「改一個壞兩個」的豬隊友，而是一個能陪你快速收斂問題、把模糊錯誤變成具體假設的得力助手。差別不在於模型多聰明，而在於你有沒有把它放進對的流程裡。
結語：與其抱怨它會壞兩個，不如設計一個讓它不容易壞的環境
「改一個壞兩個」短期內不會完全消失，因為它是大型語言模型運作原理與軟體系統複雜度之間的結構性落差。但這個落差可以被管理。把 AI 當成一個視野有限但反應極快的初階工程師：你不會讓他直接 push 到 main，你會給他清楚的任務、相關的文件、可驗證的測試，並且 review 他的每一個改動。用同樣的標準對待 AI，你會得到遠比現在更好的結果。
下次當你貼上錯誤訊息之前，不妨多花三分鐘：補上呼叫端、寫清楚限制、先讓它寫個重現測試。這三分鐘，往往就是「改一個壞兩個」與「改一個好一個」之間的距離。工具沒有變，變的是使用工具的方法——而這，才是真正拉開生產力差距的地方。