当你用 AI 修复了一个困扰已久的开源库 bug，并跑通本地测试准备向上游提交拉取请求（PR）时，可能会遇到全新的情况。在过去，项目维护者往往只关注代码能不能跑通，测试是否完备。然而，现在当你提交代码时，系统可能会先弹出一个提示框，要求你做出几项明确的披露与声明。
维护者需要你详细说明：AI 具体用在了哪里？你是否逐行理解了其中的逻辑？你是否愿意为后续可能带来的问题负责？这并非某个开源项目在故意刁难，在这些改动背后，整个开源世界的信任规则正在悄然改变。
有人觉得这是开源社区在抗拒新技术，实际上他们是在保护一条可以追责的贡献链。开源社区开始拒绝没人负责的代码，即便这些代码是用 AI 生成的。项目接受的从来不只是一段 diff，而是一条清晰可追责的贡献链：谁编写、谁理解、谁有权提交、谁能回应日常审阅，以及谁会为之后的缺陷、版权和维护成本负责。AI 降低了代码产出的门槛，但也让这种责任变得稀缺，导致开源项目必须收紧责任入口。
为了保护脆弱的责任链，一些开源社区选择了严厉的限制。在 Zig Code of Conduct 里，官方写明了极具约束力的 AI 禁令。Zig 不仅禁止提交 AI 生成的代码，还禁止利用大模型进行翻译、润色文本和编写文档，甚至寻找漏洞或进行头脑风暴也被列入禁区。在这种环境下，社区和论坛中的 AI 自动回复同样属于违规行为。
这一决策立足于项目的长远发展，而非单纯拒绝技术。维护者不愿为低成本生成的自动化代码做义务测试，更希望通过代码审阅来发掘和培养开发者。每一次代码审阅都是一次深度的对话，维护者需要以此观察贡献者的理解力，确认他们是否理解了项目的核心设计哲学。如果所有提交都由模型代劳，人类只充当传声筒，维护者就无法判断贡献者的真实水平，项目也将失去自我造血的能力。
也有社区在全盘封锁之外，寻找人与工具之间的平衡。Godot Pull Request Guidelines 就展现了温和而务实的态度。虽然官方不鼓励使用 AI 辅助贡献，且会直接拒绝完全由模型自动生成的拉取请求，但如果开发者只是让 AI 辅助思考，并在提交前做了完整的校对与改进，只要在提交时诚实披露，项目依然会予以接收。
为了消除开发者的顾虑，Godot 甚至明确指出，日常使用的单行代码补全或单纯的翻译软件并不在限制范围内。这种机制说明社区并没有工具洁癖，他们支持合规地使用开发工具，但底线是必须有一个具体的贡献者站出来，为每一行提交的代码负责。
对于一些处于底层的系统级项目，对 AI 代码的防守态势极为严密，其核心担忧在于安全和版权。Gentoo Council AI policy 明确禁止贡献由大语言模型辅助创建的内容。大模型生成的代码如同黑盒，缺乏足够的可解释性，加之训练数据来源复杂，极易带来版权和合规纠纷。
虚拟化底层项目 QEMU 在 QEMU Code provenance 中规定，凡是判定为 AI 生成或衍生的内容，一律直接退回。他们要求代码必须有明确的来源，避免因为知识产权背景模糊而给社区带来后续的法律风险。浏览器引擎 Servo AI contributions policy 同样选择将 AI 编写的代码、问题报告以及讨论挡在门外，因为对于容错率极低的基础设施项目，任何隐患都会引发严重的后果。
在数据科学与 Web 开发等中层生态中，NumPy、pandas 和 Django 则是通过更细致的披露机制来绑定责任。在 NumPy AI Policy 中，开发者可以在工作流中引入 AI 助手，但必须在提交描述中详尽说明哪些部分使用了工具。若试图隐瞒使用痕迹，一旦被发现，项目组会直接予以拒绝。pandas automated contributions policy 则强调人工校正的价值，只接受经过人类重写、测试和验证的逻辑，AI 可以生成初稿，但最终提交的内容必须由人类深度确认。
Django AI-assisted contributions 在此基础上，进一步划定了一条防线。Django 允许使用 AI 辅助编写代码并进行诚实披露，但绝对禁止使用 AI 工具自动进行拉取请求的审阅。在维护者看来，自动生成的审阅意见往往包含大量的信息噪音与幻觉，会极大地消耗维护者的有限精力，因此守门的权力必须完好地保留在人类手中。
面对更复杂的商业和技术生态，顶级的开源基金会和巨型基础项目选择通过成熟的制度，将法律与质量责任落实到人。阿帕奇软件基金会（ASF）在 ASF Generative Tooling Guidance 中给出了系统性的指引。他们避开了一刀切的粗暴做法，将焦点放在工具服务条款、第三方材料合规性以及开源许可的兼容性上，建议开发者在满足这些合规条件时进行贡献，并使用标记来说明来源。
作为开源世界基石的 Linux 内核，则展现了更纯粹的契约精神。在 Linux
kernel AI Coding Assistants
指南中，内核社区明确表示不限制开发者使用何种 AI
编程助手，但死死卡住了开发者原创证书（DCO）这一底线。任何向内核提交补丁的人，都必须附上
Signed-off-by
的签名。这一签名不仅是技术标记，更是一份庄严的法律声明，代表提交者对代码的版权和质量承担全部责任。
由于 AI 助手并非法律实体，无法承担责任，因而绝不能在内核中签字。这意味着所有的潜在侵权风险、安全漏洞和维护成本，最终都必须归结到具体的自然人身上。正是凭借这条坚固的责任链条，Linux 内核得以在不排斥 AI 工具的前提下，依然确保庞大项目的安全与合规运转。
这股规则重塑的浪潮，给所有开发者和工程团队带来了明确的信号。习惯了在本地用 AI 快速写好代码、跑通测试便直接提交的开发者，需要调整自己的工作习惯。在未来的开源协作中，开发者提交的不仅是一段跑得通的代码，还有一份沉甸甸的责任凭证。在点击发送之前，我们需要准备好完备的测试记录，写清详尽的修改逻辑，诚实披露 AI 的使用痕迹，并证明自己具备持续回应审阅的能力。
大模型确实解放了生产力，能用极低的成本填满编辑器，但它永远无法在贡献证书上签字，也无法为代码后续的表现买单。将代码的生成交给工具，将代码的责任留给自己。AI 可以写出每一行代码，但真正能向社区做出承诺并承担后果的，永远只有屏幕前的人。