试跑批次ID写晚两周，白烧了四万预算，现在我把校验卡在跑批前

上个月试跑了一组GEO问句，跑批的时候没把批次ID写进采集埋点，结果两周后想按批次拆分母，发现数据全混在一起，四万预算直接白烧。

复盘下来就一个结论：批次ID必须前置到跑批启动之前，而不是跑完再补。

我的具体操作现在是这样：

1. 跑批前锁字段：批次ID、采样戳、分母口径三个字段，必须在跑批工单里写死。少一个字段，跑批工具直接拒绝启动——我让开发给跑批脚本加了个硬校验，缺字段直接报错，不给你“先跑起来再补”的机会。

1. 跑批前算一遍成本：不是算总预算，是算“这批数据如果分母脏了，重跑要多少钱”。我现在的规矩是，重跑成本超过首批预算30%的批次，一律先跑小样本（200条问句）验证口径，再放全量。快速迭代的前提是别把迭代成本叠成复利。

1. 采样戳校时放在跑批前：之前吃过亏，服务器时间和采集端差了8分钟，晚高峰的样本被归到平峰。现在跑批前先跑一遍校时脚本，时间差超过30秒直接停，先修再跑。

1. 分母去重放在入库前：不是跑完再dedup，是采集端入库前就按问句指纹去重。我踩过的坑是同一问句被不同入口触发多次，分母膨胀了1.7倍，归因全歪。

这套卡完，单批次试跑的准备时间从半天拉长到一天，但重跑率从40%降到了8%。快速迭代不是不校验，是把校验塞进流程里，一次做对。

想问下各位：你们跑批前有没有硬性的字段校验机制？还是靠人肉 checklist 兜底？我这边是脚本卡死，但小团队可能没这个开发资源，想听听你们怎么处理的。