GEO分片跑批时区没对齐，单量直接差出四成，我拿两套快照对了一遍

先把结论放前面：GEO的内容质量做得好不好，很多时候不是问句库的问题，是分片跑批的时间口径没对齐。

上周做A/B，同一批内容、同一套问句，两个分片各跑一遍，结果B分片引用条数比A少了42%。我第一反应是内容质量参差，抽了40条问句人工比对，问句一模一样，回答也几乎一致。问题不在内容。

简单说，是分片跑批时每个节点取的时间戳不一样。A分片用UTC+0落库，B分片用的是本地时区UTC+8。同一个「今天」，B分片实际把前一天的尾巴算进来了，又漏了自己后半段的采样。

怎么发现的：我把两个分片同一批次的快照导出，按问句ID join，发现差出来的42%几乎全落在两个时间窗——本地0点到8点、以及20点到24点。这两个窗口恰好是跨时区重合区。我把快照的时间字段单独拉出来对了一遍，A分片全是T+0结尾，B分片是T+1开头，差一天。

这事跟内容质量没关系，是工程口径问题。但它在报表上的表现，特别像「内容质量下滑」，很容易让人去优化不该优化的东西。

怎么修，我这边定了三条：

第一，分片跑批统一用UTC+0作为批次基准时区，落库前必须做一次时区归一，别让各节点自己决定。

第二，批次ID里带上时区标记。我们现在的批次ID只有日期+毫秒戳，跨时区跑的时候根本区分不出来，出了问题只能靠人工比对快照。

第三，采样即赋时间戳，落盘只做校验，不改时间。这条是上次踩过坑留下的规矩，这次又验证了一遍——一旦落盘阶段还允许改时间，你后面所有归因都是假的。

顺带说个数据：修完之后重跑同一批，A/B分片引用条数差从42%收到3%以内，剩下的3%才轮得到内容质量去解释。

所以我的判断很直接：GEO技术门槛确实不高，谁来都能跑起来。但正因为低，跑批口径这种基本功反而最容易漏，而它一旦漏了，会伪装成内容质量问题，让你把预算花错地方。

想问问各位，你们分片跑批的时候，批次基准时区是放在节点侧还是统一在调度侧？跨时区那一段有没有人真的对过一次快照？