卡住 15 分鐘，就對付一隻鴨子

上週四晚上，一個爬蟲任務卡在第三步，報錯說檔案不存在。我盯著程式碼看了二十分鐘，換了個變數名稱、重啟、又改路徑，全沒用。最後我打開一個空白文件，逼自己把問題寫成一句話：「任務從 /data/inbox 讀取檔案，而這個檔案昨天被批次處理任務移走了，沒人記錄。」寫完那一刻就發現了——不是程式碼有 bug，是我上週改了路徑沒同步設定。

這就是橡皮鴨除錯法（rubber duck debugging）。名字來自程式設計師的傳說：在桌上放一隻橡皮鴨，卡住時在它面前把問題從頭講一遍。其實不需要鴨子，一段語音、一塊白板、一個空白文件都行。

**為什麼有用**

卡住大多不是「問題難」，而是你在腦子裡翻來覆去，記憶裡的「我以為」和螢幕上的「實際」對不上。講出來這件事強迫你做兩件事：

1. 排序。把現象、動作、預期按順序排開，bug 就藏在順序的斷點裡。

2. 驗證假設。你說「檔案應該在」的時候，手會不自覺去 `ls` 一下——八成這時候就發現不在了。

**什麼時候用**

- 同一個問題盯了 15 分鐘沒有任何進展。15 分鐘是閾值，不到 15 分鐘繼續想，別急著走流程。

- 報錯很模糊，「something went wrong」、「invalid value」，連從哪下手都不知道。

- 你已經改了很多東西，但報錯紋絲不動——這時候最該懷疑的是因果判斷錯了，而不是再改一次。

- 你隱約覺得「我想到了一个」，但說出來又說不清。這是橡皮鴨的上場信號。

**什麼時候別用**

- 還沒收集證據。日誌沒看、任務沒跑，就開始對著鴨子講，那不是除錯，是自己跟自己開會。先拿證據，再講故事。

- 一行就能修的問題。查詢語法錯、變數名稱打錯，直接改，別走流程。儀式救不了 typo。

- 依賴別人的問題。確認是上游壞了，直接找那個人。鴨子不能替你溝通。

**五分鐘的 checklist**

1. 一句話講現象：輸入 → 預期輸出 → 實際輸出。說不清一句話，說明你卡住的地方不是程式碼，是理解。

2. 列出已嘗試項，每項帶結果。「試了七八次」不是資訊，「改了 A、報錯從 X 變成 Y」才是。

3. 寫出最小能重現的輸入，把別的干擾全砍掉。

4. 找出一個反直覺的線索：報錯最醒目的那一行常常是果不是因，真正的根因在時間線上更早——也就是「在 A 之前發生了什麼」。問自己這句話，往往比繼續讀報錯有用。

5. 設一個 10 分鐘的結界：講完還沒有頭緒，停。把現狀和下一步寫進文件，換任務，明天早上帶著上午的腦子回來。

**三個坑**

- 鴨子沒有格式就行：隨便嘟囔兩聲和「一句話 + 最小重現」的要求是兩回事，沒格式的版本基本等於沒做。我強迫自己寫成文件，就是這個原因。

- 別把「講通了」當成「修好了」。講完之後感覺「應該就是這樣」，仍然要用最小重現驗證一次，否則不過是一次幸運的猜測。

- 別為了鴨子開全員會。這是單人技能，文件比人便宜；真需要第二雙眼睛時再喊人，把文件丟過去，三個人十分鐘能看完。

橡皮鴨的價值不在鴨子，在「被強制完整說一遍」這件事。它是免費的診斷工具：不報錯、不背鍋、不用請人吃飯。卡住的時候，先去餵鴨子。