怎么验证一次 LLM 改动 而不自欺

几乎每周都冒出个新模型、新推理档位，顺手试一个、瞄一眼结果、觉得它更好，太容易了。问题就出在那一瞄。单次跑几乎说明不了什么，而且它很乐意印证你本来就想看到的结论。所以我们搭了个小装置来正经地验。这算不上研究，样本太小，但它不止一次抓到我们判断错了。

多数糟糕的对比一次动了两样。我们只动一样。证据是冻住的——每次都是同样八条已核查的源——prompt 用的是 app 里 真正在跑 的那份，直接 import，不另抄，这样测的才是真会上线的东西。然后只改一个旋钮：model、推理 effort、或长度指令。输出里变了的，就来自那个旋钮。而且便宜：没有实时检索要付费，扫一整轮就是几分钟、几美元。

让模型给自己的输出打分，它往往偏爱自己写的。所以我们把每个候选的标签都抹掉，两个族都来评——Opus 评 Sonnet 的、Sonnet 评 Opus 的。两个默认档打平，4.68 对 4.68。要紧的是后面这步：换了评分方，排序纹丝不动。不管 Opus 还是 Sonnet 执笔，Opus 都不低于 Sonnet。要是只有一个判官说"平"，我们是不敢信的。

就是这一刻。在最高推理档，第一次输出抓到两个默认档漏掉的方法学点——我们的深度指标涨了 75%，足够说服自己去付那个贵档位的钱。然后又跑了三次。那两个点一次都没再出现。四次下来，这点差距塌回了普通的逐次波动，而真正撑起这份简报的方法学，两个档位每次都在。单次是你说给自己听的故事。你只有重复时才看得见规律。

判官的盲区。为省 token，我们递给评分者的是一份 缩短过的源。它们标出了"编造"——可那些被标的细节明明就在完整源里，只是不在我们那份短版里。这个 eval 在制造它本该抓的问题。修法：给评分者完整的源，别给精简版。

成本幻象。我们一开始直接从 dev CLI 读成本。它背着自己的缓存 system prompt，把报出来的数字抬高了 3–4×，还把"谁更便宜"也颠倒了。你得按真正要部署的形态、用公开 list price 重新算。dev 工具打印的那个数，不是那个数。

1. 01除了你要测的那一个变量，其余全冻住。
2. 02import 真实生产 prompt——绝不另抄一份干净版。
3. 03候选匿名；跨模型族评分，别只用自家的。
4. 04Replicate。单独跑得好那一次，什么都证明不了。
5. 05给判官完整证据，不是图省事的摘要。
6. 06按真实部署形态量成本，不是 dev CLI。