2026 年 7 月，我重新打开了 wps_script。仓库最早的一批提交停在 2023 年，此后只有几次零散更新。隔了这么久，当初觉得不必解释的细节都变得陌生：表格为什么这样排，哪些动作会改变账号状态，一段请求是后来改过的，还是从参考实现沿用下来的，都要重新从提交和文档里确认。
这段历史大致分成三截。2023 年加入早期脚本并形成聚合版本，2024 年有过一轮脚本与文档更新，直到 2026 年才集中整理 AirScript 适配、说明和测试。中间的空档没有必要修饰成持续维护。再次接手这样的仓库，我需要先回答三个问题：现有代码从哪里来，目前的测试能说明什么，哪些行为不该默认发生。
来源要和代码放在一起
7 月 25 日的提交先加入了初步 AirScript 适配。第二天继续整理时，daily.js、使用说明、模拟测试和第三方声明才一起进入仓库。来源说明补得不算早，但至少从这次维护开始，它不再只存在于记忆里。
这批脚本并非从空文件起步。原始 WPS 脚本基础包含“在虎”以 MIT 许可开放的部分，daily 参考实现也包含 Sitoi 以 MIT 许可开放的代码；2026 年这一轮主要完成 AirScript 适配、任务整理、文档和后续维护。固定提交中的 THIRD_PARTY_NOTICES.md 把这些关系集中记录了下来。
这样写清来源，不会削弱后续维护的价值。迁移运行时、补测试、整理旧代码、修正文档和接住以后出现的问题，都是实际工作；但它们不等于 13 项任务全部由一个人从零完成。提交历史断断续续，项目本身也是在开源基础上继续整理的一套个人工具。
先决定哪些事不该默认执行
签到脚本很容易用任务数量展示进度。每接通一个平台，README 和配置表就多一行；与此同时，仓库也多了一份凭据、一组接口、一种失败响应，以及一些会修改账号状态的动作。
固定提交纳入 13 项任务，同时明确排除 3 项。一个公开接口在复核时已经提示服务下线；一个流程依赖 AirScript 1.0 不具备的 AES-CBC，还涉及设备、定位参数和真实申购；另一个任务会写入伪造运动数据。这三项没有进入固定提交中的 daily.js，所以只能写成“未纳入”，不能倒过来说它们后来被删除。
已经纳入的任务也不会因为出现在列表里就自动执行。新建行默认关闭；投币、抽奖、兑换、观看上报和公开互动等动作，要由各自的显式配置放行。请求量较大的流程还限制页数、数量、重试次数或数据体积。聚合脚本只是把入口放到一起，并没有替这些外部行为取得授权。
六列表格是一份运行契约
脚本运行在金山文档里，配置落在六列单元格中：A 列是任务标识，B 列存放凭据或 JSON 配置，C 列决定是否执行，D 列是可选名称，E、F 两列记录最近结果与执行时间。
补测试以后，这张表显出了接口的轮廓。它有输入格式和默认值，也有升级约束：新任务必须默认关闭；重复运行 UPDATE.js 不能覆盖已经填写的 A-F 列内容；中间缺少某项任务时，可以补回任务标识，同时保留同一行已有的凭据、开关、名称、结果和时间。任务实际运行以后，成功与失败都要回写自己的 E、F 列，不能被最后一条汇总消息覆盖。
这些规则不如新增平台醒目，却直接决定一次升级会不会悄悄改掉原有配置。脚本处理的是账号凭据和外部行为，初始化默认值同样属于安全约束。把 C 列的新建值固定为“否”，比把风险留给一段使用说明更可靠。
AirScript 配置表 A-F 运行契约：A-D 列作为输入，C 列默认关闭，UPDATE.js 只补缺失单元格，任务逐项执行后将结果与时间回写 E-F 列
图：依据固定提交中的配置与测试整理的自制契约图，不含真实账号、凭据或执行结果。
模拟测试只覆盖本地契约
公开版本的固定基线是 609153c。8 月 9 日，我从这个提交导出隔离副本，对 daily.js 和 UPDATE.js 做语法检查，再运行模拟契约测试，13 项处理器全部通过。
测试提供了一个缩小的 AirScript 环境：只放入允许使用的全局对象，记录 HTTP 调用，把请求选项限定为 method、timeout、headers 和 body，并让同一个响应正文在第二次读取时立即失败。它还会模拟建表，检查新任务默认关闭、重复运行不覆盖旧单元格、缺项补齐，以及任务执行后的成功和失败能否分别回写。
这组测试能拦住两类本地问题。一类是代码在普通 JavaScript 环境中可以解析，放进 AirScript 却用了不受支持的对象或语法；另一类是表格升级、响应读取和状态回写破坏了既有契约。它无法登录真实账号，也无法固定十几个第三方平台以后的接口行为。
因此，这次验证的准确记录是“13 项模拟契约通过”。Cookie 是否过期、平台是否触发风控、活动入口是否撤下、返回字段是否改变，都不在它的覆盖范围内。以后排错时，本地语法与表格契约、外部请求、响应解析仍要分开记录，不能把所有情况压成同一句“任务失败”。
表格里的凭据仍是明文
这套脚本没有独立的密钥存储。Cookie、刷新令牌和密码填进配置表以后，仍然是单元格里的明文。示例代码可以不带真实值，却改变不了文档分享权限决定可见范围这一事实。
它更适合个人、低频、明确授权的自动化，不适合用共享表格为多人隔离凭据。凭据应当可以撤销，文档权限也要尽量缩小。错误回写只需保留任务、阶段和收敛后的原因，不该把完整请求头或原始响应复制进单元格和截图。
C 列为“是”且处理器实际运行后，E、F 才会写入本次结果和执行时间；关闭的任务会直接跳过，不更新这两列。关闭行里残留的旧状态，只能说明上一次执行结果，不能证明当天运行过。推送适合汇总一次执行，逐任务状态仍要回到配置表判断。
2.0 迁移仍在本地
截至 2026 年 8 月 9 日的复核，固定提交 609153c 仍以 AirScript 1.0 为公开基线。2.0 迁移已经形成一组本地候选，改动分散在工作表 API、编码能力和通知方式上。
候选代码把单元格写入从 Value 调整为 Value2；创建工作表改成无参数 Sheets.Add() 后再设置名称；原脚本依赖的 Node 风格 Crypto 和 Buffer 被纯 JavaScript 的 MD5、UTF-8 与 Base64 实现替代；由于 2.0 没有 SMTP，邮件分支会明确报错，并要求关闭 email 推送。
本地候选通过了同一组 13 项模拟测试，有赞库存候选也通过了自己的测试。它们当时仍是未提交文件，不能据此描述公开 main 已经完成迁移。测试只回答这些候选字节在 mock 环境中的行为，公开仓库能够取得的还是 1.0 基线。
文档和代码没有处在同一个版本
8 月 9 日复核时，在线文档已经采用 AirScript 2.0 口径，也出现了有赞库存脚本教程；公开脚本仓库仍停在 1.0，教程指向的源码文件并不存在。教程页面返回 200，跨仓库源码链接却返回 404。
这个断点来自自己的发布流程，与第三方接口无关。本地同时放着代码、测试和文档时，“文件都写完了”很容易被误认成“已经发布”。公开结果要以远端提交为准：文档页面能打开，只证明文档服务正常，无法替代源码可取得性，也不能把本地测试结果算到远端版本上。
跨仓库发布至少要同时核对脚本仓库 HEAD、文档采用的运行时口径、页面里的源码链接，以及从远端提交重新导出的测试结果。任何一项没有对齐，说明和实际可下载的代码就不属于同一版本。
先把版本重新对齐
这次重整可以确认几件事：固定提交中的 13 项处理器通过了模拟契约，配置表的默认关闭、重复运行和逐任务回写都有测试保护，第三方来源与当前维护的关系也已经写明。与此同时，2.0 迁移在复核时仍停在本地候选，公开代码与在线文档没有对齐。
现有材料没有证明真实账号长期稳定运行，也没有证明无人值守。第三方接口仍要按失败阶段记录，涉及账号资产或公开互动的动作继续由独立开关控制。任务数量、测试数字和能够访问的文档页面，各自只能说明一小部分状态。
下一次继续维护前，先让 wps_script 与 wps_docs 回到同一基线，再从新的远端提交导出隔离副本重跑测试。等代码、说明、链接和测试结果能够对应到同一版本，再讨论增加新的任务会更踏实。