Can LLMs be Effective Code Contributors? A Study on Open-source Projects
这项研究通过对八个知名开源项目进行实验，评估了三种主流大语言模型在修复漏洞和添加功能方面的表现，结果表明 LLM 在处理复杂上下文、生成新代码及通过验证方面仍存在显著局限性，目前尚无法成为生产级代码的有效贡献者。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
🎭 背景设定：AI 实习生入职测试
想象一下，你是一家顶级软件公司的技术主管。现在，公司决定招募一批“AI 实习生”（比如 GPT-4o, Ministral3, Qwen3-Coder）来帮忙修 Bug 和写新功能。
这些项目（比如 FFmpeg）就像是极其复杂的精密钟表，里面有成千上万个齿轮（代码行）紧密咬合。如果实习生不小心多装了一个零件，或者把一个齿轮磨损了，整块表可能就会停摆。
研究人员做的，就是给这些 AI 实习生布置了 212 个真实的“工作任务”（这些任务都是人类程序员曾经做过的真实工作），然后看他们表现如何。
📉 考试结果：看起来很努力，其实“坑”很多
研究发现，这些 AI 实习生的表现可以用**“眼高手低”**来形容。虽然他们写代码的速度极快，但结果却让人捏把汗：
1. “幻觉”带来的低级错误（脑补型选手）
有些 AI 实习生在写代码时会**“一本正经地胡说八道”**。
- 比喻： 你让实习生去仓库拿一个“10号扳手”，他跑回来拿了一个根本不存在的“幻影扳手”，还一脸自信地告诉你：“这就是你要的。”
- 论文表现： 他们经常使用一些代码库里根本不存在的变量或函数（即“未声明的标识符”），导致代码根本无法运行。
2. “修了东，坏了西”（拆东墙补西墙）
有些 AI 实习生在修一个 Bug 时，会不小心把原本正常的代码给删了。
- 比喻： 就像你让修理工修一下漏水的龙头，结果他为了不让水漏出来，直接把整个水管给锯断了。
- 论文表现： 出现了“删除无关代码”的情况，导致原本好好的功能突然罢工。
3. “半吊子”修复（敷衍型选手）
有些任务需要修好三个地方，AI 只修了一个。
- 比喻： 医生让你缝合三处伤口，AI 实习生只缝了一处，然后拍拍胸脯说：“好了，治愈了！”
- 论文表现： 这被称为“部分修复”（Partial Fix），虽然看起来改了，但隐患依然存在。
🔍 核心发现：什么决定了 AI 的表现？
研究人员总结了几个影响 AI 表现的“潜规则”：
- “书读得越多，越容易迷糊” (上下文长度问题)：
如果任务所在的“说明书”（代码文件）太厚，或者要修改的“零件”（函数）太复杂，AI 就会开始犯迷糊。文件越长，AI 越容易迷失在细节里。 - “见过题型很重要” (知识截止日期问题)：
如果这个 Bug 是在 AI “学习期”之后才出现的，AI 的表现会大幅下降。这说明他们很多时候是在**“背题”，而不是真的在“思考”**。 - “写新功能比修 Bug 容易”：
让 AI 从零写个小工具（新功能）比让它在复杂的旧机器里找漏水点（修 Bug）要容易得多。
💡 给人类主管的“避坑指南”
既然 AI 实习生这么不靠谱，我们还能用他们吗？论文给出了几条建议：
- 别给太大的任务： 尽量把任务拆解得很小，给 AI 提供的“参考资料”（上下文）也不要太厚，否则它会“大脑过载”。
- 重点盯着“修 Bug”的任务： AI 写新功能还行，但修 Bug 时一定要安排资深员工进行**“地毯式检查”**，因为它们最容易在修 Bug 时引入新的安全漏洞。
- 不要盲目信任测试结果： 有时候 AI 写的东西虽然通过了简单的测试，但可能只是因为它“绕过了问题”，而不是真的解决了问题。
📝 总结
这篇文章用大白话告诉我们：
目前的 AI 程序员还只是**“初级助手”，甚至有点“捣蛋鬼”**的潜质。它们可以帮你写写简单的脚本，但如果你想让它们直接接管复杂的工业级项目，那可能会引发一场“代码灾难”。人类程序员，依然是那个最后把关的“总工程师”。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。