大语言模型写代码：是在真正修复还是在重新实现错误代码？

该 arXiv 论文测试了 LLM 修复代码缺陷的行为特征。作者从 Codeforces 采集约 3000 份用户提交，将每个有缺陷提交与其人工修复配对，以缺陷解与人工修复的相似度作为基线，用 gpt-5-nano、gpt-5-mini、gpt-5.1 生成修复，并用 Codeforces-R1 测试集判断是否真正解题。结果显示，LLM 倾向于修改比人工修复更多的代码行，有时直接生成全新解法；即使允许从零生成，其正确解题数量也高于修补缺陷提交。

此前研究多把解题能力与修 bug 能力分开评估，未考察二者关系。该工作首次以人工补丁为基线，量化 LLM 修复偏离程度，并揭示从零生成比修补更易通过测试，这改变了对 AI 编程工具评估方式的假设。

LLM 可能更擅长按问题描述重新生成完整解法，而非在既有错误代码上做局部增量修改；当被要求打补丁时，它倾向改更多行甚至重写，这与人类最小化改动的修复习惯不同，也说明评测口径会影响结论。

AI 编程助手若默认采用打补丁模式，可能产生更大 diff、增加代码审查与回归测试成本。产品可考虑在调试场景中提供“重写”与“最小补丁”两种模式，并按用户意图切换。

• 在 AI 调试工具中增加“最小修改”约束选项，限制生成 diff 行数并展示与人工补丁的相似度。
• 为代码助手设计“从零重写”与“局部修补”双模式，依据失败原因自动推荐路径。
• 面向团队代码审查流程，输出补丁范围标记和回归风险提示，帮助评审者快速判断改动是否过度。

• 该结论是否可推广到 Codeforces 竞赛之外的真实工程代码库？
• gpt-5-nano、gpt-5-mini、gpt-5.1 之外的其他模型是否呈现相同偏差？
• Codeforces-R1 测试集能否充分代表真实 bug 修复的正确性？
• LLM 修改更多行是否必然导致更高的回归缺陷率？