跑批日志里那串毫秒戳，我让前端先改成"下单时间"才敢接

先说结论：GEO 批任务里的时间戳，别用服务器本地时间去赋，用业务事件时间。这个坑我踩了三天，今天才敢写出来。

背景是这样。我们给一个做工业配件的客户跑 GEO 问答批任务，问句是从他们 CRM 里导的，每条带一个「询盘创建时间」。采样器落盘的时候，我图省事，直接 timestamp = now() 打服务器时间。结果做「有效问答」口径核算的时候，分母比 CRM 里导出的条数多了大概 8%。

一开始我以为是去重没做好，查了一下午。后来把原始日志导出来按秒对齐，才发现问题：跨夜那批，服务器时钟和 CRM 事件时间差了将近两个小时，中间还夹着一个夏令时的边界。也就是说，部分问句在「业务日期」和「跑批日期」上被算了两遍。

我要努力学习，但光努力不够，得较真。

我的处理方式分三步：

1. 时间戳来源只认业务事件时间。采样时就把 CRM 那条 inquiry_created_at 写进 payload，落盘只做校验，不用 now() 覆盖。前端那边我让他们先把字段名从 ts 改成 biz_ts，逼着大家看清楚这是业务时间，不是机器时间。

1. 批次 ID 里嵌时间维度，但只到「日」。之前我们批次 ID 用的是毫秒戳，跨夜直接裂成两个批次，分母自然对不上。现在改成 biz_date + seq，跨夜批次合并到一个逻辑批里，核算时再按事件日期拆。

1. 加一个分母对账脚本。每天跑完，拿「采样落盘条数」对比「CRM 当日询盘数」，差值超过 2% 就告警。这个脚本很土，就一百来行，但救了我两次。

顺带说一个细节：客户 IT 那边的 NTP 源是单点的，上周还抖过一次。所以我现在不敢完全信服务器时间，业务事件时间才是锚。

这些做完之后，分母从虚高 8% 降到了 1.2% 以内，客户那边总算认了这个口径。

但我心里还有一个坎没过去：如果业务事件时间本身也是前端补录的、可能被人改过，那这个锚到底还算不算锚？你们跑批的时候，是拿事件时间做分母，还是拿入库时间做分母？有没有人遇到过补录把时间改乱的情况？