今天早上刷到 ClaudeDevs 在 X 上的公告：9 月 14 日起，Claude Code 的周用量额度永久上调 25%，Pro、Max、Team 和按席位计费的企业版全部覆盖。第一眼看着是好事，到我看的时候那条帖子已经两百多万阅读了。但我把数字拆开算了一遍，结论是：对我接下来几周的排期来说，这不是涨，是降。这篇踩坑笔记记三件事：25% 是相对哪个基准算的、为什么 9 月 14 日切换之后实际到手的是少约 17%、以及中间这两周多的窗口期我准备怎么用。
关键在于现在手里拿的是临时额度。官方之前把周额度临时上调了 50%，这个临时上调一直有效到 9 月 14 日，然后被「永久上调 25%」替换掉。也就是说，公告里的 25% 不是在今天的额度上往上涨，是在最早那个原始基准上往上涨。拿一个随便的基准数摆一遍就清楚了：
原始周额度 100
临时额度（+50%） 150 ← 现在，持续到 9 月 14 日
永久额度（+25%） 125 ← 9 月 14 日起
125 / 150 ≈ 0.83
所以切换那天过后，周额度相对现在会少大约 17%。这个 17% 不是我算出来的独家发现，官方在补充说明里自己也讲清楚了，只是原帖最显眼的位置放的是「永久上调 25%」。我不觉得这是故意误导，数字都摆在那里，两句都是真话，基准不一样而已，但两百多万阅读里能被记住的，大概率只有那个更大的数字。
坦白一下，这个基准问题我绕了两次才站稳。第一遍读只看到 25%，以为是纯涨；第二遍看到 17% 的说法，又以为是在降，觉得前后矛盾；第三遍把三个数摆在一起才想明白，临时额度本来就有截止日期，50% 和 25% 压根不是同一个起点上的比较。之前记过一篇核对 AI 生成的迁移脚本的笔记，思路其实是同一个：结论先放一边，把数字自己跑一遍，那种「前后矛盾」的感觉自己就消失了。
想明白之后我给自己排了三步，你可以照着这个顺序过一遍：
- 确认自己的计划在不在这次调整范围内。Pro、Max、Team、按席位计费的企业版都覆盖，没有哪一档能躲开这次切换，所以不用花时间找例外。
- 拿自己当周的额度水平乘 1.25 再除以 1.5，得到 9 月 14 日之后的大概位置。不用算得很精确，知道是「比现在少一成半多一点」就够排期用了。
- 把手里的大块任务往前挪。我有一个拖了一阵子的全库重命名重构，本来打算什么时候有空什么时候做，现在决定就这两周做掉——重活放在 150 的窗口里跑 → 同样的活少撞几次额度墙，放到 125 里跑就是另一回事了。
顺手记两个容易踩的坑。第一个坑是排期排反：切换发生在 9 月 14 日，从今天算还有两周多一点，这是接下来额度最高的一段窗口，重活放这里，轻量的探索和读代码放到切换之后再安排。第二个坑是「永久」这个词，它在这类公告里的意思只是「不是临时的」，别延伸读成「以后不会再动」，额度这种东西跟着套餐和整体容量走，我对这个字眼的承诺力度持保留态度。
公告里还提了一句正在做的新功能，说是要让额度用得更值、对用量看得更清、管得更多。这部分我本来想展开聊聊预期，但细节实在太少，等它真的上线、我自己验证过一遍，再单独记一篇，这里先留一个坑。💡 与其等那个功能，不如从这周开始，每周固定一天在笔记里抄一行自己的当周用量，格式不用讲究，一行字就够用。坚持三周你就有自己的基准线了，下次再出这种公告，不用等任何人算给你看，自己乘除一下心里就有数，这条记下来了，下次应该用得上。
划重点：第一，看到公告里的百分比，先问一句「相对哪个基准」，这次的 25% 相对原始额度、17% 相对当前临时额度，两个数都是真的，但你排期该用的是后者；第二，9 月 14 日前的两周多是额度高点，大块任务往前放；第三，没上线的新功能按不存在处理，自己的用量记录才是马上能用的东西。这篇就记到这里，你可以现在打开计算器按一遍 1.25 ÷ 1.5，再把下周的任务清单拖出来重排一下顺序，这个动作几分钟就能做完，免得 9 月中旬那周才发现额度比预想的紧。