游戏能启动、地图能加载，足以让团队觉得工作正在接近完成。Heumann 的反编译记录却把这个直觉打断了：负责审阅的 Agent 也会接受工作者写下的解释。后来，团队把一部分验收转成了与原二进制的比对。[1] 这使“再加一个审阅者”变成了一个具体问题：它增加的是一次检查，还是另一份来自相似推理过程的认可？
MASS 提供了一个值得认真对待的相反方向。它让共享模型组织团队、比较成果，并把较好的轨迹用于训练；作者另外使用更强模型评价，评价结果不反馈给训练循环。[2] 不能因为监督信号来自自身，就认定它毫无价值。问题应收窄到：外部测量支持哪类提升，以及这种提升离我们需要的正确性保证还有多远。
两项工作的任务条件差别很大。反编译有一个已存在的参照物，可以要求复现它；开放研究通常允许多种方法和答案，字节相同既不可用，也不是目标。模型裁判能比较研究方案的覆盖与解释，这正是硬规则不容易处理的部分。由此推断，把审阅全部换成确定性脚本并不合理；先辨认哪些承诺能由脚本直接核对，再把真正开放的判断留给模型或人，才有清楚的分工。
反编译讨论里，brandonpelfrey 提出更宽松的路线：比较执行中的内存访问，并要求分支覆盖，给实现留下变化空间。原作者则反驳，内存访问一样仍可能漏掉寄存器或浮点状态的差异。[3][4] 这个分歧说明，“严格”不是一个可以单独打分的优点。检查越贴近想保留的行为越好；如果任务只需要选定输入上的行为一致，字节比对可能过严，如果承诺连未发现的原版缺陷也要保留，有限测试又可能过宽。双方没有提供可比较的完整公开实验，速度争论仍不能下定论。
今天的 Mac 推理项目给出更小的对照：作者把性能改动与相同输入下的输出比对一起记录。[5] 这不能保证模型答案正确，却能限制“加速时悄悄换了计算结果”这一类解释。检查器的价值在于排除特定错误，而不是盖一个通用正确章。MASS 的外部模型评价也类似：它比只看自评分多了一道对照，但不同模型仍可能共享遗漏，评价结果不能直接变成科研发现已被验证。
工程上，我会把一项审阅拆成两个可追问的承诺。第一，生成者能否改动判据或影响检查所读到的材料？第二，有没有一个坏结果，仍能通过这项检查？前者涉及检查边界，后者涉及判据覆盖。接着再测误拒绝：把正确但采用不同实现的结果交给它，看看是否被错误拦下。这是本期提出的比较办法，尚不是上述作者共同完成的实验。
与昨日的判断相比，今天补上了“验收会反过来约束可选实现”的一面。保持旧行为、改善运行速度、产生有价值的研究，是不同承诺；选一个容易自动化的指标，可能帮助其中一个，也可能挤掉另一个。值得追踪的进展是：在明确承诺下，系统少漏了哪些错误、又多拒绝了哪些有效结果，而不是一共安排了多少个审阅角色。
另一种解释
有可检查参照的反编译与开放研究不同；同模型审阅可能提供有用改进，固定规则也可能误拒绝正确实现。本文没有证明某一种检查器普遍更优。
接下来观察什么
寻找同一批任务中硬判据、模型审阅及组合方案的配对比较，公开错收、误拒绝、检查耗时和检查器是否可被改动。