这次南京大学团队推出的 TestPrism 基准，直接戳破了之前代码智能体评测的泡沫，就算是当前性能最强的 Coding Agent，在一题配备 4 份可行正确实现、5 份带缺陷错误实现的严苛校验规则下，整体联合通过率只有 28%。很多大家之前看到的漂亮高分，都是只用单一标准答案去打分，只要 Agent 写出和参考答案接近的代码就判定通过，这种评测方式会严重高估 Agent 的测试编写能力。这套新基准的核心判定规则不是 “写出一个正确用例就行”，而是要求 Agent 生成的测试同时满足两条硬性标准：全部收下四种合法正确写法，同时精准拦截全部五种有漏洞、不符合需求的错误写法，只要漏判一个，这道任务就算直接失败。
评测基础设置
- 总任务规模：一共 300 个代码测试任务，配套 3000 份人工核验后的代码实现样本
- 单题样本分配：每题固定 4 个正确实现、5 个错误实现
- 核心指标：JSF，联合成功分数，也就是我们说的全过关率
- 对比数据：单一参考答案模式下，最强 Agent 能拿到 59.67% 的通过率，和新标准的 28% 差距巨大
Agent 高频踩坑分类
团队对 286 条失败记录做人工标注，归纳出三类最常见失误。
- 把实现细节当成需求：强行绑定某一份标准答案的写法，别的合法实现直接被测试误杀。
- 缺陷识别不全：只能抓到一部分明显 Bug，会放过隐藏逻辑漏洞的错误代码。
- 边界判定混乱：对等价实现、边缘分支缺少分辨能力，经常出现随机误判。
配套优化方案
研究同步放出 TestHelix 改进框架，用来拉高代码 Agent 在这套基准上的表现，操作步骤分成三步。
第一步，异构合成，自动生成多条思路不一样的测试用例，避免测试逻辑单一固化。
第二步，同伴交叉验证，让多个子 Agent 互相校验对方产出的测试脚本，提前揪出误判。
第三步，递归自我迭代，用失败样本反向微调提示词和生成逻辑。在同等推理开销下，这套方案能把 JSF 指标拉高大约 11.67 到 12 个百分点。
实际落地启示
这个测试结果说明，现在市面上的代码 Agent，写出来的测试还很难直接拿去线上当验收标准。如果继续沿用单一标准答案做评测，很容易高估能力，上线之后就会出现测试放过故障代码的情况。想要靠谱的自动化测试智能体，后续评测都需要转向这种多实现对照的校验方式，而不是依赖唯一参考答案打分。
【常见问题】
问题 1：TestPrism 基准里一题配 4 份正确答案和 5 份错误答案，这个设置有什么意义？
回答 1：这个设置是为了模拟真实开发场景，同一个需求本来就存在多种合法编码方案，单一标准答案会漏掉大量等价实现，用多份正确、错误样本，才能测出代码 Agent 的测试用例能不能做到 “接受全部正确、拦截全部错误”，拿到更贴近生产环境的真实能力分。
问题 2：最强代码 Agent 在 TestPrism 拿到 28% 全过关率，是不是代表它完全没法写测试？
回答 2：并不是，它在只对照一份标准答案的旧评测里通过率接近六成，只是它生成的测试稳定性不足，很容易误杀合法代码或者漏掉缺陷，只能应付简单场景，还达不到工业级验收的可靠标准。
问题 3：TestHelix 框架可以把代码 Agent 在 TestPrism 的通过率提升多少？
回答 3：在同样推理预算的前提下，TestHelix 可以把 Agent 的联合成功分数提升 11.67 至 12.00 个百分点，主要依靠多版本测试合成、交叉校验和迭代优化，减少测试脚本的误判。
问题 4：JSF 指标和普通代码评测准确率差别在哪？
回答 4：普通准确率只看能不能命中一份标准答案；JSF，也就是全过关率，强制要求测试对同一题所有 9 份样本全部判断准确，只要有一例误判，整道任务不计入通过，门槛严苛很多。
【参考资料】
[2026-11-12]（Coding agent 写测试集体失败，AI 代码合格率被高估一倍）36 氪
【免责声明】
本文所有评测数据、基准规则均来自公开学术研究报道，不代表所有 AI 代码 Agent 的极限性能；不同模型、提示词、运行环境会带来结果波动，不能直接作为选型唯一依据；研究结论仅针对本次 TestPrism 基准，不代表模型在其他代码基准、线上业务场景下的表现。