卡内基梅隆：AI改代码，凭什么判断修好了没？

一个AI帮你改代码时，它凭什么判断"修好了没有"？

换成你自己写科学计算程序——模拟流体边界条件，或者求量子力学方程的本征值——出了问题通常怎么办？多半是打印几个中间变量，算算残差，看数值收不收敛。这话说着轻巧，做起来相当琐碎：先得弄懂物理方程，再把它翻译成一段检验代码，然后运行、读结果、改程序、再检验，来回循环。如今把活儿交给AI агент，问题就落在：它该怎么知道自己改对了没有？

卡内基梅隆大学和晶泰科技团队的论文《Rules to Tools》研究的正是这一点。实验设计朴素却扎实：给AI агент两种不同的"检查方式"，比较哪一种能让它把科学计算代码修得更好。

第一种是文字规则——把物理定律、边界条件等要求写成明明白白的说明文档，由AI агент自己写代码去验证。第二种是现成工具——直接提供一个可调用的检查函数，输入当前代码，输出一个数值结果，告诉它偏差有多大。

听着像不像考试作弊器的合法版本？其实不是。这里的"工具"并不告诉AI正确答案，只是替它省掉"自己写检测代码"这一步，直接说明当前程序离正确答案还差多远。

这个设定让人想到一个很具体的场景：修一台老式收音机，面前摆着电路图说明书，上面写着"输出电压应该在5到6伏之间"，接下来你得自己找个

论文把这套检查工具称作R2T

所谓R2T，即Rules to Tools——把公开的科学计算规则（边界条件、物理守恒定律、方程残差等）打包成可直接调用的检测程序，供AI агент在改代码过程中反复调用

研究团队做了一个相当讲究的对照实验，选用SciCode这个科学编程评测集

SciCode是由科学家编写的编程基准测试集，题目要求AI生成能解决真实科研计算问题的代码，涉及量子力学、分子动力学相关的数值方法

他们挑出8个此前完全没用来开发过检测工具的题目编号，确保这些工具不是"照着答案反推"出来的。每个题目分给两组AI агент：一组只拿文字规则加普通代码执行权限，另一组在文字规则之外还能调用现成检测工具。两组所用模型、预算、起始代码全部一致，唯一差别就是有没有这个检测工具。

结果出来了：文字组修复成功13道，工具组15道（满分16道，每题跑两次）。乍看工具组赢了，可把其中一道题（第77题）单独拎出来，故事就变了。

这道分子动力学题目，文字组两次尝试均告失败，工具组两次都成功。剔除它之后，剩下七道题两组的平均完成度完全一样。研究者还做了一项统计检验，叫任务聚类置信区间

任务聚类置信区间是一种统计方法：把每道题当作独立样本簇，反复随机抽样来估计两组差异的可信范围，避免样本太少时把偶然结果误判成真实效应

算出来的区间是负12.5到正43.75个百分点，横跨零点。换句话说，统计上还不能特别有把握地说工具组一定强过文字组。

这是整篇论文最诚实的地方，也是最容易被标题党忽略的细节：工具带来的提升并非均匀撒在所有任务上，而是集中在少数几个任务里，其余任务两组表现几乎没差别。

第77题为何差这么多？论文给了一个很有意思的解释。这道题一开始跑检测工具，结果显示"没有发现违规"——工具没报错，看起来一切正常。但工具组那两次成功尝试，后来还是靠普通代码执行发现并修复了周期性边界包裹和压力计算的问题，而这些问题根本不在检测工具的覆盖范围内。

也就是说，这道题的成功可能跟检测工具本身关系不大，而是因为工具组多了一次"检查一遍确认没问题"的机会，顺带让AI агент多想了一步，发现了工具没覆盖到的bug。

这个发现挺值得琢磨。

有时候，检测工具真正的作用并不在报出哪个错上。它会让AI агент多做一道检查，而这道额外的审视本身，就能带来收获。

类似情况也出现在第七个独立题目组里的第11题：初始检测同样显示"无违规"，工具组还是修好了。研究者专门强调，这些效应"没有一个初始标记出错误"，他们没有把结果简单归功于"工具发现了bug"，而是老实承认背后机制更复杂。

另一个让人意外的结果来自额外实验。研究者把"检测工具"这个概念拆开看：原工具组用的是封装好的专用命令，调用很方便；他们又加了两种变体——一种直接把检测代码源文件扔给AI агент，让它用普通Python自己跑；另一种提前把检测结果打印出来，直接告诉AI агент"这是你现在代码的检测报告"。

三种方式里，直接给源代码用Python跑的那组和原来的专用命令工具组一样都是15道题通过（满分16），只给检测报告文本的那组是14道。这说明让AI агент能反复调用检测逻辑这件事本身很重要：不管调用是经由精心包装的命令，还是直接丢源代码让它自己跑，效果都接近；可只给一次性检测报告，少了"反复调用、持续追踪"这一环，效果就打折扣了。

好比去医院体检，拿到一张纸质报告写着"血压偏高"，看完就完事；和医生给你配个随身血压计，让你每天测、每天看变化调整生活方式——两种干预力度完全不同。前者是一次性诊断，后者是持续反馈。缺了持续反馈，诊断再精确，病人也难知道自己调整的方向对不对。

成本账更有看头。研究者把两组消耗的计算资源都记了下来：工具组在“模型生成的内容量”上——也就是token数——一般会少一些，省下的幅度大约在5%到30%之间，具体多少要看任务组；可到了“公开检测程序本身占用的CPU时间”这一项，工具组反倒高出不少，有的任务组高出38.6%，有的甚至高出87.3%。

CPU时间指的是运行检测程序本身所耗费的处理器时间，跟AI模型生成文字用掉的token数是两码事，属于两种完全不同的成本。

这事说得通。检测工具直接把精确数值摆出来，AI agent不用再自己写一堆验证代码、再把结果描述一遍，话自然就少了；但每调用一次检测工具，机器都得重新跑一遍物理计算，这部分计算实打实要耗CPU。好比请了个随叫随到的专业检测员，你省掉了自己写报告的功夫，可检测员每次上门都得开车过来，油钱是跑不掉的。

研究者还设了一组更刁钻的场景，叫开发暴露型任务。

开发暴露型任务指的是：这些题目编号先前已被研究团队拿去开发和调试检测工具，存在“检测工具可能被这几道题的具体代码细节调教过”的风险，因此单独拎出来做敏感性分析。

他们换了一份失败的起始代码——题目还是同一道，程序版本不同——结果文字组10次里成了3次，工具组成了7次。差距看着不小，不过论文老老实实标注了样本量太小，置信区间是10到70个百分点，区间很宽，说明结果波动也大，不能过度解读。

偏微分方程求解器这条赛道上，团队也做了配对实验。详细文字说明版本完成23道（满分24），检测工具版本完成24道，几乎没差别，但工具版本的输出token数量少了31.2%。这组数据相对更稳，因为任务量更大、置信区间也更紧。

偏微分方程是描述温度分布、流体运动这类连续变化过程的数学方程，属于科学计算里最核心的问题类型之一。

论文里还有一组流体仿真实验，叫选定流动任务组。这组故意挑了一批“用文字描述探测后仍然失败”的题目，等于提前把容易的筛掉，只留难题给两组比。在这种刻意偏向困难样本的设定下，工具组的优势看着更明显，21比16（满分28），但研究者也坦承，这个筛选过程本身就会让结果偏向工具组，属于实验设计上的局限，并非工具本身有多神。

读到这儿你可能已经看出来了，这篇论文最打动我的不是“工具更好”这个结论，而是它摆结论的方式。几乎每个正面结果后面，研究团队都会补一句“但这个效应主要集中在某道题”，或者“置信区间跨过了零”，或者“这个比较是在筛选过的样本上做的”。这种近乎自我拆台的严谨，在如今人人都想讲一个漂亮故事的论文环境里，挺少见。

论文另外还测了两个科学计算基准，MDArena

MDArena是评测AI agent处理真实分子动力学模拟工作流的基准测试集，涉及分子结构、模拟协议、输出文件等多种检查维度。

和AInsteinBench

AInsteinBench评测的是AI agent在真实科学软件代码仓库里完成修复任务，涵盖多个开源科研项目的接口和功能检验。

在这两个历史数据集里，纯文字规则组的成功率是5/18和4/15，加上检测工具的组合则是7/18和7/15，提升确实有，但同样算不上压倒性。

这篇论文要解决的关键矛盾就在这儿。科学计算跟普通编程不一样：正确答案取决于物理规律和数值精度，代码语法对不对并不是重点。代码跑通了、没报错，结果照样可能违背能量守恒，或者边界条件方向搞反。这种“能运行、结果错”的情形，常规调试工具发现不了，得有懂物理、懂方程的检查逻辑才行。R2T 想干的事，就是把这类检查逻辑做成 AI agent 随时能调用的工具，省得每回都从头现造。

这个思路的价值不在于让AI agent变聪明了，而在于它把一部分原本要靠专业知识才能完成的验证工作提前封装好，变成了随取随用的基础设施。跟实验室里把常用化学试剂预先配好、贴上标签放在架子上是一个道理：不是说有了试剂就不必懂化学，而是省掉了每次从头配试剂的重复劳动，让人力能集中在真正需要判断的地方。

要是没有这套预制检测工具会怎样？论文给出的答案是：大部分时候两组表现差不多，少数任务上差距明显，而且差距的来源往往不是工具报出了关键错误，而是工具的存在逼着AI agent多走了一步审视流程。这个发现本身比“工具更好”这个简单结论更有价值，它提示我们，有时候流程设计的意义不在于提供了多准确的信息，而在于创造了一个固定的“停下来检查”的节点。

写在后面

读完这篇论文，最触动我的其实不是哪个具体数字，而是那张置信区间横跨零点的表格。研究者完全可以只报告“13比15”这个正面结果，省去统计检验的麻烦，论文看起来会更漂亮。但他们没这么做，而是老老实实把不确定性摆在读者面前。这种处理方式让我想到一个问题：眼下我们看到的很多AI能力评测报告，到底有多少经得起这种“剔除一个异常样本后效应消失”的检验？

另一个让我反复琢磨的细节是第77题和第11题的故事。工具明明没报出任何错误，AI agent却还是靠多做的一轮检查流程把问题解决了。这说明“检测”这件事的价值，有时候不在信息层面（告诉你哪里错了），而在行为层面（逼你多看一遍）。很多生产力工具的真实作用机制也是这样，番茄钟并不是真在“管理时间”，它只是在固定的间隔逼你停下来看一眼自己在干什么。

论文留下的问题也很明显：检测工具的编写时间完全没算进成本核算，论文自己也承认了这一点。如果把“人工把每条物理规则翻译成可执行代码”的时间成本算进去，这笔账还划算吗？什么样的科学计算任务值得花这个功夫预先打造检测工具，什么样的不值得？这个问题论文没有回答，可能也是接下来值得追问的方向。

Q&A

Q1：R2T是什么？

R2T的全称是Rules to Tools。它的做法，是把科学计算里那些公开规则——边界条件、物理守恒定律之类——打包成可以直接调用的检测程序。AI агент改代码时，能一遍遍调用这些工具，核对当前程序是否达标。

Q2问的是：AI агент配上检测工具之后，修复效果是否真的更好？答案是整体有提升，可提升集中在少数几道题上。多数任务里两组表现差不多，统计置信区间也说明这种提升不够稳定。说到底，不能一口咬定工具组更强。

Q3问的是检测工具会不会推高计算成本。会。实验发现，用了检测工具，模型生成的文字量一般会变少，可跑检测程序本身吃掉的CPU时间反倒多了38%到87%。成本只是从一处挪到了另一处，一边降一边升。