#WorkBuddy# 定时任务排期实战：把每日自动化搬进夜间免费额度

这是一次完整实操记录。我用一个晚上把 6 个定时任务从付费时段搬进 23:00–08:00 的免费额度，任务数量不变、功能不减。文中的命令、报错、时间戳都是本机真实执行结果，不是事后补的。

先看清楚钱花在哪

在动任何一条排期之前，我做的第一件事是把所有定时任务的触发时间抄出来，标上是否落在免费时段。

我账号上挂着二十来条自动化。抄完的结果是：一条都不在免费时段。晨报 09:00、素材准备 09:00、百家号写稿 08:20、引流 10:00 / 12:30 / 20:00、百家号发布 19:38、晚间总结 21:07、访问量巡检 21:37。

这解释了一个困惑我很久的问题：为什么我明明没怎么聊天，积分还是掉得很快。耗积分的主力不是对话，是那些每天定时跑、每次都要联网搜索 + 读写文件 + 写几千字报告的任务。

所以排期目标很明确：不减任务，只改时间。

先分类，判断哪些能挪

这是最关键的一步。我一开始的想法是「能挪的全挪」，幸好没这么干。

判断标准只有一条：纯本地的写作和计算可以挪，平台交互和发布类不能挪。

省积分只对纯本地的写作和计算成立。如果把发帖和引流也挪到凌晨，省下的那点积分远不够赔上流量和风控风险。

画依赖链，这步能救你一个隐蔽 Bug

分类之后别急着改时间，先把任务之间的依赖关系画出来。我这次差点栽在这。

我的运营晨报里有一项「发布前置体检」，会检查当天的画作素材有没有到位：

cd D:\workbuddyarea\20260426213309
# 今天素材到位了吗
ls D:/workbuddyarea/material/publish/$(date +%Y%m%d)/
# 今天有没有人工定稿
ls "每日互动评论/文案定稿_$(date +%Y%m%d).json"
# 现有 publish_task.json 能否过闸门
python ai_guard.py publish_task.json

而负责投放素材的任务，原本也在 09:00。

如果我只是把晨报挪到 06:30、素材任务留在 09:00，会发生什么？每天 06:30 检查素材的时候，素材要到 09:00 才投放，体检天天亮红灯。而且这是隐蔽错误——报告照常生成、格式正常，只是结论一直是错的，没人会发现。

正确做法是按依赖链重排，保持先后顺序：素材准备 06:00，运营晨报 06:40，然后 10:00 发帖。两条都在免费时段，也都赶在发帖之前，依赖不破。

改时间之前，先问每个任务一句：它读什么、谁写那个东西。

改排期，rrule 有三个坑

我用的是 WorkBuddy 自带的自动化（recurring），改排期就是改 rrule。这里三个坑，我全踩了一遍。

踩过的 rrule 坑，均为真实报错

坑 1：FREQ=DAILY 的 BYHOUR 只接受单个整数

想把一条任务排在 9 点、14 点、20 点，直觉写法是多值：

FREQ=DAILY;BYHOUR=9,14,20     # 直接报错

报错信息：

invalid recurring rrule: BYHOUR must be an integer between 0 and 23

结论：一个时间点等于一条自动化。要三个时间就建三条，别想着压缩。

坑 2：别用 FREQ=HOURLY 加 BYHOUR 列表凑多档

FREQ=HOURLY;INTERVAL=1;BYHOUR=9,10,11

这种写法能创建成功，极具迷惑性。但 BYHOUR 列表不生效，实际会每小时触发一次。等于给自己加了个每小时烧一次积分的任务——我差点就这么干了，还好创建完去看了一眼 nextRunAt。

坑 3：创建成功不等于排期正确，必须核对 nextRunAt

创建接口会返回一个毫秒级时间戳 nextRunAt。每次都要换算成自然时间核对，WEEKLY 类型还要确认落在正确的星期几：

python -c "import datetime;print(datetime.datetime.fromtimestamp(1791499200000/1000))"
# 2026-10-09 06:40:00

我这次核对的结果：

2026-10-09 06:00 | Fri | 素材准备
2026-10-09 06:40 | Fri | 运营晨报
2026-10-09 07:30 | Fri | 百家号巡检
2026-10-09 08:00 | Fri | 切 Hy3（付费时段提醒）
2026-10-09 23:00 | Fri | 切 Hy4 preview（免费时段提醒）
2026-10-09 23:20 | Fri | 百家号补稿
2026-10-09 23:40 | Fri | 晚间总结
2026-10-11 05:40 | Sun | 合集生成，周日

落点不对就删掉重建，别想着下次再说。

nextRunAt 换算核对结果，含星期

附赠一个：执行说明里写死的时间要同步改

我的晨报说明里写着「每天早 9 点触发」「实际执行 09:03 ~ 09:17」，晚间总结写着「每晚 21:07」，合集写着「每周日 18:00」。

只改触发时间、不改说明，执行时会按错误的时间描述自我校验，这也是隐蔽不一致。我全部同步改了，并且在每条说明顶部加了一行迁移记录：

（2026-10-09 说明：本任务原在 09:00，属付费时段，为节省积分已前移到 06:40，仍在免费额度时段内；且晚于 06:00 的「素材准备」任务，保证「发布前置体检」能读到当天素材。）

过两周我自己都想不起来为什么时间变了，有这行就能查。

模型切换：脚本做不到，但可以兜住

很多人第一反应（包括我）是写个脚本，23:00 自动切 Hy4 preview，08:00 切回免费的 Hy3。

这个做不到，别浪费时间。我把 ~/.workbuddy/settings.json（40KB）翻了一遍，没有任何 model 字段，也搜不到模型名痕迹。模型选择是会话层、界面层的状态，不落盘在配置文件里，脚本无从改写。

可行的是兜底三件套。

一是两条定时提醒，23:00 一条、08:00 一条，到点提醒切换并写状态文件。

二是一个状态文件，记录当前该用哪个模型、有效期到什么时候：

{
  "activeModel": "Hy4 preview",
  "window": "23:00-08:00 免费额度",
  "freeQuota": true,
  "rule": "每晚 23:00 至次日 08:00 使用 Hy4 preview；08:00 至 23:00 使用 Hy3",
  "activeUntil": "until_user_explicitly_clears",
  "updatedAt": "2026-10-09T01:02:00+08:00"
}

三是一条写进长期记忆的规则，而且必须写解除条件：

每晚 23:00—次日 08:00 用 Hy4 preview，其余时段用 Hy3。从 2026-10-09 起生效，直到用户明确说「积分问题已解决」为止；在此之前任何会话不得自行解除、降级。

第三条是我最想强调的。只写规则不写有效期，等于没写。我吃过亏：规则立了，过几天某个会话看积分「好像够用」就自己放宽了。把解除条件钉死，规则才真的成立。

顺带提醒一句，这类方案只能做到提醒加状态记录，实际切换仍然需要手动点选模型。

排期前后对照

任务一条没减，功能一样没少。白天只剩平台交互和发布动作，写作、总结、巡检全部挪到夜里免费用。

排期前后对照

顺带挖出来的两个东西

既然在查，我把积分通道也扒了一遍，有两个意外收获。

一是成长计划还有 200 分没领。用积分技能查，18 个任务、奖励池合计 2050 分，profile 显示已完成 16 个，但脚本把每个任务状态都显示为空。这两个数字自相矛盾，去翻接口原始返回才发现：脚本读的是 status，而接口真实字段是 accept_status，取值 claimed / in_progress / not_accepted。取错字段不报错，只让状态恒为空。改成 accept_status 优先就对上了，还剩 2 个任务共 200 分。

二是跨字段交叉校验能抓出静默错误。profile 说 16/18，任务列表却全空——两个数字打架，就说明字段映射错了。这类错误不会抛异常，只会安静地错下去。以后看到「全是 None」别急着当成「都未完成」，先找另一个字段对一下。

最后一份检查清单

如果你也想把定时任务搬进免费额度，按这个顺序做：

• 把所有定时任务的触发时间抄出来，标上是否落在免费时段
• 分类：本地写作和计算能挪；平台交互和定时发布不动
• 画依赖链：谁读什么、谁写什么，保持先后顺序
• 改 rrule：一个时间点一条，别用 HOURLY 凑多档
• 换算 nextRunAt 核对落点和星期
• 同步改执行说明里写死的时间，加一行迁移记录
• 模型切换做不到自动，改用「提醒 + 状态文件 + 带解除条件的规则」

最后一条最容易被忽略，但我认为也最有用。