#WorkBuddy# 我把成长中心的积分任务全自动化了，从 431 分干到 1519 分

上周打开 WorkBuddy 的用量页，剩余积分 431.92。

这个数字有点扎眼。主套餐 2170 已经用掉 1738，另外买的 500 加量包早清零了。按我平时的用法，撑不过三个晚上。

于是一咬牙，花了一个晚上把成长中心那套签到、做任务、领奖励的流程全自动化跑通了。现在每天零点零五自动签到，早七点和午十二点各跑一次全量任务，四小时轮询一次捡旅行礼物和盲盒。跑完一轮下来，积分从 431.92 变成 1519.72，等级从 2 级跳到 15 级，19 个任务做完 15 个。

过程不算顺，踩了四个坑，其中第三个直接把我客户端搞重启了。这篇把过程和数据都写下来，谁要抄直接抄。

一、先说结论：哪些分是能自动拿的

把成长中心的任务拆开看，其实就三类。

第一类，纯签到。 每天 100 分，连签有加成，断签可以用补签卡补。这类最稳定，也最没技术含量。

第二类，任务卡。 聊天五次、召唤三次专家团、用五个模板、设置一条自动化、体验某个行业的专家……每项 100 分，一堆 50 分的零碎任务。这类分最多，一共 19 项，但坑在于必须先点「去完成」再接任务，再去做动作，顺序反了系统不认。

第三类，玩法奖励。 抽盲盒、派 Buddy 出去旅行、连登兑换。这类分数不大，但胜在不用动脑，纯点。

一天能干的上限，签到 100 + 任务里能做的十几项 + 零碎玩法，我实测大概是 1000 出头。第二天开始，每天自然回落到 100 到 300 之间，因为任务不刷新。

这里得先泼一盆冷水：自动化只能拿到「已下发」的任务分。活动没开放的任务，接口里根本不返回，脚本再牛也抓不到。我最后卡在 15/19，剩四项——一项要本人微信扫码关注公众号，另外三项服务端压根没下发。

二、第一个坑：你的登录态是加密的

GitHub 上能搜到一堆 WorkBuddy 自动签到的项目，八成都要求你把 手机号:AT:RT 填进环境变量。

我照着做，第一步就卡死了：根本拿不到明文 token。

WorkBuddy 桌面端 5.6.2 之后默认开了 AtRestEncryption，登录态文件里的字段已经不是字符串了。你打开下面这个文件：

登录态文件在 %LOCALAPPDATA%\CodeBuddyExtension\Data\Public\auth\workbuddy-desktop.info 这个路径下。

会看到 accessToken 的值是一个 dict，形如 {"v": 1, "alg": "AES-256-GCM", "kid": "...", "iv": "...", "ct": "..."}，外面还套一层 sym-v1 的标记。密钥不落盘，由客户端在运行时从系统凭据里取。

也就是说，那些「填 token」的方案，在你这里第一步就走不下去——除非你重新走一遍短信验证码登录，把新 token 抠出来。

但这里有个更省事的思路：密钥既然在客户端进程里，那就让客户端自己解密。

WorkBuddy 是 Electron 应用，主进程里有个认证 helper，它的能力被暴露在 IPC 上。既然签到脚本本来就要读这个文件，那就顺手调一下它的解密接口：

# 伪代码，核心就三步
runtime = find_runtime()          # 定位 WorkBuddy.exe 的 Electron 运行时
envelope = session["auth"]["accessToken"]   # 拿到那个 dict
plain = run_auth_helper(runtime, {"operation": "decrypt", "value": envelope})

跑通那一刻挺爽的——不需要发短信，不需要粘 token，你人登着它就能跑。这也是我最后选 88lin/workbuddy-auto-signin 的原因，它是少数几个这么干的。零第三方依赖，单文件，只用标准库。

顺带说一句，安全上要留个心眼：解出来的明文 AT 等于你的账号凭证。我全程只把它放在本地文件里，跑完就清，绝不进 git。

三、第二个坑：计划任务里的 pythonw

签到脚本要装两个 Windows 计划任务，一个每天零点零五跑签到，一个每四小时轮询补签。装的时候报错，说找不到 pythonw.exe。

原因很蠢：我这台机器的 python 是 WindowsApps 的应用别名，Get-Command python 指向的是 C:\Users\xxx\AppData\Local\Microsoft\WindowsApps\python.exe，这个目录下面没有 pythonw.exe。

计划任务必须用 pythonw 才不弹黑框，所以得手动指定。翻了一圈，系统自带 C:\Windows\pyw.exe 可用，填进去就过了。

但紧接着第二个问题：pyw.exe 默认解析到的是 Python 3.12，而 3.12 里没装 requests（我平时用的是 3.13）。任务跑起来，LastTaskResult 是 1，日志一片空白。

两个解法叠着用：

# 1. 给 3.12 补依赖
py -3.12 -m pip install requests

# 2. 包装脚本里自己挑解释器，别信默认值
def pick_python():
    for cmd in (["py", "-3.13"], ["py", "-3.12"], [sys.executable]):
        try:
            out = subprocess.check_output(cmd + ["-c", "import requests;print(1)"], timeout=15)
            if out.strip():
                return cmd
        except Exception:
            continue
    return [sys.executable]

CREATE_NO_WINDOW 这个 flag 也别忘了加，否则每四小时给你闪一下黑框：

flags = getattr(subprocess, "CREATE_NO_WINDOW", 0)
subprocess.call(cmd, creationflags=flags)

四、第三个坑，也是最狠的：它把我客户端重启了

这个必须单独讲，因为它是那种「文档完全不提、跑起来才炸」的坑。

有个功能叫得比较全的脚本，在 Windows 上会走一条叫「桌面换血」的流程：备份当前认证文件 → 换成另一个账号的 → 重启 WorkBuddy 桌面端 → 等它自己把「桌面端对话」这类任务跑完 → 再把认证还原、再重启一次。

设计上没毛病，靠真实重启客户端来拿桌面端任务的分，确实比伪造上报干净。

问题是我这套东西就跑在 WorkBuddy 里面。

它一重启，我这边会话直接断，跑到一半的任务全没了，终端也一起被掐掉。当时看到的现象就是「莫名其妙闪退」，日志停在这一行：

21:27:21 🖥️ 桌面换血流程启动（结束后自动还原认证并重启桌面端）...

排查了半天以为是脚本崩了，后来才发现是它正在干一件很合理但对我来说很致命的事。

解法：跳过它。

python workbuddy_daily.py --no-desktop

代价是放弃「桌面端对话」那点分，大概一百来分。云端任务、小程序链式任务、各种玩法全部照跑。我做了个包装脚本，强制注入 --no-desktop，这样以后不管谁调用、不管定时任务怎么配，都不会再触发换血。

如果你也打算在自己电脑上跑这类脚本，先看它有没有 --no-desktop 这种开关，没有的话慎重。 这是这次最值钱的一条经验。

五、第四个坑：半截 refreshToken

上一个坑的后遗症。

换血流程被我从中间打断，它往认证文件里写 refreshToken 写了一半就断了。下次再读，解析失败，整个凭据导出报错退出。

关键判断在这里：我压根不需要 refreshToken。

AT（access token）本身有效期 720 小时，整整 30 天，足够跑很久。而 RT 一旦被脚本拿去用，会触发令牌轮换，轮换之后桌面端的旧 token 就失效——你桌面端会莫名其妙掉登录。

所以我改成了只注入 AT、不注入 RT。格式上仍然凑够三段（脚本按 账号:AT:RT 解析，RT 段留占位），但 RT 那段是真不参与任何请求。

try:
    rt = decrypt(session["auth"]["refreshToken"])
except Exception:
    rt = "NONE"        # 解不开就算了，本来也不用它

改完之后，凭据导出再没失败过，桌面端也没掉过登录。这个设计比原方案安全得多——能用短生命周期凭证就别碰长周期凭证，反过来更常见，但这里恰好是反的。

六、跑完之后的数据

说点实在的，别光看过程。

到账记录我贴一部分，都是接口回的真实 code：

加上签到 100、连登兑换 50、盲盒开的 20，一天净增 1088 分。

现在挂了三个计划任务：

三个都开了「唤醒执行」和「错过后补跑」，机器通着电就自己跑，不用管。

七、没做成的那四项

老实交代，别让人以为全自动了。

关注「腾讯 WorkBuddy」官方公众号 —— 这个真没办法，必须本人微信扫码，脚本里明确标了「需手动」。

体验资料库 / 腾讯轻量云专家 / 尝鲜热门技能 —— 这三项服务端压根没下发。接口返回的任务列表里查不到，脚本抓不到，只能等它上线。

所以我最后的完成度是 15/19，不是 19/19。任何号称能百分百做满的脚本，都值得怀疑一下。

八、几句提醒

第一，这类接口都是从客户端逆向出来的。 官方改一版就可能失效，修复全靠作者更新。别指望一劳永逸。

第二，Token 就是你的账号。 解出来的明文 AT 别提交到公开仓库、别贴进 Issue、别发给任何人。我自己的做法是本地存一份、跑完即清。

第三，非官方自动化有风险。 理论上存在被判定异常的可能。稳妥的做法是先用小号观察几天，确认没问题再上主号。

第四，也是最重要的：脚本这条路有天花板。 签到加任务，一天封顶也就几百到一千分，之后就是硬顶。真正的大头在别处——社区发文章、邀请好友这些官方渠道，单次收益是签到的好几倍。

把脚本当基建，把精力放在高收益的地方，这个顺序别搞反了。

附：自动化跑批实据

下面三张图都来自本机，不是示意图。数据源我也一一标出来了，方便核对。

图一，三个计划任务的运行实绩。 数据取自本机任务计划程序的运行记录。三者状态都是"就绪"，退出码均为 0，也就是最近三次都正常跑完了。中间那个 WorkBuddyDailyTasks 是主力，早上 7:10 刚跑完一轮，下一次触发是 12:10。

三个自动任务的运行实绩：状态、上次运行时间、下次运行时间与退出码

图二，早上那轮的真实日志。 脚本会把任务列表拉出来逐条判定，能领的直接领，做不了的跳过，最后统一结算。日志里能看到具体数字：Sequential_Tasks_2 这一档领到 200 积分、5 点能量，另有 5 枚徽章和一只开出来的"金算喵"。也有认怂的地方——关注公众号这类要扫码的任务，脚本不会、也不该代劳。

清晨跑批日志节选：任务判定、领奖记录与需要手动处理的任务

图三，整条链路的六个环节。 从计划任务唤醒，到拉取任务列表、逐项判定、达标即领、状态落盘，最后尝试推送。状态落盘这一步很关键，它保证同一份奖励不会被重复领取，也让每一轮的运行结果可以回溯。

自动化流程的六个环节：唤醒、拉列表、判定、领奖、落盘、推送

以上。所有数字都是我自己账号跑出来的，不是估算。有问题评论区见。