GitHub 412个仓库实测：AI编程工具让代码返工量暴涨47

GitHub上有412个开源仓库悄悄用上了AI编程助手，它们的代码提交记录被完整扒了下来。研究人员对比了这些仓库在"拥抱AI前"和"拥抱AI后"的每一项指标——结果和硅谷吹的牛皮，不太一样。

数据怎么来的：从CLAUDE.md文件顺藤摸瓜

研究团队用Google Dorks搜到了412个包含CLAUDE.md或AGENTS.md的仓库。这两个文件是AI代理工具的"说明书"，意味着项目已经深度集成了Claude、Cursor这类工具。

他们用NeoRepro工具把每个仓库的提交历史抽成了图数据库。每一次代码修改、每一行增删、每一个文件变动，都被记录在案。数据跨度覆盖AI工具引入前后的完整周期，确保对比有说服力。

筛选标准很严格：仓库至少要有200次提交，AI引入前后各保留至少3个月数据，排除个人玩具项目。最终有效样本的统计效力足够支撑结论。

核心发现：产量上去了，质量没跟上

AI工具确实让开发者写代码更快了。引入AI后，每周代码提交频率平均提升23%，单次提交修改的文件数增加31%。直观感受就是：同样时间能堆更多代码出来。

但代码返工率（Code Churn）同步飙升。研究用"同一文件在两周内被反复修改"作为返工指标，发现AI组比对照组高出47%。换句话说，AI生成的代码有接近一半需要短期内回炉重造。

更细的数据拆解显示问题所在。新增代码与删除代码的比例（add_delete_ratio）在AI组明显失衡——开发者倾向于大量生成新代码，而非重构旧代码。技术债务在看不见的地方累积。

「我们假设AI工具能提升生产力，但也猜测会增加返工量。」论文作者Andrew Rutherfoord在研究中写道。两个假设都被证实了，这不是非此即彼的选择题。

为什么AI代码更"脆"？

一个可能的解释是认知负荷转移。开发者把更多精力放在"描述需求"和"挑选AI生成的选项"上，对代码本身的理解深度下降。当需求微调或边界情况出现时，不得不推翻重来。

另一个因素是反馈循环变短。AI让"写代码"变得廉价，开发者更频繁地提交半成品，依赖后续迭代修正。传统开发中会在脑子里多过几遍的逻辑，现在被外包给了Git历史记录。

GitHub上的真实行为数据印证了这一点：AI组的提交粒度更细，但单次提交的代码稳定性更差。就像工厂把质检环节从生产线末端挪到了客户手里，数字好看，体验打折。

这对团队管理者意味着什么

研究没有给出"用还是不用"的二元答案，但划出了几个需要重新校准的指标。如果你还在用"代码行数"或"提交次数"考核开发者，AI工具会让这套体系彻底失真。

代码返工率应该进入核心看板。不是作为惩罚依据，而是识别"AI生成-人工修补"模式健康度的早期信号。当某个模块的返工率持续高于团队均值，说明AI的上下文理解出了偏差，或者人的介入时机不对。

更隐蔽的风险是技术债务的滞后性。研究追踪的是短期返工，但设计缺陷的代价往往在数月后才显现。AI加速的不仅是功能交付，也可能是烂摊子的堆积速度。

论文最后抛出一个开放问题：当AI能生成无限量的"看起来对的代码"，开发者的核心技能会不会从"写代码"转向"验代码"？而验证能力，恰恰是这项研究里暴露出来的短板。