現在許多開發者習慣用 AI 來協助 debug，但在實務上常遇到一種情況：
依照 AI 建議改了兩三輪後，錯誤仍然存在，甚至越改越複雜。
這種狀況其實有幾個常見的盲點，值得特別注意。
1. 先回到「上一個正常版本」
當你已經按照 AI 的方向修了好幾次但問題仍未解決時，最有效的第一步是：
回到上一個正常工作的版本，縮小問題來源。
許多 bug 並不是你正在看的那段程式碼造成的，而可能是：
- 同事剛好修改了某個底層模組
- 某個 shared component 產生 side effect
- Auto Layout 層級重新 layout 時觸發 crash
如果只是盯著眼前的 function 修，反而容易被誤導。
2. AI 沒有看到你的整個專案
AI 通常只能根據你貼出的片段判斷問題，這代表它不知道：
- 你的 view hierarchy 裡是否有其他 constraint 影響 layout
- 某些 model 是否被 extension 修改過
- 父層或子層邏輯是否干擾目前的行為
- 整個專案採用的 concurrency 模型是什麼
因此，AI 可能會朝著完全錯誤的方向修，導致反覆修改卻無法解決。
3. Swift 6 例子：錯誤真正原因常不在你修改的那一行
例如開發者常遇到的錯誤：
passing closure as a 'sending' parameter risks causing data races
許多人（包含 AI）會開始從 function 內部調整，但這類錯誤真正的關鍵通常是：
傳進去的物件沒有實作 Sendable。
也就是說，你不是要改 function，而是要回頭檢查：
- 傳入的 model / struct / class
- 裡面是否有 non-Sendable 成員
- 是否需要標註
@unchecked Sendable
如果 AI 沒看到相關檔案，自然很難找到正確方向。
結語：AI 是工具，不是預言機
AI 很適合用來：
- 解釋概念
- 協助產生測試程式
- 提供重構建議
- 釐清你已懷疑的方向
但在 debug 狀況下，以下三件事更重要：
- 回到上一版，縮小差異範圍。
- 釐清真正問題來源，而不是依 AI 指示一直 patch。
- 一次提供 AI 完整相關檔案，讓它看全貌。
當你把基本功與 AI 工具結合，debug 效率才會真正提升，而不是被建議牽著走。
留言