什麼是 Recovery Template 和 Default Order？
在 AI 程式設計工作流程中，團隊經常需要控制 agent 的回應順序，尤其是在平行呼叫、多步驟回溯或狀態復原場景。 Recovery template 是指當某次生成失敗或需要重新生成時，系統按預先定義的模板只替換受影響部分，而保留其他上下文。 Default order 則是嚴格按照請求發出的順序依次生成回复，即使中途有失敗也會等待或跳過，不改變未受影響部分的順序。
簡單說，recovery template 是“局部重試”，default order 是“整體排隊”。
適用場景：什麼時要候選哪一個？
Recovery Template 適合：程式碼審查和局部修復
當你的 AI agent 負責程式碼審查（code review）時，常常需要修改某一行或某一個函數，而不想影響其他已審核的程式碼。例如，團隊用 AI 檢視 PR，發現某個函數有 bug，你用 recovery template 讓 agent 只重新產生那個函數的建議，而保留其他評論和上下文。這樣既能快速修復，又不會讓 agent 重新輸出所有內容。
實操例子：
- 你用 AI 產生了 5 個針對 PR 的評論。其中第 3 則評論的修復建議有錯誤。
- 用 recovery template：將第 3 條評論替換為正確版本，其他 4 條不動。
- 用 default order：你需要從頭重新執行整個審查，或手動跳過，容易失去工作。
Default Order 適合：一致性要求高的流程
當你的團隊需要嚴格依照固定順序執行任務時，例如自動化 CI/CD 管線、逐步部署腳本，或是多 agent 協同的嚴格流程，default order 能保證結果的可複現性。例如，AI 依序產生測試案例、然後執行、然後報告。如果其中一步失敗，default order 會明確中斷，方便你定位問題，而不會像 recovery template 那樣「靜默」隱藏局部錯誤。
真實場景：某團隊在用 AI 產生全量遷移程式碼時，用了 recovery template 試圖快速重試失敗步驟，結果因為上下文不一致導致遷移後的程式碼出現隱含 bug。後來改用 default order，雖然慢，但每次失敗都能追溯到準確步驟。
最容易踩的坑
迷思 1：盲目追求速度而用 recovery template
有些團隊為了讓 AI 反應更快，所有場景都用 recovery template。但 recovery template 依賴於模板的準確性和上下文的完整性。如果模板定義不嚴謹（例如替換範圍過大或過小），很容易出現「局部正確，整體錯亂」的情況。例如，一個函數簽名改了，但 recovery template 只替換函數體，導致簽名不符。
迷思 2：認為 default order 一定比較穩定
Default order 依序執行，但一旦出現長時間等待或掛起，後續所有請求都會被阻塞。在並行處理大量小任務時，default order 可能變成瓶頸。
迷思 3：忽略上下文一致性
兩種策略都依賴 context。如果你在執行過程中修改了外在狀態（例如資料庫、環境變數），recovery 的範本無法感知這些變化，導致產生結果與預期不符。
具體對比決策表
| 對比維度 | Recovery Template | Default Order |
|---|---|---|
| 核心適用場景 | 局部重試、程式碼審查、修復 | 嚴格順序、管線、可重複性 |
| 執行速度 | 快（只重試局部） | 慢（依序執行） |
| 一致性與可追溯性 | 低（可能隱藏中間錯誤） | 高（每一步可觀察） |
| 實現複雜度 | 高（需要設計模板和補丁策略） | 低（按序編排即可） |
| 失敗影響範圍 | 局部（可單獨修復） | 全域（可能阻塞後續） |
失敗時的備用方案
當 recovery template 因上下文不一致導致錯誤時，回退到 default order 重新執行整個流程。具體做法：記錄請求的初始狀態（包括所有輸入和環境快照），然後以原始順序重新傳送請求，不跳過任何步驟。這能確保結果可重現。
如果 default order 因長時間掛起而失敗，可以採用 逾時 + 重試模板，即對超時的單步設定 recovery template 只重試該步，但依然保持其他步驟順序。
遷移檢查清單
如果團隊正在從 default order 切換到 recovery template（或反之），以下清單能幫你避免常見問題：
- 明確哪些步驟有嚴格的順序依賴（必須用 default order）
- 定義 recovery template 的作用域（替換什麼、保留什麼）
- 確保上下文快照在重試前不變
- 設定日誌記錄每次重試的範本和實際替換內容
- 灰階測試：先用 recovery template 在低風險任務上（如程式碼格式化），再逐步擴大
下一步動作
在理解這兩種策略後，建議先在自己的 AI 工作流程中畫出一個“風險階梯”，把任務按失敗容忍度和順序依賴分成兩類，分別應用不同策略。然後從小範圍試點開始，逐步優化。
暫無評論，快來發表你的看法吧