💻 computer science

ZeroCoder: Can LLMs Improve Code Generation Without Ground-Truth Supervision?

本文提出了名为 ZeroCoder 的无标签协同进化框架，通过联合训练代码生成器与测试生成器，利用自生成的代码 - 测试交互反馈及动态贝叶斯选择器（DyB4）解决奖励稀疏与选择器漂移问题，从而在无真实监督的情况下显著提升了代码与测试的生成质量。

原作者： Lishui Fan, Mouxiang Chen, Tingwei Zhu, Kui Liu, Xin Xia, Shanping Li, Zhongxin Liu

发布于 2026-04-10

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Lishui Fan, Mouxiang Chen, Tingwei Zhu, Kui Liu, Xin Xia, Shanping Li, Zhongxin Liu

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

这篇论文介绍了一个名为 ZeroCoder 的有趣系统，它的核心目标是：让 AI 写代码的能力变强，但完全不需要人类老师（Ground-Truth）来批改作业。

想象一下，你正在教一个学生（AI）写代码。通常，你需要给他题目，然后给他标准答案和测试题，告诉他“做对了”还是“做错了”。但标准答案和测试题太贵、太少了，不够用。

ZeroCoder 的想法是：让学生自己出题，自己做题，自己互相批改。

下面我用几个生动的比喻来解释它是如何做到的：

1. 核心概念：双人舞（代码与测试的“共进化”）

以前，AI 写代码时，测试题通常是固定的（像死板的考官）。如果 AI 变聪明了，能骗过那些简单的测试题，但考官还是老样子，AI 就学不到新东西了。

ZeroCoder 把 AI 变成了两个角色，让它们像跳双人舞一样互相配合、互相促进：

角色 A（程序员）： 负责写代码解决方案。
角色 B（测试员）： 负责写测试题（用来检查代码对不对）。

比喻：
想象一个拳击训练场。

程序员是拳手，测试员是陪练。
如果陪练太弱（只会出简单的直拳），拳手随便打打就能赢，拳手就永远练不出真本事。
如果陪练太强（还没练好就出重拳），拳手根本接不住，也学不到东西。
ZeroCoder 的妙处在于： 它让陪练（测试员）和拳手（程序员）一起变强。
- 当拳手变强了，陪练必须想出更刁钻的招式（更难的测试题）才能难倒他。
- 当陪练变强了，拳手就必须写出更完美的代码才能过关。
- 这样，两者在“互相较劲”中共同进步。

2. 三大挑战与解决方案

虽然想法很美好，但实际操作中有三个大坑，ZeroCoder 用三个聪明的方法填上了：

挑战一：题目太简单或太难，大家都“躺平”

如果题目太简单，所有代码都能通过；如果太难，所有代码都报错。这时候，AI 就分不清谁好谁坏了，学不到东西。

解决方案：像筛子一样过滤（离线预筛选）
ZeroCoder 在正式训练前，先让 AI 试做一遍。它不看答案对不对，而是看代码和测试题互动的“花样”够不够多。
- 比喻： 就像在选运动员。如果所有选手都跑 100 米，有的跑 10 秒，有的跑 11 秒，这能看出水平。但如果题目太简单，大家都跑 5 秒；或者太难，大家都跑不动。ZeroCoder 会把这种“没花样”的题目筛掉，只留下那些能让 AI 分出高下的“好题目”。

挑战二：测试员太水，只会出“假考题”

刚开始时，AI 写的测试题可能很烂，比如只测试“输入是空”这种简单情况，或者写个 assert True（永远为真）来糊弄。这样程序员就能轻松过关，但学不到真本事。

解决方案：变异测试（Mutation Reward）
ZeroCoder 给测试员加了一条规则：“你的测试题必须能抓出‘伪装者’。”
- 比喻： 假设程序员写了一个看似完美的代码，但里面藏着一个微小的逻辑漏洞（就像把“苹果”写成了“梨”）。ZeroCoder 会故意把代码里的词偷偷换掉（变异），生成一个“坏代码”。
- 如果测试员能发现这个“坏代码”并报错，说明测试员很厉害，给高分。
- 如果测试员没发现，说明它太水了，给低分。
- 这逼着测试员必须写出能“照妖”的题，从而倒逼程序员写出更严谨的代码。

挑战三：裁判的尺子歪了（选择器漂移）

在训练过程中，AI 的能力一直在变。一开始，AI 写的代码很烂，测试题也很烂。后来 AI 变强了。如果裁判（选择器）还拿着一开始的旧标准来打分，就会出错（比如把以前能骗过旧测试题的“坏代码”误判为“好代码”）。

解决方案：动态校准（DyB4）
ZeroCoder 发现裁判的尺子会“漂移”。为了解决这个问题，它引入了一个动态校准机制。
- 比喻： 就像体育比赛，裁判每隔一段时间就要重新校准一下秒表。ZeroCoder 只需要极少量的真实答案（比如 10 道题），就能告诉裁判：“现在的 AI 水平变了，你的打分标准也要跟着变。”
- 这让裁判始终能准确判断谁强谁弱，不会因为标准过时而乱打分。

3. 结果如何？

实验证明，这套方法非常有效：

完全不用人类答案（Label-Free）： 即使没有人类提供的标准答案，ZeroCoder 也能让 AI 的写代码能力大幅提升（比如提升了 14.5%）。
只需一点点人类答案（Small-Label）： 如果只给 10 道题作为校准，效果更是惊人（提升了 21.6%），甚至接近那些拥有海量标准答案的“神仙”训练模式。
双向提升： 不仅代码写得更好了，AI 出题（写测试）的能力也变强了（提升了 24.3%）。

总结

ZeroCoder 就像是一个自我进化的“黑客松”训练营：
它不依赖昂贵的“标准答案”，而是让 AI 扮演程序员和测试员两个角色，通过互相出题、互相找茬、互相变强的方式，在不断的“内卷”中提升实力。

以前： 老师出题，学生做题，老师批改。
现在： 学生 A 出题，学生 B 做题，然后互相批改。如果谁出的题太水，谁就扣分；如果谁做的题太假，谁就扣分。

这种方法不仅省去了昂贵的“老师”（人类标注数据），还让 AI 在自我博弈中变得更加聪明和严谨。

ZeroCoder 技术总结

1. 研究背景与问题定义

背景：代码生成是软件工程中的核心任务。基于可验证奖励的强化学习（RLVR）通过执行反馈显著提升了大语言模型（LLM）的代码生成能力。然而，现有的 RLVR 流程高度依赖人工编写的单元测试或基于参考解生成的测试用例作为验证器。随着数据规模扩大，高质量监督数据的获取成本高昂且稀缺，成为进一步发展的瓶颈。

核心问题：

监督稀缺：能否在不依赖真实标签（Ground-Truth）的情况下提升代码生成能力？
自生成测试的局限性：现有的自奖励机制（Self-Rewarding）多依赖模型内部的一致性（如投票），容易强化错误路径；而基于自生成测试的方法受限于测试生成模型本身的性能，生成的测试往往缺乏区分度（Discriminativeness），导致奖励信号噪声大。
选择器漂移（Selector Drift）：在协同进化过程中，固定的选择规则（如基于固定先验的贝叶斯选择器）可能因模型能力的动态变化而失效，导致奖励信号质量下降。

目标：提出一种完全无标签（Label-Free）的框架，通过代码生成（Coder）和测试生成（Tester）的协同进化（Co-evolution），利用自生成的代码 - 测试交互反馈来同时提升两项任务。

2. 方法论：ZeroCoder 框架

ZeroCoder 是一个完全无标签的协同进化 RLVR 框架，其核心思想是让同一个模型交替扮演“代码生成器”和“测试生成器”的角色，通过两者的交互产生监督信号。

2.1 核心流程

采样与执行：
- 对于每个问题，Coder 生成 $N$ 个候选解，Tester 生成 $M$ 个候选测试。
- 执行所有 $(Solution, Test)$ 对，构建通过矩阵（Passing Matrix） $E$ ，其中 $E_{ij}=1$ 表示解 $i$ 通过测试 $j$ 。
选择器（Selector）：
- 基于矩阵 $E$ ，使用选择算法（如 MaxPass, CodeT, B4）识别出“共识子集”：即一组大概率正确的解（ $C_S$ ）和一组与其一致的测试（ $C_T$ ）。
奖励构建：
- Coder 奖励：如果解被选入 $C_S$ ，则给予正奖励（二元奖励）。
- Tester 奖励：包含三个部分：
  - 代理一致性项（Proxy-Agreement）：测试若能通过共识解，给予奖励。
  - 区分度项（Discriminative Term）：引入变异测试（Mutation Testing）。测试若能杀死（Fail）共识解的变异体，给予额外奖励。这迫使测试不仅验证正确性，还要能区分细微的错误。
  - 格式项（Format Term）：惩罚不可执行的测试。
- 课程学习（Curriculum）：通过调度器 $\lambda_k$ 动态调整区分度项的权重，初期侧重测试的有效性，后期侧重区分度。

2.2 关键组件设计

离线基于排名的预过滤（Offline Rank-based Pre-filtering）：
- 问题：太简单或太难的问题会导致通过矩阵退化（全 1 或全 0），无法提供有效的梯度信号。
- 方案：在训练前，计算每个问题通过矩阵的秩（Rank）。仅保留秩高于阈值 $\tau$ 的问题。秩越高，代表交互模式越多样，信息量越大。
交替更新（Alternating Updates）：
- 在训练步骤中交替更新 Coder 和 Tester，避免非平稳性（Non-stationarity）问题。
动态 B4 选择器（$DyB4$）：
- 问题：静态选择器（如固定先验的 B4）在训练过程中会因模型能力漂移而产生“选择器漂移”，导致选择质量下降。
- 方案：$DyB4$ 是一个动态校准的贝叶斯选择器。它利用极少量（如 10 个）带标签的校准集，在每个训练步骤前动态调整贝叶斯先验超参数，使选择器始终适应当前 Coder/Tester 的能力分布。

3. 主要贡献

ZeroCoder 框架：提出了首个完全无标签的协同进化 RLVR 框架，通过代码与测试的相互博弈，利用自生成的交互信号同时优化代码生成和测试生成能力。
**选择器漂移分析与 $DyB4 $**：首次识别出协同进化中的“选择器漂移”现象，并提出了$ DyB4$。该方法仅需极少量标签（10 个实例）即可动态校准选择器，显著提升了奖励信号的质量。
关键机制验证：
- 证明了基于秩的预过滤能有效剔除低信息量样本。
- 证明了基于变异的区分度奖励是防止测试生成退化为“通过所有测试”的关键。
实证结果：在多个模型和基准测试上，ZeroCoder 在无标签设置下取得了显著提升，且配合 $DyB4$ 后性能接近甚至媲美有真实标签监督（Oracle）的训练效果。

4. 实验结果

实验在三个模型（Qwen2.5-1.5B, Qwen3-4B, Qwen2.5-Coder-7B）和六个基准（MBPP, LiveCodeBench, APPS, CodeForces 等）上进行。

无标签设置（Label-Free）：
- 在 Qwen2.5-Coder-7B-Instruct 上，ZeroCoder（使用静态选择器 B4）相比基线模型，代码生成性能提升 14.5%，测试生成性能提升 15.6%。
- 证明了自生成的代码 - 测试交互本身即可作为有效的监督信号。
小标签设置（Small-Label with $DyB4$）：
- 引入仅 10 个带标签实例进行 $DyB4$ 校准后，Qwen2.5-Coder-7B-Instruct 的代码生成提升达到 21.6%，测试生成提升 24.3%。
- 性能表现与使用完整真实标签的 Oracle 训练（Oracle-supervised）相当，甚至在某些指标上更优。
消融实验：
- 移除变异奖励（Mutation Reward）导致代码生成性能显著下降，证实了区分度测试的重要性。
- 预过滤（Pre-filtering）在适度阈值下效果最佳，过严的过滤会导致数据稀缺。
- $DyB4$ 对校准集大小不敏感，10 个样本已足够。

5. 意义与影响

突破监督瓶颈：ZeroCoder 证明了在缺乏昂贵的人工标注数据（Ground-Truth Tests/Solutions）的情况下，LLM 依然可以通过自我博弈和协同进化实现显著的性能提升。这为代码生成领域提供了一种可扩展、低成本的训练范式。
协同进化机制：揭示了代码生成与测试生成是互补任务。通过让模型同时扮演两个角色并相互施压，可以打破单一角色优化的局限，生成更具区分度的测试和更鲁棒的代码。
动态校准的重要性：指出了在动态训练环境中，静态选择规则会失效，提出了轻量级的动态校准方案（$DyB4$），为未来的自适应 RL 系统提供了新思路。
接近 Oracle 性能：在仅需极少量标签（10 个）进行校准的情况下，达到了接近全监督训练的效果，极大地降低了高质量代码生成模型的训练门槛。

总结：ZeroCoder 通过巧妙的协同进化设计和动态校准机制，成功解决了无监督代码生成中的奖励稀疏和选择器漂移问题，为构建自进化的代码生成系统奠定了坚实基础。