11 月 2 日，Kimi 发布了一套游戏开发方案。官方演示里，模型接入 Unity、Unreal Engine 和 Blender 插件，在团结引擎的 Tuanjie Codely Agent 配合下，无人干预连续跑了 20 小时，复现一款游戏，并交出一份可以继续开发的原生工程。 对普通开发者来说，20 小时不是重点；重点是官方那句“直接操作现有工程”。它意味着 AI 开始碰的不再是孤立脚本，而是你的场景层级、资源引用、存档格式和版本历史。Kimi
先看这 20 小时成立的条件。一篇拆解写得很清楚，前提是任务定义足够清晰、验收足够客观；“复现原作”恰好有现成参照物，是 Agent 最容易跑通的那类任务。 换成像“把战斗做得更爽”这样的开放目标，好不好玩没有客观标准，AI 就失去了自查的锚点。演示证明的是“有明确目标时，AI 能长时间执行”，不是“把项目交给它，它自己知道该做成什么样”。知乎
更要命的是，AI 能写代码，却不知道你项目里哪些东西不能动。一位用 Codex 和 Godot 做独立游戏的开发者算过，自己只想加一个手电功能，顺着光照、电池、人物动作、武器合成、昼夜、地图、存档和死亡一路捋下来，牵扯出 44 个需要判断的逻辑关系。 哪些该做、哪些会改变玩法，是设计决策，不是代码生成。AI 可以帮你把清单列全，但前提是你先告诉它项目里有哪些系统、它们怎么互相影响。知乎
这也解释了为什么“改现有工程”比“新建 Demo”难一个量级。Unity 中国 CEO 张俊波在采访里说，现有大模型缺少增量操作的数据，即使拿到完整 Unity 工程训练，模型学到的也更接近一次性完成整个项目，很难处理“把这盏灯变成绿色”之类看似简单的具体要求。 你的项目里还有大量没写进文档的约定：命名习惯、第三方插件、资源导入规则、平台适配分支。这些才是 AI 最容易踩空的地方。游戏葡萄
就算它改对了，验收也省不了。在已有案例里，AI 生成一版界面只要几分钟，但要把菜单层级、美术规范、碰撞判定和性能预算都调到能上线，仍然要人逐项看。有开发者总结得很直接：纯靠指挥 AI 黑箱式修改，很快就会撞上一个永远过不去的信息墙。 Unity 官方分享的一位个人开发者案例里，模型也会在长上下文中反复出错、原地绕圈，或把简单功能做得过于复杂。 他的办法是换模型、重新整理上下文，再让它先读懂项目文档和已有规则。这些动作都不是“按一下生成”能省掉的。知乎Unity官方
权限是另一笔账。Kimi 官方说，使用插件直接改引擎工程，需要拿到项目文件和相应权限。 张俊波也提醒，为了让 AI 完成更多任务，使用者往往会开放很高权限，它可能执行意料之外的操作，给知识产权和隐私带来隐患。 对普通开发者，最低成本的防线不是买更贵的模型，而是分支、备份、diff 审查和可回滚的操作记录。让 AI 在分支上改，永远比在主线上改便宜。Kimi游戏葡萄
工具本身也还没到“装上就能用”的程度。Kimi 的 Blender 插件安装细节还没公开。 Godot 侧的 AI 插件已经能接进编辑器，但版本要求、导出时的残留配置都要自己检查。Breakpoint MCP 的 1.18 版本就用了严格模式，避免导出时留下脏 autoload。 这些细节说明，厂商演示是信号，不是交付。普通开发者现在最该做的，是挑一个边界清楚的小任务，比如改一个 UI 动效、补一段存档逻辑，放在分支上跑一遍，算清楚“每一条被接受的改动”花了多少时间和 token，再决定要不要把权限交出去。知乎哔哩哔哩
AI 改游戏引擎真正省下的，是从“想到一个玩法”到“看到一个能跑的原型”的时间。能不能用好，取决于你能把项目讲多清楚、把验收定多具体、把权限管多严。这三件事，模型暂时还替不了你。
