AI代码修复工具真的需要每次都“跑一遍程序“吗？

这项由北京航空航天大学、武汉大学与新加坡管理大学联合开展的研究发表于2026年的软件测试与分析国际顶级会议ISSTA 2026论文编号为arXiv:2606.26978有兴趣深入了解的读者可通过该编号查询完整论文。**一个被所有人默认正确的假设**在软件开发的世界里有一类工具正在悄悄改变程序员的工作方式那就是基于大语言模型也就是ChatGPT、Claude这类AI的自动程序修复工具。这些工具能够读懂代码里的bug描述自动生成修复补丁甚至还能通过反复运行测试来验证自己的修复是否正确就像一个不知疲倦的程序员不断地写代码、跑测试、看报错、再改代码循环往复。这套写代码→运行程序→看结果→再改的工作流程已经成为当今最顶尖AI代码修复系统的标配。没有人质疑它的必要性每个人都默认运行测试当然有用反馈当然有价值不然为什么花这么多时间等待程序跑完然而这支来自北航、武大与新加坡管理大学的研究团队决定较真地问一句运行代码这件事真的值这个价吗这个问题乍听起来有些荒谬。一个修复bug的工具不跑测试那它靠什么知道自己改对了然而研究团队做了一个精心设计的实验把能不能跑测试这个变量单独拎出来控制其他条件一律不变然后比较有测试权限和没有测试权限的AI工具最终修复成功率到底差多少。结果让所有人都大吃一惊。**一、那8.8次测试运行都在做什么**在开始做控制实验之前研究团队先做了一件事把目前公开发布的AI代码修复工具的行为记录全部扒出来看一遍。他们总共分析了7745条完整的工作日志这些日志来自四款主流AI代码修复工具SWE-agent、OpenHands、LiveSWEAgent和Mini-SWE-agent涵盖了十二种不同的大语言模型包括GPT-4、GPT-5、Claude系列、Kimi-K2、Qwen3-480B、Gemini-3-Pro、DeepSeek-V3.2等。这些工具都在一个叫SWE-bench的标准测试集上接受评测该测试集包含了GitHub上真实的代码仓库和真实发生的bug。平均下来每修一个bug这些AI工具会运行8.8次测试。但这个数字的背后藏着巨大的差异。用最新Claude-4-Sonnet模型驱动的OpenHands平均每个任务要跑18.7次测试而用GPT-5.2驱动的Mini-SWE-agent平均只跑2次两者之间相差将近10倍。更有意思的是更新的模型反而普遍比老模型跑更多测试唯一例外是GPT-5.2它跑得特别少。研究团队还仔细分析了这些测试发生在工作流程的哪个阶段。他们把整个修复过程分成三个阶段早期开始的三分之一、中期中间的三分之一、晚期最后的三分之一。结果发现测试运行越来越集中在晚期。以OpenHands配合Qwen3-480B为例超过55.9%的测试发生在最后阶段。而GPT-5.2和Kimi-K2这类较新的模型早期阶段的测试极少GPT-5.2甚至只有1.8%的测试发生在早期。这背后有一个合理的解释较新的模型可能已经能够从问题描述本身理解bug的本质不需要先跑测试来摸清情况而是直接动手改改完才跑测试验证。至于这些测试的成功率整体平均是57.9%。也就是说大约有四成的测试运行是失败的AI工具看着报错继续改代码。晚期运行的测试成功率普遍高于早期比如OpenHands配合Claude-3.5-Sonnet早期成功率只有42%到了晚期飙升到72%。这说明随着修复进展AI工具越来越接近正确答案测试通过的概率也越来越高。**二、那么禁止跑测试会怎样**了解了现状之后研究团队设计了真正的核心实验。他们保持AI代码修复工具的所有其他能力完全不变——工具可以读文件、搜索代码、写补丁唯独在能不能运行测试这件事上做文章。实验设计了四种不同的执行权限档位形成一个从完全禁止到完全放开的光谱。第一档叫禁止执行通过提示语告诉AI不要跑pytest、unittest等测试框架同时也不安装项目的依赖库让测试即便尝试了也会因为缺少依赖而失败就像给工具一把不能插入锁孔的钥匙。第二档和第三档叫配额限制分别给工具一次或三次测试机会并且告诉它每次运行测试要花一个点数要求它认真考虑每次是否值得用。第四档叫预算引导测试次数没有限制但提示语里要求工具在每次运行前考虑成本收益。最后一档叫完全放开就是现有系统的默认状态想跑多少次就跑多少次。实验覆盖了三款代理工具商业闭源的Claude Code用Anthropic的Claude Sonnet 4.5模型和Codex用OpenAI的GPT-5.2-xhigh模型以及开源的OpenCode用阿里的Qwen2.5-Coder-32B模型通过vLLM自托管。测试集使用了SWE-bench的两个子集Lite版本的前100个案例和Verified版本的前100个案例共200个任务每个任务每种配置跑一遍总计3000次完整的修复尝试。结果出来了。Claude Code在禁止执行模式下的修复成功率是63%在完全放开模式下是64%差距是1个百分点。Codex在Lite集上禁止执行居然以74%反超完全放开的73%在Verified集上73%对75%差2个百分点。开源的OpenCode两种模式下都是大约10%左右误差在1个百分点以内。研究团队用统计学方法McNemar检验验证了这些差异根本不具备统计意义p值均大于0.05意味着这点差距完全在随机波动范围内没有任何一组数据能说明能跑测试比不能跑测试带来了可靠的提升。还有一个有趣的边界现象OpenCode使用的Qwen2.5-Coder-32B模型有65K的上下文窗口限制相当于这个AI的工作记忆容量有限。当它被允许无限制地跑测试时大量的测试输出日志塞满了它的上下文反而让它没有足够空间好好读代码最终连补丁都生成不出来了——完全放开模式下成功生成补丁的比例从74%跌到了50%。对于这类上下文受限的较小模型给它一次精心挑选的测试机会配额1次模式反而能取得最好的效果Lite上14%Verified上17%高于其他所有配置。**三、不让它跑测试省了多少**成功率差不多那成本呢运行一次测试的代价远不止等程序跑完这么简单。从AI工具的角度看每次测试的结果——那些冗长的报错信息、堆栈追踪、测试日志——都会被塞回到AI的对话历史里占用它的工作记忆推高API调用的费用。从工程部署的角度看让AI工具运行真实项目的测试需要事先为每个代码仓库搭建好运行环境安装好所有依赖维护好Docker镜像这是一项持续的工程成本。禁止执行模式把这些成本一刀切掉了。对于Claude Code禁止执行比完全放开节省了56%到62%的token消耗对应的墙钟时间也就是真实等待时间减少了48%到54%——禁止执行模式平均531到573秒完成一个任务完全放开模式则需要1028到1234秒几乎慢一倍。对于Codex节省幅度相对小一些因为它本身的推理消耗就很大测试反馈的占比相对较小配额1次模式节省约21%到25%的token是最优选择。对于OpenCode禁止执行模式在Verified集上节省了67.7%的token和67.4%的时间代价只是1个百分点的成功率差异。还有一个经常被忽略的好处禁止执行意味着不需要为每个代码仓库维护测试环境。在实际工业部署中每新增一个需要修复的项目就要维护一套对应的运行环境这种工程负担会随着规模增长而线性放大。禁止执行模式彻底消除了这个成本。**四、测试到底在哪里没帮上忙**成功率差不多成本差很多那测试到底在干什么研究团队深入挖掘了600个禁止执行vs完全放开的对比案例把它们分成四类两种模式都成功Pass→Pass、两种模式都失败Fail→Fail、禁止执行成功但完全放开失败Pass→Fail、反过来完全放开成功但禁止执行失败Fail→Pass。结果600个案例里有547个91%是稳定的——也就是说无论有没有测试权限结果都一样。真正因测试而改变结果的只有53个案例其中24个是有测试反而变差了29个是有测试才修好了净收益只有5个案例。这种接近对称的分布意味着测试大致上帮了一些忙也大致上坏了一些事最终抵消得差不多。研究团队仔细分析了两个稳定群体揭示了背后的两个原因。第一个原因是测试在找到问题在哪这件事上几乎没有帮助。理论上在开始修改代码之前先运行一次测试可以复现bug、看到报错信息帮助AI确定应该改哪个文件。研究团队把这类修改代码前运行的测试叫做复现执行仔细统计了它的效果。商业模型Claude Code在成功案例里有55.2%的实例用了复现执行但有没有这个复现文件定位准确率都超过95%两种模式之间只差不到2个百分点。Codex更极端成功案例里只有6.4%用了复现执行。最有意思的是OpenCode它的成功案例里没有一个用了复现执行每一次成功都是直接读代码、找问题、改代码根本不需要跑测试来辅助定位。而且在这些复现执行里只有大约一半是有用的——也就是说运行结果里包含了文件路径、堆栈信息或行号能告诉AI问题在哪里。另一半或者因为缺少依赖直接报错或者只输出了所有测试通过这类没有任何定位价值的信息。所以实际上大约只有一半的复现执行产生了可行动的反馈而这些反馈对最终定位准确率的影响依然微乎其微。第二个原因是测试反馈在把错误改对这件事上也帮助有限。商业模型Claude Code有54%的案例只做了一次代码修改就结束了Codex是60.5%就算在完全放开模式下大多数成功的修复也只是写一次、写对了。在确实做了多次修改的案例里完全放开模式下只有49.2%的商业工具案例在跑完测试后真的修改了代码Claude Code的响应率67.5%明显高于Codex31%。更令人深思的是那些失败案例的具体失败方式。在完全放开模式下失败的案例里81.2%的Claude Code案例和100%的Codex案例曾经在自己运行的测试里看到过测试通过的结果——但提交到SWE-bench官方评测系统后依然失败了。换句话说AI工具以为自己修好了它自己选的测试确实也通过了但官方用来判断是否真正修复的测试用例却没通过。这就像一个学生做完试卷后对了对答案发现选择题全对就认为考试肯定过关但实际上老师评分主要看大题而大题完全错了。这个现象揭示了一个深层问题AI工具倾向于运行它自己认为相关的测试但这些测试往往不是官方用来验证bug修复是否完整的测试集。于是自我验证通过和真正修复成功之间存在一道鸿沟而更多的测试运行并不能弥合这道鸿沟。OpenCode则表现出另一种失败模式它的失败案例里只有52.3%产生了任何验证性测试而且这些测试里只有11.1%曾经通过过。换句话说Qwen2.5-Coder-32B的问题不在于自欺欺人地以为通过了而在于它根本连让测试通过的补丁都写不出来它的困境发生在更早的阶段。**五、越复杂的bug越需要跑测试这个假设也不成立**有人可能会说好也许简单的bug不需要跑测试但对于复杂的多文件修改测试反馈应该很有价值吧研究团队特地验证了这个直觉。他们把Verified集上的100个测试案例按照标准答案补丁的复杂度分组只修改一处1个hunk的有62个案例修改2到3处的有25个修改4处及以上的有13个。然后在每个复杂度分组里分别比较禁止执行和完全放开的成功率差异。结果是非单调的也就是说复杂度越高并不意味着测试越有帮助。对于Claude Code单处修改的案例里完全放开比禁止执行高6.5个百分点但在4处及以上修改的案例里禁止执行反而比完全放开高23.1个百分点——也就是说对于最复杂的bug完全放开模式反而更容易失败。Codex在各复杂度分组间几乎没有差异。OpenCode的趋势也类似地翻转了。一个可能的解释是复杂的多处修改需要整体性的推理要同时理解多个代码改动之间的关联。而无限制的测试运行会把大量报错日志塞进AI的上下文打断它的整体推理让它陷入局部的、逐条修错的模式反而适得其反。不管确切原因是什么测试的价值随着bug复杂度单调递增这个假设被这组数据明确否定了。**六、排除作弊的可能性**研究团队也考虑到了一个合理的质疑也许那些商业模型在训练数据里见过SWE-bench的答案所以在禁止执行的情况下依然表现不差是靠背答案而不是靠推理他们用了两个方法来排除这个可能性。第一他们比较了禁止执行模式和完全放开模式下生成的补丁内容发现完全相同的补丁只占24%Claude Code、1%Codex和14%OpenCode大多数是改了同一个文件但改法不同平均相似度在42%到60%之间。这说明模型在适应当前上下文有没有测试反馈来生成不同的解决方案而不是机械地复述记忆中的答案。第二他们特意选用了Qwen2.5-Coder-32B这个开源模型来做验证因为这个模型的训练数据截止日期早于SWE-bench Verified测试集的发布时间意味着它在训练时根本没见过这些答案。但在这个干净的开源配置下禁止执行和完全放开的成功率差距依然是0个百分点。这就排除了数据污染的解释。**七、软约束还是硬约束结果都一样**还有一个技术细节需要交代研究使用的禁止执行主要是通过提示语软性约束的也就是告诉AI不要跑测试但并不强制阻止。实际上Claude Code偶尔还是会尝试跑测试只是因为依赖没安装而失败。研究团队针对这个问题做了两个额外验证。一是只统计那些在禁止执行模式下一次测试都没跑过的案例在这个更严格的子集里结果与完整样本一致。二是专门给Claude Code加了CLI级别的硬约束使用--disallowedTools参数直接禁止pytest等命令在Verified集上的结果是63%对67%差4个百分点依然在误差范围内。无论软约束还是硬约束结论都没有变化。**这告诉了我们什么**说到底这项研究揭示的是一个被工程惯性掩盖的事实现在的AI代码修复工具之所以跑这么多测试并不是因为每次测试都真的有帮助而是因为这是标准做法没有人认真算过这笔账。研究团队发现绝大多数情况下AI工具要么一次写对、不需要测试反馈要么即便测试反馈了也改不对。真正靠测试反馈扭转败局的案例少得可怜而测试反馈反过来干扰了AI推理、导致本来能修对的案例变成失败的数量与之旗鼓相当。这背后还有一个更深的问题AI工具选择运行的测试往往不是能真正判断bug是否修复的测试。自我验证通过了不代表真正修复了这个鸿沟是当前技术架构难以弥合的。这对实际使用这类工具的工程师来说意味着什么如果你正在部署或使用AI代码修复系统在成本敏感的场景下完全可以考虑限制测试权限——省下一半以上的时间和费用成功率几乎不受影响。而如果你是这类工具的开发者也许应该思考如何让工具更聪明地决定什么时候值得跑一次测试而不是默认永远跑个没完。执行能力应该是一种有意识地使用的工具而不是无条件开启的默认状态。这项研究提供了翔实的数据支撑让这个道理从直觉变成了可量化的事实。---QAQ1AI代码修复工具禁止运行测试后修复成功率会大幅下降吗A根据这项研究的实验数据禁止AI代码修复工具运行测试后修复成功率几乎没有变化。Claude Code在禁止执行模式下的成功率是63%完全放开模式是64%差距只有1个百分点。Codex在部分测试集上禁止执行反而更高。统计检验证实这些差异属于随机波动不具备统计意义。Q2AI代码修复工具运行测试主要消耗哪些资源A主要有三类资源消耗。一是token消耗每次测试的输出日志会被塞回AI的对话历史推高API费用禁止执行可节省56%到62%二是时间完整测试模式比禁止执行模式慢约一倍三是工程成本运行真实项目测试需要为每个代码仓库搭建并维护运行环境禁止执行可彻底省去这笔持续开销。Q3SWE-bench是什么这项研究为什么用它来测试AI代码修复工具ASWE-bench是一个专门评测AI代码修复能力的标准测试集包含了GitHub上真实代码仓库中真实发生过的bug。每个案例提供代码仓库快照、问题描述和官方测试用例通过是否通过官方测试来判断AI生成的补丁是否真正修复了bug。这项研究选用它是因为其代表性强、评判标准客观且有大量已有工具的公开日志可供分析。