跑批前校时我卡了三次，最后一次发现是机器时钟慢了两秒

先说结论：跑批前校准 + 锁分母 + 写批次ID，三件事缺一件，实验就白跑。

上周做GEO引用率的小步快跑实验，本来想一天出结论，结果光前置校验就卡了三次。今天把坑拆开讲，省得你们再踩。

坑一：采样戳和日志时间对不上

我拉了两个平台答案的引用数据，按照「时间戳」对齐，结果发现A平台引用率18%，B平台26%。第一反应是口径问题，后来查日志发现：采样工具写的是本地时间，日志是UTC。差了8个小时，正好错开一个高峰时段。

快速迭代的前提是数据能对得上，所以我现在跑批前第一件事——ntpdate -q 校时，把机器时钟跟时间源对一遍。别嫌土，最后一次卡住，就是某台采集机时钟慢了两秒，批次ID全乱序了。

坑二：分母没锁，去重规则前后不一致

这次实验我用了三组问句，每组20条，一共60条。但分母到底算「问句数」还是「曝光次数」？

• 按问句数：引用率 = 被引用的问句数 / 总问句数
• 按曝光：同一条问句被AI展示5次，算5次分母

我一开始混着用了，后来发现两个口径差了1.8倍。所以跑批前必须把分母口径写死在配置里，别靠人记。我现在直接建个 denominator_lock 字段，跑批脚本读这个字段，谁改谁负责。

坑三：批次ID写入时机太晚

最开始是跑完批再回写批次ID，结果中间有一台机器断网重跑，重复写入了同一批数据。现在我把批次ID写进请求头，落库前先查重，重复的直接丢。 小步快跑不是乱跑，是每步都可追溯。

怎么改的

我把跑批前置校验拆成了三步，每步不超过5分钟：

1. 校时：所有采集机跟时间源对一遍，误差超过500ms就报警
2. 锁分母：配置文件里写死分母口径 + 去重规则，生成hash存下来
3. 写批次ID：请求头带批次ID + 机器编号，落库前查重

跑通这套之后，同样的实验我重复了三次，引用率方差从8%降到1.2%。数据能复现，迭代才有意义。

抛个问题

你们跑GEO实验的时候，批次ID是在请求前写还是落库后写？有没有遇到过因为机器时钟漂移导致批次串号的？我这边现在靠校时+查重兜底，但总觉得还有更轻量的方案，求个思路。