上周 Godot一个用户量很大的开源游戏引擎更新了贡献政策全面禁止 AI 代理直接提交代码违者永久禁止访问仓库。这是目前最强硬的一次反 Vibe Coding表态。我每天都在用 Claude Code 写代码看到这个新闻的第一反应不是AI 又被针对了而是这个规则说的正是我一直担心的问题。先说清楚 Godot 具体做了什么Godot 基金会这次更新贡献政策核心是三条规则具体内容禁止 AI 代理直接提交代码违者永久禁止访问仓库这是目前开源社区里最严厉的处罚力度新贡献者门槛合并 PR 数量在 3 个及以下的用户被定义为新贡献者会有额外限制强制人工审核任何 PR 必须由真人完成审核并批准才能合并进主分支——这条规则以前就有这次是进一步明确和强化触发这次政策更新的原因大量 AI 生成的低质量 PR 涌入项目维护者的审查负担暴增同时也引发了代码质量和责任归属的争议——如果一段 AI 生成的代码出了问题责任算谁的这不是个例而是一个正在扩大的趋势Godot 不是第一个这么做的项目。最近开发者圈里流行一个新词——“Vibe Slop”氛围垃圾代码专门用来形容那种看起来能跑但没人真正理解、也没人愿意负责的 AI 生成代码。这个词流行起来本身就说明了一个现象大量开源维护者已经被Vibe Coding 提交的低质量代码折磨够了。维护者的困境很实际审查一段人写的代码你大致能判断作者的思路和意图审查一段 AI 生成的代码你完全不知道提交者自己有没有理解这段代码在干什么如果代码出问题提交者可能自己都答不上来为什么这样写对开源项目来说PR 数量暴增但质量下降等于维护成本不降反升。作为个人开发者我怎么看这件事我自己每天都在用 Claude Code 写代码效率提升是真实的。但 Godot 这次的政策让我重新想清楚了一个问题Vibe Coding 适合你自己负责的场景不适合你要说服别人相信的场景。具体展开场景Vibe Coding 是否合适原因自己的项目自己维护✅ 合适出了问题自己扛理解不理解是自己的事给团队提 PR⚠️ 谨慎同事需要理解你的代码AI 生成的东西你自己都说不清就麻烦了给开源项目提 PR❌ 不合适维护者要为整个项目的长期质量负责你的不理解变成了别人的负担写文档/脚手架/一次性脚本✅ 合适低风险出错影响小Godot 这次针对的其实是最后一种情况的极端版本有人用 AI 生成代码自己完全不审查就直接提 PR 给维护者把理解代码这个责任完全甩给了别人。这不是在用 AI 提升效率是在用 AI 转移劳动。一个容易被忽略的区别AI 辅助 vs AI 甩锅我自己现在用 AI 写代码会明确区分两种情况AI 辅助我依然负责让 AI 生成初稿我逐行看过、理解、调整遇到我不确定的地方会去验证或者测试提交前我能对每一行代码的存在负责AI 甩锅我不再负责AI 生成什么就是什么没有真正 Review提交的时候其实是把责任转移给了下一个看代码的人出了问题第一反应是这是 AI 写的Godot 这次的政策本质上是在强制大家从甩锅模式切回辅助模式。我觉得这个方向是对的只是用了比较激烈的手段一刀切禁止 AI 代理提交而不是要求提交者做更严格的自我审查。这对我们日常写代码有什么启发不管你是不是给开源项目提 PRGodot 这次事件都值得我们对照检查一下自己的 AI 使用方式自查清单提交代码前我能不能对每一行的存在给出理由如果同事问我这段逻辑为什么这样写我能不能不查 AI 对话记录就回答我有没有真正 Review 过 AI 生成的内容还是看起来能跑就直接提交了如果这段代码出了 bug我能不能独立排查而不是重新问一遍 AI四个问题里如果有两个以上答不上来说明你正在从AI 辅助滑向AI 甩锅需要收一收。最后Godot 这次的强硬表态不是AI 编程不行而是不负责任的 AI 编程不行。作为每天靠 AI 提效的开发者我反而觉得这种边界感是好事——它把用 AI 写代码和用 AI 逃避理解代码这两件事划清楚了。Vibe Coding 本身没有错错的是把我不需要理解也一起 Vibe 掉了。你怎么看 Godot 这次的政策你在用 AI 写代码时会不会做逐行 Review评论区聊聊。
Godot 全面封杀 Vibe Coding,作为每天用 AI 写代码的人,我反而觉得这是件好事
发布时间:2026/7/7 3:09:22
上周 Godot一个用户量很大的开源游戏引擎更新了贡献政策全面禁止 AI 代理直接提交代码违者永久禁止访问仓库。这是目前最强硬的一次反 Vibe Coding表态。我每天都在用 Claude Code 写代码看到这个新闻的第一反应不是AI 又被针对了而是这个规则说的正是我一直担心的问题。先说清楚 Godot 具体做了什么Godot 基金会这次更新贡献政策核心是三条规则具体内容禁止 AI 代理直接提交代码违者永久禁止访问仓库这是目前开源社区里最严厉的处罚力度新贡献者门槛合并 PR 数量在 3 个及以下的用户被定义为新贡献者会有额外限制强制人工审核任何 PR 必须由真人完成审核并批准才能合并进主分支——这条规则以前就有这次是进一步明确和强化触发这次政策更新的原因大量 AI 生成的低质量 PR 涌入项目维护者的审查负担暴增同时也引发了代码质量和责任归属的争议——如果一段 AI 生成的代码出了问题责任算谁的这不是个例而是一个正在扩大的趋势Godot 不是第一个这么做的项目。最近开发者圈里流行一个新词——“Vibe Slop”氛围垃圾代码专门用来形容那种看起来能跑但没人真正理解、也没人愿意负责的 AI 生成代码。这个词流行起来本身就说明了一个现象大量开源维护者已经被Vibe Coding 提交的低质量代码折磨够了。维护者的困境很实际审查一段人写的代码你大致能判断作者的思路和意图审查一段 AI 生成的代码你完全不知道提交者自己有没有理解这段代码在干什么如果代码出问题提交者可能自己都答不上来为什么这样写对开源项目来说PR 数量暴增但质量下降等于维护成本不降反升。作为个人开发者我怎么看这件事我自己每天都在用 Claude Code 写代码效率提升是真实的。但 Godot 这次的政策让我重新想清楚了一个问题Vibe Coding 适合你自己负责的场景不适合你要说服别人相信的场景。具体展开场景Vibe Coding 是否合适原因自己的项目自己维护✅ 合适出了问题自己扛理解不理解是自己的事给团队提 PR⚠️ 谨慎同事需要理解你的代码AI 生成的东西你自己都说不清就麻烦了给开源项目提 PR❌ 不合适维护者要为整个项目的长期质量负责你的不理解变成了别人的负担写文档/脚手架/一次性脚本✅ 合适低风险出错影响小Godot 这次针对的其实是最后一种情况的极端版本有人用 AI 生成代码自己完全不审查就直接提 PR 给维护者把理解代码这个责任完全甩给了别人。这不是在用 AI 提升效率是在用 AI 转移劳动。一个容易被忽略的区别AI 辅助 vs AI 甩锅我自己现在用 AI 写代码会明确区分两种情况AI 辅助我依然负责让 AI 生成初稿我逐行看过、理解、调整遇到我不确定的地方会去验证或者测试提交前我能对每一行代码的存在负责AI 甩锅我不再负责AI 生成什么就是什么没有真正 Review提交的时候其实是把责任转移给了下一个看代码的人出了问题第一反应是这是 AI 写的Godot 这次的政策本质上是在强制大家从甩锅模式切回辅助模式。我觉得这个方向是对的只是用了比较激烈的手段一刀切禁止 AI 代理提交而不是要求提交者做更严格的自我审查。这对我们日常写代码有什么启发不管你是不是给开源项目提 PRGodot 这次事件都值得我们对照检查一下自己的 AI 使用方式自查清单提交代码前我能不能对每一行的存在给出理由如果同事问我这段逻辑为什么这样写我能不能不查 AI 对话记录就回答我有没有真正 Review 过 AI 生成的内容还是看起来能跑就直接提交了如果这段代码出了 bug我能不能独立排查而不是重新问一遍 AI四个问题里如果有两个以上答不上来说明你正在从AI 辅助滑向AI 甩锅需要收一收。最后Godot 这次的强硬表态不是AI 编程不行而是不负责任的 AI 编程不行。作为每天靠 AI 提效的开发者我反而觉得这种边界感是好事——它把用 AI 写代码和用 AI 逃避理解代码这两件事划清楚了。Vibe Coding 本身没有错错的是把我不需要理解也一起 Vibe 掉了。你怎么看 Godot 这次的政策你在用 AI 写代码时会不会做逐行 Review评论区聊聊。