CoSPlay: 测试时基于自生成代码与单元测试的协作自对弈

TL;DR CoSPlay 在无需真实单元测试 (GT UTs) 的情况下，通过协同自博弈让自生成代码与单元测试相互纠错、迭代优化，并基于输出共识选择最终解答，在代码生成基准上达到或超越需 GT UTs 的 RLVR 训练方法。

问题

问题背景

LLM 代码生成正从纯采样向可验证奖励引导的推理时扩展 (Test-Time Scaling) 演进。RLVR 和 TTS 方法依赖可执行验证反馈来筛选/改进候选代码，大幅提升了 pass@k 等指标，但过程离不开 Ground-Truth Unit Tests (GT UTs) — 预先写好的正确测试用例。

现有方法局限

• RLVR（如 CURE）在训练阶段需要用 GT UTs 计算奖励，成本高昂且阻碍规模化；
• TTS 方法本身不需要训练，但现有 TTS 如自我精炼 (self-refine) 或 Best-of-N 在没有 GT UTs 时性能急剧下降，因为只能靠模型自信度投票，缺乏客观正确性信号；
• GT-free TTS 尝试用自生成 UTs 代替 GT，但这些 UTs 噪声大、覆盖率低，常与错误代码形成虚假耦合（一段错误代码恰好通过不完善的测试），而 UT 的质量又无法在没有可靠代码的条件下验证，形成死循环。

为什么这个问题难/重要

挑战：代码正确性与测试有效性的相互依赖本质——“先有鸡还是先有蛋”问题。单独优化任何一方都会因另一方不可靠而引入偏差。需要一种机制让两者在推理阶段协同演化，通过双向信号互相校正，而非单向依赖。

重要性：真实开发场景中，为新需求编写代码时往往没有现成的单元测试，开发者需同时构思实现和验证逻辑。赋予 LLM 类似能力，可大幅降低对人工标注测试的依赖，实现 zero-shot 高可靠性代码生成。这直接关系到推理时计算预算的利用效率和部署可行性。

行业类比

类似 GANs 中生成器与判别器的对抗训练，但 CoSPlay 是合作博弈而非对抗：代码和测试通过执行矩阵的双向通过计数相互促进，最终在无外部监督的情况下输出一致可靠的解决方案。

核心洞察

• CoSPlay 首次将无 ground-truth unit test 的测试时扩展建模为 code 与 unit test 的双向协同演化问题，而非单向的代码筛选。现有 GT-free TTS 方法仅用自生成 UT 评估代码，忽略了 UT 本身的噪声和虚假耦合；CoSPlay 则通过执行矩阵的互通过数 (bidirectional pass-count signals) 同时修剪弱代码、刷新不可靠 UT，使二者质量相互促进。这一设计让 UT 的准确性从 14.6% 提升至 78.3%，从而在无任何训练数据的情况下达到与 RLVR 训练模型相当甚至更优的性能，为纯推理阶段的代码生成提供了可扩展且无需标注数据的竞争力方案。
• 当多个代码候选取得相同最高通过数时，CoSPlay 放弃随机选择或简单多数投票，转而采用基于输出一致性聚类的决胜策略。论文观察到正确代码在相同输入下输出一致而错误代码发散，因此选择最大共识簇中的代码，有效利用了 LLM 对输入的内在语义一致性。这与传统 BoN 或 self-consistency 的投票机制有本质区别：后者仅统计最终答案的频率，而 CoSPlay 在选码阶段即引入了一致性信号，使得决策可解释性更强，并在同等算力预算下显著提升 BoN 指标，尤其在困难基准上展现了更强的泛化能力。

方法

核心思路

CoSPlay 是一个无需 ground-truth 单元测试 (GT-free)、无需额外训练的推理框架，通过合作式自博弈 (cooperative self-play) 联合优化代码生成与单元测试 (UT) 质量，从而在没有 GT 的情况下提升代码生成的正确性。

输入与初始化

• 输入：编程问题描述。
• 生成初始代码池与 UT 池：利用 LLM 对同一问题进行多样化解题思路采样，并针对每种思路生成配套的单元测试。

关键模块

1. 差异化 UT 生成

框架首先分析不同解题思路的潜在失败模式，生成具有区分力的 UT 集合。这些 UT 不仅验证常见情况，更刻意捕捉不同实现间的行为差异，为后续合作进化提供丰富信号。

2. 合作自博弈迭代

构建 Code-UT 执行矩阵，记录每个代码样本通过每个 UT 的情况。使用双向通过计数信号驱动迭代优化：

• 弱代码剪枝/修复：通过率过低的代码被移除或基于通过的 UT 进行修复。
• 不可靠 UT 替换：与多数代码行为不一致的 UT（如与错误代码伪相关）被替换或刷新。

代码池和 UT 池在迭代中相互进化和提纯，无需 ground-truth 标定。

3. 最终选择策略

当多个代码达到最高通过计数且难分优劣时，采用输出共识聚类：对同一测试输入，正确代码会给出相同输出，而错误代码则发散。选择最大共识簇中的代码作为最终答案。

输出

• 最优代码解决方案。
• 高质量的自生成 UT 集合（可用于后续验证或复用）。

与同类方法的差异

现有 GT-free 测试时缩放方法直接使用自生成 UT 进行重排序或修复，但 UT 质量无法自验证，容易与错误代码形成虚假耦合。CoSPlay 通过合作式共同进化同时提纯代码与 UT，在无外部监督信号下突破这一瓶颈，推理阶段即可实现与有 GT 训练的 RLVR 模型相当的性能。

实验

实验在四个具有挑战性的代码生成基准上评估 CoSPlay，使用 Qwen2.5-7B-Instruct 作为基础模型。方法无需训练，在测试时通过协同自博弈（cooperative self-play）同时优化代码候选与自生成的单元测试（UT）。首先利用大模型生成多样化解题思路与判别性 UT 构想，然后构建 Code-UT 执行矩阵，基于双向 pass-count 信号迭代淘汰弱代码、修复不可靠 UT，最终通过输出一致性聚类（output-consensus cluster）选出最佳代码。

关键发现：CoSPlay 在 Qwen2.5-7B-Instruct 上将平均 BoN 从 22.1% 大幅提升至 33.2%（绝对提升 11.1 个百分点），UT 准确率从 14.6% 提升至 78.3%，展现出强大的联合优化能力。该方法甚至匹配或超越了依赖真实单元测试训练的 RLVR 模型 CURE-7B，并在应用于 CURE-7B 时进一步带来 5.7% 的 BoN 增益。这表明 test-time 的协同演化可以有效弥补训练阶段对 expensive ground-truth 的依赖。

与基线对比的深度解读：相比其他 Ground-Truth-free 的 Test-Time Scaling 方法，CoSPlay 在相同 token 预算下表现更优，且随着预算增大性能持续提升，验证了其可扩展的推理策略。传统方法仅用自生成 UT 做选择或精炼，而 CoSPlay 通过双向信号打破代码与 UT 质量的相互制约，使得两者共同进化，这是性能显著优于先前方法的核心原因。

行业影响

落地场景

CoSPlay 无需真实单元测试（GT UTs）即可提升代码生成质量，适合缺少高覆盖率测试套件的产品开发场景。典型应用包括：

• 低代码/无代码平台：自动生成后端逻辑时，利用自博弈机制验证并优化代码，减少人工编写测试成本。
• 企业内部开发者工具（如 IDE 插件、CI/CD 流水线）：在开发者提交代码片段时，自动生成并执行自测用例，实时反馈潜在缺陷。
• 开源社区自动化：为 Pull Request 自动生成代码审查建议和测试用例，提升协作效率。

商业价值

• 降本：消除对昂贵人工标注测试用例的依赖，尤其在业务逻辑快速迭代的 SaaS 场景下，可节省大量测试工程人力。
• 增效：推理时自博弈（test-time scaling）允许模型自我提升，无需重新训练，降低模型更新成本。实验表明，在 Qwen2.5-7B-Instruct 上通过率（BoN）从 22.1% 提升至 33.2%，超过需强监督的 CURE-7B，意味着小模型即可达到此前需昂贵 RLVR 训练的性能。
• 体验提升：在交互式编程环境中，更快给出更可靠的代码建议，降低用户调试时间。

与现有工作流的集成

CoSPlay 作为推理时框架，可即插即用到现有 LLM 代码生成服务中：

1. 部署为推理中间件：在 LLM API 之上封装一层自博弈引擎，接收 prompts，输出经多轮协同优化的最终代码和测试套件。
2. 与 Git-based CI 集成：在代码提交后触发 CoSPlay，生成针对性测试并验证补丁，将结果回注到 Pull Request。
3. 兼容主流框架：可轻松适配 LangChain、Semantic Kernel 等工具链，作为自定义 Agent 工具使用。

具体落地用例

• 电商平台促销规则引擎：运营配置复杂折扣逻辑时，传统开发需大量测试边界条件。CoSPlay 可自动生成代码并自我验证，确保规则正确，上线周期从数天缩短至小时级。
• 医疗数据处理脚本生成：研究机构清洗临床数据时，需要高可靠性代码。CoSPlay 通过自生成测试保证数据转换准确性，降低因错误代码导致的科研风险，同时无需临床专家编写测试用例。

局限

• **推理开销较大**: CoSPlay 需要在测试时进行多轮 LLM 调用(代码/测试生成、修复、聚类等),并反复编译运行代码与测试矩阵,导致推理时间与计算成本显著高于普通采样或单次自修复方法。论文虽展示了随 token 预算增加的持续收益,但在低延迟或强预算约束场景(如交互式编程助手)中实用性受限,实际部署需权衡响应速度与代码质量提升。
• **对初始池质量敏感**: 方法依靠初始代码和自生成测试的多样性启动协同演化。若初始生成池中正确代码稀少或测试缺乏区分度(例如在简单任务上生成的都是弱测试),双向 pass-count 信号可能无法有效驱动迭代提升,甚至出现错误代码伪共识。论文在困难基准(LiveCodeBench)上提升明显,但在低难度任务上的增益与失败案例分析较少。
• **适用问题类型受限**: CoSPlay 强依赖运行时可验证信号(pass/fail),对于需要复杂环境依赖、非确定性输出或需要人工评判语义正确性(如自然语言生成、部分 API 调用逻辑)的任务,自生成测试难以自动评估代码真实性。与基于 GT 的方法相比,它在无明确测试框架的现实应用场景(如数据分析脚本)中可能失效;另外,其协同演化未显式处理逻辑错误不触发异常的情况,可能导致测试集覆盖不足,最终代码含隐性缺陷。