想让 AI 帮我做游戏，查了一圈最后选了 Godot
查了一圈 Godot、Unity、虚幻，最后落在 Godot
之前用 TypeScript 写过几个 web 游戏，能跑，能甩个链接给朋友，点开就能玩。但每次做到一半都会冒出同一个感觉：这东西再怎么堆，好像也长不成一个「正经」游戏。
后来想认真做一个，让 AI 写掉大部分代码，就去查到底哪个引擎最合适。去查之前我默认觉得，谁的资料多、谁被讨论得多，AI 就最会用谁，按这个逻辑要么 Unity，要么继续留在 web。查的过程里发现不完全是这么回事，下面把查到的东西按引擎捋一遍。
先说「天花板低」这个体感准不准。只能说对了一半，因为我把两层完全不同的东西混在一起了。
第一层是性能和画面。JavaScript 单线程、垃圾回收会卡、3D 工具链不成熟，这些都是真的，开放世界和写实 3D 在浏览器里基本无解。不过这条线在往上走：2025 年 9 月 WebGPU 在所有主流浏览器落地了，iOS Safari 也包括在内，大矩阵运算比老 WebGL 快好几倍。Three.js 的周下载量一年翻倍到 540 万，连虚幻 5 的 Lyra 示例都有人在浏览器里跑起来了。
第二层是发行和观感，这层基本是旧观念。想上 Steam，Electron 包一层就行，2025 年 10 月就有一个三人小团队这么把 Phaser 挂机游戏发上了 Steam。想上手机应用商店，Capacitor 包一层。「浏览器游戏上不了台面」这个说法，现在已经不成立了。
而且 web 其实是 AI 跑得最快的地方。Phaser 是唯一在自己 GitHub 主页上直接写「每一个主流前沿大模型的训练数据里都有 Phaser」的游戏框架，仓库里还带了给 claude code 和 cursor 用的 agent skills。有个开发者用 claude 加 cursor，花 25 到 30 小时做了个塔防，一万五千行代码 95% 是 AI 写的，丢进 game jam 拿了四星。
所以「天花板低」这个感觉，其实混了画面上限、发行门槛、AI 能帮多少这几件事。前两个确实低过，现在也在补；第三个反而一直是 web 的强项。
查下来最有意思的一点，是「谁资料多 AI 就最会用谁」这个逻辑本身就不太成立。我看到两个反例，摆在一起还挺说明问题的。
第一个是 Bevy，Rust 写的游戏引擎。Rust 的训练数据一点不少，但 Bevy 大概每三个月来一次 breaking change（破坏性 API 改动），快速上手文档里就挂着这条警告。结果就是 AI 永远在用过时的写法，语法看着对，编译过不去。有个叫 Architect of Ruin 的开发者，花六周把整个游戏从 Bevy/Rust 迁到了 Unity/C#，他自己说的原因是 AI 对 C# 的建议「高度相关」，对 Bevy 永远慢半拍。
第二个反例正好反过来。Pico-8 是台限制极狠的复古游戏机：128×128 像素、16 种颜色、代码上限 8192 个 token。按「资料多才行」的逻辑，这么小众的东西 AI 应该完全玩不转。实际上有人用 claude code 一轮对话就写出了一个零 bug 的 Lua 游戏，自己一行没动。原因恰恰是它的 API 小到没有歧义，AI 一眼能看全。
这两个例子放一起看，我只能说真正起作用的变量不是训练数据总量，是 API 的新鲜度和稳定度，再加上 AI 能不能把整个项目看全。所以挑引擎其实该问的是：这个引擎里的东西，AI 能不能整个读成文本，能不能自己把游戏跑起来看结果改。后面三个引擎我都是拿这个去对的。
Bevy 数据多却编译不过，Pico-8 小到 AI 一眼看全：真正的变量不是训练数据量，是新鲜度加看得全
先说虚幻。要画面本身，虚幻确实没对手，Nanite、Lumen、MetaHuman 这套堆出来就是电影级的写实度，今年口碑很好的《Clair Obscur: Expedition 33》，就是小团队用虚幻 5 做到了 3A 画面。
但换成「让 AI 来写」，虚幻是三个里最难受的，难在三处：
- 蓝图是二进制的。可视化脚本存成 .uasset 文件，二进制节点图，AI 根本读不了，也写不了。有个开发者说得很直白：打开 claude code 想让它看蓝图，它看不见。2025 年有篇论文为了研究蓝图，自己写了解析器去啃 33 万多个 .uasset 文件。现在的变通办法是装插件，把蓝图先翻译成 C++ 给 AI 看，等于承认 AI 没法直接碰。
- 虚幻的 C++ 不是普通 C++。一堆 UCLASS、UPROPERTY 反射宏，加上出了名难学的 GAS 技能系统，AI 就算语法写对了也常出幻觉。英伟达今年专门写了篇博客，讲怎么让 AI 在大型虚幻 C++ 代码库里少出错，还把它列成公开待解决的难题。这种体量的公司把它当课题做，本身就说明现成工具不够用。
- 编译太慢。从虚幻 4 到虚幻 5，有人冷编译从二十多分钟涨到五十到七十分钟。AI 的优势是快速试错，改一下等一个小时，这个循环基本就废了。
还有一点挺微妙的：虚幻 5.7 自带的 AI 助手被刻意关在沙盒里，读不了项目文件，也执行不了任何编辑器操作，说白了就是个贴在文档上的聊天框。那个对 AI 更友好的新语言 Verse，目前只能在 Fortnite 创作工具里用，做正经游戏用不上。
所以虚幻适合「画面就是产品」的项目，前提是接受 AI 只能当 C++ 副手，碰不了蓝图，搭不了关卡。想让 AI 扛大头的话，它是三个里最差的选择。
Unity 手里最大的牌就是训练数据。C# 是主流语言，Stack Overflow 上有一百多万个问题，再加二十多年的文档、教程和 Asset Store 讨论。单写游戏逻辑，AI 在 Unity 上确实最稳：有开发者记录编辑器脚本第一次跑通的比例接近八成，还有人八分钟搭出了平时要两三天的本地化系统。
但代码这块稳，不代表整个做游戏的流程顺，Unity 的工作流有好几处跟 AI 拧着来。
场景和预制件存成带 GUID 的 YAML，技术上是文本，AI 实际读不懂。同样一个简单场景，Unity 要六十多行密密麻麻的 ID 引用，Godot 十行就够。大量操作还得在编辑器里拖拽、连线、调 Inspector，这些纯文本的 AI 都做不了。C# 在 Unity 里做同一件事还有四五种流派——UnityEvent、C# event、ScriptableObject、消息总线——AI 得先猜你这个项目用的是哪一种。
最说明问题的是社区自己摸出来的变通办法：别让 AI 直接写场景文件，让它写「生成场景的编辑器脚本」，绕回纯代码。Unity 官方的 AI（连带 MCP）2025 年下半年才出测试版，社区普遍反映还不如民间那个一万星的开源版本好用。
钱的问题也在。运行费风波（2023 年 9 月宣布、2024 年 9 月取消）之后，Unity Pro 涨到每个座位每年两千多美元，社区的信任一直没真正修复。Godot 是永久免费的。
然后是 Godot。拿前面那个问题一条条对下来，Godot 的匹配度高得有点离谱。
场景文件（.tscn）和资源文件（.tres）全是纯文本，AI 能直接读、直接 diff、直接改，中间不需要任何转换。这一条 Unity 只做到一半，虚幻完全做不到。
三个引擎按「AI 能否当文本读」排队：Godot 纯文本能读，Unity YAML 半读，虚幻二进制读不了
它是 MIT 开源的，连引擎本身（十万多星）都在训练数据里，AI 不只懂 API，还能读引擎内部实现。GDScript 语法像 Python，门槛低；也可以用 C#，把那份独立于 Godot 的庞大训练数据接进来。
我觉得最关键的还是闭环这块。Godot 从 4.0 起原生支持 --headless，AI 能自己把游戏跑起来、读报错、再改，配上 GUT 测试框架，「写测试、跑、看结果」这条循环不需要人插手。2025 到 2026 年 Godot 的 MCP 工具也爆发了：主力 godot-mcp 近四千星，GoPeak 带九十多个工具，断点调试、截图都有，还有的 server 能让 AI 自己启动游戏、模拟点击、截一张图看一眼、再走下一步。这是所有引擎里最完整的 AI 自检回路，真的很牛。
AI 自检闭环：写代码、跑 headless、读报错、再改，循环不需要人插手
体量也轻。Godot 编辑器大约 50MB，Unity 2GB，虚幻 50GB 起步。对要在 CI 里反复拉起的 AI 流水线来说，这是秒级和分钟级的差距。
商业上的疑虑也在消退。《杀戮尖塔 2》在运行费风波之后从 Unity 迁到了 Godot，2026 年 3 月开测，据报道同时在线峰值 57 万。Godot 在 GMTK game jam 的占比从 2024 年的 19% 涨到 2025 年的 40%，Steam 上的 Godot 游戏两年从 618 个涨到近三千个。
当然坑也有。GDScript 的训练数据确实比 C# 少，而且 Godot 4.0 在 2023 年 3 月把 API 大改过一遍，很长一段时间里，训练截止早的模型会很自信地写出 Godot 3 的废弃语法。这个问题真实存在，但在收窄：据实际在用的开发者说，换上 opus 4.5 之后的模型，再把项目说明写清楚，就很少踩了。
还有一个预期上的问题，我觉得比语法坑更要紧。指望对引擎一无所知、纯靠嘴让 AI 从零做出一个游戏，基本会失败：有人在 Godot 里光实现一个拖拽就试了二三十次，最后弃坑；好几篇 vibe coding 翻车实录，都卡在状态机这种地基上。今年 GDC 的调查数字挺直白的：81% 的开发者用 AI 做调研和头脑风暴，47% 拿它辅助写代码，只有 5% 敢把 AI 放进面向玩家的功能。只能说你自己得先会搭脚手架，AI 才放得大；完全不会的话，它也很难替你从零长出一个项目来。
查完这一圈，怎么选反而简单了。
做原型、打 game jam、图个甩链接就能玩，留在 web，Phaser 加 TypeScript。天花板没我原来想的那么低，WebGPU 还在往上顶，真想上桌面就 Electron 包一层。这条路 AI 跑得最快，浏览器里改一下马上看见结果，闭环最短。
认真做一个能上 Steam 的游戏、想让 AI 扛大头，用 Godot。它把 web 对 AI 友好的那个根保住了，场景、资源、脚本都还是文本，同时性能上限是原生的，配上 MCP server，agent 能自己闭环。想在训练数据上再押一手就用 C#，代价是放弃 web 导出。
画面本身就是产品、要做写实 3A，再考虑虚幻，而且要接受 AI 只帮得上 C++ 那一截。
之前写过想不写代码做三个游戏，也聊过为什么偏偏是 claude code 赢了，思路上其实是一路的。下一个认真做的游戏应该就从 Godot 开始试了，试出什么坑再写。
