在信任任何评估/指标/实验/基准前…

当你准备相信某个「怎么算成功」的验证（A/B、holdout、分数、validation），或结果好得太干净、太自我印证时，用 8 类泄漏模式审计它是否独立。

适用场景

解决思路

1. 识别被审计的 validation（eval / metric / experiment / holdout /「how we'll know」），并命名它的各个组件：什么扮演 model、scorer、designer、dataset。
2. 提出核心问题：外部 ground-truth 是否「独立地」进入这个验证？
3. 用下面全部 8 个 pattern 逐一测试该 validation（部分 pattern 只适用于特定组件，例如 human subject、scorer），只报告命中的那些，并按名字报出。
4. 对每一个命中的 pattern，给出「独立 ground-truth」的修复方案。
5. 检查 #1 Recall, not reason：是否在背诵一个记住的答案，而不是真正推导出来的答案；系统是否早就知道它声称正在计算的那个结果。
6. 检查 #2 Wrong null hypothesis：消融是否只去掉了表面标签，却没有去掉系统实际利用的底层信号，导致这个「control」仍然在泄漏。
7. 检查 #3 Shared hallucination：两个组件互相验证，把循环论证当成一个数字上报。
8. 检查 #4 Tautology：scorer 在给自己划定的桶打分。
9. 检查 #5 Verifier = designer：以 holdout 之名，行私有、不可复现配方之实。
10. 检查 #6 Shared-pool bias：train 与 holdout 取自同一个标注者池，同一个偏差进入了两侧。
11. 检查 #7 Frame injection：问题本身把假设直接递给了被试。
12. 检查 #8 Demand characteristics：被测量的对象知道自己正在被测量。
13. 注意会咬两次的隐蔽性：你可以盲化 output value，却仍然泄漏 collection recipe。
14. 保持 read-only：只指出泄漏点和独立性修复方案，不要改写实验。
15. 对高风险的 validation，可以额外加一个独立的 fresh-context auditor（N=1），只交给它 validation design，而不给它本次会话的推理，让它盲跑一遍 8-pattern taxonomy；默认仍是同会话、read-only。
16. 验证时把 mandela 用在这个审计自身上：对你自己跑 #3–#5——你是否是一个在给自己划的桶打分的 scorer（#4 Tautology）？verifier 是否就是 designer（#5）？你的结论是否与设计自身的主张构成 shared hallucination（#3）？
17. 检查：一个没有参与这次审计的读者，能否仅凭所引用的证据独立得出你的结论——即存在独立 ground-truth？
18. 报告要点名 root cause，而不是罗列一堆清单。

适用边界 · 注意事项

• 没有任何可审计的 validation（没有 eval / metric / experiment / holdout / benchmark）时。
• 期望它去重写、修复或重新设计实验时——该技能是 read-only，只指出泄漏与独立性修复。
• 需要统计功效、显著性检验或大规模实验设计本身的工作，而不是泄漏审计时。