当AI能写出可用的补丁，开源社区该不该收？一个项目的分叉给出了它的答案。
发生了什么
据 Hacker News 上的讨论，一个开源项目的维护者拒绝了由 AI 生成的代码贡献（contribution）。随后，社区中有人将该仓库分叉（fork），并在分叉版本中加入了视频加速（video acceleration）相关的功能。事件本身并不复杂：贡献被拒 → 代码被另起炉灶 → 分叉版本补齐了原项目没有的能力。讨论热度不高，但它触及的是一条正在变宽的裂缝。
为什么重要
开源协作的默认假设，是“补丁即价值”——只要代码能跑、能通过测试、能解决问题，来源并不重要。AI 编程助手普及之后，这个假设开始松动。维护者拒绝 AI 贡献，动机可能有很多：无法确认代码的版权与许可来源、担心贡献者并不理解自己提交的内容、审核成本高于自己重写、或单纯对“AI 生成”这一标签持保留态度。这些理由在治理层面都站得住脚，但它们与贡献者的预期发生了正面冲突。
分叉是开源给出的传统解法：既然共识无法在原仓库内达成，就带着代码离开。值得注意的是，这次分叉不只是“复制一份”，而是顺手加上了原项目缺失的视频加速。这意味着分叉的动机可能不止于抗议——有人本来就想要这个功能，AI 贡献被拒只是提供了一个契机。
影响与看点
对维护者而言，这是一个信号：拒绝 AI 贡献的代价，可能不是“少一个补丁”，而是“多一个竞品分叉”。当被拒的代码本身具备实用价值时，社区会用脚投票，把价值转移到别处。
对开发者而言，值得关注的是贡献流程本身。如果项目没有明确的 AI 贡献政策——是否接受、是否需要标注、是否要求贡献者能解释每一行——那么每一次 AI 提交都会变成一次临时裁决，既消耗维护者精力，也消耗贡献者的耐心。把规则写清楚，比逐个拒绝更省事。
对用户而言，短期内可能受益：分叉版本提供了视频加速，等于多了一个选择。但长期看，碎片化会带来维护分散、生态割裂的问题，尤其是当分叉只为了一个功能而存在时。
一个独立的判断：AI 代码贡献的争议，本质上不是技术问题，而是信任与治理问题。项目迟早需要像对待许可证一样，明确对待 AI 生成内容——否则分叉会成为默认的解决方式，而分叉从来不是零成本的。
