AI 写代码，竟然靠“抄自己作业”变强了：一篇论文揭开大模型代码能力提升的朴素路径
大模型写代码，开始学会“自己教自己”
AI 写代码这件事，过去一年已经从“能不能写”变成了“写得靠不靠谱”。无论是程序员用 Copilot 补全函数，还是创业公司拿模型去跑自动化编程代理，真正卡住大家的，往往不是模型会不会吐出代码，而是它吐出来的代码到底能不能一次跑通。
这也是为什么，arXiv 上这篇题为《Embarrassingly Simple Self-Distillation Improves Code Generation》的论文会显得格外耐人寻味。作者提出了一种几乎朴素到让人怀疑“就这？”的方法：让大模型自己多生成一些代码答案，用合适的温度和截断策略采样，然后再拿这些原始输出反过来做监督微调。没有外部验证器，没有更强的教师模型，也没有强化学习的复杂闭环。结果却不差——以 Qwen3-30B-Instruct 为例，在 LiveCodeBench v6 上的 pass@1 从 42.4% 提升到 55.3%。
这个数字不是小修小补，而是一个颇有分量的跃升。尤其是在代码生成领域，pass@1 的含义很直白：模型第一次给出的答案能不能过测试。它不像聊天场景那样可以靠“多说几句”来补救，代码错一个边界条件，系统就直接判你出局。换句话说，这篇论文最有意思的地方，不只是“又涨点了”，而是它告诉我们：模型能力的提升，未必总要靠更昂贵、更复杂的训练管线，有时更像是把自己脑子里已经有的东西，重新捋顺一遍。
为什么“简单方法”反而有效
如果把今天的代码大模型比作一个见多识广但有点毛躁的工程师，那很多失败并不是因为它完全不会，而是因为它在关键时刻选错了词、走偏了分支、写出了“看起来很对”的废代码。论文作者把这个问题归结为一种“精度—探索冲突”。
这很好理解。模型在生成代码时，一方面需要足够精确，尤其是在函数名、边界判断、变量更新这些不能差一丁点的地方；另一方面，它又需要探索，因为很多编程题并没有单一路径，算法思路、实现细节、数据结构选择都可能有多种可行解。问题在于，解码策略很难同时把这两件事做到最好。温度太低，模型容易保守，沿着一个并不优秀但高概率的路径机械前进；温度太高，又容易在不该发散的地方“灵感过剩”，把代码写飞。
作者的发现是，简单自蒸馏（SSD）似乎在某种程度上帮模型重新塑造了这种平衡。它不是粗暴地让模型更保守，也不是一味鼓励多样性，而是通过把自己采样得到的输出再拿来训练，让 token 分布发生一种“按上下文调整”的变化：该收的时候收，压制那些容易干扰正确答案的尾部噪声；该放的时候放，保留解决复杂问题时需要的探索空间。
这也是整篇论文最有启发性的地方。过去大家一谈“让模型变强”，直觉上总会想到要引入更强老师、奖励模型、过程监督、搜索树、执行反馈……总之系统越复杂越像前沿。可这篇工作像是在提醒行业：别急着造更豪华的训练流水线，也许模型最需要的，不是一个更严厉的教练，而是一面镜子。
它为什么发生在今天，而不是两年前
这件事放在 2026 年特别有意义，因为代码生成已经进入“后训练竞争”阶段。基础模型的预训练规模越来越接近天花板，大家手里拿到的语料、算力、模型架构差异虽然还重要，但已经不是唯一胜负手。真正拉开差距的，越来越是后训练——你怎么对齐、怎么微调、怎么用测试反馈、怎么做合成数据。
这两年，行业里最热的几条路线其实都不轻松。强化学习在数学和代码任务上确实有效，但成本高、工程复杂，而且常常伴随训练不稳定。基于 verifier 的方法也很流行，本质上是让一个系统去判断答案对不对，再反向筛选好样本，但这依赖额外组件，而 verifier 本身也可能有偏差。再往上走，很多 agentic coding 系统靠的是多轮搜索、执行、修复，效果不错，可部署成本、延迟和推理费用都随之上涨。
相比之下，SSD 的诱惑力非常现实：如果你本来就有一个还不错的代码模型，那你也许不需要重新搭一个复杂王国，只要让它多写几版答案，再把这些输出重新喂回去，就能拿到一块可观的增益。这对开源社区尤其友好。不是每个团队都有能力训练奖励模型、构建大规模执行环境、跑长链路 RL。可“采样 + 监督微调”几乎是每个有一定训练资源的团队都能尝试的。
论文里还提到，这种方法不仅在 Qwen 系列有效，在 4B、8B、30B 尺度的 Qwen 和 Llama 模型上都有泛化，既覆盖 instruct 版本，也覆盖 thinking 版本。这个信息很关键，因为它让 SSD 不像一次偶然调参，而更像一种具备平台性意义的后训练技巧。
对行业是好消息，但也别高兴得太早
从记者视角看，我会把这篇论文归入“看似不起眼，实则可能改变方法论”的那一类。它最大的价值，是把很多团队从“非得上复杂系统不可”的路径依赖里拽出来。尤其对中小模型团队、开源社区、垂直场景公司来说，SSD 像一把便宜又趁手的扳手：不是万能，但可能特别常用。
不过，乐观归乐观，几个问题也绕不开。第一个争议是：模型用自己的输出训练自己，会不会把偏见和错误一并固化？这其实是自蒸馏方法的老问题。它能放大模型已有的长处，也可能放大模型习惯性的错法。论文结果显示在代码任务上收益明显，说明采样策略和数据分布控制得不错，但一旦迁移到更开放、更主观、更依赖事实性的任务，这种自我循环是不是还成立，就没那么简单了。
第二个问题是，这类提升是否高度依赖 benchmark。LiveCodeBench 是当前颇受关注的代码评测集，难度和时效性都比很多老 benchmark 更贴近真实世界，这当然是加分项。但真实开发环境不是一道道孤立的题目，而是需求含糊、依赖混乱、旧代码一堆、文档写得像谜语。模型在算法题上更强，不等于它在企业软件开发里就能少踩坑。今天的代码模型，最怕的仍然是“局部很聪明，整体不靠谱”。
还有一个更深的问题：如果简单自蒸馏真的持续有效，会不会反过来削弱大家对外部反馈的重视？我觉得不会。更可能的情况是，SSD 会成为一个基础模块，夹在预训练和更复杂后训练之间。你可以把它理解成一种“先把模型自己的思路梳理顺，再去接强化学习和执行反馈”的中间层。它不是替代品，更像增压器。
从“会生成”到“更会判断”，代码 AI 的下一站在哪里
如果顺着这篇论文往前看，代码生成模型的竞争正在悄悄换赛道。过去比的是谁记得更多 API、谁能写更长函数、谁在 HumanEval 上分高。现在比的则是：谁更懂什么时候该坚定，什么时候该探索；谁能减少那些“明明差一点就对”的低级失误；谁能把推理时的随机性，转化为训练时的资产。
这背后其实是代码任务的特殊性。代码和自然语言最大的不同，在于它既允许多解，又要求精确。你可以用不同算法写出同一道题，但任何一种写法都逃不过编译器和测试用例的冷酷审判。模型必须同时具备创造性和纪律性，这几乎像是在要求一个人既像诗人，又像审计师。
所以我很看好这篇工作带来的一个行业启发：未来最有价值的，不一定是让模型“想得更多”，而是让模型“更会筛掉自己不该想的东西”。这听起来有点拧巴，但对代码来说却非常贴切。很多 bug 不是因为没有灵感，而是因为多余的灵感闯进了不该出现的位置。
如果接下来几个月里，更多团队复现出类似结果，我们可能会看到一种新的常态：代码模型的升级不再总是伴随惊天动地的大训练，而是更多来自一系列便宜、稳健、可复用的后训练技巧。那会是一个很务实的时代。对用户来说，这意味着 IDE 里那个 AI 助手也许不会突然变成“超级程序员”，但它第一次写对的概率会明显提高。说到底，这比任何花哨演示都更有价值。
而对于那些每天被 AI 生成代码坑过的人来说，这篇论文传递出的好消息只有一句：别急，也许下一代代码模型，不是更能说，而是终于更少“胡说八道”了。