近日，开源游戏引擎 Godot 官方发布了一条引发开发者广泛讨论的声明：全面禁止“Vibe Coding”（即完全依赖 AI 生成代码、开发者仅做粗略检查的编程方式）提交至项目仓库。这一决定迅速登上技术社区热搜，支持与反对声音各半。作为一名每天使用 AI 辅助编写代码的开发者，我非但没有感到被冒犯，反而由衷认为——这恰恰是开源生态走向成熟的标志。
什么是 Vibe Coding？一场关于“代码外包”的狂欢
“Vibe Coding”一词源于近期 AI 编程工具的爆发式增长。开发者不再逐行手写代码，而是向 GitHub Copilot、Cursor 或 Claude 等 AI 工具描述需求，然后直接复制粘贴 AI 生成的片段，仅做最低限度的测试便提交。这种方式被戏称为“跟着感觉编程”——只要程序能跑，就“感觉对了”。
在个人项目或快速原型中，Vibe Coding 确实能大幅提升效率。但将其引入开源协作，尤其像 Godot 这样拥有数十万行 C++ 核心代码、承载着游戏开发者信任的引擎项目，风险立刻暴露无遗。
Godot 的“封杀”意味着什么？
据 Godot 官方公告，新规要求所有代码贡献者必须亲自理解并能够解释自己提交的每一行代码。AI 工具可作为辅助，但不能替代开发者完成逻辑构思、算法设计或测试。官方明确表示：“若无法解释代码为何能正常工作，请不要提交。”
这项政策并非针对 AI 本身，而是针对“未经审核的 AI 输出”。Godot 维护者指出，他们已收到大量由 AI 生成的拉取请求，其中包含难以察觉的边界条件错误、隐藏的安全漏洞，甚至涉及 GPL 协议下的版权问题。例如，AI 可能“记忆”了来自不同许可证项目的代码片段，导致 Godot 面临法律风险。
为什么我赞同“封杀”？
作为每天使用 AI 编程的从业者，我深知 AI 的强大与脆弱。我的工作流中，AI 大约承担了 40% 的代码生成——模板代码、重复逻辑、单元测试骨架。但关键的业务逻辑、架构设计、性能优化，我坚持手动完成，并逐行审查 AI 的输出。
我见过太多“Vibe Coding”的后果：同事提交的 AI 生成代码在运行时抛出诡异的空指针异常，而他自己甚至看不懂报错信息；一个“看起来很美”的算法实现，实际消耗了比预期多两个数量级的内存；更可怕的是，AI 曾生成一段看似无害的 CGI 脚本，实则埋入了潜在的命令注入漏洞。
在开源项目中，这些问题会被无限放大。一个没有经过深思的提交可能影响整个引擎的稳定性，而维护者需要耗费数倍精力去修正“黑箱代码”。Godot 的禁令，本质上是在保护开源协作的根基——信任与责任。你贡献代码，就意味着你为其质量背书。
理性看待：不是反对 AI，而是反对“无脑复制”
有趣的是，Godot 官方声明特别强调这项禁令不针对“使用 AI 辅助的开发过程”。只要开发者能理解、修改并测试 AI 生成的代码，就可以正常提交。这恰好说明，Godot 并非“反 AI”，而是希望开发者保持清醒：AI 是锤子，你不能把所有的钉子都砸成小动物。
从行业趋势看，已有多个主流开源项目开始限制 AI 生成代码的提交。Python 核心开发者曾因 AI 生成的补丁中含有隐秘的 Unicode 攻击向量而深恶痛绝；Linux 内核社区也反复警告“不要提交你无法理解的代码”。这些共识背后，是对软件工程本质的回归：代码不仅是执行命令，更是人类智慧的凝结与交流。
结语：Vibe Coding 有未来，但需要规则
我并不认为 Vibe Coding 会消亡。在个人玩具项目、自动化脚本、甚至某些企业内部的低风险场景中，它依然高效。但当一个开源项目选择拥抱全球开发者时，它必须守住底线：不允许任何人把“未知”塞进几十万人依赖的代码库。
每天用 AI 写代码的我，感谢 Godot 的这次“封杀”。它提醒我们：在享受技术红利的同时，永远不要放弃对代码的敬畏之心。AI 可以为我们加速，但不能替我们思考。真正的“好代码”，从不在“感觉对了”中诞生，而在理解、权衡与负责中沉淀。