为什么我会把 Codex Plus 最后 3–5% 的额度留给最大的工程任务

我在使用 Codex Plus 时观察到的一个很有意思的工作流模式，其实和提示词怎么写关系没那么大，反而更和时机有关。

当我的 5 小时额度或每周额度只剩最后 3–5% 时，我已经不会再把这部分余量花在小请求上了。相反，我会把它用来启动我能发起的最大工程任务，而且通常会同时覆盖多个已经提前准备好的项目。

这些任务一般包括：完整的 TypeScript 迁移、整个仓库范围的 ESLint 清理、覆盖整个代码库的深度 bug 审查，或者大规模重构。这类工作放在平时，往往会让人觉得成本太高，不太会随手发起。

是什么改变了我的工作方式

原因很简单：我不止一次看到，哪怕可见额度看起来已经耗尽，Codex 还是会继续工作。表面上看，整个会话似乎应该结束了，但任务还在往前推进，有时甚至会直接做完。

我并不是把这件事当成产品的确定规则来讲。我只是在描述一种反复出现、而且足够明显到改变我使用习惯的个人体验。自从我注意到这个模式之后，最后那几个百分点就不再像是必须小心保护的剩余额度了。它反而成了我触发最重、最有杠杆价值工作的最佳时机。

以前我会把剩余额度留给更安全、成本更低的请求。现在我把它当成启动高强度工程操作的窗口，比如：

这里的关键是提前准备。只有当项目本身已经准备好执行、任务边界也定义清楚时，这种做法才最有价值。到了那个阶段，如果再把最后的额度用在小事上，反而会让人觉得是在浪费最有价值的时刻。

像 Codex Plus 这样的工具，价值并不只取决于它本身有多强。你怎么安排投入时机，同样会影响最终结果。时间点上的一个小变化，可能就会明显改变同样额度所带来的实际收益。

对我来说，这甚至改变了我对这个产品的心理预期。最后那几个百分点不再像是一轮使用的终点，反而更像是我应该停止犹豫、把最重任务交出去的那个瞬间。

有时候，说实话，我真的会有一种感觉：即使可见额度已经没了，Codex 还是在继续替我工作。我不知道这是不是某种有意设计的边界情况，还是只是某些任务在实际完成时的表现方式。但它已经足够有用，以至于我现在会围绕这个观察来安排自己的工作流。

如果你也在用 Codex Plus 做软件工程，也许值得自己测试一下临近额度结束时的使用方式，而不是默认认为最后那几个百分点一定要保守使用。至少在我的经验里，反过来做反而更有效。

我也很想知道，其他开发者是否注意到了类似的模式，尤其是在做迁移、lint 清理、大范围审查，或者跨多个仓库的大型重构时。