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 for OpenHarmony:diacritic 移除重音符号,实现精准的模糊搜索与排序(文本规范化处理) 深度解析与鸿蒙适配指南

Flutter for OpenHarmony:diacritic 移除重音符号,实现精准的模糊搜索与排序(文本规范化处理) 深度解析与鸿蒙适配指南

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net 前言 全球化应用经常需要处理包含各种重音符号(Accent)和变音符号(Diacritic)的文本,如法语的 “café”、德语的 “München” 或西班牙语的 “mañana”。如果不进行处理,用户在搜索 “cafe” 时可能搜不到 “café”,导致体验极差。 diacritic 是一个专注于解决此类问题的轻量级 Dart 库。它能在几乎不损失语义的情况下,将这些字符转换为其最接近的 ASCII 形式。本文将介绍如何在 OpenHarmony 应用中利用它优化搜索和排序体验。 一、diacritic 简介 1.1 核心功能 * 移除变音符号:将 à, é, î, ö 等转换为 a, e, i,

By Ne0inhk
Flutter for OpenHarmony: Flutter 三方库 hashlib 为鸿蒙应用提供军用级加密哈希算法支持(安全数据完整性卫士)

Flutter for OpenHarmony: Flutter 三方库 hashlib 为鸿蒙应用提供军用级加密哈希算法支持(安全数据完整性卫士)

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net 前言 在 OpenHarmony 应用开发中,涉及到本地存储加密、用户密码脱敏、大文件完整性校验或区块链应用时,一套算法完备、执行高效的哈希(Hash)库是必不可少的。虽然 Dart 原生也提供了一些简单的加密方法,但在算法多样性(如 Argon2、SHA-3, Blake2b 等高级算法)和性能表现方面,往往无法满足高安全等级项目的需求。 hashlib 正是专门为高性能数据加解密与完整性校验打造的库。它纯代码实现且经过了极致的循环优化,是鸿蒙平台上保护敏感数据的数字堡垒。 一、核心加密算法矩阵 hashlib 支持极其广泛且先进的加密标准。 原始明文数据 hashlib 算法引擎 传统算法 (MD5 / SHA-256) 现代算法 (SHA-3 / Keccak) 极致速度 (Blake2b / Blake2s) 密钥派生 (Argon2 / Scrypt)

By Ne0inhk
Prometheus+cpolar 实现监控警告教程

Prometheus+cpolar 实现监控警告教程

声明:不是广告,仅是实践教程 Prometheus、node_exporter、Alertmanager 这套组合是中小团队和个人运维的实用工具,Prometheus 能精准采集 CPU、内存等服务器核心指标,node_exporter 轻量化完成数据收集,Alertmanager 则能按规则分类推送告警,三者适配性强、开源免费,无需高额成本就能实现 7x24 小时服务器监控,尤其适合个人博主、小公司运维人员这类缺乏专职运维的群体。 使用这套工具时要注意,告警规则设置需贴合实际场景,比如 CPU 告警阈值不宜过高或过低,否则易出现误报或漏报,且默认配置下仅能在局域网内查看数据,排查问题时容易受限。 仅依靠局域网访问监控系统的弊端十分明显,比如外出时发现服务器异常,无法远程查看监控数据,只能等回到内网环境才能排查;团队协作时,成员必须接入同一局域网才能查看告警信息,跨地域办公时沟通和处理效率大打折扣。 而将这套监控工具与 cpolar 结合后,无需申请公网 IP、无需配置路由器端口映射,就能把监控系统暴露到公网,不管是在家、出差,用手机或电脑都能随时查看服务器状态,团队成员也能通

By Ne0inhk
Flutter 三方库 mix_context 的鸿蒙化适配指南 - 实现极简上下文增强、支持非 Widget 作用域下的 BuildContext 访问与状态注入

Flutter 三方库 mix_context 的鸿蒙化适配指南 - 实现极简上下文增强、支持非 Widget 作用域下的 BuildContext 访问与状态注入

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 mix_context 的鸿蒙化适配指南 - 实现极简上下文增强、支持非 Widget 作用域下的 BuildContext 访问与状态注入 前言 在进行 Flutter for OpenHarmony 开发时,我们经常会遇到底层逻辑(如 Service、Repository)需要访问 BuildContext 的窘境(例如为了弹出一个全局 Dialog 或获取当前的主题颜色)。虽然传统的做法是层层传递参数,但代码会因此变得臃肿。mix_context 提供了一种更优雅的上下文混入与注入方案。本文将指导大家如何在鸿蒙端利用该库提升代码的响应能力。 一、原理解析 / 概念介绍 1.1 基础原理 mix_context 的核心思想是将 BuildContext 的引用通过全局代理或单例模式进行“

By Ne0inhk