只验证脚本能 checkout、prompt、apply patch、compile、run tests、保存 receipt。不要在这个阶段下结论。
Software Engineering Empirical Research Radar
Repair 实验设计
先把公平性写死，再让 LLM 开始修。
Repair 实验最容易输在设计，而不是输在模型。初学者常犯的错是：baseline 太弱、反馈轮数不公平、prompt 里泄漏 oracle、最后只报 plausible。下面这套设计是为 SANER/ASE 风格的 pilot 准备的。
RQs
| RQ | 问题 | 主要指标 |
|---|---|---|
| RQ1 | 同预算下，diagnostic advice 是否比 vanilla LLM 修复更多 bug？ | correct、plausible、unique correct、attempts。 |
| RQ2 | diagnostic advice 是否优于普通 Ochiai top-k guidance？ | paired better/same/worse、delta attempts、delta test cost。 |
| RQ3 | 收益来自哪里？定位、上下文、测试反馈、还是减少 overfit？ | compile fail、test fail、patch size、edit location、overfitting label。 |
| RQ4 | 哪些 advice 类型有效？value-route、frontier、chain、failure-conditioned spectra？ | 按 advice family 分层的 paired result。 |
实验组
| Arm | 允许输入 | 公平性控制 |
|---|---|---|
| vanilla | failing test、stack trace、buggy file/function、项目编译命令。 | 不提供 FL ranking 或我们的诊断证据。 |
| Ochiai-guided | vanilla 输入 + statement-level Ochiai top-k，严格 tie-worst 口径。 | 这是必须打过的普通 FL baseline。 |
| feedback-loop | vanilla/Ochiai 输入 + 每轮编译/测试失败摘要。 | 如果我们的 arm 允许反馈，baseline 也必须允许反馈。 |
| diagnostic-advice-guided | vanilla + Ochiai + patch-free diagnostic card。 | 只能给运行事实和定位解释，不能给 gold patch/fault type。 |
最小 Pilot
优先，因为本地已有 statement universe、Ochiai 和 fault mapping 经验。用于看 signal，不要过度调参。
如果 16 个 bug 有信号，扩到 50 个跨项目 bug。用固定 seed 和冻结 budget。
最后才考虑 854 active bugs。此时需要并行、缓存、失败恢复和成本预算。
统一预算
推荐先冻结这些数
- 每个 bug 每个 arm 最多 5 轮 feedback loop。
- 每轮最多 1 个 primary patch + 可选 N 个 sampled patches；所有 arm 相同。
- 每轮最多输入 40k tokens、输出 4k tokens；超过时按固定规则截断。
- 测试顺序固定：compile -> triggering tests -> relevant tests -> full tests。
- 所有输出保存 receipt，不能靠聊天记录复盘。
Correctness 判定
Plausible：补丁通过已有测试。Correct：补丁语义上修对。Correct 至少需要人工审查、developer patch comparison、独立/generated tests 或明确的语义理由。论文表格必须把 plausible 和 correct 分开。