想让 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 一眼就能看全。
两个例子一对比，我只能说，决定 AI 好不好用的不是训练数据有多少，是 API 新不新、稳不稳，再加上 AI 能不能把整个项目看全。所以挑引擎其实该问两件事，这个引擎里的东西 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 这些都做不了。而且同一件事，在 Unity 里用 C# 有四五种流派（UnityEvent、C# event、ScriptableObject、消息总线），AI 得先猜你这个项目用的是哪一种。
社区自己摸出来的变通办法最能说明问题。他们不让 AI 直接写场景文件，而是让它写「生成场景的编辑器脚本」，绕回到纯代码上。Unity 官方的 AI（连带 MCP）2025 年下半年才出测试版，社区普遍觉得还不如民间那个一万星的开源版本好用。
还有钱的问题。Unity 2023 年 9 月宣布收运行费，2024 年 9 月又取消了，这场风波之后 Unity Pro 涨到了每个座位每年两千多美元，社区对它的信任一直没真正恢复。Godot 则是永久免费。
然后是 Godot。拿前面那两条一条条对下来，Godot 对得上的程度高得有点离谱。
场景文件（.tscn）和资源文件（.tres）全是纯文本，AI 能直接读、直接 diff、直接改，中间不用任何转换。这一条 Unity 只做到了一半，虚幻完全做不到。
三个引擎按「AI 能否当文本读」排队：Godot 纯文本能读，Unity YAML 半读，虚幻二进制读不了
它是 MIT 开源的，连引擎本身（十万多星）都在训练数据里，所以 AI 不光懂 API，还能读引擎内部是怎么实现的。GDScript 的语法像 Python，上手门槛低。也可以用 C#，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 起步。AI 流水线要在 CI 里一遍遍把引擎拉起来，这就是几秒和几分钟的差别。
商业上的顾虑也在变少。《杀戮尖塔 2》在运行费风波之后从 Unity 迁到了 Godot，2026 年 3 月开测，据报道同时在线峰值有 57 万。GMTK game jam 里用 Godot 的比例，从 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 开始试了，试出什么坑再写。
