Theo 谈 Codeberg 的 AI 代码限制与开源未来

我最近给 Codeberg 捐了几千美元，还鼓励大家把它当作 GitHub 的替代品。如今会员投票决定限制主要由生成式 AI 编写的项目，我对此很失望。我支持独立的开源基础设施，正因如此，这个决定才让我在意。

Codeberg 是由社区运营的开源项目托管平台。我原以为这里能避开大型商业平台的问题，但这条规则让我担心：它按软件的制作方式排除人，而不是看项目和贡献是否有价值。

讨论之前先说清楚：不要骚扰参与此事的志愿者或会员。他们花自己的时间维护了一个我也受益的平台。我们可以反对政策，但这不是攻击制定者的理由。

我先看一篇社区讨论，作者主张禁止 AI 生成内容。这是参与者的提议，本身并不是平台已经采纳的政策。但它显示了这场争论背后的强烈情绪，也展示了对低质量贡献的担忧怎样迅速扩大成更宽泛的禁令。

问题并不是每一处 AI 生成的修改都好，而是使用 AI 是否就足以让一个项目不值得被托管。我认为工具可以帮助人编写和审查代码；判断产出及维护者的行为，比单看用了什么工具更合适。

Codeberg 是会员组织，依靠志愿者运作，能力有限，也有自己的治理方式。我欣赏它公开讨论和投票；但过程透明并不意味着我必须赞同结果，社区投了票也不意味着政策后果就不再重要。

我不认同一种假设：AI 辅助完成的工作就不可能是真正的开源工作。即使大量代码出自助手，项目仍可能有人类维护者负责，也可能存在有意义的协作；反过来，纯人工编写的项目也可能维护得很差。

围绕这场争论的一些评论，让原本愿意支持 Codeberg 的人感到沮丧。我不认为 AI 上的分歧足以让人否定他们，或假定每个使用这些工具的开发者都有恶意。

官方公告介绍了会员的两项决定：承诺不将托管内容用于训练语言模型，以及拟修改条款，限制主要由生成式 AI 编写代码的项目。这是两个不同的问题：保护托管内容不被用于训练，与决定允许托管哪些项目，并不是一回事。

关于托管限制的投票以 358 票对 144 票通过。我不赞同这个结果，但这代表参与投票的会员，而不是所有开源开发者。我的观众投票同样有自选偏差，也不能证明整个社区的态度。

拟议文字针对主要由生成式 AI 编写的代码构成的项目，并非全面禁止任何 AI 使用。Codeberg 的说明表示，执行方式仍待制定；早期例子区分了已有社区维护的项目，以及某些高度自动化或资源消耗很大的用法。详见 [Codeberg 公告](https://blog.codeberg.org/protecting-our-floss-commons-from-llms.html)。

我认为 AI 也能改善软件：它可以帮助人读懂陌生代码、寻找问题，让更多人有机会参与开发。这些是潜在收益，并不能证明生成代码一定安全，也不能让项目省去审查。政策问题在于如何处理不良后果，同时避免排除有价值的使用。

志愿者提出的问题值得认真对待。自动爬虫可能给服务造成压力，大量表面的机器生成 issue 或补丁，也会迫使维护者花时间审查连提交者自己都不理解的内容。开源维护者没有义务接受这样的贡献。

Codeberg 还提到，非常大的 AI 相关仓库和不活跃项目会占用存储与持续集成资源。靠捐款和志愿劳动运营的服务不能假设基础设施无限；托管仓库有持续成本，贡献者未必能直接看到。

我同意 Codeberg 应能阻止滥用式抓取、限制资源消耗，并拒绝大量低质量提交。我更希望规则针对这些具体行为和成本。若按 AI 编写代码所占比例划线，可能把有价值的项目也一并排除。

计算资源和开发机会并不均等。我担心，围绕每行代码由谁写成制定规则，会让缺少时间、经验或资源的人更难参与。更好的问题是：是否有人愿意理解并维护这个项目。

公告还提到 AI 基础设施的环境成本。我质疑这些成本如何与计算资源的其他用途比较，以及托管禁令是否是合适的回应。讨论应依靠测量，而不是预设 AI 可以无限增长，或预设它毫无影响。

我在视频中认为数据中心冷却大多循环用水，影响常被夸大。这个说法过于笼统：冷却方式各不相同，蒸发冷却会消耗水。[美国能源部](https://www.energy.gov/cmei/femp/cooling-water-efficiency-opportunities-federal-data-centers)介绍了蒸发损耗；[国际能源署](https://www.iea.org/reports/energy-and-ai/executive-summary)估计，2024 年全球所有数据中心用了约 1.5% 的电力，各地影响不同，这个数字并非仅指 AI。

我更希望看到对清洁能源和高效基础设施的投资，而不是先认定某一类软件工具必须被排除。环境取舍是真实存在的，但降低影响的方法应该与实际的电力和用水需求相联系。

我提到德国的能源选择，作为这些取舍有多困难的例子。我对相关选择的批评属于个人观点，不能单凭这一点就推断某个 Codeberg 项目或模型的排放和用水影响。

公告的另一个担忧是，智能体生成的软件可能缺少真正的社区。我认为，一个项目即使用 AI 辅助起步，也仍然可能成为人们协作的地方。项目历史、人的维护责任和实际互动，比简单贴标签更重要。

信任确实是问题。维护者需要知道贡献者理解了修改，并愿意对其负责。如果有人几秒钟生成一大段补丁，却让维护者独自发现问题，看似提高的效率只是把工作转嫁给了别人。

我理解维护者被低质量提交淹没时的处境。项目可以明确贡献要求、关闭不合格报告，并要求作者测试和解释补丁。这些边界能保护维护者，同时不必由平台认定所有大量使用 AI 的项目都没有价值。

讨论也涉及许可问题：生成内容可能与已有作品相似，人们担心来源和许可义务。这些问题值得关注，但这场讨论并不能证明每个 AI 辅助项目都会自动违反许可证。

执行还面临一个实际难题：托管平台如何可靠判断代码库中有多少比例由模型编写？我担心错误指控、随意裁量，以及维护者被迫证明自己没有做某件事。政策如何执行，与它的初衷同样重要。

Codeberg 从自由软件、协作和珍惜共享资源的角度解释立场。我也希望社区健康，但对工具得出了不同结论。开放协作可以包括人对借助工具产出的代码承担责任。

博客中的初步、非正式执行说明很重要。它表示，已有社区维护的项目，包括偶尔接受生成式贡献的项目，通常较不受影响；轻量级个人项目虽不受鼓励，但很可能获容忍。这是指导性说明，并非对每个个案的保证。

可能不再受欢迎的例子包括大量由自主智能体生产的项目、反复使用大语言模型的情况、资源需求过高的项目，以及违反项目自身规则的贡献。这些例子不等于某类项目都会立即被自动封禁。

即使考虑这些限定，我仍对这个方向感到失望。关心开源替代方案的开发者应该可以讨论平台的选择，而维持平台运转的人也有权为服务能承受的范围设定限制。

我回到开源的含义：分享代码，让别人可以查看、修改并在其上构建。在我看来，因为开发工具而排除项目会让社区变得更狭窄。托管平台的条款与具体开源许可证授予的权利是不同的，尽管两者都会影响项目的托管。

AI 与开源贡献的争论不会因为一次投票而结束。维护者有权要求有意义、可审查的贡献；贡献者也应该能够负责任地使用工具。难点在于如何制定并执行同时兼顾两者的规则。

目前我仍对 Codeberg 的决定感到失望，也会考虑其他选择，包括自行部署 Forgejo。我依然珍视提供开放基础设施的人，希望讨论能够聚焦于政策及其后果。