L1.11.2seeds do not survive version changes设计研究
固定随机种子只能在同一版本内复现，模型或提示更新后即失效
别名: 种子失效 · 跨版本不可复现 · seed is version-local
概念解释
把种子写进日志，以为拿到了科学实验里的随机种子。换一次模型权重、一次解码库、甚至一次系统提示，同一种子走出另一条轨迹。种子是版本内的（seeds do not survive version changes）：它复现的是这一次构建上的抽样，不是跨时间的同一实验。
支持以为「我们有种子所以能重放」。重放在发版后第一天就可能是谎言。
机制
种子只进入伪随机发生器。发生器下游的任何东西——权重量化、批大小、推测解码、安全层改写的系统提示——都会改条件分布，种子便对着另一份分布抽。产品发布把这些下游当常规，种子却被当成长命标识存进工单，两边的寿命不匹配。
更隐蔽的是提示侧。产品在用户句子外包了一层不断迭代的系统提示和工具说明。用户以为输入没变，种子对着已经变了的完整提示在抽。日志若只存用户可见的那一句，种子连版本内都救不了。
怎么研究
固定种子，分别改：权重小版本、解码器、系统提示一个句子、批大小。看逐字恢复率。自变量：改动类型、是否把完整提示快照和种子绑在一起。因变量：身份恢复、语义恢复。
「语义差不多」不能当复现。复现在缺陷场景里必须能再次露出那个错，差不多会把错抹掉。
边界
完全自托管、冻结镜像、禁止热更新的流水线，种子可以在镜像寿命内当复现键。镜像一换，键作废，要在发布说明里写死。图像生成里种子常被当作用户可调参数，跨模型本来就不被期望稳定，需在控件上写清。这条不处理要把哪三样一起存才能追溯，只处理种子单独不够、且跨版本尤其不够。
怎么落地
- 种子旁边必须标模型版本、解码器和完整提示哈希。缺一项，界面不许说「可复现」。
- 发版后旧工单的重放要标明「仅供参考，本版本无法保证同一轨迹」，不要当通过/失败的判决。
- 用户可见的「用同一种子再来一次」只承诺当前版本。版本一变，这个控件要停或改文案。
- 验证：发一个小版本（只改系统提示一句），用旧种子重放一条已知输出。若产品仍显示「已复现」而字节不同，种子被当成了跨版本魔法。