跑GEO批任务前，我让团队先把"问句ID"的生成规则写进需求文档

上周跟技术对齐新一版GEO批任务的表结构，聊到复合键的时候卡住了。

起因是我们后台跑出来的线索数跟CRM对不上，差了19条。我一开始以为是老问题——采样戳和落盘戳没对齐，或者环境变量没关。结果查了两天，发现根子在复合键：批次ID + 问句ID + 内容哈希，这三个字段拼起来做主键。

问题就在"问句ID"上。

我们技术最初的写法是：问句ID = hash(问句文本)，全局唯一，跟批次无关。听起来很合理对吧？同一句问句不管在哪一批，ID都一样，方便做跨批次对比。

但我拿自家数据一跑就发现不对了。同一句问句在两个批次里进了两个不同的模型，一个用gpt-4o，一个用我们自研的小模型，返回的引用源完全不一样。可因为问句ID一样，落库的时候被当成同一条记录覆盖了。也就是说，我少算了整整一个批次的曝光。

后来我让他们改成：问句ID = hash(批次ID + 问句文本)。批次一变，问句ID就变。跨批次对比靠问句文本字段去做，别指望主键。

改完之后重跑，之前那批虚高的数据掉了——不是掉了19条，是掉了31条。因为还有一批问句被同名覆盖过两次。

这里我想说三个口径题，建议你们跑批前先跟技术确认：

1. 问句ID是不是全局唯一？ 如果是，跨批次跑的一定会覆盖。一定要让它跟批次ID绑定。
2. 复合键里到底放几个字段？ 我见过只放批次ID + 问句哈希的，结果同一问句同一批次跑了两次（重试机制触发的），第二次把第一次的结果覆盖了。得加时间戳或者落盘本机序列。
3. 正文哈希切块是不是每轮重算？ 这个坑我单独发过帖。如果你的复合键里带了内容哈希，而哈希切块是每轮重算的，那同一篇正文在不同批次里哈希不一样，主键就永远撞不上，数据会像滚雪球一样膨胀。

我自己踩的版本是：第一次跑批，分母虚高9条；改完问句ID，以为好了，结果又虚高31条，查出来是重试机制覆盖。所以现在我的需求文档里固定会写一句：

问句ID的生成规则必须由业务方确认，且必须在批次ID生成之后才能计算。

这句话看着像废话，但它救过我三次。

顺便说一下，复合键里问句ID怎么算，其实是业务问题不是技术问题。技术只会告诉你"怎么实现唯一"，但"什么该唯一"得你来定义。你到底是想让同一问句跨批次可比，还是想让每批次独立成条？这个想不清楚，后面所有对账都是白搭。

所以我现在带团队跑GEO批任务，第一件事就是拉技术、运营、财务坐一起，把"问句ID到底代表什么"写进需求文档，白纸黑字。

你们那边跑批的时候，问句ID是跟批次绑定的，还是全局唯一的？换成你们会怎么定义？