AI到底能不能做独立游戏？
这个问题被反复问了一年。
Pieter Levels去年办的vibe coding游戏比赛“vibejam 2025”收到了一千一百多份投稿，最后能让人玩超过五分钟的没几个。
大部分作品停留在"能跑就行"——画面糙、玩法薄、新鲜感撑不过一晚。质疑声很统一：AI写得了几百行的小玩具，撑不起一个真正有体感的游戏。
最近X上出现了一个反例。
4月15号，一个叫George Kalogeropoulos的希腊开发者发了一条自嘲推文：本来想给Pieter Levels办的 vibejam 2026交个简单游戏，结果掉进了先做引擎的兔子洞。
vibejam 2026是5月1日截止的vibe coding比赛，奖金池3.5万美元，规则要求至少90%的代码由AI生成。
这种比赛按惯例就是糙猛快搞一个交差。George的反向操作是，他先用三天时间写了一个完整的游戏引擎。
引擎跑出来的数据很扎眼。一万个游戏物体在浏览器里同时运行，帧率稳定在每秒144帧。编辑器一次性复制五千个物体，整个界面不卡顿。
这只是他同时在推进的三个项目之一。另一个是用Claude Code和Godot从零做的动作角色扮演游戏，所有3D模型由AI生成，每一行代码由Claude写。第三个就是用上面那台自制引擎做的vibejam参赛作品。
三个项目，一个人，全部依赖AI执行。
他自己的原话是："I just direct."（我只负责指挥）
我把他近一个月的相关推文翻了一遍，工作流细节、踩过的坑、用到的具体工具链全在里面。
整理出来是因为这套东西不像某些AI演示那样只能跑个样子。它是真的能持续产出可玩内容的。
第一个项目：Claude Code直接在Godot里搭场景
3月24日，George放出了第一段视频。一个动作角色扮演游戏的房间已经搭好，主角能跑能砍，正在调魂Like战斗——三连击、翻滚、耐力槽、命中停顿。
他在推文里把工作流写得很清楚。
3D模型由Meshy生成。Meshy是一个图生3D的工具，扔一张图进去，吐出来一个带贴图的3D模型。
代码由Claude Code写。
引擎用Godot，配合一个叫Godot MCP的协议层。MCP的全称是Model Context Protocol，可以理解为AI和软件之间的通用接口。装上Godot MCP之后，Claude就能直接操作Godot编辑器，不再是写代码让你去复制粘贴。
26号他发了完整流水线，被人转疯了。流程是这样的：
先在Nano Banana或者ChatGPT里画概念图，定下房间的视觉调性。然后在Meshy里把概念图变成3D模型，角色动画交给Meshy或者Mixamo做。Mixamo是Adobe的免费角色动画库，提供现成的走路、跑步、攻击动作，把模型上传进去就能自动绑骨。
接着把概念图扔给Claude Code，让它通过Godot MCP直接在游戏引擎里把场景复刻出来。这一步是整套流程里最反直觉的——Claude不是在生成代码，它是在像设计师一样直接操作编辑器。
跑一遍游戏，截屏，把截图喂回Claude的聊天窗口，让它"吐槽"哪里不对。然后根据反馈再改。来回几轮，画面就调到位了。
George自己加了一句：比做网页应用是难一些，但能做。
4月1日他更新了进度。库存系统和可装备的装备已经跑通，角色身上能换装，背包里能堆东西。界面用到的图标贴图是ChatGPT生成的，代码还是Claude Code写的。
他在推文里反复强调一句话：100% AI游戏开发的流水线里，到目前为止没遇到过路障。
这话听上去像是吹的。但你看他每一条更新都附着实际可玩的视频。而且是真的有画面、有交互、有数值反馈的游戏片段。
第二个项目：本来想做个小游戏，结果先做了个引擎
事情是这样发生的。
George想给vibejam 2026交个作业。比赛规则推荐用Three.js（一个跑在浏览器里的3D库），90%的代码必须由AI生成，5月1日前提交。按理说这种比赛就该快速糙猛地搞一个出来。
他的想法是："弄个简单的游戏交上去就行。"
然后他想了一下，做游戏总得有个编辑器吧，不然每次改场景都得手撸代码也太麻烦了。于是他开始做编辑器。
做着做着，他想起来自己当年用C++和OpenGL写过引擎，有底子。既然都做编辑器了，干脆把编辑器做成一个完整引擎算了。
3天过去了。他在4月14号转帖的时候说：浪费了3天在我的引擎上，现在终于开始做游戏了。
接下来一周，他做的事情完全偏离了原计划。
4月15号，他正式承认：本来想给vibejam做个简单游戏，结果掉进了先做引擎的兔子洞。
到4月20号，他放出了引擎的完整功能列表：编辑器、ECS架构、物理系统、粒子、贴花、自定义着色器、动画、脚本、性能分析器、构建流水线。其中ECS是游戏引擎里一种主流架构，把"物体"拆成"组件"和"系统"，特别适合大规模实体的高性能管理。
性能数据是：1万实体稳定每秒144帧。
编辑器一次性复制5000个实体，整个界面不卡顿。
他在另一条推文里解释了这个性能是怎么压出来的。他花了无数小时在性能分析器上优化数据结构。光做到游戏画面流畅还不够，编辑器在批量操作的时候也要保持响应。
界面部分的设计也有讲究。他没有自己重新发明一套UI系统，而是直接在Three.js画布上叠了一层网页画布，让开发者用现成的HTML和CSS定义界面，两层之间通过事件通信。这样既省力，又能让所有界面元素接入引擎的脚本系统。
引擎本身是渲染器无关的。当前用Three.js跑浏览器游戏，未来可以接入桌面级的渲染器做PC游戏。
最关键的一点：引擎自带MCP接口，AI智能体可以直接操作引擎做游戏。这个引擎从设计的第一天起，就是为AI协作准备的。
测试版5月份开放。
第三个项目：用自己的引擎做vibejam参赛游戏
引擎做完之后，George终于可以做vibejam的游戏了。
4月19号他放出了一段视频，一个跑在浏览器里的3D游戏，画面流畅。他在评论里确认：这个游戏是用他自己的Three.js引擎做的。具体玩法他没多说，只展示了画面。
20号他被人质疑：你这引擎跟Godot比有啥意义？他的回复挺直接。
Godot是桌面优先的，他的引擎是网页优先的。两者架构不一样，做事方式也不一样。Godot在它擅长的领域是个非常好的引擎，但这不代表别的引擎没有存在空间。
动作角色扮演游戏用Godot，vibejam参赛游戏用自家引擎，George自己也是这么分工的。两个项目同时推进，工具链互不干扰。
代码层面他用Claude Code和Codex（OpenAI的编程智能体）同时跑。需要手动看代码的时候才打开VS Code。引擎自带的MCP接口让AI智能体能直接读写场景、操作物体、调用脚本。他做vibejam游戏的过程，本身就是在用AI测试自己引擎的"AI友好度"。
"我只负责指挥"，这句话比工具链更值得说
把工具列出来很容易：Claude Code、Codex、Meshy、ChatGPT、Nano Banana、Godot、Three.js、Mixamo。
但工具不是重点。
George在好几条推文里都说过同一句话：他自己只负责指挥。
方向、游戏感觉、画面对错、迭代节奏，这些他自己判断。具体的代码、模型、贴图、动画，由AI执行。
为什么他能做到，别人做不到？
他自己回答过这个问题。他有十年以上的专业软件工程背景，做过游戏引擎，写过C++和OpenGL。代码库变大了不会失控，因为他在动手前会先把架构设计好。AI执行得再快，方向错了就是在堆垃圾。
这一点跟Andrej Karpathy（前特斯拉AI总监）今年早些时候提过的"vibe coding"边界是一致的。AI能加速执行，但需要一个有判断力的人来定方向。差别在于，George把这个边界推到了一个极端：一个人同时推进动作角色扮演游戏、引擎、网页游戏三个项目，全部依赖AI执行。
他还提到了一个细节：角色扮演游戏的数值平衡是他手动把关的。AI能写战斗系统的代码，但要让玩家觉得"打得爽"，这个判断目前还得靠人。
回到开头那个问题：AI到底能不能做独立游戏？
去年那一千多份vibejam投稿大多止步于演示级，问题不在AI，而在于很多人想绕开"理解"直接拿到结果。
George展示的另一种走法是：不绕开理解，把执行交出去。
他知道一个引擎应该有什么模块，知道一个动作角色扮演游戏的战斗节奏怎么调，知道一个3D模型扔到场景里光线该怎么打。
这些判断他做得出来，AI才能配合得上。
这两年AI编程工具的更新速度，已经让"独立开发者能做的事情"和"小团队能做的事情"边界开始模糊。
George自己说过，再过几年，一个人做雄心勃勃的项目会变得完全现实。
vibejam 2026在5月1日截止。
届时大概率会出现一批用类似工作流做出来的游戏。
George的引擎测试版也在5月开放。
如果你正在试着用AI做游戏或者做工具，George这套流程值得反复看几遍。他用的工具大家都能拿到。真正稀缺的是他展示出来的协作姿势：
人定方向，AI执行，截图吐槽，迭代到位。