前言¶

做自动化的人大概率都踩过同一类坑：脚本写在本地，靠 cron 定时跑，结果机器休眠一晚、断网十分钟，或者跨时区跑在 UTC+0 的机器上，签到就断了，积分也就没了。更麻烦的是签到类任务通常不支持补签，断一天就是少一天，而且你很难第一时间发现——等你发现时已经过去好几天了。

下面介绍的这个 Skill 就是把这类「每天必须跑一次、断了就要补」的任务收敛成一个配置项驱动的脚本：工作日还是节假日都要跑、错过时间自动补跑、网络不通先等网络、签到结果落盘可查。它面向的是 WorkBuddy 的每日签到积分领取场景。

这是什么¶

@user_390e7a89/leon-daily-checkin（Skill 名：自动签到领积分），版本 1.3.0，来源 community，分类 dev-programming，由 user_390e7a89 发布维护，标签 requires_api_key=true。

它解决的问题很具体：把 WorkBuddy 的每日签到积分领取从「记得去点一下」变成「脚本自己会签到，签到日按服务端日期判定，漏了自动补」。

核心功能¶

来自官方简介的能力清单：

1、按需立即签到，或每天定时自动签到。
2、纯标准库脚本，不依赖第三方包。
3、支持 desktop / token / credentials 三种鉴权方式。
4、指数退避重试，失败不直接放弃。
5、幂等防重复，同一天重复执行不会产生多次签到。

全场景覆盖与补签策略¶

这是官方资料里最花篇幅的部分，结论可以先说：节假日不需要任何特殊处理。

签到按自然日判定，不是按工作日。也就是说周末和法定节假日照常签到、照常给分，任务 365 天每天触发。所以脚本不内置节假日表，也不调用节假日接口——多跑没有副作用（幂等），少签才是实际损失。

补签机制分三层，按时间顺序执行：

1、错过 11:00 的签到窗口后，在开机或系统唤醒时立即补跑（StartWhenAvailable）。
2、20:00 再兜底试一次。
3、断网时脚本先等待网络恢复，最多等 300 秒，然后再签（新增 wait_for_network，可配置）。

跨时区的处理方式是：脚本按 UTC+8 的服务端日期判定「今天」是签到日，日志同时打印本地日期和服务端日期。所以即使部署在国外的机器上补跑，签到的也是服务端的「今天」，不会出现本地日期和服务端日期错位导致的漏签或重复。

失败重试和通知分两层：

1、脚本内部做指数退避重试。
2、系统层每 10 分钟重试 3 次。

结果写入 last_result.json 落盘。config.yaml 里新增了 notify 节，可以配置成功和失败的通知命令。

安装与启用¶

需要说明的是，本次抓取的官方资料里没有给出具体的安装命令和完整的配置字段清单，只有 config.yaml 中的 notify 节和 wait_for_network 这两个配置项被明确提到。因此这里不写未经核实的安装步骤，只给出官方地址，实际部署前以官方页面为准：

官方地址：https://api.skillhub.cn/user_390e7a89/leon-daily-checkin
SkillHub 页面：https://www.skillhub.cn/skills/user_390e7a89/leon-daily-checkin

按标签 requires_api_key=true，启用前需要准备相应的鉴权凭据，三种方式（desktop / token / credentials）任选其一。

适用场景与注意¶

适合的人：想把 WorkBuddy 每日签到积分托管给脚本、不希望每天手动点、也不能接受漏签的用户。

需要注意的几点：

1、幂等设计意味着重复执行安全，但也意味着你无法靠「多跑一次」来补救失败，真正起作用的是三层补签。
2、签到日判定依赖 UTC+8 服务端日期，如果你的服务端时区不是 UTC+8，需要确认判定逻辑是否符合预期。
3、断网等待上限 300 秒，超过这个时长仍未恢复网络时，这一轮会失败，需要依赖系统层的下一轮重试。
4、通知能力依赖 config.yaml 的 notify 节配置外部命令，配置不当会导致失败时没有告警——这类任务静默失败的代价很高，建议把通知接上。

结尾¶

这个 Skill 的价值在于把「每天签到」这种看起来简单、实际容易因为休眠、断网、时区、节假日判断而漏掉的重复劳动固化成一套有补签、有重试、有落盘、有通知的机制，同时保持纯标准库、幂等、三种鉴权可选的实现方式。需要的话从这里开始：

https://api.skillhub.cn/user_390e7a89/leon-daily-checkin