22 天，把 WorkBuddy 每日积分做成全自动：从 F12 到 Playwright 实战

22 天，把 WorkBuddy 每日积分做成全自动：从 F12 到 Playwright 实战 想让 AI 每天自动帮你领积分？这事儿我实打实折腾了 22 天，踩了一圈坑，最后用 Playwright + 登录态复用把"每日签到"和"今日礼包"全自动化了。把路线和架构公开，少走弯路。 一、走过的死路（别再踩） 1. 以为本地有接口：翻遍本地数据库和配置文件，发现积分余额只在云端，本地零字段。 2. 以为能直接浏览器自动化：环境没有浏览器 MCP、没装 Playwright，纯靠 WebFetch 过不了登录态，点不了按钮。 3. 以为 F12 抓 cURL 就够：能抓到请求，但登录态（cookie/token）会过期，且每次要手动抓，不"自动"。 4. 以为后台自动化能维持活跃：实测调技能前后活跃记录 md5 完全没变——后台跑的动作根本不算"活跃"。 二、最终跑通的架构 核心一句话：自动化登录态类任务，关键在于"拿到并复用登录态"，能直接调后端 API 就别模拟点击。 1. 装 Playwright（Node 隔离环境，浏览器二进制放 D 盘不占系统盘）。 2. 一次性获取登录态： - 拉起一个可见的 Chromium，导航到积分页； - 你手动扫码登录一次； - 脚本检测到真正进入积分页后，用 context.storageState() 把登录态存成 auth.json。 3. 每日脚本（定时任务 09:00 跑）： - 加载 auth.json 注入登录态； - 直接 fetch 后端接口： - 每日签到：POST /billing/meter/daily-checkin - 今日礼包：POST /billing/meter/claim-gift - 读回响应，判断"已领取/成功/失败"并写日志、如实汇报。 三、两个被验证的真实接口 接口：成功/已领响应 POST /billing/meter/daily-checkin：今天已签到，请明天再来 POST /billing/meter/claim-gift：每人限领一次，您已领取过无法重复领取 注意：这些是后端真实路径，直接 fetch（带 credentials: 'include'）即可，不需要模拟任何 UI 点击。 四、还能自动化的 vs 不能的 · ✅ 能自动：签到、礼包（都是 HTTP 接口）。 · ❌ 不能自动（实测）：Buddy 加油站——它是客户端"升级并重启 App"专属逻辑，网页端无对应接口，只能手动领。 五、经验总结 1. 先验证能力，再画饼：环境到底支不支持浏览器自动化，先 npm ls / 查 MCP 连接确认，别上来就承诺"我能点"。 2. 登录态是金：一次性扫码存 storageState，之后每天复用，比每次抓 cURL 稳得多。 3. 能调 API 就别点 UI：接口返回的语义（"已签到"）比猜按钮状态可靠。 4. 如实汇报：自动化必须报告真实结果，绝不编"已领取"。 如果你也在折腾 WorkBuddy 积分自动化，希望这条路线能省你 20 天。