这项由南洋理工大学、华为技术有限公司和香港大学联合开展的研究，以预印本形式于2026年7月7日发布，论文编号为arXiv:2607.06065，感兴趣的读者可通过该编号查阅完整论文。
软件开发的世界里，有一个让所有程序员都头疼的问题：你费尽心力写了一段代码来修复一个软件漏洞，提交上去之后，却不知道它到底修好了没有。没有人帮你检查，没有人给你反馈，你就像把一封信投进了邮筒，却永远不知道收件人有没有收到。
近年来，人工智能编程工具的进步让情况有了变化。AI已经能够扮演"代码工程师"的角色，自动分析软件问题并提交修复方案——也就是所谓的"拉取请求"（Pull Request，简称PR，可以理解为"修复建议稿"）。然而问题依然存在：AI提交完修复方案之后，同样没有人帮它检查，这个方案是真的解决了问题，还是只是"看起来解决了"？整个过程仍然是单向的、缺乏反馈的。
这就是这篇论文要解决的核心问题。研究团队提出了一个叫做SWE-Review的框架，核心思路是：给AI写的修复方案配一个"审稿人"——另一个AI，专门负责检查那份修复方案写得对不对，哪里有问题，应该怎么改。这样一来，整个流程就从"写完就算"变成了"写——审——改——再审"的闭环循环。
一、为什么一份AI写的修复方案需要另一个AI来审查
代码审查在软件工程里是一个古老而重要的实践。人类团队里，一名程序员写完代码之后，另一名同事会仔细阅读并提出意见，这个过程叫做Code Review（代码审查）。它能发现错误、提升质量、防止问题代码进入正式版本。
然而，当AI开始大量提交修复方案时，这个环节却严重滞后。现有的自动代码审查工具大多只会做一件事：把修复方案的"差异文件"（也就是显示哪里改了什么的记录）交给AI模型，让它一次性给出通过或拒绝的判断。这就好比请一位考官评卷，但只给他看学生写了哪几行字，而不给他看整本教材、参考答案和出题背景——考官只能凭经验猜测对不对，很容易出错。
真正的问题在于，一个看起来合理的修复方案，未必解决了真正的根源问题。它可能只是消除了表面的报错，而根本的逻辑缺陷依然藏在代码深处。判断这件事，需要审查者深入挖掘整个代码仓库，追踪问题的来龙去脉，而不只是盯着那几行被修改的代码看。
这就是SWE-Review与以往审查工具最根本的区别：它训练出的"审查者"（Reviewer Agent）不是静静坐在那里读一份文件，而是主动在代码仓库里四处探索、追踪调用链、动手运行测试，像一位亲身调查的侦探那样，在掌握了足够证据之后再做出判断。
二、侦探式审查：主动探索与静态阅读的差距到底有多大
研究团队专门设计了一个基准测试集——SWE-Review-Bench，来衡量这种"主动探索式审查"到底比"静态阅读式审查"强多少。这个测试集包含1384份由AI生成的修复方案，来自500个真实软件问题，使用了三个能力参差不齐的AI代码生成器来产生这些方案，形成了高、中、低三种质量档次的样本分布。
评价一个审查者好不好，研究团队使用了三把尺子。第一把叫"完成率"，衡量的是审查者能不能产出一份格式正确、可以被解析的审查报告，就像看一个侦探最终有没有写出结案报告。第二把叫"决策准确率"，衡量审查者判断"通过还是要求修改"这个二选一的准确度，就像看侦探抓没抓到真凶。第三把叫"修改后解决率"，这是最实用的一把尺子：审查者给出反馈之后，代码工程师照着反馈去改，改完之后问题解决了吗？这把尺子直接衡量了审查的实际价值。
论文里有一个非常直观的案例——sympy-13877问题。这是一个Python数学库里的漏洞：当你用某个算法计算一个包含符号变量的矩阵的行列式时，会报出一个"非法NaN比较"的错误（NaN是"不是一个数字"的意思，出现在不应该出现的地方就会引发崩溃）。一个AI代码工程师提交了一份修复方案，在代码的某个下游位置加了一个保护性检查，防止NaN值触发比较操作。表面上看，崩溃消失了，错误不报了。
然而，当研究团队的主动探索式审查者介入时，它没有直接看修复方案。它先读懂了问题描述，然后顺着代码的调用链一路追溯——矩阵行列式计算流程从哪里进入、经过哪些函数、调用了哪些工具。它发现，真正的问题其实在另一个文件`matrices.py`里：一行代码本该写成`ret = cancel(ret)`，但实际上只写了`cancel(ret)`，返回的结果被直接丢弃了，未被简化的零表达式因此被错误地当成非零值参与了后续计算，进而导致一系列连锁错误。那个候选修复方案只是在下游堵住了崩溃，但错误结果（行列式返回NaN而非正确数值）依然存在。
主动探索式审查者发现了这一点，要求修改，并指出了真正的修复位置。静态阅读式审查者则因为没有追溯上游，只看到了修复方案"防止了崩溃"，就批准通过了。后者的结论——这个修复"安全、有针对性且不引入回归问题"——在逻辑上看似合理，实际上却是错的。
在量化比较上，使用Claude Opus 4.6作为统一的审查模型，主动探索式审查在三个不同质量档次的修复方案上全面胜出。以决策准确率为例，在由最弱AI生成的修复方案上，主动探索式审查达到89.4%，而静态阅读加上额外文件上下文的方式只有80.8%，仅看差异文件的方式只有72.0%。这一差距在难度更高的案例上更加明显——研究团队按照修复方案与标准答案的差异程度和需要验证的行为范围，将测试集分成了简单、中等、困难三档，发现主动探索式审查在困难档案例上的决策准确率领先幅度最大。
这个结论背后有一个清晰的道理：当一个问题的答案不在那几行被修改的代码里，而是藏在整个代码仓库的某个角落时，只盯着差异文件看是不够的，必须主动去找。
三、让小模型也能做好审查：从轨迹数据中学习侦探技能
主动探索式审查之所以强，是因为它能够动态收集证据。但这种方式依赖于强大的模型（如Claude Opus 4.6），成本很高，也无法直接让普通研究者复现或使用。那么，能不能把这种能力"教给"更小、更轻量的模型？
研究团队的回答是肯定的，而且他们为此构建了一个专门的训练数据集——SWE-Review-Traj，包含8914条高质量的审查轨迹。所谓"审查轨迹"，就是一个完整的审查过程记录：审查者在代码仓库里走了哪些步骤、看了哪些文件、运行了哪些测试、得出了什么结论、给出了什么诊断建议。这就好比把一位经验丰富的侦探破案的全过程详细录下来，然后用这些录像来培训新侦探。
这些训练数据来自SWE-rebench这个大规模真实软件问题集合。研究团队先用三个AI代码生成器产生候选修复方案，再用能力较强的开源模型GLM-5（带有"思考模式"）作为老师模型来对每份方案做审查，记录下完整的探索过程。原始产生了14156条轨迹，经过筛选——只保留决策结论正确的（即正确通过了真正有效的方案，或正确拒绝了无效方案的轨迹）——最终留下8914条作为训练数据。
为了验证训练数据的质量，研究团队从两个维度进行了检验。语义层面，他们让Claude Opus 4.6和GPT-5.4两个模型分别对审查报告的诊断质量打分，评估三个维度：诊断是否准确指出了问题根源、修改建议是否正确、论据是否有扎实的代码依据。两位评委的平均分都超过3分（满分5分），一致性很高（Cohen's κ系数为0.72），只有3.3%的评分相差超过2分。功能层面，研究团队随机抽取100个真实被拒绝的案例，分四种条件让代理重新修复：完全没有审查反馈、只有拒绝决定没有诊断、有老师模型的完整审查反馈、有访问了标准答案和测试用例的"神谕"审查。结果显示，完全没有反馈时修复成功率只有3%，只有拒绝信号时提升到8%，加上老师模型的诊断反馈后跃升到21%，而"神谕"的上限是32%。这意味着那些诊断信息确实是有用的，能帮助代理找到正确方向。
用这套数据训练出来的模型（研究团队称之为SWE-Review-8B和SWE-Review-30B-A3B，分别基于80亿和300亿参数的基础模型）表现相当可观。以较小的SWE-Review-8B为例，训练前这个模型几乎无法产出格式正确的审查报告（完成率约4%），决策准确率接近随机猜测水平（约50%）。训练后，完成率升至71%到84%，决策准确率提升了18到21个百分点，达到67%到72%。在实际应用中，对于由较弱AI生成的修复方案（原始解决率27.5%），SWE-Review-8B能将审查后修改的最终解决率提升至35.1%，提升幅度接近8个百分点。
四、审查技能还能反哺代码生成：一个模型同时学会写和审
研究的另一个发现出人意料：审查轨迹不只是对训练审查者有用，它们对训练代码生成者同样有用。
研究团队做了一组对比实验：用同样数量的数据，分别训练一个只学代码生成轨迹的模型，和一个同时学习代码生成轨迹与代码审查轨迹的模型，然后直接比较两者在解决真实软件问题上的成绩。
结果出人意料地清晰。在1000条代码生成数据的规模上，单独训练代码生成的模型解决率为27.6%，混合加入等量审查数据后提升到28.4%。在2000条数据规模上，单独训练达到31.2%，混合训练达到36.8%，差距扩大到5.6个百分点。在3000条数据规模上，单独训练34.0%，混合训练37.8%。这说明审查训练数据为模型提供了一种对代码生成也有帮助的思维方式——要修复一个问题，你得先真正理解它的根源在哪里，而审查训练恰好强化了这种能力。
更有趣的是，混合训练出来的模型同时成为了一个可用的审查者。它的审查完成率从原来的9%到33%（仅学代码生成时的水平）跳升到了68%到87%，决策准确率达到67%到72%。这意味着同一个模型可以既扮演代码工程师又扮演审查者，在自己写完修复方案之后自己审一遍，发现问题再自己修改——一套完整的"写-审-改"循环完全由一个模型承担。在这种设置下，最终软件问题解决率从初次生成时的27.6%提升到了34.6%，31.2%提升到41.8%，34.0%提升到41.2%，取决于训练数据规模。
五、比"多试几次"更聪明的策略：审查驱动的迭代修改
当AI系统在面对一个困难问题时，一种常见的应对方式是"多试几次，然后挑最好的那个"——就像扔骰子，多扔几次，总能撞到一个好结果。这种方法在学术界叫做"Best-of-N"（N选最优）。
问题在于，每次尝试都是从零开始，彼此之间没有任何信息传递。前九次失败的经验，对第十次尝试完全没有帮助。这好比一个学生做一道应用题，做错了之后把卷子揉掉，重新发一张空白卷继续做，而不是在错误基础上修改——效率极低。
研究团队提出的"审查驱动迭代修改"（Review-Guided Iterative Revision）则是另一种策略：每次修复方案被拒绝，审查者都会给出具体的诊断和修改建议，代码工程师在原有方案基础上针对性地改进，而不是推倒重来。这就像老师改卷之后给出详细批注，学生照着批注修改，而非重新做一遍。
研究团队将这种策略与另外两种方法进行了量化比较，都使用Qwen3-30B-A3B作为代码生成模型，使用训练好的SWE-Review-8B作为审查者。第一种比较对象是"验证器选最优N"——用另一个专门训练的评分模型（SWE-Lego-Verifier-8B）给多份候选方案打分，挑分数最高的。第二种是"审查者门控重采样"——审查者审查候选方案，审查通过了就停下，否则重新生成一个，直到通过或达到最大次数上限。
在最大尝试预算为5次的情况下，审查驱动迭代修改的解决率从基线的22.9%提升到了38.4%，而且平均只用了2.44次就达到了这个结果（因为审查通过就立刻停止循环）。审查者门控重采样在最大预算16次时才达到32.3%的解决率，但平均消耗了8.9次。验证器选最优N在最大预算16次时只能达到25.6%，而且每次增加预算都要付出完整的采样成本，没有任何提前停止机制。
从效率角度看，审查驱动迭代修改达到了2.28个百分点/百万词元（词元是AI模型处理文字的基本单位）的提升效率，而审查者门控重采样只有0.35个百分点/百万词元——相差约6.5倍。这意味着，在消耗同样计算资源的前提下，前者能带来比后者多6.5倍的性能提升。
六、深入解剖：审查者在哪里会犯错，以及为什么
研究团队没有止步于展示好结果，还详细分析了审查者的错误模式——这部分内容对于理解整个系统的局限性非常重要。
通过分析Claude Opus 4.6在所有测试案例上的272个错误，研究团队发现错误分为两大类：167次"假通过"（实际上没修好，却被批准了）和105次"假拒绝"（实际上修好了，却被要求改）。
假通过的根源大致分为三类，比例相近：微妙的逻辑缺陷经过代码检查仍被忽视（占37.7%），测试用例不够充分未能暴露问题（占32.1%），以及跨文件的推理断链（占29.0%）。值得注意的是，"没有运行测试"这个选项在Opus的错误分析中是空的——因为Opus几乎在每次审查中都会运行复现测试（99.9%的案例），所以假通过的问题不在于测试缺席，而在于测试质量不足或测试本身就是由有同样错误思维的AI写出来的。在假通过的案例里，有82%的审查报告里出现了"通过"字样，说明审查者被自己写的测试欺骗了；而62%的假通过修复方案里包含了由AI代码工程师自己写的测试文件，这些测试自然会验证与修复方案相同的思路，形成了一种自我循环的盲区。
假拒绝则主要源于代码误读（占44.3%）——审查者看错了代码逻辑，和非标准但正确的解法（占25.8%）——修复方案用了一种不寻常的方式解决了问题，审查者因为习惯了"标准路径"而误判为错误。
从难度分层来看，假通过率随着问题难度上升而急剧增加：在简单档为7.6%，中等档为8.2%，困难档为16.7%。这说明随着AI代码生成器变得更强，它们提交的方案更接近正确答案，其中包含的缺陷也更加隐蔽，更难被审查者发现。换句话说，未来审查者面临的挑战会越来越大。
在探索行为分析上，研究团队还发现了一个有趣规律：在决策正确的审查案例里，探索步骤往往更少；在决策错误的案例里，探索步骤反而更多。Opus在决策正确时平均用了23.2步，决策错误时用了28.1步，差异显著。这说明"探索步骤多"不是能力强的体现，而是不确定的信号。最快的四分之一审查（不超过17步）达到了90.8%的决策准确率，最慢的四分之一（超过28步）只有69.4%。这意味着步骤数量可以作为一个轻量级的信心指标——当审查者探索了很久还没下结论时，这本身就是一个警告信号。
从资源消耗来看，Claude Opus 4.6平均每次审查消耗148K词元，而训练好的SWE-Review-8B消耗2.36M词元——足足高出16倍，决策准确率却低10到13个百分点。这说明更小的模型在审查上还有很大的提升空间，它们目前采用的是"广撒网"式的探索策略，而Opus则更像是"精准定位"。
说到底，SWE-Review这项研究做的事情，是把人类软件工程实践里一个古老而有效的机制——代码审查——用AI的方式重新实现，并且证明了它在AI辅助开发的全链路中能发挥多大的价值。当AI代码生成器越来越普及，每天提交的修复方案越来越多，有一个能真正判断"这个方案修好了没有"的审查机制就变得至关重要。
这项研究还揭示了一件反直觉的事：审查能力和生成能力并不是两种截然不同的技能。让一个模型学会审查，竟然也能让它更好地生成代码；让一个模型扮演审查者，它反过来还能把自己当生成者写出的方案改得更好。两者背后共享的，是一种在代码仓库里追踪问题根源的推理能力。
这对于未来的AI编程工具意味着什么？意味着未来的AI助手可能不会只是"帮你写代码"，而是能在写完之后自我审查、自我诊断、自我改进，形成一个无需人类全程介入的质量保障循环。当然，研究也坦诚地指出了现阶段的局限：目前整个框架只聚焦于"修复软件漏洞"这类任务，没有涉及功能开发、重构、文档改善等更广泛的代码变更类型；评价指标也只关注功能性（修好了没有），不涉及代码风格、可读性、安全性等维度。这些都是后续值得深入探索的方向。
有兴趣深入了解这套框架技术细节的读者，可以通过arXiv编号2607.06065查阅完整论文，研究团队也承诺将公开发布基准测试集、审查轨迹数据和训练好的审查模型，以便更多研究者在此基础上继续探索。
Q&A
Q1：SWE-Review和普通代码审查工具有什么区别？
A：普通代码审查工具通常只是把修改内容交给模型一次性判断，就像只看试卷答案而不看题目背景。SWE-Review的审查者会主动在整个代码仓库里探索，追踪问题根源，运行测试验证，更像一位亲自调查的侦探，能识别出那些"表面看起来修好了但实际没修好"的方案。
Q2：SWE-Review-Traj这个训练数据集有什么用？
A：SWE-Review-Traj包含8914条完整的代码审查过程记录，用来训练小型开源模型学会做代码审查。用这些数据训练后，一个80亿参数的小模型的审查完成率从约4%提升至71%到84%，决策准确率提升了约20个百分点。同时，这些审查数据还能提升代码生成模型的性能，混合训练后软件问题解决率提升了最高5.6个百分点。
Q3：审查驱动迭代修改和"多试几次挑最好"有什么实质差异？
A：最核心的差异是有没有信息传递。"多试几次挑最好"每次都从零开始，前几次失败的教训对后续没有帮助。审查驱动迭代修改则在每次失败后由审查者给出具体诊断，代码工程师在原有基础上针对性改进。数据上，前者在最多尝试16次时解决率只有25.6%，后者最多尝试5次就达到38.4%，而且平均只用了2.44次，计算效率高出约6.5倍。