让AI写出能跑赢市场的交易代码，为什么比想象中难十倍

2026年9月的一篇论文里，几个研究者做了一件挺较真的事。

他们想知道，如果让一个大语言模型专门去学写量化交易代码，到底能学成什么样。不是泛泛地说"AI会写代码"，而是精确地问：给它一句话描述的交易策略，它能不能写出一段真正能跑、能交易、还跟你说的意思一致的程序。

这个问题听起来简单，做起来却是另一回事。

**核心问题：代码能跑和代码对，是两件完全不同的事**

先说一个可能颠覆你认知的事实。

一段代码语法完全正确，能顺利跑起来，依然可能是废的。

它可能从头到尾一笔交易都没做成，因为触发条件写反了。它也可能做了一堆交易，但那根本不是用户要的策略，比如用户说"均线金叉买入"，模型却写成了"均线死叉买入"，程序照样顺畅运行，只是逻辑完全相反。

这就是算法交易代码生成这件事的难点所在。它不像写个网页爬虫，跑出结果对不对一眼能看出来。

Backtrader

：一个Python的开源量化交易回测框架，用来模拟策略在历史数据上的表现。

要让模型写出合格的Backtrader策略代码，它得同时理解好几层东西：技术指标怎么用、买卖条件怎么判断、仓位怎么管理、止损逻辑怎么写、框架的生命周期方法怎么调用。随便一个环节出错，整个策略就名存实亡。

研究者之前做过一个叫QuantCode-Bench的评测基准，专门用来测这件事，包含400个交易策略的文字描述任务。他们发现，一段代码要被认定"合格"，得依次闯过四关：语法编译通过、能在回测环境里顺利执行、至少产生一笔交易、通过AI裁判对语义是否符合要求的判断。

这次的研究，就是想搞清楚，能不能通过专门的训练，让模型在这四关上都变得更强。

他们试了两条路：一条是继续预训练，另一条是监督微调。这两条路听起来都是"训练模型"，但做的事情完全不一样。

**继续预训练：先让模型"泡"在交易框架代码里**

继续预训练*：在模型已经完成基础训练之后，再用某个特定领域的大量文本或代码继续训练它，让模型对这个领域更熟悉，这个过程不涉及具体的任务指令，只是让模型"读"更多相关内容。

研究者从GitHub上收集了大量跟算法交易相关的仓库代码，用关键词筛选出跟交易框架、技术指标、市场数据相关的项目，再按star数和更新时间过滤掉不活跃的仓库，最后用去重算法清理掉大量的分叉项目和雷同模板。最终攒出了大约50到60亿token的语料。

这一步不涉及"用户问什么、模型答什么"的配对，模型只是单纯地继续学习怎么把这些代码的下一个词接下去。

这就好比你想让一个刚入职的新员工尽快熟悉公司，与其直接给他布置任务让他边做边学，不如先让他把过去三年的项目文档和内部代码库通读一遍。他可能还不会独立处理具体业务，但至少不会再对着公司专用的某个工具或者某个命名规范一脸茫然。如果跳过这一步直接让他干活，他大概率会在最基础的调用方式上反复栽跟头，因为他压根不知道公司内部的"行话"是什么。

效果如何？

数据显示还不错，但没有想象中那么惊艳。

在参数量为397B的Qwen3.5模型上，继续预训练让"裁判通过率"（Judge Pass，衡量语义是否符合要求）从41.5%提升到47.5%，涨了6个百分点。在参数量更小的35B模型Qwen3.6上，这个指标从27.8%提升到33.0%，涨了5.2个百分点。

回测成功率和产生交易的比例也都有相应提升，但整体来看，这是一种"温和的进步"，而不是质变。

**监督微调：给模型一本"标准答案"**

监督微调*（SFT，Supervised Fine-Tuning）：用一批人工验证过的"问题-标准答案"配对数据，直接训练模型按照这种映射关系去生成内容，相比继续预训练，这一步有明确的输入输出对应关系。

如果说继续预训练是让模型"多读书"，监督微调就是直接给它"刷题库"，而且这个题库里的每一道题都有经过验证的标准答案。

研究者构建了一个大约800条的数据集，每一条都是"用户的自然语言交易请求"配上"一段验证过能跑、能交易的Backtrader代码"。这些请求不是编出来的，而是从Reddit、StackExchange和GitHub上搜集的真实讨论内容整理而来，保证贴近真实用户会怎么提需求。

这里有个关键细节，生成这些标准答案的时候，研究者是让模型在一个带着Backtrader框架文档的智能体环境里去写代码，鼓励它尽量用框架自带的组件，而不是自己从零造轮子。这样做的好处是两方面的：一是写出来的代码更"地道"，符合框架的惯用写法；二是方便筛掉那些看起来合理、但其实跟框架运行机制不兼容的答案。

效果怎么样？这次是真正的质变。

在35B模型的序列中，经过继续预训练之后再做监督微调，Backtest（回测成功率）从53.8%直接跳到83.5%，涨了近30个百分点；产生交易的比例从36.8%涨到60.0%；语义裁判通过率从33.0%涨到58.2%，涨了超过25个百分点。

如果把这个过程类比成教一个新手厨师，继续预训练相当于让他翻遍了所有菜谱书，知道了各种食材和调料的名字。而监督微调则是手把手带他做了800道菜，每道菜出锅前都有人尝过确认没问题才算数。读菜谱能让他认字,实际跟着做菜才能让他真正学会掌勺。如果没有这800道菜的实操训练，他可能连菜谱里写的步骤该怎么落地都想不明白。

**多轮对话里，继续预训练出现了一个反直觉的现象**

这篇论文里最让人意外的发现，出现在多轮交互的测试里。

研究者设计了一个"代理式"（agentic）评测场景，模型写完代码后，如果没通过测试，系统会把具体的报错信息反馈给它，让它修改，最多给10次机会。T1代表第一次尝试的通过率，T10代表最多10轮之后的最终通过率。

原本的预期是，继续预训练既然整体提升了对框架的熟悉程度，那第一次和最后一次的表现应该都会变好。

结果却是：只做了继续预训练、没做监督微调的35B模型，第一轮通过率从基线的22.3%涨到了32.3%，看起来是进步的。但是到了第10轮，它的通过率却只有32.5%，几乎和第一轮持平，而原始基线模型经过10轮修改后能达到47.5%。

也就是说，继续预训练之后的模型，几乎学不会"从错误反馈里改进"这件事。

研究者的解释是，继续预训练用的是纯代码续写的训练方式，没有对话格式、没有指令跟随的训练信号，这可能悄悄削弱了模型理解"用户给我提了个修改意见，我该怎么回应"这种对话能力。

这就像一个人专心苦练了三个月的独奏，技艺确实精进了，但如果这三个月里完全没有跟乐队合奏过，等真正上台跟别人配合演出时，他反而会因为听不懂指挥的临场手势而频频出错。单独练习时间越长，有时候"配合"这项能力反而被遗忘得越彻底。

而经过监督微调之后的模型就完全不同。它的第一轮通过率是58.3%，10轮之后能到79.5%，两项指标相比基线模型分别提升了36个百分点和32个百分点。监督微调同时改善了"一次写对"的能力和"根据反馈修正"的能力，这说明问题不在于多轮交互本身有多难，而在于训练数据的格式是否包含了对话式的指令结构。

**更大的考验：真实代码仓库里的修复任务**

SWE-bench

：一个评测大语言模型能否解决真实GitHub代码仓库里issue（问题反馈）的基准测试，要求模型理解代码库上下文、生成补丁、跑测试、根据反馈修复代码。

研究者还额外构建了一个类似SWE-bench的测试集，专门针对算法交易相关的代码仓库，大约200个经过验证的任务。这个场景比单独写一段策略代码要复杂得多：模型得先读懂issue描述的是什么问题，再去代码库里定位相关文件，改代码，跑测试，根据测试结果再修。

这里最强的通用大模型GPT-5.4也只解决了38.6%的任务，Qwen3.5-397B-A17B是33.2%，Kimi-K2.5是29.0%。

这个数字远低于前面提到的单策略生成任务的最终成功率，这说明把一个具体的技术能力从"干净的单任务环境"迁移到"真实、混乱的代码仓库环境"，中间的落差依然巨大。

**一个意外的副作用：训练强了一项能力，却弄丢了另一项**

这是整篇论文里我觉得最值得单独拎出来说的部分。

研究者在准备把经过领域特训的35B模型部署到实际产品里时，发现了一个麻烦：这个模型在跟外部工具交互时，经常生成格式不规范的"工具调用"，具体表现是调用标签没有正确闭合。

结构化工具调用*：大语言模型在作为智能体工作时，需要按照约定好的格式去调用外部工具（比如运行代码、查文件），这个格式必须严格符合解析规则，否则调用系统无法识别。

这个问题不管是只做了继续预训练的模型，还是继续预训练之后又做了策略生成微调的模型，都存在。也就是说，针对特定领域（写交易代码）做强化训练的过程中，这个模型把原本掌握的"怎么规范地跟工具系统对话"这件事给悄悄丢了。

这跟著名的"灾难性遗忘"现象高度吻合，当你拿新数据集中力度训练模型某项特定能力时，它可能会连带丢掉原本已经掌握、但这次训练没有特意强化的别的能力。

这就好比一个本来中英文都很流利的翻译,被公司派去封闭培训了三个月的德语,结果专业术语的德语确实突飞猛进，但回来后却发现，他原本应对日常对话的英语口语反而变得生硬磕巴了。专项强化训练这件事本身，往往是有代价的，它挤占的不只是时间，还可能悄悄覆写掉原有的能力。

研究者尝试了两种补救方案。

第一种是参数空间的权重合并

权重合并*：把两个不同训练阶段的模型参数，按一定比例线性组合成一个新模型，这是一种试图同时保留多个模型优点的低成本手段。

他们把经过特训的模型和原始模型按0.65比0.35的比例做了线性合并，结果这个方法没有解决问题，合并后的模型依然会输出格式错误的工具调用。

第二种方案是在合并后的模型基础上，再做一轮专门针对"工具使用轨迹"的恢复性微调，训练数据里专门包含大量结构完整的工具调用样例。这次格式问题确实被修复了，模型重新能够生成解析器认可的规范调用。

但代价是，这个恢复后的模型在前面提到的代码仓库修复任务上，表现反而比原始基线模型更差：原始基线能解决23.7%的任务，恢复后的模型（16k上下文版本）只能解决16.3%，32k版本更是只有13.0%。

这说明一件很重要的事：格式对了，不等于能力恢复了。

模型重新"会说话"了，能生成解析器认可的格式，但它判断"什么时候该调用哪个工具、调用完之后该怎么处理结果"这个更深层的决策能力，并没有真正跟着恢复回来。

这就好比一个人中风之后经过语言康复训练，终于能把每个字清楚地念出来了，但他说出来的句子逻辑经常是混乱的，前言不搭后语。发音这个表层功能修复了，背后支撑"说出有意义的话"的那套认知过程，却没有完全跟上。

研究者坦诚地说，他们没有做进一步的对照实验去确认具体原因，只是提出了几种可能的猜测，比如训练序列长度是否起到了某种隐性的筛选作用，比如长轨迹里是否存在"离策略"的偏差问题。这是一个被诚实标注为"尚未解决"的开放问题。

**从比较表格看全貌**

论文里有一组数字很能说明问题的全貌。

把特训后的35B模型（经过继续预训练加监督微调）摆在整个大模型排行榜里看，它的回测成功率是83.5%，远高于自己原始基线的46.0%，甚至超过了参数量大得多的通用模型Gemini-3-Flash（76.0%）。但跟真正的顶尖模型比，比如Claude Opus 4.6的98.2%，还是有明显差距。

这说明专项训练能让一个相对小的模型在特定垂直领域里，表现追平甚至超过某些更大的通用模型，但距离行业最前沿依然有路要走。

而且这篇论文反复强调一件事：代码写得对，不代表策略能赚钱。

整个评测体系从头到尾都没有把收益率、夏普比率这类经济指标纳入考核。他们的理由很直接，如果把赚不赚钱也算进"对不对"的标准里，模型很可能会为了追求回测收益，偷偷篡改用户原本要求的策略逻辑，这就从"忠实执行用户意图"变成了另一回事。

这个区分其实很值得琢磨。一个靠谱的代码助手，首先得保证"你让我做什么我就做什么"，至于这个策略本身在市场里能不能赚钱，那是另一个完全不同层面的问题，不该被混在一起评价。

Q&A

Q1：QuantCode-Bench是什么？

A：QuantCode-Bench是论文团队此前构建的一个评测基准，包含400个算法交易策略的文字描述任务，用来检验大语言模型生成的Backtrader代码是否能编译通过、顺利运行、产生交易、并且在语义上符合用户原本的要求。

Q2：继续预训练和监督微调哪个效果更好？

A：监督微调的效果明显更强。在35B模型上，继续预训练把语义裁判通过率从27.8%提到33.0%，而在此基础上再做监督微调能进一步提到58.2%，而且监督微调同时改善了模型第一次尝试的成功率和多轮修改后的最终成功率，继续预训练反而会削弱模型从错误反馈中修正的能力。

Q3：为什么模型写的交易代码能跑却不一定对？

A：因为代码语法正确和能顺利执行，不等于它实现的是用户真正想要的策略逻辑。模型可能把买入条件写反、漏掉止损规则、或者用错指标，代码照样能运行甚至产生交易，但跟用户描述的策略完全是两回事，所以必须要有语义层面的判断才能确认代码是否真正做对了。