编码 AI 的“自我进化”实验117 倍更少参数凭什么能挑战 GPT-5 级能力如果你最近在关注大模型圈子很可能被一个消息刷屏一个编码 AI 项目宣称仅用约 1/117 的参数规模在一个编程基准上跑出了 93.3% 的正确率直接对标甚至超过 GPT-5 的表现。很多人第一反应是这又是标题党吧毕竟 GPT-5 级别的模型背后是数千亿参数、海量算力和复杂训练管线。一个小参数模型凭什么逆袭坦白说我第一眼看到这个标题时也带着怀疑。但真正读完项目材料之后我更倾向于另一个判断这场“小模型挑战大模型”的实验真正的看点不在于参数数字而在于它把“自我改进”Self-Improvement从一个 AI 领域的热门概念落成了一个可复现、可运行的工程范式。这篇文章不打算单纯复述项目简介。我会从你真正关心的问题出发这个小模型到底是怎么炼成的它和传统“训练→微调→部署”的流程有什么本质区别如果你也想在自己的项目里复刻这种“自我进化”机制应该从哪里下手以及最现实的——这种思路适合哪些场景不适合哪些场景文章会拆解项目的核心机制、环境准备、代码实现、运行验证和排错思路并给出我对这个方向的工程判断。如果你对“小模型 监督微调 自生成数据 迭代评估”这条路径感兴趣这篇文章值得读完再收藏。1. 为什么“参数更少、性能更强”这件事值得警惕性关注先说一个很重要的前提在 AI 领域所有“小模型超越大模型”的结论都不能脱离基准测试、任务范围和评估口径来理解。这个项目展示的“93.3% 正确率”核心场景是编码任务Code Generation / Code Repair 类并且是特定评测集上的结果。它不是说一个 3B 参数的模型在综合智能上击败了 GPT-5而是说在限定任务、限定数据分布、且引入自我改进机制之后一个远小于前沿大模型的模型可以在该任务上达到接近或超越前沿模型的准确率。这背后的工程意义非常明确它降低的是“特定任务达到高准确率”的成本门槛。如果你所在的企业或团队长期依赖 GPT-5、Claude 这类大模型的 API 来完成特定编码任务每个月的 token 费用可能相当可观。更麻烦的是某些场景由于隐私或合规要求根本不允许把代码发送到外部 API。这时候一个在本地就能跑、参数量不大、但准确率能打的小模型价值就不只是“省钱”了而是“让过去不可行的方案变得可行”。但为什么说“警惕性关注”因为“自我改进”这个术语现在有被滥用的趋势。很多产品只是加了点上下文学习In-Context Learning或者测试时计算Test-Time Compute就贴上了“自我进化”的标签。真正的自我改进必须包含这样一个闭环模型生成结果 → 自动化评估结果 → 评估反馈作为新数据 → 继续训练模型 → 模型在下一轮表现得更好。没有这个循环就只是普通的模型调用优化。所以读这篇文章时请你带着一个核心问题它到底是用什么机制实现“越用越强”的这个机制能不能迁移到我的项目中2. 核心概念拆解什么是“自我改进 AI”在深入项目之前先把概念讲清楚。2.1 传统编码模型的使用方式大多数开发者对“编码 AI”的使用停留在一次性的“提示词 → 生成结果”模式用户提问Prompt → 模型调用Inference → 输出代码Completion这个模式的本质是模型的权重在训练阶段就固定了。无论你问多少次模型不会因为“上次答错了”而自动记住教训。如果答错了你需要手动改写提示词或者等待模型厂商发布新版本。这是典型的静态模型。2.2 什么是自我改进Self-Improvement自我改进的核心是把“评估结果”重新注入训练流程生成结果 → 自动评测 → 筛选好坏结果 → 形成新训练数据 → 继续训练 → 模型更新 → 再生成 → 再评测这里的关键词是自动评测。如果每一步都需要人工判断生成结果好不好那么所谓的“自我改进”就是半自动的成本依然很高。这个项目能做到“自我进化”前提一定是有一套可自动执行的评测机制——在编码任务中这通常意味着跑单元测试、静态检查、编译验证、输出对比。2.3 监督微调与数据飞轮这个项目大概率基于开源基座模型做监督微调SFT, Supervised Fine-Tuning。和从零训练不同监督微调是在已有预训练模型基础上用高质量的“输入-输出”数据进一步更新权重。这个项目的创新之处不在于 SFT 本身而在于数据来源变了——训练数据不是纯靠人工标注很大一部分是由模型自己先生成、再由自动评测筛选出来的“优质答案”。这个数据飞轮一旦转起来理论上模型可以不断从自身的高质量输出中学习。这就是“自我改进”四个字的底层逻辑。2.4 为什么小模型也能“一口吃成胖子”小参数模型比如 3B、7B 级别的能力上限确实不如千亿模型但在特定任务上上限并不完全由参数量决定。如果你把一个问题限定在“修复 Python 函数中的类型错误”这类规则清晰的编码任务上一个小模型经过充分微调完全有可能在评测集上逼近甚至超过通用大模型。原因很简单任务空间缩小了模型需要记忆的模式就少了小容量也能装下足够好的策略。这也是这篇文章最想传达的一个判断大模型是通用平台小模型是专用引擎。自我改进机制恰好是让专用引擎持续升级的最佳方式。3. 项目的核心机制“自我进化”到底怎么运作从标题和材料信息来看这个项目的核心不是某一个新的基础模型架构而是围绕“自我改进”构建的一套训练与评估闭环。我们可以把它的运行逻辑拆成四个阶段。3.1 阶段一基座模型初始化项目从一个开源预训练模型开始通常是 3B 到 7B 参数规模的代码模型。这个阶段的模型能力是“通才但粗浅”——能写代码但错误率偏高。3.2 阶段二生成候选答案针对编码任务数据集模型对每个问题生成多个候选答案Candidate Solutions。在采样时可能需要设置较高的温度参数temperature和 top-p让生成结果具有多样性。这一步的目的是探索不同解题路径。3.3 阶段三自动评估与筛选这是整个闭环的裁判环节。对每个候选答案评测系统会执行编译检查代码能否通过编译。单元测试能否通过预先写好的测试用例。静态分析是否符合代码风格和常见规范。覆盖率分析测试覆盖了哪些分支。只有通过全部检查的答案才会被标注为“优质答案”。这里要特别强调评测集的质量直接决定了自我改进的天花板。如果评测用例本身就稀疏、有漏洞那么模型学会的就不是“写正确代码”而是“钻评测空子”。3.4 阶段四增量训练SFT Round将筛选出的优质答案整理成新的 SFT 数据集对模型做一轮增量监督微调。训练完成后模型权重更新然后用更新后的模型再次执行阶段二和阶段三进入下一个迭代轮次。每完成一轮就相当于完成了一次“自我进化”。多轮迭代后模型在评测集上的正确率逐步上升最终可能达到 90% 以上。3.5 这个机制为什么能带来收益传统做法是“一次训练一次部署”模型的能力上限在训练结束后就锁定了。而这个项目的做法是“训练-部署-评估-再训练”循环每一轮都在自动修正上一轮的短板。此处的核心收益是你可以用一份算力预算买到“持续变好”的模型而不是“一次定型”的模型。听起来很美好但实施这个闭环远比写模型调用代码复杂。接下来我们看看如果想复现或借鉴这个项目你需要准备哪些环境和技术栈。4. 环境准备与前置条件如果你看完前面的机制想在本地跑通这个项目或类似流程我建议按下面的要求准备环境。版本号不必死磕但技术栈要匹配。4.1 硬件环境GPU建议至少一张 24GB 显存的 GPU如 RTX 3090/4090、A10、A100 视预算选择。3B 模型的微调和推理24GB 显存是比较舒适的起点6B~7B 模型则建议 48GB 或以上。内存建议 32GB 以上。磁盘SSD 预留 100GB 以上用于存放模型权重、数据集和中间产物。如果本地资源不足也可以选择云 GPU 实例或 Kaggle 免费 GPUT4 16GB来跑最小验证。4.2 软件环境操作系统Ubuntu 20.04 / 22.04 最佳Windows 也可以但后续 shell 命令建议用 WSL2 或 Git Bash。Python3.10 或 3.11。CUDA11.8 或 12.1 均可取决于 PyTorch 版本。深度学习框架PyTorch 2.x。训练工具建议使用 Hugging Face Transformers PEFTLoRA Accelerate bitsandbytes这是目前开源社区最常见的微调技术栈。评估/执行工具pytest 用于测试执行如果涉及代码修复可以配合 tree-sitter 做 AST 解析。4.3 基础依赖安装先把 Python 环境和基础依赖准备好。# 创建虚拟环境 python3.10 -m venv venv source venv/bin/activate # 安装基础依赖 pip install --upgrade pip pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 pip install transformers datasets accelerate peft bitsandbytes pip install pytest tree-sitter安装完成后建议用以下命令确认 PyTorch 能正常调用 GPUpython -c import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))如果输出True和你的显卡型号说明环境基本可用。5. 复现“自我改进”闭环从最小示例开始完整复现一个多轮自我改进模型通常需要写上千行代码。这里我提供一个最小可运行的闭环示例帮你理解每一步的真实操作。为了降低复杂度我使用一个较小的基座模型路径并用一个简化的编码任务修复损坏的 Python 函数。5.1 定义评测函数评测是整个闭环的“裁判”。先把裁判逻辑写清楚。# 文件路径evaluator.py import subprocess import tempfile import os def run_test(code_string: str, test_code: str) - bool: 在临时目录中执行被测代码和测试代码。 返回 True 表示所有测试通过False 表示存在错误。 with tempfile.TemporaryDirectory() as tmpdir: code_path os.path.join(tmpdir, solution.py) test_path os.path.join(tmpdir, test_solution.py) with open(code_path, w, encodingutf-8) as f: f.write(code_string) with open(test_path, w, encodingutf-8) as f: f.write(test_code) # 执行 pytest使用 -q 静默输出 result subprocess.run( [pytest, test_path, -q, --tbno], cwdtmpdir, capture_outputTrue, textTrue, timeout30 ) return result.returncode 0这个函数做的事情很简单把生成的代码和预置测试代码写入临时目录然后调用 pytest 执行。如果 returncode 为 0说明所有测试通过。5.2 定义“代码修复”提示模板与候选生成在自我改进中模型不直接写新代码而是“修复有 bug 的代码”。这样任务边界更清晰评测也容易自动化。# 文件路径data_prep.py PROMPT_TEMPLATE \ 你是一名 Python 编程专家。以下代码存在 bug请修复它使它能通过所有单元测试。 有问题的代码 python {buggy_code}修复后的代码 def build_prompt(buggy_code: str) - str: return PROMPT_TEMPLATE.format(buggy_codebuggy_code)生成候选答案时需要让模型多次采样以便覆盖不同的修复思路。# 文件路径generate_candidates.py from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_name Salesforce/codegen-350M-mono # 小模型示例仅用于跑通流程 model AutoModelForCausalLM.from_pretrained(model_name) tokenizer AutoTokenizer.from_pretrained(model_name) if tokenizer.pad_token is None: tokenizer.pad_token tokenizer.eos_token def generate_fixes(prompt: str, num_samples: int 5, max_new_tokens: int 256): inputs tokenizer(prompt, return_tensorspt, truncationTrue, max_length1024) outputs model.generate( **inputs, max_new_tokensmax_new_tokens, do_sampleTrue, temperature0.8, top_p0.95, num_return_sequencesnum_samples, pad_token_idtokenizer.pad_token_id ) return [tokenizer.decode(o, skip_special_tokensTrue) for o in outputs]注意这里选用codegen-350M-mono只是为了在普通开发机上快速跑通流程。真正追求高准确率建议使用 3B 或 7B 级别的代码模型例如 DeepSeek-Coder 系列、CodeQwen 系列或 StarCoder2 系列。5.3 构造“自我改进”数据接下来需要一个包含“有 bug 代码 正确测试代码”的数据集。开源社区常用 HumanEval 或 MBPP 中故意注入 bug 的变体。为了演示我们手工构造一个最简单的数据条目。# 文件路径sample_dataset.py sample_bugs [ { id: bug_001, buggy_code: def add(a, b):\n return a - b\n, test_code: def test_add():\n assert add(2, 3) 5\n\ndef test_add_negative():\n assert add(-1, -1) -2\n }, { id: bug_002, buggy_code: def max_of_three(a, b, c):\n if a b:\n return a\n elif b c:\n return b\n else:\n return c\n, test_code: def test_max_positive():\n assert max_of_three(3, 7, 5) 7\n\ndef test_max_negative():\n assert max_of_three(-3, -7, -5) -3\n } ]注意bug_002中当a不是最大值时会误判。这种细小的逻辑 bug 是“代码修复”任务的典型样本。5.4 核心闭环生成 → 评测 → 筛选 → 微调现在把整条流水线串起来。# 文件路径self_improve_pipeline.py from evaluator import run_test from data_prep import build_prompt from generate_candidates import generate_fixes from sample_dataset import sample_bugs import json def collect_good_samples(dataset, num_samples_per_bug5): good_samples [] for item in dataset: prompt build_prompt(item[buggy_code]) fixes generate_fixes(prompt, num_samplesnum_samples_per_bug) for fix_code in fixes: # 提取生成结果中 python 后面的部分便于执行 if python in fix_code: extracted fix_code.split(python)[-1].split()[0] else: extracted fix_code if run_test(extracted, item[test_code]): good_samples.append({ prompt: prompt, completion: extracted, bug_id: item[id] }) return good_samples if __name__ __main__: good collect_good_samples(sample_bugs) with open(good_samples.jsonl, w, encodingutf-8) as f: for sample in good: f.write(json.dumps(sample, ensure_asciiFalse) \n) print(f收集到 {len(good)} 条高质量修复样本)执行这个脚本后会得到一个good_samples.jsonl文件里面的每一行都是一条“问题-修复后代码”的配对数据。这些数据就是下一轮微调的训练语料。5.5 用 LoRA 做增量微调有了高质量样本接下来对模型做一轮轻量级微调。为了在消费级 GPU 上运行这里使用 LoRALow-Rank Adaptation只需要训练很小一部分参数。# 文件路径finetune_lora.py from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training from datasets import Dataset import torch model_name Salesforce/codegen-350M-mono model AutoModelForCausalLM.from_pretrained(model_name, torch_dtypetorch.float16) tokenizer AutoTokenizer.from_pretrained(model_name) if tokenizer.pad_token is None: tokenizer.pad_token tokenizer.eos_token lora_config LoraConfig( r8, lora_alpha32, target_modules[qkv_proj], # 不同模型的模块名不同需要根据实际 model 打印结果调整 lora_dropout0.05, biasnone, task_typeCAUSAL_LM ) model prepare_model_for_kbit_training(model) model get_peft_model(model, lora_config) # 读取数据 data [] with open(good_samples.jsonl, r, encodingutf-8) as f: for line in f: data.append(json.loads(line)) # 构造训练样本prompt completion def format_sample(sample): return { text: sample[prompt] sample[completion] tokenizer.eos_token } formatted_data [format_sample(sample) for sample in data] dataset Dataset.from_list(formatted_data) def tokenize_function(examples): tokenized tokenizer(examples[text], truncationTrue, max_length1024, paddingmax_length) tokenized[labels] tokenized[input_ids].copy() return tokenized tokenized_dataset dataset.map(tokenize_function, batchedTrue, remove_columns[text]) training_args TrainingArguments( output_dir./lora_ckpt, per_device_train_batch_size2, gradient_accumulation_steps4, num_train_epochs3, learning_rate2e-4, fp16True, logging_steps10, save_strategyepoch, ) from transformers import Trainer trainer Trainer( modelmodel, argstraining_args, train_datasettokenized_dataset, ) trainer.train() model.save_pretrained(./lora_ckpt/final)微调完成后模型权重不在原始模型基础上直接更新而是保存为一个轻量的 LoRA 适配器。下次推理时加载基座模型并叠加 LoRA 适配器即可。5.6 合并 LoRA 权重并进入下一轮# 文件路径merge_lora.py from transformers import AutoModelForCausalLM, AutoTokenizer from peft import PeftModel base_model AutoModelForCausalLM.from_pretrained(Salesforce/codegen-350M-mono) tokenizer AutoTokenizer.from_pretrained(Salesforce/codegen-350M-mono) lora_model PeftModel.from_pretrained(base_model, ./lora_ckpt/final) merged_model lora_model.merge_and_unload() merged_model.save_pretrained(./self_improved_model_round1) tokenizer.save_pretrained(./self_improved_model_round1)下一轮迭代时把model_name换成./self_improved_model_round1重新执行“生成 → 评测 → 筛选 → 微调”流程。这就是完整的“自我进化”循环。6. 运行结果与效果验证以上最小示例的目标是跑通闭环而不是立刻达到 90% 准确率。你可能会发现第一轮收集到的优质样本很少——这很正常因为 350M 模型的修复能力有限加上手工构造的 bug 数量少、多样性不足。验证闭环是否运行成功可以从三个层面判断。6.1 数据层面运行self_improve_pipeline.py后检查good_samples.jsonl是否有内容。如果没有 0 条记录说明模型的生成答案全部未通过测试。这时可以调高temperature增加生成多样性。增加num_samples_per_bug。检查buggy_code是否在模型的“能力射程”内。6.2 训练层面在 LoRA 微调过程中观察loss是否逐步下降。如果 loss 不降或震荡明显通常说明数据量太小或者学习率过高。建议从2e-4开始数据量少于 50 条时更保守一点。6.3 评测层面基础模型和第一轮微调后模型在相同测试集上的通过率对比是衡量“自我改进”是否有效的核心指标。可以用以下脚本快速评估。# 文件路径evaluate_model.py from transformers import AutoModelForCausalLM, AutoTokenizer from generate_candidates import generate_fixes from evaluator import run_test from sample_dataset import sample_bugs from data_prep import build_prompt def evaluate_model(model_path, dataset, num_samples5): model AutoModelForCausalLM.from_pretrained(model_path) tokenizer AutoTokenizer.from_pretrained(model_path) if tokenizer.pad_token is None: tokenizer.pad_token tokenizer.eos_token total len(dataset) solved 0 for item in dataset: prompt build_prompt(item[buggy_code]) fixes generate_fixes(prompt, num_samplesnum_samples) passed False for fix_code in fixes: if python in fix_code: extracted fix_code.split(python)[-1].split()[0] else: extracted fix_code if run_test(extracted, item[test_code]): passed True break if passed: solved 1 print(f模型 {model_path} 修复成功率: {solved}/{total} {solved/total:.1%}) if __name__ __main__: evaluate_model(Salesforce/codegen-350M-mono, sample_bugs, num_samples5) evaluate_model(./self_improved_model_round1, sample_bugs, num_samples5)如果第二轮输出中微调后模型的修复成功率高于基座模型说明自我改进闭环真正生效了。7. 常见问题与排查思路把“自我改进”从概念落到工程会遇到不少隐形坑。这里列出我在类似流程中最常遇到的问题。问题现象可能原因排查方式解决方案collect_good_samples返回 0 条基座模型能力不足或温度设置过低检查生成代码的日志看是否存在语法错误调高 temperature/top-p换更大基座模型简化数据结构pytest 执行超时生成代码存在死循环或资源占用过高查看run_test中的 timeout 参数缩短 timeout在生成代码外层增加沙箱限制微调后模型“退化”数据集中混入了低质量样本检查 SFT 数据是否只包含通过测试的答案增加更多测试用例提高筛选门槛训练 loss 不降学习率过高或数据量过小调整学习率并检查数据集条数降到1e-4~5e-5优先补充优质数据加载 LoRA 时报错找不到模块target_modules写错打印模型结构查找实际模块名不同架构模块名不同比如 LLaMA 是q_proj、v_proj合并权重后推理结果变差基座模型和 LoRA 没有同一版本确认merge_lora.py加载的基座模型与训练时一致统一基座模型路径显存不足模型太大或 batch size 太大查看 GPU 显存占用降低 batch size开启梯度累积使用 4bit 量化自我改进提升幅度很小评测任务本身已接近模型能力上限分析失败样本的共性模式失败样本中加入提示模板或修改任务边界关于合法授权与安全边界如果你在真实业务中应用这套流程务必只使用你有权使用的代码、数据和模型权重。涉及人体、涉密或受版权保护的代码数据在送入模型或上传任何服务前先确认合法性和授权范围。模型的“自我改进”是对你已有的合法数据的再加工不是绕过版权约束的工具。8. 最佳实践与工程建议在项目的具体机制之外这套“自我改进”思路沉淀出了几条通用的工程经验值得从架构层面记录。8.1 评测器要像线上一样严格自我改进的“导师”是评测器。如果评测器是松散的数据飞轮就会转歪。在编码任务中评测器至少要做到执行单元测试而不是只做静态对比。覆盖边界条件和异常输入。限制生成代码的执行权限沙箱、超时、资源限制。对通过率、失败类型做日志记录方便归因。弱评测器会不断给模型“喂”看似正确但实际脆弱的样本长期迭代后模型会逐渐学会钻漏洞。8.2 小模型优先跑通大模型用来定上限在预算有限时建议先用小模型把数据飞轮和评测链路跑通再替换为更大基座模型。这样做的原因是小模型的迭代成本低、调试速度快可以快速暴露机制缺陷比如数据格式错误、评测逻辑漏判。等链路稳定后再把基座模型从 0.35B 换到 3B 或 7B通常能拿到显著的准确率提升。8.3 每轮迭代都要做“旧题重测”模型在新一轮微调后可能在旧数据集上表现更好但在更广的任务上退化。工程上称之为“灾难性遗忘”。应对方法是在每一轮微调时混入一定比例的原始指令数据或上一轮的优质样本保证模型不会“只顾眼前新题忘了老技能”。8.4 数据多样性比数据量更重要如果你手工构造 100 条几乎同质的 bug模型学到的是“你给出的固定修复模式”而不是“通用修复能力”。更好的做法是从真实代码库中收集历史 bug 和修复 commit。按错误类型分类语法错误、逻辑错误、类型错误、边界条件错误。每一类均衡采样防止模型偏科。8.5 关注“自我改进”的边际收益自我改进不是无限的。随着迭代轮次增加正确率提升会逐渐放缓。更稳妥的经验是前两三轮提升最明显之后进入平台期。如果连续两轮正确率不再提升应该把精力转向扩充评测集、换基座模型或增加训练数据多样性而不是继续盲目迭代。8.6 安全与权限边界无论你是个人开发者还是在企业内网部署都建议遵守以下原则最小权限训练和评测环境不要开放不必要的网络端口。数据隔离敏感代码数据不要混入公共模型调用链路。版本管理每轮微调后的模型权重和数据快照都要打标签方便回滚。外部依赖审计引入开源训练框架时确认依赖来源可信。9. 从实验到工程你下一步可以怎么走现在回到文章开头的问题这个小模型挑战 GPT-5 的故事究竟对我们有什么实际参考价值我的判断是它的价值不在于告诉你“大模型被超越了”而在于展示了一条特定任务下用更小成本逼近前沿模型能力的工程路径。如果你是一个技术负责人可以考虑在自己的代码智能助手项目中引入类似的“后训练评估闭环”原先只用大模型 API 做一次性生成现在可以内部先跑一个小模型用自动测试打分把高分结果沉淀为训练数据定期微调领域模型降低对昂贵外部 API 的依赖。如果你是算法工程师最值得花时间研究的不是模型本身而是评测系统的可靠性。一个准确、稳定、可扩展的自动评测器是自我改进能否成立的前提。评测器不准后面所有环节都是噪音。如果你只是普通开发者也不妨把这个项目当成一次学习机会跑通最小闭环理解“数据飞轮”如何构建。将来你接触大模型应用开发时会更容易判断哪些功能真的需要微调哪些用提示词就够了以及如何用量化、LoRA、4bit 等技术在本地部署小模型并达到业务要求。想要继续深入可以沿这几个方向展开研究每个基座模型的target_modules差异理解 LoRA 微调的底层原理。收集开源代码数据集如 HumanEval、MBPP在标准基准上复现自我改进的指标提升。尝试把“自我改进”从代码修复扩展到 SQL 生成、配置生成、日志解析等企业常见场景。关注模型评测中的“测试集污染”问题确保你的评测数据没有混入训练数据。最后提醒一句任何“超越 GPT-5”类结论都要先看基准范围、评测口径和任务边界。在 AI 领域这种限定条件下的超越并不罕见也正因如此它才更有工程参考价值。建议把文章收藏起来等你想动手跑通第一轮“自我改进”闭环时直接按上面的步骤操作即可。有任何不明确的地方欢迎在评论区交流。
自我改进AI：小参数编码模型如何以117倍差距挑战GPT-5级能力
编码 AI 的“自我进化”实验117 倍更少参数凭什么能挑战 GPT-5 级能力如果你最近在关注大模型圈子很可能被一个消息刷屏一个编码 AI 项目宣称仅用约 1/117 的参数规模在一个编程基准上跑出了 93.3% 的正确率直接对标甚至超过 GPT-5 的表现。很多人第一反应是这又是标题党吧毕竟 GPT-5 级别的模型背后是数千亿参数、海量算力和复杂训练管线。一个小参数模型凭什么逆袭坦白说我第一眼看到这个标题时也带着怀疑。但真正读完项目材料之后我更倾向于另一个判断这场“小模型挑战大模型”的实验真正的看点不在于参数数字而在于它把“自我改进”Self-Improvement从一个 AI 领域的热门概念落成了一个可复现、可运行的工程范式。这篇文章不打算单纯复述项目简介。我会从你真正关心的问题出发这个小模型到底是怎么炼成的它和传统“训练→微调→部署”的流程有什么本质区别如果你也想在自己的项目里复刻这种“自我进化”机制应该从哪里下手以及最现实的——这种思路适合哪些场景不适合哪些场景文章会拆解项目的核心机制、环境准备、代码实现、运行验证和排错思路并给出我对这个方向的工程判断。如果你对“小模型 监督微调 自生成数据 迭代评估”这条路径感兴趣这篇文章值得读完再收藏。1. 为什么“参数更少、性能更强”这件事值得警惕性关注先说一个很重要的前提在 AI 领域所有“小模型超越大模型”的结论都不能脱离基准测试、任务范围和评估口径来理解。这个项目展示的“93.3% 正确率”核心场景是编码任务Code Generation / Code Repair 类并且是特定评测集上的结果。它不是说一个 3B 参数的模型在综合智能上击败了 GPT-5而是说在限定任务、限定数据分布、且引入自我改进机制之后一个远小于前沿大模型的模型可以在该任务上达到接近或超越前沿模型的准确率。这背后的工程意义非常明确它降低的是“特定任务达到高准确率”的成本门槛。如果你所在的企业或团队长期依赖 GPT-5、Claude 这类大模型的 API 来完成特定编码任务每个月的 token 费用可能相当可观。更麻烦的是某些场景由于隐私或合规要求根本不允许把代码发送到外部 API。这时候一个在本地就能跑、参数量不大、但准确率能打的小模型价值就不只是“省钱”了而是“让过去不可行的方案变得可行”。但为什么说“警惕性关注”因为“自我改进”这个术语现在有被滥用的趋势。很多产品只是加了点上下文学习In-Context Learning或者测试时计算Test-Time Compute就贴上了“自我进化”的标签。真正的自我改进必须包含这样一个闭环模型生成结果 → 自动化评估结果 → 评估反馈作为新数据 → 继续训练模型 → 模型在下一轮表现得更好。没有这个循环就只是普通的模型调用优化。所以读这篇文章时请你带着一个核心问题它到底是用什么机制实现“越用越强”的这个机制能不能迁移到我的项目中2. 核心概念拆解什么是“自我改进 AI”在深入项目之前先把概念讲清楚。2.1 传统编码模型的使用方式大多数开发者对“编码 AI”的使用停留在一次性的“提示词 → 生成结果”模式用户提问Prompt → 模型调用Inference → 输出代码Completion这个模式的本质是模型的权重在训练阶段就固定了。无论你问多少次模型不会因为“上次答错了”而自动记住教训。如果答错了你需要手动改写提示词或者等待模型厂商发布新版本。这是典型的静态模型。2.2 什么是自我改进Self-Improvement自我改进的核心是把“评估结果”重新注入训练流程生成结果 → 自动评测 → 筛选好坏结果 → 形成新训练数据 → 继续训练 → 模型更新 → 再生成 → 再评测这里的关键词是自动评测。如果每一步都需要人工判断生成结果好不好那么所谓的“自我改进”就是半自动的成本依然很高。这个项目能做到“自我进化”前提一定是有一套可自动执行的评测机制——在编码任务中这通常意味着跑单元测试、静态检查、编译验证、输出对比。2.3 监督微调与数据飞轮这个项目大概率基于开源基座模型做监督微调SFT, Supervised Fine-Tuning。和从零训练不同监督微调是在已有预训练模型基础上用高质量的“输入-输出”数据进一步更新权重。这个项目的创新之处不在于 SFT 本身而在于数据来源变了——训练数据不是纯靠人工标注很大一部分是由模型自己先生成、再由自动评测筛选出来的“优质答案”。这个数据飞轮一旦转起来理论上模型可以不断从自身的高质量输出中学习。这就是“自我改进”四个字的底层逻辑。2.4 为什么小模型也能“一口吃成胖子”小参数模型比如 3B、7B 级别的能力上限确实不如千亿模型但在特定任务上上限并不完全由参数量决定。如果你把一个问题限定在“修复 Python 函数中的类型错误”这类规则清晰的编码任务上一个小模型经过充分微调完全有可能在评测集上逼近甚至超过通用大模型。原因很简单任务空间缩小了模型需要记忆的模式就少了小容量也能装下足够好的策略。这也是这篇文章最想传达的一个判断大模型是通用平台小模型是专用引擎。自我改进机制恰好是让专用引擎持续升级的最佳方式。3. 项目的核心机制“自我进化”到底怎么运作从标题和材料信息来看这个项目的核心不是某一个新的基础模型架构而是围绕“自我改进”构建的一套训练与评估闭环。我们可以把它的运行逻辑拆成四个阶段。3.1 阶段一基座模型初始化项目从一个开源预训练模型开始通常是 3B 到 7B 参数规模的代码模型。这个阶段的模型能力是“通才但粗浅”——能写代码但错误率偏高。3.2 阶段二生成候选答案针对编码任务数据集模型对每个问题生成多个候选答案Candidate Solutions。在采样时可能需要设置较高的温度参数temperature和 top-p让生成结果具有多样性。这一步的目的是探索不同解题路径。3.3 阶段三自动评估与筛选这是整个闭环的裁判环节。对每个候选答案评测系统会执行编译检查代码能否通过编译。单元测试能否通过预先写好的测试用例。静态分析是否符合代码风格和常见规范。覆盖率分析测试覆盖了哪些分支。只有通过全部检查的答案才会被标注为“优质答案”。这里要特别强调评测集的质量直接决定了自我改进的天花板。如果评测用例本身就稀疏、有漏洞那么模型学会的就不是“写正确代码”而是“钻评测空子”。3.4 阶段四增量训练SFT Round将筛选出的优质答案整理成新的 SFT 数据集对模型做一轮增量监督微调。训练完成后模型权重更新然后用更新后的模型再次执行阶段二和阶段三进入下一个迭代轮次。每完成一轮就相当于完成了一次“自我进化”。多轮迭代后模型在评测集上的正确率逐步上升最终可能达到 90% 以上。3.5 这个机制为什么能带来收益传统做法是“一次训练一次部署”模型的能力上限在训练结束后就锁定了。而这个项目的做法是“训练-部署-评估-再训练”循环每一轮都在自动修正上一轮的短板。此处的核心收益是你可以用一份算力预算买到“持续变好”的模型而不是“一次定型”的模型。听起来很美好但实施这个闭环远比写模型调用代码复杂。接下来我们看看如果想复现或借鉴这个项目你需要准备哪些环境和技术栈。4. 环境准备与前置条件如果你看完前面的机制想在本地跑通这个项目或类似流程我建议按下面的要求准备环境。版本号不必死磕但技术栈要匹配。4.1 硬件环境GPU建议至少一张 24GB 显存的 GPU如 RTX 3090/4090、A10、A100 视预算选择。3B 模型的微调和推理24GB 显存是比较舒适的起点6B~7B 模型则建议 48GB 或以上。内存建议 32GB 以上。磁盘SSD 预留 100GB 以上用于存放模型权重、数据集和中间产物。如果本地资源不足也可以选择云 GPU 实例或 Kaggle 免费 GPUT4 16GB来跑最小验证。4.2 软件环境操作系统Ubuntu 20.04 / 22.04 最佳Windows 也可以但后续 shell 命令建议用 WSL2 或 Git Bash。Python3.10 或 3.11。CUDA11.8 或 12.1 均可取决于 PyTorch 版本。深度学习框架PyTorch 2.x。训练工具建议使用 Hugging Face Transformers PEFTLoRA Accelerate bitsandbytes这是目前开源社区最常见的微调技术栈。评估/执行工具pytest 用于测试执行如果涉及代码修复可以配合 tree-sitter 做 AST 解析。4.3 基础依赖安装先把 Python 环境和基础依赖准备好。# 创建虚拟环境 python3.10 -m venv venv source venv/bin/activate # 安装基础依赖 pip install --upgrade pip pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 pip install transformers datasets accelerate peft bitsandbytes pip install pytest tree-sitter安装完成后建议用以下命令确认 PyTorch 能正常调用 GPUpython -c import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))如果输出True和你的显卡型号说明环境基本可用。5. 复现“自我改进”闭环从最小示例开始完整复现一个多轮自我改进模型通常需要写上千行代码。这里我提供一个最小可运行的闭环示例帮你理解每一步的真实操作。为了降低复杂度我使用一个较小的基座模型路径并用一个简化的编码任务修复损坏的 Python 函数。5.1 定义评测函数评测是整个闭环的“裁判”。先把裁判逻辑写清楚。# 文件路径evaluator.py import subprocess import tempfile import os def run_test(code_string: str, test_code: str) - bool: 在临时目录中执行被测代码和测试代码。 返回 True 表示所有测试通过False 表示存在错误。 with tempfile.TemporaryDirectory() as tmpdir: code_path os.path.join(tmpdir, solution.py) test_path os.path.join(tmpdir, test_solution.py) with open(code_path, w, encodingutf-8) as f: f.write(code_string) with open(test_path, w, encodingutf-8) as f: f.write(test_code) # 执行 pytest使用 -q 静默输出 result subprocess.run( [pytest, test_path, -q, --tbno], cwdtmpdir, capture_outputTrue, textTrue, timeout30 ) return result.returncode 0这个函数做的事情很简单把生成的代码和预置测试代码写入临时目录然后调用 pytest 执行。如果 returncode 为 0说明所有测试通过。5.2 定义“代码修复”提示模板与候选生成在自我改进中模型不直接写新代码而是“修复有 bug 的代码”。这样任务边界更清晰评测也容易自动化。# 文件路径data_prep.py PROMPT_TEMPLATE \ 你是一名 Python 编程专家。以下代码存在 bug请修复它使它能通过所有单元测试。 有问题的代码 python {buggy_code}修复后的代码 def build_prompt(buggy_code: str) - str: return PROMPT_TEMPLATE.format(buggy_codebuggy_code)生成候选答案时需要让模型多次采样以便覆盖不同的修复思路。# 文件路径generate_candidates.py from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_name Salesforce/codegen-350M-mono # 小模型示例仅用于跑通流程 model AutoModelForCausalLM.from_pretrained(model_name) tokenizer AutoTokenizer.from_pretrained(model_name) if tokenizer.pad_token is None: tokenizer.pad_token tokenizer.eos_token def generate_fixes(prompt: str, num_samples: int 5, max_new_tokens: int 256): inputs tokenizer(prompt, return_tensorspt, truncationTrue, max_length1024) outputs model.generate( **inputs, max_new_tokensmax_new_tokens, do_sampleTrue, temperature0.8, top_p0.95, num_return_sequencesnum_samples, pad_token_idtokenizer.pad_token_id ) return [tokenizer.decode(o, skip_special_tokensTrue) for o in outputs]注意这里选用codegen-350M-mono只是为了在普通开发机上快速跑通流程。真正追求高准确率建议使用 3B 或 7B 级别的代码模型例如 DeepSeek-Coder 系列、CodeQwen 系列或 StarCoder2 系列。5.3 构造“自我改进”数据接下来需要一个包含“有 bug 代码 正确测试代码”的数据集。开源社区常用 HumanEval 或 MBPP 中故意注入 bug 的变体。为了演示我们手工构造一个最简单的数据条目。# 文件路径sample_dataset.py sample_bugs [ { id: bug_001, buggy_code: def add(a, b):\n return a - b\n, test_code: def test_add():\n assert add(2, 3) 5\n\ndef test_add_negative():\n assert add(-1, -1) -2\n }, { id: bug_002, buggy_code: def max_of_three(a, b, c):\n if a b:\n return a\n elif b c:\n return b\n else:\n return c\n, test_code: def test_max_positive():\n assert max_of_three(3, 7, 5) 7\n\ndef test_max_negative():\n assert max_of_three(-3, -7, -5) -3\n } ]注意bug_002中当a不是最大值时会误判。这种细小的逻辑 bug 是“代码修复”任务的典型样本。5.4 核心闭环生成 → 评测 → 筛选 → 微调现在把整条流水线串起来。# 文件路径self_improve_pipeline.py from evaluator import run_test from data_prep import build_prompt from generate_candidates import generate_fixes from sample_dataset import sample_bugs import json def collect_good_samples(dataset, num_samples_per_bug5): good_samples [] for item in dataset: prompt build_prompt(item[buggy_code]) fixes generate_fixes(prompt, num_samplesnum_samples_per_bug) for fix_code in fixes: # 提取生成结果中 python 后面的部分便于执行 if python in fix_code: extracted fix_code.split(python)[-1].split()[0] else: extracted fix_code if run_test(extracted, item[test_code]): good_samples.append({ prompt: prompt, completion: extracted, bug_id: item[id] }) return good_samples if __name__ __main__: good collect_good_samples(sample_bugs) with open(good_samples.jsonl, w, encodingutf-8) as f: for sample in good: f.write(json.dumps(sample, ensure_asciiFalse) \n) print(f收集到 {len(good)} 条高质量修复样本)执行这个脚本后会得到一个good_samples.jsonl文件里面的每一行都是一条“问题-修复后代码”的配对数据。这些数据就是下一轮微调的训练语料。5.5 用 LoRA 做增量微调有了高质量样本接下来对模型做一轮轻量级微调。为了在消费级 GPU 上运行这里使用 LoRALow-Rank Adaptation只需要训练很小一部分参数。# 文件路径finetune_lora.py from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training from datasets import Dataset import torch model_name Salesforce/codegen-350M-mono model AutoModelForCausalLM.from_pretrained(model_name, torch_dtypetorch.float16) tokenizer AutoTokenizer.from_pretrained(model_name) if tokenizer.pad_token is None: tokenizer.pad_token tokenizer.eos_token lora_config LoraConfig( r8, lora_alpha32, target_modules[qkv_proj], # 不同模型的模块名不同需要根据实际 model 打印结果调整 lora_dropout0.05, biasnone, task_typeCAUSAL_LM ) model prepare_model_for_kbit_training(model) model get_peft_model(model, lora_config) # 读取数据 data [] with open(good_samples.jsonl, r, encodingutf-8) as f: for line in f: data.append(json.loads(line)) # 构造训练样本prompt completion def format_sample(sample): return { text: sample[prompt] sample[completion] tokenizer.eos_token } formatted_data [format_sample(sample) for sample in data] dataset Dataset.from_list(formatted_data) def tokenize_function(examples): tokenized tokenizer(examples[text], truncationTrue, max_length1024, paddingmax_length) tokenized[labels] tokenized[input_ids].copy() return tokenized tokenized_dataset dataset.map(tokenize_function, batchedTrue, remove_columns[text]) training_args TrainingArguments( output_dir./lora_ckpt, per_device_train_batch_size2, gradient_accumulation_steps4, num_train_epochs3, learning_rate2e-4, fp16True, logging_steps10, save_strategyepoch, ) from transformers import Trainer trainer Trainer( modelmodel, argstraining_args, train_datasettokenized_dataset, ) trainer.train() model.save_pretrained(./lora_ckpt/final)微调完成后模型权重不在原始模型基础上直接更新而是保存为一个轻量的 LoRA 适配器。下次推理时加载基座模型并叠加 LoRA 适配器即可。5.6 合并 LoRA 权重并进入下一轮# 文件路径merge_lora.py from transformers import AutoModelForCausalLM, AutoTokenizer from peft import PeftModel base_model AutoModelForCausalLM.from_pretrained(Salesforce/codegen-350M-mono) tokenizer AutoTokenizer.from_pretrained(Salesforce/codegen-350M-mono) lora_model PeftModel.from_pretrained(base_model, ./lora_ckpt/final) merged_model lora_model.merge_and_unload() merged_model.save_pretrained(./self_improved_model_round1) tokenizer.save_pretrained(./self_improved_model_round1)下一轮迭代时把model_name换成./self_improved_model_round1重新执行“生成 → 评测 → 筛选 → 微调”流程。这就是完整的“自我进化”循环。6. 运行结果与效果验证以上最小示例的目标是跑通闭环而不是立刻达到 90% 准确率。你可能会发现第一轮收集到的优质样本很少——这很正常因为 350M 模型的修复能力有限加上手工构造的 bug 数量少、多样性不足。验证闭环是否运行成功可以从三个层面判断。6.1 数据层面运行self_improve_pipeline.py后检查good_samples.jsonl是否有内容。如果没有 0 条记录说明模型的生成答案全部未通过测试。这时可以调高temperature增加生成多样性。增加num_samples_per_bug。检查buggy_code是否在模型的“能力射程”内。6.2 训练层面在 LoRA 微调过程中观察loss是否逐步下降。如果 loss 不降或震荡明显通常说明数据量太小或者学习率过高。建议从2e-4开始数据量少于 50 条时更保守一点。6.3 评测层面基础模型和第一轮微调后模型在相同测试集上的通过率对比是衡量“自我改进”是否有效的核心指标。可以用以下脚本快速评估。# 文件路径evaluate_model.py from transformers import AutoModelForCausalLM, AutoTokenizer from generate_candidates import generate_fixes from evaluator import run_test from sample_dataset import sample_bugs from data_prep import build_prompt def evaluate_model(model_path, dataset, num_samples5): model AutoModelForCausalLM.from_pretrained(model_path) tokenizer AutoTokenizer.from_pretrained(model_path) if tokenizer.pad_token is None: tokenizer.pad_token tokenizer.eos_token total len(dataset) solved 0 for item in dataset: prompt build_prompt(item[buggy_code]) fixes generate_fixes(prompt, num_samplesnum_samples) passed False for fix_code in fixes: if python in fix_code: extracted fix_code.split(python)[-1].split()[0] else: extracted fix_code if run_test(extracted, item[test_code]): passed True break if passed: solved 1 print(f模型 {model_path} 修复成功率: {solved}/{total} {solved/total:.1%}) if __name__ __main__: evaluate_model(Salesforce/codegen-350M-mono, sample_bugs, num_samples5) evaluate_model(./self_improved_model_round1, sample_bugs, num_samples5)如果第二轮输出中微调后模型的修复成功率高于基座模型说明自我改进闭环真正生效了。7. 常见问题与排查思路把“自我改进”从概念落到工程会遇到不少隐形坑。这里列出我在类似流程中最常遇到的问题。问题现象可能原因排查方式解决方案collect_good_samples返回 0 条基座模型能力不足或温度设置过低检查生成代码的日志看是否存在语法错误调高 temperature/top-p换更大基座模型简化数据结构pytest 执行超时生成代码存在死循环或资源占用过高查看run_test中的 timeout 参数缩短 timeout在生成代码外层增加沙箱限制微调后模型“退化”数据集中混入了低质量样本检查 SFT 数据是否只包含通过测试的答案增加更多测试用例提高筛选门槛训练 loss 不降学习率过高或数据量过小调整学习率并检查数据集条数降到1e-4~5e-5优先补充优质数据加载 LoRA 时报错找不到模块target_modules写错打印模型结构查找实际模块名不同架构模块名不同比如 LLaMA 是q_proj、v_proj合并权重后推理结果变差基座模型和 LoRA 没有同一版本确认merge_lora.py加载的基座模型与训练时一致统一基座模型路径显存不足模型太大或 batch size 太大查看 GPU 显存占用降低 batch size开启梯度累积使用 4bit 量化自我改进提升幅度很小评测任务本身已接近模型能力上限分析失败样本的共性模式失败样本中加入提示模板或修改任务边界关于合法授权与安全边界如果你在真实业务中应用这套流程务必只使用你有权使用的代码、数据和模型权重。涉及人体、涉密或受版权保护的代码数据在送入模型或上传任何服务前先确认合法性和授权范围。模型的“自我改进”是对你已有的合法数据的再加工不是绕过版权约束的工具。8. 最佳实践与工程建议在项目的具体机制之外这套“自我改进”思路沉淀出了几条通用的工程经验值得从架构层面记录。8.1 评测器要像线上一样严格自我改进的“导师”是评测器。如果评测器是松散的数据飞轮就会转歪。在编码任务中评测器至少要做到执行单元测试而不是只做静态对比。覆盖边界条件和异常输入。限制生成代码的执行权限沙箱、超时、资源限制。对通过率、失败类型做日志记录方便归因。弱评测器会不断给模型“喂”看似正确但实际脆弱的样本长期迭代后模型会逐渐学会钻漏洞。8.2 小模型优先跑通大模型用来定上限在预算有限时建议先用小模型把数据飞轮和评测链路跑通再替换为更大基座模型。这样做的原因是小模型的迭代成本低、调试速度快可以快速暴露机制缺陷比如数据格式错误、评测逻辑漏判。等链路稳定后再把基座模型从 0.35B 换到 3B 或 7B通常能拿到显著的准确率提升。8.3 每轮迭代都要做“旧题重测”模型在新一轮微调后可能在旧数据集上表现更好但在更广的任务上退化。工程上称之为“灾难性遗忘”。应对方法是在每一轮微调时混入一定比例的原始指令数据或上一轮的优质样本保证模型不会“只顾眼前新题忘了老技能”。8.4 数据多样性比数据量更重要如果你手工构造 100 条几乎同质的 bug模型学到的是“你给出的固定修复模式”而不是“通用修复能力”。更好的做法是从真实代码库中收集历史 bug 和修复 commit。按错误类型分类语法错误、逻辑错误、类型错误、边界条件错误。每一类均衡采样防止模型偏科。8.5 关注“自我改进”的边际收益自我改进不是无限的。随着迭代轮次增加正确率提升会逐渐放缓。更稳妥的经验是前两三轮提升最明显之后进入平台期。如果连续两轮正确率不再提升应该把精力转向扩充评测集、换基座模型或增加训练数据多样性而不是继续盲目迭代。8.6 安全与权限边界无论你是个人开发者还是在企业内网部署都建议遵守以下原则最小权限训练和评测环境不要开放不必要的网络端口。数据隔离敏感代码数据不要混入公共模型调用链路。版本管理每轮微调后的模型权重和数据快照都要打标签方便回滚。外部依赖审计引入开源训练框架时确认依赖来源可信。9. 从实验到工程你下一步可以怎么走现在回到文章开头的问题这个小模型挑战 GPT-5 的故事究竟对我们有什么实际参考价值我的判断是它的价值不在于告诉你“大模型被超越了”而在于展示了一条特定任务下用更小成本逼近前沿模型能力的工程路径。如果你是一个技术负责人可以考虑在自己的代码智能助手项目中引入类似的“后训练评估闭环”原先只用大模型 API 做一次性生成现在可以内部先跑一个小模型用自动测试打分把高分结果沉淀为训练数据定期微调领域模型降低对昂贵外部 API 的依赖。如果你是算法工程师最值得花时间研究的不是模型本身而是评测系统的可靠性。一个准确、稳定、可扩展的自动评测器是自我改进能否成立的前提。评测器不准后面所有环节都是噪音。如果你只是普通开发者也不妨把这个项目当成一次学习机会跑通最小闭环理解“数据飞轮”如何构建。将来你接触大模型应用开发时会更容易判断哪些功能真的需要微调哪些用提示词就够了以及如何用量化、LoRA、4bit 等技术在本地部署小模型并达到业务要求。想要继续深入可以沿这几个方向展开研究每个基座模型的target_modules差异理解 LoRA 微调的底层原理。收集开源代码数据集如 HumanEval、MBPP在标准基准上复现自我改进的指标提升。尝试把“自我改进”从代码修复扩展到 SQL 生成、配置生成、日志解析等企业常见场景。关注模型评测中的“测试集污染”问题确保你的评测数据没有混入训练数据。最后提醒一句任何“超越 GPT-5”类结论都要先看基准范围、评测口径和任务边界。在 AI 领域这种限定条件下的超越并不罕见也正因如此它才更有工程参考价值。建议把文章收藏起来等你想动手跑通第一轮“自我改进”闭环时直接按上面的步骤操作即可。有任何不明确的地方欢迎在评论区交流。