換個視角：這次寫協作過程本身

Day 21 講了容錯模式的設計。今天倒帶重放，講這個模式當初是怎麼跟 Claude Code 一起落地的——因為那次協作過程本身，比結果更值得記錄。

第一步：我用業務語言描述需求

我給的初始指令大意是：「所有呼叫 LLM 生成內容的地方要加上容錯：失敗時不能中斷排程流程，要退回純數據的基本版內容。」

注意這段話的抽象層級——我講的是業務規則（不能中斷、要有退路），不是實作指令（在哪個檔案加 try/except）。這是跟 agent 協作幾個月摸出來的心得：把「要什麼」講清楚，把「怎麼做」留給它先提案。你描述得越接近實作，就越容易把自己還沒想清楚的實作偏見一起塞給它。

第二步：它反問了一個我沒想到的問題

Claude Code 讀完專案裡現有的幾處 LLM 呼叫後，回了一個問題，大意是：

「失敗」的定義包含「API 成功回應、但內容不符合預期格式」的情況嗎？現有程式碼裡有一處對回應做了格式解析，如果解析失敗，目前的行為是往外拋例外。

這一問直接命中了我沒想清楚的邊界。我原本腦中的「失敗」只有逾時跟錯誤碼——「成功地回傳垃圾」這個失敗模式（後來在 Day 21 裡寫的 _looks_valid 檢查）是被這個反問逼出來的。而它能問出這個問題，恰恰因為它動手前真的去讀了現有程式碼，發現了一處與我的描述矛盾的既有行為。

這是我認為 AI 協作最被低估的價值：它是一面會找碴的鏡子。 你給的規格照到現有程式碼上，不一致的地方它會指出來——而規格跟現實的不一致處，正是 bug 的出生地。

第三步：定案模式，然後機械化地掃全場

邊界定清楚後（失敗 = 逾時 ∪ 錯誤碼 ∪ 格式不符；一律回 fallback 字串不拋例外），它做了三件事：

1. 把這個模式抽成統一的包裝函式，命名、參數形狀、日誌格式跟專案慣例對齊
2. 找出專案裡所有呼叫 LLM 的位置——包括兩處我自己都忘記存在的舊功能——逐一改接包裝函式
3. 對每一處補上 fallback 路徑的測試（用 Day 23 會講的紅燈先行流程）

第 2 步值得特別停留。「把一個模式套用到所有符合條件的地方」這件事，人類工程師的失誤率被大幅低估了——大範圍重構漏改一兩處是常態，而漏掉的那處不會報錯，它只是安靜地保持著舊行為，直到某天 AI 掛掉時那一處如舊地把例外拋穿整條排程。機械化的完整性正是 agent 相對於人類的結構性優勢：它不疲勞、不「想說這處應該沒差」、不因為改到第十五處而開始複製貼上。

這次協作的分工總結

回看整個過程,分工的形狀很清楚：

這張表幾乎就是我對「跟 AI agent 協作」的完整方法論——後面幾天（測試紀律、記憶系統、多 agent、自動巡檢）都是這張表在不同場景的展開。