fix(qdreader): restore upstream adv task flow

2026-05-22 00:55:22 +08:00
parent d2a7e49ec5
commit fc4b3bc587
4 changed files with 34 additions and 116 deletions
@@ -695,9 +695,8 @@ QDReader 签到结果判定补充：

 - `今日已签到`、`重复签到`、`已领取`、`已完成`、`无可领取礼包` 等幂等提示应视为成功类，不应让账号失败。
 - 激励任务 `finishWatch` 的 `Result/result = 9` 是上游可接受状态，要继续回查完成状态，而不是直接失败。
- 激励任务不要只对每个任务 `finishWatch` 一次；如果上游任务体带 `NeedCount` / `Count` / `Times` 等次数字段（例如“激励碎片”），应按次数重复提交同一个 `TaskId`，再回查 `mainPage`。
- 每日任务的原版链路是 `packagelist` 后先处理惊喜/前置任务，再处理“完成1个广告任务”，最后对标题为“每日任务”的目标按次数（通常 3 次）执行 `finishWatch`；不能只提交每日任务本身一次或跳过前置广告任务。
- 回查完成状态时要优先校验本轮提交的具体 `TaskId`，不能因为其它旧任务已完成就把当前任务判定为成功。
+- BOSS 明确要求 QDReader 激励任务“依照原项目，不做我以为的逻辑修改”。原项目的激励任务控制流是：读取 `VideoRewardTab.TaskList`；如果最后一项 `IsFinished === 1` 直接完成；否则遍历所有未完成且有 `TaskId` 的列表项，每项提交一次 `/argus/api/v1/video/adv/finishWatch`；最后再回查 `mainPage`，仍以回查后列表最后一项 `IsFinished === 1` 作为完成判断。
+- 因此不要在激励任务里加入本地推测过滤，例如跳过“每日签到/其它入口任务”、只校验本轮提交的 TaskId、按 `NeedCount - Count` 计算剩余次数、或者输出“跳过 N 个需其它入口任务”。这些看起来更严格/更安全，但已经被现场结果证明会和原项目语义偏离，导致误判未完成。
 - 可选任务如果被签名网关返回 `url 不在允许的接口列表内`，应标记为跳过 `⏭`，不要污染基础签到成功率。
 - 大咖荐书必须用 base62 token，并带 `senderId` 拉取具体会话；单次 `pullmessage` 或十进制 token 容易导致“参数错误”。