[Paper] 摘要介导的修复：大型语言模型能否将代码摘要用作程序修复的工具？

Source: arXiv - 2511.18782v1

概览

大型语言模型（LLM）能够生成令人印象深刻的代码，但它们仍会在细微的 bug 上出错，这类错误模型往往难以察觉。本文提出 摘要‑介导修复——一种仅通过提示的技术，先让 LLM 用自然语言对有缺陷的函数进行概述，再利用该概述指导修复步骤。作者展示，在多个生产级 LLM 上，这一额外的“思考‑出声”阶段可以适度提升自动程序修复的成功率。

关键贡献

• 新颖流水线：提出一种两步的“先摘要‑后修复”提示，将代码摘要视为显式的诊断产物。
• 实证评估：在两个广泛使用的函数级数据集（HumanEvalPack 和 MBPP）上进行基准测试，涉及八种不同的 LLM，涵盖开源和商业模型。
• 摘要风格分析：比较多种提示风格（普通、错误感知、意图聚焦），发现 错误感知诊断摘要 始终带来最大提升。
• 量化收益：在未见过的 bug 上实现最高 65 % 的修复率，相较直接修复基线平均提升 5 %。
• 实用洞见：表明摘要成本低、可读性强，可直接嵌入现有修复工作流，无需额外训练或模型改动。

方法论

1. 数据集准备 – 作者从两个函数级基准套件（HumanEvalPack 和 MBPP）出发，这些套件包含正确的参考实现以及一组注入的 bug。
2. 提示设计 – 对每个有缺陷的函数，首先给出一个提示让 LLM 生成自然语言摘要。探索三种摘要风格：
   • 普通： “概述此函数的功能”。
   • 意图聚焦： 强调代码的高层目标。
   • 错误感知诊断： 明确要求模型指出代码与预期行为之间的任何不匹配。
3. 修复步骤 – 将生成的摘要（连同原始有缺陷代码）再次输入同一 LLM，使用第二个提示请求给出纠正后的实现。
4. 基线 – 直接修复基线省略摘要步骤，直接让 LLM 一次性修复 bug。
5. 评估指标 – 通过运行每个基准对应的单元测试来判断修复是否成功；当修复后的代码通过所有测试即计为成功。

结果与发现

• 一致提升 – 在全部八种 LLM 中，错误感知诊断摘要带来的提升最大，通常为 3–6 个百分点。
• 上限 – 表现最好的模型（GPT‑4）在使用摘要步骤时可修复 最高 65 % 的有缺陷函数，而不使用时为 60 %。
• 模型依赖性 – 较小或能力较弱的模型提升幅度较小，说明收益取决于模型对摘要的推理能力。
• 整体影响适度 – 虽然提升具有统计显著性，但并非颠覆性；该流水线更像是一个有帮助的“轻推”，而非灵丹妙药。

实际意义

• 可读的诊断 – 生成的摘要可直接展示给开发者，作为快速的 sanity check，提前暴露可能的意图不匹配。
• 即插即用集成 – 由于仅依赖提示工程，可无缝加入现有基于 LLM 的代码助手（如 GitHub Copilot、Tabnine），无需重新训练或修改模型。
• 成本效益的调试 – 摘要生成成本低（单次 token 级推理），可减少修复尝试次数，从而在生产流水线中节省 API 费用。
• 更佳的 CI/CD 自动化 – 在持续集成场景下，摘要步骤可提前标记可疑函数，仅在诊断指示具体缺陷时才触发自动修复机器人。
• 教育工具 – 在学习平台上，先展示摘要再给出修复，可帮助初学者理解高层意图与底层实现的区别。

局限性与未来工作

• 提升上限有限 – 该方法仅能带来几百分点的修复成功提升，无法根本解决 LLM 对低层 bug 的遗漏。
• 模型敏感性 – 在较小或能力不足的模型上收益下降，表明该技术并非对所有模型都通用。
• 提示脆弱性 – 诊断摘要的质量高度依赖提示措辞；未来可探索更系统的提示搜索或 few‑shot 示例。
• 向更大代码库的可扩展性 – 实验局限于单函数片段，如何将流水线扩展到多文件或类级别的修复仍是未解挑战。
• 用户研究 – 本文未评估开发者实际与生成摘要的交互方式；后续工作可衡量真实环境下的生产力提升。

结论：摘要‑介导修复提供了一层低成本、友好的人类可读诊断，能够轻推基于 LLM 的代码助手产生更好的修复，但应被视为对程序修复可靠性的补充工具，而非完整解决方案。

作者

• Lukas Twist

论文信息

• arXiv ID: 2511.18782v1
• 分类: cs.SE
• 发表时间: 2025 年 11 月 24 日
• PDF: Download PDF