6 月 30 日，Godot 基金会发布了一篇博文《Changes to our Contribution Policies》，宣布了一项在开源圈引发广泛讨论的决定：Godot 将禁止 AI 生成的代码贡献。AI agent 提交的 PR 会被自动封禁，用 AI 写了大量代码而不披露的，也一样。

这不是一个仓促的决定。从今年 2 月开始，Godot 的维护者就在公开抱怨 AI "slop" PR 的问题。"我不知道我们还能撑多久"，五个月后，他们撑不住了。

问题有多严重

Godot 的 PR 积压量已经成了社区 meme。基金会承认这里面有一部分是好事：说明想参与贡献的人多了，项目在增长。但根本问题在于：审查者太少，而 PR 成本降得太低。

原话是这么说的：

The amount of effort required to make a PR has gone down (and number of PRs has increased as a result), while the amount of work to review PRs and the amount of people available to review has stayed the same.

AI 工具让"写一个 PR"的成本趋近于零。但审查一个 PR 的成本没变。你仍然需要一个有经验的维护者仔细阅读每一行代码、思考边界情况、验证正确性。以前 100 个 PR 里有 10 个需要认真审，现在 500 个里有 50 个需要认真审，但合格的审查者还是那几个。

更致命的是审查的"回报"消失了。以前审查一个新手贡献者的 PR，维护者能感觉到自己在带人。这段反馈会帮助一个人成长为未来的维护者。现在呢？

If your feedback on PRs is just being absorbed by a machine and not going towards mentoring a potential future maintainer, it becomes much harder to justify spending your free time on PR review.

你把精心写的代码审查意见发给一个 AI agent，它转头把反馈喂给 LLM，三分钟后吐出"修好了"的新版本。下一次它还是犯同样的错。这对于用业余时间义务维护开源项目的人来说，是一种深层消耗。

Godot 到底禁了什么

具体的政策分四个层面：

1. 禁止 AI agent 和 vibe coding。 "This already leads to an auto-ban from our GitHub repository and will continue to do so." 明确。一旦发现，直接 ban。

2. AI 只能用于"琐事"。 官方列举的范围是代码补全、正则表达式、查找替换这类机械操作。涉及实质性逻辑的代码必须是人写的。如果你用了 AI 辅助，必须在 PR 讨论中主动披露。

3. 禁止 AI 生成文本用于人际沟通。 维护者花时间读你的 issue 或 PR 描述，结果发现是 LLM 写的，基金会把这件事定性为"基本的尊重问题"："This is a basic principle of respect." 唯一的例外是机器翻译，前提是原文是人写的。

4. 新贡献者不能直接提 feature PR。 合并过 3 个以下 PR 的新人，必须先修 bug、写文档来建立信任，然后才能在有维护者明确同意的情况下提交新功能或大规模重构。这条规则不直接针对 AI，但它堵住了 AI 贡献的另一条路：一个零贡献记录的人突然提交一个 2000 行的"新渲染管线"。这种 PR 几年前就已经是 red flag 了，AI 让这种现象翻了倍。

这不是 Godot 一家的事

Godot 不是第一个对 AI 代码 say no 的开源项目，也不会是最后一个。

今年早些时候，RPCS3（PS3 模拟器）的团队公开发帖："Please stop submitting AI slop code." 团队直接呼吁用户"别搞 vibe coding"，原话更狠："Leave behind something useful to humanity when you're gone, instead of peddling slop."

PlayStation 模拟器社区也收紧了类似政策。Playdate 掌机的开发商 Panic 直接宣布不再接受任何用生成式 AI 创建的游戏。

Steam 上也出现了所谓的"AI stigma"。一项数据调查显示，Steam 上标记为用了 AI 的游戏，评测数平均减少 53%，而且留下来的评测也更负面。这不一定是质量问题。更可能是玩家对"AI 内容"的本能排斥。

游戏引擎圈之外，这个问题也在蔓延。Godot 的困境本质上是所有大型开源项目都会遇到的：维护者有限、贡献者暴增、AI 让低质量贡献的成本归零。

问题不在 AI，在于"谁负责"

读完整篇公告，Godot 最核心的论点其实就一句话：

AI cannot take responsibility, and we can't trust heavy users of AI to understand their code enough to fix it.

这触及了开源协作的根本契约：你提交代码，你就对这段代码负责。出 bug 了你修。逻辑有隐患你解释。别人问"这段为什么要这么写"你能答得上来。

如果一个贡献者用了 AI 写了一整段逻辑，然后出了 bug 自己看不懂、修不了、解释不清。那这个"贡献"对项目来说是负资产。

我见过太多这样的场景。某 GitHub issue 下面，一个人贴了一大段 AI 生成的"解决方案"，看起来很漂亮，变量命名工整，注释齐全。但仔细看：用了不存在的 API，边界条件全漏了，异常处理靠 except: pass。维护者花 20 分钟指出来，对方回复："哦，这是 Claude 写的，我再让它改改。"

这种交互对维护者的消耗是真实的。它不只是时间问题，而是一种信任的侵蚀。你不知道下次这个人出现，带来的会是真正的帮助，还是另一坨需要你花时间鉴别的 slop。

我的做法

我自己也用 AI 编程，Claude Code、Cursor、各种 agent 都用过。但 Godot 的政策让我重新审视了自己的使用方式。目前我的原则是：

AI 写样板代码，我写决策。 生成一个标准的 REST API 路由？AI 来做。决定这个 API 的鉴权策略、数据模型、错误处理语义？我必须想清楚，并且能向同事解释。

AI 辅助阅读代码，人负责理解代码。 用 AI 来解释一个陌生代码库的模块结构、跳转关系，效率极高。但如果要提交修改，我必须能不看 AI 的提示独立讲清楚改了什么、为什么。

AI 写测试、人审测试。 AI 生成单元测试的边界用例很有用。它不会漏掉 null、空字符串、负数这种 case。但测试的逻辑必须经我过目：mock 对不对？断言有没有覆盖真正的业务预期？别让一个写错的测试给你虚假的安全感。

这不是反 AI。恰恰相反，正因为 AI 在编程上的能力在指数级增长，分清"什么该让 AI 做、什么必须人做"才变得前所未有地重要。Godot 的维护者们不是 Luddite。他们比大多数开发者更清楚 AI 的威力。正是因为每天面对这些 AI 生成的 PR，他们才比任何人都更早看到了问题。

开源社区的契约是：你写代码，你负责，你帮助项目成长。AI 改变了"写代码"这一步的速度，但没改变"负责"和"成长"这两个环节。而且短期内，它改变不了。

参考：Godot Foundation — Changes to our Contribution Policies