AI写测试自己验：南大新基准揭穿28%合格率真相

假如让学生自己出题、自己答题、再自己判分，这场考试还能信吗？

AI圈眼下正上演类似的一幕。大模型写代码的本事越来越强，不少公司干脆让它顺手给代码配一套测试，拿来判断代码对不对。看上去是个自洽的循环：AI写代码，AI写测试，AI再自己验自己。可这套测试本身靠不靠谱，此前大家的检验办法相当粗糙——只要它能在“标准答案”上跑通，就算过关。

南京大学的研究团队在这个环节里挖出了一个大窟窿。他们做了一个名为TestPrism的新基准，测出来的数字很扎眼：当前最强的AI编程助手，生成的测试代码里真正可靠的只占28%；换成老办法检验，合格率却有59.67%。两者整整差出31.67个百分点，等于说一半以上的“合格测试”只是表面功夫，里子是空的。

### 只认一份标准答案的坑

问题究竟出在哪里，得先讲明白。

传统做法是这样评估AI生成的测试代码的：准备一份初始的、带缺陷的代码版本，再备一份官方认证的“标准答案”代码。一套好测试，应该在初始代码上跑出失败（证明它真能抓到毛病），在标准答案上跑出通过（证明它不会误伤）。

乍听没毛病，可它漏掉了一点：同一个编程需求，正确的写法往往不止一种。

拿数学题打比方，一道“求解方程组”，有人用代入法算出来，有人用矩阵法算出来，路子不同，只要最后数值对，都该判对。可现实里不少老师批卷只拿一份“标准解法”去对，学生换了思路做对了，反倒被算错。

单一参考答案评估的毛病就出在这。测试代码可能跟标准答案的实现细节绑得过死，一换成同样正确、写法不同的实现，它立马翻脸，把对的判成错的。反过来，它也可能带着明显的疏漏，某些错误实现根本没查出来，只不过标准答案恰好没踩到这个坑而已。

**也就是说，过去用来衡量AI生成测试代码质量的那套办法，根子上可能就是在自己骗自己。**

研究团队换了一套更狠的考法。每个编程任务不再只配一份标准答案，而是配齐整整十份实现：四份写法不同但同样正确的“变体答案”，五份刻意埋了错误的“问题答案”，再加上一份原始标准答案，凑成一个十人评审团。

真正靠得住的测试，得扛住这十份实现的集体检验：四份写法各异但确实正确的代码，它都要放行；五份暗藏问题的代码，它都要打回。这个新标准叫联合成功函数，三个条件同时满足才算合格——“在初始状态失败”“通过所有正确实现”“拒绝所有错误实现”。

### 评审团给出的真相

联合成功函数是整篇论文最核心的评价标准，它综合考察AI生成的测试代码三件事：在初始代码上能否失败、在所有正确实现上能否通过、能否拒绝所有错误实现。

搭这套评审团体系，研究者没少下功夫。他们从17个不同来源收集了2000个编程任务，覆盖六种编程语言，其中不乏SWE-bench、Terminal-Bench这些业内叫得响的基准集。任务被拆成1700个训练任务和300个正式测试任务，两边相互独立，免得训练阶段学到的技巧在考试时被直接套用。

每个任务都得凑齐一整套十人评审团：一份官方标准答案，四份风格迥异却同样正确的替代方案，五份错法各不相同的失败方案。这些替代方案不是随便拼的，背后有一套严格的多样性筛选机制。

抽象语法树距离是一种技术方法，用来衡量两段代码在结构层面差多少：代码被解析成树状结构后，比较局部特征的差异，就能判断两个实现是不是足够“长得不一样”。

那四份正确的替代方案，团队要求彼此之间的平均结构差异必须超过某个阈值，防止评审团里出现四胞胎——四份看着不同、骨子里几乎一样的代码。五份错误方案则优先挑失败在不同检查点上的版本，比如一个栽在边界条件，另一个卡在类型处理，这样才好全方位考验测试代码的识别能力。

这就像组一个面试官团队。要是五个面试官都照着同一份简历模板问同一类问题，这场面试不过是把同一个问题重复五遍。靠谱的面试团队得从不同角度切入，技术面、沟通面、压力面各管一摊，才看得出候选人行不行。不这么做的后果，论文里的实验数据给了答案：评审团规模扩大、多样性增加之后，原本能过老式单一标准评估的测试代码，成功率从49.33%一路掉到24.33%，几乎砍半。换句话说，很多测试代码能过旧考试，纯粹是题出得太简单，题库里的坑太少。

研究团队一共动用了十四种不同的AI编程配置，覆盖六大主流模型家族，把这套新考题跑了一遍。成绩最拔尖的Claude Fable 5.1，在老标准下合格率能到59.67%，听着还行；换上联合成功函数这套新标准，直接腰斩到28%。

更有意思的是排名靠后的某些模型，呈现出一种古怪的分裂：它们识别错误代码的比率特别高，甚至超过86%，可谓嫉恶如仇，可对正确替代方案的接纳率惨不忍睹，经常误伤无辜。光会挑错并不够，真正靠谱的测试得在“抓坏人”和“放好人”之间找平衡，哪一头跑偏都会拖累整体表现。

### 失败案例里藏着什么

光知道合格率低还不够，研究团队索性把失败案例拆开看个究竟。他们从六大模型家族里各挑出表现最好的那个配置，采样300条失败轨迹，剔除14条因超时无法分析的样本，剩下286条交给两位专家逐条人工标注。

标注过程颇费耐心，两位专家各自独立判断分类，最终算出的一致性系数达到0.81，说明这套分类体系立得住。标注结果把失败归成三大类：覆盖缺口占34.6%，检查逻辑有问题占50%，执行层面出错占15.4%。

覆盖缺口说到底是测试代码只碰了表面，没踩到真正的雷区。论文举了一个扑克牌游戏的案例：产出的测试全程都没校验过“同花顺”与“三条”孰大孰小这类核心判定逻辑，于是一个把同花顺当成散牌的错误实现，轻轻松松混过了测试，一点压力没有。好比考驾照只考倒车入库，路口左转压根没测，一个不会看信号灯的司机照样能把驾照拿到手。

检查逻辑出问题这块是最大的坑，整整占了一半。毛病出在哪儿？测试代码确实摸到了相关功能，可判断标准本身就错了，或者太

> 执行逻辑错误：指的是测试代码自己在运行当中出了技术性故障，例如调用方法时参数绑定出了岔子、命令执行格式写错了。这类毛病跟测试要验证的业务逻辑没有关系，纯粹是代码本身有bug。

执行逻辑错误占比最小，警示意味却不小。有个案例是测试代码用self关键字去调一个本该独立存在的函数，结果多绑了一个参数进去，连标准答案都跑不通，压根没机会判断对错。

三类问题摞在一起，大致就说清了AI生成的测试代码为何普遍不靠谱：要么测得不够多，要么测了但判断标准歪了，再加上少数时候测试代码自己先崩了。

### 怎样真正提高AI测试代码的质量

找出问题总比解决问题容易。研究团队没在诊断这一步停下，动手搭了个叫TestHelix的系统，想从根子上把这个局面扳过来。

这套系统的核心思路一句话能说清：别让单个AI孤零零地写测试，让多个AI彼此验证、彼此挑刺。

具体走三步。头一步叫异构合成，说白了就是找几个独立的AI智能体，各给一个不同的探索方向，分头独立做出一套“测试代码加修复方案”的组合。有的智能体先写一个基础回归测试，再配一个最小修复方案；有的智能体从公开示例里倒推验证规则，再独立把修复实现出来；还有的智能体专管挑刺，盯着那些容易被简单测试漏掉的边角情况找。

这做法有点像公司开发新品前搞的多团队赛马。只让一个团队闭门造车，很容易钻进自己的思维盲区，觉得设计天衣无缝，用户一上手全是问题。同时让三个独立团队从不同角度切入，最后比出来的方案往往更经得起推敲。不这么做会怎样？论文的实验数据给了明确答案：只生成一套测试跟修复方案的配置，合格率是20.33%；生成三组方案并融合验证后，合格率跳到27.67%，高出7.34个百分点。

第二步是整个系统的灵魂，叫同行交叉验证。

这一步怎么操作？让A智能体写的测试代码，去跑B智能体独立开发的修复方案，看会不会误判。同时再拉一个完全不知修复方案细节的审查者进来，只依据公开的任务需求文档，检查测试代码里的判断逻辑站不站得住脚，有没有没事实依据的武断假设。

> 差异化挑战：两份不同的修复方案都过了审查之后，系统会主动去找能区分这两份方案行为差异的输入用例，进一步检验测试代码的区分能力够不够。

这个机制很巧妙，等于让多个独立视角互相印证，而不是关起门来自嗨。打个比方，像论文答辩：只有导师一人看过稿子就放行，师生之间容易互相认同，却漏掉外部评审能挑出的毛病。额外请两位没参与过写作的外审专家，拿着原始研究问题来质询，很多藏着的逻辑漏洞立马现形。实验数据显示，引入这套完整的交叉验证流程后，合格率从21%左右一下蹦到27.67%，提升超过6个百分点，是整套系统里收益最大的一环。

第三步叫递归自我提升，是个长期优化机制。系统在训练任务上反复试不同的测试生成策略，记下每次尝试的执行轨迹，从中提炼可复用的经验教训，再把这些经验固化成改进后的策略，拿到独立验证集上确认真实可靠，才把这套“冻结”的策略用到正式评测里。

研究团队拿Claude Opus 4.6模型跑了整整20轮这种自我迭代优化，每轮用25个全新训练任务检验改进效果，只有真正有进步、又没在已有成功案例上退步的策略，才会被留下进入下一轮。最终这套反复打磨的策略，在100个独立验证任务上跟最初版本正式比了一次，合格率从48%升到58%，高出10个百分点，统计显著性检验的p值只有0.006470，说明不是运气好，是真有效。

三步合起来看完整收益曲线：在GPT 5.6和Kimi K3这两个模型上，TestHelix相比各自原生的编程助手，联合成功函数指标都提升了8.67到9个百分点。换算成相对单套测试基础方案的提升幅度，这个数字能到11.67到12个百分点。

### 测试多了测试少了都出问题

有一组实验结果值得单独拎出来说，它揭示了一个反常识的现象。

研究团队做了个追加实验，把标准的十人评审团临时扩到十五人，追加七份正确实现和七份错误实现，再看联合成功函数这个指标怎么变。结果发现一条规律：不管往评审团里加正确答案还是错误答案，原本的合格率都会一路往下掉。

从最初的49.33%起步，只追加五份正确的替代实现，合格率就跌到38.1%；只追加五份错误实现，合格率跌到30.49%；两种交替着加，加到九份时，合格率只剩24.33%。

这说明什么？评审团规模本身就是一把双刃剑。评审团越大，测试代码要同时满足的“接纳”和“拒绝”条件就越多，哪个环节出纰漏都会让整体判定失败。这跟生活里常见的现象很像：只找一个朋友帮你判断一个决定靠不靠谱，很容易得到过于宽松或片面的结论；找来十个朋友轮番发表意见，反而更容易把决定本身的瑕疵暴露出来，因为总有人能从新角度戳破漏洞。

这也解释了论文为何反复强调，单一参考答案评估是整个评估体系里最宽松的特例，它构成一个上限，而真正扩大评审团规模后得到的合格率，永远不会超过这个上限，只会越来越逼近测试代码的真实水平。

### 这件事之后会怎样

论文发表后，圈内对AI自动化测试生成的讨论风向有了明显转变。以前大家默认“能通过标准答案就算靠谱”，如今越来越多团队开始意识到，这种单点验证方式存在系统性盲区。

后续研究顺着这个方向继续深挖。比如有工作针对代码修复场景专门设计了名为PROBE的方法，拿生成的程序变体去加强已有测试基准，检验测试代码面对“行为不变、实现细节不同”的变体时是否依然稳健。这与TestPrism强调的多实现验证理念高度呼应，相当于把思路延伸到了代码修复这一相邻领域。

另一条脉络是测试生成策略本身如何自我进化。TestHelix用到的AutoSaddler优化框架，实质继承了此前Meta-Harness这类端到端优化模型执行框架的思路，又结合了Reflexion提出的“语言智能体靠文字反馈自我修正”机制。这些工作共同指向一个方向：AI系统不再一次性给出答案，而是能持续迭代、从执行反馈中积累经验。读完这篇论文，我一直在想一个问题：我们到底该怎么定义“靠谱”这两个字。

写在后面

过去判断一件事做得好不好，习惯用一个简单的二元标准：通过了就是好，没通过就是不好。但TestPrism让我意识到，很多时候“通过”本身就是个脆弱的判断，它完全取决于你用什么标准衡量、拿谁的答案去对照。

还有个细节出乎我的意料：按老标准拿下最高分的那些模型，一换上新的评判标准，反倒显露出最严重的分裂。有的模型对错误代码格外敏感，九成以上的错误都能揪出来，可碰上正确的替代写法却常常看走眼，接纳率才四成多。这种“宁可错杀，不可放过”的保守做法看着挺负责，其实是另一类不靠谱——它意味着真正正确的创新实现会被这套测试一直挡在门外。

现实里有一种挺常见的管理风格与此类似：审核流程卡得极死，凡是看着不合惯例的方案一律否掉，风险把控瞧着做得挺到位，可创新的可能性也在无形中被掐掉了。好的审核机制应当两头兼顾，既拦得住真正的问题，也给合理的新思路留出余地。

论文还有一个问题没完全说清楚：如果评审团规模继续扩大，比如从十人扩充到五十人甚至一百人，联合成功函数这个指标会不会趋于一个稳定值，还是会一直往下探底，直到趋近于零？如果真的存在稳定值，那它或许能帮我们找到一个“合理的多样性阈值”，既不会因为题太简单而放水，也不会因为题太难而失去区分意义。这个问题，留给未来的研究者去回答吧。

Q&A

Q1：TestPrism的联合成功函数具体是什么意思？

A：联合成功函数对AI生成的测试代码提了三个条件，得同时满足才算过关——放到最初那版有问题的代码上必须失败，对每一种正确的替代实现都要通过，对每一种错误实现都要拒绝。跟过去只拿一份标准答案做对照的评估方式比，这个要求严多了。

Q2：为什么单一参考答案评估的方法不靠谱？

A：因为同一个编程需求往往有多种正确写法。测试代码如果只跟一份标准答案绑定，很容易出现两种问题：一是测试代码恰好能通过标准答案，但拒绝了其他同样正确的写法；二是测试代码存在明显漏洞，但标准答案碰巧没有触发这个漏洞，导致漏洞被掩盖。

Q3：TestHelix是如何提升AI生成测试代码质量的？

A：TestHelix分三步实现提升：先让多个AI智能体独立开发不同的“测试加修复”方案组合，再让这些方案互相交叉验证，并引入独立审查者检查逻辑漏洞，最后通过长期自我迭代优化测试生成策略。整体上，它在两个主流模型上都带来了8点67到9个百分点的合格率提升。