28 天每日改进或全额重置：一份能照抄的 AI 编码配额运营手册

一个带五人小团队做内部工具的负责人，上个月的账很难看：Codex 的额度在中旬就见底，团队被迫在「继续付费加速」和「等下周重置」之间反复横跳。他在群里发了句牢骚——「现在的额度规则比写代码难懂」。这其实不是一个团队的困境，过去一个月里，Codex 和 ChatGPT Work 的用户群体里这类抱怨几乎是主旋律。

10 月 5 日，OpenAI 负责 Codex 与 ChatGPT Work 的 Tibo Sottiaux 在社交平台上公开承诺：接下来的 28 天里，每一天要么交付一项对多数 Codex / Work 用户明确有价值的改进，要么做一次全额重置。

这条帖子几小时内过了百万浏览，评论区分成差不多两半——一半叫好，一半嘲讽。但对真正靠这些工具吃饭的人来说，争论它是不是公关动作没有意义；有意义的是：这是一个有截止日期的公开节奏，你可以围绕它安排工作，也应该知道它的边界在哪。

下面把它拆成可操作的部分：承诺的准确边界、背景成因、配额机制的真实含义、以及一套能照抄的应对方法。

先把原文的三个限定词读清楚

这条承诺里有三个词决定了它的实际约束力：

• 「明确改进」：门槛不是「发布了点东西」，而是发布了东西且有意义。一个只有极客会用到的命令行开关不算数。
• 「对多数 Codex / Work 用户」：受益人要覆盖中位数用户，而不是长尾。
• 「或是一次全额重置」：重置是兜底方案，不是赠品。这个措辞本身就预设了「有些天拿不出合格改进」这个事实。

同时必须诚实指出一个结构性问题：「明确改进」这个标准没有被量化，没有指标、没有方法、也没有可被证伪的条件。作为管理者你会立刻意识到——从设计上讲，这条承诺几乎不可能被判失败。任何一天都可以宣称成功。所以不要把它当成 SLA，它是一个方向性的表态。

另一个被误传的点：网上有人把它总结成「28 天 28 次重置」。不是。原文是二选一，不是叠加。

为什么偏偏是 10 月 5 日：前面那一个月发生了什么

这条承诺不是凭空出现的，它是一整月压力的出口。把时间线排一下就很清楚：

• 9 月 25 至 26 日：Codex 与 Work 出现服务中断，随后对付费账号做了一次额度重置。
• 9 月下旬：GPT-6 Astra 质量问题复盘，又一次重置。
• 9 月 29 日（DevDay）：发布常驻智能体 Dots，同时推出 Pro 500 与 Ultrafast 档位，Pro 200 以更小的额度结构重新开放。
• 10 月 1 至 3 日：GPT-6.1 Sol 引发巨大的负载尖峰，随后宣布对全部付费 ChatGPT 账号做全球重置。
• 10 月 3 日：Claude Opus 5.5 登顶 Epoch Capabilities Index，领先 GPT-6 Astra 0.84 分。差距不大，但这个排名很好写标题。

把这串事件连起来读，是一个反复用重置来还信任债的团队。这次的 28 天承诺，本质上是把这个习惯写成了制度——顺便也变成了对外承诺。

前一天，同一位负责人还列了团队在这个周期内的四个方向：产品简化、同样的额度给到更多有效产出（即效率）、突破性功能、以及新模型。加上一句「有时候得超前投入，但反馈已经很清楚，你们想要的是更简单」。

最关键的一条机制：重置补的是余额，不是上限

这句必须单独讲，因为绝大多数人理解错了。

一次重置的作用是把剩余额度刷回去，而不是把额度上限提高。换句话说，如果你本周的上限是 X，用掉了 0.7X，重置之后你回到 X——但你下周的上限还是 X。

由此得出一个反直觉但很重要的操作结论：不要为了等重置而攒额度。 攒着不用是纯亏损，因为重置是覆盖而不是累加。正确的做法是把额度当一个会定期刷新的水池，想用就用，重置来了就按满水池重新排任务。

具体到排班：把最重的任务（大规模重构、全仓库迁移、长时间智能体跑批）安排在余额最充沛的时候，通常是重置刚发生之后；把日常的小改动和 PR 评审穿插在其余时间。同时每天早上去「设置—用量」里看一眼剩余额度和刷新时间戳，把这个动作变成团队的晨会第一件事——很多团队的额度浪费，纯粹是因为没有人盯着。

10 月 30 日那一刀，并没有被取消

这是最容易被忽略、也最影响采购决策的一条信息。

在本次 28 天承诺窗口之内，10 月 30 日仍然计划执行 Pro 档 Codex / ChatGPT Work 额度的下调：从 Plus 档的 20 倍降到 10 倍。 公告里没有任何内容表明这一刀会被取消。

这个信息该怎么用？很直接：做订阅决策时按「当前已确认的额度档位」算，不要按「这个月可能会有改进」算。 如果你是冲着 20 倍额度买的 Pro，那么在 10 月 30 日之后你的实际可用量会腰斩。这时候要算清楚三笔账：

• 腰斩之后的实际月度任务量能不能覆盖团队需求？
• 差出来的部分需要再用哪条路径补（第二档位？另一个工具？还是降预期）？
• 新档位的边际性价比是否还高于替代方案？

这三笔账应该在 10 月 30 日之前算完，而不是当天发现不够用再临时加钱。

第一天交付了什么：默认提速约 50%

承诺发出的第一天，兑现内容是：订阅用户的 GPT-6 Astra 与 GPT-6.1 Sol 默认提速约 50%，部分使用「Sign in with ChatGPT」的第三方产品也一并受益。

这个兑现本身值得一提的地方在于它选的方向。它没有给一个新功能，而是动了「每次请求要花多少时间」这件事。对天天用智能体跑任务的团队来说，等待时间是最大的隐性成本——一个五分钟的阻塞式等待会让人下意识不去启动它，长期下来实际使用率远低于额度利用率。

如果你是管理者，这个值钱的不是那 50% 本身，而在于提速之后，你值得把那套「因为慢所以不做」的任务排队模型重排一遍。 提速意味着同样额度的「时间成本」下降，那些因为「太慢懒得跑」而被搁置的任务现在值得重排一遍。做一次盘点：过去一个月里，有哪些任务是因为耗时长被主动放弃的？现在可以重新纳入。

一套能照抄的双 harness 运营法

关于要不要因为这条承诺就从 Codex 换到别处，或者反过来，答案都一样：不要因为一条帖子整体切换。

正确的做法是让两套 harness 同时处于可用状态，然后用固定数据集量化对比。具体到执行：

建立一组固定的对照任务。 选十到十五个能代表你团队真实工作的任务，覆盖：一个新模块的从零搭建、一次跨文件的重构、一个难查的 bug 定位、一轮测试补全。任务要冻结，不要每次换。

定义四个可比的口径。 完成任务数（在给定额度内跑完几个）、首次产出质量（需要几轮人工纠正）、单任务耗时、卡死率（需要人工介入或直接放弃的比例）。第三和第四项往往比第一项更能反映真实体验。

每周跑一次，记录成表。 频率不要更高，否则你会淹没在噪声里；也不要更低，否则抓不到版本变化。

配额分配按任务类型切，不按人头切。 探索性任务（不知道能不能成）走便宜的那条；确定性任务（已验证的模式、需要稳定产出）走配额充足的那条。这样即便某一侧临时收紧，也不会全面停摆。

这套方法的好处是：无论接下来 28 天里哪一侧发布什么，你都有第三方数据和结果的差异所呈现的真实对比，而不是在社区里看别人吵架。

现在就做的五件事

第一，今天就去设一个每日额度巡查。 「设置—用量」页面，每天早上花十秒看剩余额度和下一次刷新时间。把它写进团队晨会清单。绝大多数额度事故是「不知道什么时候会用完」，不是「不够用」。

第二，取消所有「攒额度」的行为准则。 群里如果还有人跟团队说「这周省点用」，立刻纠正。重置是覆盖式的，攒着等于白扔。

第三，在 10 月 30 日之前把 Pro 档降级的账算完。 如果你或团队订阅受影响，做上面那三笔账，写下来，定好 11 月的实际配额方案。别等到那天发现额度砍半再临时决策。

第四，把重任务排在重置之后。 关注官方渠道的重置公告，把最吃额度的批处理任务顺着这个节奏排。

第五，建立你自己的评测集。 这是五件事里最花时间、但唯一有长期复利的。十几个冻结任务加上四个量化口径，足以让你在未来任何一次模型更新、任何一次产品调整中，都有一套自己的判断依据，而不是跟着别人的结论走。

最后说一句关于这类承诺的态度：它不是合同，但它是节奏。 你不能拿它去索赔，但你可以用它规划未来四周的工作密度——而且如果你把每天的产出记录下来，28 天之后你会得到一份属于自己的、比任何评测榜单都更贴近实际的评测报告。这份报告，才是这条承诺真正给你的东西。