核心发现
方法论
AutoCodeRover把软件项目视为程序结构而非文件集合：先由LLM从问题描述中抽取候选关键词，再通过基于AST的检索API进行迭代式上下文搜索，包括search_class、search_method_in_class、search_code_in_file等，逐步定位相关类、方法和代码片段。若项目含测试集，则引入基于测试的谱系故障定位（SBFL）为方法赋予可疑度，进一步缩小范围。最后，另一个LLM代理依据已收集上下文与bug位置生成补丁，并用测试验证、失败则重试。
关键结果
- 在SWE-bench-lite的300个真实GitHub issue上，AutoCodeRover达到19%的解决率（pass@1），即约57个问题被自动修复；论文强调这一效率高于近期报告的SWE-agent。
- 这些已解决问题平均每个约4分钟完成，而人工开发者修复同类问题平均耗时2.68天，说明该系统在实际开发节奏中具有可用性。
- AutoCodeRover的平均单次成本仅$0.43 USD；作者还报告其生成补丁中约2/3是正确且可接受的，这一点在Devin与SWE-agent相关讨论中并未充分给出。
研究意义
这项工作把LLM从“会写代码”推进到“会做软件维护”。其意义不只在于自动补全或片段生成，而是让模型面对真实仓库、真实issue、真实测试和真实补丁流程。对于学术界，它提供了一个软件工程导向的代理框架；对于工业界，它提示大模型可以先通过结构化检索理解根因，再用测试闭环验证修复，从而缓解人工排障与代码维护的长期成本。
技术贡献
技术上，AutoCodeRover的关键贡献是把“代码搜索”作为LLM推理的中枢，而不是把仓库当作静态文本。它在AST层面搜索类/方法，支持多轮检索和上下文累积；它把issue文本、项目结构、局部方法实现与SBFL结果组合起来，形成更接近人类工程师的诊断流程。相比很多APR工作默认已知bug位置，AutoCodeRover要先找位置，再修复，这更接近真实软件维护。
新颖性
新颖性在于：它不是单纯的LLM补丁生成器，而是一个面向程序改进的端到端系统。与把代码库视为文件堆的通用agent不同，它显式利用AST、类/方法级检索和测试驱动的故障定位来“找根因”。论文还用Django-13933示例展示了迭代搜索如何从ModelChoiceField扩展到ModelMultipleChoiceField，再定位to_python，体现了结构化检索的独特价值。
局限性
- 该方法仍依赖LLM能正确抽取关键词并逐步收敛到目标位置；若issue描述模糊、命名不一致或上下文分散，检索链可能偏航，导致找不到真正的bug位置。
- SBFL只在存在可用测试集时才能发挥作用，因此对测试稀缺或测试覆盖不足的项目帮助有限；同时，4分钟左右的平均耗时适合基准任务，但在更大仓库或更复杂变更下仍可能上升。
- 论文主要在SWE-bench-lite的300个Python项目上评估，跨语言、跨框架以及大规模多模块系统上的泛化能力仍未充分验证。
未来方向
作者把这项工作视为“自主软件工程”的起点。未来可结合更强的结构化检索、自动调试、增量测试与多轮补丁评审，进一步提高正确率与稳定性；也可扩展到更多语言、更多仓库规模，并研究如何让LLM生成的代码先自动诊断、再自动改进，形成闭环式自治开发流水线。
AI 总览摘要
AutoCodeRover试图回答一个现实而尖锐的问题：大模型已经能写代码，但能否真正接手软件维护？论文给出的答案不是“直接生成补丁”，而是把修复问题的全过程拆成“先找对位置，再写对修改”。与把仓库当作一堆文件的通用LLM代理不同，AutoCodeRover把项目视为由类、方法和抽象语法树（AST）组织起来的程序结构，用结构化搜索去逼近问题根因。
系统流程分两段。第一段是上下文检索：LLM先从issue标题和描述中提取关键词，再调用search_class、search_method_in_class、search_code_in_file等本地AST检索API，多轮迭代地扩展上下文；若存在测试集，还会结合谱系故障定位（SBFL）给方法打可疑度分数，优先查看高可疑位置。第二段是补丁生成：另一个LLM代理基于已收集上下文、候选bug位置和错误信息生成补丁，并用测试验证，失败则重试。
Django-13933是一个很典型的例子：issue要求ModelChoiceField在抛出验证错误时显示无效值。AutoCodeRover先定位到ModelChoiceField与ModelMultipleChoiceField，再沿着to_python与validate追踪，最终找到django/forms/models.py中的目标行，并生成能把value嵌入错误信息的补丁。作者强调，这种流程更像资深开发者的排查方式：不是盲写代码，而是先问“根因在哪里、相关逻辑在哪里、测试能否证明修复”。
在SWE-bench-lite上，AutoCodeRover评估了300个真实GitHub issue，解决率达到19%，即约57个问题；平均每题约4分钟，远低于人工修复平均2.68天。论文还报告平均成本仅$0.43美元，且约2/3的已产出补丁被认为正确且可接受。整体上，这项工作把LLM从“代码生成器”推进为“软件改进代理”，为未来自动化维护、自动修复和半自治开发提供了清晰路线图。
深度分析
研究背景
软件工程长期追求自动化：从测试生成、故障定位到程序修复，研究者一直想把重复、耗时的维护工作交给机器。近年LLM与Copilot类工具显著提升了代码生成能力，但“会写”不等于“会修”。真实项目中的bug修复与功能添加往往需要读issue、找根因、定位跨文件依赖，并结合测试判断修改是否有效。SWE-bench-lite把这一难题标准化为300个真实GitHub issue，覆盖11个Python项目，如Django、SymPy等，成为评估端到端软件修复能力的重要基准。
核心问题
核心问题不是生成一段代码，而是在没有人工标注bug位置的情况下，仅凭自然语言issue和仓库代码，自动找出受影响的类、方法与文件，并产出可通过测试的补丁。这比HumanEval或MBPP一类单文件代码题难得多，因为它要求理解项目结构、跨文件语义、错误信息与测试约束。论文认为，现有很多APR和LLM agent方法要么默认已知bug位置，要么把仓库当作文件集合，因而难以应对真实维护任务。
核心创新
AutoCodeRover的创新点有三层。第一，它以AST为核心表示，把“搜索代码”提升为搜索类、方法与代码片段，而非文件名匹配。第二，它采用迭代式上下文检索：LLM根据当前返回结果继续发起新搜索，使上下文逐步收敛到根因。第三，它把SBFL纳入检索决策，在有测试时用失败/通过信息为方法排序，从而更像调试而非纯生成。与多数APR研究不同，它先解决定位，再解决修复。
方法详解
- �� 输入：GitHub issue的标题与描述 + 本地代码仓库 + 可选测试集。
- �� 第一步，关键词抽取：LLM从自然语言问题中识别可能对应类名、方法名、异常信息或代码片段的词，如Django例中的ModelChoiceField。
- �� 第二步，结构化检索：调用search_class、search_method_in_class、search_code_in_file等API在AST上定位候选对象，获取签名、方法实现和局部上下文。
- �� 第三步，迭代收敛：LLM根据上一轮检索结果决定下一轮搜索什么，例如从class到method，从方法签名到具体实现。
- �� 第四步，故障定位增强：若有测试，使用SBFL为方法赋可疑度，优先检索与issue关键词和高可疑方法都相关的区域。
- �� 第五步，补丁生成：另一个LLM代理在给定bug位置与上下文后生成修改，典型做法是修改异常消息、条件判断或参数传递。
- �� 第六步，验证与重试：利用测试套件检查补丁是否可应用、是否通过；失败则在重试预算内继续生成。
实验设计
实验基准为SWE-bench-lite，共300个真实GitHub issue，覆盖11个热门Python项目。任务类型包括bug修复与功能添加。论文重点比较AutoCodeRover与近期LLM代理方法，尤其提到SWE-agent，并讨论Devin这类系统的背景。评估指标主要是解决率（efficacy/pass@1）、平均耗时与平均成本，此外还分析补丁可接受性。论文还通过Django-13933给出定性案例，展示检索到补丁生成的完整链路。
结果分析
最重要的数字是：AutoCodeRover在SWE-bench-lite上达到19%解决率，约57/300个issue被修复，且平均每个问题约4分钟完成。作者指出这一结果高于近期报告的SWE-agent。第二个关键结果是成本：平均每次任务仅$0.43 USD，说明结构化检索可以显著降低LLM调用和无效搜索开销。第三个结果是质量：约2/3的自动生成补丁被认为正确且可接受，表明并非只有“能过测”这一维度，而是具备较强工程可用性。
应用场景
最直接的应用场景是开源项目维护：自动读issue、定位问题、提交候选补丁，再由人类审查。其次是企业内部代码库的缺陷修复与功能增量，尤其适合有测试套件、仓库结构清晰、issue文本质量较高的项目。对平台方而言，它也可作为代码助手的“修复层”，把LLM生成代码后的可信性再提升一步。
局限与展望
AutoCodeRover仍建立在几个现实假设上：issue描述要足够信息化，仓库代码需可本地解析为AST，且测试集最好可用。若项目缺少测试，SBFL无法发挥作用；若命名混乱、依赖链长或问题跨多个模块，迭代检索可能难以完全收敛。论文当前主要验证Python开源项目，未来需要在跨语言、超大仓库和更复杂变更上进一步检验鲁棒性。
通俗解读 非专业人士也能看懂
可以把AutoCodeRover想成一个非常聪明的维修队。你给它一张报修单——“这个按钮坏了”“这个功能缺一块”——它不会直接乱拆机器，而是先问：这件事最可能和哪些零件有关？然后它拿着放大镜，在机器的结构图里一层层找，先看总组件，再看小组件，再看具体螺丝。这个过程不是瞎猜，而是边看边缩小范围。
如果机器旁边还有“故障记录本”，AutoCodeRover会一起翻看：哪些地方经常出问题，哪些零件最可疑。这样它就更容易先去正确的位置。等它终于找到真正有问题的零件后，才开始动手修。修完以后，它还会拿测试清单一项项检查，确认这次修理没有把别的地方弄坏。
这篇论文最重要的想法是：修东西之前，先把“这东西到底坏在哪里”找准。它不是只会写修补材料的工人，而更像会看图纸、会查记录、会做检查的老维修师傅。所以它能更像人类工程师那样工作，也更接近真实的软件维护。
简单解释 像给14岁少年讲一样
想象你在玩一个大型游戏，突然出现了一个奇怪的bug：某个道具点了没反应，或者升级按钮报错。你当然不想把整个游戏重装一遍，对吧？你更希望有人先去查：是哪个菜单有问题、哪个功能连错了、还是某个小开关坏了。AutoCodeRover做的事情就有点像这个“超级排查员”。
它先读玩家发来的报错说明，从里面抓出线索，比如“这个道具”“那个按钮”“报错信息”。然后它不是随便翻文件，而是沿着游戏的“零件图”去找：先找大模块，再找里面的小功能，再看具体代码。找的时候，如果它手里还有“测试记录”，就会知道哪些地方最可疑，像侦探先盯最像嫌疑人的人。
找到问题后，它再写修复方案，改完还会自己做检查，看看是不是修好了、有没有把别的地方弄坏。论文里最厉害的数据是：它在300个真实问题里修好了19%，也就是57个左右，而且平均每个只花大约4分钟，成本还只有0.43美元。厉害吧？这说明AI不只是会“写一句代码”，还开始学会“修一整件事”了！
当然，它也不是魔法。问题说得不清楚、测试不够、代码太乱的时候，它也会迷路。不过这已经很像一个正在成长的高级游戏助手了：先会找错，再会修错，最后才可能真正帮你管住整个大型项目。
术语表
AST（抽象语法树）
把代码按语法结构拆成树状表示，方便机器理解“类、方法、调用关系”这些结构。技术上，AutoCodeRover把它作为代码搜索与定位的底层表示。
用于search_class、search_method_in_class等结构化检索。
LLM agent（大语言模型代理）
由大模型驱动、能调用工具并根据反馈继续行动的系统。技术上，它不是一次性生成答案，而是迭代搜索、分析、再生成补丁。
分别承担上下文检索和补丁生成两个阶段。
SBFL（谱系故障定位）
利用通过/失败测试的执行覆盖信息，给程序方法或语句分配“可疑度”。直观上，它告诉系统“哪些地方更像出错源头”。
在有测试套件时用于缩小搜索范围。
SWE-bench-lite
一个包含300个真实GitHub issue的基准，覆盖11个Python开源项目。它衡量模型能否从issue到补丁完成端到端修复。
本文的主实验数据集。
pass@1
只给一次机会时，系统能否直接成功的指标。它更贴近真实自动化场景，因为不依赖大量重试。
作者报告约57个issue在单次尝试下被修复。
开放问题 这项研究留下的未解疑问
- 1 目前还不清楚这种“AST结构化检索+LLM代理”在跨语言、大规模多模块仓库中的稳定性如何；现有结果主要来自300个Python issue，泛化边界仍需更多证据。
- 2 论文显示平均成本很低，但没有系统展开不同仓库规模、不同测试密度、不同issue复杂度下的成本曲线；未来需要回答“什么样的项目最适合自动修复”。
应用场景
近期应用
开源Issue自动初修
维护者可以让系统先读报错、找相关类和方法、生成候选补丁，再由人工审查。前提是仓库可本地索引且最好有测试集。
企业内部代码修复助手
在大型内部仓库中，AutoCodeRover可作为“第一轮排查员”，帮助工程师快速缩小根因范围，减少人工翻文件和盲目试错。
远期愿景
自主软件工程流水线
未来可把自动定位、自动修复、自动测试与自动评审串成闭环，让LLM生成的代码先自我改进再进入人工审核，推动半自治开发。
原文摘要
Researchers have made significant progress in automating the software development process in the past decades. Recent progress in Large Language Models (LLMs) has significantly impacted the development process, where developers can use LLM-based programming assistants to achieve automated coding. Nevertheless, software engineering involves the process of program improvement apart from coding, specifically to enable software maintenance (e.g. bug fixing) and software evolution (e.g. feature additions). In this paper, we propose an automated approach for solving GitHub issues to autonomously achieve program improvement. In our approach called AutoCodeRover, LLMs are combined with sophisticated code search capabilities, ultimately leading to a program modification or patch. In contrast to recent LLM agent approaches from AI researchers and practitioners, our outlook is more software engineering oriented. We work on a program representation (abstract syntax tree) as opposed to viewing a software project as a mere collection of files. Our code search exploits the program structure in the form of classes/methods to enhance LLM's understanding of the issue's root cause, and effectively retrieve a context via iterative search. The use of spectrum-based fault localization using tests, further sharpens the context, as long as a test-suite is available. Experiments on SWE-bench-lite (300 real-life GitHub issues) show increased efficacy in solving GitHub issues (19% on SWE-bench-lite), which is higher than the efficacy of the recently reported SWE-agent. In addition, AutoCodeRover achieved this efficacy with significantly lower cost (on average, $0.43 USD), compared to other baselines. We posit that our workflow enables autonomous software engineering, where, in future, auto-generated code from LLMs can be autonomously improved.