Devin 的用量按日、按周自动刷新是什么意思？怎么排工作节奏
大部分人看编程 Agent 的定价页，眼睛只盯着两个东西：月费多少、给多少量。看完就关页面了。但真正决定你每天顺不顺手的，往往是页面上一句不起眼的话——额度什么时候恢复。
Devin 的定价页把这句话写出来了：用量额度（usage allowance）按日 / 按周自动刷新，英文原文用的词是 automatically refresh。同一页还写了超额怎么办——可以额外购买用量，这部分按 API pricing 计费；Free 档另外标了一句 Limited model availability（可用模型受限）。
这一句「按日 / 按周刷新」，和你在别处习惯的「每月给你一个总额度池」是两套完全不同的范式。它会直接改写你安排一周工作的方式：哪些活能连着干、哪些活必须摊开、deadline 前该提前几天动手。读完这篇，你应该能给自己排出一个不撞额度的推进节奏，并且知道官方没写明的那几件事该怎么自己测出来。
三种额度周期，差别不在多少，在什么时候回血
市面上的用量限制，剥掉营销话术，机制上就三类。把它们并排放：
| 范式 | 恢复方式 | 能不能攒 | 撞上限之后 | 代价落在哪 |
|---|---|---|---|---|
| 月度总额度池 | 每个账期给一整包，用完为止 | 能——月内任意分配 | 停用 / 降级 / 加购 | 钱（补额度）或整月受限 |
| 按日 / 按周滚动刷新 | 到点自动补满，不看你上次用了多少 | 不能——过期作废 | 等下一次刷新，或加购 | 时间（等回血）为主 |
| 时间窗口滚动 | 在一个滚动窗口内计数，窗口滑过才释放 | 不能 | 只能等窗口滑过去 | 纯时间 |
Devin 属于第二类。定价页原文说的是 usage allowance 按日 / 按周自动刷新，所以它既不是「月初发一大包你自己省着花」，也不是纯粹的等窗口。
第一类的代表逻辑是「先给你一包」——包用完了，要么加钱补，要么这个账期就这样了。第三类的代表逻辑是「算你最近一段时间用了多少」，站内写过 Claude Code 的额度限制 和 周层面的限制，那种情况下你撞上之后没有任何加速手段，只能盯着表等。还有一类混合玩法是降速而不停用，比如站内讲过的 Cursor 快速请求用完之后转慢速，代价从「不能用」变成「用得慢」。
三类里，按日刷新是最容易被误读的一种。很多人把它当成「月额度除以三十天」，然后开始算「我今天没用完，明天是不是能多用点」。不能。这正是下一节要说的事。
省不下来，但也栽不狠
「按日刷新」这四个字里藏着一对互为代价的性质，理解了这一对，你就理解了这个范式的全部。
第一个性质：不能攒。 你没法执行「这个月前三周省着用、最后一周冲刺」这种策略。月度额度池允许你这么做——额度是一个池子，你什么时候舀是你的自由，只要总量够。按日刷新不是池子，是水龙头：今天流出来的没接住，就流走了，不会在明天的桶里多出来。所以「我这周基本没碰 Agent，攒了一批量下周赶工」——这个假设在按日刷新下是空的。你下周还是每天那么多。
举个具体的：你手上有个活，粗看要连续高强度跑三四天的 Agent 才能推完，比如把一个后端服务的鉴权层从会话改成令牌。你想的是「我这周先做别的，下周一到周三三天集中干完」。在月额度池下这个安排完全成立，因为你确实省下了前面几天的量。在按日刷新下它不成立——下周一你能用的，和你这周有没有省着用毫无关系。
第二个性质：也不会栽狠。 反过来看，这个机制对犯错的容忍度反而更高。月额度池最难受的场景是月中一次失手：你让 Agent 去啃一个大范围重构，它自己拆成搜索、通读、生成、逐文件改、跑测试、再自检十几步，一路烧下去，等你回过神，这个月剩下的日子都得省着过。按日刷新不会这样。今天用超了，明天到点自动补满，最多难受一天。
这两个性质叠起来，结论很清楚：按日刷新惩罚「集中爆发」，奖励「稳定推进」。 你不是被扣了额度，你是被换了一种时间形状——同样的总量，被切成了一天一份，强制摊平。
顺带算一笔能复核的账，感受一下差别有多大。按一个月 30 天算：月度额度池，整个月你只做一次分配决策（怎么把这包花掉）；按日刷新，一个月里有 30 次独立的重置点；按周刷新，30 ÷ 7 ≈ 4.3 次重置。同样一个月，前者你有一次全局调度权，后者你有 30 次局部止损点、零次全局调度权。这就是为什么同样的总量，用起来的手感能差出这么多。
据此排你的一周
把上面两条性质翻译成可执行的排期，是三条。
一、大任务拆成多天推进，别指望集中一天猛干。 这不是「效率建议」，是机制逼出来的。把「重构订单模块」这种任务切成：第一天只让 Agent 通读现有实现并产出改动清单；第二天改数据层；第三天改服务层；第四天补测试和自检。每天的目标独立、可交付、可回滚。这样安排还有个额外好处——每天收工时你手上都有一个能编译能跑的状态，而不是一个改到一半的大坑。
反过来说，如果你的任务实在切不动（比如一次跨文件的大范围重命名，中间态根本编译不过），那就要提前把它排在你当天额度最完整的时候动手，并且事先把改动范围收窄。给 Agent 的话别说「把这个电商项目的订单模块重构一下」，说「只改 order/service.ts 里的 createOrder，别动支付逻辑」。范围写死，步数就收敛，撞上限的概率大幅下降。
二、deadline 前提前几天开始，不要指望最后一晚通宵。 这条是按日刷新最反直觉的地方。在很多别的资源约束下，「最后一晚拼一把」是有效策略——你可以透支睡眠换产出。按日刷新下透支不了：你的额度不认你今晚多努力，它只认今天是不是新的一天。周五交付的东西，周四晚上才开始，你能动用的就只有周四那一份 + 周五那一份。同样的活如果周一开始，你能动用五份。总量差了两倍多，而你并没有多花一分钱。
一个粗糙但好用的排法：估算这个活大概需要几个「Agent 密集日」，然后在这个数字上加两天当缓冲，从 deadline 往前倒推开工日。加的这两天不是给意外留的，是给「第一天方向跑偏了要重来」留的——Agent 干活跑偏是常态，而重来一遍要花的量常常不比第一遍少。
三、留意日额度和周额度谁先到顶。 Devin 定价页写的是按日 / 按周刷新，两个周期都提到了。这意味着有可能存在两层约束同时生效——日的管你今天能干多少，周的管你这一周合计能干多少。如果确实是两层叠加，那就会出现一种典型情况：周一到周三你都没到日上限，感觉一切正常，周四忽然被拦下来，因为撞的是周额度不是日额度。
所以排期时别只盯着「今天还剩多少」。如果你连着三四天高强度用，第四五天就要开始留心是不是接近周层面的上限了，把那几天的活换成不吃额度的部分——写文档、理需求、人工 review Agent 前几天的产出、跑测试。这些活本来也该有人做，正好填进去。
官方没写明的，别猜，自己测
到这里必须把边界说清楚，因为下面这几件事，Devin 定价页都没有写：
- 具体几点刷新。是按 UTC 零点、按你账号所在时区的零点、还是按你首次订阅那一刻起算的滚动 24 小时——页面没有交代。
- 每档刷新多少。Free、Pro、Max、Teams、Enterprise 各档的额度数量，定价页一律未写明数量（Free 档另外标了 Limited model availability）。所以本文不会给你任何「Pro 档每天多少」的数字——不是我省略了，是它压根没公布。
- 日额度和周额度的确切关系。是周额度 = 日额度 × 7，还是两者独立设定、周额度更松或更紧，页面没说。上一节我用了「如果确实是两层叠加」这样的假设句式，就是因为这一层没有可靠依据。
这些一律以官方定价页与你自己的控制台为准。我不给推测值，猜错了比不说更糟——你会照着一个假数字排期，然后在最不该断的那天断掉。
好消息是，刷新点这件事你自己观察两天就能摸清楚，成本极低：
- 今天找个正常的工作时段，正常用，直到你在控制台里能看到剩余量明显下降。记下这个数和当时的准确时间。
- 接下来别再用了。每隔一两小时回来看一眼那个数字，记下每次查看的时间点。
- 数字从「你昨天用剩的」跳回「满」的那一瞬间，落在哪两次查看之间，刷新点就在那个区间里。第二天再重复一次，区间就能收窄到一小时内。
- 想确认周周期，就连续记七天以上的每日起点值。如果某一天的起点明显低于前几天，说明周层面的约束开始咬了；如果每天起点都一样，那大概率日额度是独立的。
两天的观察能换来一个你自己验证过的、比任何二手说法都可靠的排期基准。而且这个方法不依赖厂商公布任何数字——你测的是行为，不是文档。
顺便说一句超额那条路：定价页写了可以额外购买用量，这部分按 API pricing 计费。也就是说 Devin 给你留了一个「用钱换时间」的出口——撞了上限不是只能等。但这个出口的实际单价取决于 API pricing 那张表，定价页在这里只给了指向、没给数字，所以能不能划算得算你自己那一版账。机制上要记住的是：你的代价可以落在时间上（等刷新，免费但慢），也可以落在钱上（买额外用量，快但要花钱），选哪条取决于那天你缺的是哪一样。
各档的价格结构，顺带一算
刷新周期讲完，把定价页上明确写了的价格结构也列一下，排期时选档会用到：
| 档位 | 价格 | 额度数量 |
|---|---|---|
| Free | $0/月 | 页面未写明；标注 Limited model availability |
| Pro | $20/月 | 页面未写明 |
| Max | $200/月 | 页面未写明 |
| Teams | $80/月 + $40/月/座位 | 页面未写明 |
| Enterprise | 需洽谈 | 页面未写明 |
一个能复核的算术：Pro 到 Max 是 $20 → $200，价格正好 10 倍。但因为两档的额度数量页面都没写，所以不能推出「量也是 10 倍」——这是很多人会顺手做的推断，而它没有依据。
Teams 的结构更值得算一下，因为它是「$80 固定 + $40 每座位」的两段式。5 个座位：$80 + $40 × 5 = $280/月，人均 $280 ÷ 5 = $56。10 个座位：$80 + $400 = $480/月，人均 $48。20 个座位：$80 + $800 = $880/月，人均 $44。那笔 $80 的固定费摊到人头上，5 人时每人分摊 $16，20 人时每人分摊 $4——团队越大，固定部分越不显眼，人均越贴近 $40。小团队上 Teams 之前值得先算这一笔，看那 $80 的门槛费换来的东西值不值。
最后
「按日 / 按周自动刷新」听着像个细节，实际是个范式选择，它决定了你和这个工具的相处方式。
记住三件事就够了。第一，省不下来——别做「前面攒着后面冲刺」的计划，那个池子不存在。第二，也栽不狠——某天用超了不是灾难，睡一觉就回来了，所以该试的重构可以放手试。第三，提前开工比熬夜有用——同样的活，周一开始能动用五天的量，周四开始只能动用两天的，这个差距没法用努力补。
至于每天到底多少、几点回血、周额度怎么算——定价页没写，我也不猜。花两天自己观察一次刷新点，你拿到的答案比任何转述都准。