这项由南洋理工大学、华为技术有限公司和香港大学联开展的研究，以预印本形式于2026年7月7日发布，论文编号为arXiv:2607.06065，感兴趣的读者可通过该编号查阅完整论文。

软件开发的世界里，有个让所有程序员都头疼的问题：你费尽心力写了段代码来修复个软件漏洞，提交上去之后，却不知道它到底修好了没有。没有人帮你检查，没有人给你反馈，你就像把封信投进了邮筒，却永远不知道收件人有没有收到。

近年来，人工智能编程工具的进步让情况有了变化。AI已经能够扮演"代码工程师"的角，自动分析软件问题并提交修复案——也就是所谓的"拉取请求"（PullRequest，简称PR，可以理解为"修复建议稿"）。然而问题依然存在：AI提交完修复案之后，同样没有人帮它检查，这个案是真的解决了问题，还是只是"看起来解决了"？整个过程仍然是单向的、缺乏反馈的。

这就是这篇论文要解决的核心问题。研究团队提出了个叫做SWE-Review的框架，核心思路是：给AI写的修复案配个"审稿人"——另个AI，门负责检查那份修复案写得对不对，哪里有问题，应该怎么改。这样来，整个流程就从"写完就"变成了"写——审——改——再审"的闭环循环。

、为什么份AI写的修复案需要另个AI来审查

代码审查在软件工程里是个古老而重要的实践。人类团队里，名程序员写完代码之后，另名同事会仔细阅读并提出意见，这个过程叫做CodeReview（代码审查）。它能发现错误、提升质量、止问题代码进入正式版本。

然而，当AI开始大量提交修复案时，这个环节却严重滞后。现有的自动代码审查工具大多只会做件事：把修复案的"差异文件"（也就是显示哪里改了什么的记录）交给AI模型，让它次给出通过或拒的判断。这就好比请位考官评卷，但只给他看学生写了哪几行字，而不给他看整本教材、参考答案和出题背景——考官只能凭经验猜测对不对，很容易出错。

真正的问题在于，个看起来理的修复案，未解决了真正的根源问题。它可能只是消除了表面的报错，而根本的逻辑缺陷依然藏在代码处。判断这件事，需要审查者入挖掘整个代码仓库，追踪问题的来龙去脉，而不只是盯着那几行被修改的代码看。

这就是SWE-Review与以往审查工具根本的区别：它训练出的"审查者"（ReviewerAgent）不是静静坐在那里读份文件，而是主动在代码仓库里四处探索、追踪调用链、动手运行测试，像位亲身调查的侦探那样，在掌握了足够证据之后再做出判断。

二、侦探式审查：主动探索与静态阅读的差距到底有多大

研究团队门设计了个基准测试集——SWE-Review-Bench，来衡量这种"主动探索式审查"到底比"静态阅读式审查"强多少。这个测试集包含1384份由AI生成的修复案，来自500个真实软件问题陵水万能胶厂家，使用了三个能力参差不齐的AI代码生成器来产生这些案，形成了、中、低三种质量档次的样本分布。

评价个审查者好不好，研究团队使用了三把尺子。把叫"完成率"，衡量的是审查者能不能产出份格式正确、可以被解析的审查报告，就像看个侦探终有没有写出结案报告。二把叫"决策准确率"，衡量审查者判断"通过还是要求修改"这个二选的准确度，就像看侦探抓没抓到真凶。三把叫"修改后解决率"，这是实用的把尺子：审查者给出反馈之后，代码工程师照着反馈去改，改完之后问题解决了吗？这把尺子直接衡量了审查的实际价值。

论文里有个非常直观的案例——sympy-13877问题。这是个Python数学库里的漏洞：当你用某个法计个包含符号变量的矩阵的行列式时，会报出个"非法NaN比较"的错误（NaN是"不是个数字"的意思，出现在不应该出现的地就会引发崩溃）。个AI代码工程师提交了份修复案，在代码的某个下游位置加了个保护检查，止NaN值触发比较操作。表面上看，崩溃消失了，错误不报了。

然而，当研究团队的主动探索式审查者介入时，它没有直接看修复案。它先读懂了问题描述，然后顺着代码的调用链路追溯——矩阵行列式计流程从哪里进入、经过哪些函数、调用了哪些工具。它发现，真正的问题其实在另个文件`matrices.py`里：行代码本该写成`ret=cancel(ret)`，但实际上只写了`cancel(ret)`，返回的结果被直接丢弃了，未被简化的表达式因此被错误地当成非值参与了后续计，进而致系列连锁错误。那个候选修复案只是在下游堵住了崩溃，但错误结果（行列式返回NaN而非正确数值）依然存在。

主动探索式审查者发现了这点，要求修改，并指出了真正的修复位置。静态阅读式审查者则因为没有追溯上游，只看到了修复案"止了崩溃"，就批准通过了。后者的结论——这个修复"安全、有针对且不引入回归问题"——在逻辑上看似理，实际上却是错的。

在量化比较上，使用ClaudeOpus4.6作为统的审查模型，主动探索式审查在三个不同质量档次的修复案上胜出。以决策准确率为例，在由弱AI生成的修复案上，主动探索式审查达到89.4，而静态阅读加上额外文件上下文的式只有80.8，仅看差异文件的式只有72.0。这差距在难度的案例上加明显——研究团队按照修复案与标准答案的差异程度和需要验证的行为范围，将测试集分成了简单、中等、困难三档，发现主动探索式审查在困难档案例上的决策准确率先幅度大。

这个结论背后有个清晰的道理：当个问题的答案不在那几行被修改的代码里，而是藏在整个代码仓库的某个角落时，只盯着差异文件看是不够的，须主动去找。

三、让小模型也能做好审查：从轨迹数据中学习侦探技能

主动探索式审查之所以强，是因为它能够动态收集证据。但这种式依赖于强大的模型（如ClaudeOpus4.6），成本很，也法直接让普通研究者复现或使用。那么，能不能把这种能力"教给"小、轻量的模型？

研究团队的回答是肯定的，而且他们为此构建了个门的训练数据集——SWE-Review-Traj，包含8914条质量的审查轨迹。所谓"审查轨迹"，就是个完整的审查过程记录：审查者在代码仓库里走了哪些步骤、看了哪些文件、运行了哪些测试、得出了什么结论、给出了什么诊断建议。这就好比把位经验丰富的侦探破案的全过程详细录下来，然后用这些录像来培训新侦探。

这些训练数据来自SWE-rebench这个大规模真实软件问题集。研究团队先用三个AI代码生成器产生候选修复案，再用能力较强的开源模型GLM-5（带有"思考模式"）作为老师模型来对每份案做审查，记录下完整的探索过程。原始产生了14156条轨迹，经过筛选——只保留决策结论正确的（即正确通过了真正有的案，或正确拒了案的轨迹）——终留下8914条作为训练数据。

为了验证训练数据的质量，研究团队从两个维度进行了检验。语义层面，他们让ClaudeOpus4.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，PVC管道管件粘结胶混加入等量审查数据后提升到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-GuidedIterativeRevision）则是另种策略：每次修复案被拒，审查者都会给出具体的诊断和修改建议，代码工程师在原有案基础上针对地改进，而不是倒重来。这就像老师改卷之后给出详细批注，学生照着批注修改，而非重新做遍。

研究团队将这种策略与另外两种法进行了量化比较陵水万能胶厂家，都使用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倍的能提升。

六、入解剖：审查者在哪里会犯错，以及为什么

研究团队没有止步于展示好结果，还详细分析了审查者的错误模式——这部分内容对于理解整个系统的局限非常重要。

通过分析ClaudeOpus4.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。这意味着步骤数量可以作为个轻量的信心指标——当审查者探索了很久还没下结论时，这本身就是个警告信号。

从资源消耗来看，ClaudeOpus4.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倍。相关词条:离心玻璃棉     塑料挤出机     钢绞线厂家    铝皮保温    pvc管道管件胶

奥力斯    万能胶生产厂家    联系人：王经理    手机：13903175735（微信同号）    地址：河北省任丘市北辛庄乡南代河工业区

1.本网站以及本平台支持关于《新广告法》实施的“极限词“用语属“违词”的规定，并在网站的各个栏目、产品主图、详情页等描述中规避“违禁词”。
2.本店欢迎所有用户指出有“违禁词”“广告法”出现的地方，并积极配合修改。
3.凡用户访问本网页，均表示默认详情页的描述，不支持任何以极限化“违禁词”“广告法”为借口理由投诉违反《新广告法》，以此来变相勒索商家索要赔偿的违法恶意行为。