別讓未完成的 Opus 5.5 長任務吃掉預算：先建立可恢復的 Harness
長任務的浪費，往往不是模型「做太久」，而是 run 在中途失去可用進度：下一次只好重新讀脈絡、重做已完成工作、再花一輪成本確認結果。先設好保存、驗證與重用的執行環境，才能把長跑 agent 變成工程流程。
進度要能交接
任務中斷時，下一個 session 應拿到目前狀態、已改動的範圍、未解決問題與下一步，而不是只拿到一個模糊的「繼續」。
完成必須有證據
把可執行的測試、檢查或明確輸出當成 done 的條件。只有模型說「完成了」，無法判斷該停止、重試或升級。
把修正變成下一次的起點
每次長任務留下的命令、檢查與恢復步驟，應沉澱為可重用的 workflow，而不是散在一次性的對話紀錄裡。
最昂貴的不是失敗，而是無法接續的失敗
把「長跑」拆成七個可檢查的層
任務契約：先定義邊界與完成證據
寫清楚目標、不可碰的範圍、輸出位置、驗收命令與不確定時要停下來問什麼。這是所有後續判斷的共同參照。
工作切片：讓每輪有小而可驗證的增量
把任務切成能獨立檢查的里程碑；不要等到數小時後才知道一整段方向錯了。切片不是微管理，而是降低回復點的間距。
狀態帳本：把已知事實寫在模型外
保留目前分支、已讀資料、已做變更、測試結果、阻塞點與待決策項。狀態應由檔案或結構化紀錄承接，不依賴短暫對話記憶。
Checkpoint：在可回退的位置保存成果
每完成一個可驗收切片，就留下清楚的 diff、提交或可定位的工作產物。checkpoint 要能回答：下次從哪裡開始、什麼不能覆蓋。
驗證器：把「看起來對」換成可重跑的檢查
優先使用 build、test、lint、schema check、畫面驗證或明確的人工核准。驗證輸出也要記錄，才能讓下一輪知道是否真的通過。
預算與停止規則：讓重試有上限
定義時間、成本、錯誤次數與升級門檻；遇到缺少前提、外部依賴失敗或連續無進展時，保存現況並停止，而非無限續跑。
恢復手冊：把這次 run 變成下次的起跑線
最後整理最短的 resume 指令：讀哪份狀態、執行哪些驗證、從哪個 checkpoint 接手、需要誰決策。重複出現的模式再升級為 skill 或腳本。
中斷時，不是「再試一次」，而是有秩序地恢復
下次交給 coding agent 前，先補這四句
如何閱讀這則貼文
來源
此頁是繁中工程筆記，將來源貼文的可見內容與明確標示的實作建議分開呈現；不將未取得全文的 X Article 細節當成已驗證事實。