香港科技大学（广州）研究团队的新突破：不用"标准答案"，AI也能越考越强？

这项由香港科技大学（广州）与江苏集萃感知技术研究所联合开展的研究，发表于2026年5月，论文编号为arXiv:2605.23491，感兴趣的读者可通过该编号查询完整论文。

说到底，教AI写代码，历来是一件麻烦事。麻烦在哪儿？核心在于"如何判断AI写的代码好不好"。你不能光靠肉眼看，必须有一套可以自动运行、自动打分的"考试题"——行话叫做"单元测试"（Unit Test，后文简称UT）。这些测试题就像数学题的标准答案一样，给定一个输入，告诉你正确的输出是什么，然后让AI写的代码去"对答案"。

问题在于，这些"标准答案"从哪儿来？通常由人类专家或官方出题人一道道精心设计，成本极高，数量有限。现有最厉害的那批AI编程训练方法（学术上称为"强化学习+可验证奖励"，即RLVR），都依赖大量这样的标准测试题才能运转，就像学生刷题必须有答案一样。一旦没有这些"标准答案"，AI的表现就会大幅下滑。

这个困境，就像是一个只能在有"参考答案"的题库里练习的学生。一旦题库用完，或者遇到新题型，就茫然无措。

研究团队提出的方法叫做**CoSPlay**，全称"Cooperative Self-Play at Test-Time with Self-Generated Code and Unit Test"，直译为"利用自生成代码和单元测试的测试时合作自博弈"。这个名字听起来很拗口，但核心思路用一句话就能说清楚：**让AI自己出题、自己答题、自己改卷、自己进步——全程不需要任何人类提供的标准答案，也不需要重新训练AI的大脑。**

这就像一个学生，没有老师、没有答案册，但他能和同学互相出题、互相批改，在这个过程中越来越厉害。CoSPlay就是让AI扮演这个"既出题又答题"的学生角色。

---

一、为什么"没有标准答案"是个大问题

先说清楚这件事有多重要。当前AI写代码的能力突飞猛进，背后有两大核心技术路线。第一条路是"强化学习"（Reinforcement Learning with Verifiable Rewards，RLVR）：用大量带有标准答案的测试题反复训练AI，让AI在训练过程中学会如何写出能通过测试的代码。第二条路是"测试时扩展"（Test-Time Scaling，TTS）：不改变AI本身，而是在AI"临场发挥"时多生成几个方案，然后用测试题筛出最好的那个。

两条路都依赖标准测试题。就像备考高考，无论是平时刷题（强化学习），还是考前押题（测试时扩展），都得有题目和答案。而这些题目由权威出题人提供，数量有限，制作成本极高。目前业界最强的一批AI编程模型，比如论文中提到的CURE-7B，需要4500道这样的标准测试题才能训练出来；AceCoder-7B-RM甚至需要多达32.9万条偏好数据。

当没有这些"标准答案"时会发生什么？研究团队发现，现有的"无标准答案"方法普遍存在两个致命弱点：AI自己生成的测试题质量参差不齐，有的题目答案根本就是错的；更糟糕的是，错误的代码和错误的测试题会"狼狈为奸"——错误的代码恰好通过了错误的测试题，反而得到了高分，就像两个都抄错的同学，互相对答案后都觉得自己做对了。

这种现象，研究团队称之为"虚假耦合"（spurious coupling）：错误的代码和错误的测试题意外地"配对成功"，产生错误的正反馈。这是整个无标准答案场景下最难克服的障碍。

CoSPlay的使命，就是在这种困境中找到出路。

---

二、CoSPlay的核心设计：代码和测试题互相"淘汰赛"

CoSPlay的工作流程分为三个大阶段，可以用一场"双向淘汰赛"来理解。

**第一阶段：出题前先摸底**

赛前侦察员的工作，是搞清楚对手的弱点在哪里。CoSPlay的第一阶段，就是让AI扮演这个侦察员。

AI首先面对一道编程题，生成多个高层次的"解题思路"（论文中称为hints）。这些思路不是具体的代码，而是类似"这道题可以用贪心算法解"、"也可以用动态规划解"这样的方向性想法。然后，AI把这些思路两两组合（单独或成对），扩展成更详细的解题方案。这样，AI就为自己准备了一批"多样化的解法草稿"。

接下来是关键步骤：AI针对每一个解法草稿，主动思考"这个解法容易在哪里犯错"。就像经验丰富的老师会说"用贪心算法的同学，往往会在处理边界条件时翻车"，AI生成了一批"攻击性测试思路"（attack ideas）——专门针对各种解法可能犯的错误设计的测试方向。

这批针对性测试思路，大大提高了后续生成测试题的质量。对比实验显示，用这种方式生成的测试题，平均"通过率"比直接随机生成的高出2.39个百分点，而且极低通过率的"无效测试题"减少了29%。打个比方：与其随机出一百道题，不如精准研究对手弱点后出二十道针对性题目，效果反而更好。

**第二阶段：代码和测试题互相博弈**

这是CoSPlay最核心的部分，也是"合作自博弈"名字的由来。

AI根据之前的解法草稿，生成一批候选代码（默认16个）；同时根据攻击性测试思路，生成一批候选测试题（默认16道）。为了保证测试题的答案尽量正确，AI对同一个输入多次计算预期答案（默认采样4次），只有当至少3次计算结果一致时，才采用该答案——这叫"自洽验证"（self-consistency），就像多算几遍确认答案，不一致就扔掉。

然后，AI把所有候选代码和所有候选测试题放进一个"执行矩阵"——每一行是一个代码，每一列是一道测试题，格子里填"通过"或"失败"。这个矩阵就像一场循环赛的赛程表。

从这个矩阵里，AI可以读出两种信号：对于每道测试题，有多少代码通过了它（称为"测试题通过率"）；对于每个代码，它通过了多少测试题（称为"代码通过率"）。研究团队从理论上证明，并用实验数据验证：通过率越高的测试题，其答案越可能是正确的；通过率越高的代码，越可能是真正正确的代码。这个直觉非常符合现实——如果一道测试题被大多数代码都通过了，说明这道题比较基础可靠；如果一个代码通过了大多数测试题，说明这个代码比较稳健。

基于这两种信号，AI开始进行四步迭代净化。

第一步是"清理失分代码"：如果某个代码一道测试题都过不了，那它很可能彻底错误，直接替换掉。第二步是"打破虚假耦合"：如果某道测试题的通过率极低（只有极少数代码通过），这道题很可疑——它可能是个答案错误的测试题，恰好与少数错误代码"配对成功"。AI把这道可疑测试题替换成新生成的测试题，打破这种可疑的"默契"。第三步是"修复问题代码"：选出通过率最高但还没有被所有代码通过的测试题（这道题既可靠又有区分度），让AI对未通过它的代码进行针对性修改，就像学生根据错题本改错。第四步是"替换无效测试题"：经过代码修复后，有些测试题可能变得"全过"或"全不过"，这两种情况下它们已经失去区分代码好坏的能力，直接替换成新的测试题。

这四步反复循环（最多5轮），代码池和测试题池就在这种"互相挑战、互相净化"的过程中共同进化。研究数据显示，经过5轮迭代后，低通过率区域的测试题密度平均下降了近30%，而高通过率区域的密度相应提升；代码侧也呈现类似趋势，低通过率代码逐渐被清除，高通过率代码越来越多。

**第三阶段：平局决胜局**

经过双向淘汰赛，最后往往会有几个代码并列第一（通过了同样多的测试题）。这时候，普通的"选最高分者"策略无法决出胜负。

CoSPlay采用了一个聪明的"加时赛"机制。AI随机生成一批新的合法输入（不需要预先知道正确答案），让所有并列第一的代码都跑一遍，记录各自的输出。然后，按照"输出相同"为标准，把这些代码聚类分组。

背后的逻辑是：真正正确的代码，无论遇到什么合法输入，输出都应该相同（因为它们实现的是同一个正确逻辑）；而错误的代码，往往会以各种不同的方式出错，输出分散。所以，最大的那个"输出一致的代码群"，最可能包含正确代码。

研究团队从理论上证明了这一点：随着随机输入数量增加，正确代码的输出特征会越来越成为"主流群体"，而任何单个错误签名的概率则以指数速度衰减。实验中，正确代码确实高度集中在大型聚类中，错误代码则多数分散在小型或单独聚类里。选出最大聚类中可靠性最高的代码作为最终答案，就是CoSPlay的最终决策。

---

三、实验成绩：它真的有效吗？

研究团队在四个公认的高难度编程测试集上进行了评估：LiveBench（128道题）、LiveCodeBench v2（511道题）、CodeContests（239道题）、CodeForces（467道题）。这四个测试集代表了从竞赛级别到实际工程问题的广泛难度范围。

最核心的对比实验结果相当亮眼。以7B（70亿参数）规模的基础模型Qwen2.5-7B-Instruct为起点：不加任何改进，它的平均"最优16选1"准确率（BoN@16，即从16个候选答案中选最优）只有22.1%，自生成测试题的准确率（UT Accuracy）更低到只有14.6%。经过CoSPlay加持后，最优选1准确率跃升至33.2%，测试题准确率飙升到78.3%。

更值得关注的是，经过CoSPlay加持的Qwen2.5-7B-Instruct，其最终BoN准确率（33.2%）已经略微超过了CURE-7B（32.9%）——而CURE-7B是用4500道标准测试题进行过专门强化学习训练的模型，CoSPlay什么额外训练都没做，仅靠推理时的自我进化就追平乃至超过了它。

当CoSPlay被应用到已经经过强化学习训练的CURE-7B上，效果还能进一步叠加：平均BoN从32.9%提升到38.6%，提升了5.7个百分点。这说明CoSPlay与强化学习训练并不冲突，两者可以相互补充。

在14B参数规模上，类似的规律同样成立。Qwen2.5-14B-Instruct加上CoSPlay后，平均BoN从33.2%提升到42.0%，与CURE-14B的41.8%基本持平，同样不需要任何额外训练数据。

在与其他"测试时扩展"方法的横向对比中，CoSPlay在可比或更少的计算量下，准确率普遍高于竞争对手。比如，将样本数扩展到256个的朴素方法（BoN N=256）消耗了74.5万个token，准确率只有22.5%；CoSPlay消耗68.2万个token，却达到37.2%。此外，研究团队还把CoSPlay应用到DeepSeek-V3.2-685B（6850亿参数的顶级大模型）和Gemini-2.0-Flash上，前者的平均BoN从65.7%提升到68.2%，尤其在最难的CodeForces测试集上，从39.3%大幅跃升到50.0%。

---

四、为什么这些信号真的可靠？

一个自然的疑问是：没有标准答案，AI怎么知道自己生成的测试题和代码哪个更可信？研究团队对此给出了理论推导和实验验证双重支撑。

理论层面，他们证明了一个关键定理：在一定前提下（正确代码通过正确测试题的概率，高于错误代码通过正确测试题的概率），"通过率越高的测试题，答案越可能正确；通过率越高的代码，越可能真的能解题"。这个前提在实际中通常成立——因为正确的代码会忠实执行正确逻辑，而错误的代码只能偶尔碰巧给出正确答案。

实验层面，研究团队对比了正确与错误的代码/测试题在通过率上的分布。结果清晰显示：正确测试题集中在高通过率区域，错误测试题集中在低通过率区域；正确代码集中在高通过率区域，错误代码集中在低通过率区域。GT正确率（即真实准确率）与通过率之间呈现出单调递增的正相关关系，且这一关系在5轮自博弈过程中始终稳定成立。

聚类选择的可靠性同样有理论支撑。研究团队证明，随着随机输入数量趋于无穷，正确输出签名会成为概率最高的唯一主导模式，而任何错误签名的概率都以指数速度衰减。实际实验中，即使只有有限的随机输入，聚类大小与代码真实正确率之间也呈现出显著正相关：聚类越大，包含正确代码的概率越高。t-SNE可视化图进一步直观地展示了这一点：正确代码在输出空间里紧密聚集，错误代码则分散在各处。

---

五、拆解每个零件：哪些设计真的有用？

研究团队还做了一系列"拆解实验"，逐一验证每个设计模块的贡献。

去掉第一阶段的"解题思路探索和攻击性测试思路生成"（w/o exp-atk），是影响最大的单一操作。测试题准确率从接近80%跌至32.5%，BoN准确率也从36.7%跌至30.3%，而且随着自博弈轮次增加，测试题的区分能力反而在下滑——没有高质量的测试题种子，迭代进化无从启动。

去掉整个自博弈阶段，BoN从36.7%跌至33.0%，测试题准确率从78.7%跌至55.7%——说明初始质量再好，也需要迭代净化来进一步提升。

去掉"打破虚假耦合"这一步（第二步），BoN下降约1.7个百分点。这看起来不多，但在高难度测试集上，这种"错误代码与错误测试题配对"的干扰如果不及时清除，会随着轮次积累放大负面影响。

去掉"针对最可靠且有区分度的测试题修复代码"这一步（第三步），BoN下降约0.9个百分点。关键在于"针对性"——如果随机选一道测试题来指导代码修复，效果明显变差，说明选哪道题来当"导师"至关重要。

去掉"自洽验证"（即不再要求测试题答案多次计算一致），测试题准确率从78.7%跌至63.7%，BoN也下降约3.4个百分点——验证了"宁缺毋滥"的测试题筛选策略的必要性。

去掉"随机初始测试题"（只用攻击性思路生成测试题），测试题的多样性（UT rank，即独特输入数量）在整个自博弈过程中始终偏低——说明随机测试题起到了"补充多样性"的作用，防止测试题池陷入同质化。

---

六、可推广性：只适用于特定模型吗？

CoSPlay的一个重要特性是"模型无关性"——它不依赖特定模型的内部结构，任何能生成代码和测试题的语言模型都可以受益。

研究团队在七种不同的模型上验证了这一点，涵盖纯指令微调模型（Seed-Coder-8B-Instruct、DeepSeek-Coder-V2-Lite-Instruct-16B）、强化学习调优模型（Absolute-Zero-7B、AceCoder-Rule-7B、AceCoder-RM-7B）以及顶级大模型（DeepSeek-V3.2-685B、Gemini-2.0-Flash）。在这七种模型上，CoSPlay将平均BoN从37.8%提升到45.3%，绝对提升7.5个百分点。

不过，研究团队也坦诚地指出了两类边界情况。其一，如果模型能力太弱，生成的代码和测试题质量太差，通过率信号就失去了区分好坏的能力，自博弈反而可能加剧噪音。其二，如果模型已经非常强悍、在某个测试集上接近饱和，那么剩余的低通过率样本本身质量已经和新生成的差不多，替换改动反而引入随机性，带来波动而非提升。对于Gemini-2.0-Flash在LiveBench上的表现，这种饱和效应确实导致了轻微下滑。

这给出了一个直观的"甜蜜区"判断标准：当模型的初始能力足够让通过率信号与真实质量正相关，同时当前池子里还有明显的低质量样本值得替换时，CoSPlay的收益最大。对大多数中等难度以上的编程测试场景，这个条件都能满足。

---

七、成本与收益：值不值得用？

一个现实的问题是：CoSPlay的迭代自博弈，必然比直接生成代码消耗更多计算资源。完整版CoSPlay在Qwen2.5-7B上平均消耗约68.2万个token，而直接生成只需约628个token。但关键在于，相比之下，把样本数暴力扩展到256个（消耗74.5万token）的朴素方法，准确率才22.5%；消耗116.6万token的ThinkCoder（Round 2），准确率只有25.3%。CoSPlay用更少的token，取得了远高于这些方法的37.2%准确率。

研究团队还提供了两个轻量化变体：去掉自洽验证后，token消耗降至24.4万，准确率仍有34.2%，仍然超过所有竞争方法；进一步去掉测试题迭代更新后，token消耗降至9.0万，准确率32.5%，也依然略微超过最强竞争基线SFS（Round 80）的32.0%。这说明CoSPlay的核心收益主要来自框架设计本身，即使去掉最耗资源的模块，基础优势依然保持。

此外，随着候选代码数量（k）的增加，CoSPlay的准确率持续提升，在k=64时仍未见饱和，展示了良好的"越多候选越好"的扩展性。相比之下，单纯增大采样数的朴素方法，往往在k较大时准确率反而下滑（因为没有有效筛选机制，越来越难从大量候选中挑出正确答案）。

---

归根结底，CoSPlay这项研究讲述的故事，是一个关于"在不确定环境下如何建立可靠自我评估机制"的故事。它的核心洞察是：即使没有外部标准答案，通过让代码和测试题在执行矩阵里互相挑战、互相净化，系统内部的"多数共识"本身就携带了关于质量的有效信息。正确的东西倾向于彼此认同，错误的东西倾向于各自为政——这个规律在代码领域被CoSPlay精准地利用了。

这项研究对普通人的潜在影响是实际的：它降低了让AI辅助编程变得可靠的门槛，不再需要大量昂贵的人工标注数据，任何个人或机构都可能在自己的场景下部署类似机制，让AI的代码能力在使用过程中持续进化。而对于整个AI研究社区而言，CoSPlay提供了一套"无监督内部质量评估"的方法论框架，理论上可以推广到任何有"可执行验证"特性的任务——只要能运行代码、检查输出，就可以构建类似的共进化机制。

当然，这条路并非没有边界。依赖可执行环境这一前提，意味着CoSPlay暂时无法直接应用于无法运行代码的推理任务。如何将这套共进化框架推广到更广泛的可验证推理场景，以及如何进一步降低token消耗，是研究团队指出的未来方向。有兴趣深入了解技术细节的读者，可通过arXiv论文编号2605.23491获取完整论文。

---

Q&A

Q1：CoSPlay方法不需要任何标准答案是如何实现准确率验证的？

A：CoSPlay利用了一个关键统计规律：在一批自生成的代码和测试题中，通过率越高的测试题答案越可能正确，通过率越高的代码越可能真正能解题。研究团队从理论上证明了这一点，并用实验验证了通过率与真实正确率之间存在显著的单调正相关关系。换句话说，系统内部的"多数投票"机制本身就携带了质量信息，不需要外部标准答案来校准。

Q2：CoSPlay方法中所说的"虚假耦合"具体是什么问题，有多严重？

A：虚假耦合是指错误代码恰好通过了答案也错误的测试题，产生假阳性通过记录，从而让错误代码获得不应有的高分。比如，一个把所有情况都输出"0"的错误代码，可能恰好通过了一道预期答案也是"0"但其实设计有误的测试题。这会干扰整个排序机制，让好代码被淘汰、坏代码被保留。CoSPlay专门设计了第二步"打破虚假耦合"来识别并替换这类可疑测试题。

Q3：CoSPlay方法适合在个人电脑或小型团队环境中使用吗？

A：完整版CoSPlay需要消耗约68万个token来处理一道题，对算力有一定要求，通常需要GPU服务器。不过论文提供了两个轻量化变体：去掉自洽验证后token消耗降至约24万，去掉测试题迭代更新后进一步降至约9万，后者的成本与普通的"生成16个候选然后筛选"方法相当，但准确率仍然超过现有主流方法。对于小型团队，轻量版是更现实的选择。