从余额到流水：用Python核对每日收入、兑换支出与周期奖励

积分、优惠额度和活动奖励经常被压缩成一个“当前余额”。但余额无法单独回答今天赚了多少、哪个任务漏发、兑换扣了多少。做自动化对账时，先保留逐笔流水，再计算各类统计，比从余额差反推业务完成更可靠。

1. 一个余额为零的例子

假设账户期初有 1990 分，当天签到收入 10 分，随后兑换支出 2000 分，期末余额是 0。当天收入仍是 10 分，净变化才是 -1990 分。如果把“余额为零”显示成“今日收入为零”，就会误判签到漏发。这里的数值仅是演算示例。

账本至少应保留交易 ID、原始时间、方向、金额、明细名称和交易后余额。收入和支出先分别累加，再计算净额；不要让兑换记录参与“每日任务收入”的统计。

2. 无时区字符串必须先核实含义

2026-11-04 16:00:00 没有说明时区。它可能是 UTC，也可能是服务端本地时间。只有将接口原始时间与页面显示、服务文档或另一条可靠时间线对照后，才能决定怎样解释。不能因为业务位于中国，就直接将原始字符串当成北京时间。

如果已经核实接口使用 UTC，可以这样转换后再判断归属日期：

from datetime import datetime, timezone, timedelta

beijing = timezone(timedelta(hours=8))
raw = datetime.strptime("2026-11-04 16:00:00", "%Y-%m-%d %H:%M:%S")
local = raw.replace(tzinfo=timezone.utc).astimezone(beijing)
assert local.date().isoformat() == "2026-11-05"

replace(tzinfo=...) 是给一个已经明确含义的无时区时间附上时区，不会移动钟面时间；astimezone 才执行转换。顺序弄反，会把午夜附近交易划入错误日期。

3. 同时保存“入账日期”和“奖励类型”

某个周任务在周二入账，它既属于周二发生的收入，也属于周任务奖励。两种维度不能混用。可以按北京时间日期汇总四类收入：每日任务、每周任务、每月任务、其他；再单独记录当天支出和净变化。

“今日周任务收入 0”与“本周周任务累计 50”可以同时成立。同理，本月累计 200 并不意味着今天收入 200。报表字段应明确写成 today.WEEKLY 和 weekly_totals[week]，不要让一个含糊的 weekly 字段承载两种意义。

按入账时间汇总的“本周累计”还有一个边界：它不一定等于业务任务所属周。如果平台延迟发放上周奖励，而流水没有任务周期字段，就应说明这是入账周统计，不能擅自推断奖励归属周期。

4. 分页抓取也需要一致性检查

第一页可能只返回最近十笔。如果只统计第一页，月初或发生大量交易时就容易漏算。抓取所有页后，应检查总条数、交易 ID 唯一性和账号标识。每页报告的总条数若在抓取过程中变化，说明读取期间可能有新交易，应重做快照，不能把半新半旧的数据直接当成完整账本。

即使条数稳定，也不能证明内容绝对不变。能使用服务端游标或快照版本时优先使用；只有普通分页时，可再比较首尾边界或后续重新对账。保留原始流水，才能追查后来发生的补发、撤销和修正。

5. 历史常见收入不等于正常收入

如果一个脚本连续两周只完成签到，历史众数会稳定在签到分值。这个数字可以叫“历史常见收入”，不能叫“全部任务完成的正常基线”。建立完整基线，应挑出每个必需任务都有对应入账、金额与当日规则吻合的日期，再要求足够多的完整样本。

规则也可能变更。今天新增了任务，用今天的规则倒查一个月前的记录，会使完整样本变少。这时应保留“样本不足”，或者采用带生效日期的规则版本；不要为了给报表填一个数字而退回使用不完整历史日。

6. 让语言模型解释异常，让账本负责数字

语言模型适合整理漏项原因、关联错误日志和提出排查建议，但日报金额应由确定性代码生成。模型读取多层统计时，可能把月累计当成今日收入。可将已验证的今日分账与周期累计作为不同对象传入，并校验结构化返回；最终对外摘要中的金额始终取账本字段。

最小回归用例应覆盖北京时间午夜、跨年 ISO 周、当天兑换、延迟入账以及“本月有收入但今日月收入为零”。这些边界比只检查一个总和更能发现报表中的错账。