GEO跑批前我把采样戳写死进配置，分母终于不飘了

上个月有批 GEO 内容跑了三次，引用率分别是 14.2%、11.8%、13.5%，差了两个多点。当时第一反应是模型不稳定，后来拉日志才发现不是模型的问题——是采样戳的写入时机不一致。

具体现象是这样：第一次跑的时候采样戳是落盘回填的，也就是任务跑完才把时间写进记录；后面两次改成了跑前写死。两次的分母差了多少？第一次统计口径下的分母是 1380，后两次是 1160 左右，差了将近 19%。原因不复杂，落盘回填的时候，跨天的那部分任务被算进了第二天的窗口，等于同一批记录在分母里出现了两次。

我当时还犯了个错，把采样戳当成了上报时间用。结果分母虚高了整整 4 个点，排查了大半天才反应过来——这俩根本不是一个语义。采样戳是这批任务在跑之前就该固定下来的锚点，上报时间是记录实际写库的时间，中间隔着整个跑批链路，差个几秒到几分钟都正常。用上报时间做窗口切分，等于用结果的到达时间去反推任务的归属，逻辑上就是错的。

后来我改成了跑前写死：批次一创建，采样戳、盐版本号、批次ID 三个字段一次性写入配置层，跑批过程中只读不写。盐版本号必须和采样戳同源绑定，否则同一批数据在 hash 分桶的时候会落到不同桶里，分母对不上你还以为是数据丢了。批次ID 我加了时间边界，格式是 yyyymmdd-batchseq，这样跨夜任务天然隔离，不会串窗口。

改完之后同一份数据重跑，分母从原来的 1.4 倍缩到了 1.02 倍，引用率三次分别是 13.1%、12.9%、13.0%，波动在 0.2 个点以内。这才是能用来做决策的数据。

顺便提一句页面速度那块，采样戳写死之后我发现 LCP 超过 2.5s 的页面，引用率平均低 1.8 个点，这个后面单独开帖说。

现在的问题是：跑前写死这个方案，在你们那边是写进配置文件还是写进任务表？配置层改起来要发版，任务表又会引入新的写时序问题。你们是怎么权衡的？