评测试时，别只拿一条参考实现开绿灯

给编码 agent 出测试，最省事的验收是：对着官方那一份参考实现跑一遍，绿了就当测试写对了。这条捷径会把别的合法实现误伤，也会放过只对这一份答案生效的断言。TestPrism: Rethinking Test Evaluation Beyond a Single Reference 把验收改成三件事同时成立：测试先在初始程序状态上失败，再放行每一份合法实现，并挡住每一份不合法实现。

论文 2026-10-08 挂到 arXiv，编号 2610.12289v1。本轮用 export.arxiv.org 核摘要。摘要里没有代码仓。Hugging Face 日榜这轮还能看到它，26 个 upvote。

先换尺子，再看 agent 写的测试

按摘要自己动手核，只需记住这把尺子怎么用。

第一步，不要只拿一份参考实现当对错。TestPrism 收了 300 道测试任务，来自 17 个源，配 3000 个候选实现，合法和非法各一半。评一次测试，是在这 3000 个实现上同时看，不是在一个金标准上偷看一眼。

第二步，主指标用 Joint Success Function。它要求三件事一起成立：测试在初始程序状态上必须失败；每一个合法候选都要通过；每一个非法候选都要被拒绝。十四条基线编码 agent 配置上，这个联合成功只有 28.00%。如果退回“只对上那条参考答案”，成功率会升到 59.67%。中间那截 31.67 个百分点，就是单参考尺子会夸大的部分。分析还写到漏检行为、站不住的断言，以及测试构造本身出错。这些百分比是官方摘要数字，不是本轮复现。

第三步，如果要把分数拉回来，摘要给出的对照是 TestHelix：把异构的测试与修复配对、同伴交叉验证和递归自改进叠在一起。在两个模型上，Joint Success Function 相对原生 harness 提高 8.67 到 9.00 个百分点。没有公开仓库，就谈不上安装命令和许可证。下轮作者若放代码，再核许可和复现脚本。

和站内其它评测稿怎么分开读

站内刚写过 Cadence：那是运行时按健康度调度监视，评的是 SWE-bench Lite 上两条 harness 会不会跑偏。TestPrism 评的是测试本身有没有把合法实现一网打尽。两篇可以并排读，不要并成一篇。

读这篇只需记住四组数：300 题、17 个源、3000 个候选；联合成功 28.00%；单参考 59.67%；TestHelix 再加 8.67 到 9.00 个百分点。其余都还在摘要里。评测试时，先问这三条是否同时成立，再决定要不要相信那条绿了的参考答案。

操作上可以缩成一张检查单。先把候选实现按合法和非法分开，不要只留官方那一份。再跑生成出来的测试：初始状态必须红，合法集合必须全绿，非法集合必须全红。三条里坏了一条，联合成功就不算。若只向那条参考答案看齐，59.67% 会让人误以为测试已经可用。本轮十四条基线配置都没越过 28.00% 这道联合门槛。没有代码仓，检查单也只能停在纸面上；数字仍以摘要为准。