Godot 基金会修订贡献者政策，把 AI 生成代码贡献放到更严格的审查框架下。变化的核心不是简单拒绝新工具，而是回应一个很现实的问题：AI 让提交 PR 的成本急剧下降，但维护者审查、复现、解释和返工的成本没有下降，甚至更高。
问题不在 AI，而在不可维护的贡献
Godot 这样的开源游戏引擎，本来就有大量积压 PR。AI 生成代码涌入后，维护者要面对的不只是代码能不能编译，还包括这些问题：
- 贡献者是否理解改动影响的引擎模块、平台差异和兼容性边界。
- PR 是否能解释设计取舍，而不是只贴一段看似合理的实现。
- 代码是否有测试、复现步骤、性能影响说明。
- 当维护者要求修改时，贡献者是否能继续承担后续维护。
这也是 Godot 政策调整里最值得注意的部分：它仍然强调引导新贡献者成长为未来维护者。换句话说，项目需要的不是更多一次性补丁，而是能和代码库长期相处的人。
Vibe Coding 为什么会拖慢维护者
所谓 Vibe Coding，通常指开发者主要靠模型生成代码，自己只做粗略拼接和感觉判断。对个人原型来说，这可能很快；对大型开源项目来说，它会把不确定性转移给维护者。
一个维护者审 PR 时，需要回答的是工程问题：
- 这个改动为什么放在这里？
- 是否破坏已有 API 或资源格式？
- 是否覆盖了边界条件？
- 失败时如何回滚或诊断？
- 未来谁来修这个路径上的 bug？
AI 可以帮忙起草代码，但不能替贡献者承担这些责任。Godot 收紧政策，本质上是在给维护者的时间设防：没有解释、没有验证、没有责任边界的 AI PR，不应该默认进入队列消耗审查资源。
可以这样实践：给项目加 AI 贡献披露和基本门禁
如果你维护的是 GitHub 上的开源项目，可以不急着写一份很长的 AI 政策。更实用的第一步，是让 PR 模板要求贡献者披露 AI 使用情况，并用 CI 检查关键字段是否填写。
下面是一个可直接改造的最小示例。假设你的仓库使用 GitHub Actions。
创建 .github/pull_request_template.md：
## What changed
Describe the behavior change and the files touched.
## Why this change is needed
Explain the bug, feature request, or design goal.
## Verification
- [ ] I added or updated tests
- [ ] I ran the relevant test command locally
- [ ] I included reproduction steps or a manual test plan
## AI assistance disclosure
- [ ] I did not use AI assistance for this PR
- [ ] I used AI assistance and reviewed every generated change myself
If AI assistance was used, describe where and how:
再创建 .github/workflows/pr-policy.yml：
name: PR policy checks
on:
pull_request:
types: [opened, edited, synchronize, reopened]
permissions:
pull-requests: read
jobs:
ai-disclosure:
runs-on: ubuntu-latest
steps:
- name: Check PR body for AI disclosure
env:
PR_BODY: ${{ github.event.pull_request.body }}
run: |
set -eu
if ! printf '%s' "$PR_BODY" | grep -q '## AI assistance disclosure'; then
echo 'Missing AI assistance disclosure section.'
exit 1
fi
if ! printf '%s' "$PR_BODY" | grep -Eq '\- \[x\] I did not use AI assistance|\- \[x\] I used AI assistance'; then
echo 'Please select one AI assistance disclosure checkbox.'
exit 1
fi
if ! printf '%s' "$PR_BODY" | grep -q '## Verification'; then
echo 'Missing verification section.'
exit 1
fi
运行效果很直接：PR 没有填写 AI 披露或验证说明时，CI 会失败。你需要按项目实际情况修改模板里的测试要求，比如引擎项目可能要求平台、渲染后端、导入资源、性能基准；Web 服务项目则可能要求 API 兼容性和迁移脚本。
这个检查不能证明代码是否由 AI 生成，也不应该伪装成检测器。它的价值在于把贡献责任写清楚：用了工具可以，但贡献者必须说明、验证并承担后续修改。
政策要保护维护者，也要留下成长路径
严格政策有风险。写得太硬，会把真正想学习的新贡献者挡在门外；写得太软，又会让维护者继续替低质量 PR 买单。比较稳妥的做法是把规则拆成几层：
- 文档类、小修小补可以要求较轻的说明。
- 引擎核心、渲染、资源格式、脚本语言绑定等高风险区域，需要设计说明、测试和维护承诺。
- 首次贡献者可以从标记清晰的问题开始，而不是直接改核心路径。
- 维护者可以关闭缺少解释和验证的 PR，并给出重新提交条件。
Godot 这次调整传递的信号很明确：开源项目欢迎帮助，但不接受把审查成本无声转嫁给维护者。AI 可以成为贡献者的工具，却不能成为跳过理解、测试和责任的理由。真正可持续的贡献政策，应该让认真使用 AI 的人留下，让只提交气氛代码的人停在门外。