AI 生成概念图，表现游戏场景从线框到实体的构建过程
做一款动作游戏，策划写下“闪避之后可以反击”只要几秒。等到真正试玩，团队才会知道闪避结束后留多少时间给玩家反击、敌人的动作能不能看清，以及连按两次按钮会发生什么。原型的用处，是尽早把这些争论变成可以用手柄验证的问题。
11 月 2 日，月之暗面发布游戏开发与创意工作解决方案。方案结合 Kimi K3.1 系列模型、Kimi Code、Kimi Work 和专业工具插件，可以连接 Unity、Unreal Engine、Blender 等软件并操作工程。在官方展示的 Godot 案例中，系统根据参考素材和玩法要求搭建了一个 2.5D 动作游戏原型，包含挥剑、闪避和格挡，并利用渲染画面及试玩录像检查修改结果。
另一项与 Unity 中国合作的展示把交付推进到工程层面。按发布方披露，系统在一次演示中连续运行约 20 小时，期间没有人工干预，并交付了可继续开发的原生工程。这次演示记录了一个具体任务的结果。不同项目所用的引擎版本、素材规模和现有代码结构会改变工作的难度。
对负责立项的人，可试玩版本已经足以检验一个玩法。对接手工程的开发人员，最先要看的可能是另一组问题：项目能否在团队的环境里打开，场景和资源是否容易找到，核心规则集中在哪里，下一次改动又是否会破坏既有功能。两个团队即使拿到同一个原型，也可能给出不同的验收结论。
这也是引擎接入值得关注的地方。可以进入工程并查看运行结果，意味着 AI 有机会自行完成一轮修改和验证。团队则需要决定哪些操作可以在试验分支里自动完成，哪些资源或设置一旦改动就要留下记录、由人复核。
下一次有价值的演示，可以从一个陌生开发者接过工程开始。让他修改一条战斗规则、重新运行原型，再交给策划试玩。这个接力过程能说明，团队究竟得到了一次可看的演示，还是一份已经进入制作流程的工程。