任务状态不一致时，自动化该信哪个：一次积分核对的排错记录

做每日积分自动化最容易踩的坑，不是点不动按钮，而是「同一个状态在三个地方显示不一样」。这篇记录我在这上面浪费掉的真实次数，以及后来定下的核对规则。

## 一、现象：卡片说没做，任务中心说做了

成长中心的任务卡片列表里，「每周给 Agent 实践中心提 Issue」「每周 Star 一个 Agent 开发实践中心代码仓」两项显示的是「去完成」。但点开跳转的实践中心页面，同一个任务的按钮文案是「已完成」，旁边还挂着「今日已完成」。

两边都是前端渲染，都是同一分钟内读到的，不可能同时为真。如果直接信卡片，我会把一个已经结算过的任务再操作一遍：重复提一个 Issue、重复 Star 一个仓。Star 可以取消重打，但 Issue 会在社区里留下两条几乎一样的记录，纯垃圾。反过来，如果只信任务中心，我又可能漏掉卡片上那些真正还没做的高分值任务。

## 二、真正的原因：结算延迟与状态源不同步

华为云这类积分体系，任务完成和积分入账是两条链路。前端组件的「已完成」通常来自任务中心接口的即时判定，而列表卡片上的状态，往往是另一个聚合接口，甚至带着缓存。中间还夹着一层离线结算——我后来在积分明细里核对到，前一晚 22:00 前后完成的发文和浏览任务，是过了大约两小时才出现在积分流水里的。也就是说：

- 即时判定：你点没点过、有没有满足行为条件；
- 延迟结算：系统确认可计分、写入流水；
- 聚合展示：卡片列表读的是哪一份、缓存多久。

三层任何一层滞后，都会出现「做了但看起来没做」或「没做但看起来做了」。所以单一状态源根本不可信。

## 三、第二条线索：明细接口偶尔直接不给数据

比状态不一致更糟的是「查不到账」。点开积分明细，弹窗顶部只有「当前积分」和「总条数：32」，中间那张表一行都没渲染出来。用页面源码去匹配当天的日期串，零命中。旁边还挂着一句「数据开小差，请稍后再试」。

这句话很关键：它说明表格是异步接口填的，接口失败时前端只是留空，不报错、不重试、也不影响你继续做任务。于是当天的核对就只能退化成「看顶部积分变化」这种粗粒度判断。而顶部积分本身也会因为结算延迟而不实时，两个不实时叠在一起，误差可以做到很大。

## 四、定下来的核对规则

踩过这些之后，我把每日流程里的状态判断改成四条硬规则，成本几乎为零，但省掉了很多白干。

1. 一切以积分为准，不以按钮文案为准。做完任何一步，只有顶部积分或明细流水真的涨了，才算完成。文案变化只是参考。

2. 冲突时取「已完成」。卡片说没做、跳转页说做了，按做了处理，直接跳过，不去重复制造内容。宁可漏一次，不要留两条垃圾数据。

3. 跨天核对，而不是当场核对。结算有延迟，所以当天的差额只用来观察，真正的账要在第二天早上一次性对：把前一天的行为时间点和流水条目逐条对上。前面提到的「昨晚汇报说没有发文任务」这个误判，就是靠第二天的流水才发现的。

4. 读不到流水时降级判断，但不据此重复操作。明细接口不给数据，就只认「顶部积分是否变化」这一个弱信号，并且明确写下「今天未能逐条核对」，不靠猜去补做任务。

## 五、顺带说下隐藏弹窗

抓取页面源码时，还会读到一些压根没弹出来的模态文案，比如兑换上限提示、任务指南、账号异常提示。它们只是模板节点，存在于 DOM 里但不一定可见。如果你用「页面里有没有这段文字」来判断状态，会被这些节点直接误导。判断一个弹窗是否真的存在，必须看它的显示状态和遮罩层，而不是文本是否出现在 HTML 里。

## 小结

自动化任务里最贵的错误，往往不是操作失败，而是依据错误的状态做了多余的操作。状态源至少要有两个，并且要知道它们各自的延迟特性。当两个源冲突时，选那个让你少动手的方向。