GEO试跑前我硬塞了张「分母口径卡」，三天后数据对上了

上周我又踩了个老坑：试跑数据第一天就打架。

事情不复杂。我们拿 50 条 query 做小样本试跑，三天迭代两版，目标是先看 AI 引用率有没有动静。结果第一天运营说引用率 18%，我拉后台日志一算只有 7%。差在哪？分母。运营用的是「AI 回答中带链接的条数」，我用的是「query 总量」。两个口径都没错，但混在一起就是灾难。

快速迭代的前提是口径不能迭代。 这是我这次最大的教训。

所以我做了张「分母口径卡」，试跑前必须填完，一页 A4，三个必填项：

1. 分母是谁：query 总量、去重后 query 量、还是有效回答条数？我们最后锁的是「去重后 query 量」，因为试跑阶段重复问句太多，不去重直接虚高。
2. 采样戳怎么校时：AI 回答的生成时间和日志落库时间经常差 2-5 分钟，跨小时就跨批次。我们统一按「回答生成时间」归档，日志时间只做审计。
3. 批次 ID 写入时机：这个最容易被忽略。我们一开始是跑完再写批次 ID，结果中途重跑的三条数据混进了上一批，分母直接多了 3 条。后来改成 query 入队时就写批次 ID，跑完再补状态，才断干净。

前置校验我也加了一步：先跑 5 条 query 的全链路，人工对一遍分母。 5 条对不上，50 条就是白跑。这一步花了 20 分钟，省了后面两天的扯皮。

三天迭代两版的结果是：第二版引用率从 7% 爬到 11%，涨幅不大，但这次运营和我的数终于能对上了。分母锁死之后，涨跌才有归因价值，不然你永远在解释「是不是口径变了」。

我的判断很简单：小步快跑不是跑得快就行，是每一步的尺子不能换。 试跑阶段最贵的不是算力，是口径反复。

问一句：你们试跑时批次 ID 是入队写还是跑完写？我见过两种都有坑，想听听别人怎么处理的。