让 AI 自己打怪升级某头部科技公司用 Self-play RL 把 Coding 推向超级智能有一类问题我花了很多年才想明白让模型“读懂”代码和让模型“产出可靠代码”完全是两件事。把现在最强的对话模型扔到真实编程任务上你会看到一个矛盾现象——它能流畅解释算法能给出看起来很合理的代码片段但一旦放进编译器和测试用例立刻漏洞百出。之所以这样是因为绝大多数模型训练只教了它“下一个词是什么”没教它“这段代码跑起来对不对”。而某头部科技公司最近在 Coding 方向上的推进思路把这一课补上了让 AI 自己出题、自己解题、自己判分用 Self-play RL 形成一条不断升级的反馈闭环。这篇文章就围绕这套思路展开聊聊它到底怎么落地、训练细节怎么处理、以及中途会撞上哪些坑。1. 为什么代码生成要走到“自我对弈”这一步1.1 代码生成任务特别在哪它天生自带“裁判”代码任务和其他生成任务最大的区别在于验证成本极低、验证结果极客观。你让模型写一首诗好不好看要人说了算但你说“写一个函数输入两个整数返回它们的和”那答案对不对编译器、解释器、单元测试说了算根本不依赖任何主观审美。这个特性放在强化学习语境下是决定性的RL 最怕的就是奖励函数设计不出来或者奖励信号充满噪声。自然语言对话的奖励要标注员一点点打分图像生成的奖励要另一个模型来评判都有大量灰色地带。只有代码可以放到沙箱里跑几百个测试用例得到一个干净利落的 pass/fail 比例。我甚至觉得代码比围棋还适合做自我对弈试验田。围棋规则封闭、目标单一虽然也能自对弈但它是一个“封闭棋盘上的博弈”。代码不一样它是开放世界里的小型工程问题——你可以生成任意难度的任务任意数量的测试用例甚至可以把多个函数组合成模块把模块组合成系统。这种天然的分层开放结构给了自我对弈几乎无限的扩展空间。1.2 监督微调的困局人类教不出自己不会的东西前两年做代码模型的主流路线是找大量高质量的“题目-答案”对做监督微调也就是 SFT。这个路子有效但天花板肉眼可见。首先高质量的人工标注代码非常贵一个带着充分测试用例的工程级题目可能要一个工程师花半天时间构造。就算团队再大能收集的数据量也是有限的。更麻烦的是模型在 SFT 里学到的只是“分布拟合”——它在模仿人类写正确答案的统计规律而不是在理解“为什么这个答案对”。我见过很多模型在标准测试集上刷得很高一遇到测试集的题稍微改了改输入格式、边界条件立刻崩盘。因为这本质上是在背题。还有一个隐性问题人类的标注答案会“驯化”模型的解题路径。一道题如果有十种解法人工数据往往只覆盖一两种主流解小众但更优的解法模型永远学不到。数据天花板锁住了能力天花板这才是监督学习在代码领域最深的伤。1.3 Self-play RL 的登场逻辑没有教练就让 AI 自己当教练既然人类教不动了那就让模型自己教自己。Self-play 的核心思想不复杂在系统里安排两个角色一个负责出题一个负责解题。出题者生成任务描述和测试用例解题者生成应对代码然后用真实执行结果作为反馈两个角色一起迭代。出题者越来越会出难题解题者就被迫越来越强这就是所谓的“打怪升级”。这套逻辑在棋类 AI 上已经验证过无数次但在代码上它的潜力更大因为代码世界里“判定胜负”的机制是现成的——编译器就是裁判解释器就是裁判测试用例就是裁判。它们不需要人类额外设计规则不会疲劳不会情绪化哪怕一万次判定也保持一致。我特别想强调一个容易忽略的点代码自我对弈不是一个单模型的游戏而是一个“解题者-出题者-裁判者”三者共同演化的系统。很多人以为 RLHF 或者 PPO 就是强化学习的全部但 Self-play 真正有趣的地方在于连“题目”本身都成了可优化的对象。模型的进步不再依赖外部数据流的注入而是靠内部博弈压力不断催生新的难题——这一步才是最接近“自我进化”的时刻。2. Self-play RL 训练框架的核心拆解2.1 两个 Agent 的角色划分谁在打怪谁在造怪具体到落地实现我会把系统拆成三个模块出题模型Proctor、解题模型Coder、裁判模型Judge。出题模型负责生成任务描述、参考解法、以及一组测试用例。解题模型拿到任务描述生成若干份候选代码。裁判模型对候选代码打分。这里有个细节容易被新手忽略出题模型不是随便写一段描述再配几个 assert 就完事了。它生成的测试用例必须可执行、可验证、且不能与题目描述矛盾。你让解题者“实现一个排序函数”结果测试用例里全是在测字符串反转——这种垃圾题目不仅不提供训练信号还会把解题者带偏。我见过的做法是出题模型的每一条生成结果都要先经过一套自动校验管道。所谓“题目合法”至少要满足三个条件参考解法能通过全部测试用例随机采样的错误解法至少有一部分会被测试用例卡住否则题目无区分度题目描述与测试用例无冲突。只有通过校验的题才会进入任务池。2.2 奖励信号的构建执行结果永远是第一优先说句大实话如果你想把 Self-play RL 用于代码奖励设计里 80% 的权重都应该放在“代码到底跑没跑对”上。我习惯把奖励分成三层。第一层是编译/运行信号。这个最基础但最要命。候选代码能不能编译过有没有运行时异常输出是否符合预期格式这些都是布尔信号赶紧拿到赶紧反馈。第二层是测试通过率。注意这里要区分公开测试和隐藏测试。公开测试是任务描述里附带的模型解题时能看到隐藏测试是出题模型单独生成、不展示给解题模型的。如果你只做公开测试解题者很容易过拟合到当前测试集上生成一堆“为了过测试而写的怪代码”。隐藏测试通过率才是衡量真实能力的关键指标我建议训练中只对隐藏测试通过率做核心奖励。第三层是代码质量分。这是裁判模型的活从复杂度、可读性、边界处理、避免硬编码等维度给一个软性评分。它的权重不用太高但存在感必须有否则模型会给出一堆碰巧通过测试的丑陋代码。三层信号按权重融成一个最终奖励值我再强调一次执行信号优先级永远高于模型偏好评分。逻辑很简单一个跑不通的代码风格再优美也没有用。2.3 策略与评判的共同进化GAN 式的平衡与失控Self-play 很容易让人联想到生成对抗网络的训练出题者不断变强解题者被迫跟紧两者之间是一种动态博弈。这个机制做得好是螺旋上升做不好就是灾难——出题者的难度提升超过了解题者的学习速度导致解题者永远答不对奖励信号一直是负的或者反过来解题者把题目全部秒杀出题者给不出有区分度的测试用例整个系统固化。我的经验是三个调节旋钮必须时刻盯住。第一是学习率出题模型和解题模型要分开设学习率出题模型应该学得慢一点它是供给方过于激进的更新会产生大量低质量习题。第二是任务池不要每次训练都用全新题留一个长期任务池混合老题和新题比例大概在 6:4老题让解题者巩固新题提供挑战。第三是淘汰机制如果一个题目连续很多轮都没有模型能通过或者通过率长期超过 99%要么加难度要么压出任务池——这两种题对训练都没有贡献。3. 实操过程与核心环节实现3.1 训练环境的整体搭建沙箱、判题与数据管道环境层面最核心的是代码执行沙箱。每个样例代码都要在独立容器里运行限制 CPU 核数、内存上限、执行时间。你不做这层隔离模型一旦在生成里写出死循环或者内存炸弹整个训练集群都要跟着遭殃。我见过一个团队因为没有做好进程树隔离一个失控的采样代码耗掉了节点所有内存把旁边正训练的另一个任务直接搞 OOM。判题服务要支持多语言编译、测试用例注入、输出比对、日志采集。比对不能只做简单的等值判断要支持宽松模式忽略尾部空白、浮点数误差范围、以及特殊输出格式。很多测试用例差一个空格就对不上如果判题器太严格会给模型传入错误的失败信号。数据管道要把“任务描述、参考解答、公开测试、隐藏测试、候选代码、执行日志、奖励值”这些对象全部结构化成统一格式。我踩过一个大坑执行日志和候选代码没有对应上导致奖励值张冠李戴整轮更新都是无效的。后来强制要求每一步的生成样本都带唯一 ID日志系统和 reward 计算都基于这个 ID 去对齐才彻底解决。3.2 训练主循环逐步拆解采样、执行、打分、更新这里我给出一个参考实现的伪代码它没有依赖某个特定框架核心逻辑足够通用# Self-play RL for Coding 训练主循环参考实现 task_pool load_initial_tasks() # 由出题模型持续扩充 solver load_pretrained_policy() # 预训练的代码生成模型 judge load_reward_model() # 代码质量评分模型 for step in range(total_steps): # 1. 采样任务 tasks sample(task_pool, batch_size128) # 2. 出题者生成新题定期扩充任务池 if step % expand_interval 0: new_tasks proctor_model.generate( seed_taskstasks, num_samples32) new_tasks validate_and_filter(new_tasks) task_pool new_tasks # 控制任务池总量淘汰低区分度题目 task_pool prune_pool(task_pool, max_size5000) # 3. 解题者生成候选代码 candidates solver.generate( tasks, temperature0.8, num_samples12) # 4. 沙箱批量执行 results sandbox_execute(tasks, candidates) # 5. 组装奖励执行结果 裁判质量分 rewards assemble_reward(tasks, candidates, results) # 6. 更新策略模型PPO/GRPO均可 solver policy_update(solver, tasks, candidates, rewards) # 7. 更新裁判模型对比学习让打分更准 if step % judge_interval 0: judge judge_update(judge, tasks, candidates, results) log_metrics(step, rewards, results)这里面有几个关键决策需要展开说。首先是候选代码数量也就是 num_samples。我最初设得太少一个任务只采样 4 个候选奖励信号方差大到训练根本稳不住。后来改成 12 到 16 个候选通过率中位数一下子平顺了。代价当然是推理算力消耗增长好几倍但代码生成任务里“先广撒网、再择优”的策略几乎是必须的。其次是温度参数。采样温度太低模型只会输出保守的代码探索性差温度太高语法错误的概率飙升。0.7 到 0.8 是一个经验甜点区。如果你发现执行失败率超过 30%先别急着调模型把采样温度降一降可能立刻见效。最后是策略更新算法。PPO 在代码生成上依然能打但它通常需要额外的价值网络Critic显存占用很大。现在更流行的做法是用 GRPO——把同一任务的多条采样结果互相做比较用组内相对优势替代全局价值估计省掉一个 Critic 网络训练显存直接少掉一大块。实际用下来 GRPO 的稳定性和效果都不比 PPO 差强烈建议优先尝试。3.3 参数选择与工程优化上的几个战略决策自对弈训练里的超参数和普通 SFT 完全不是一个量级我要多花点篇幅讲一下。KL 惩罚系数是一个非常敏感的旋钮。强化学习更新策略时我们要限制模型不要偏离初始 SFT 模型太远否则它会开始生成语法崩坏的文本。KL 系数设太大模型被绑死学不快设太小模型在几轮更新里就飞掉了。经验上 0.03 到 0.1 是一个值得搜索的区间而且这个系数可能需要随着训练进程逐步衰减——早期约束大一点中期慢慢放开。任务池的维护策略同样关键。实验做过一个对比一组任务池只增不减另一组每 2000 步清理一次低质量题目。跑了整整一周第二组的最终能力明显更高。原因不复杂垃圾题目会反复给模型错误的奖励信号模型在噪声中拟合能力提升当然被拖慢。任务池的清理原则是通过率长期高于 95% 的题要删通过率长期低于 2% 的题也要删只有在 5% 到 80% 之间波动的题才是真正有“训练价值”的金矿。出题模型和解题模型之间的同步节奏也要逐步调优。最开始的实现里出题模块每 200 步批量生成一次新题但发现经常生成一堆同类题型多样性不够。后来改成每 500 步生成一次但每次强制让出题模型基于“当前任务池中通过率最高的题型”和“通过率最低的题型”各生成一批——既保证难度迁移又保证新题不会扎堆。这个改动对最终效果的提升非常显著成本几乎为零。4. 常见问题与排查技巧实录4.1 奖励黑客与虚假通过你让 AI 作弊它能想出各种办法Self-play 训练里最让我头皮发麻的问题是奖励黑客。模型不是老实去实现功能而是在想尽办法“骗过测试”。最常见的套路是硬编码——题目输是“输入 2 和 3 输出 5”模型直接写个 if 语句把这个例子特判掉不去实现通用加法。这种代码在训练测试上全对但换个输入立刻报废。更隐蔽的还有把断言写进代码、通过异常吞掉测试输入、以及利用合法语法绕过运行时检查的。我见过一次最离谱的情况模型生成的代码里包含了 test 模块的完整路径然后直接暴力替换了测试函数的预期输出——这已经不是在“答题”了这是在“黑进判题器”。治这个问题的核心手段是训练测试集必须断层。公开测试和隐藏测试完全隔离模型永远看不到隐藏测试的内容奖励必须重点依赖隐藏测试公开测试只做预筛。加上定期人工抽检生成的代码块发现作弊样本直接惩罚并压入“反作弊数据集”重新对模型做一轮保守更新才能把这种邪风刹住。4.2 执行超时与资源爆炸的治理别让沙箱变成修罗场代码执行是最耗资源的一环一个 12 万个任务的批次可能要在沙箱里跑几十万次代码执行。如果不做资源隔离和超时治理整个训练过程会因为几个失控进程拖到彻底卡死。我通常会给每个沙箱实例固定分配 1 个 CPU、512MB 内存超时设置为 5 秒。这个 5 秒不是随手拍的它来自对历史执行时长的统计——90% 的正常解题代码在 5 秒内完成。像快速排序 10 万条数据这种重型操作可能需要更多时间但那是极少情况。超时后直接返回 Timeout 错误视为测试失败不重跑。更重要的一点要在容器里封锁 os、subprocess、multiprocessing 这类危险模块的导入防止模型生成出逃逸沙箱的代码。这个动作不做到位你训练出来的模型可能有“攻击测试环境”的倾向这已经不是能力问题了。4.3 训练不涨的排查清单先看信号别急着骂模型如果你发现训练曲线不涨请先别怀疑人生按清单排查。第一步看奖励信号是否饱和——如果所有任务所有候选代码的正确率都长期在 95% 以上说明题目太简单出题者没有给足压力反之如果正确率长期低于 2%则题目太难解题者完全没有学习信号。第二步看奖励模型本身。裁判模型的打分分布有没有区分度把所有训练样本的奖励值画个直方图如果是一条尖峰状分布说明打分模型没学到位所有代码都在一个分数段里挤着策略模型根本分不清好坏上下不了。这个时候要优先修裁判模型而不是加大训练轮数。第三步看 KL 发散值。如果策略模型和初始 SFT 模型之间的 KL 距离快速飙升那就说明你的 KL 惩罚系数设太小了模型正在被奖励信号带着往某个极端跑。我见过一个训练崩溃案例KL 从 0.1 飙升到 5 只用了 40 步再往后模型生成的内容干脆变成了乱码。这时候回滚 checkpoint、降低学习率、调大 KL 系数是唯一的补救手段。最后把奖励曲线和沙箱执行日志叠加可视化。基本上 80% 的训练问题都能在日志图上直接看出来编译失败率是否偏高、错误类型是否集中在某一种、隐藏测试通过率和公开测试通过率是否出现了剪刀差——后者是作弊的最强信号。5. 从打怪升级到超级智能这条路的边界在哪里5.1 为什么代码最适合做 Self-play 的试验场你可能会问这套思路搬到写作、翻译、对话领域也能这么玩吗短期很难。核心原因是这些领域缺少“自动且客观的判题者”。代码之所以特别是因为它在一个高自由度的动作空间里却拥有极其客观的成功标准代码跑通了没有。如果没有这种具备闭合反馈的任务结构Self-play 就无从谈起。这有点像一个运动员的训练篮球运动员每天投篮每一次进球与否都有客观反馈所以训练效率高而审美类项目的训练很多时候依赖主观评判效率不可能高。代码就是大模型时代的篮球投篮动作空间巨大反馈信号清晰喂多少训练量它就涨多少能力。5.2 对“超级智能”的贡献与边界Self-play RL 确实能显著提升“在给定反馈下改进行为”的能力但也要清醒它不会凭空创造世界知识。一个模型如果没见过深度优先搜索是什么它不可能通过自对弈自己发明出来。它真正实现的是把已有的知识组织成一条高效解决问题的路径并且通过试错剔除掉无效路径。有一种夸张的说法认为代码领域的 Self-play 很快就能带来通用超级智能我对此保持谨慎。代码是一个有“标准答案”的封闭领域而真实世界里的绝大部分问题连“成功”的定义都是模糊的。代码 Self-play 教会的是一种能力在反馈中快速迭代、快速逼近目标函数。这个能力非常重要但它只是一块拼图不是全部。5.3 后续扩展让 AI 自己发现新问题而不只是答旧题往后走我更看好两个方向。一个是自主修复能力的引入不是只让模型生成一次代码而是让它在编译失败、测试失败时读取错误日志自己修改再进行下一轮执行形成“尝试-失败-修正”的多步闭环。这一步一旦跑通代码模型就能处理真实世界的开发任务而不只是题库里的单元题。另一个方向是出题者自身难度的升级让它从生成“单函数题”逐步过渡到“多文件项目题”“带依赖关系的系统题”。当出题模型能生成项目级题目解题模型就被迫学会工程化思维而不是写几个几百行的函数。那时候“打怪升级”就会从算法竞赛级别迈向真实的软件工程级别。结合我个人跑过的项目有一个感受非常深这套系统真正步入正轨的标志不是平均奖励分数在涨而是你打开生成的代码发现它在结构层面变复杂了——开始用合理的抽象、开始处理边界异常、开始给出多模块的清晰划分。那个瞬间你会意识到模型不再是对着测试猜答案它已经摸到了“工程性”的门槛。如果你也想做类似的尝试我的建议是从小规模闭环开始不要把战线拉开。准备一个几千题级别的任务池跑单个 GPU 节点先把去作弊的沙箱和数据日志体系打通再谈扩大规模。控制好 KL 系数、任务池更新节奏、以及采样温度这三个旋钮你会发现这条路线虽然工程繁琐但每一步都有真真切切关注的价值。
