【制造·硬件】车间里没人记得点签到：我用 WorkBuddy 把每日积分做成了 4 个整点的定时任务

▲ 图1 签到时间线

背景与痛点：最简单的动作，反而最难坚持

我是做电池保护板（PCM）研发的，日常节奏基本是三段式：上午在实验室跑测试，下午可能蹲在产线跟问题，晚上回来写报告、回海外客户的邮件。工作电脑经常一整天开着但不碰，或者干脆合盖带走。

WorkBuddy 有两类每日积分活动：Buddy 加油站签到，每天 100 积分，连续第 7 天额外 1000；Buddy 旅行（派猫猫去咖啡馆），每天一轮，奖励 5~10 积分浮动。加起来一天一百出头，一个月三千左右——对经常要用 AI 的人来说不是小数目。

但手动签到这个动作，恰恰是我这种日程最容易漏的。九月中旬我就翻车过一次：连续天数从 8 直接掉回 1，一千分的长跑奖励重新计。这件事让我下决心把它彻底自动化——不是"提醒我签到"，而是"根本不需要我"。

输入材料：全部来自本机，零手工整理

这件事的起点材料很少，也都是现成的：

1. 本机已登录的 WorkBuddy 桌面端——登录态存在本地，脚本可以直接读取，不需要扫码或输入任何凭据；

2. 官方的两个活动接口——签到走 Buddy 加油站，旅行走成长中心，都是账号自己的数据；

3. 我自己的运行日志——脚本每次执行会往 result.log 追加一行摘要，后来成了整篇文章的数据源；

4. 一份已经写好的本地 Skill——workbuddy-reward-helper，纯 Python 标准库，不用装任何第三方包。

WorkBuddy 配置：一个 Skill + 四条定时任务

本地 Skill：workbuddy-reward-helper

这个 Skill 做的事非常克制，就四个子命令：

python scripts/main.py all # 日常推荐：先签到、后旅行，输出汇总 JSON

python scripts/main.py status # 只读查询，不做任何领取/派遣

all 的返回长这样（真实输出，record_id 未改）：

{"checkin": {"task": "checkin", "status": "success", "credit": 100, "streak_days": 5},

"travel": {"task": "travel", "status": "claimed", "reward_credit": 7, "record_id": 2237800}}

它的旅行部分不是"无脑点按钮"，而是一个小状态机：猫闲着（idle）就派去咖啡馆；到达（arrived）就领奖励；旅行中（traveling）或当日已达上限（daily_limit_reached）就跳过。每一步都只依赖服务端返回的状态，不猜、不重试轰炸。

安全设计也交代一下：登录态 token 只在内存里用，不写日志、不打印、不上传第三方；日志里只有任务名、状态和积分数字。这点对要长期跑的自动化很重要——出问题可以放心把日志给人看。

定时任务：每天 4 个整点，每条一个时间点

我在 WorkBuddy 自动化里建了 4 条任务，分别落在每天 09:00、13:00、17:00、21:00，每条跑的都是同一条命令 main.py all。

▲ 图3 定时任务配置

为什么是 4 个点、为什么都跑 all？两个原因：

• 旅行时长是 1~4 小时浮动的。早上 9 点派出去，可能 10 点就到，也可能 13 点才到。单靠一个时间点，"到达→领取"这个闭环很容易错过，所以要用多个时间点补跑；

• 脚本幂等。已签到会返回 already_checked，当天旅行完成会返回 daily_limit_reached，重复跑没有副作用。所以四个点都写 all，让服务端状态自己收敛，不需要四条任务各管一摊。

操作步骤与中途调整

第一步，手动跑通一次。 建定时任务之前先在终端跑 all，确认登录态能读到、两个接口都返回正常。这一步别省——定时任务只是触发器，脚本本身不通，定时只会准时地失败。

第二步，建定时任务，这里踩了第一个坑。 我最初想用一条任务表达"每天 9、13、17、21 点各跑一次"，RRULE 写成 BYHOUR=9,13,17,21。结果自动化校验器直接报错：BYHOUR 不支持逗号列表，每个时间点必须单独一条。拆成 4 条之后一次通过。这个坑不踩不知道，官方 RRULE 文档里 BYDAY=MO,WE,FR 是合法的，唯独 BYHOUR 的列表被校验器拒了。

第三步，验证幂等性。 同一天手动重复跑了多次 all，确认第二次开始全部返回 already_checked / daily_limit_reached，积分没有重复计入。日志里 9/19 那天有 12 次运行记录，就是压测幂等的痕迹。

第四步，踩到第二个坑，也是差点误判的一个。 有天我想只读核对一下今天领没领，跑了 status，返回说"今天没签到、连续 0 天"；紧接着跑 all，却返回 already_checked——同一个时刻，两个接口给了相反的答案。

▲ 图4 实跑输出对比

反复核对后确认：status 走的那个查询接口的 today_checked_in 字段不可靠（签到成功后仍可能返回 false），判断"今天领没领"必须看 `all` 的实际返回；真要只读核对，得改用另一个活动状态接口。这条教训已经写进了 Skill 的文档里，标题就是警告。

第五步，实战检验。 9 月 25 日我在车间一整天，电脑只在傍晚捡起来过——日志显示那天全天只有 17:00 一条定时任务跑到，签到 success credit=100，旅行也正常派遣，第二天中午照常领到奖励。整天没碰电脑，积分一分没丢，这就是这套配置要的效果。

产出物：一份可以验收的台账

跑了 17 天（9/10 ~ 9/26），产出如下：

▲ 图2 积分构成

1. 运行台账：result.log 共 121 行，每天 3~5 次运行记录，每次一行，可审计可回溯；

2. 积分账目：日志明确记录的签到积分 1500 + 旅行积分 113 = 1613 积分，全程零人工干预；

3. 连续天数：最长连到 10 天（9/16 中断过一次后重连）；

4. 一套可直接复用的定时任务配置：4 条 RRULE（FREQ=DAILY;BYHOUR=9/13/17/21;BYMINUTE=0），加一条幂等命令，任何人可以在自己的 WorkBuddy 里照抄重建；

5. 一份沉淀成文的 Skill：把接口契约、状态机、踩过的坑全部写进 SKILL.md 和参考文档，下次遇到类似"每日活动"类接口可以直接套。

踩坑与注意事项（精华都在这）

• RRULE 的 BYHOUR 不支持逗号列表，多个时间点必须拆成多条任务（BYDAY 的列表倒是支持，容易想当然）；

• 只读状态接口会说谎：today_checked_in 可能返回 false，幂等判断必须以执行动作（all）的返回为准；

• 旅行时长 1~4h 浮动：定时点要能覆盖"派遣→到达→领取"整个窗口，建议至少早、中、晚、夜四个点；

• 整天不开机没有补签：签到按自然日结算，连续天数会断。这是硬限制，多时间点只能提高"开机窗口内被覆盖"的概率，救不了整天关机；

• 9/16 的连续中断我在日志里没找到原因：前后两天都是 success，连续计数却归 1，可能与活动周期切换有关——日志里没有答案的部分，我不编。

总结

这件事技术上不复杂：一个读本地登录态的脚本，加四条幂等的定时任务。但它解决的是"坚持"问题——把一个依赖人记性的每日动作，变成一套不需要人存在的系统。17 天 1613 积分里，我亲手操作的次数是零。

如果你的工作也和我一样，白天在人机料法之间打转，电脑时开时关，建议把这类每日任务交给定时自动化：先手动跑通，再拆时间点，最后用日志验证幂等——三步走完，就可以忘掉这件事了。