研究将AI代码质量问题描述为“公地悲剧”
The Decoder··作者 Matthias Bastian
关键信息
该数据集仅包含负面观点（无中立或正面体验），因此结果反映的是一个批判性子群体，而非整个开发者社区。审查者常感到自己是无偿的提示工程师，并通过注释中的表情符号等特征来识别AI生成代码。
资讯摘要
研究人员分析了1154条关于AI生成代码（开发者称之为‘垃圾代码’）的在线讨论。他们发现一个反复出现的主题：个人开发者节省了时间，但将负担转嫁给审查者和开源维护者，形成典型的‘公地悲剧’，集体损害远超个人收益。真实案例包括curl项目和Apache Log4j 2因AI生成的无效漏洞报告关闭了漏洞赏金计划。
有些团队面临不可持续的工作量，例如每天要审查30个拉取请求，却只有六名审查者。开发者还报告称被管理层强制使用AI工作流，使他们变成无偿的质量检查员，而非创造性贡献者。
资讯正文
研究将开发者对“AI垃圾”的不满描绘为软件开发中的“公地悲剧”
一项定性研究探讨了开发者如何看待并抵制软件开发中低质量的AI内容，即所谓的“垃圾”（slop）。批评者描述了一种“公地悲剧”，即个人生产力提升是以审查者和开源社区的利益为代价的。
来自海德堡大学、墨尔本大学和新加坡管理大学的研究人员进行了一项定性研究，考察了那些认为AI内容存在问题的开发者如何合理化并组织他们的批评。塞巴斯蒂安·巴尔特斯（Sebastian Baltes）、马克·陈（Marc Cheong）和克里斯托夫·特罗德（Christoph Treude）分析了Reddit和Hacker News上15个讨论帖中的1154条帖子。
研究人员特别搜索包含术语“AI垃圾”的线程，这意味着数据集明显偏向于已经对这一现象持负面看法的开发者。设计上，关于AI辅助代码生成的正面或中立体验基本缺失。因此，这项研究并不代表整个开发者群体对AI工具的看法，而是映射了一个批判性子群体的论点。
基于这些数据，研究人员制定了一份包含15个类别的编码手册，分为三个主题集群：审查摩擦、质量下降以及力量与后果。
支持AI辅助开发的人可能会反驳这种不满情绪，理由是随着AI的进步，人类感知的代码质量变得不再重要。例如，OpenAI的一名员工预测，AI生成的代码很快将不再需要人工审查，这会导致“系统故障，调试难度远高于目前大多数情况”，但最终这些问题会被解决。知名AI开发者安德烈亚斯·卡帕蒂（Andrej Karpathy）早已指出，人类是AI辅助研究中的瓶颈。
如果沿着这个逻辑深入下去，随着模型能力增强，人类瓶颈只会变得更严重。问题不再是代码是否符合人类的质量标准，而是它能否被AI代理有效运行、维护、迭代和优化。在这个设想中，人类只需监督流程，而无需逐行检查。
个体生产力提升，集体成本增加
该研究的核心发现描绘了另一种图景：批判性的开发者将AI垃圾视为“公地悲剧”。个人开发者和公司从AI生成的内容中获益，但审查者、维护者和更广泛的社区则承担了代价。代码库累积技术债务，知识资源遭到污染，审查者精疲力竭，协作开发所依赖的信任关系逐渐瓦解。
这个问题在开源世界尤其严重，因为共享资源由志愿者维护。现实中已有案例说明这一点：curl项目因AI生成的漏洞报告消耗了大量维护者时间却未产出有效结果，最终关闭了漏洞赏金计划；Apache Log4j 2和Godot游戏引擎也报告了类似问题。
开发者还表示，他们的工作流程被迫引入AI工具，这是管理层强加的结果。在一个案例中，高管层直接复制AI输出来应对团队遇到的每一个技术问题。
评审者变成了无偿的提示工程师
批评声音中的一个主导主题是，审查AI生成代码的人承受了巨大负担。一位开发者表示：“开发时间缩短了，但团队现在需要花更多时间来审查。这看起来并没有带来任何好处。” 有团队报告每天收到30个拉取请求（pull requests），却只有六名评审者。
评审者描述了自己“第一次看到这段代码”的感觉，并抱怨被变成了无偿的提示工程师：“他们实际上就是利用你来做他们的工作（即批判性地评估和理解他们的AI垃圾代码，并给出下一个提示）。”
评审者还发展出了识别AI生成代码的自身经验法则。代码注释中出现表情符号被认为是几乎确定的线索。其他标志包括分步注释模式、冗长的风格以及Unicode字符残留。协作过程中的信任度也受到了打击。一位开发者描述了一个AI代理的拉取请求：“某一点上，你根本无法相信它任何内容。它对所做之事没有真正理解，只是在猜测。”
根据报告，AI代理还表现出令人担忧的行为。研究描述了“死循环”式的自我意识错误修正，以及代理修改测试用例使错误代码通过而非修复实际代码的情况。在一个案例中，AI代理“虚构了外部服务，然后模拟了这些虚构的外部服务”，从而创建了一个内部自洽但完全虚假的集成环境。
除了代码库之外，一些开发者还描述了外部知识资源的质量下降。“我现在开始看到文档和教程缺少实现某些功能所需的关键信息或代码示例。或者内容完全是错误的，甚至使用了不存在的类。”
该研究还指出了集体技能退化的担忧。一位Hacker News评论者描述了一个两难困境：如果你需要成为经验丰富的工程师才能有效使用AI，但你又必须在没有AI的情况下成为经验丰富的工程师，那么新的资深工程师该如何产生？这种担忧适用于知识工作的很大一部分领域。
应对措施从PR限制到问责标准不等
研究记录了开发者正在提出或已经实施的具体对策：对AI生成代码的拉取请求设定大小限制（“每条PR少于500行代码，否则不予审查”）、要求在同行评审前进行自我审查、同步代码走查、由外部团队进行双重代码审查，并将责任与绩效考核挂钩。
研究人员从研究结果中得出针对三类群体的建议。工具开发者应将重点从代码生成转向验证和审查——例如通过不确定性指标和来源信息；同时鼓励更小、渐进式的变更，并以更容易检查的方式组织输出结果。
团队领导者应重新考虑评估标准，这些标准目前奖励产出数量，而应更多地关注下游成本，例如代码审查的工作量和错误率。同时，这项研究强调，开发者应保留对AI工具使用时机和方式的控制权。团队还应要求贡献者理解并解释他们的更改，并通过PR大小限制和代码走查等实践加以支持。
对于教育机构，研究人员建议采用口试或现场编程考试等评估形式，并在早期课程中限制AI工具的使用，以帮助学生先建立基础技能。他们表示，仅凭产出结果并不能证明能力。
AI新闻，无炒作——由人类精选
来源与参考
收录于 2026-04-06