自动化任务的关键不是一键执行，而是可验证的闭环

很多自动化任务看起来只需要一个脚本：登录、调用接口、提交结果，然后等待积分或状态变化。真正容易出错的地方，却是最后一步：命令成功，并不等于业务完成。

一、先区分三种状态

第一种是请求成功：接口返回 200，或者页面提示提交成功。它只能说明请求被服务端接收。

第二种是业务完成：目标对象真的创建、更新或发布，页面可以重新读取到结果。

第三种是权益到账：积分、优惠券或任务状态已经出现在官方明细中。它通常还会经过异步审核和同步，不能用前两种状态推断。

二、为什么自动化容易误判

常见问题包括账号切换后仍复用旧状态、重复提交造成幂等冲突、页面缓存没有刷新，以及只记录了本地日志而没有保存服务端证据。尤其是多账号场景，任务文件、凭据和浏览器登录必须按账号隔离，否则很容易把一个账号的完成结果写到另一个账号。

三、我采用的验收顺序

1. 先读取当前页面，确认账号、日期、任务状态和余额。
2. 执行前检查当天是否已有尝试记录，避免重复请求。
3. 提交后重新读取业务页面，而不是只看命令退出码。
4. 最后查看官方积分明细或对象详情，记录时间、账号和结果。
5. 对于公开文章、Issue、报名等动作，保留人工确认，避免脚本替用户作出不可逆的公开承诺。

四、可复用的最小模板

任何自动化任务都可以拆成“准备、执行、回读、核验、记录”五步。准备阶段保存目标和账号指纹；执行阶段使用幂等键；回读阶段重新查询服务端；核验阶段检查最终业务结果；记录阶段只保存脱敏证据。

这样做会让脚本少一点“看起来完成”的假象，多一点真正可恢复、可审计的结果。自动化的价值不是把点击次数降到零，而是让每次操作都能解释、复现和验证。