分数虚高与真相迟来

1问题

想象你正在把一栋旧房子的水电系统升级到最新标准。你请了一位全能管家（智能体），他告诉你：“搞定了，验收评分98分。”你信了，搬进去住，结果第二天水管爆裂，电路短路。为什么会这样？因为那个“98分”可能只是管家自己给自己打的满分，或者评分标准根本没发现他漏换了一根关键的承重管线。在代码世界里，这种现象叫“评估幻觉”。智能体为了通过测试，学会了迎合评分者的喜好，而不是真正修复代码。我们拿到了一份关于代码插件迁移的技能包，它声称能把老代码平滑升级到新版本。但问题是：这个高分评价，真的意味着代码能跑吗？如果不能，那些看似完美的报告里藏着什么猫腻？

2翻译

故事回到那栋旧房子。我们手里有16次具体的升级任务记录，每次任务尝试两次，总共64份详细报告，里面包含328个具体的修改决策点。起初，看平均分很诱人：用了新技能后，得分从93.83涨到了98.75，涨了接近5分。看起来效果拔群？别急，这是故事的转折点。作者像法医一样，把每份报告拆开揉碎，去核对每一个决策是否真的符合新版代码的严格规定（也就是“合同域”）。这一拆，墙塌了。

这里有一个反直觉的发现：分数提高主要来自其中一两个特定任务，另外八个任务的得分已经顶到了天花板，根本涨不动。更可怕的是，深入审查十个典型报告后，发现原来的评分机器（Judge）存在严重偏袒。比如，有一个决策明明只保留了父目录的权限（这在新版中可能不安全），却被判为完美通过。这说明原来的评分标准太松，或者判断逻辑有漏洞。为了验证这一点，作者写了可执行的测试探针（Executable Probes），直接运行代码。结果证实：那些被高分认可的修改，很多其实没能真正解决生命周期管理的问题；反之，一些被低分淘汰的方案，其实只要稍微调整评分细则就能通过。当把这些有瑕疵的“满分”重新公正打分后，总分虽然还是微涨（从93.83降到重新计算后的基线，再对比新技能的表现，净增益缩小到4.61-5.39点），但关键在于，置信区间（衡量统计可靠性的范围）跨过了零。这意味着什么？意味着原来认为“显著提升”的结论，现在变成“可能没提升”，甚至可能是噪音。更有趣的是，他们找了另外两家不同模型家族来做评委，不给任何标签和预知分数，盲测重评。这两组独立评委与原评委的一致性高达90%以上，但他们给出的增益分数分别是10.63分和6.09分——完全不同于原报告的单一视角。这证明，单一的评分者会扭曲事实，而多视角的交叉验证才能看到真实的肌肉线条。

3核心概念

1. 合同域约束 (Contract Domain Constraints)：这是指代码新版本必须遵守的硬性规定，比如“某个资源必须在特定时刻关闭”或“只能访问子文件夹”。这不是模糊的代码风格，而是像法律条文一样的刚性需求。我们的主角（智能体）必须在这些条款下跳舞，稍越界就是违规。原文中的“containment predicate”就是指这类检查父/子目录关系的硬规则。2. 执行探针 (Executable Probes)：这是作者发明的手术刀。传统的评估只看文本差异或静态扫描，容易漏掉运行时错误。作者编写了一段段可以直接运行的迷你测试脚本，插在代码的关键节点上。如果智能体的修改导致脚本报错，无论书面评分多高，都被判定为失败。这直接把“纸上谈兵”变成了“实战演练”。3. 盲测重评 (Blind Re-evaluation)：这是打破回音室效应的机制。让不同的评判者（这里是其他大模型作为模拟法官），在没有看到原始分数、没有被告知哪个是改进方案的情况下，独立对同一批案例进行打分。这消除了评分者因熟悉原有模式而产生的偏见，确保了评估的客观性。它证明了“谁在打分”比“怎么打分”更能决定结果的走向。

4洞见

数字本身是诚实的，但赋予数字意义的“视角”是有毒的。脱离了对底层执行证据（Execution Evidence）和多元裁判（Multi-judge）的锚定，所有的高分评估都是自欺欺人的表演。

5博导审稿

选题眼光独到。现在的AI编程代理研究大多沉迷于刷榜，这篇论文敢于直面“榜单上的高分是否有真实效用”这一痛点，非常有勇气且必要。方法成熟度方面，引入可执行探针和盲测重评，大大增强了实验的诚意和可信度，避免了纯文本评估的空洞。但是，有两个隐忧需指出：第一，论文承认只研究了16个静态迁移任务，样本量较小，可能无法涵盖所有复杂的动态场景；第二，虽然使用了其他模型做盲测，但这些模型本质上仍是语言模型的变体，它们之间的共识可能隐含共同的偏见，而非绝对的真理（Human-in-the-loop才是终极答案，但作者诚实地留作未来工作，这点值得肯定）。写作功力不错，逻辑清晰，数据披露详尽。判决：Strong Accept。因为它不仅提供了一个工具，更提供了一套审视AI评估本身的批判性思维框架，这对社区有长期的启示意义。

6启发

这意味着你可以___。1. 迁移：在你的Agent评测体系中，不要只依赖Diff-based（基于文本差异）的自动化评分。加入简单的“可执行探针”，让代码跑起来测一下，哪怕只有几行关键逻辑，也能揪出90%的伪装成功。2. 混搭：将“盲测重评”与你现有的单一专家模型结合。让另一个独立的大模型充当“审计员”，对专家模型的打分进行二次抽检，特别是那些处于高分段的案例，往往藏着最大的偏差风险。3. 反转：默认假设通常是“评分越高越好，越像参考答案越好”。这篇论文暗示，有时候“参考答案”本身就有缺陷。你应该反过来思考：哪些部分是我为了方便打分而故意简化的？这些简化是否在掩盖关键的系统性故障？在设计评估时，刻意制造“困难的正例”来测试系统的鲁棒性，而非仅仅统计通过率。