開發者的 Codex 限額應對工作流程

把限額當成執行約束

Codex 容量暫時不可用時，最昂貴的錯誤往往不是等待，而是開始一項必須依賴第二條路徑才能完成的任務，之後又在限額中斷時丟失上下文。提前做一點準備，恢復工作會容易很多。

這套流程不假設公開重設會準時發生。涉及你個人帳號的決定，以帳號狀態頁為準；涉及整體動態的判斷，再參考公開追蹤器。

開始長任務前

檢查私有視窗

開啟登入後的 Codex 使用情況與限額頁面，記錄帳號顯示的重設資訊。不要把私有令牌、識別符號或截圖複製到公開渠道。真正有用的是限額型別和時間，不是帳號周邊的詳細資料。

給工作分類

把任務拆成可以獨立完成的部分：

• 檢查倉庫和整理需求；
• 需要多次模型互動的實現；
• 格式化、測試、構建等確定性的本地命令；
• 複審、文件和部署準備。

優先完成確定性工作。它們可以更早暴露真正問題，也能減少之後需要的模型容量。

準備檢查點

保留一份簡短記錄，包括目標、改動檔案、已經執行的命令、未決問題和下一步安全操作。這樣恢復工作時不會重複探索，也不會脫離原有上下文重新做決定。

限額中斷時

先儲存工作狀態。儲存原始碼改動，記下最後一次成功命令，並確認這是限額提示、網路錯誤還是應用錯誤。不同原因需要不同處理。

然後檢查帳號狀態。如果私有視窗還沒有重設，公開事件或預測不能證明你的帳號應該已經恢復。如果帳號狀態已經改變但任務仍然失敗，應當調查模型、網路、倉庫或產品入口，而不是繼續等待全域事件。

可以使用公開追蹤器回答一個更窄的背景問題：是否有其他使用者報告了大範圍變化，證據強度如何？在區分很重要時，開啟已確認事件背後的來源。不要把預告訊號當成已完成重設。

按可逆性拆分任務

先做低風險、可逆的工作：閱讀檔案、寫測試、起草文案、準備補丁或建立本地分支。計劃和輸入穩定後，再執行不可逆操作。這條原則即使沒有限額問題，也屬於良好工程實踐。

大型功能應當先定義一個可以單獨構建和驗證的小切片。帶有明確檢查點的小切片，比散落在很多無關檔案中的半成品更容易恢復。

記錄問題，但不要洩露秘密

一份有用的問題記錄應包括：

• UTC 時間；
• 使用的產品入口和任務型別；
• 不含敏感資訊的完整錯誤文字；
• 不包含憑據或識別符號的帳號狀態類別；
• 如果檢視過，記錄對應的公開追蹤事件；
• 採用的替代方案和結果。

不要把 API Key、會話 Cookie、密碼、私有狀態連結或帳號匯出檔案貼上到追蹤器、問題報告或聊天記錄中。任何聲稱可以繞過限額、同時要求這些資訊的網站，都在索取超出本流程所需的權限。

預測不確定時怎麼安排

可以採用三個層級：

1. 現在繼續： 工作很小，或有可靠的本地替代方案。
2. 準備後等待： 任務重要，但可以從檢查點開始。
3. 切換路徑： 截止時間使等待成本過高。

預測可以幫助選擇，但不應成為唯一依賴。70% 的估計仍然意味著選定視窗內有 30% 的可能不會恢復。應當針對代價最高的結果準備，而不是隻準備更可能的結果。

容量恢復後覆盤

訪問恢復後，把帳號狀態與問題記錄對照起來，確認是哪一種限額髮生了變化；再執行最小可復現任務，並檢查是否留下半成品。如果公開報告和帳號體驗仍然不同，應當報告範圍差異，而不是直接聲稱追蹤器對所有人都錯了。

關於公開資訊與個人資訊的區別，閱讀Codex 什麼時候重設；關於預測解讀，閱讀如何理解重設預測。