GEO试跑只跑一组样，难怪你后面归因全崩

上周帮一个做SaaS的哥们看GEO试点数据，他上来就跟我聊归因模型，我说你先打住，样本怎么采的？他发了张表过来，我一看血压就上来了——同一个问句，只在周三下午跑了一轮，跑了20条，就敢拿去跟老板汇报「AI推荐带来XX%新客」。

快速迭代的前提是样本能对账，不是跑得快。

我自己踩过的坑：去年Q4有个项目，为了赶双周迭代，AI答案采样只跑了一轮，结果第二周复盘发现推荐率从18%掉到6%。我以为是内容被吃了，查了半天，最后发现是采样戳集中在同一时段，AI那会儿刚好在换索引批次，整批答案跟别的时段不是一个口径。白折腾三天。

从那之后我定死一条规矩：任何GEO试跑，先跑三组小样再上量。

三组怎么分，我的做法很土但管用：

1. 时间分三档：早、中、晚各采一轮，每轮不用多，15-20条够看趋势。AI答案的时段波动比你想的大，尤其涉及实时信息的问句。
2. 批次ID前置写入：采样脚本里第一时间把批次号、时间戳、模型版本写进日志，别等数据落地了再补。补的时候你会发现字段对不上，对不上的数据就是废数据。
3. 分母先锁死：三组小样跑完，先别急着算推荐率，先确认三组的问句分母是不是同一套。我见过太多人三组分母悄悄差了几条，转化率算出来差一个量级。

三组小样跑完，如果趋势一致，再上量到几百条；如果三组打架，先别上量，回去查是不是口径没锁住。这一步多花半天，能省掉后面三天的归因扯皮。

说白了，GEO快速试错不是「跑得糙」，是「跑得小但跑得准」。小步快跑的核心在小步，步子迈大了，数据就散架了。

你们试跑阶段一般跑几组小样？有没有人试过按「AI索引更新周期」来切采样窗口的，我最近想验证这个，求个现成的经验。