开源LumioTemplate 打造 AI Native 游戏研发新范式

“Nobody wants a stylus.” —— 乔布斯

2007 年，乔布斯在发布第一代 iPhone 时说，没人想要手写笔。人天生带着十根手指，根本不需要去迁就一根塑料笔。

十九年过去了，今天游戏圈做所谓的 AI Native，却在忙着给商业引擎接 MCP。把大模型塞进为人手和人眼设计的图形软件里，隔着接口一遍遍调工具、翻场景、看截图。

这等于是在给 AI 配一支手写笔。

我想提的概念，就叫 No Stylus。

真正的 AI 原生游戏开发，不仅不需要 MCP，甚至根本不需要依赖传统的商业引擎。

历史总是那么相似

当年给手机配笔，在微软的逻辑里不仅合理，而且必须。

微软当时最大的资产是桌面生态。为了守住这套生态和所谓的兼容性，Windows Mobile 几乎是桌面的等比微缩版。从左上角的开始菜单、右上角的关闭叉号，到几像素宽的滚动条，全盘照搬了桌面逻辑。面对成年人指腹按不中两毫米菜单的物理矛盾，他们不惜代价想了各种修补办法，最典型的妥协，就是配一根塑料笔当鼠标指针的替身。

乔布斯推翻了这种背着包袱修修补补的做法。他不去迁就旧桌面，直接从底层系统和交互架构推倒重做，换上电容多点触控，让人天生的十根手指直接操控屏幕。初代 iPhone 带着极多的短板问世，没有应用商店，不能复制粘贴，甚至不支持 3G。但底层交互的方向是对的，短板后来全能补上。

反观微软，为了所谓的兼容性在错误方向上越走越远。直到 2010 年转做 Windows Phone、再到 2019 年底彻底停止支持，打了十几年补丁也没追回来。

如今游戏圈大搞的 MCP，逻辑如出一辙。

现在的商用引擎是为人类的手和眼睛演化了二十年的庞大系统，核心交互全靠肉眼看视口、鼠标点场景树调数值。大家舍不得这套旧生态，就给引擎开放 API、包一层 MCP 协议，在老系统上到处打洞，好让 AI 钻进来操作。

实际开发笨重不堪。模型想改一个属性，得先调工具遍历场景树，拿回一大堆用不上的资产信息，上下文瞬间被挤占大半。改完一行数据，再等引擎编译、重载域，几十秒过去了。碰到空引用报错，模型看不到全局，只能隔着这层接口反复探查，排查一个简单逻辑能耗掉十几次工具调用。

为了兼容旧体系而到处打洞，随着项目规模和开发需求不断扩展，只会变得越来越脆弱，越来越危险。

AI 天生擅长什么

AI 最擅长什么，大家都有体会。AI 写网页非常舒适。

网页天生由纯文本驱动。改完代码，浏览器毫秒级热更新，控制台报错模型自己能抓，很容易在网页端快速搭建出一整套自洽的玩法循环。

反观商业游戏引擎，无论多开、启动还是编译，流程都极其繁琐。动辄几十个 G 的体量，改一行代码就要等漫长的域重载。

更要命的是协作架构。游戏行业长久以来习惯了用 SVN，这种天生不能并行开发的架构，彻底把 AI 最强大的并行能力锁死了。它本来可以多模型、多分支同时跑，被塞进商业引擎后，却被强制降级成了单线程排队工作。

这无疑是在严重拖慢 AI 的研发效率。

做游戏前期，在网页环境里跑，完全可以不开引擎。

不开引擎，物理和渲染怎么办

做过商业项目的人第一反应多半是质疑。物理碰撞怎么办，骨骼动画和大世界渲染怎么办？

立项第一天死磕这些，是本末倒置。刚体模拟和体积雾对验证玩法帮不上忙，只会带来漫长的调试与编译。立项初期最要紧的，是把核心玩法和数值循环跑顺，让 AI 在轻量环境里毫无阻力地完成验证。

最理想的状态，是既能在网页端实时预览试错，后期又能一键导出到商业引擎直接打包。

做架构的人在立项时要想清楚。项目前期能不能脱离引擎？究竟在哪个阶段才必须依赖商业引擎？把这几件事想明白了，再去谈怎么接回商业引擎。

LumioTemplate 面向 AI Native 的开源架构

基于刚才这条思路，我开源了面向 AI Native 的游戏开发工程模板 LumioTemplate，仓库地址放在了评论区置顶。

这套工程是我在多个真实游戏项目里反复摸索、踩过无数坑总结出来的一套实战积累。它的架构理念很纯粹，彻底面向 AI Native 思想设计，向上兼容市面上所有的 Agent 框架，向下兼容所有的商业游戏引擎。更把策划定调、美术一致性、代码契约和多 Agent 并发，整合成了一套完整的 AI Native 研发管线。

维度	核心能力	带来的优势
上下文管理	玩法规则、美术基准、开发红线和任务进度全部集中在规范目录	不管新开多少次对话，模型每次都能读到最新进度，代码不会越改越乱
配套 LGUI	面向 AI 的轻量 UI 运行时，在浏览器里直接把游戏界面和按键交互做完	摆脱商业引擎漫长的编译等待，改完界面毫秒级热刷新，不用反复干等
全 Agent 兼容	原生遵循统一规范，向上兼容 Claude Code、Codex、Cursor 等所有 Agent 框架	今天用 Claude 拆模块，明天换 Codex 写逻辑，换哪个工具都能接着干
全流程管控	内置策划定调、美术风格基准图库，配合代码规范与自动化审查	画风有样图对照，玩法有规则卡着，不用担心模型自由发挥把项目做偏
多 Agent 并发	先定好配表与接口协议，把功能拆给多个子 Agent 各自写代码和自测	不用卡在商业引擎里单线程排队，几个模型可以同时写不同模块，开发效率直接翻倍
商业引擎兼容	玩法循环与核心逻辑先在网页轻量环境跑顺，向下兼容 Unity、UE 等所有商业引擎	前期省去开引擎和反复编译的时间，后期直接进 Unity 或 UE 套上工业级美术
项目 Agent 自进化	自己记录所有 bug 单，定期总结、归因并做出判断	把每次排障教训直接提炼成新规则，驱动项目 Agent 持续自我进化，越往后写越懂项目

下周预告，探索 LGUI 的上限到底在哪

下周我会发一期视频，专门探索 LGUI 的能力上限。视频里会拿同一张大厅原型图，对比市面上几个顶级模型在 UI 上的能力表现，包括 Claude-Opus55、gpt-6-astra 和 gemini-4-argon。

这组对比的起点，是我用 Image 2.5 生成的一张纯 2D 大厅原型图。

用 LGUI，从这张 2D 图片做到功能完整的 HTML 网页原型，花了三个小时。做完一键导出到 Unity 打包生成 Unity 原型。下面这张截图，左边是导出的 Unity 原型窗口，右边是浏览器里的 HTML 网页原型，两边的界面效果一致

至于几个顶级模型拿着同一张图各能做到什么程度，下周视频里见。

结语

新的生产力刚出现的时候，第一批尝试往往是给旧体系打补丁。把桌面操作系统塞进三寸屏幕再配一支塑料笔是这样，给为人设计的游戏引擎套一层 MCP 也是这样。

对人来说，最顺手的工具是十根手指。对 AI 来说，是纯文本和一个改完马上能跑的环境。

AI 做游戏才刚开始，眼下很像 2007 年 1 月 8 日，发布会的前一天。iPhone 还没上台，满街的手机还配着塑料键盘和手写笔。

Nobody wants a stylus.

我是 LumioGames，做了十年游戏引擎，现在一个人创业。

如果你觉得今天这篇有启发，欢迎点赞、收藏与关注，我们下篇见。