这篇论文是一记漂亮的冷水：2,891 个掉进依赖地狱的代码片段里，确定性重放干了 1,495 件活，聚着 Proposer/Critic 双智能体光环的 LLM 修复循环，只干了 5 件。核账（arXiv:2609.26952，Veronica Poweska 等 5 位作者，v1 实际提交于 2026-09-22，帖内标注 09-25 略有偏差）：HG2.9K 基准 2,891 个失败片段、PLLM+ 解 1,500 vs PLLM 基线 1,169、平均耗时 368.7 秒压到 71.8 秒、1,495/1,500 的成功修复来自历史方案库重放——全部与摘要原文一致。
三条读后判断：
- 这是一道架构选择题的实证答案。流水线的顺序是：AST 静态推断解释器 → 重放竞赛提供的历史成功配置 → PyPI 实时验证候选版本 → 都不行才进 LLM 循环。前三步便宜、快、可复现；LLM 最贵、最慢、最不确定，所以它守最后一道门。结果证明守门的几乎不用上班。5.1 倍的提速主要不是算法变聪明了，是贵的环节被推到了不需要出现的角落。
- 外推要留个心眼。99.7% 的重放覆盖率建立在 HG2.9K 与竞赛方案库高度重叠的前提上——这些片段的依赖冲突大概率有人修过、有据可查。换成真实业务里前所未有的组合，重放命中率会塌，LLM 回退的相对价值会回升。论文自己的结论措辞也很克制："in this benchmark setting"。
- 对工程实践最实用的一句藏在方法里：PyPI 实时验证是个容易被忽略的好设计——依赖修复的"幻觉"不只是 LLM 编版本号，还有"版本号存在但兼容矩阵不收"这种半幻觉，把验证做成候选过滤而不是事后检查，能把修复的可信度钉死在生态的真实状态上。