读前先问
EvidenT 解决的不是"某一行代码怎么改"，而是"一个软件包在真实构建环境里失败后，怎样跨日志、构建配方、脚本与源码归档持续修到能重新构建"。
- 大方向的任务是什么？ 这是系统级软件包自动修复（system-level package repair）：输入是一个构建失败的软件包及其构建日志、
.spec文件（RPM/openSUSE 软件包常用的"构建说明书"，负责声明依赖、编译命令、测试和安装阶段）、脚本、压缩源码包和目标处理器信息；输出是经过修改、能在外部构建服务中成功重建的软件包。 - 这个方向有什么问题？ 失败证据分散在多种文件里，日志长而嘈杂，真正需要修改的对象也不一定是源码。一次失败的修复如果没有被记录，智能体下一轮还可能重复同一条错误路线。
- 为什么会有这些问题？ 工具链的频繁更新以及指令集架构（ISA）多样性的不断提升，使得大规模系统级软件包修复成为一项关键任务。由于故障证据异构、依赖约束复杂，且存在架构特有的构建约定，诊断和修复构建故障仍然极具挑战性。
- 作者怎么解决？ EvidenT 用一个按轮次维护证据的控制器，把"最新构建反馈、修复历史、缓存发现、知识上下文"放进固定槽位，再通过 MCP（Model Context Protocol，模型上下文协议） 把日志分析、依赖解析、文件定位、归档修改和构建验证封装成大模型可以按统一接口调用的工具。
- 怎么验证？ 主实验使用 219 个 RISC-V 构建失败软件包，并在 79 个 aarch64（64 位 ARM 架构）与 83 个 x86_64（常见于 Intel/AMD 电脑和服务器的 64 位架构）软件包上验证跨指令集架构泛化；最多允许 3 轮"分析—修改—重新构建"。
- 结果怎样？ GPT-5-mini 版本修复 118/219 个 RISC-V 软件包，成功率 53.88%，约为 CXXCrafter（一个面向构建流程生成与修复的对比系统，成功率 20.55%）的 2.62 倍。这里的"成功"由 OBS（Open Build Service，开放构建服务） 判定：OBS 接收软件包源码、
.spec构建配方和相关文件，在隔离且可复现的构建环境中解析依赖，依次执行准备、编译、测试、安装和打包，并返回状态与完整日志；只有状态变为succeeded才算修复成功。因此它比让大模型自行判断可靠，但仍不等价于运行时功能完全正确。
论文精读
引言
软件包生态可以理解为"源码 + 构建规则 + 依赖 + 测试 + 打包元数据"的整体。持续演化的依赖、编译器、指令集架构和构建工具会让一个原本可用的软件包突然构建失败。与单文件程序修复不同，系统级修复往往要同时理解日志、.spec 文件、Shell 脚本、压缩归档和构建环境。
把前面的概念串起来看：RISC-V、aarch64 和 x86_64 都属于 ISA（Instruction Set Architecture，指令集架构），不同 ISA 可能使用不同编译器参数、汇编指令、依赖版本和兼容性补丁。OBS 在本文中既是执行环境，也是评价"裁判"：它从干净环境重新构建整个软件包，而不是只检查某个文件能否通过语法检查；构建失败时还会产生新日志，作为下一轮修复的反馈。
作者先做了一项 100 例配对研究：每个失败构建对应最近一次后来成功的构建，并由两名工程师独立标注失败类型、修复位置和修改规模，分歧通过讨论解决。这个研究直接导出三项设计要求：必须拿到可操作的失败证据；必须把异构证据组织成稳定结构；必须保存前几轮失败尝试，避免重复。
方法
整体架构：三个主组件如何形成闭环
EvidenT 的整体架构不是若干工具的简单堆叠，而是三个主组件分工协作。论文提出的三个挑战，也分别对应这三个组件：
- Analysis and Repair Orchestration（分析与修复编排模块）：对应 Challenge 1。它协调日志异常提取、依赖约束解析、目录结构定位等分析工具，以及归档重打包、配置适配、源码修改等修复工具。它的职责是把嘈杂构建信号变成可行动的失败证据，并在模型缺少专业经验时补充历史案例和架构知识。
- Evidence-Preserving Repair Controller（证据保留修复控制器）：对应 Challenge 2。它维护能够区分不同迭代轮次的证据上下文，把最新构建反馈、修复历史、缓存发现和知识上下文融合到固定提示词槽位。它不直接修改文件，而是负责"这一轮模型应该看到什么、哪些失败路线不能再走"。
- Build-based Validation and Feedback Loop（基于构建的验证与反馈循环）：对应 Challenge 3。它把修补后的完整软件包送入可复现的外部构建环境，根据成功、失败或超时结果生成新的构建证据，再交还控制器。这样每轮都有真实执行结果约束，避免只靠模型自我判断，也减少重复探索。
把数据流连起来就是：失败软件包和日志进入控制器 → 编排模块定位问题并修改工件 → 外部构建服务验证完整软件包 → 构建结果回到控制器，成为下一轮的新证据。因此，编排模块负责"做什么"，控制器负责"记住什么并如何决策"，验证循环负责"修得对不对"。
方法一：从噪声日志里提取可操作证据
论文把"故障定位"明确拆成三类工具，而不是笼统地让模型自己翻日志和目录：
- Failure Signal Extraction（失败信号提取工具）：其中核心是 ALC（Anomaly-focused Log Condensation，面向异常的日志压缩）。它先按准备、编译、测试、安装等构建阶段切分日志，再用 Drain（一种把大量相似日志自动归并成模板的日志解析算法）去掉重复噪声，最后让 LLM（Large Language Model，大语言模型） 判断哪些模板和上下文真正指向失败。它回答"哪里报错，哪几行最值得看"。
- Dependency Constraints（依赖约束工具）：解析
.spec文件中的BuildRequires、宏、版本限制和各构建阶段，整理成结构化约束。它回答"这个包需要哪些库、工具或版本条件，当前修法有没有违反构建配方"。 - Structure Localization（结构定位工具）：扫描源码目录和压缩包内部结构，提取可能相关的文件、类、函数或符号，并剪掉与错误无关的大量目录。它回答"错误信号应该落到哪个具体文件或代码位置"。
这三类属于"分析和定位"工具；归档重打包、配置适配和源码修改则是后续的"执行修复"工具。前者决定改哪里、为什么改，后者才真正改变软件包内容。
方法二：把四类证据放进固定槽位
控制器每轮维护四类上下文：Build Feedback 只保留最新一次完整构建的结果；Repair History 保存前几轮改过什么以及验证结果，把失败补丁当作负面证据；Cached Findings 缓存确定性工具的输出，避免同一轮反复扫描；Knowledge Context 按需检索历史问题、代码评审、架构文档与 ISA 相关陷阱。
融合时遵守三个原则：第一，时间锚定，最新构建反馈覆盖旧日志；第二，固定槽位，不同来源不会混成一大段上下文；第三，负面约束，把失败路线转写为"不要重复"的提示。它的作用不是让上下文越积越长，而是让每轮都能回答四个问题：刚才哪里失败、已经试过什么、当前稳定事实是什么、过去类似问题怎么解决。
方法三：用动态提示词约束完整工作流
动态提示词由三部分组成：全局修复规则、四个证据槽位和三阶段工作流。规则要求优先处理与失败相关的工件、修改要最小但完整、保持原有结构、所有修改必须经过真实构建验证；工作流则固定为"分析与定位—工件级修改—提交并重建"。
这比普通 ReAct（让模型在"思考—调用工具—观察结果"之间循环的智能体工作方式）提示更像一份维修工单：模型可以决定具体怎么修，但不能跳过构建验证，也不能把前一轮已经失败的路线当成新方案。论文把这种结构称为 cross-modal evidence fusion（跨模态证据融合）；这里的"模态"不是图像与文本，而是日志、配方、目录结构、补丁历史和架构知识等不同工程证据形态。
方法四：真正修改软件包，而不是只生成补丁文本
MCP 工具把修复动作分成三类：归档重打包会解压源码包、修改内部文件并重新封装；配置适配会更新构建配方或配置；源码修改会原子地替换目标文件。完整文件更新虽然比行级 diff 更重，但能减少补丁上下文错位、编码或换行破坏等工程问题。
每轮结束必须把修改后的软件包送入外部构建服务。构建成功则停止；失败或超时则把最新结果写回证据槽，再进入下一轮。论文实验最多 3 轮，每次 OBS 轮询上限为 600 秒。因此，EvidenT 的真正"裁判"不是 LLM 自评，而是可复现构建环境。
实验
前置实证研究：RQ1 与 RQ2
这里的 RQ（Research Question，研究问题）1 和 2 不是在评估 EvidenT 的成功率，而是在回答"真实软件包为什么构建失败、人工最终改了哪里"。作者先用这两项研究建立需求，再从 RQ3 开始评估 EvidenT。
RQ1：构建失败的主要根因是什么？
作者从 OBS 收集最近的 100 个 RISC-V 构建失败软件包。它们是后续 219 个主评估样本的一个子集，并满足三个筛选条件：失败之后能找到同一软件包的后续成功构建；日志、.spec、源码和辅助文件完整可取；失败与成功版本都能复现。两名软件工程师独立阅读失败日志并标注根因，遇到分歧后讨论形成统一分类。
表 2 值得从五个角度理解：
- 测试失败最多，占 44/100。 其中测试断言或规范检查失败 17 个、测试框架执行问题 16 个、测试代码与新环境不兼容 11 个。它说明"源码编译通过"并不等于软件包可交付，测试代码、测试依赖和测试环境同样是重要维护对象。
- 编译失败占 27/100，但内部原因并不单一。 代码级语法/类型问题与构建脚本或编译器配置问题各 11 个，API/函数不兼容 5 个。相同的"编译失败"表象，可能要改源码、编译参数、头文件或依赖版本，不能只看最后一行报错。
- 依赖失败占 21/100，且"缺少依赖"比"依赖冲突"更常见。 缺少库、工具或模块有 15 个，版本冲突或依赖已废弃有 6 个。这类问题往往应该先检查
.spec中的BuildRequires和版本约束，而不是直接改业务源码。 - 打包失败只有 8/100，却不能忽略。 其中 6 个来自打包配置或语法，2 个发生在安装/最终验证阶段。它们通常与宏、安装路径、文件清单或子包冲突有关，错误位置可能已经远离真正需要修改的配置。
- 44% 是测试相关，56% 分散在依赖、编译和打包阶段。 这说明不存在一套只面向源码或只面向日志末尾的通用修法，也直接解释了为什么架构中需要日志、依赖和结构三类定位工具。
还要注意两个边界：第一，表 2 是两名工程师基于日志做出的专家分类，不是 EvidenT 自动预测的标签；第二，这 100 个样本要求之后存在成功版本且能够复现，因此可能低估那些长期无人修复、工件残缺或环境无法重建的困难案例。表 2 的 Count 也只是出现频数，不能和后文"各类别修复成功率"混为一谈。
RQ2：修复为什么困难，最终修改真正落在哪里？
RQ2 不再只看失败日志，而是把每个失败软件包与时间上最近的后续成功构建配对，在目录结构、源码、.spec 文件、源码归档和辅助打包文件上做文件级与行级差异比较。
结果是：72/100 的成功修复主要修改 .spec 构建配方，包括依赖声明、宏、编译标志和补丁应用方式；其中 45 个修改不超过 50 行，23 个修改 51–100 行，4 个超过 100 行。剩余 28/100 涉及源码归档或辅助文件，其中新增文件 9 个、删除文件 2 个、修改既有文件 17 个。
这个结果支持两个结论。第一，系统级修复的主要对象经常是"软件如何被构建和打包"，而不只是源码算法；第二，即便修改规模不大，也必须先跨日志、依赖、配方和目录结构找到正确工件。因此 RQ2 直接推动了 EvidenT 的工件级修复工具和证据融合设计。
需要避免一个常见误读：这里的 72% 表示成功版本与失败版本相比，主要修复位置在 .spec；它不等于"72% 的原始失败都由配置错误造成"。失败根因分类看表 2，修复落点看 RQ2，两者回答的是不同问题。
数据、指标与对比方法
- 数据集：219 个 RISC-V、79 个 aarch64、83 个 x86_64 的真实 OBS 失败软件包；RISC-V 为主实验，其余用于跨 ISA 泛化。
- 成功指标：重建后 OBS 状态为
succeeded；成功率 = 成功重建的软件包数 / 全部评估软件包数。 - 结果状态：
Failed表示系统完成修复尝试后，软件包仍然构建失败。B/U是论文合并使用的一列，完整写法是 Broken/Unsolvable：其中 B = Broken，字面意思是输入工件本身残缺或不可正常处理；U = Unsolvable，表示在当前工件、依赖和工具能力下无法继续求解。论文只说明这一合并类别包括"描述缺失或依赖无法解析"的案例，并没有再给 B、U 各自独立的判定规则或数量，因此不能把二者拆成两个精确统计项。 - 时间指标：
Time-R是不含构建阶段的平均修复开销，Time-B是平均外部构建耗时。 - 对比方法：Bare LLM（只看原始日志和工作区、单轮生成修改）、Agentless（轻量文件定位与补丁生成 Agent）、CXXCrafter（偏向生成和改进完整构建方案）、RepairAgent（通用工具增强修复 Agent），以及工具相同但每轮清空证据的 EvidenT w/o evidence。
测试、依赖、编译、打包四类成功率是怎么评估的？
这四个数字不是"测试准确率、依赖准确率"等四种不同指标，而是用同一个最终标准，在四组不同失败样本上分别计算：
- 两名工程师先阅读原始失败日志，把每个软件包按最初的根因归到一类：依赖失败、编译失败、测试失败或打包失败。依赖失败指缺少/冲突的库或版本；编译失败指编译器拒绝源码或构建指令；测试失败指
%check阶段的断言、兼容性或测试框架执行失败；打包失败指安装路径、文件清单、宏、元数据或打包脚本出错。 - EvidenT 对每个软件包执行最多三轮修复，并把修改后的完整软件包交给 OBS 重新构建。
- 对任一类别，都用同一个公式：该类别中最终 OBS 构建成功的软件包数 ÷ 该类别的软件包总数。例如"测试失败成功率"不是看测试用例通过了多少，而是看"原本在测试阶段失败的软件包"有多少经过修复后让整个构建流程变成
succeeded。
论文报告测试、依赖、编译、打包四类分别为 68.18%、61.90%、55.56%、50.00%。需要注意，实验章节没有再次列出这四组的分母；这些百分比与前面人工标注的 100 个子集（44、21、27、8 个）恰好对应，可分别反推出 30/44、13/21、15/27、4/8，但这是根据数字做的对应推断，论文没有在该段明确写出分子。
关键结果
- 整体有效：EvidenT（GPT-5-mini）达到 53.88%，明显高于 CXXCrafter 的 20.55% 和无证据版本的 19.18%。这说明"有工具"还不够，跨轮次组织证据才是主要增益来源。
- 不是只会修编译错误：测试、依赖、编译、打包四类失败的成功率分别为 68.18%、61.90%、55.56%、50.00%。
- 跨架构仍有效：在 aarch64 和 x86_64 上分别达到 41.77% 与 46.99%，但三组数据仍来自同一个 OBS/软件包生态，因此不能直接外推到任意构建系统。
- 多轮确实必要：GPT-5-mini 从 1 轮的 28.77% 提升到 2 轮的 43.38%，3 轮达到 53.88%；Qwen3-max 也从 14.61% 提升到 26.03%。
- ALC 是最敏感的单模块：完整系统为 53.88%；移除 ALC 后只剩 29.68%，下降 24.20 个百分点。移除知识上下文、依赖约束、结构定位后分别为 32.42%、35.62%、44.75%。
失败分析也值得注意：论文统计 7,923 次工具调用，仅 3 次顺序错误，但有 34 次因为归档损坏、构建配方缺失或元数据非法而提前终止。这说明下一步瓶颈不只是模型推理，还包括工件完整性检查、工具错误恢复和更稳定的构建反馈。
读后回顾
动机
以前的自动修复常把任务压缩成"日志 → 补丁"，默认失败证据一次就足够、修改对象主要是源码、模型会自然记住前一轮做过什么。系统级软件包恰好同时破坏这三个假设：证据分散、修改对象多样、验证周期长，而且失败尝试本身也包含信息。
EvidenT 最重要的视角转换是：迭代失败不是无用结果，而是下一轮的证据。这使问题从"生成一个好补丁"变成"维护一个可审计的维修状态，并用真实构建不断收敛"。
创新点
- 把证据保存提升为控制器的一等能力。 四个固定槽位同时约束新旧证据、失败历史和领域知识，解决多轮智能体容易遗忘、重复和上下文漂移的问题。
- 把系统级修复拆成可调用工具。 日志异常、依赖、结构、归档、配置、源码和构建验证都有明确接口，使 LLM 负责决策，工具负责确定性操作。
- 用真实构建闭环评价每一步。 每个修复动作是否有效，不靠模型打分，而看外部构建是否成功；失败结果返回下一轮。
从审稿视角看，这篇论文能成立的关键不是"又做了一个 Agent"，而是先用 100 个真实案例说明任务结构，再让架构的每个模块对应一个经验发现，并通过无证据版本、模块消融、跨 ISA 实验和多轮曲线逐层验证。它形成了比较完整的"问题证据—设计选择—实验支撑"链条。
核心方法：论文与代码逐项对照
| 论文模块 | 代码位置 | 实现方式与实践意义 |
|---|---|---|
| 多轮控制器 | client.py |
AutoRepairClient 默认最多 3 次构建尝试、每轮最多 30 次工具交互；每轮先重置缓存、注入历史，再进入 LLM—工具循环。若模型没有主动检查构建，代码会执行兜底验证。 |
| 动态提示词 | utils/prompts/merged_prompt_loop.txt |
明确要求优先依据证据、默认先看 .spec、做最小且完整的修改、重打包后再验证，并按分析、修复、验证三阶段行动。 |
| 四类证据状态 | server.py |
用 modification_history、tool_call_history、tool_cache 保存历史与缓存；新一轮会清空缓存和调用记录，但保留修改历史。 |
| 故障定位 | tools/analysis_and_repair/ad/、dependency_constrain.py、localize_structure.py |
分别完成阶段化日志压缩与异常分类、.spec 依赖解析、跨语言目录与符号结构定位。 |
| 知识检索 | arch_know_search.py、historical_case.py |
用 TF-IDF 与余弦相似度检索 ISA 知识和历史案例，属于轻量、可解释的辅助知识来源。 |
| 工件级修改 | server.py 中的修改与归档工具 |
采用完整文件原子更新，并检查压缩目标不能错误指向解压目录；降低归档递归、半写入和补丁错位风险。 |
| 构建验证 | tools/validation/check_build_res.py、docker_build.py |
论文复现实验使用 OBS；当前仓库为评审方便默认提供 Docker 后端，失败日志写入 log_failed.txt，OBS 路径仍保留。 |
提示词大概怎么写？
它不是让模型"自由修复"，而是先给硬规则，再给证据槽，最后限定阶段。可以概括成：
全局规则：只处理与失败相关的工件；修改必须最小但完整；保持原有结构；每轮必须真实构建。
本轮证据：最新错误是什么；之前改过什么且为何失败；哪些工具结论仍有效；有哪些历史案例或 ISA 陷阱。
行动顺序：先定位 → 再修改 → 必要时重新封装 → 上传/提交 → 检查构建结果。
代码还包含两类保护：check_repeat_tool_call 最多容忍同类重复调用 5 次；若模型没有完成上传或构建检查，客户端会补上确定性步骤。这些工程约束让"必须验证"不只停留在提示词层面。
论文描述与代码的一处重要差异
论文把 Repair History 描述成"自动记录所有修改并把失败补丁作为负面证据"。仓库里确实有 track_file_modification_tool，但 modify_file_tool 并不会自动调用它，提示词也没有强制每次修改后必须调用跟踪工具。换句话说，历史保存能力存在，但是否完整记录仍可能依赖 Agent 是否主动调用。若把它做成生产系统，最好在修改工具内部自动写入历史，避免关键创新点依赖模型自觉。
从消融结果看，证据保留控制器 + ALC 是最核心组合：无证据版本只有 19.18%，说明跨轮次状态是框架级贡献；移除 ALC 从 53.88% 降到 29.68%，说明没有高质量失败信号，再好的循环也会在噪声中迭代。这个结论与论文创新点基本匹配。
实验分析
数据集与评估方式
数据并不是常见的静态代码补丁基准，而是 OBS 中可重建的真实失败软件包。每个样本都必须能获取完整工件并在实验环境中复现。主实验以 RISC-V 为中心，aarch64 和 x86_64 用来检验只替换 ISA 知识上下文后能否迁移。
评估是自动化、外部环境驱动的：系统提交修改后的软件包，等待构建服务返回成功、失败或超时。论文还报告修复耗时和构建耗时；没有依赖人工或另一个大模型给补丁"打分"。
每个实验分别证明什么？
RQ3：完整系统是否真的比现有方法有效？
- 怎么比：在 219 个 RISC-V 失败软件包上统一使用 OBS 作为最终验证器；对比 Bare LLM、Agentless、CXXCrafter、RepairAgent，以及使用相同工具但不保留跨轮证据的 EvidenT w/o evidence。
- 看到什么：GPT-5-mini 版本的 EvidenT 成功修复 118/219（53.88%）；最强已有基线 CXXCrafter 为 45/219（20.55%）；Bare LLM 只有 4/219（1.83%）；无证据版本为 42/219（19.18%）。
- 能证明什么：单轮"日志到补丁"远远不够；即便给 Agent 同样的分析和修改工具，如果清空前一轮证据，成功率也会大幅下降。因此核心增益来自"工具编排 + 跨轮证据管理"，不是单纯换了更强模型。
- 补充分析：作者还按失败类别、主要编程语言和底层 LLM 分组。多语言软件包修复 42/80；Python 为 54/89；C/C++ 为 8/20。更换为 Qwen3-max 或 DeepSeek-v3 后成功率降为 26.03% 和 17.81%，说明框架有效但仍明显依赖基础模型能力。
RQ4：能不能从 RISC-V 迁移到别的处理器架构？
- 怎么比：保持控制器、工具和工作流不变，只替换"知识上下文"中的架构相关资料，然后分别处理 79 个 aarch64 与 83 个 x86_64 失败软件包。
- 看到什么：aarch64 成功 33/79（41.77%），x86_64 成功 39/83（46.99%）；两组都优于相应基线和无证据版本。
- 能证明什么：核心循环没有把 RISC-V 规则硬编码到所有模块，架构特有知识可以相对独立地替换。
- 不能证明什么：三组仍来自同一个 OBS 软件包生态，所以这只是跨 ISA 泛化，不等于跨发行版、跨构建平台或跨企业环境都有效。
RQ5：多轮迭代真的有用，还是重复碰运气？
- 怎么比：把最大修复轮数分别设为 1、2、3，并同时观察 GPT-5-mini 与 Qwen3-max；每一轮都必须经过一次真实构建，失败日志和修改历史才能进入下一轮。
- 看到什么：GPT-5-mini 从 63/219（28.77%）提升到 95/219（43.38%），再到 118/219（53.88%）；Qwen3-max 从 32/219（14.61%）提升到 43/219（19.63%），再到 57/219（26.03%）。
- 能证明什么：增加轮数与更高成功率相关，而且两种模型趋势一致；结合无证据对照，说明后续轮确实在利用最新构建反馈和历史修改。
- 仍缺什么：论文没有给出相同调用预算下"只重复、不保留证据"的独立随机重试基线，因此不能把全部增益都严格归因于证据复用。
RQ6：到底哪个模块贡献最大？
- 怎么比：每次只移除一个模块，其他设置保持不变：ALC 日志压缩、KC（Knowledge Context，知识上下文）、DC（Dependency Constraints，依赖约束）或 SL（Structure Localization，结构定位）。
- 看到什么：完整系统为 53.88%；移除 ALC、KC、DC、SL 后分别降到 29.68%、32.42%、35.62%、44.75%。
- 能证明什么：四个模块都有正贡献。ALC 被移除后的跌幅最大（24.20 个百分点），说明先从长日志中找对失败信号，是后续依赖推理和文件修改能够奏效的前提；结构定位降幅较小，但仍有稳定贡献。
- 注意：单模块消融可以说明"移除它会怎样"，却不能完全分离模块之间的交互，例如 ALC 与依赖约束可能相互增强。
RQ7：系统为什么仍然会失败？
- 怎么分析：作者回看工具调用轨迹和无法完成的修复案例。
- 看到什么：共 7,923 次工具调用中只有 3 次顺序错误，但有 34 次因归档损坏、构建配方缺失或元数据非法而提前终止；论文案例还展示了一个经过三轮才补齐头文件内容、依赖和类定义的修复过程。
- 能证明什么：主要瓶颈已经不只是"模型会不会按顺序调用工具"，而是输入工件是否完整、外部依赖是否可获得，以及构建反馈能否持续提供有效证据。
还缺哪些实验？
- 构建成功之后的单元测试、集成测试、回归测试和性能测试；当前指标无法排除"能编过但行为错了"。
- 多次独立运行的方差、成本与 token 消耗；论文只说明 GPT-5-mini 两次运行没有明显变化，统计强度仍有限。
- 跨 OBS 之外的构建平台、更多发行版与更复杂依赖生态。
- 对修改历史是否完整记录的端到端审计，以及自动记录历史后的增益。
- 与人工维护者的补丁质量、可读性、安全性和合入率比较。
下游任务与局限
- 验证指标偏窄：构建成功是必要条件，不是功能正确的充分条件。
- 不可解样本边界会影响分母：
B/U是 Broken/Unsolvable 的合并标记，即"工件损坏/不完整"或"在当前条件下不可求解"。论文没有把 B 与 U 分别计数，只把描述缺失、依赖无法解析等案例统一纳入这一列；因此数据准备质量和"不可解"的操作性定义都会显著影响成功率。 - 工具链仍可能脆弱：归档损坏、元数据非法和外部服务不稳定会让循环提前终止。
- 知识检索较轻量：TF-IDF 适合稳定、可解释的基线，但对语义相近而词面不同的历史案例可能召回不足。
- 代码中的历史跟踪未完全内建：应把修改记录变成所有写工具的强制副作用，并附带文件哈希、diff、构建结果和回滚点。
可以沿三个方向继续做：把测试与运行时探针接入验证闭环；把每轮证据组织成可查询的修复轨迹图；在真实仓库中加入补丁审查、安全扫描和自动回滚，使系统从"构建修复器"走向"可合入的维护助手"。
FAQ
1. 论文到底怎样量化"修好了"？
唯一硬指标是外部构建服务返回 succeeded。它比 LLM 自评可靠，但只覆盖"能成功构建"；如果补丁让测试被跳过、功能退化或性能下降，当前指标可能察觉不到。
2. 为什么四类证据不是全部无限累积？
最新构建反馈只保留一份，避免旧日志干扰；修复历史跨轮保留，用于禁止重复；缓存发现只在底层工件不变时复用；知识上下文按需检索。这样的生命周期设计兼顾了"记住教训"和"不过载上下文"。
3. 多轮提升会不会只是多给模型几次碰运气？
曲线本身不能完全排除随机性，但 w/o evidence 只有 19.18%，完整系统为 53.88%，说明有结构的证据复用远比单纯重复更重要。更严谨的后续研究仍应报告多随机种子方差，并设置"相同调用预算但不保留证据"的重复试验。
4. 公开代码能直接复现论文结果吗？
仓库提供代码、轻量 smoke test、Docker 验证后端和 Zenodo 数据；论文主结果则依赖 OBS、模型凭据和完整评估环境。当前 main.py 只是占位入口，实际流程从 client.py 启动。轻量测试通过只能证明导入、样例和核心解析器可运行，不等价于复现 219 个软件包的 53.88%。
我按论文完整标题、arXiv ID 和
site:openreview.net检索，未找到公开 OpenReview 评审或 rebuttal 记录。因此这里没有臆造审稿意见，FAQ 仅来自论文、代码与实验边界。
