网页任务自动化的结果核验：状态、流水与安全边界

网页自动化最容易出现的误判，不是按钮没有点到，而是按钮已经点到，脚本就宣布业务完成。保存、发布、报名和积分入账往往是不同阶段：页面可能先显示请求已提交，后台随后校验，最终结果还需要审核或异步处理。

本文给出一种不依赖特定平台内部接口的核验方法：把操作记录、业务状态和结果流水分开处理，并为等待与人工确认保留独立状态。

一、先定义“完成”，再编排点击

开始自动化之前，先用一句话描述验收标准。例如，“提交报名表”与“收到报名成功确认”不是同一个目标；“打开体验页面”与“平台记录体验任务完成”也不能混为一谈。

对于带奖励的任务，建议至少记录以下证据：

• 当前账号是否与授权账号一致。
• 任务页面是否明确显示完成，而不只是按钮点击成功。
• 对应任务的结果流水是否出现，以及数值是否匹配。
• 记录对应的任务标识、时间和周期是否正确。

操作日志只能证明脚本做过什么，不能独立证明平台已经认可这个结果。

二、把“等待入账”与“失败”分开

可以将过程划分为五种状态：待执行、执行中、等待确认、已核验、需人工处理。一个任务已经提交，却仍在审核中时，应停留在“等待确认”，而不是立即重试，更不应在汇总报告中算作已经到账。

总余额增加也不一定能归因到当前任务。其他签到、历史奖励或兑换操作可能同时改变余额。应优先核对与任务对应的流水，余额差额只作为辅助证据。

下面是一个简化的、与具体平台无关的判定函数。输入数据应来自已经读取的页面和对应流水，而不是由脚本自行编造。

from dataclasses import dataclass
from typing import Optional


@dataclass(frozen=True)
class TaskEvidence:
    account_matches: bool
    task_completed: bool
    expected_points: int
    credited_points: Optional[int]


def verify_result(evidence: TaskEvidence) -> str:
    if evidence.expected_points <= 0:
        raise ValueError("expected_points must be positive")
    if evidence.credited_points is not None and evidence.credited_points < 0:
        raise ValueError("credited_points must not be negative")
    if not evidence.account_matches:
        return "blocked"
    if not evidence.task_completed:
        if evidence.credited_points not in (None, 0):
            return "needs_review"
        return "pending"
    if evidence.credited_points is None:
        return "waiting_for_ledger"
    if evidence.credited_points != evidence.expected_points:
        return "needs_review"
    return "verified"


evidence = TaskEvidence(
    account_matches=True,
    task_completed=True,
    expected_points=30,
    credited_points=30,
)
print(verify_result(evidence))

这段示例应输出 verified。其中，None 表示尚未取得对应流水，不等于已经确认没有奖励；0 表示取得的对应记录数值为零。生产实现还应分别保存查询是否成功、流水标识、任务周期和服务端时间，避免将“查询失败”误当作“没有流水”。

该函数只是业务判定示例，不是任何平台的官方接口，也不能代替真实任务操作。

三、在容易产生副作用的位置设置边界

浏览、公开发布、账号绑定和购买资源的风险并不相同。执行器应在动作之前识别副作用，而不是等错误发生后再提醒用户。

• 公开发布前确认内容不含 Cookie、登录票据、密钥、手机号或内部地址。
• 账号绑定时检查目标用户名，第三方数据共享应根据页面实际范围单独判断。
• 学习实验尽量使用平台分配的沙箱账号，不要混用个人生产账号。
• 免费体验与额度计费版本分别处理，不能因为有赠送额度就假设没有后续成本。
• 临时资源使用后应释放，并保存退出或清理确认，不把关闭浏览器标签当成资源已释放。

对于人脸验证、短信确认或需要本人完成的考试，应保留人工步骤。自动化负责流程辅助，不应该替代身份主体，也不应该伪造通过记录。

四、重试之前，先判断动作能否重复

页面超时不代表提交失败。遇到保存或发布超时，先读取记录列表或结果页面，确认是否已经生成记录，再决定是否重试。

对允许重试的读取操作，可以设置有限次数和退避间隔；对发布、报名、兑换等可能产生重复结果的动作，则应检查业务标识、标题、提交时间或已存在记录。没有幂等保障时，不要无限重复提交。

五、用可核查的汇总结束流程

最终报告最好将结果分成三组：

1. 已完成且证据一致：有明确完成状态，并取得对应结果记录。
2. 已提交但待确认：等待审核、他人采纳、赛事评审或异步入账。
3. 未完成：需要本人验证、缺少授权、资源不满足或操作失败。

只汇总第一组中已经确认的奖励；第二组可以列出预期规则，但不能把预期值当成实际收益。对于“建议被采纳”“作品晋级”这类取决于第三方判断的结果，更不能通过多点几次按钮来承诺完成。

可靠的网页自动化，不是让脚本尽可能快地结束，而是让每一个“已完成”都对应可以复查的证据。

本文为 AI 辅助原创整理。代码为独立教学示例，不涉及任何平台未公开接口，不承诺奖励规则或审核结果。