韩国大学让AI"用代码思考"，数学解题能力超越百倍体量的大模型

这项由韩国大学（Korea University）与AIGEN Sciences联合完成的研究，以预印本形式发布于arXiv（编号：arXiv:2605.07237），最新版本更新于2026年5月11日。有兴趣深入了解的读者可以通过该编号在arXiv平台查询完整论文。

数学一直是AI最难啃的骨头之一。不是因为模型不够聪明，而是因为数学计算容不得半点差错——哪怕一步算错，整道题就全废了。就像你在用纸笔做多位数乘法，中间某一行不小心写错了个数字，后面所有的推导全都跟着跑偏，最终答案自然南辕北辙。

现有的AI解题方法大致分两类。一类是纯用自然语言推理，就像一个学生完全靠脑子在草稿纸上写文字推导；另一类是"工具辅助推理"，也就是AI一边用文字分析，一边不时调用Python解释器来帮忙算数。后者听起来很合理，但韩国大学的研究团队发现，这种"文字夹代码"的工作方式本身埋着三个结构性缺陷，导致AI的表现始终差一口气。

为了彻底解决这个问题，他们提出了一套全新的框架，叫做THINC（Thinking in Code，即"用代码思考"）。核心思想非常简单：与其让AI用文字推导、偶尔借助代码验证，不如直接让代码本身承担全部推理工作——文字只负责在开头规划一下大方向，之后的所有计算和逻辑全部交给代码来完成。

结果相当令人意外。这个基于4B参数（"4B"代表40亿个神经网络参数，是衡量模型大小的单位）的小模型，在五个顶级数学竞赛评测集上，平均准确率达到78.1%，不仅超越了所有同类"工具辅助推理"系统，甚至超过了参数量是它近60倍的Qwen3-235B-A22B-Thinking。

一、现有方法的三个"暗病"

要理解THINC为什么有效，先得搞清楚它要解决的问题到底是什么。

把AI用文字推理加代码执行的混合模式，比作一个工程师和计算器配合工作的场景，问题就很直观了。这个工程师（文字推理部分）先在脑子里或草稿纸上算一遍，然后把中间结果交给计算器（代码执行部分）去验证。这听起来很稳妥，但实际上有三个很容易被忽略的漏洞。

第一个漏洞叫"事后验证陷阱"。工程师已经用脑子把题做完了，答案算出来了，然后才叫来计算器说"帮我确认一下"。计算器跑了一遍，果然也得出同样的答案。看起来双保险，实际上计算器根本没做任何新的推理——它只是在重复确认一个已经算好的结论。如果工程师脑子里算错了，计算器验证的也是那个错误，起不到任何纠正作用。

第二个漏洞叫"错误悄悄传递"。工程师在脑子里算了一步，得到某个中间值，比如把500的12%算成了50（正确答案是60）。然后他把这个错误的中间值50直接写进了代码里，让计算器继续往后算。计算器忠实地执行了，但它不知道输入进来的50是错的——它不会去质疑这个数字的来源，只会老老实实地用50继续计算。错误就这样被悄悄传递下去，最终得出一个完全错误的答案，而整个过程没有任何警报响起。

第三个漏洞叫"角色重叠浪费"。本来文字推理和代码执行各有各的擅长：文字适合做高层次的战略规划，代码适合做精确的数学计算和符号运算。但在实际的混合模式中，文字推理往往会把解题步骤一步步详细描述出来，相当于把整个算法用文字实现了一遍；紧接着的代码块又把完全相同的算法用程序语言重新实现了一遍。两者做的是同一件事，文字推理的那部分完全是在做无用功，不仅没有发挥自己应有的作用，还浪费了宝贵的计算资源。

二、THINC的核心设计：让代码当主角

THINC的解法可以用一个很直接的类比来理解：把解题过程比作一支施工队修建一栋楼。

在旧的模式里，项目经理（文字推理）会先拿着蓝图把整个施工流程念一遍，告诉大家第一步怎么做、第二步怎么做、预计每步花多少时间、中间某个数字是多少……然后工人们（代码执行）再按照经理说的去干。如果经理念错了某个数字，工人就会按照错误的数字施工，而且没人会去核查经理说的数字对不对。

在THINC的模式里，项目经理只负责最开始的一件事：看一眼蓝图，然后简短说一句"我们要修一栋三层楼，从地基开始，用钢筋混凝土结构"。说完这句话，经理就退到一边了。接下来的所有工作——打地基、砌墙、安装管线——全部由工人们自己按照工程标准来完成，每一步的结果都有实际测量数据为证，不依赖经理的口头描述。

用更技术性的语言来说，THINC的轨迹格式是这样的：一个问题进来之后，模型先产生一段简短的自然语言规划（t?），说明解题的整体策略；然后完全切换到代码模式，每个代码块执行完之后，把执行结果作为下一个代码块的输入依据，直到得出最终答案。两个代码块之间，没有任何自然语言的推理段落。

这个结构的精妙之处在于，它从设计层面就堵死了前面三个漏洞。代码块是主动的推导者，不是事后的验证者；所有中间数值都由解释器产生，没有任何手动输入的机会；自然语言只做战略规划，不做具体推导，两者的职责边界清晰明确。

三、从零到高手：三步训练流程

明白了THINC的核心理念，接下来的问题是：怎么让一个普通的AI模型学会这种"只用代码思考"的方式？

研究团队设计了一个三步走的训练流程，可以类比为培养一位厨师的过程：先观摩名厨做菜（轨迹蒸馏），再系统练习基本功（监督微调），最后通过真实比赛磨炼技艺（强化学习）。

第一步是"观摩名厨"，即从一个更强的教师模型那里采集符合THINC格式的解题样本。研究团队选用了Qwen3.5-27B作为教师模型，给它看三道示例题（包括标准的THINC格式解题过程），然后让它对大量竞赛数学题生成解题轨迹。每道生成的轨迹都要经过严格筛选：答案必须正确、每个代码块都能无错运行、至少包含三个独立的代码块、而且开头的规划部分不能占整个轨迹超过一半的篇幅。这最后两个条件是为了确保筛选出来的样本真的是"代码做主角"，而不是文字推理占了大头、代码只是点缀。经过筛选后，最终保留了12,200条高质量的代码中心型轨迹，构成了THINC-SFT数据集。

第二步是"练习基本功"，即用这12,200条轨迹对学生模型进行监督微调。研究团队选用了两个基础模型：Qwen3-1.7B和Qwen3-4B-Thinking-2507，分别训练出THINC-1.7B-SFT和THINC-4B-SFT两个版本。训练参数方面，使用了32K的上下文长度、学习率7×10??、以及3个训练轮次。这一步的目标不是让模型马上变得很厉害，而是让它学会THINC的格式——就像新厨师先学会基本的刀工和火候控制，而不是直接上来就做满汉全席。

事实上，刚做完监督微调的模型表现确实不算出色：THINC-4B-SFT的平均准确率只有48.1%，比基础模型还要低一些。这是完全在预料之中的——模型此时刚学会了一种新的"做事方式"，但还不够熟练。

第三步是"真实比赛磨炼"，即通过强化学习（Reinforcement Learning，简称RL）进一步提升模型的解题能力。强化学习的逻辑很直观：模型尝试解一道题，如果最终答案对了就得到奖励，如果答错了就不得奖励。通过大量这样的"尝试-反馈"循环，模型逐渐学会哪些解题策略真正有效。

研究团队使用的具体算法叫GRPO（Group Relative Policy Optimization），一种不需要额外"裁判模型"的强化学习方法。训练分为三个阶段，核心差别在于可用的计算资源：第一阶段允许最多20次工具调用、上下文长度16K；第二阶段过滤掉已经被完全解决的简单题，专注于有挑战性的题目；第三阶段大幅扩展资源，允许最多40次工具调用、上下文长度32K，让模型能够处理需要更长推理链的超难题目。

经过完整的强化学习训练，THINC-4B的平均准确率从48.1%跃升至78.1%，提升了整整29.9个百分点。这一步才是真正的"成才时刻"。

四、比赛成绩：碾压同级，以小胜大

研究团队在五个顶级竞赛数学评测集上测试了THINC，分别是AIME 2024、AIME 2025、AIME 2026、HMMT 2025 February和BeyondAIME。这些评测集的题目难度极高，相当于数学竞赛中的顶级赛事水平，普通人看到题目可能连题意都难以理解。

评测方式是为每道题生成16次解答，然后计算平均答对率（avg@16）。这种方式比只生成一次更能反映模型的真实能力，避免了运气因素的干扰。

在这五个评测集上，THINC-4B的平均成绩是78.1%，在四个评测集上拿到了第一名。最直接的对比对象是ASTER-4B——这个模型和THINC-4B使用完全相同的基础模型（Qwen3-4B-Thinking-2507）、相似的教师模型容量和强化学习流程，唯一的区别就是ASTER采用传统的"文字夹代码"交错格式，而THINC采用纯代码推理格式。在这个最公平的对比条件下，THINC-4B在所有五个评测集上均超过了ASTER-4B，平均领先4.1个百分点。更值得关注的是，THINC-4B实现这个成绩所用的工具调用次数（平均6.1次）比ASTER-4B（11.1次）少了将近一半，生成的响应长度（平均13.5K个token）也比ASTER-4B（15.4K）要短。也就是说，THINC不仅更准确，还更高效。

更戏剧性的对比来自跨量级的比较。Qwen3-235B-A22B-Thinking是目前开源社区中最强的纯文字推理模型之一，参数量高达2350亿（其中220亿是激活参数）。THINC-4B的参数量只有40亿，体量差距接近60倍。然而在五个评测集中的四个上，THINC-4B的得分都超过了这个巨无霸，平均领先2.9个百分点。

THINC-4B也超越了它自己的教师模型Qwen3.5-27B（在相同的3-shot提示条件下），平均领先幅度达到13.4个百分点——一个学生全面超越了自己的老师，这在机器学习领域并不常见，但通过监督微调加强化学习的组合确实能做到这一点。

在更小的1.7B规模上，THINC同样展现出一致的提升。THINC-1.7B的平均准确率达到42.8%，超过了Qwen3-1.7B基础模型（32.2%）、被提示使用Python解释器的Qwen3-1.7B（29.8%），以及同量级的竞争者CoRT-1.5B（25.7%）。

五、它真的在"用代码思考"吗？

一个合理的疑问是：THINC只是在形式上遵循了"先规划、后代码"的格式，还是真的在用代码来进行推理？研究团队用两个指标来回答这个问题。

第一个指标是"每条轨迹写了多少行代码"。THINC-4B平均每条轨迹写349行代码，远超排名第二的ReTool（261行）、ASTER（102行）和CoRT（40行）。单从数量来看，THINC确实在大量使用代码。

第二个指标更能说明问题，叫"代码接地率"——也就是最终答案有多大比例实际出现在某个代码块的执行输出里，而不是由模型直接在文字中生成的。这个指标衡量的是最终答案到底是"代码算出来的"还是"文字写出来的"。THINC-4B的代码接地率高达99.2%，几乎所有答案都来自解释器的执行输出。相比之下，ReTool是88.4%，rStar2-Agent是74.3%，CoRT和ASTER大约都是50%左右，DemyAgent最低只有34.9%。这意味着有超过一半的时间，这些对比模型的最终答案实际上是直接由文字推理"拍脑袋"给出的，完全绕过了代码解释器——而绕过解释器，就意味着绕过了精确计算的保障。

THINC-4B的这个特性，从它的轨迹结构来看是"被迫"的——因为格式规定了两个代码块之间没有文字推理的空间，答案要么从代码执行结果里来，要么就没有地方可以生成。这个"被迫"其实是个优点。

六、代码出错了怎么办？

这里有一个很自然的担忧：如果代码是唯一的推理工具，一旦代码执行出错，模型岂不是完全没有退路了？在传统的"文字夹代码"模式里，代码出错了，模型至少还可以在下一段文字中分析原因、重新规划，就像登山时遇到一条路不通，可以用语言说"这条路不行，我们换条路"。THINC没有这个选项——两个代码块之间没有文字，面对执行错误，模型只能在下一个代码块里直接应对。

研究团队用一个叫"Recovery@k"的指标来测量这种情况下的表现：在前k个代码块全部执行出错的情况下，模型最终还能答对的比例。k从1测到5，覆盖了从一次失败到五次连续失败的场景。

结果出乎意料：所有的传统交错推理系统都随着k的增加而大幅退步。ASTER在k=1时有52.1%的恢复率，到k=5时跌到18.5%；rStar2-Agent在k=1时有39.1%，到k=5时直接跌到0%；ReTool、DemyAgent和CoRT也呈现类似的下滑趋势。

THINC-4B的表现截然不同：在k=1、2、3时，恢复率稳定在64%到69%之间，几乎没有下滑；到k=4时下降到54.5%，k=5时下降到33.3%。即使是k=5这个极端场景，THINC-4B的恢复率也是所有交错推理基线中最高值的将近两倍。

研究团队进一步分析了这种鲁棒性的来源。刚做完监督微调、还没经过强化学习的THINC-4B-SFT，在k=1时的恢复率已经达到42.9%，超过了大多数交错推理基线。这说明"代码中心型"的格式本身就带来了一定的鲁棒性——不依赖文字推理来吸收错误，反而逼着模型在代码层面就把问题解决掉。在强化学习之后，这种鲁棒性进一步大幅提升，k=1、2、3时分别提升了超过20个百分点。

七、一道真实题目的完整解题过程

为了让上述描述更加具体，研究团队在论文中给出了THINC-4B解决AIME 2026第3题的完整轨迹。题目是：找出不超过100的整数中，有多少个可以表示成a+b+ab的形式，其中a和b是不同的正整数？（参考答案是70。）

模型的规划段只做了一件事：把a+b+ab这个表达式改写成(a+1)(b+1)-1，然后说"这样直接枚举就可以了，我去写代码"。接下来没有一句多余的文字，直接进入代码执行。

第一个代码块：写了一个双重循环，枚举所有满足条件的(a,b)对，把结果存入集合去重。输出：70。但模型在代码注释里写道，循环里的`break`语句可能有问题——也就是说，它在代码执行结束之后，通过阅读自己写的代码发现了一个潜在的逻辑漏洞，而这个反思过程完全是在代码注释里完成的，没有任何文字推理段落。

第二个代码块：针对刚才发现的问题重写了循环逻辑，修复了break条件，并顺便输出了所有满足条件的数字的完整列表。结果仍然是70。

第三个代码块：把这70个数字按奇偶分类，验证没有遗漏或重复计算。奇数48个，偶数22个，合计70个，验证通过。

第四个代码块：用完全不同的数学等价形式（令u=a+1，v=b+1，通过枚举乘积u×v来计数）独立重新推导了一遍，并且明确检验两种方法的结果是否一致。结果还是70，两种方法完全吻合。

第五个代码块：反向验证——找出1到100中所有不能被表示的数字，确认恰好有30个，从而确认可以被表示的有70个。

最终答案：70。全程没有任何文字推理介入，所有的自我纠错、结构验证、独立重推都在代码块内部完成。

八、超出数学领域：科学题目也适用

研究团队还做了一个额外的测试，把THINC-4B放在GPQA-Diamond评测集上跑了一遍。这个评测集不是数学题，而是研究生级别的物理、化学和生物选择题，对AI来说是完全陌生的领域。

结果显示，THINC-4B在avg@16指标上得到66.48%，比基础模型Qwen3-4B-Thinking的66.32%略高；在best@16（16次尝试中的最佳成绩）指标上达到91.41%，超过ASTER-4B的90.40%，并比基础模型高出7.57个百分点。这个结果表明，代码中心型的推理方式并不局限于数学领域，在需要系统性分析和精确计算的科学问题上同样有效。

归根结底，THINC这项研究回答了一个很简单的问题：当你让AI在做数学题时"少说话、多动手"，会发生什么？答案是，它做得更好了，而且快了，还更不容易出错。

这并不是说文字推理没有价值——战略规划仍然需要语言来完成。但具体的计算、逻辑推导和验证这些事情，代码本就比文字更擅长，强迫它们共存反而制造了麻烦。研究团队找到了一个让两者各司其职的方式，效果相当显著。

当然，这项研究也有其局限。目前的实验只在1.7B和4B这两个较小的模型规模上进行，在更大规模的模型上是否同样有效还不清楚。评测范围也局限于竞赛数学，代码中心型推理是否适合其他类型的问题（比如开放式问答或创意写作）还需要进一步探索。

如果你对技术细节感兴趣，可以通过arXiv编号arXiv:2605.07237找到这篇完整论文。研究团队也表示代码和模型将很快开放，届时感兴趣的研究者可以直接在自己的任务上尝试。

Q&A

Q1：THINC框架和普通的"AI用代码解数学题"有什么区别？

A：普通的工具辅助推理（TIR）是文字推理和代码执行交替进行——AI先用文字分析一段，再调用代码算一段，然后继续用文字推理。THINC的核心区别是：开头只用文字做一次战略规划，之后所有推理步骤全部由代码完成，两个代码块之间没有任何文字推理。这使得所有中间结果都由解释器生成，避免了文字推理中的计算错误被悄悄传递到代码里的问题。

Q2：THINC-4B是怎么用40亿参数打败2350亿参数的大模型的？

A：参数量大不等于解题方式更合理。Qwen3-235B-A22B-Thinking用纯文字推理解题，文字计算本身容易出错；而THINC-4B把所有数值计算交给Python解释器来完成，从源头上消除了文字计算的不可靠性。加上强化学习训练让模型反复尝试难题、积累有效的解题策略，最终在竞赛数学这类对精确计算要求极高的领域，THINC-4B的解题方式比大模型的纯文字推理更有优势。

Q3：THINC在代码执行出错时是怎么应对的？

A：THINC没有文字推理段落来"解释"执行错误，模型只能在下一个代码块里直接重写逻辑来应对。实验测试显示，这种方式的鲁棒性反而比传统交错推理更强——在前五个代码块全部出错的极端情况下，THINC-4B仍有33.3%的恢复率，而最强的对比模型（ASTER）已经跌到18.5%，rStar2-Agent直接跌到0%。强化学习阶段让模型大量练习了"遇到错误直接在代码层面修复"这种能力。