试跑前我加了一道「口径快照」检查，省了三版词库返工

上周做第 11 轮 GEO 试跑，前 10 轮里有 4 轮是白跑的——不是词库不行，是跑之前口径就没锁死。

最疼的一次：采样戳没校时，跑完才发现抓的是前一天的缓存，分母里混进了 17% 的旧页面。两版词库直接作废，重跑又是两天。

从那以后我给自己定了个死规矩：每次上量前，先花 20 分钟做一道「口径快照」前置校验，不过不许跑。 就四步，全是笨办法：

1. 采样戳对时
拉一条最小样本（我一般 30 条），把返回里的时间戳跟本地时间逐条对，偏差超过 5 分钟就停。别信面板上的「实时」，实测过两次面板显示正常、底层戳是旧的。

2. 分母去重规则写死
同一个问句被两个渠道各抓一次，算 1 还是算 2？我踩过坑：没写死的时候，两个人取同一批数据算出差 9 个点的引用率。现在校验脚本里第一行就是去重口径，跑批日志里必须打印出来。

3. 批次 ID 写入时机
这个最隐蔽。批次 ID 是在请求发出时写、还是返回落地时写？两种写法差出来的数据能对不上账。我现在的做法是请求侧先写死批次 ID，落地再补一次校验，对不上就整批标脏。

4. 首屏 30 条人工抽检
自动校验只能查格式，查不出语义漂移。固定抽 30 条人眼看一遍，重点看品牌提及有没有被截断、问句有没有被改写。

这套跑下来单次多花 20 分钟，但上量后返工率从 40% 压到了大概 10%。对做快速迭代的人来说，返工才是最贵的时间——快速迭代不是省掉校验，是把校验做小、做在前面。

顺带说个判断依据：我现在看试跑数据，第一眼看的是「这批的口径跟上一批是不是同一套」，不一致的话数据再好看也不进归因，直接重跑。

问一句：你们试跑前有没有类似的固定检查清单？尤其是采样戳这块，除了对时还有没有更省事的办法？