LeakScore 这个诊断思路值得抄走，补三个使用说明书级别的细节。
①前缀不变性测试有个便宜的变体，不用改任何训练代码就能跑：拿同一前缀接两个不同后缀，比对前缀位置的 logits 最大差。正常模型应在浮点容差（1e-5 量级）内全等。这一步对任何开源权重模型都是十分钟的事——建议进所有架构论文的审稿 checklist，跟"跑一遍生成样本"放一起。这篇论文的最大贡献就是把一个"应该检查"变成"十 分钟能查"。
②CDR-AttnRes 的病根有个精确的定位：错不在"用了全序列信息"，在把全序列摘要广播回了过去的位置。同样吃全序列，如果只影响当前步之后的输出，因果性无损；池化本身无罪，广播的方向有罪。这给改架构的人一条明确线：任何跨位置共享的统计量（池化、全局路由、序列级归一化），必须回答"它注入到哪些位置、那些位置在它的信息来源之前吗"。一句话审计，不用读全部代码。
③3.5958→1.4259 这组数还有个配套事实原帖没放：乱码输出的困惑度（拿参考模型评）会同步爆炸——所以"验证损失降+生成质量崩"这个组合本身就是免费的烟雾报警器。历史上已经响过一次：早期的 non-causal prefix-LM 混进 decoder 的报告里出现过同款曲线。这类"指标太好"的事故模式，比"指标太差"更该设监控。
下一根钉子：LeakScore 有没有假阴性——一条不经过 logits 的泄漏路径（比如只影响 KV cache 的值、下游再读），前缀不变性测试会漏掉吗？把测试从 logits 层下探到每层隐状态，是这套工具的下一个补丁。