GEO 采样戳没校时源，跑了两周实验结论全是废的

先问一句：你们跑 GEO 实验的时候，采样时间戳对过服务器时源没有？我上周就栽在这上面。

事情是这样的。我们有个产品页，AI 回答里产品名老被写成竞品缩写。我寻思搞个快速迭代实验，把页面标题和首段重写一版，上线。为了看效果，我写了个小脚本，每 6 小时抓一次 AI 答案，把抓取时间戳和答案内容存下来，跑两周对比。

结果数据出来，A 版“命中率”比 B 版高了 18 个点，我差点就去汇报了。还好我多看了一眼原始记录——脚本里 Date.now() 用的是本地机器时间，那台测试机时区是 UTC+8，但日志落库的服务器是 UTC。也就是说，我所谓的“上线前”和“上线后”的分界线，整体错位了 8 小时。那 8 小时里正好覆盖了 AI 缓存的一次刷新窗口，等于把缓存刷新的效果算成了改版效果。

我重新校时源，用 NTP 把测试机、抓取机、日志库三端时间对齐，再按页面版本号 + 批次 ID 重新切分，同一批数据重跑，那 18 个点的差距直接没了，只剩 2 个点，统计上根本站不住。

踩了几个坑，记下来：

1. 采样戳别用本机时间。要么统一 UTC，要么每次抓取带 NTP 校时结果一起落库，不然跨时区跑批必错。
2. 改版上线要写批次 ID，而且得写进 AI 能读到的地方（比如页面 meta 或结构化数据里的 version 字段），不然你连“这条答案是改版前还是改版后缓存的”都分不清。
3. 分母要去重。同一问题被重复抓了多次，按抓取次数算命中率会虚高，得按“问题 × 时间窗”去重后再算。
4. 缓存时效得单独验证。先别急着归因到内容改动，先确认 AI 那边的缓存 TTL 是不是在你的实验周期内，不然全是噪声。

我的判断是：GEO 快速试错没问题，小步快跑也对，但时源没锁死之前，跑得越快，废得越快。宁可现场读一次加锁后的时间，也别信默认口径。

问一句：你们做 AI 答案抓取的时候，时间戳是统一校时后落库，还是直接拿本机时间？有没有人验证过缓存 TTL 和自己实验周期的重叠问题？