上交大等研究：AI写代码前先问明白，修复成功率提升4.4个百分点
来源：互联网 2026-07-31 17:10:07上海交通大学等联合研究提出ACQUIRE框架，让AI在修复代码前先通过提问获取代码库知识，再动手修复。在500个真实GitHub问题测试中，修复成功率提升最多4.4个百分点，时间和成本保持合理。
先来看一组研究数据。2026年7月，上海交通大学、匹兹堡大学与广东以色列理工学院联合发布了一项预印本研究（arXiv编号：2607.11111），核心议题是：如何让AI系统更靠谱地自动修复代码。这门手艺活儿，说白了就是在一大堆相互缠绕的代码中找到那根出问题的线，然后精准地修好它，还不能碰断旁边好好的线。
可现实是，AI在这件事上的表现，远比表面看起来要糟糕。研究团队观察到一个令人头疼的现象：这些AI系统，即便拥有堪称顶级的推理能力，依然会在修代码时频繁犯错。问题的根源，不是它们不够聪明，而是它们对要修的那个代码库，根本不够了解。
免费动漫立即观看： >>>点此进入<<<
打个比方，你能想象一个外科医生在完全不了解病人身体状况的情况下，直接开刀吗？现有的AI修复系统，做的事情基本就是如此：拿到一份“病情描述”（也就是bug报告），然后就在代码里翻找、下刀。结果可想而知，要么找错了地方，要么修了表面、留着病根，甚至越修越乱。
这篇论文提出的新框架叫ACQUIRE（全称Agent Collaboration for Question-Answer-driven Issue REsolution，可以理解为“通过问答驱动的智能体协作来解决代码问题”）。它的核心逻辑只有一句话：先搞清楚，再动手。在真正开始修代码之前，系统会主动向代码库“提问”，把不懂的东西弄清楚，然后再拿着这些知识去修复问题。实验结果显示，在一个包含500个真实GitHub问题的标准测试集上，这套方法将AI的修复成功率提升了最多4.4个百分点，同时花费的时间和金钱代价依然保持在合理范围内。
一、为什么AI修代码总是“看不懂地图就出发”
要理解这项研究解决的是什么问题，先得明白现有AI修代码系统的通病是什么。
当一个开发者在GitHub上提交了一个bug报告，比如“程序在处理带括号的参数类型时会崩溃”，AI系统拿到的就是这样一段文字描述，加上整个代码库。代码库可能有数万个文件、数十个模块，里面充斥着各种相互调用、相互依赖的函数和类。AI需要从这片丛林里找到出问题的那棵树，再精准地修剪它。
问题在于，光凭bug描述里的几个关键词，AI往往只会做“关键词匹配”——哪个文件名、函数名和描述里的词最像，就去改哪里。这就好比，你告诉一个刚来的维修工“家里水管漏水了”，他不去检查管道走向、不了解房子的结构，直接根据你说的“漏水”两个字去找所有和水有关的东西，结果把好好的热水器给拆了，真正漏水的地方却没碰到。
研究团队从多项实证研究中总结出，AI修代码失败的最主要原因包括这样几类：停留在表面的关键词定位，找不到真正出错的源头；跨模块追踪失败，搞不清楚一个错误是怎么从A传导到B再传导到C的；违反隐含的接口约定，不知道某个函数有特定的调用规则；以及缺乏对外部库或协议规范的了解。更糟糕的是，那些失败的修复尝试消耗的计算资源是成功修复的四倍以上、执行步骤是成功修复的将近两倍。这意味着，越是搞不清楚状况的AI，越会在错误的路上越走越远、成本越烧越高。
已有一些研究尝试在修复之前先做一些“探索”。比如，有的系统会先构建代码库的结构图，标记出哪些地方可能有问题；有的会生成一份摘要，告诉AI大概在哪里找。但这些方法本质上依然是“修复导向”的探索——它们输出的是“可能出问题的地点列表”，而不是“你真正需要理解的知识”。把一张地图交给一个不知道目的地在哪里的人，并不能帮他找到路。
二、灵感来自经验丰富的程序员的工作方式
研究团队的灵感来自一个朴素的观察：有经验的开发者在面对一个陌生代码库里的bug时，并不会立刻开始翻代码找位置。他们会先问问题。“这个函数究竟是怎么工作的？”“这个API的调用有什么约束？”“这个模块和那个模块之间是怎么传数据的？”把这些问题搞清楚之后，他们才会动手修复。这种先理解、后行动的模式，在软件工程的调试研究中早有记录——有经验的程序员投入更多时间在程序理解上，结果反而修得更快、更准。
受此启发，研究团队设计了一个验证实验，想看看“提前把关键问题问清楚”到底能带来多大帮助。他们构造了一个“理想条件”场景：给AI一个bug报告，同时偷偷告诉它正确答案在哪些文件里，并且为它生成一个和这个bug最相关的问题以及基于正确文件的准确答案。然后把这对问答注入到AI修复系统里，看看成功率会怎么变。
结果相当鼓舞人心。在原本失败的116个案例中，有26个因为获得了这组“提前知道答案的问答”而成功修复。这意味着，大约22%的失败案例，其实不是因为AI推理能力不够，而是因为它缺少了某些关键知识。更值得注意的是，这个实验条件还相当保守——只提供了一个问题，而且答案只基于正确文件，而不是整个代码库。真实系统能挖掘的信息远不止于此。
这个实验确立了一个核心信念：如果能在修复之前为AI提供精准的、有根据的代码库知识，就能显著提升修复成功率。接下来的问题是，在没有“提前知道正确答案”这种作弊条件的情况下，怎么自动生成这样的知识？
三、ACQUIRE的工作方式：三个角色、两个阶段
ACQUIRE的设计围绕三个专门的AI角色展开，它们分别承担不同的职责，通过两个阶段的协作完成整个修复任务。
第一个角色叫做“提问者”（Questioner）。它的工作是拿到bug报告之后，不急着找代码，而是先生成几个有针对性的问题。这些问题不是随意发问，而是按照一套经过仔细设计的分类框架来提的。研究团队在分析了大量真实失败案例之后，归纳出四类最常见的知识缺口，也就是AI最容易因为不了解而修错的知识类型。
第一类是“机制与行为”，占了所有问题的约70%。这类问题关注的是“某个功能到底是怎么运作的”——比如数据在函数之间是怎么流转的，某个状态是在哪里被更新的，某种异常是在哪个环节被触发的。第二类是“设计与用法”，占约18%，关注的是“某个接口或API有什么使用约定”——哪些参数是必须的，调用顺序有没有要求，出错时会抛出什么类型的异常。第三类是“定位与结构”，占约8%，关注的是“某个功能在代码库的什么地方实现”——这类问题直接帮助AI缩小搜索范围。第四类是“生态与标准”，占约3%，关注的是代码库依赖的外部知识——比如某个第三方库的行为规范，或者某种协议的技术标准。
提问者会根据当前bug的具体内容，从这四类框架中挑选最合适的角度生成问题，而不是机械地每类出一题。某些bug可能需要两个都是“机制与行为”类的问题，某些则需要跨类别组合。默认设置下，每个bug生成两个问题。
第二个角色叫做“回答者”（Answerer）。每生成一个问题，就会启动一个独立的回答者实例来处理它。回答者的工作方式和一个有经验的开发者查阅代码库非常相似：它可以浏览目录结构、打开文件、搜索关键词、查看函数定义——但它只能读，不能改，整个代码库在这个阶段保持原样。
回答者有三条严格的行为准则。首先，答案必须有依据，必须引用具体的文件路径、函数名、代码行为，而不能凭空猜测。其次，一旦收集到足够的证据就要主动提交答案，不要无限漫游。第三，如果实在找不到充分的证据，必须明确说“找不到”，而不是编造一个听起来合理的答案。多个回答者实例并行工作，互相不共享探索过程，这样既保证了每个答案的独立性和专注度，也大幅压缩了等待时间——整个提问回答阶段的耗时取决于最慢的那个实例，而不是所有实例的时间之和。
第三个角色叫做“修复者”（Resolver）。它拿到的不只是原始的bug报告，还有前两个角色生成的完整问答知识集合。这些问答内容在修复开始之前就已经被整合进修复者的上下文，让它在第一步操作之前就已经掌握了关键的代码库背景知识。
有一点设计细节值得特别说明：这些问答知识是作为“参考信息”提供给修复者的，而不是强制指令。修复者可以根据自己在探索过程中观察到的实际代码，来验证、调整甚至推翻问答中的某些说法。这种“建议而非命令”的注入方式，保证了系统的鲁棒性——即使某个答案有小的偏差，修复者依然有机会通过直接查看代码来纠正。
四、实验怎么做的，结果怎么样
研究团队选用了SWE-bench Verified作为测试平台。这是一个由500个真实GitHub问题组成的测试集，每个问题对应一个真实的代码库，修复结果的好坏用开发者事先写好的单元测试来判定——通过了测试才算真正修好了。这种评测方式非常严格，无法靠“看起来像修好了”来蒙混过关。
为了验证ACQUIRE的效果不依赖于特定的AI模型，研究团队选用了两个来自不同技术路线的大语言模型。一个是DeepSeek-V3.2，这是一个开源的“混合专家”架构模型，参数量达到6710亿，每次推理时激活约370亿参数，在代码理解和生成任务上表现出色。另一个是GPT-5-mini，来自OpenAI，是一个面向高效部署优化的闭源模型，速度快、成本低。
对比的基准方法涵盖了当前主流的“修复前探索”策略。Mini-SWE-Agent是一个最基础的修复系统，不做任何预处理，直接迭代地执行shell命令来找bug和改代码。LocAgent通过构建代码库的异构图（包含导入关系、调用关系、继承关系），用AI引导的多跳遍历来生成“可疑位置列表”。CoSIL通过逐步扩展本地调用图来精炼搜索范围，输出紧凑的高相关性代码片段。LingmaAgent构建代码库级别的知识图，结合蒙特卡洛树搜索来引导探索，生成修复导向的仓库摘要。SWE-Debate则引入多智能体辩论机制，让多个AI独立提出修复假设，互相质疑，最终达成共识。
结果显示，ACQUIRE在两个模型上都取得了所有方法中最高的修复成功率：在GPT-5-mini上提升了3.8个百分点（从58.4%到62.2%），在DeepSeek-V3.2上提升了4.4个百分点（从66.4%到70.8%）。更关键的是，ACQUIRE的成本和时间开销都相当合理——每个实例的平均花费在两个模型上分别是0.054美元和0.073美元，平均耗时分别是302秒和1042秒。相比之下，LingmaAgent的成本是ACQUIRE的2到4倍，SWE-Debate的成本是ACQUIRE的7到14倍，而它们的修复成功率提升远不及ACQUIRE。
那些定位导向的方法（LocAgent和CoSIL）在GPT-5-mini上不仅没有提升，反而出现了下降，这揭示了一个深层问题：把一张“可疑位置清单”交给推理能力有限的模型，不但帮不上忙，还可能误导它走向错误的路径。ACQUIRE的问答知识则不同，它传递的是“为什么这个地方值得关注、它的行为逻辑是什么”，而不只是“去那里看看”。
五、生成的知识到底有多可靠
一套系统的知识获取机制再精妙，如果产生的知识本身错漏百出，那注入再多也只会帮倒忙。为此，研究团队对生成的问答质量做了严格的人工审核。
四位计算机科学专业的硕士研究生（各有四年开发经验）对232对问答进行了独立双盲评审，分歧通过讨论解决。这232对问答来自四个不同的结果分组：原本失败、有了ACQUIRE变成功的44个案例；原本成功、有了ACQUIRE反而失败的22个案例；以及从另外两个分组（一直失败、一直成功）中各随机抽取的25个案例。
评审结果显示，232对问答中有230对（99.1%）被标记为“有依据”——其中98对（42.2%）完全准确，所有说法都能在代码库中找到明确支撑；另外132对（56.9%）存在轻微偏差，比如行号不精确、函数归属稍有错误，但核心结论不受影响。只有2对（0.9%）包含了真正无依据的核心声明，被判定为“有误导性的无根据断言”。
这种高可靠性并非偶然。ACQUIRE的问答设计有一个内在的优势：把一个复杂的bug报告拆解成几个范围明确的小问题，每个回答者只需要聚焦在一个具体问题上，搜索和推理的范围大幅缩小，犯错的机会自然也少得多。这就像一个人被问“请介绍一下中国近代史”会说很多错的，但被问“1919年五四运动发生在哪个城市”几乎不会答错。
研究团队还仔细分析了那22个“原本成功、引入ACQUIRE后反而失败”的案例。其中只有5个是真正由于问答内容的误导造成的——比如问答强调了一个相关但并非关键的位置，修复者就一直在那里打转，偏离了正确修复路径。有趣的是，这5个案例里的10对问答中，只有1对被判定为无根据的错误声明，其余9对在内容上是正确的，只是提供了“正确但不是关键”的信息，误导了修复者的注意力方向。
剩余17个失败案例则与问答质量关系不大，主要是修复者自身的行为问题：把一个正确的线索过度泛化、只实现了修复的一部分、引入了额外的不必要改动等等。这说明，改进修复者对问答知识的“批判性使用能力”，是未来进一步提升系统表现的重要方向。
六、是什么让系统真正有效：两个设计选择的验证
为了确认ACQUIRE的性能提升究竟来自哪里，研究团队构造了两个“削减版”变体进行对比实验。
第一个变体叫做ACQUIRE-Proposal，把提问者和回答者的整个问答流程替换成一个单步“提案生成”：系统读取bug报告，直接生成一份包含根因分析和修复建议的提案，然后把这份提案注入修复者。这个变体的成绩跌到了66.0%，比完整的ACQUIRE（70.8%）低了4.8个百分点，甚至比什么都不做的基础系统（66.4%）还要低。
这个结果揭示了一个重要道理：让AI一次性完成“读懂bug、分析原因、给出建议”这三件事，会产生一种“什么都沾点儿、什么都不深入”的分析，既不够聚焦，又容易自相纠缠。相反，把这个复杂任务拆解成若干个范围明确的小问题，每次只让AI回答一个具体问题，不仅答案更准确，对修复者的帮助也更直接。这就像让一个助手帮你准备一场演讲，“帮我把这场演讲准备好”这个指令下去，出来的东西往往不对路；但“帮我找三个关于气候变化的具体数据”这样的分解指令，往往更容易得到有用的结果。
第二个变体叫做ACQUIRE-FreeQ，保留了完整的问答流程，但去掉了提问者用来指导生成的四类框架。提问者可以自由地提任何它觉得相关的问题，没有任何分类约束。这个变体的成绩是67.0%，比完整版低了3.8个百分点。
为了弄清楚为什么加了分类框架的问题更好，研究团队用AI评审系统对两组问题进行了多维度打分。结果显示，有分类框架指导的问题在“诊断实用性”（即答案对于缩小debug范围的帮助程度）上高出0.38分，在“推理深度”（即需要多少跨文件、跨模块的分析）上高出0.38分，在“覆盖度”（即一组问题覆盖了多少不同的诊断角度）上高出0.78分。自由生成的问题最大的问题是“同质化”——两个问题往往从相似的角度切入，浪费了宝贵的提问机会。分类框架的作用就像一个提醒，确保提问者从多个不同维度去审视同一个问题，而不是把两个问题都用在同一件事上。
在500个实例的两两对比投票中，有分类框架的ACQUIRE在294次中被评为更优，ACQUIRE-FreeQ只有111次，另有95次平局。不失率达到77.8%。
七、问多少个问题最合适
ACQUIRE默认生成两个问答对，但研究团队也系统地测试了不同数量的效果。
生成零个问答的时候，系统退化为纯粹的基础修复系统，成功率是66.4%，每个实例花费0.055美元。加入一个问答对之后，成功率立刻跳升到69.0%，而额外花费仅有0.005美元。这意味着，哪怕只给AI补充一条有根据的知识，也能带来实质性的改善。
两个问答对的时候，成功率达到了峰值70.8%，每个实例花费0.073美元。这是整个测试范围内效果最好的配置，也是研究团队采用的默认设置。到了三个问答对，成功率回落到69.0%，而花费继续上升到0.082美元。这种“先升后降”的曲线背后有两个原因：两个来自不同类别的问题能够有效覆盖互补的知识缺口；而第三个问题往往和前两个有知识重叠，注入更多内容反而会稀释修复者的注意力，让它在已知信息和新信息之间来回权衡，造成认知上的负担。
这个发现和语言模型处理长文本的一般规律吻合——上下文过长时，模型对关键信息的响应能力会下降，甚至“迷失在信息的中间”。两个精准的问答对，恰好在信息丰富度和认知负荷之间取得了最佳平衡。
八、一个具体案例：58步找到一个关键字母也没提到的文件
研究团队挑选了一个具体的真实案例来展示ACQUIRE和普通修复系统的差距。这个问题来自Python文档生成工具Sphinx：当开发者用 `:param dict(str, str) opc_meta:` 这样的格式描述一个参数时，Sphinx会把类型“dict(str, str)”解析成“dict(str”，把参数名解析成“str) opc_meta”——也就是说，碰到括号里的逗号和空格就断掉了。
普通修复系统拿到这个报告，看到的关键词是“渲染错误”，就去找和渲染、输出相关的代码。它先去改了typehints.py，发现不对；再去改writers/html.py，还是不对；然后又跑到autodoc/__init__.py里试图打一个补丁，依然失败；最后做了回滚。整个过程走了117步，从未碰到真正出问题的文件。这就像一个人因为“灯泡不亮了”去换整个电路板，却完全没有检查过灯泡本身。
ACQUIRE的提问者生成了一个问题，大意是：“这个代码库里的文档字符串解析器目前是怎么从`:param`指令中提取类型信息的，尤其是当类型里面有嵌套括号时？”
这个问题的角度完全不同——它不是从“渲染”入手，而是从“解析机制”入手。回答者按照这个方向探索，先查看了autodoc/和napoleon/这两个看起来最相关的模块，没找到实际的解析逻辑；然后扩大搜索范围，进入了sphinx/util/目录，在那里发现了docfields.py文件，里面的TypedField类里有一行代码：`parts = fieldarg.split(None, 1)`——这行代码用的是按空格分割，碰到“dict(str, str) opc_meta”时，第一个空格在括号里面，所以分割出了“dict(str,”和“str) opc_meta”，把类型名切错了。回答者的答案精确地给出了文件路径、类名、行号和根本原因。
修复者拿到这个答案，直接打开docfields.py，确认了那行有问题的split调用，然后实现了一个能识别括号嵌套的分割函数来替代它。整个修复过程只用了52步，比基础系统的117步减少了55%。
这个案例体现了ACQUIRE最本质的优势：通过把问题转化成对“底层机制”的追问，而不是对“表面症状”的搜索，系统能够抵达那些与bug报告在字面上没有任何关联的正确位置。
说到底，这项研究做的事情其实很朴实——它只是把人类程序员面对陌生代码库时的本能反应，系统化地赋予了AI：先问，再修。这不是什么革命性的碘伏，而是一种对现有AI修复流程的有效补充。通过把一个完整的bug理解任务拆解成若干个小问题，并让AI在真实代码库里寻找有根据的答案，整个修复过程变得更有方向感、更少走弯路。
从实际效果来看，4.4个百分点的提升在这个领域并不是一个可以随意忽略的数字。当前最先进系统的成功率已经在七成左右，每提高一个百分点都需要付出相当的努力。ACQUIRE以相对轻量的代价实现了这样的提升，且在两种不同架构的模型上都保持了一致性，说明它补充的是一种普遍存在的能力缺口，而非针对某个模型的特殊优化。
当然，这套方法也有它的局限。目前的提示设计和测试主要针对Python代码库，是否同样适用于其他编程语言还有待验证。四个问题类别的框架也是基于对过往失败案例的人工分析归纳出来的，未来或许可以通过更大规模的数据自动学习出更精细的分类体系。此外，现在的问答知识是在修复开始前一次性生成的，不会随着修复进程的推进而动态更新——如果AI在修复过程中产生了新的疑惑，它没有办法再回头追问。如何在修复过程中实时获取知识、同时控制好额外的成本，是这个方向上一个值得探索的开放问题。
对于普通用户来说，这项研究的意义在于：未来你在GitHub上提交的bug，或者你请AI帮你修的代码错误，有更大的概率能被一次修对、修全、修得不留后遗症。而背后的原因，只是一个简单的习惯的改变——先弄清楚，再动手。
有兴趣深入研究这套框架的读者，可以通过arXiv编号2607.11111查阅完整论文，相关代码和数据也已公开发布。
Q&A
Q1：ACQUIRE框架在修复代码前具体会问什么类型的问题？
A：ACQUIRE的提问者会从四类框架中生成问题：第一类是“机制与行为”，约占70%，问的是某个功能内部如何运作；第二类是“设计与用法”，约占18%，问的是API接口有哪些调用约束；第三类是“定位与结构”，约占8%，问的是某个功能在代码库哪里实现；第四类是“生态与标准”，约占3%，问的是依赖的外部库或协议规范。系统默认每个bug生成两个问题，从不同角度覆盖知识缺口。
Q2：ACQUIRE生成的问答知识准确率有多高？
A：研究团队对232对问答进行了人工双盲评审，结果显示99.1%的问答被标记为“有依据”，其中42.2%完全准确，56.9%存在轻微偏差（如行号不精确）但核心结论正确，只有0.9%即2对包含了真正无依据的核心断言。高准确率来自于问题拆解设计——每次只问一个小问题，让回答者的任务范围大幅缩小，减少了出错机会。
Q3：SWE-bench Verified测试集是怎么评判代码修复是否成功的？
A：SWE-bench Verified包含500个来自真实GitHub仓库的代码问题，每个问题配有开发者预先编写的单元测试。AI生成修复补丁后，系统会自动运行这些单元测试，只有测试全部通过才算修复成功，计入Pass@1指标。这种评测方式无法靠“看起来修对了”蒙混过关，必须真正解决了bug才能得分。
侠游戏发布此文仅为了传递信息，不代表侠游戏网站认同其观点或证实其描述
同类更新
更多
热游推荐
更多-
- DreamStudio
- Android/ | AI绘图
- 2026-06-30
-
-
- Playground AI
- Android/ | AI绘图
- 2026-06-30
-
- Adobe Firefly
- Android/ | AI绘图
- 2026-06-30
-
-
-
- Leonardo AI
- Android/ | AI绘图
- 2026-06-30
-
- Stable Diffusion
- Android/ | AI绘图
- 2026-06-30
