摘要ChatGPT、Codex等AI编程工具降低了写代码和提交PR的门槛但也让部分开源项目收到大量未经验证、贡献者自己都无法解释的代码。越来越多项目开始禁止、限制或要求披露AI辅助内容。本文分析背后的原因并整理使用AI向开源项目提交代码前必须注意的5件事。以前给开源项目提交一次PR通常要先阅读文档、理解代码、复现问题再完成修改和测试。现在使用ChatGPT、Codex等工具后只要描述需求AI就可以搜索项目、修改文件、生成测试甚至整理提交说明。效率确实提高了但问题也随之出现贡献者没有真正理解修改内容代码看起来完整实际上调用了不存在的接口一次修改几十个文件给维护者带来巨大审核压力PR被指出问题后提交者无法解释或继续维护AI生成内容的版权和代码来源无法确认。因此部分开源项目已经开始为AI辅助贡献设置更严格的规则。Godot明确禁止完全由AI生成的贡献并要求代码主要由人类编写QEMU目前会拒绝被认为包含或源自AI生成内容的贡献NetBSD将大模型生成代码视为存在来源风险未经核心团队书面批准不得提交Zig社区则实行非常严格的“禁止LLM内容”规则。不过这并不代表整个开源社区都在全面拒绝AI。Linux内核目前允许AI辅助贡献但要求人类提交者完成审查、承担全部责任并通过Assisted-by标记披露使用的工具。也就是说争议的重点并不是“能不能用AI”而是提交者是否真正对结果负责。一、为什么部分开源项目开始限制AI代码1. 生成代码很快审核代码却没有变快AI可以在几分钟内生成一个看起来完整的PR但维护者仍然需要逐行检查修改是否真的解决问题是否破坏已有功能是否符合项目架构是否存在安全漏洞测试是否真实有效后续是否容易维护。提交者可能只花十分钟生成代码维护者却要花几个小时审核。对于主要依靠志愿者维护的开源项目来说大量低质量PR会迅速消耗有限的审核资源。近期一项针对开源社区的研究把这种现象称为“AI-DDoS”生成成本下降后大量看似合理但质量不足的贡献不断涌入最终挤占项目的正常维护能力。2. 提交者自己也不理解代码开源项目的代码审查通常不是简单回答“能不能合并”。维护者可能会继续追问为什么选择这种实现为什么修改公共接口这个条件判断覆盖了哪些场景是否考虑线程安全为什么要增加这个依赖出现回归问题后怎么处理如果提交者只是把维护者的问题复制给ChatGPT再把AI生成的回复粘贴回来整个沟通过程就失去了意义。维护者需要的是能够理解代码、解释设计并继续维护的人而不是一个负责转发AI答案的账号。3. AI容易生成“看起来正确”的错误代码AI生成代码最麻烦的地方不一定是明显的语法错误而是那些表面合理、实际有问题的实现。例如调用项目中不存在的方法根据旧版本文档生成代码忽略项目特有的边界条件重复实现已经存在的功能为简单问题增加复杂抽象测试只验证正常流程修复当前Bug时引入新的回归问题。这些代码通常可以通过简单检查甚至能够在本地运行但不一定适合长期合并进项目。4. 代码来源和许可证难以确认开源项目不仅关心代码能不能运行还要确认代码来源是否合法。很多项目要求贡献者通过开发者原创声明也就是DCO确认自己有权提交相关代码。QEMU限制AI生成内容的重要原因之一就是当前很难明确判断模型输出的版权来源以及它是否与项目许可证兼容。即使AI没有直接复制某个项目的代码贡献者也很难证明生成结果完全不存在许可证风险。5. 合并代码意味着长期维护一次PR被合并后影响的不只是当前版本。未来可能还需要修复兼容问题适配新版本处理安全漏洞补充文档回答其他开发者的问题重构相关模块。如果提交者不了解代码也不准备继续维护那么所有后续成本都会转移给项目维护者。这也是为什么很多项目宁愿拒绝一个“暂时能运行”的AI生成PR也不愿意接收无法持续维护的代码。二、使用ChatGPT和Codex提交代码前要注意5件事1. 先阅读项目的AI贡献政策不要默认所有开源项目都允许使用AI。不同项目的规则差异很大有些完全禁止AI生成代码有些允许少量代码补全有些要求主动披露有些只允许修改已经确认的问题有些允许AI辅助但人类必须承担全部责任。提交之前至少要检查CONTRIBUTING.mdPull Request模板Code of Conduct开发者文档仓库中的AI PolicyIssue或邮件列表中的相关讨论如果项目已经明确禁止就不要抱着“应该检测不出来”的想法提交。隐瞒AI使用即使暂时通过审核一旦被发现也可能影响账号信誉。2. 确保自己能够解释每一处修改使用ChatGPT或Codex完成修改后不要马上提交。先逐个文件检查为什么要修改这个文件每个新增方法负责什么修改会影响哪些旧功能是否存在更小的实现方式删除某段代码会不会产生副作用新增依赖是否真的必要。一个简单的判断方法是如果维护者针对任意一行代码提问我能不能不用再问AI直接解释清楚如果答案是否定的说明这次修改还不适合提交。AI可以帮助写代码但PR的实际作者仍然应该是能够理解并负责的人。3. 不要让AI一次修改太多内容AI工具很容易把一个小问题扩大成大范围重构。原本只是修复一个参数判断最后却可能变成修改公共接口调整多个文件更换数据结构新增工具类重命名大量方法顺便格式化整个项目。这种PR即使代码没有问题维护者也很难审核。开源项目通常更欢迎修改范围小目的明确一个PR只解决一个问题不夹带无关重构能够独立测试和回退。给Codex下达任务时可以明确限制只修复当前Issue描述的问题不修改公共接口不新增第三方依赖不格式化无关文件。修改前先列出涉及的文件和原因。范围越清楚最终PR越容易被维护者接受。4. 必须自己运行测试和检查差异不能因为ChatGPT生成了测试就默认修改已经可靠。提交前至少应该完成项目原有测试新增功能测试边界条件测试静态代码检查格式和代码规范检查Git Diff人工检查。重点观察是否修改了无关文件是否删除必要的异常处理是否加入不存在的API是否留下调试代码是否写死路径、密码或密钥是否为了让测试通过而修改测试预期是否出现大量无意义注释。测试全部通过也只能说明当前用例没有发现问题不能证明代码一定正确。5. 按项目规则披露AI使用情况如果项目允许AI辅助但要求披露就应该如实说明。可以在PR中写清楚使用了什么工具AI主要完成了哪些工作哪些部分经过人工修改执行了哪些测试自己如何验证代码是否存在仍需维护者关注的风险。例如本次修改使用Codex辅助搜索相关调用位置并生成初始补丁。所有改动已由本人逐行检查并根据项目规范重新调整。已运行现有测试和新增边界测试未发现回归问题。Linux内核的现行指导也强调AI不能代替人类签署DCO最终提交者需要审查代码、确认许可证要求并承担全部责任。披露AI并不一定会导致PR被拒绝。真正容易引起维护者反感的是代码明显由AI生成提交者却试图隐藏而且无法解释具体实现。三、ChatGPT和Codex更适合怎样参与开源项目AI工具并不是只能用来生成完整代码。在开源贡献中它们更适合承担一些辅助工作帮助理解项目目录查找函数和字段引用解释陌生代码整理Issue中的复现步骤生成初始测试思路检查遗漏的边界条件总结Git Diff对照贡献规范检查PR。这些工作能够提高效率同时不会完全把设计、判断和责任交给AI。对于重要修改比较稳妥的流程是人工理解问题 → AI辅助分析 → 小范围修改 → 人工审查 → 运行测试 → 按规则披露 → 提交PR而不是把Issue丢给AI → 自动修改整个项目 → 直接提交PR四、提交PR前的简单检查清单提交之前可以快速确认以下问题我是否阅读了项目的贡献规范项目是否允许AI辅助内容我能否解释每一处代码修改这次PR是否只解决一个明确问题是否运行了原有测试和新增测试是否查看了完整Git Diff是否存在无关重构或新增依赖是否需要披露ChatGPT或Codex的使用出现问题后我是否愿意继续修改和维护只要其中有几项无法确认就不适合急着提交。总结部分开源项目开始拒绝AI生成代码并不是简单排斥ChatGPT、Codex或其他AI编程工具。真正让维护者担心的是低质量PR大量增加审核成本全部转移给维护者提交者不了解自己提交的代码代码来源与许可证不明确合并后无人承担长期维护责任。不同项目的态度并不相同。有些项目完全禁止AI内容有些要求严格披露也有项目允许使用AI但坚持由人类审查和负责。使用ChatGPT或Codex参与开源项目时最重要的不是隐藏AI痕迹而是确保自己真正理解代码、完成测试、遵守规则并愿意为提交结果负责。