用定时任务驯服 AI 的滚动窗口限制

初版：2026-04-13；最近更新：2026-05-12

问题

某些 AI 服务采用滚动窗口限制——比如 5 小时一个窗口，从第一条消息开始计时。问题是这个起点完全取决于你什么时候发第一条消息，不可预测。经常出现的情况是：干活干到一半撞上限制，或者随手问了一句话，不知不觉把窗口浪费了。

窗口从第一条消息触发——这不只是限制，也是可以利用的机制。既然我能决定什么时候发第一条消息，我就能决定窗口什么时候开始。

一天 24 小时，窗口 5 小时，每 6 小时触发一次刚好留 1 小时缓冲。四个时间点：01:00、07:00、13:00、19:00，几乎覆盖全天。

漂移问题：如果我在两个触发点之间主动使用了，窗口会提前，但最多偏移 1 小时。而且不会累积——只要睡觉期间不用，第二天早上 07:00 自动修正回来。

额外收获：07:00 触发但 09:00 才开始工作，中间两小时不消耗额度，等于把 5 小时的额度压缩到 3 小时用，密度更高。

定时任务在每个时间点用最轻量的模型发一次最简请求，等收到应答才算完成。配上即时通讯通知确认成败，加重试和日志。

具体工具不重要——cron、launchd、Task Scheduler、甚至手机闹钟都行。核心是同一个：主动触发一次最低成本的请求来锁定窗口起点。

这个思路不限于某一家服务。任何基于滚动窗口、由用户行为触发的限制系统都适用。规则改不了，但进入规则的时机可以选。

提出用定时任务主动触发滚动窗口起点的思路，并采用 01:00、07:00、13:00、19:00 四个时间点覆盖全天。

原来的 01:00、07:00、13:00、19:00 更像是覆盖全天的方案。但如果默认工作时间是 09:00-18:00，凌晨和深夜的触发点对白天工作的帮助有限，真正能充分用上的工作窗口并不多。

所以新的触发点调整为 05:00、10:00、15:00。这样工作时间会被切成三段：09:00-10:00、10:00-15:00、15:00-18:00。除非高强度使用，第一、三个窗口触限的情况相对较少，可以把更自由的使用安排在这些时段。

这不是绕过限制，周限制和月限制仍然存在。它只是把进入滚动窗口的时间从“覆盖全天”改成“贴近工作节奏”。