《周末关机 = 连签必断：我用 WorkBuddy 给自己搭了一套「自己醒过来」的方案》

一、先说痛点：连签断在了没人看的那两天

我在物流公司做人事薪酬，管着 4 家分公司的组织架构。这活儿跟写代码八竿子打不着，但我有个小爱好——用 WorkBuddy 帮我做重复性工作，攒下来的积分还能换成长值。

用着用着就发现一个规律：工作日天天正常，一到周末就断。

翻日志一查，缺签日清清楚楚：

原因也简单得让人无语：我周末把电脑关机了。

关机了，脚本就没了，脚本没了，那天的签到就没了。听起来像个笑话，但这就是最朴素的问题——

周末不碰电脑 → 电脑不执行签到 → 当天的签到和积分就这么没了。

顺带说一个反直觉的观察：平台的"连签"计数并不会因为漏一天就清零。我 10-16 时是连签 6 天、漏掉 10-17 和 10-18 之后，10-19 依然显示连签 7 天——它记的是"累计签到天数"而不是"严格连续的日历天数"。

但积分是真的实打实少了：10-24 时累计 1200 分，10-26 补签回来时是 1300 分，中间只涨了 100——10-25 那天的 100 分是永远补不回来的。

我想让它自己醒过来把活干了。第一反应是网上那一套："进 BIOS 开 Wake on Alarm，设个定时开机"。我照着做了，然后发现——不管用。

二、我以为是 BIOS 的问题，其实是 Windows 电源语义的问题

第一次失败让我怀疑人生。我甚至为此专门重启进了一次 BIOS，在 Advanced → Wake Up Event Setup 里把 Wake on Alarm 设成 Daily 08:00:00，存盘退出。

依然没醒。

后来我把 Windows 的电源状态彻底捋了一遍，才发现自己从一开始就搞错了前提：

关键点在这儿：「快速启动」本质是「关机时自动做一次休眠」，但它有个前提——系统必须启用了休眠。

很多机器上 HiberbootEnabled=1 而 HibernateEnabled=0，此时"关机"就是真断电，快速启动形同虚设，BIOS 里设再多的唤醒也没用——因为主板的 RTC 根本没电。

判据不能看注册表，要看实际输出：

我这台机器的输出是：

「休眠」那一行写着尚未启用。所以我这台机器关机 = 真断电 = 定时唤醒在物理上就不成立。不是 BIOS 没设对，是这条路压根不通。

三、换个思路：既然 S3 能唤醒，那就不关机

顺着上面那张表往下推，思路就顺了：

关机不行，睡眠行。 睡眠（S3）下内存是保电的，RTC 也在跑，机器随时能被叫醒。 那就让电脑整个周末保持"睡眠"，别关机不就完了？

但还有第二个问题：谁把它叫醒？ 总不能让我周一早上爬起来按电源键吧。

答案在计划任务里：WakeToRun

Windows 计划任务有一个 WakeToRun 属性。开启后：

电脑在 S3 睡眠中，到了任务触发时间，它会自己醒过来把任务跑完，然后按需继续睡。

这条链路完全在操作系统层，不需要改任何 BIOS 设置，也不需要主板 RTC 唤醒定时器。

我最终的方案就是 4 个计划任务 + 8 轮轮询：

工作日则靠 8 轮轮询兜底：01:00 / 05:00 / 08:05 / 09:00 / 10:30 / 13:00 / 17:00 / 21:00，每轮都检查"今天签了没"，没签就补。

进睡眠这一行代码

powercfg /hibernate 相关命令要管理员权限且在本机不适用，直接调 Windows API 更干净：

走 cmd 调 powercfg 不行（需管理员），用 Windows API 调用 powrprof.dll。 另外不要用 Add-Type——部分环境的安全策略禁止运行时编译 .NET，ctypes 调 API 可以完美规避。

真机验证

光设计没用，得测。写了个一次性任务：先让电脑进睡眠，再让计划任务到点唤醒。

这条日志是我整个方案的立身之本——它证明唤醒链路真的通了，不是纸上谈兵。

四、方案上线后，还是断了一次（这段最有价值）

我以为到这儿就万事大吉了。结果 10 月 25 号周日，又断了。

一开始我怀疑是脚本问题，查了一圈日志——signin.log 里 10-25 一条记录都没有，weekend.log 里也没有唤醒痕迹。于是我去翻 Windows 事件日志，找到了真凶：

"关闭是意外的"——这行字是整个谜题的钥匙。

复盘时间线：10-24 09:30 睡眠指令正常发出，之后电脑进入了 S3；但在 S3 里被硬断电了（可能是电源波动、可能是插排跳闸、也可能是谁按了电源键）。断电之后机器就是块砖，08:05 的 WakeToRun 自然无从谈起。

这才是真教训：

方案只防"关机"，防不住"断电"。S3 睡眠依赖内存保电，一断电，S3 和 S5 就没有区别了。

所以现在我的周末铁律是两条：

1. 绝不手动关机（睡眠可以，关机不行）；
2. 别让插排/电源出问题，宁可花钱换个带 UPS 的插排。

顺便纠正一个我一开始的误解：我原以为"漏了签，第二天补签就能把分补回来"。实测不是这样——

10-26 补回的是它自己那天的签，10-25 那 100 分是净损失。连签天数没清零，但分是真没了——所以别指望"断一天没关系"，一天就是一天。

怎么知道有没有悄悄断过

光看积分不够，得能自查。我加了个小工具，一行命令跑出全局体检：

输出长这样：

周末日期表是脚本自动生成未来 12 个月的，不需要手动续期——这省心程度对 HR 来说太重要了，我不想每季度去改一次配置。

五、几个让我少踩坑的细节

1. 唤醒后网络没就绪，签到会失败。 S3 唤醒后网卡往往要十几秒才连上。我的做法是：唤醒后先等网络（最多等 90 秒），再签，失败重试 3 次。

2. schtasks 命令行可能被安全策略拦。 改用 PowerShell 的 New-ScheduledTaskTrigger / Set-ScheduledTask cmdlet，稳。

3. WakeToRun 装的时候必须提权。 不然后面查任务属性全是空的，还以为是功能不work。安装脚本里我直接加了自提权：

4. 错过的触发器要能补跑。 所有任务都开了 StartWhenAvailable = true，这样即使错过了触发时间，也会在系统下次有机会时补跑。上面 10-26 就是靠这个把当天的签补回来的（注意：只能补当天，漏掉的那天补不回来）。

5. 关键任务一定要留日志。 signin.log（签到明细）、weekend.log（看护日志）、wake_test.log（唤醒验证）三份分开。没有日志，出了问题你就是瞎猜。

六、写在最后

现在我的周末是这样过的：周五下班，电脑自己睡过去；周六早上 8 点，它自己醒过来签完到，再睡回去；周日重复一次。 我全程不用管。

到 10 月 28 号为止，累计签到 15 天、1500 分。中间漏掉的那几天，只能说交学费了——好在连签计数没清零，不然更肉疼。

这个方案最有价值的地方，可能不是"省了几次点击"，而是让我想明白了一件事：

很多"做不到"的事情，根源不在于你不够努力，而在于你一开始就把问题诊断错了方向。

我一开始死磕 BIOS，是因为"定时开机"这个说法太深入人心了。真正花时间把 S3/S4/S5 和 powercfg /a 的输出捋清楚之后，方案就自然浮出来了——而且是更简单的那个（不改 BIOS，只改 Windows 任务），还是更稳的那个（操作系统层，跨主板通用）。

顺便说一句，这类偏底层的小脚本我是让 WorkBuddy 帮我写的：它把 SetSuspendState 的三个参数含义、计划任务的 WakeToRun 属性、事件日志里 6008/41 这些错误码的含义，一次性给我讲明白了，我只需要负责验证和决策。

如果它当时也帮我把方案直接封装成可分发的技能包，那就更省事了——现在我这套「签到 + 周末免断签」已经打包提交到 WorkBuddy 开放平台审核了，等过审就能一键装。

本文为真实使用记录整理，文中路径与命令均已核对可复现。