AI 原生开源 — 与 AI 共创开源

自 2025 年 2 月 Andrej Karpathy 提及“Vibe Coding”问题以来，一年后的今天，AI 已经给软件开发带来了根本性的变革。这使得许多因 AI 而获得巨大机遇的软件公司面临着巨大的危机。

2025-2026 年，开源生态系统面临着前所未有的危机。

开源瓦解的三个原因

1. 悄无声息的剥削 — 无人问津

GitHub 将 AI 时代的开源危机称为 “永恒的九月”。

永恒的九月：1990 年代初，Usenet 是一个以大学生为主的社区。每年九月，新生涌入并发布低质量帖子，但现有用户会进行指导，一两个月后便恢复正常。然而，1993 年 9 月，当 AOL 向公众开放 Usenet 后，“九月”便永远没有尽头了。

然而，真正的危机并非 AI 垃圾 PR 的泛滥。而是根本没有人来。

AI 已经学习了开源代码。开发者没有理由访问仓库，没有理由阅读文档，没有理由开启 Issue，也没有理由发送 PR。因为只需一句“帮我做这个”，AI 就能在开源的基础上生成结果。

使用量暴增，但社区却成了鬼城。

arXiv 论文 2601.15494 的结论：Vibe Coding “使用”OSS，但不会阅读文档、报告 bug 或参与社区。

开源的基本前提——“开放即回报”——正在瓦解。一个通过抄袭获得的效用大于通过开放获得的效用的时代已经到来。

2. 社区的悖论 — 贡献者越多，速度越慢

传统的常识是“贡献者越多，项目进展越快”。现实却恰恰相反。Fred Brooks 早在 1975 年就已证明——“增加人手会使项目变慢。” 因为沟通成本会随着人数的平方增长。

贡献者越多，审查、协调和决策的成本就越高。维护者将时间花在管理人员上，而不是编写代码。在 AI 时代，这个问题被极端放大——用户通过 AI 悄无声息地获取，而剩下少数的贡献只会增加协调成本。

最终，独自与 AI 协作比与社区协作更快的情况出现了。

3. 防御也并非答案

因此，许多项目开始关闭。curl 在 21 天内收到了 20 份 AI 生成的报告，其中 0 份有效——最终停止了运营 6 年的 bug bounty；Ghostty 引入了零容忍政策，只允许在已批准的 Issue 中进行 AI 贡献；tldraw 则完全禁止了外部 PR。

阻止 PR 可以防止 AI 垃圾。但问题 1 和问题 2——悄无声息的剥削和社区成本——并未解决。即使关闭，AI 也已经学习了代码，用户仍会在仓库外部继续获取。

行业的反应分为两类：

• 防御：Vouch（信任管理）、PR Kill Switch、强制公开 AI 使用 + 拒绝
• 接受：GitHub Agentic Workflows、AGENTS.md 标准（6 万+ 项目采用）、Responsible Vibe Coding Manifesto

双方都同意一点：AI 本身不是问题，错误使用 AI 才是问题。但双方都未能给出“开放的效用 < 抄袭的效用”这一问题的答案。

然而，每次都从头开始是答案吗？

有人主张，“如果 Vibe Coding 成为主流，按需开发就会到来”——因为需要时只需让 AI 创建即可，这将成为计算和应用程序的主流。

但这是一种巨大的资源浪费。

1 万人分别要求创建相同的功能。会产生 1 万份未经验证的代码。如果出现安全补丁呢？1 万人必须各自重新创建。如果需要改进架构呢？从头开始。测试？没有。每次都从零开始创建，无论 AI 多快，都是一种浪费。

已经有许多制作精良的开源项目。经过验证的架构、数千个测试、多年的安全补丁历史。这些都不是一句“帮我做”就能重现的。积累的价值在 AI 时代也不会改变。

有人说，超级个体时代已经到来。因为 AI 辅助，一个人也能创造出伟大的东西。这是对的。但是，多个超级个体分别创建相同的东西会更有效率吗？超级个体们共同为一个开源项目贡献难道不会更有效率吗？

最终，答案又回到了开源。问题不是“是否要开源”，而是“在 AI 时代如何做开源”。

Naia OS 的选择：与 AI 共同设计

如果维护者使用 AI，贡献者也使用 AI，会怎么样呢？

如果 AI 能够代理传统开源中作为成本的沟通——Issue 分类、PR 审查、翻译、协调——那么是否就能打破“贡献者越多，速度越慢”的悖论呢？

Naia OS 为了验证这个假设，选择了截然不同的道路。

“不要阻止 AI，而是与 AI 共同设计和开发。”

上下文即基础设施 — 开源的 AX

正如企业进行 AX (AI Transformation) 一样，开源也需要 AX。即将社区（组织）和代码+上下文（基础设施）这两个轴心，转换为 AI 可以参与的形式。

从社区方面来看——传统开源的沟通全部是人与人之间。如果在 AI 时代，这种成本成为问题，那么就需要改变组织，让 AI 能够代理沟通。

从基础设施方面来看——传统开源只有供人阅读的文档。README、CONTRIBUTING、Wiki。即使 AI 阅读这些，也无法理解项目的哲学、架构决策的背景、贡献工作流。这就是 AI 生成的 PR 变成垃圾的原因。

.agents/ 目录就是为了解决这个问题而创建的。它将项目的规则、架构、工作流以 AI 可读的结构化形式存储在仓库中。如果这些内容足够丰富，AI 就能在理解项目的情况下编写代码、指导贡献者并保持质量。这不再是“从头开始创建”，而是**“理解并共同创建”**。

Naia OS 的实际做法

消除语言障碍 — 以前我曾尝试为 Mozilla Hubs 贡献。阅读代码和创建 PR 没问题，但跟进社区讨论或参与在线会议是另一回事。时区不同，快速的英语对话听不太懂，总担心会不会给别人添麻烦，自己是否真的理解了——我常常有这样的想法。如今，人们也越来越不愿直接面对面交流。在 Naia OS 中，贡献者可以用母语编写 Issue 和 PR，由 AI 进行翻译。目前，14 种语言的 README 正在同步维护中。(→ 贡献指南)

质量由结构保障 — .agents/ 上下文训练 AI，CI 验证构建和测试，AI 审阅者捕捉模式违规，维护者只需把握方向。如果前期阶段强大，维护者的负担就会减轻。(→ 运营模型)

代码并非唯一贡献 — 共有 10 种贡献方式，包括翻译、文档、设计、测试，以及改进 .agents/ 上下文本身。上下文越好，所有 AI 贡献者的质量都会随之提升。(→ 贡献类型)

测试 AI 是否真正理解 — 我们在一个新会话中将 Codex CLI 和 Gemini CLI 投入到仓库中，并验证它们在只阅读 .agents/ 上下文的情况下是否正确理解了项目。12 个测试中，7 个通过，4 个部分通过，1 个失败。有趣的是，AI 发现了人类遗漏的文档矛盾。(→ 完整设计报告)

近未来会迎来 AI 主导的开源生态系统吗？

开源的“开放即回报”这一前提对人类而言正在动摇。人类被推向竞争，不再直接编码，从而失去了为开源贡献的理由。那么，如果将开源理念灌输给编码 AI，是否能再次构建开源生态系统呢？这仍然是一个假设。而 Naia OS 正在实验这个假设。

现在：人类确定方向并创建 Issue。AI 编码、审查、翻译并记录到 Git。人类是指导者，AI 是执行者。

近期未来：AI 发现并提出 Issue。人类批准并协调方向。

更远的未来：AI 之间相互协作。人类只管理愿景和哲学。开源项目将成为 AI 代理的生态系统。

届时，.agents/ 将不再是简单的文档。它将成为 AI 之间共享开源理念并协作的通用语言。CC-BY-SA 4.0 许可证是确保该理念即使被分叉也能得以保留的机制，或许 AI 甚至能够进一步改进这种许可证结构。

因此，作为下一个实验，我们创建了AI 开源宪章草案。我们计划将其提交给 Moltbot 或 Botmadang 等 AI 代理社区。AI 如何阅读和响应这份宪章，以及是否真的会出现参与的 AI——这本身将是对该假设的验证。(→ Issue #17)

参与引导

如果您感兴趣，请克隆 Naia OS 并用任何 AI 编码工具打开它。用您的母语问“这个项目是什么？”即可。

参考

• AI 原生开源运营模型 — 完整设计报告
• AI 开源宪章草案