试错跑太快，实验组和对照组的分母根本不是同一批人

上周刚踩了个坑，直接说结论：快速迭代没问题，但每次试错前必须先把实验组和对照组的分母口径锁死，不然跑得越快错得越离谱。

事情是这样的。我们上周跑了一轮 GEO 问句库的 A/B 试错，两周做了三轮，节奏拉满。第一轮跑完看数据，实验组引用率比对照组高了 11 个点，团队直接嗨了，准备全量铺。我当时多嘴问了一句：分母是什么？

结果一查，实验组的分母是「近 7 天内有 AI 曝光的问题数」，对照组的分母是「问句库里的总问题数」。这两拨人根本不是同一批——实验组把已经死掉、从没被 AI 触达的问题全剔掉了，分母天然小一圈，引用率当然虚高。

更坑的是采样时间戳。实验组的数据是周一上午拉的，对照组是周三下午拉的，中间隔了一轮索引更新。AI 那边引用池的刷新节奏是啥，我们根本没校。等于说两个组不仅分母口径不同，连时源都不一致，这实验结论基本作废。

我后来复盘了一下，问题出在试错流程上。为了快，我们把「拉数」这个环节交给了两个不同的人做，一个用 BI 看板，一个直接写 SQL，默认口径各按各的理解来。快速迭代最怕的就是这个——快在实验设计上，不能快在口径上。

所以现在我们定了个死规矩，每次试错开跑前花 10 分钟锁三件事：

1. 分母锁定：实验组和对照组的分母必须是同一套问题池、同一套去重规则，谁改分母谁写说明。
2. 时源锁定：两组数据必须落在同一个采样窗口内，跨窗口的直接标「不可比」。
3. 批次 ID 写入时机：实验组的问题打标必须在曝光前写入，不能事后补，不然归因全是扯淡。

这 10 分钟看着拖节奏，但比跑三轮全废省太多了。上周那轮重跑之后，真实提升只有 3 个点，跟 11 个点差了十万八千里——要是没查口径直接全量铺，资源就打水漂了。

顺便提一句，最近看竞品报告也发现类似毛病，他们给的「引用率提升」我拆了分母，发现是按「有引用的问题数」算的，不是按「总问题数」，口径一换数字立马缩水。所以看别人报告也别急着信，先问分母。

你们跑试错的时候，实验组和对照组的采样时源是怎么对齐的？有没有那种「快是快，但两组数据压根不在同一时间窗」的情况？