开发者的 Codex 限额应对工作流程

把限额当成运行约束

Codex 容量暂时不可用时，最昂贵的错误往往不是等待，而是开始一项必须依赖第二条路径才能完成的任务，之后又在限额中断时丢失上下文。提前做一点准备，恢复工作会容易很多。

这套流程不假设公开重置会准时发生。涉及你个人账号的决定，以账号状态页为准；涉及整体动态的判断，再参考公开追踪器。

开始长任务前

检查私有窗口

打开 Codex /status，记录账号页面显示的重置信息。不要把私有令牌、标识符或截图复制到公开渠道。真正有用的是限额类型和时间，不是账号周边的详细资料。

给工作分类

把任务拆成可以独立完成的部分：

• 检查仓库和整理需求；
• 需要多次模型交互的实现；
• 格式化、测试、构建等确定性的本地命令；
• 复审、文档和部署准备。

优先完成确定性工作。它们可以更早暴露真正问题，也能减少之后需要的模型容量。

准备检查点

保留一份简短记录，包括目标、改动文件、已经运行的命令、未决问题和下一步安全操作。这样恢复工作时不会重复探索，也不会脱离原有上下文重新做决定。

限额中断时

先保存工作状态。保存源代码改动，记下最后一次成功命令，并确认这是限额提示、网络错误还是应用错误。不同原因需要不同处理。

然后检查账号状态。如果私有窗口还没有重置，公开事件或预测不能证明你的账号应该已经恢复。如果账号状态已经改变但任务仍然失败，应当调查模型、网络、仓库或产品入口，而不是继续等待全局事件。

可以使用公开追踪器回答一个更窄的背景问题：是否有其他用户报告了大范围变化，证据强度如何？在区分很重要时，打开已确认事件背后的来源。不要把预告信号当成已完成重置。

按可逆性拆分任务

先做低风险、可逆的工作：阅读文件、写测试、起草文案、准备补丁或创建本地分支。计划和输入稳定后，再执行不可逆操作。这条原则即使没有限额问题，也属于良好工程实践。

大型功能应当先定义一个可以单独构建和验证的小切片。带有明确检查点的小切片，比散落在很多无关文件中的半成品更容易恢复。

记录问题，但不要泄露秘密

一份有用的问题记录应包括：

• UTC 时间；
• 使用的产品入口和任务类型；
• 不含敏感信息的完整错误文本；
• 不包含凭据或标识符的账号状态类别；
• 如果查看过，记录对应的公开追踪事件；
• 采用的替代方案和结果。

不要把 API Key、会话 Cookie、密码、私有状态链接或账号导出文件粘贴到追踪器、问题报告或聊天记录中。任何声称可以绕过限额、同时要求这些信息的网站，都在索取超出本流程所需的权限。

预测不确定时怎么安排

可以采用三个层级：

1. 现在继续： 工作很小，或有可靠的本地替代方案。
2. 准备后等待： 任务重要，但可以从检查点开始。
3. 切换路径： 截止时间使等待成本过高。

预测可以帮助选择，但不应成为唯一依赖。70% 的估计仍然意味着选定窗口内有 30% 的可能不会恢复。应当针对代价最高的结果准备，而不是只准备更可能的结果。

容量恢复后复盘

访问恢复后，把账号状态与问题记录对照起来，确认是哪一种限额发生了变化；再运行最小可复现任务，并检查是否留下半成品。如果公开报告和账号体验仍然不同，应当报告范围差异，而不是直接声称追踪器对所有人都错了。

关于公开信息与个人信息的区别，阅读Codex 什么时候重置；关于预测解读，阅读如何理解重置预测。