无意义的变更应得零分，我的却没得。

在正式实验之前，我进行了一次小规模试点。结果发现了十多个错误。

每一个错误都出在我自己的测量代码中。没有一个错误能教会我任何关于真正试图回答的问题的知识。

这是继 killcheck 之后的后续工作，killcheck 是我今年早些时候在这里写过的测试质量框架。新的工作是一篇研究论文，参加了 Kaggle 关于基于 Google Gemma 4 模型构建的 AI 编码代理的竞争，探讨如何判断代理的错误修复是否真正正确。该论文将于 11 月提交，结果将在比赛结束后公布，因此这篇文章没有任何发现。它包含的是发现之前的部分，我认为这无论如何都是更有用的那一半。

这些错误

它们很无聊。这正是它们危险的原因。

排序在不同运行之间不稳定，因此相同的输入会根据文件系统当天早上的状态产生不同的序列。未播种且我不知道存在的随机性。在负载下触发并被记录为结果而非缺失结果的超时。由于我无法立即解释的原因，在两次相同运行之间输出存在差异。

这些错误都不会自我宣告。它们都不会导致崩溃。它们都会产生一个数字，这个数字看起来完全像一个真实的数字，你可以把它放入表格中，而不会有人眨眼。

我在上一个项目后曾讨论过这种模式。然后我在新项目中又犯了一次。事实证明，知道故障模式的存在几乎没有任何保护作用。

起作用的一个技巧

以下是找到大部分错误的东西。

构建你已知答案的控制组。

最清晰的例子：一个什么都不做的更改应该始终得分为零。如果你向管道输入惰性内容，而管道报告了一个结果，那么这个结果来自你的管道。除此之外没有其他来源。你刚刚捕获了你的仪器凭空制造出一个数字。

我的得分不为零。不止一次。

这就是整个技术，而且几乎简单到令人尴尬。你并不是在测试你好奇的东西。你是在测试测量它的机器是否能正确地测量你已经知道答案的东西。

如果它不能，那么它曾经给过的每一个数字都未经核实。不一定是错的。未经核实，而在你即将发表时，这在实践中意味着同样的事情。

为什么这与仅仅测试你的代码不同

我有测试。测试通过了。

测试检查你的代码是否按照你的指示行事。控制组检查它产生的东西是否与现实相符。这是两个不同的问题，而在测量代码上，第二个问题才是重要的，因为故障模式不是异常。故障模式是一个看似合理的数字。

一个看似合理的错误数字没有症状。它不会抛出异常。它在日志中看起来并不奇怪。它会安静地存在于你的结果表中，直到你允许它存在多久，而唯一能捕捉到它的情况是你提前知道答案并看到机器与你不一致。

这也解释了为什么错误集中在它们所在的地方。我的管道中所有有明显正确答案的部分都早期得到了检查，因为检查很容易且答案明确无误。所有产生判断的部分则长时间未得到检查，因为没有东西可以与之对照。所以我构建了某种东西来与之对照。

这强加给你的顺序

我会做得不同的事情，以及这次在艰难学习之后我所做的事情，是在实验之前而不是在第一个令人困惑的结果之后构建控制组。

这感觉像是一种延迟。你想要进入有趣的部分。控制组不是有趣的部分，它们不产生见解，也没有人会为了确认你的工具能够数到零的部分而阅读论文。

但前期花在它们身上的每一小时，都是你后期不必花费在纠结一个令人惊讶的结果究竟是发现还是缺陷上的时间。第二个问题要昂贵得多，因为到那时你已经有了自己的看法，而看法会让你对符合自己观点的证据变得宽容。

教训

在你信任关于他人系统的某个数字之前，先让你的仪器证明它能产生一个它已知的数字。

无操作得分应为零。空输入应给出空结果。完全相同的重复运行应给出完全相同的答案。这些并非深刻的见解，而是基础。但整个桌子都立在这个基础上，而我两次都以惨痛的代价得知跳过这一步的后果。

在我真正了解实际研究问题之前，我发现了十多个错误。我认为这个比例是正常的。我认为大多数人只是没有去统计罢了。