除非你一直住在后院的老木堆底下，否则你一定看到了代理编码（Agentic Coding）正在如何撼动软件开发世界。事情发生得又快又猛，跟上节奏本身几乎就是一份全职工作。

　　最近一个引起开发者广泛关注的领域，是代理编码如何影响开源社区。多年来，开源运动一直在捍卫人们使用、修改和贡献软件的权利。如今，代理编码正在成为这个过程的一部分。

　　但事情远没有那么简单。

　　一方面，开源项目的维护者被编码代理提交的大量低质量拉取请求（PR）淹没，感到理所当然的沮丧。另一方面，正如DHH（David Heinemeier Hansson）所指出的，维护者开始对接受AI编写的代码产生某种“势利”情绪——认为它在某种程度上不值得被纳入项目。一些组织已经明确禁止AI生成的提交。

　　我理解他们不想让AI“垃圾”淹没输入队列。但我认为彻底禁止AI编写的代码是一个巨大的错误。

　　谁的代码？

　　在深入探讨之前，有必要先看看这个问题引发的另一个核心议题：AI写的代码到底归谁？

　　版权法要求作品必须由人类创作才能获得版权保护。2026年3月2日，美国最高法院拒绝审理Thaler诉Perlmutter案——这意味着，纯粹由AI生成的作品在美国法律下无法获得版权保护。如果你用“给我写一个CMS系统”提示Claude Code，然后一字不改地将输出签入公共GitHub仓库，这代码是否受版权保护并不明确。

　　但如果你向Claude Code提供规范和指南，与Claude协作完善初始结果，在迭代过程中审查并修改代码，那么可以主张人类确实参与了创作。只不过，这在法律上远非明确。完全自主的AI生成代码（无人创造性输入）在大多数司法管辖区处于法律灰色地带。

　　目前的主流观点是：逐字接受简单提示的输出结果不受版权保护，没有人真正拥有这段代码。

　　但这引出了道德问题。如果我在开源项目中发现一个Bug，让GitHub Copilot去修复，Copilot写出了一个巧妙而有效的修复方案——谁在乎代码归谁？ 项目维护者仅仅因为它是AI生成的就应该拒绝这样的PR吗？这看起来很荒谬，但它正在今天发生。

　　我们的代码

　　AI生成代码还涉及许可证合规问题。

　　一般来说，LLM生成代码而非复制代码——它们不会直接从仓库复制粘贴。然而，确实存在AI生成的代码与开源代码高度相似的情况，以至于可以被认定为复制品。如果这种情况发生在GPL代码上，在没有让接收代码库被“感染”的情况下使用它，可能构成许可证违规。

　　更令人担忧的是“Copyleft洗白”（Copyleft laundering）现象。2026年3月，一个LGPL许可的Python库的长期维护者，用Claude Code在约五天内将整个代码库重新生成，并以宽松的MIT许可证发布结果。根据JPlag分析，其与新版本的结构相似度不到1.3%。但原作者并不认同——这不是“净室”实现，因为维护者多年接触LGPL代码，且LLM明确访问了LGPL版本的元数据。自由软件基金会明确指出：“一个吸收了它被要求重新实现的代码的大语言模型，没有什么‘干净’可言”。软件自由保护组织于2026年3月27日宣布对此进行正式分析。

　　学术界已将这种现象称为“Copyleft洗白”——通过AI辅助重新实现来系统性地规避Copyleft义务。

　　这正是为什么许多开源项目对AI生成代码保持高度警惕。许可证合规风险的来源不再是传统的第三方组件，而是“AI生成代码”这一来源不透明的第三方内容。

　　Black Duck的最新研究显示，AI生成的代码可能复制受GPL和AGPL等限制性许可证约束的代码，带来知识产权和许可风险。然而，只有54%的组织在评估AI生成代码时关注IP和许可问题——这个数字低得令人担忧。

　　分裂的开源世界

　　开源社区对AI代码的态度正走向严重的两极分化。

　　一方是“全面禁止派” 。2026年4月初，OpenJDK发布了广泛禁止生成式AI内容的政策：贡献不得包含由大语言模型、扩散模型或类似深度学习系统部分或全部生成的内容。理由是：评审负担过重、安全与保障风险、以及知识产权不明确。即使只修改了100行AI生成代码中的10行，也不能提交。

　　编程语言Zig采取了更严格的政策——不接受任何由大语言模型生成的内容，也不接受由大语言模型改写、润色、编辑、头脑风暴或调试过的内容。Zig创始人Andrew Kelley直言AI辅助贡献是“垃圾”——“有人给我们提交完全没有价值的贡献。它们甚至是负价值，因为会占用团队有限的代码审查时间”。当时Zig还有200个未处理的PR。

　　其他加入“禁止”阵营的还包括：NetBSD（AI生成代码被视为“受污染”产物）、Gentoo（禁止使用自然语言处理工具辅助创建的贡献）、QEMU（拒绝任何被认为包含或源自AI生成内容的贡献）、RPCS3（禁止自主AI智能体）、SDL（明确禁止LLM生成代码）以及OBS Studio（代码必须由人类编写）。

　　2026年1月，cURL关闭了运行六年的漏洞赏金计划，因为安全团队被AI生成的漏洞报告淹没。到2025年底，只有约1/20到1/30的报告是真实的，而一年前这个比例约为1/6。创始人Daniel Stenberg称这是为了“消除提交捏造谎言的动机”。

　　另一方则是“有条件接纳派” 。经过数月激烈争论，Linux内核在2026年4月正式确立了AI代码贡献政策——允许AI辅助编写代码，但所有责任由提交者承担。新规引入“Assisted-by”标签，用于标注AI的参与程度。Linus Torvalds以标志性的直率风格终结了辩论：“AI只是工具，内核应该关注的是约束人的行为，而不是去管别人本地机器上跑了什么软件”。

　　有趣的是，同属Oracle旗下的两个项目采取了截然相反的立场：OpenJDK全面禁止，而GraalVM明确允许AI辅助贡献。GraalVM的政策参考了Linux内核，但要求更宽松——提交的人类贡献者对整个贡献负责，必须评审并理解贡献、验证其正确性。如果贡献者无法解释、辩护或维护某项AI辅助变更，该变更可能被拒绝。

　　Aurelia前端框架则采取了一个更务实的中间立场：“我们关心的只有一件事：最终进入框架及其包中的代码的质量。你是如何做到的，那是你的事。 ”AI辅助的PR不会一开始就被扣分，手写的也不会被自动放行。但他们也强调：“支持AI不是邀请你把生成的代码扔过墙，然后指望维护者来清理”。

　　好的代码就是好的代码

　　归根结底，开源维护者应该关心的是提交的质量和许可证合规性，而不是这些提交是如何得出的。基于代码来源的准入制度，似乎不是项目成功的好路径。

　　好的代码就是好的代码，不管它来自哪里。

　　代理编码已经到来，开源社区需要意识到并拥抱这一必然性。但这并不意味着无条件的接纳——Linux内核的“允许但负责”模式、GraalVM的“贡献者全责”原则、Aurelia的“质量唯一标准”立场，都指向了一条更务实的道路：不是禁止工具，而是约束使用工具的人。

　　开源社区的真正挑战不是“要不要AI”，而是如何在保持质量和合规的同时，不让AI“垃圾”淹没维护者有限的精力。这需要政策、技术和文化的共同演进——而不是简单的一禁了之。

作者：Nick Hodges