当 AI 开始批量制造 PR：开源社区为何对“刷贡献”说不

导语

AI 编程工具正在降低参与开源项目的门槛，但它也带来了一个不太体面的副作用：有人开始把开源仓库当成自动生成贡献记录的场所。项目维护者 Neil Alexander 在博客中公开表达了不满，呼吁那些主要依靠 AI 批量制造 PR、issue 或安全报告来丰富简历的人，不要把这类内容继续投向他的项目。

这并不是对 AI 工具本身的否定。真正引发争议的，是贡献者是否理解自己提交的内容，以及这些提交是否经过实际验证。

一个正在变化的贡献模式

根据维护者的观察，过去一年，外部贡献呈现出几种变化：

• PR 的数量明显多于 issue，贡献行为更偏向直接提交代码；
• issue 中经常附带较完整的 AI 分析，形式上看起来专业，但未必准确；
• 安全漏洞报告比以前更加频繁；
• 漏洞报告后常常附带 AI 生成的修复建议，但建议不一定符合项目实际架构；
• 一些提交似乎更重视“留下记录”，而不是解决经过确认的问题。

这些现象单独看并不意味着提交一定没有价值。AI 确实可以帮助贡献者定位代码、理解陌生项目、整理复现步骤，甚至提出潜在修复方向。但当生成内容未经运行、测试和人工复核就被直接提交，维护者面对的就不再是效率提升，而是一批需要重新筛选的噪声。

为什么“看起来专业”仍然不够

开源贡献的价值不只取决于文字是否完整、代码是否能够编译，关键还在于它是否理解项目的上下文。一个安全报告可能忽略既有的防护机制，一份修复方案可能破坏兼容性，一个看似合理的重构也可能偏离项目长期维护策略。

维护者需要逐条确认问题是否真实存在、修改是否必要、测试是否充分，以及提交是否符合项目的设计原则。如果 AI 生成的内容大量涌入，维护工作就会从“评估少数有价值的建议”变成“替贡献者完成基础验证”。对于依赖志愿者维护的项目而言，这种额外成本尤其明显。

更值得警惕的是，刷贡献会改变开源协作的激励机制。当 PR 的数量被当成能力证明，贡献者可能更关注提交次数，而不是问题质量；当简历把自动生成的修改包装成个人经验，项目维护者就承担了被动筛选和纠错的成本。

AI 时代需要怎样的贡献规范

使用 AI 并不等于低质量贡献。更合理的做法，是把 AI 当作辅助工具，而不是责任的转移工具。贡献者至少应当确认：问题能够复现，修改确实解决问题，相关测试已经执行，并且自己能够解释变更原因。若内容由 AI 协助生成，也应主动说明工具参与程度，并承担后续沟通责任。

项目方面，则可以通过贡献指南、PR 模板和安全报告流程，明确要求复现步骤、测试结果、影响范围以及人工验证情况。对于明显重复、缺少上下文或无法验证的提交，维护者也有必要及时拒绝，而不是为了保持“开放”形象而无限吸收。

这场争议的核心，并不是开源社区要不要 AI，而是贡献是否仍然建立在理解、验证和责任之上。AI 可以让更多人开始接触开源，却不能自动把生成文本变成有价值的协作。对贡献者来说，少提交一些未经核验的内容，往往比批量制造“看起来像贡献”的记录更能证明能力；对项目来说，建立清晰边界则是维持社区信任的必要条件。

来源：OSChina