Godot被AI代码“围攻”!维护者崩溃发声:“不知道还能坚持多久”

Godot被AI代码“围攻”!维护者崩溃发声:“不知道还能坚持多久”

整理 | 郑丽媛

出品 | ZEEKLOG(ID:ZEEKLOGnews)

当大模型能在几秒钟内生成一段“看起来像那么回事”的补丁时,开源社区却开始付出另一种代价。

最近,开源游戏引擎 Godot 的核心维护团队公开吐槽:他们正被大量“AI 生成的低质量代码”淹没。那些代码往往结构完整、注释齐全、描述洋洋洒洒,但真正的问题是——提交者可能并不理解自己交上来的内容。

这件事,并不是简单的“有人偷懒用 AI 写代码”。它正在触及开源协作最核心的东西:信任。

一场悄无声息的“AI 洪水”

事情的导火索来自一条 Bluesky 讨论帖。

Godot 主要维护者之一、同时也是 Godot 商业支持公司 W4 Games 联合创始人的 Rémi Verschelde 表示,所谓的“AI slop”(AI 生成的低质量内容)正在持续涌入项目仓库,Pull Request 数量和审查压力都在飙升。

对不了解开源流程的人来说,PR(Pull Request)只是“提交代码”的按钮;但对维护者而言,每一个 PR 都意味着阅读、理解、测试、回溯架构影响、评估兼容性、讨论修改方向……这是一整套严肃的工程流程。

过去,新贡献者提交的代码即便有问题,维护者也能通过交流判断:对方是否理解架构、是否认真测试、是否真心想参与项目建设——而现在,问题变得复杂了。

当“像人写的”≠“是人写的”

Verschelde 直言,如今他们每天都要反复怀疑新贡献者的 PR。

描述部分通常是典型的大模型风格:长篇解释、逻辑完整、语气自信。但真正棘手的是代码本身——它未必有明显错误,却也未必真正合理有效。

基于此,项目维护者不得不开始问自己一连串问题:

● 这段代码是不是至少部分由人类写的?

● 提交者真的理解自己改动的逻辑吗?

● 是否做过真实测试?

● 测试结果会不会也是 AI 编的?

更微妙的是,即便识别出 AI 参与,也无法简单定性:代码出错,是因为 AI 写的?还是一个经验不足的新手开发者犯了错?

如果你出于怀疑,直接询问对方是否使用了 AI,对方回答:“我只是用 AI 帮我写 PR 描述,因为我英文不好。”——那你又该如何处理?

很显然,这已经不是代码质量的问题了,而是因AI参与造成了协作信任的“灰色地带”。

“我也不知道我们还能坚持多久”

作为一个完全开源的游戏引擎,其实Godot 一直强调“欢迎任何人参与”。它没有商业巨头背书,也不像某些主流引擎那样高度封闭。任何用户,都可以尝试为自己使用的引擎做出贡献。

正因为这种开放性,Godot 才拥有活跃的社区生态。

但问题也随之而来:当生成式 AI 降低了“提交代码”的门槛,贡献数量被放大,维护者的时间却没有被同步放大。

Verschelde 表示,维护者本来就需要花大量时间帮助新贡献者,把 PR 调整到可合并状态;而现在,在 AI 生成内容泛滥的情况下,这种辅导成本正在急剧增加。对一个核心团队规模有限的项目来说,这种压力无疑是实打实的消耗。

他甚至无奈说道:“我也不知道我们还能坚持多久。”

用 AI 打 AI?听起来就很讽刺

Verschelde 透露,其团队内部正在讨论解决方案,包括自动检测机制,比如考虑使用 AI 来识别 AI 生成内容。但这本身就带着黑色幽默意味——为了检测 AI 生成的“垃圾代码”,不得不再运行一套 AI 系统。

Verschelde 公开表示,他并不愿意继续“给 AI 机器喂数据”。在他看来,这种循环有些荒诞。

与此同时,Godot 也在评估是否需要迁移代码托管平台。当前该项目托管在 GitHub 上,而 GitHub 的母公司是微软,它正是全球最积极推进 AI 产品化的科技公司之一。

现如今,部分开发者利用 AI 批量生成 PR,目的并不一定是改善项目,而是为了“刷贡献记录”,为自己的履历增加筹码。因此Godot 团队考虑,迁移到更小众的平台,也许能减少这类动机——但风险也同样明显:曝光度下降、真实贡献者流失、生态割裂。

真正的解法,可能很现实

在所有讨论之后,Verschelde 给出的答案其实非常务实:资金支持。

如果能有更多资金,就能雇佣更多维护者,承担审核与指导成本。否则,少数核心成员很难长期承受这种“被 AI 放大”的工作量。

换句话说,AI 提高了代码生成效率,却没有自动生成对应的“审核人力”。

然而,Godot 的困境并非孤例。越来越多开源项目都在面对类似问题:PR 数量增长、质量参差不齐、审查压力倍增。或许未来会出现更严格的 AI 使用标记制度,或者贡献者信誉分层机制,甚至付费维护体系成为常态。

但在这些制度成熟之前,像 Godot 这样的项目只能在理想主义与现实压力之间继续平衡。

参考链接:https://www.pcgamer.com/software/platforms/open-source-game-engine-godot-is-drowning-in-ai-slop-code-contributions-i-dont-know-how-long-we-can-keep-it-up/

推荐阅读:

Agent取代App、机器人“盲区”、RAG成本失控……2026 奇点智能技术大会首批议题发布

万人大厂一夜裁员4000+人!她拼命用AI提效,却在凌晨12:30等来解雇通知

岗位一朝被Meta砍掉,工程师转头训练小狗敲键盘,竟靠Claude把乱码做成了游戏,还开源了!

未来没有前后端,只有 AI Agent 工程师。

这场十倍速的变革已至,你的下一步在哪?

4 月 17-18 日,由 ZEEKLOG 与奇点智能研究院联合主办「2026 奇点智能技术大会」将在上海隆重召开,大会聚焦 Agent 系统、世界模型、AI 原生研发等 12 大前沿专题,为你绘制通往未来的认知地图。

成为时代的见证者,更要成为时代的先行者。

奇点智能技术大会上海站,我们不见不散!

Read more

Flutter 组件 meeting_place_core 的适配 鸿蒙Harmony 实战 - 驾驭分布式会议引擎、实现鸿蒙端高性能协作空间与复杂信令分发方案

Flutter 组件 meeting_place_core 的适配 鸿蒙Harmony 实战 - 驾驭分布式会议引擎、实现鸿蒙端高性能协作空间与复杂信令分发方案

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 meeting_place_core 的适配 鸿蒙Harmony 实战 - 驾驭分布式会议引擎、实现鸿蒙端高性能协作空间与复杂信令分发方案 前言 在后疫情时代的协同办公浪潮中,视频会议已经从单一的垂直应用演变为鸿蒙(OpenHarmony)生态中“泛在协作”的核心基础设施。当你在鸿蒙平板上开启一场跨国技术评审,或者在鸿蒙车机上紧急连线公司晨会时,支撑这一切流畅运行的,是底层极其复杂的会议核心引擎。 meeting_place_core 是一套工业级的、专为多端同步设计的会议核心抽象包。它不负责 UI 渲染,而是专注于房间管理(Room Management)、成员状态流转、信令推送及媒体流的逻辑编排。 适配到鸿蒙平台后,结合鸿蒙强大的分布式能力,meeting_place_core 能让你的 App 轻松实现“手机开会,大屏投映,

By Ne0inhk
解决Google Scholar “We‘re sorry... but your computer or network may be sending automated queries.”的问题

解决Google Scholar “We‘re sorry... but your computer or network may be sending automated queries.”的问题

解决Google Scholar “We’re sorry… but your computer or network may be sending automated queries.”的问题 在使用Google Scholar进行学术搜索时,你可能会遇到错误提示: “We’re sorry… but your computer or network may be sending automated queries. To protect our users, we can’t process your request right now. See Google Help for more information.

By Ne0inhk
Spring Boot快速入手

Spring Boot快速入手

SpringBoot快速入手 * Maven * Maven基本概念 * Maven创建 * 项目构建 * 管理依赖 * Maven仓库 * 本地仓库 * 中央仓库 * 私有服务器 * SpringBoot程序 * Spring Boot项目创建 * 启动项目 * 可能出现的错误 完成StpringBoot环境搭建,并使用起创建一个项目,输出HelloWorld Maven Maven基本概念 什么是Maven 呢? 官方地址https://maven.apache.org/index.html Apache Maven is a software project management and comprehension tool. Based on theconcept of a object model (POM), Maven can manage a

By Ne0inhk
五分钟理解Rust的核心概念:所有权Rust

五分钟理解Rust的核心概念:所有权Rust

欢迎来到Rust的世界。你可能听说过Rust以其惊人的运行速度、强大的内存安全保证而闻名,甚至连续多年被评为“最受开发者喜爱的编程语言”。而支撑起这一切荣耀的基石,正是我们今天要深入探讨的核心概念——所有权(Ownership)。 对于许多刚从Java、Python、C++等语言转来的开发者来说,“所有权”就像一个神秘的守门人,它严格、挑剔,甚至有点不近人情,常常用编译错误将你拒之门外。但请相信我,一旦你理解了它的工作原理和设计哲学,这位守门人就会变成你最忠诚、最强大的守护骑士。 这篇文章的目的,就是带你穿越迷雾,用最详尽的解析和最生动的比喻,让你不仅“知道”所有权是什么,更能“理解”它为何如此设计,并最终“掌握”如何与它和谐共处。准备好了吗?让我们开始这场精彩的思维探险吧! 第一章:编程语言的“内存难题” —— Rust给出的答案 在程序的世界里,管理内存(Memory Management)是一件天大的事。它就像一个国家的财政管理,管得好,国家繁荣昌盛(程序高效稳定)

By Ne0inhk