又有一个知名开源项目对 AI 生成代码关上了门。
发生了什么
据 Hacker News 上的讨论，Linux 发行版 Pop!_OS 背后的开发方 System76 更新了其贡献政策，禁止在项目的大部分代码库中提交由 AI 生成的代码。所谓「大部分」，意味着这一限制并非覆盖全部仓库，而是针对核心代码路径设定了更严格的准入标准——具体哪些模块被纳入、哪些被豁免，需要以项目公开的贡献指南为准。
这不是一次孤立的动作。近一段时间，已有多位开源维护者以不同形式表达过类似立场，从要求贡献者声明代码来源，到直接拒绝 AI 生成的补丁。Pop!_OS 的做法只是把这种零散的抵制，变成了一条写进项目规则的明文条款。
为什么重要
要理解这件事，得先理解开源项目的法律处境。绝大多数开源许可证（如 GPL、MIT）都建立在「贡献者拥有其提交代码的版权，并有权将其授权出去」这一前提之上。而主流 AI 编程助手生成的代码，其训练数据来源、输出与训练语料之间的相似度、以及生成结果是否可被主张版权，至今没有清晰的法律结论。
对下游用户来说，这不是抽象的哲学问题。如果一段 AI 生成的代码被认定与某段受版权保护的代码实质相似，那么把它合并进一个以 GPL 发布的发行版核心组件，可能给整个项目带来许可污染的风险。System76 作为一家销售预装 Linux 硬件的公司，其代码库直接进入商业产品，对这类风险的敏感度自然高于纯社区项目。
另一个层面是维护成本。AI 生成的补丁往往看起来合理，却在边界条件、错误处理和项目约定上存在隐蔽偏差，审查者需要投入更多精力去验证，而贡献者本人可能并未真正理解这段代码。对维护者而言，这稀释了「提交即承诺」的信任基础。
影响与看点
短期看，这条规则的实际约束力有限。AI 生成代码很难被可靠检测，项目方大概率依赖贡献者的自觉声明，而非技术手段。它的真正作用在于表态：把责任明确地放回提交者身上，一旦出问题，项目可以援引规则免责。
对开发者而言，值得关注的信号是「AI 辅助」与「AI 生成」之间的界线正在被项目方主动划分。用 AI 补全一行样板代码，和让模型从头写一个模块，在多数新规里会被区别对待。习惯把 AI 输出直接提交的开发者，需要开始考虑声明来源、人工重写和自测覆盖。
对整个生态来说，这更像是开源治理在 AI 时代的一次压力测试。许可证体系、贡献者协议、代码溯源工具都还没有跟上，项目只能先用最原始的方式——规则和信任——来填补空白。Pop!_OS 的选择未必会成为主流，但它提出的问题，每个维护者迟早都要回答。
