Software Engineering Empirical Research Radar

从 FL/TCP 到 AI-Native Program Repair

一个面向中文快速阅读的 repair 专题教程：如何从 fault localization、test prioritization 和 trace 经验进入现代 LLM 程序修复。

定位。 你不需要从零变成 repair 学者。你已经有 FL、TCP、trace 和 CI 直觉；repair 只是把问题推进一步：不仅问哪里错、跑哪些测试，还问如何生成补丁、验证补丁、避免假修。

主张。 AI repair 时代最有价值的不是泛泛代码生成，而是诊断证据如何改变模型的修复行为。

总览论文地图实验设计怎么开跑Starter Lab成本预算FAQ
返回总教程 Benchmark map 相关论文

分层阅读路线

Repair Pipeline：先看流程，不先看数字

Bug context

收集 failing tests、stack trace、错误输出、相关文件/函数、依赖片段和已有测试。

Localization / scope

决定模型应该看 statement、method、function、file 还是多文件上下文。

Patch generation

LLM 或 repair system 生成候选补丁；可以一次生成，也可以多轮 agentic 生成。

Validation

编译、运行 triggering/relevant/all tests，并记录 plausible、失败日志和成本。

Feedback loop

把编译错误、测试失败、运行时状态或诊断证据反馈给模型，再试下一轮。

Correctness review

区分 plausible patch 和 correct patch，检查 overfitting、语义偏差和补丁大小。

近年代表工作怎么读

工作设置你该学什么链接
SRepairfunction-level LLM repair; Defects4J 1.2/2.0不要默认 statement-level FL 是唯一入口；function-level repair 已经是强 practical baseline。source
RepairAgentautonomous LLM-based agent for program repair现代 baseline 不只是 prompt，而是查文件、找上下文、生成补丁、跑测试、迭代。source
DebugRepairself-directed debugging + runtime evidence for LLM APR运行时证据正在成为强线；我们的 trace/value-route 必须压缩成公平、patch-free advice。source
NIST/IEEE Computer surveyLLM-based APR overview用 survey 快速建立术语和系统分类，但不要只停在综述。source
Defects4JJava real-bug benchmark所有 repair 数字先问版本、active/deprecated、bug universe、validation scope。source

今年工作的演化

时间线主流形态关键技术对我们的启发
2023--2024LLM repair 从 direct prompting 走向 FL/context-guided repair；研究重点是给模型多少上下文、用 statement 还是 function scope。buggy function retrieval、suspicious statement、few-shot prompt、multi-sample patch generation、generate-and-validate。这阶段的核心问题是 context selection；你的 FL 能力可以直接变成 repair scope/advice。
2024--2025Repair 开始明显 agent 化：模型不只输出补丁，还会查文件、定位、修改、运行测试并根据失败继续迭代。tool use、file navigation、test feedback loop、patch queue、budgeted attempts、agent trace logging。强 baseline 不能只用一次性 LLM；至少要有反馈循环或 agentic baseline。
2025--2026研究重心转向 runtime evidence、自主 debugging、评价可信度和更严格的 correct patch 判定。stack/value evidence、trace compression、failing/passing contrast、generated tests、overfitting detection、semantic review。这正好连接 00 的 trace 采集和 06/07/08 的诊断证据；关键是 patch-free、statement-level、tie-worst 的公平证据。

现在大概能修到什么水平

口径直观数字怎么解读链接
Defects4J official universe854 active bugs + 10 deprecated bugs先确认分母；不同论文用 395、835、854 或子集时不能直接横比。source
RepairAgent164 / 835 correct bugs, about 19.6%agentic repair 是合理 baseline，但不是天花板；它展示了 tool loop 的必要性。source
SRepairreported 300 single-function bugs plus 32 multi-function bugsfunction-level context 能很强；只给 statement 可能会限制 LLM。source
DebugRepairreported 295 correct bugs with DeepSeek-V3 in its settingruntime evidence/self-debugging 已经是强线；我们的新证据要证明比普通 FL/Ochiai 更有用。source
Strict leaderboard styleoften reports much smaller cross-tool comparable numbersleaderboard 口径更保守；适合提醒自己 plausible/correct/benchmark split 不能混。source

读法。 Defects4J 上现代 LLM/APR 的强结果大致已经进入 20%--35% correct 的区间；但不同论文的 bug universe、模型、预算、validation scope 和 correct 判定不同，不能把数字当成一个排行榜。我们的实验必须用同一组 bugs、同一预算、同一模型、同一 validation protocol 做 paired comparison。

关键技术层

技术层核心问题常见做法我们的切入
Context retrieval模型该看哪些代码？file/function retrieval、call graph、dependency slice、test-to-code links。把 Ochiai statement 映射到 method/function neighborhood，比较不同 scope。
Diagnostic evidence模型该知道什么失败事实？stack trace、assert diff、value trace、failing/passing contrast、state invariant hint。把 00/06/07/08 的结果压缩成 patch-free diagnostic card。
Patch generation一次生成还是多候选？single-shot、multi-sample、self-refine、agent proposal queue。控制 token/attempt 数，避免我们的 arm 只是预算更多。
Validation scheduling每个 patch 后先跑哪些测试？compile first、triggering tests、relevant tests、full suite、history-aware prioritization。把 TCP 迁移成 repair-loop test scheduling。
Feedback summarization失败信息怎么回传给 LLM？compiler error summary、failed assertion diff、top stack frames、changed-line receipt。反馈必须短、固定格式、不能泄漏 developer patch。
Correctness defense过测试是否真的修对？human review、developer patch comparison、independent/generated tests、overfitting taxonomy。最终 claim 分 plausible/correct，负例单独分析。

你的旧能力怎么迁移

Transfer

FL / TCP / Trace 到 Repair 的翻译表

旧能力Repair 中的新问题可能贡献
Fault localization给模型哪个 scope 和 suspicious evidence？repair advice、statement-neighborhood evidence、scope selection。
Test prioritization每轮候选补丁之后先跑哪些 tests？agentic repair 的 validation scheduling。
Trace / value route失败与通过行为在哪里分叉？runtime evidence compression、diagnostic card。
CI / regression testing修复循环如何低成本、可靠、可回滚？repair loop protocol、cost-aware validation、flaky-aware repair。

Benchmark 和工具集

Benchmark / Tool适合做什么风险
Defects4J主战场；适合 FL/repair/testing 的可复现实验。版本和 bug universe 容易混；correct patch 仍需判定。
QuixBugs小算法 bug；适合快速 smoke test。太小，不能代表真实工程 repair。
ManyBugs / IntroClass经典 C repair benchmark。生态较旧，和 LLM/Java pipeline 距离较远。
SWE-bench真实 GitHub issue 级 agentic repair。太重，短期不适合作为第一篇主实验。
Bugs.jar / Bears / BugSwarmJava/CI 相关真实 bug 或 failure。搭建和可复现成本更高，适合作后续扩展。

常见坑

第一篇实验建议

Paper sprint

Diagnostic advice for LLM repair

最小公平实验不是“我们的 advice vs 什么都不给”，而是三组 paired comparison：

核心指标：fixed/plausible/correct、attempts、compile fail、test fail、patch size、test cost、overfitting risk。

两到四周冲刺计划

时间目标产出
Day 1--2搭 smoke runner能对 1 个 Defects4J bug 生成 patch、apply、compile、run tests、保存 receipt。
Day 3--4写三套 promptvanilla、Ochiai-guided、diagnostic-advice-guided，固定预算。
Day 5--7跑 3-bug smoke看是否出现 unique plausible/correct、attempt 减少或 overfitting 降低。
Week 2Csv-1..16 pilotpaired result table、patch inspection、go/no-go。
Week 3--4扩到 50 bugs若 pilot 有信号，形成 SANER/ASE 级别的最小结果。

读论文时的检查清单

Checklist

每篇 repair 论文都先问这些