★ FEATURED ARTICLE 读前先问EvidenT 解决的不是某一行代码怎么改而是一个软件包在真实构建环境里失败后怎样跨日志、构建配方、脚本与源码归档持续修到能重新构建。大方向的任务是什么这是系统级软件包自动修复system-level package repair输入是一个构建失败的软件包及其构建日志、.spec文件RPM/openSUSE 软件包常用的构建说明书负责声明依赖、编译命令、测试和安装阶段、脚本、压缩源码包和目标处理器信息输出是经过修改、能在外部构建服务中成功重建的软件包。这个方向有什么问题失败证据分散在多种文件里日志长而嘈杂真正需要修改的对象也不一定是源码。一次失败的修复如果没有被记录智能体下一轮还可能重复同一条错误路线。为什么会有这些问题工具链的频繁更新以及指令集架构ISA多样性的不断提升使得大规模系统级软件包修复成为一项关键任务。由于故障证据异构、依赖约束复杂且存在架构特有的构建约定诊断和修复构建故障仍然极具挑战性。作者怎么解决EvidenT 用一个按轮次维护证据的控制器把最新构建反馈、修复历史、缓存发现、知识上下文放进固定槽位再通过MCPModel Context Protocol模型上下文协议把日志分析、依赖解析、文件定位、归档修改和构建验证封装成大模型可以按统一接口调用的工具。怎么验证主实验使用 219 个 RISC-V 构建失败软件包并在 79 个aarch6464 位 ARM 架构与 83 个x86_64常见于 Intel/AMD 电脑和服务器的 64 位架构软件包上验证跨指令集架构泛化最多允许 3 轮分析—修改—重新构建。结果怎样GPT-5-mini 版本修复 118/219 个 RISC-V 软件包成功率 53.88%约为 CXXCrafter一个面向构建流程生成与修复的对比系统成功率 20.55%的 2.62 倍。这里的成功由OBSOpen Build Service开放构建服务判定OBS 接收软件包源码、.spec构建配方和相关文件在隔离且可复现的构建环境中解析依赖依次执行准备、编译、测试、安装和打包并返回状态与完整日志只有状态变为succeeded才算修复成功。因此它比让大模型自行判断可靠但仍不等价于运行时功能完全正确。论文精读引言软件包生态可以理解为源码 构建规则 依赖 测试 打包元数据的整体。持续演化的依赖、编译器、指令集架构和构建工具会让一个原本可用的软件包突然构建失败。与单文件程序修复不同系统级修复往往要同时理解日志、.spec文件、Shell 脚本、压缩归档和构建环境。把前面的概念串起来看RISC-V、aarch64 和 x86_64 都属于ISAInstruction 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失败信号提取工具其中核心是ALCAnomaly-focused Log Condensation面向异常的日志压缩。它先按准备、编译、测试、安装等构建阶段切分日志再用Drain一种把大量相似日志自动归并成模板的日志解析算法去掉重复噪声最后让LLMLarge 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这里的RQResearch 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但这是根据数字做的对应推断论文没有在该段明确写出分子。关键结果整体有效EvidenTGPT-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.pyAutoRepairClient默认最多 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.txtOBS 路径仍保留。提示词大概怎么写它不是让模型自由修复而是先给硬规则再给证据槽最后限定阶段。可以概括成全局规则只处理与失败相关的工件修改必须最小但完整保持原有结构每轮必须真实构建。本轮证据最新错误是什么之前改过什么且为何失败哪些工具结论仍有效有哪些历史案例或 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/21953.88%最强已有基线 CXXCrafter 为 45/21920.55%Bare LLM 只有 4/2191.83%无证据版本为 42/21919.18%。能证明什么单轮日志到补丁远远不够即便给 Agent 同样的分析和修改工具如果清空前一轮证据成功率也会大幅下降。因此核心增益来自工具编排 跨轮证据管理不是单纯换了更强模型。补充分析作者还按失败类别、主要编程语言和底层 LLM 分组。多语言软件包修复 42/80Python 为 54/89C/C 为 8/20。更换为 Qwen3-max 或 DeepSeek-v3 后成功率降为 26.03% 和 17.81%说明框架有效但仍明显依赖基础模型能力。RQ4能不能从 RISC-V 迁移到别的处理器架构怎么比保持控制器、工具和工作流不变只替换知识上下文中的架构相关资料然后分别处理 79 个 aarch64 与 83 个 x86_64 失败软件包。看到什么aarch64 成功 33/7941.77%x86_64 成功 39/8346.99%两组都优于相应基线和无证据版本。能证明什么核心循环没有把 RISC-V 规则硬编码到所有模块架构特有知识可以相对独立地替换。不能证明什么三组仍来自同一个 OBS 软件包生态所以这只是跨 ISA 泛化不等于跨发行版、跨构建平台或跨企业环境都有效。RQ5多轮迭代真的有用还是重复碰运气怎么比把最大修复轮数分别设为 1、2、3并同时观察 GPT-5-mini 与 Qwen3-max每一轮都必须经过一次真实构建失败日志和修改历史才能进入下一轮。看到什么GPT-5-mini 从 63/21928.77%提升到 95/21943.38%再到 118/21953.88%Qwen3-max 从 32/21914.61%提升到 43/21919.63%再到 57/21926.03%。能证明什么增加轮数与更高成功率相关而且两种模型趋势一致结合无证据对照说明后续轮确实在利用最新构建反馈和历史修改。仍缺什么论文没有给出相同调用预算下只重复、不保留证据的独立随机重试基线因此不能把全部增益都严格归因于证据复用。RQ6到底哪个模块贡献最大怎么比每次只移除一个模块其他设置保持不变ALC 日志压缩、KCKnowledge Context知识上下文、DCDependency Constraints依赖约束或 SLStructure 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、构建结果和回滚点。可以沿三个方向继续做把测试与运行时探针接入验证闭环把每轮证据组织成可查询的修复轨迹图在真实仓库中加入补丁审查、安全扫描和自动回滚使系统从构建修复器走向可合入的维护助手。FAQ1. 论文到底怎样量化修好了唯一硬指标是外部构建服务返回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 仅来自论文、代码与实验边界。参考资料论文EvidenT: An Evidence-Preserving Framework for Iterative System-Level Package Repair官方代码仓库完整评估数据与复现材料ZenodoISSTA 2026 Research Papers
阅读完成 · 觉得有帮助？
