假設、日誌和二分查詢

一旦 AI 提出了一個原因，不要直接接受。用低成本的方式測試它。 最便宜的測試通常是一行日誌。

讓 AI 新增臨時日誌：

"在我們改任何東西之前，新增一個 console.log（或 print），在第 14 行之前顯示 user 的值，這樣我們就能看到它是不是真的為 undefined。"

執行它，把輸出貼上回來。現在你擁有的是證據，而不是一個理論。也許 user 確實是 undefined——這就確認了假設。也許它沒問題，真正的元兇在上一層。無論哪種情況，你都向前推進了。調查時要慷慨地打日誌：變數的值，以及一個標籤，說明它是哪個變數、日誌在哪裡。一個打印出 undefined 的光禿禿的 console.log(user)，遠不如 console.log("user at validate.js:14 =", user) 有用。還有，bug 修好後記得把臨時日誌拔出來——遺留的除錯噪音本身就是一小攤爛攤子。

當 bug 藏在一個很長的流程中的某處，而你說不清在哪裡時，使用二分查詢。把可疑區域對半切分：在中點新增一條日誌。

核心思路：每次檢查都丟掉剩下一半，所以一個龐大的搜尋空間會迅速塌縮。下面這個 bug 藏在第 1 步和第 8 步之間的某處——三次檢查就把它逼了出來：

   步驟:  1  2  3  4  5  6  7  8      bug 藏在這裡某處
          ░░░░░░░░░░░░░░░░░░░░░░

   檢查 1 ── 在 4 打日誌 ── OK ──▶  bug 在 4 之後，棄掉 1–4
                                  ░░░░░░░░░░░  (剩 5 6 7 8)

   檢查 2 ── 在 6 打日誌 ── BAD ─▶  bug 在 6 處/之前，棄掉 7–8
                                  ░░░░░  (剩 5 6)

   檢查 3 ── 在 5 打日誌 ── OK ──▶  bug 在第 6 步   ✔ 找到

   8 步 → 3 次檢查。  1000 步 → 約 10 次檢查。

那裡的值看起來正確嗎？那麼 bug 在它之後——搜尋那一半。那裡的值已經看起來不對了嗎？那麼 bug 在它之前——搜尋那一半。每一步都把搜尋空間減半，所以即使是一千行的路徑，也能在大約十次檢查內縮小範圍。明確地告訴 AI："幫我二分排查——我應該在哪個中點打日誌？" 同樣的技巧不僅對程式碼有效，對歷史也有效：如果某個功能上週還能用、今天壞了，就對你的提交做二分查詢，找到引入這個 bug 的那個確切改動。