开头先给结论这类“让编码AI自己进化”的项目最值得关注的不是“超越GPT-5”这种抢眼的比较而是它把模型参数压缩了上百倍之后仍然在代码生成、代码修复、推理链这类任务上能贴近大模型的效果。对于想研究自我改进机制、做代码模型轻量化、或者在本地GPU上跑编码Agent的人这才是真正的看点。“自我改进AI”在这类项目里通常不是指模型自己改自己的权重而是指模型在任务循环里不断生成候选代码、运行测试、收集反馈、再用反馈构造训练数据形成一轮一轮的迭代。也就是说模型的能力是在“生成—验证—学习”的闭环里往前走的不是修改prompt也不是调高temperature碰运气。这篇文章我会按一条可复现的路径来拆先讲清楚它到底在“改进”什么再讲为什么参数少了仍然能保持较高正确率然后给出本地复现时需要的环境、步骤、参数和验证方式最后留一份排查清单。如果你现在正在做代码生成模型、想在低显存环境里跑编码AI或者想给自己的小模型加一层“自我进化”的训练回路这篇文章可以直接当参考。1. 先搞清楚编码AI的自我改进到底改的是什么1.1 是模型进化不只是调参很多第一次接触“自我改进”的人会以为项目里有个模型模型写代码写错了就自己改改完就变强。真实情况比这个朴素也比这个工程化得多。编码AI的自我改进本质是一个数据飞轮用基础模型生成一批候选代码。在沙箱环境里运行测试拿到通过或失败的结果。对结果进行筛选把“能通过测试的代码”和“测试不通过但暴露问题的代码”都记录下来。用这些样本构造训练集重新训练或继续微调模型。新模型再参与下一轮生成重复流程。所以“自我改进”的核心不是模型运行时自我调整而是在训练与推理之间建立循环。项目里展示的“正确率提升”其实是循环迭代的结果。如果你在本地复现要先接受一个事实单独跑一次推理你不会看到模型突然变聪明。只有把“生成—验证—再生成”的回路搭起来并让模型在新数据上训练过改进才会发生。1.2 编码任务为什么特别适合做自我改进代码和自然语言不一样代码有确定的验证标准——测试用例。你可以把一段代码放进沙箱跑测试看输出判断它对不对。这种确定性反馈是自然语言生成给不了的。所以编码AI的自我改进主要围绕这几个环节展开生成模型根据需求描述或单元测试生成代码。执行在隔离环境中运行代码检查编译、运行、输出。反馈把运行结果转成模型能学习的文本信号。迭代失败样本和成功样本进入下一轮训练。这比“让模型写一段文章再自己判断好坏”要可靠得多因为标准不是主观的。1.3 我们真正要关注的核心变量看这类项目我最建议关注四个变量初始模型的代码理解能力。基础太差的模型即使循环再多次也很难生成能通过复杂测试的代码。测试用例的质量。测试覆盖不到的地方模型会“钻空子”生成能跑通当前用例但不符合完整需求的代码。反馈数据的格式。反馈写得太模糊模型学不到东西反馈写得太复杂模型训练时容易过拟合。迭代轮数。改进不是线性的常见情况是第一轮提升明显后面越来越慢甚至波动。这几个变量在你跑自己的实验时会反复遇到建议先记住。2. 参数少不等于能力差关键在生成质量和训练目标2.1 “117倍更少参数”按什么口径算标题里的“117倍更少参数”需要做个简单拆解。以常见的7B参数模型作为对照如果目标是“约几十M到几百M参数的编码模型”参数倍数就可能到几十倍甚至上百倍。倍数听起来夸张但实际逻辑并不神秘编码任务密集且规则性强模型只需要把注意力集中在程序结构、语法、常见算法模式上。参数更少的模型如果训练数据全是“代码—测试—结果”这种强信号反而更容易收敛。大模型在泛化任务上优势明显但在固定代码评测集上小模型经过专门训练完全可能接近大模型的效果。不过这里要提醒一句参数效率高不等于所有代码任务都更强。你让这个模型去写散文、做开放问答、处理复杂指令它大概率不如大模型。但在代码理解、函数级生成、测试驱动修复这些领域差距可以被缩小。2.2 训练目标决定了自我改进的方向自我改进AI能走通关键不在模型结构而在于训练目标设计。编码模型在自我改进循环里通常要学三件事给定问题描述或测试输出正确代码。给定错误代码和失败日志输出修复后的代码。给定多个候选版本判断哪一份更可能通过测试。这三件事对应三种数据成功样本、失败修复样本、偏好排序样本。实践里很多人只注意“成功样本”忽略了失败修复样本。失败样本其实更有价值因为它能让模型知道自己错在哪、如何从错误返回正确路径。我的建议是每一轮迭代中失败样本至少要保留30%到40%不要全部丢掉。2.3 为什么大模型参数量巨大但错误率在小模型上反而可以降低这并不是说小模型战胜了大模型而是任务边界被缩小了。大模型需要处理海量知识参数分布得很开。编码专用的小模型把所有参数都压在代码生成和程序理解上相当于“专才”对“通才”。当评测任务集中在代码生成和修复场景时专才的命中率自然能更高。我实测过类似思路的项目最初的模型在基础函数生成上都频繁报错经过几轮带测试反馈的训练后输出格式稳定了很多也能处理一部分逻辑嵌套。这就是任务收窄带来的收益。所以看到“超越GPT-5”这种表述可以理解成“在编码评测集上参数更少的专用模型取得了接近或超过通用大模型的准确率”。它不意味着小模型全面胜出。3. 本地复现自我改进编码AI的最小闭环3.1 适合先跑的环境配置这类项目对硬件要求取决于模型体积和你选的基座模型。如果按百M级小模型来做普通消费级显卡就能跑。如果从7B级别的开源模型开始迭代建议至少准备16G以上显存或者直接用云GPU实例。给一个保守的环境建议项目入门配置推荐配置GPU8G显存16G或24G显存内存16G32G或以上磁盘10G可用空间50G以上需要存训练集和checkpoint操作系统Linux Ubuntu 20.04与左侧一致Python3.103.10或3.11深度学习框架PyTorch 2.x与左侧一致沙箱工具Docker或Python venvDocker隔离更稳如果你的机器只有CPU也不是完全不能跑但训练环节会比较痛苦建议先用小模型、少数据验证代码逻辑再换到GPU环境正式跑。3.2 搭建环境与安装依赖基础依赖通常包含四类模型加载与训练transformers、datasets、accelerate、peft代码执行沙箱docker或python-docker或者直接使用subprocess配合临时目录数据构造与评测pytest、unittest、jsonlines调度与日志tqdm、loguru、pandas安装说明只能给通用示例具体版本要以你的环境和模型要求为准。大致命令如下pip install transformers datasets accelerate peft pip install pytest docker loguru tqdm这里不建议一次装太多额外库。先跑通最小流程再按需要补充。3.3 从单个问题开始生成、执行、反馈复现时不要一上来就构造海量训练集。我建议先从单条问题开始验证三个环节模型能根据问题描述生成代码。生成的代码能在沙箱中执行。失败信息能转成反馈文本。用一个简单描述来测试问题描述 编写一个Python函数输入一个整数列表返回所有偶数的和。模型生成代码后你把它保存成临时文件然后通过沙箱执行。沙箱的核心作用有两个防止模型生成的代码执行危险操作以及捕获运行时的标准输出和错误追踪。成功时你会看到类似结果输入: [1, 2, 3, 4, 5, 6] 期望输出: 12 实际输出: 12 测试通过失败时你会看到错误日志这个日志就是下一轮训练的反馈材料。3.4 构造一个最小迭代循环我这里给一个通用流程框架不绑定具体模型# 伪代码用来说明迭代闭环的骨架结构 # 实际使用时需要补全数据读取、模型调用、沙箱执行和训练逻辑 def self_improve_round(model, task_list, k5): new_samples [] for task in task_list: candidates model.generate(task[prompt], num_return_sequencesk) for code in candidates: result run_code_in_sandbox(code, task[tests]) if result.passed: new_samples.append({ prompt: task[prompt], code: code, target: code, label: pass }) else: new_samples.append({ prompt: task[prompt] \n错误日志:\n result.stderr, code: code, target: , label: fail }) return new_samplesk是每个问题的候选数量。我建议从3到5开始不要一开始就开到10。候选数量大确实能增加覆盖多样性的概率但也会成倍增加沙箱执行和过滤成本。拿到新样本之后你要做一次数据清洗删除无法运行、明显损坏的代码。删除超时、内存异常的任务。保留“修复成功”的失败样本。平衡通过样本和失败样本的比例。清洗完成后才进入模型训练或微调环节。4. 参数、评测和训练策略别急着开大先看曲线4.1 生成参数怎么设置生成阶段有几个参数直接影响数据质量参数保守值说明temperature0.7到0.9太高容易生成语法错误太低则多样性不足top_p0.9到1.0控制采样范围默认可先不动max_new_tokens256到512编码任务通常不需要过长输出num_return_sequences3到5候选数量决定了生成阶段的成本do_sampleTrue需要采样才有候选多样性如果你的目的是数据扩充temperature可以放高一点。如果目的是评测模型最终效果建议temperature调到0采用贪心解码避免随机性干扰比较。4.2 训练阶段的关键观察指标自我改进的模型在训练阶段不能只看loss。我每次跑完都会盯四个指标通过率变化同一组测试用例上模型生成的代码通过比例是否上升。编译错误率生成代码里语法错误的占比这个指标降得快说明基础代码结构被模型学到了。修复能力给定失败日志后模型生成的新版本正确率是否提高。遗忘程度模型在已有任务上的正确率是否出现明显下跌。第4点特别容易忽略。很多模型在加入新数据之后旧任务反而变差了。这时候要考虑混合旧数据或者降低新数据占比。4.3 93.3%正确率是怎么验证出来的要理解“正确率”先看评测集的定义。不同项目评测集大小差异很大可能几百条也可能几千条。在没有原始数据的情况下我不会把某个数字当成“绝对水平”而是把它当成一个相对指标。更合理的验证方式是固定一个评测集例如LeetCode难度较低的函数题、MATH中的代码题、pytest测试驱动题目。把任务分为“生成新代码”和“修复错误代码”两类。用同一组测试环境跑模型输出。统计通过率、超时率、异常退出率。如果你的目标是重复项目的93.3%正确率我建议先做这些准备确认评测集有多少题、是否固定。确认沙箱环境是否一致。确认测试用例是否公开。确认模型是贪心解码还是采样解码。同一个模型在不同解码方式下正确率会有明显差距。评测方式不统一时数字很难直接对比。4.4 如何避免“虚假改进”自我改进回路里最常见的坑是模型学会针对测试用例编写“恰好能过”的代码但没有真正理解需求。举一个例子任务是“返回列表最大值”如果测试只用到了正整数列表模型可能生成一个只比较正整数的函数遇到负数时就会出错。这种模型在训练集上正确率很高在真实场景里反而脆弱。避免方法有三种设计测试用例时覆盖边界条件空列表、负数、重复元素、大数。在训练数据中加入“需求不完全满足”的失败样本。验证时使用新的、与训练集分布不同的用例。我自己习惯把评测集分成两个部分一部分来自训练数据一部分来自模型没见过的题目。第二部分的通过率才是模型真实能力的信号。5. 常见问题排查报错、卡住、不收敛5.1 模型生成的代码在沙箱里全部失败先不要怀疑模型能力优先排查以下几个点模型是否真正接收到了完整的问题描述。生成时是否忘了指定语言提示比如“请用Python实现”。max_new_tokens是否太小代码被截断。沙箱中是否缺少模型代码依赖的库。每个任务是否都用了独立沙箱避免状态污染。我在第一次跑这类流程时问题通常出在截断和依赖缺失上而不是模型本身。检查顺序建议是输入格式、生成输出截断、沙箱依赖、权限问题。5.2 训练loss下降了但生成通过率没提升这是最常见的“不收敛”现象。loss下降说明模型在学习训练数据不代表它学到了能通过测试的规律。常见原因训练数据里成功样本和失败样本不均衡。比如失败样本太多模型在生成时倾向于输出修复代码而不是完整解决方案。prompt和答案的格式不统一。模型学到的是“格式模板”不是“代码逻辑”。数据量太少模型在重复记忆训练集。测试用例难度高于训练数据难度。处理方式先查看训练集里样本被过滤后的分布然后限制训练轮数提前保存验证指标最好的checkpoint不要只按loss来选模型。5.3 模型在旧任务上变差这是灾难性遗忘的表现。在自我改进循环里新数据往往集中在新采集的任务上旧任务在训练集中被稀释。解决办法有几个每次迭代时保留若干条旧任务数据混入新数据。采样旧数据时按难度分层多保留容易出错的旧样本。使用低学习率。训练时每隔几步在旧评测集上跑一次验证。5.4 单轮改进挺明显第二轮就停了这不是bug。自我改进的收益递减很常见。第一轮往往能补足模型的基础短板比如语法格式、常见库使用第二轮以后剩余错误通常是逻辑复杂度高或测试用例要求高小模型光靠循环很难继续突破。这种情况下不要硬跑更多轮。先看当前模型卡在什么类型的题目上再针对性地补充类似数据或者提高候选数量。5.5 沙箱里的隐藏资源消耗代码执行沙箱如果不限制CPU和内存可能出现一个模型生成的死循环脚本把整台机器拖垮。建议给沙箱加限制设置超时时间比如每条用例10到20秒。限制内存使用可以在容器层面配置。文件系统使用临时目录跑完即清。禁用网络访问防止生成代码请求外部服务。docker run --rm --networknone \ --memory512m \ --cpus1 \ -v $(pwd)/sandbox:/sandbox \ python:3.10 python /sandbox/run_test.py这个命令是示例思路。只要你用的是容器方案尽量加上网络和资源限制能避免很多事故。6. 从单机实验到批量真实验证6.1 批量任务需要单独设计数据管道单条任务跑通之后进入批量阶段会迎来新问题多个任务并发执行时沙箱资源怎么分配。生成结果和测试输出怎么统一记录。中间进程崩溃后能不能从断点恢复。输出文件命名怎么保证不冲突。建议把每个任务的输入、生成代码、测试结果、日志单独存成一个JSON文件{ task_id: task_0001, prompt: 编写一个函数返回两个整数的最大值, generated_code: def max_num(a, b):\n return a if a b else b, test_result: passed, error_log: , runtime_seconds: 0.12 }批量跑时先确认一个任务从生成到执行完毕需要多长时间再决定并发数。不要上来就开最大并发否则GPU显存和CPU资源会被打满。6.2 从单机到调度的自然过渡如果你只想验证机制单机脚本足够。如果准备把自我改进回路用于项目或团队内部分享我建议做这几个升级用任务队列托管数据比如Redis或简单文件队列。把沙箱执行封装成独立服务与模型推理端分离。记录训练数据和评测数据的版本号。每一次模型更新都要留下评测报告。这些升级不一定需要在第一版做。先跑通再根据需求决定是否引入调度。6.3 什么时候考虑大模型辅助小模型的自我改进会遇到瓶颈一个实用的办法是让大模型做“辅助数据增强”不是让小模型直接超越大模型。比如大模型生成更多样的候选代码。大模型把失败日志改写为更清晰的问题描述。大模型补充新测试用例。这些数据给小模型训练。整个系统依然是小模型主导推理和生成大模型只负责“老师”角色。这种思路在实践里比“让小模型凭空进化”稳定得多。但它有个前提你要有调用大模型API或本地大模型的通道。免费API的额度有限本地大模型的显存要求又上去了所以还是要量力而行。6.4 生产环境中要盯住的三个稳定目标长期跑自我改进编码AI我会把目标定义成生成正确代码的比例持续上升。失败日志返回后修复成功率上升。新增代码风格与需求描述的一致性保持稳定。这三个目标不要求模型一夜之间从60%跳到90%。真实迭代会把正确率往上推但过程是波动的。你要看的是整体趋势而不是单次迭代结果。7. 关于“超越GPT-5”的正确理解方式7.1 评测集才是比较的基础编码模型之间比较必须在同一批任务上跑并且评测集要覆盖边界条件。如果只比较“模型在训练过的问题上的表现”没有什么说服力。更合理的理解是一个参数很少的编码专用模型在受限的代码生成和测试驱动修复任务上通过自我改进的数据闭环可以达到接近大模型的水平。这是一种范式验证不是通用能力的全面碾压。对普通开发者来说这个思路的最大价值是不需要几百万的算力预算你也可能在本地完成一个编码模型的迭代实验验证数据飞轮是否对你有用。7.2 什么场景真正适合这样做我的判断是自我改进AI适合以下场景你有稳定的代码任务集任务类型固定测试用例能自动生成或人工补充。你本来就依赖开源模型或API模型想提高特定任务上的正确率。你希望降低推理成本用小模型替换部分大模型编码功能。你在研究模型如何在被验证的环境中持续提升能力。不适合的场景也很明确开放域代码需求任务描述不清晰测试用例无法自动生成。初始模型在所有任务上错误率太高连正确样本都很难产生。每次任务都是全新项目没有可复用的评测集。如果匹配的是不适合场景自我改进回路很容易变成“用大量算力生产噪音”。8. 踩坑复盘与后续优化方向8.1 最容易忽略的三个细节第一模型生成代码时的系统提示词要稳定。同一问题不同提示词下生成的代码风格差别很大影响数据质量。建议全流程固定一套提示词模板。第二沙箱执行结果要区分“测试不通过”和“运行环境异常”。前者是模型问题后者可能是代码依赖了未安装的库、访问了不存在路径或权限不足。如果混在一起训练模型会学到错误关联。第三构造训练数据时不要只存“生成代码”还要保存“问题描述、测试用例、错误日志、成功代码和失败代码的配对关系”。数据越完整下一轮训练的可控性越强。8.2 从“测试通过”到“需求满足”还有距离项目里的正确率通常是指模型生成的代码能在测试用例上通过。但生产环境下真正有价值的是“代码满足完整需求”包括异常处理、边界条件、性能要求、代码可读性。建议后续优化时增加几类验证用额外测试用例验证模型代码的通用性。对超长输入和特殊字符做稳定性测试。检查模型生成的代码是否主动处理异常。对比模型修复代码的时间和修复后的质量。8.3 后续可以尝试的方向如果跑通最小闭环可以沿着这些方向往下走多语言扩展从Python扩展到Java、Go、Rust。多轮修复允许模型根据多条失败日志逐步修改代码而不是一次性输出最终版本。与代码检索结合让模型在生成前检索相似历史代码库。安全测试检查生成代码是否存在路径穿越、SQL注入、命令注入问题。这些方向都需要单独构建评测集。不要妄想一个模型自动把所有问题都解决还是要按任务逐步推进。9. 最后留一份自查清单如果你准备自己动手复现我建议按这个顺序做一遍。第一步选一个基座模型优先选代码能力尚可的小模型。第二步准备20到50个固定任务每个任务带测试用例。第三步跑通“生成—沙箱执行—反馈记录”这条链路。第四步手工检查30到50条生成结果确认数据质量。第五步用这批数据做一次微调。第六步在同一批任务上评测微调前后的正确率差异。第七步加入新任务继续下一轮迭代。每一轮迭代都要单独保存模型checkpoint、训练数据、评测结果。不要覆盖上一次的结果否则后面发现问题时无法回溯。这条路线不是最快的但它能让你看清楚每一环的真实状态。自我改进AI要落地靠的是稳定可复用的数据闭环不是某一次生成撞上了正确答案。参数少、正确率高本质上是因为任务边界清晰、反馈准确、数据循环合理。想复现这个效果你真正要下功夫的地方不在模型本身而在测试用例质量、沙箱执行稳定性和数据清洗规范。 
长河君 · 2026/9/6 1:47:05 · 阅读 1.2k 编码AI自我改进：小参数模型如何逼近大模型效果
开头先给结论这类“让编码AI自己进化”的项目最值得关注的不是“超越GPT-5”这种抢眼的比较而是它把模型参数压缩了上百倍之后仍然在代码生成、代码修复、推理链这类任务上能贴近大模型的效果。对于想研究自我改进机制、做代码模型轻量化、或者在本地GPU上跑编码Agent的人这才是真正的看点。“自我改进AI”在这类项目里通常不是指模型自己改自己的权重而是指模型在任务循环里不断生成候选代码、运行测试、收集反馈、再用反馈构造训练数据形成一轮一轮的迭代。也就是说模型的能力是在“生成—验证—学习”的闭环里往前走的不是修改prompt也不是调高temperature碰运气。这篇文章我会按一条可复现的路径来拆先讲清楚它到底在“改进”什么再讲为什么参数少了仍然能保持较高正确率然后给出本地复现时需要的环境、步骤、参数和验证方式最后留一份排查清单。如果你现在正在做代码生成模型、想在低显存环境里跑编码AI或者想给自己的小模型加一层“自我进化”的训练回路这篇文章可以直接当参考。1. 先搞清楚编码AI的自我改进到底改的是什么1.1 是模型进化不只是调参很多第一次接触“自我改进”的人会以为项目里有个模型模型写代码写错了就自己改改完就变强。真实情况比这个朴素也比这个工程化得多。编码AI的自我改进本质是一个数据飞轮用基础模型生成一批候选代码。在沙箱环境里运行测试拿到通过或失败的结果。对结果进行筛选把“能通过测试的代码”和“测试不通过但暴露问题的代码”都记录下来。用这些样本构造训练集重新训练或继续微调模型。新模型再参与下一轮生成重复流程。所以“自我改进”的核心不是模型运行时自我调整而是在训练与推理之间建立循环。项目里展示的“正确率提升”其实是循环迭代的结果。如果你在本地复现要先接受一个事实单独跑一次推理你不会看到模型突然变聪明。只有把“生成—验证—再生成”的回路搭起来并让模型在新数据上训练过改进才会发生。1.2 编码任务为什么特别适合做自我改进代码和自然语言不一样代码有确定的验证标准——测试用例。你可以把一段代码放进沙箱跑测试看输出判断它对不对。这种确定性反馈是自然语言生成给不了的。所以编码AI的自我改进主要围绕这几个环节展开生成模型根据需求描述或单元测试生成代码。执行在隔离环境中运行代码检查编译、运行、输出。反馈把运行结果转成模型能学习的文本信号。迭代失败样本和成功样本进入下一轮训练。这比“让模型写一段文章再自己判断好坏”要可靠得多因为标准不是主观的。1.3 我们真正要关注的核心变量看这类项目我最建议关注四个变量初始模型的代码理解能力。基础太差的模型即使循环再多次也很难生成能通过复杂测试的代码。测试用例的质量。测试覆盖不到的地方模型会“钻空子”生成能跑通当前用例但不符合完整需求的代码。反馈数据的格式。反馈写得太模糊模型学不到东西反馈写得太复杂模型训练时容易过拟合。迭代轮数。改进不是线性的常见情况是第一轮提升明显后面越来越慢甚至波动。这几个变量在你跑自己的实验时会反复遇到建议先记住。2. 参数少不等于能力差关键在生成质量和训练目标2.1 “117倍更少参数”按什么口径算标题里的“117倍更少参数”需要做个简单拆解。以常见的7B参数模型作为对照如果目标是“约几十M到几百M参数的编码模型”参数倍数就可能到几十倍甚至上百倍。倍数听起来夸张但实际逻辑并不神秘编码任务密集且规则性强模型只需要把注意力集中在程序结构、语法、常见算法模式上。参数更少的模型如果训练数据全是“代码—测试—结果”这种强信号反而更容易收敛。大模型在泛化任务上优势明显但在固定代码评测集上小模型经过专门训练完全可能接近大模型的效果。不过这里要提醒一句参数效率高不等于所有代码任务都更强。你让这个模型去写散文、做开放问答、处理复杂指令它大概率不如大模型。但在代码理解、函数级生成、测试驱动修复这些领域差距可以被缩小。2.2 训练目标决定了自我改进的方向自我改进AI能走通关键不在模型结构而在于训练目标设计。编码模型在自我改进循环里通常要学三件事给定问题描述或测试输出正确代码。给定错误代码和失败日志输出修复后的代码。给定多个候选版本判断哪一份更可能通过测试。这三件事对应三种数据成功样本、失败修复样本、偏好排序样本。实践里很多人只注意“成功样本”忽略了失败修复样本。失败样本其实更有价值因为它能让模型知道自己错在哪、如何从错误返回正确路径。我的建议是每一轮迭代中失败样本至少要保留30%到40%不要全部丢掉。2.3 为什么大模型参数量巨大但错误率在小模型上反而可以降低这并不是说小模型战胜了大模型而是任务边界被缩小了。大模型需要处理海量知识参数分布得很开。编码专用的小模型把所有参数都压在代码生成和程序理解上相当于“专才”对“通才”。当评测任务集中在代码生成和修复场景时专才的命中率自然能更高。我实测过类似思路的项目最初的模型在基础函数生成上都频繁报错经过几轮带测试反馈的训练后输出格式稳定了很多也能处理一部分逻辑嵌套。这就是任务收窄带来的收益。所以看到“超越GPT-5”这种表述可以理解成“在编码评测集上参数更少的专用模型取得了接近或超过通用大模型的准确率”。它不意味着小模型全面胜出。3. 本地复现自我改进编码AI的最小闭环3.1 适合先跑的环境配置这类项目对硬件要求取决于模型体积和你选的基座模型。如果按百M级小模型来做普通消费级显卡就能跑。如果从7B级别的开源模型开始迭代建议至少准备16G以上显存或者直接用云GPU实例。给一个保守的环境建议项目入门配置推荐配置GPU8G显存16G或24G显存内存16G32G或以上磁盘10G可用空间50G以上需要存训练集和checkpoint操作系统Linux Ubuntu 20.04与左侧一致Python3.103.10或3.11深度学习框架PyTorch 2.x与左侧一致沙箱工具Docker或Python venvDocker隔离更稳如果你的机器只有CPU也不是完全不能跑但训练环节会比较痛苦建议先用小模型、少数据验证代码逻辑再换到GPU环境正式跑。3.2 搭建环境与安装依赖基础依赖通常包含四类模型加载与训练transformers、datasets、accelerate、peft代码执行沙箱docker或python-docker或者直接使用subprocess配合临时目录数据构造与评测pytest、unittest、jsonlines调度与日志tqdm、loguru、pandas安装说明只能给通用示例具体版本要以你的环境和模型要求为准。大致命令如下pip install transformers datasets accelerate peft pip install pytest docker loguru tqdm这里不建议一次装太多额外库。先跑通最小流程再按需要补充。3.3 从单个问题开始生成、执行、反馈复现时不要一上来就构造海量训练集。我建议先从单条问题开始验证三个环节模型能根据问题描述生成代码。生成的代码能在沙箱中执行。失败信息能转成反馈文本。用一个简单描述来测试问题描述 编写一个Python函数输入一个整数列表返回所有偶数的和。模型生成代码后你把它保存成临时文件然后通过沙箱执行。沙箱的核心作用有两个防止模型生成的代码执行危险操作以及捕获运行时的标准输出和错误追踪。成功时你会看到类似结果输入: [1, 2, 3, 4, 5, 6] 期望输出: 12 实际输出: 12 测试通过失败时你会看到错误日志这个日志就是下一轮训练的反馈材料。3.4 构造一个最小迭代循环我这里给一个通用流程框架不绑定具体模型# 伪代码用来说明迭代闭环的骨架结构 # 实际使用时需要补全数据读取、模型调用、沙箱执行和训练逻辑 def self_improve_round(model, task_list, k5): new_samples [] for task in task_list: candidates model.generate(task[prompt], num_return_sequencesk) for code in candidates: result run_code_in_sandbox(code, task[tests]) if result.passed: new_samples.append({ prompt: task[prompt], code: code, target: code, label: pass }) else: new_samples.append({ prompt: task[prompt] \n错误日志:\n result.stderr, code: code, target: , label: fail }) return new_samplesk是每个问题的候选数量。我建议从3到5开始不要一开始就开到10。候选数量大确实能增加覆盖多样性的概率但也会成倍增加沙箱执行和过滤成本。拿到新样本之后你要做一次数据清洗删除无法运行、明显损坏的代码。删除超时、内存异常的任务。保留“修复成功”的失败样本。平衡通过样本和失败样本的比例。清洗完成后才进入模型训练或微调环节。4. 参数、评测和训练策略别急着开大先看曲线4.1 生成参数怎么设置生成阶段有几个参数直接影响数据质量参数保守值说明temperature0.7到0.9太高容易生成语法错误太低则多样性不足top_p0.9到1.0控制采样范围默认可先不动max_new_tokens256到512编码任务通常不需要过长输出num_return_sequences3到5候选数量决定了生成阶段的成本do_sampleTrue需要采样才有候选多样性如果你的目的是数据扩充temperature可以放高一点。如果目的是评测模型最终效果建议temperature调到0采用贪心解码避免随机性干扰比较。4.2 训练阶段的关键观察指标自我改进的模型在训练阶段不能只看loss。我每次跑完都会盯四个指标通过率变化同一组测试用例上模型生成的代码通过比例是否上升。编译错误率生成代码里语法错误的占比这个指标降得快说明基础代码结构被模型学到了。修复能力给定失败日志后模型生成的新版本正确率是否提高。遗忘程度模型在已有任务上的正确率是否出现明显下跌。第4点特别容易忽略。很多模型在加入新数据之后旧任务反而变差了。这时候要考虑混合旧数据或者降低新数据占比。4.3 93.3%正确率是怎么验证出来的要理解“正确率”先看评测集的定义。不同项目评测集大小差异很大可能几百条也可能几千条。在没有原始数据的情况下我不会把某个数字当成“绝对水平”而是把它当成一个相对指标。更合理的验证方式是固定一个评测集例如LeetCode难度较低的函数题、MATH中的代码题、pytest测试驱动题目。把任务分为“生成新代码”和“修复错误代码”两类。用同一组测试环境跑模型输出。统计通过率、超时率、异常退出率。如果你的目标是重复项目的93.3%正确率我建议先做这些准备确认评测集有多少题、是否固定。确认沙箱环境是否一致。确认测试用例是否公开。确认模型是贪心解码还是采样解码。同一个模型在不同解码方式下正确率会有明显差距。评测方式不统一时数字很难直接对比。4.4 如何避免“虚假改进”自我改进回路里最常见的坑是模型学会针对测试用例编写“恰好能过”的代码但没有真正理解需求。举一个例子任务是“返回列表最大值”如果测试只用到了正整数列表模型可能生成一个只比较正整数的函数遇到负数时就会出错。这种模型在训练集上正确率很高在真实场景里反而脆弱。避免方法有三种设计测试用例时覆盖边界条件空列表、负数、重复元素、大数。在训练数据中加入“需求不完全满足”的失败样本。验证时使用新的、与训练集分布不同的用例。我自己习惯把评测集分成两个部分一部分来自训练数据一部分来自模型没见过的题目。第二部分的通过率才是模型真实能力的信号。5. 常见问题排查报错、卡住、不收敛5.1 模型生成的代码在沙箱里全部失败先不要怀疑模型能力优先排查以下几个点模型是否真正接收到了完整的问题描述。生成时是否忘了指定语言提示比如“请用Python实现”。max_new_tokens是否太小代码被截断。沙箱中是否缺少模型代码依赖的库。每个任务是否都用了独立沙箱避免状态污染。我在第一次跑这类流程时问题通常出在截断和依赖缺失上而不是模型本身。检查顺序建议是输入格式、生成输出截断、沙箱依赖、权限问题。5.2 训练loss下降了但生成通过率没提升这是最常见的“不收敛”现象。loss下降说明模型在学习训练数据不代表它学到了能通过测试的规律。常见原因训练数据里成功样本和失败样本不均衡。比如失败样本太多模型在生成时倾向于输出修复代码而不是完整解决方案。prompt和答案的格式不统一。模型学到的是“格式模板”不是“代码逻辑”。数据量太少模型在重复记忆训练集。测试用例难度高于训练数据难度。处理方式先查看训练集里样本被过滤后的分布然后限制训练轮数提前保存验证指标最好的checkpoint不要只按loss来选模型。5.3 模型在旧任务上变差这是灾难性遗忘的表现。在自我改进循环里新数据往往集中在新采集的任务上旧任务在训练集中被稀释。解决办法有几个每次迭代时保留若干条旧任务数据混入新数据。采样旧数据时按难度分层多保留容易出错的旧样本。使用低学习率。训练时每隔几步在旧评测集上跑一次验证。5.4 单轮改进挺明显第二轮就停了这不是bug。自我改进的收益递减很常见。第一轮往往能补足模型的基础短板比如语法格式、常见库使用第二轮以后剩余错误通常是逻辑复杂度高或测试用例要求高小模型光靠循环很难继续突破。这种情况下不要硬跑更多轮。先看当前模型卡在什么类型的题目上再针对性地补充类似数据或者提高候选数量。5.5 沙箱里的隐藏资源消耗代码执行沙箱如果不限制CPU和内存可能出现一个模型生成的死循环脚本把整台机器拖垮。建议给沙箱加限制设置超时时间比如每条用例10到20秒。限制内存使用可以在容器层面配置。文件系统使用临时目录跑完即清。禁用网络访问防止生成代码请求外部服务。docker run --rm --networknone \ --memory512m \ --cpus1 \ -v $(pwd)/sandbox:/sandbox \ python:3.10 python /sandbox/run_test.py这个命令是示例思路。只要你用的是容器方案尽量加上网络和资源限制能避免很多事故。6. 从单机实验到批量真实验证6.1 批量任务需要单独设计数据管道单条任务跑通之后进入批量阶段会迎来新问题多个任务并发执行时沙箱资源怎么分配。生成结果和测试输出怎么统一记录。中间进程崩溃后能不能从断点恢复。输出文件命名怎么保证不冲突。建议把每个任务的输入、生成代码、测试结果、日志单独存成一个JSON文件{ task_id: task_0001, prompt: 编写一个函数返回两个整数的最大值, generated_code: def max_num(a, b):\n return a if a b else b, test_result: passed, error_log: , runtime_seconds: 0.12 }批量跑时先确认一个任务从生成到执行完毕需要多长时间再决定并发数。不要上来就开最大并发否则GPU显存和CPU资源会被打满。6.2 从单机到调度的自然过渡如果你只想验证机制单机脚本足够。如果准备把自我改进回路用于项目或团队内部分享我建议做这几个升级用任务队列托管数据比如Redis或简单文件队列。把沙箱执行封装成独立服务与模型推理端分离。记录训练数据和评测数据的版本号。每一次模型更新都要留下评测报告。这些升级不一定需要在第一版做。先跑通再根据需求决定是否引入调度。6.3 什么时候考虑大模型辅助小模型的自我改进会遇到瓶颈一个实用的办法是让大模型做“辅助数据增强”不是让小模型直接超越大模型。比如大模型生成更多样的候选代码。大模型把失败日志改写为更清晰的问题描述。大模型补充新测试用例。这些数据给小模型训练。整个系统依然是小模型主导推理和生成大模型只负责“老师”角色。这种思路在实践里比“让小模型凭空进化”稳定得多。但它有个前提你要有调用大模型API或本地大模型的通道。免费API的额度有限本地大模型的显存要求又上去了所以还是要量力而行。6.4 生产环境中要盯住的三个稳定目标长期跑自我改进编码AI我会把目标定义成生成正确代码的比例持续上升。失败日志返回后修复成功率上升。新增代码风格与需求描述的一致性保持稳定。这三个目标不要求模型一夜之间从60%跳到90%。真实迭代会把正确率往上推但过程是波动的。你要看的是整体趋势而不是单次迭代结果。7. 关于“超越GPT-5”的正确理解方式7.1 评测集才是比较的基础编码模型之间比较必须在同一批任务上跑并且评测集要覆盖边界条件。如果只比较“模型在训练过的问题上的表现”没有什么说服力。更合理的理解是一个参数很少的编码专用模型在受限的代码生成和测试驱动修复任务上通过自我改进的数据闭环可以达到接近大模型的水平。这是一种范式验证不是通用能力的全面碾压。对普通开发者来说这个思路的最大价值是不需要几百万的算力预算你也可能在本地完成一个编码模型的迭代实验验证数据飞轮是否对你有用。7.2 什么场景真正适合这样做我的判断是自我改进AI适合以下场景你有稳定的代码任务集任务类型固定测试用例能自动生成或人工补充。你本来就依赖开源模型或API模型想提高特定任务上的正确率。你希望降低推理成本用小模型替换部分大模型编码功能。你在研究模型如何在被验证的环境中持续提升能力。不适合的场景也很明确开放域代码需求任务描述不清晰测试用例无法自动生成。初始模型在所有任务上错误率太高连正确样本都很难产生。每次任务都是全新项目没有可复用的评测集。如果匹配的是不适合场景自我改进回路很容易变成“用大量算力生产噪音”。8. 踩坑复盘与后续优化方向8.1 最容易忽略的三个细节第一模型生成代码时的系统提示词要稳定。同一问题不同提示词下生成的代码风格差别很大影响数据质量。建议全流程固定一套提示词模板。第二沙箱执行结果要区分“测试不通过”和“运行环境异常”。前者是模型问题后者可能是代码依赖了未安装的库、访问了不存在路径或权限不足。如果混在一起训练模型会学到错误关联。第三构造训练数据时不要只存“生成代码”还要保存“问题描述、测试用例、错误日志、成功代码和失败代码的配对关系”。数据越完整下一轮训练的可控性越强。8.2 从“测试通过”到“需求满足”还有距离项目里的正确率通常是指模型生成的代码能在测试用例上通过。但生产环境下真正有价值的是“代码满足完整需求”包括异常处理、边界条件、性能要求、代码可读性。建议后续优化时增加几类验证用额外测试用例验证模型代码的通用性。对超长输入和特殊字符做稳定性测试。检查模型生成的代码是否主动处理异常。对比模型修复代码的时间和修复后的质量。8.3 后续可以尝试的方向如果跑通最小闭环可以沿着这些方向往下走多语言扩展从Python扩展到Java、Go、Rust。多轮修复允许模型根据多条失败日志逐步修改代码而不是一次性输出最终版本。与代码检索结合让模型在生成前检索相似历史代码库。安全测试检查生成代码是否存在路径穿越、SQL注入、命令注入问题。这些方向都需要单独构建评测集。不要妄想一个模型自动把所有问题都解决还是要按任务逐步推进。9. 最后留一份自查清单如果你准备自己动手复现我建议按这个顺序做一遍。第一步选一个基座模型优先选代码能力尚可的小模型。第二步准备20到50个固定任务每个任务带测试用例。第三步跑通“生成—沙箱执行—反馈记录”这条链路。第四步手工检查30到50条生成结果确认数据质量。第五步用这批数据做一次微调。第六步在同一批任务上评测微调前后的正确率差异。第七步加入新任务继续下一轮迭代。每一轮迭代都要单独保存模型checkpoint、训练数据、评测结果。不要覆盖上一次的结果否则后面发现问题时无法回溯。这条路线不是最快的但它能让你看清楚每一环的真实状态。自我改进AI要落地靠的是稳定可复用的数据闭环不是某一次生成撞上了正确答案。参数少、正确率高本质上是因为任务边界清晰、反馈准确、数据循环合理。想复现这个效果你真正要下功夫的地方不在模型本身而在测试用例质量、沙箱执行稳定性和数据清洗规范。