游戏引擎开始给 AI 留工位了

2026 年 4 月 30 日，GameMaker 发布了年度最重要的更新公告。内容很多：新的 GMRT 运行时要退出 beta 了，JavaScript 和 TypeScript 要成为一等公民了，C# 也要来了，源码要对所有人开放了，Blender 工作流要深度集成了。这些每一条都够写一篇分析。

但最容易被忽略也最值得细看的一条，藏在「Developer Tools」那一段里——GM-CLI，一组命令行工具。这个工具的名字很朴素，功能也很直白：build、run、compile、create project、add sprite、add event to object。听起来像是给那些讨厌图形界面的老派开发者准备的。但它真正的目标用户，可能根本不是人。

因为在此之前，AI 和游戏引擎之间隔着一堵墙。过去两年我们聊「AI 做游戏」的时候，大家脑子里的画面大多是两个方向：要么是用 Midjourney 生成美术素材，要么是让人家帮你写几段 GML 代码。两种方式有一个共同问题——AI 只能聊天，不能动手。你描述完需求，它给你一段代码或者一张图，然后呢？还是得你自己去复制粘贴、新建文件、配路径、跑构建。AI 像个坐在旁边的顾问，说得头头是道，最后还得你亲自来执行。

GameMaker 这次做的，是把这堵墙拆了一角。GM-CLI 开源，Apache License，已经可用。它做的事情很简单：把以前只能在 IDE 里点菜单完成的操作，全部暴露成命令行接口。建项目、加资源、加事件、编译、运行、查配置——全都能通过命令完成。这意味着什么？意味着一个外部程序可以直接操作你的 GameMaker 项目，而不需要人去点点点。

这正是 AI agent 需要的东西。GameDeveloper 的报道里，GameMaker head Russell Kay 的原话说得很清楚：AI-assisted coding 已经成为很多开发者工作流的重要部分，GameMaker 要反映这个现实。工具是 complementary and opt-in，由开发者决定是否使用。翻译过来就是：我们不逼你用，但我们知道你不用的话迟早会落后。

Claude Code 就是那个「外部程序」。它的官方产品页上写得明白：开发者可以在 terminal / IDE / Slack / web 里直接跟代码库对话，描述需求后让 Claude 去处理后续动作。现在 GameMaker 把它包进自己的 CLI，开发者就能用自然语言让 AI 去查询项目结构、找 bug、管理 build configurations。不需要再手动打开某个文件夹找哪个脚本出了问题，也不需要再去翻文档确认某个参数怎么配。

但这只是第一步。GM-CLI 解决的是「AI 有手」的问题。而 GameMaker 这次更新的另一个大块——GMRT，解决的则是「AI 有眼」的问题。

GMRT 是 GameMaker 全新的运行时架构，桌面平台未来几个月退出 beta，移动和主机平台年内陆续跟上。LTS26 计划从 2026 年 Q2 开始到 2028 年 Q1 结束，GMS2 Runtime 将进入 feature complete 状态，新功能全部转向 GMRT。更重要的是，GMRT 的 Desktop、Mobile、Web 源码会对所有用户开放，Console 版本源码给验证过平台资格的 Enterprise 用户。

源码开放这件事对 AI 的意义可能比对人更大。当一个 AI agent 可以读取运行时源码、理解项目结构、定位崩溃日志里的堆栈信息时，它能做的就不再是「猜哪里有问题」，而是「读出来哪里有问题」。这对小团队来说价值巨大——你不再需要一个资深工程师来帮你看日志，你需要的是一个能读懂日志的工具。

语言扩展路线同样值得注意。JavaScript Q2、TypeScript Q3、C# Q4 preview。JS/TS 将是一等语言，可替换 GML 代码；C# 是与 GML/JS/TS 互操作。为什么这个顺序重要？因为 JavaScript 是目前生态中 AI 训练数据最丰富的语言之一。任何 LLM 对 JS 的理解深度都远超 GML。把 JS 做成一等公民，等于让 GameMaker 项目能无缝接入整个 AI 编程生态——Copilot、Cursor、Windsurf、Claude Code，所有这些工具在 JS 上的表现都比在专有语言上好得多。

3D 方面的改进也不容忽视。glTF 模型加载、Scene Graph、改进的 3D 数学函数、动画加载，官方明确提到以 Blender 作为主要资产创建来源并希望未来紧密集成 Blender 工作流。这意味着 GameMaker 正在从一个「2D 玩具」往「严肃的多维度游戏生产系统」迁移。而一旦引擎变得复杂，自动化就变得更必要——因为复杂系统的重复劳动量是指数级增长的。

所以回到最初的问题：AI 到底会在游戏开发里先接管什么？答案可能出乎很多人的意料。不是写核心玩法逻辑，不是设计关卡，不是画美术，甚至不是写代码。而是开项目、加资源、跑版本、查崩溃、配构建、改配置这些最枯燥的重复动作。这些东西以前靠人去点，以后靠 CLI 去调。而 CLI 的另一端，可以是 AI。

当然也有风险。AI 会犯错，而且一旦它有了修改项目的权限，错误也会被放大。如果项目结构本身混乱，AI 只会更快地把混乱扩散到更多文件里。所以这件事的核心矛盾不在于「会不会用 AI」，而在于「你的工程流能不能被 AI 接住」。如果一个团队的项目命名规范混乱、目录结构随意、注释缺失，那么无论 GM-CLI 多强大，AI 进去之后也只能制造更多的混乱。

这就是为什么 GameMaker 这次更新里，GM-CLI 和 GMRT、源码开放、语言扩展是放在一起宣布的。它们是一套组合拳：CLI 给 AI 提供入口，GMRT 和源码开放给 AI 提供可读的结构，多语言支持给 AI 提供更丰富的上下文。三者缺一不可。未来的分水岭大概会在这里出现。不是你会不会用 AI 写代码，而是你的工程流有没有准备好被 AI 接住。GameMaker 已经把门打开了，接下来就看开发者自己愿不愿意走进去