跑批前别急着上量，我拿三张表把AI答案的「口径漂移」卡住了

上周跟一个做家电的朋友吃饭，他说他们团队上个月跑了 12 批 GEO 问句，结果 AI 答案里品牌推荐率从 18% 掉到 9%，一群人慌了，差点把投放全停掉。我让他把跑批日志拉出来，三张表一摆，问题不在策略，在口径。

第一件事：采样戳校时。 他们 12 批里有 3 批的取数时间戳是乱的——有一批判是凌晨 2 点抓的，但服务器时钟比标准时间快了 41 分钟。AI 答案里带「最新」「近期」这类词，时间一错，引用的就是前一天的缓存页。后来我们规定：跑批前先对 NTP，时间戳写进批次 ID，误差超过 5 分钟直接作废重跑。

第二件事：锁分母。 他们统计「品牌被提及率」时，分母一会儿是全部问句，一会儿是去掉空答案后的问句，两批数据混在一起算，能不跌吗？我的做法是跑批前先定死分母口径：总问句数、有效返回数、去重后品牌数，三个数写进表头，跑完谁都不许改。改口径可以，下一批重新起 ID。

第三件事：批次 ID 写入时机。 这个最容易被忽略。他们有一批是边跑边写 ID，结果中途断了一次，重跑的部分没换 ID，跟上一批搅在一起。我要求批次 ID 在跑批启动那一刻就生成并落盘，跟问句表一一对应，断点重跑必须新起一个子 ID。

这三件事做完，他们重跑了 5 批，推荐率稳定在 16%-19% 之间，之前那个 9% 纯粹是口径漂移闹的。快速迭代不是不校验，是校验前置，把试错成本压到最低。我现在的习惯是跑批前花 20 分钟过一遍检查清单：校时、锁分母、写 ID，缺一样就不上量。

你们团队跑批的时候，批次 ID 是在启动前生成还是跑完再补？我见过两种做法，想听听大家怎么处理的。