我是谁，以及我遇到了什么问题
我是制造业从业者（起重机械配件行业），不是全职程序员。日常用 TraeCode 做 CAD 自动化、业务文档处理和数据分析。Trae 的新积分体系下，每日签到送 200 积分，但经常忘记签到，一个月下来白白损失好几千积分。
论坛上有人分享了自动签到脚本（传送门），但下载后发现两个问题：
-
脚本路径写死了
TRAE SOLO CN，我本地装的是Trae CN，路径对不上 -
签到 API 返回
code: 9004（参数错误），说明 API 接口已经更新了
于是我用 TraeCode 一步步调试、修复、部署，最终实现全自动每日签到。
我是怎么用 TraeCode 解决这件事的
使用模式：IDE 模式（对话式交互 + 工具调用）
第一步：适配本地路径
TraeCode 读取了脚本源码，发现 storagePath 变量写的是硬编码路径。我用 Edit 工具把路径从 TRAE SOLO CN 改成 Trae CN，匹配我本机的安装目录。
第二步：调试 API 参数
这是最耗时的一步。签到接口返回 code: 9004（参数错误），需要找出缺了什么参数。
TraeCode 帮我做了以下排查：
-
在
storage.json里发现telemetry.machineId和telemetry.devDeviceId两个字段——这两个值可能是请求头里缺的设备标识 -
给请求加上
X-Machine-Id和X-Device-Id头——加上之后，API 错误从9004（参数错误）变成了9074（服务器繁忙/限流），说明请求格式已正确，只是被限流了 -
在 auth 对象里发现
userId和userRegion字段，补充到请求头
关键发现：设备 ID 头是签到 API 的隐藏必填项。不加这两个头，API 直接返回 9004 拒绝；加上之后，API 正确返回签到状态（150+50=200积分待领取）。
第三步：部署自动化
服务器在高峰期会返回 9074（参与用户太多），需要在低峰期重试。我做了三层保障：
-
重试逻辑：脚本内置 10 次重试，每次随机等 15-30 秒
-
守护进程：用 PowerShell 写了一个常驻后台进程，每小时检查一次，未签到就自动触发
-
开机自启：在 Windows 启动文件夹放了一个 VBS 启动器，开机后自动拉起守护进程
所有文件部署在 Desktop\trae-checkin\ 目录下：
-
checkin.js：签到核心脚本（AES 解密 token → 查询状态 → 领取积分） -
run_checkin.cmd：CMD 入口 -
trae_daemon.ps1：后台守护进程 -
start_daemon.vbs：静默启动器（开机自启）
第四步：验证
运行脚本后，控制台输出：
Status: not checked in. Expected: 150+50 credits
Server busy, retry 1/10 in 26s...
API 通信完全打通，token 解密成功，状态查询正常。服务器限流是暂时的（大量自动签到脚本同时在跑），凌晨低峰期会成功。守护进程会在整点自动重试。
成果展示
最终交付物：
-
一个可直接运行的自动签到脚本包，适配 Trae CN 路径
-
一个不需要管理员权限的后台守护进程方案
-
一个开机自启的 VBS 启动器
这套系统的效果：每天自动签到 200 积分 × 31 天 = 6,200 积分/月，完全免费、完全自动。配合每月登录赠送 500 积分，月度固定收入约 6,700 积分。
效率对比
以前：每天要手动打开 TraeWork → 点击签到按钮 → 关掉。经常忘记，一个月漏签 10+ 天，损失 2,000+ 积分。
现在：完全无感。开机后后台自动跑，低峰期自动成功，日志写在本地文件里可随时查看。
经验和技巧总结
-
API 调试的关键是逐步加字段：先跑最简请求看报什么错，再从
storage.json里找可能的设备/用户标识逐个加到请求头里。9004→9074 的变化就是关键突破口 -
不需要管理员权限也能做定时任务：Windows 启动文件夹 + VBS 静默启动 + PowerShell 守护进程 = 完整替代 schtasks
-
服务器限流是正常的：大量用户同时跑签到脚本会导致 9074，凌晨低峰期自然解决，重试逻辑兜底即可