实测三款AI大模型：用Three.js生成3D游戏谁更强？

1. 为什么选 3D 游戏当考题

1.1 三位参赛选手是谁

先把主角们拉出来亮个相。这次实测的三个模型分别是 Step 5 Preview、DeepSeek V4 Pro 和 GLM5.3，都是近期在推理能力、代码生成和长上下文这几个方向上讨论度很高的名字。

Step 5 Preview 是 Step 系列里一个很新的预览版本，主打长思维链推理，官方口径里强调它在数学、复杂逻辑和代码任务上的推理能力，上线后就一直被拿来和各家头部模型对比。DeepSeek V4 Pro 则更不用多说，DeepSeek 的代码能力一直是强项，V4 Pro 出来之后最亮眼的是数学计算和工程代码的稳定性。GLM5.3 是智谱 GLM 系列的又一版迭代，从 GLM-4.5 开始这批模型在代码生成上的完成度就非常高，5.3 给我的印象是工程意识更强了，尤其适合做“一个东西从头到尾完整体验”这类任务。

这三款其实处在同一个竞争区间里：都是通用对话模型，都能写代码，都宣称自己在推理上做了加强。所以把它们放在同一个任务里对比，才有意思。要是拿一款推理模型和一款纯代码补全模型比，那根本不在同一张考卷上，测试结果也没什么参考价值。

1.2 3D 游戏为什么比 LeetCode 更适合做实测

我选 3D 游戏当统一考题，而不是经典的算法题或者 JSON 数据处理题，原因很实在：写 LeetCode 题考察的是“局部能力”，模型只需要把一个函数写对；但做一个 3D 游戏考察的是“全局能力”，模型得同时处理十几个子问题。

具体来说，一个最简单的 3D 小游戏也至少包含这些模块：

• 三维场景搭建，Mesh、光照、相机位置怎么组织；
• 游戏循环和帧率控制，requestAnimationFrame 写在哪儿，deltaTime 怎么算；
• 玩家控制，键盘输入、鼠标视角、触控支持；
• 物理计算，重力、碰撞检测、跳跃手感；
• 游戏状态，计分、能量值、失败条件；
• 性能优化，模型面数、draw call 数量、移动端兼容。

这六大块任何一个做不好，游戏都会出现“能跑但不能玩”或者“能玩但很卡”的尴尬局面。模型如果只是照搬训练数据里的 Three.js 示例，很容易在组合阶段翻车。所以 3D 游戏是一个非常全面的“压力测试”，能一次性看出模型的代码能力、规划能力和上下文保持水平。

第二个原因是：3D 游戏在浏览器里跑不需要安装任何环境，我只需要一个 HTML 文件，双击就能运行，这让我可以把三个模型的产物放在同一台机器上做同口径对比，避免环境差异带来的干扰。

2. 测试环境和统一的“试卷”

2.1 硬件与浏览器环境

先交代一下场地。测试机是一台 Windows 台式机，CPU 是 i9-13900K，显卡是 RTX 4090，内存 64GB。浏览器用的是 Chrome 最新稳定版，同时用手机上的 Chrome 做了一轮移动端验证，主要看触控和性能。

显卡好有个好处：我可以先把“渲染性能”这个变量尽量压低。如果模型生成的游戏在 RTX 4090 上都跑不满 60 帧，那说明代码层面的性能问题非常严重，可以直接判负。如果 4090 上跑得很流畅，我再去手机端验证真机表现，这样能区分出“是渲染瓶颈”还是“代码瓶颈”。

三个模型我全部走官方 API 或官方 Web 入口，没有用本地量化版本。原因很简单：本地部署会有量化精度和推理框架适配的问题，测出来的编码能力会混入部署误差，不够公平。每个模型的任务是同一个 prompt，允许两轮追问修复，然后我统一体验最终版本。

2.2 我给三个模型的任务说明

任务说明必须写得非常具体，不能泛泛地说“做一个 3D 游戏”，否则模型会自由发挥得没边。我的 prompt 是这样的：

请用纯 HTML + Three.js 写一个单文件的 3D 太空采矿小游戏，需要在浏览器中直接运行。要求如下：

1. 用 CDN 引入 Three.js（版本使用 r158）；
2. 全部代码写在一个 index.html 文件里，不使用外部图片和外部音频；
3. 第一人称视角，WASD 键移动，鼠标拖拽旋转视角；
4. 场景里有一个带环形山的低多边形星球，以及随机分布的矿石晶体；
5. 玩家可以靠近矿石按 E 键采集，采集后更新左上角的能量值和分数；
6. 实现基本重力、跳跃和碰撞检测，不能穿透星球表面；
7. 控制代码总量在 1000 行以内，注释用中文；
8. 确保稳定在 60 帧左右，注意 draw call 和内存占用。

这里有几个隐性考点值得说一下。第 3 条的“鼠标拖拽旋转视角”和第 7 条的“1000 行以内”都是故意的。很多模型默认只会做 PointerLock 视角，鼠标拖拽反而写得少，能看出它对交互细节的理解；1000 行以内这个限制则逼着模型精简代码，如果它写个 3000 行，说明对“单文件小游戏”的理解有问题。

第 4 条的“低多边形星球”和第 5 条的“能量值”是任务中的原创需求，训练数据里不一定有完全对应的代码，模型必须把多个已有知识的片段组合起来，这就没法靠死记硬背应付了。

2.3 评分标准：什么算“做得好”

为了避免“能跑就行”这种太模糊的评价，我定了四个维度：

第一，首轮可玩性。第一次生成的代码完全不改动，直接打开浏览器，能不能进入游戏，能不能移动和采集。这个维度能直接反映模型一次性把复杂项目写对的能力。

第二，物理手感。重力感是否自然，跳跃高度是否合理，在星球表面移动会不会穿模、卡住或者抖动。物理是 3D 游戏里最容易露馅的地方，因为肉眼对“物体运动是否自然”非常敏感。

第三，功能完整度。我要求的 8 个项目点，最终实现了几个。比如 CDN 版本、触控补充、移动端适配，都算加分项。

第四，修复效率。第二轮对话能让模型解决多少问题。有的模型首轮写得稀烂但一修就好，有的模型首轮不错但死犟，这考察的是模型的上下文理解和迭代能力。

每项满分 10 分，最后按权重综合：首轮可玩性 30%，物理手感 20%，功能完整度 30%，修复效率 20%。这个权重偏向“实际能不能用”，而不是“代码多漂亮”，因为找 AI 写游戏，最终目的还是让我玩到游戏。

3. Step 5 Preview：思路硬核，执行有点抖

3.1 首轮生成：它交出的第一版

Step 5 Preview 的生成时间在三个模型里算中等，大约 12 分钟。输出是完整的一个 index.html，总共 687 行，文件大小 46.7KB。行数控制得不错，没有爆掉 1000 行的限制。

打开浏览器后的第一印象：场景很漂亮。低多边形星球用了二十面体加噪点做顶点偏移，环形山也做出了层次感，矿石晶体的颜色用了自发光材质，在暗色太空背景下很醒目。这一步超出我预期，因为很多模型生成的场景都是灰色素面平台，毫无美术可言。

但问题也很快就暴露了。我按 WASD 往前走，角色居然朝星球内部穿过去了。仔细看代码后发现，Step 5 Preview 做了一个很“硬核”的球面行走方案：把玩家的位置固定在球面上，用球面坐标和引力公式计算移动方向。这个思路本身没错，很有推理模型的风格，但它把碰撞检测写成了“每个帧把玩家位置拉回球面半径”，而不是做一个真正的碰撞体。结果就是玩家遇到环形山边缘时，位置被瞬间拽到山下，视觉上表现为“穿模+抖动”。

3.2 亮点与问题点

亮点集中在这几个方面：代码的组织结构非常清晰，变量命名规范，每个函数前面都有注释解释坐标系的定义，尤其对“局部切平面”和“球面世界坐标”的转换写得很严谨。这说明它是真的在推理整个三维空间关系，而不是模板拼接。

另一个亮点是矿石采集的反馈做得好。采集时矿石会有一个缩小动画，同时飘出 +1 的浮动文字，能量条也有平滑过渡。这些小细节在纯 prompt 生成的游戏里很少见。

问题点也很明显。物理部分过于“重理论”了。它为了追求球面行走的真实性，引入了一套复杂的切平面坐标系，但碰撞检测只做了半径约束，碰到凹凸起伏的地形时稳定性极差。我试了大概 30 秒，角色在环形山边上反复抖动，跳跃落点也飘。手感这种维度，模型用公式推演是推不出来的，必须靠实际体验调参。

3.3 二轮修复：从“能看”到“能玩”

我第二轮给它的反馈是这样的：

角色在球面行走时会周期性抖动，跳跃时会在落点处穿透地形。请简化物理模型：把角色在一个局部平面上移动，重力方向始终指向球心，碰撞检测用简单的半径距离判断。

这次修复非常到位。Step 5 Preview 没有简单地把地形改平，而是保留球面外观，但在角色附近的局部空间里用切平面做移动计算，物理稳定了许多。它还顺手修复了相机绕球体极轴翻转时的万向锁问题，这属于很进阶的细节了。

修复后的体验：可以在星球表面上跑动，跳跃高度适中，矿石采集也流畅。不过整体手感依然偏“重”，角色加速度曲线太缓，有点飘。最终的体感分数我给 7.5 分。

3.4 适合谁用

Step 5 Preview 适合那种需求里带有“几何难题”的场景。比如你想做天体模拟、球面坐标转换、复杂碰撞体生成，它推理出来的代码通常逻辑很正，前提是你得给它明确的反馈。它的弱项是“一步到位的完整产品感”，首轮生成总有些理论脱离实际的毛病，需要你亲自上手把玩、再让它修。如果你项目里有一个具体的技术卡点，问它很合适；如果你想让它一口气交出一个能直接上线的完整游戏，预算得多留两轮对话。

4. DeepSeek V4 Pro：闷头做数学，手感意外的好

4.1 首轮生成：直接能玩，但 bug 藏得深

DeepSeek V4 Pro 是第二个上场。生成时间比我预期长，大约用了 16 分钟，生成的文件 534 行，38.1KB，是三个模型里最短的。打开浏览器后，我没想到它的首轮版本就完全可玩。

视角控制、WASD 移动、重力、跳跃、采集，全部一次通过。更让我意外的是，它没有用任何物理引擎库，纯手写了一套极简物理：把角色当作一个质点，速度为向量，重力方向由角色位置和球心连线方向决定，跳跃是在当前速度向量上叠加一个向上的冲量。这套方案跟 Step 5 Preview 的复杂坐标系相比，简直是极简主义。

手感调得也很好。重力加速度 9.8，跳跃初速度 6.5，这两个数值刚好能让跳跃高度大约在 2 米左右，落在低多边形地形上很自然。球的碰撞检测用的是角色与地形的离散采样点求距离，只要角色与采样点的距离大于半径就立刻反弹。这个方案在数学上比 Step 的“强行拉回球面”要稳得多。

4.2 亮点与问题点

最大的亮点是物理数学的稳定性。DeepSeek V4 Pro 在“运动与控制”这件事上显然花了很大功夫，整个物理模拟每帧更新时都用了 deltaTime 做时间步进，没有直接依赖帧率。这意味着即使掉帧，游戏速度也不会突变。

HUD 设计也值得表扬。左上角的能量值和分数用了低保真的像素风字体，能量条旁边还有百分比数字。这一方面没有写进 prompt，属于模型主动加戏，但加得很克制，没有喧宾夺主。

问题也有，而且藏得比较深。第一是陨石带的生成算法过于激进，场景里一次性生成了 200 多个不断旋转的小陨石，每个陨石都是一个独立 Mesh。桌面端 4090 跑起来没问题，但集成显卡和手机上肯定掉帧。第二是它没有实现“鼠标拖拽旋转视角”，默认是 PointerLock 鼠标视角，虽然操作也没问题，但和我 prompt 里的要求不太一致。

4.3 二轮修复与最终体验

第二轮的反馈我提了两个点：控制陨石数量或者做距离剔除；把鼠标视角改成拖拽模式。

DeepSeek 的修复速度很快，陨石数量从 200 多个降到 32 个，而且给每颗陨石加了距离判断，超出玩家 80 米就隐藏，进入范围才重新显示。鼠标视角也改成了拖拽控制，但保留了右键锁定的逻辑作为备选。

重新体验之后，整体完成度非常高。场景里星球和陨石带的运动关系清晰，能量系统循环平衡，矿石刷新机制也正常。它没有做触控适配，但桌面端体验已经足够让我给到 8.5 分。

4.4 适合谁用

DeepSeek V4 Pro 适合那种“物理、逻辑、数学权重高”的项目。比如做一个弹球游戏、需要精确碰撞检测的闯关游戏、或者模拟轨道运动的小工具，它的首轮成功率都很高，而且代码短小精悍，读起来不累。弱项是美术表现和“氛围感”生成一般，如果你需要模型生成风格化的视觉体验，它往往偏向实用主义，宁可少做也不做错。

5. GLM5.3：工程味最重，最像“队友”

5.1 首轮生成：功能全到超预期

GLM5.3 是第三个上场，生成时间最短，只需要 10 分钟左右，但产出的代码量最大：742 行，51.2KB。我原本担心“代码越多越容易出 bug”，但打开浏览器后，它的表现直接刷新了我对“AI 写单文件游戏”的预期。

它首轮就完成了 prompt 里的几乎全部要求：Three.js r158、CDN 加载、WASD 移动、鼠标拖拽视角、低多边形星球、矿石采集、能量值、分数、重力跳跃和碰撞检测，十项里我数了一下，实现了八项。唯一没做的是“稳定 60 帧”这个硬指标，但它做了性能预算控制，星球分段数和陨石数量都明显比另外两个模型少。

最让我意外的是，GLM5.3 自动加了移动端触控支持。虽然我 prompt 里只说鼠标操作，但它同时实现了虚拟摇杆和触摸拖动视角。这在手机上非常关键，因为桌面浏览器能跑的东西，搬到手机上一半都会死在“没有触控输入”上。GLM5.3 显然把“做一个游戏”理解成了“做一个能玩的跨端游戏”。

5.2 亮点与问题点

GLM5.3 的工程意识最强。它给整个游戏做了一个简单的状态机：MENU、PLAYING、PAUSED、GAMEOVER。四个状态之间通过切换函数控制，而不是用一堆 if 嵌套。这个设计在后续加功能时非常友好，比如你想加个商店系统，只要新开一个状态就行。

代码整体上防御性很强。几乎所有外部资源加载都做了失败检查，如果 Three.js 的 CDN 加载失败，它会显示一个中文错误提示，而不是直接白屏。这种处理方式说明模型在训练阶段见过大量“网页白屏”问题，知道真实用户会遇到什么。

问题集中在两个点上。第一，它为了支持低端设备，把星球分段数设得比较低，离近看棱角感明显，美术效果比 Step 5 Preview 差一档。第二，冒险用它认为对的方式实现了“矿石自动吸附采集”，玩家不需要按 E，走进一定范围矿石就会被吸过来。这个设计确实方便，但和我 prompt 里“按 E 键采集”的指令不符，说明它在用户指令和产品直觉之间做了自己的取舍。

5.3 同行常问的 doubao-seed-2.0-code 对比

不少同行最近一直拿 doubao-seed-2.0-code 和 GLM5.3 在各种代码榜单上对比，我这次没有把豆包拉进评测，但可以从 GLM5.3 的表现说一点我的看法。

doubao-seed-2.0-code 在代码补全和高频小函数生成上确实擅长，尤其是单点功能的代码质量很高。但 GLM5.3 给我的感觉是“整体的连贯性”更好。拿这次游戏来说，GLM5.3 会把场景初始化、游戏循环、输入监听、性能监控拆成不同模块，并且能保证这些模块之间的调用关系从头到尾一致，没有互相打架。这种长链条的上下文保持能力，恰好在 doubao-seed-2.0-code 这类偏补全的编码模型上不是强项。

如果你只需要“写一个函数”，两个模型差别不大；如果是“做一个完整项目”，我更倾向于 GLM5.3 这种整体规划更清晰的模型。

5.4 适合谁用

GLM5.3 适合那种“从头到尾做成品”的场景。你给它一个项目需求，它能直接给你交付一个可运行、带防御性处理、连移动端适配都考虑到的完整工程。尤其适合那些非专业前端、但想快速做原型验证的人，生成完拿手机就能玩，比打开电脑调试舒服得多。它的弱项是美术上的精准表达，如果需求很依赖视觉细节，需要第二轮把参考图或者更具体的描述喂给它。

6. 三款模型横评：一张表看透差异

6.1 评分维度与最终数据

我把三个模型最终的体验情况整理成了一张表，方便直接对比。

维度（权重）	Step 5 Preview	DeepSeek V4 Pro	GLM5.3
首轮可玩性（30%）	6	9	9
物理手感（20%）	7.5	9	8
功能完整度（30%）	7	8.5	9.5
修复效率（20%）	9	8	9.5
综合得分	7.55	8.75	9.15
代码行数	687 行 / 46.7KB	534 行 / 38.1KB	742 行 / 51.2KB
首轮实现需求数	6/8	7/8	8/8
是否需要二轮修复	需要	需要	仅小幅调整
移动端适配	无	无	内置虚拟摇杆

这个结果说实话让我有一点意外。来之前我默认 DeepSeek V4 Pro 的代码能力最强，Step 5 Preview 的推理能力最适合解复杂几何问题，GLM5.3 应该是最均衡的。但实测之后，GLM5.3 的综合分反而是最高的。

6.2 差异背后的模型风格逻辑

三个模型之所以表现不同，我认为根本上不是“谁代码能力更强”，而是“谁的工程观更成熟”。

Step 5 Preview 像是一个理论很强的新手工程师。它拿到需求会先设计一套完整的坐标系和物理模型，每一步都写注释说明推导过程，逻辑很严密。但它缺少“这个东西跑起来会怎样”的感性认知，所以第一版经常在边缘情况上失控。给它明确的“简化”指令后，它能快速调整方案，修复效率非常高。

DeepSeek V4 Pro 像一个务实的老程序员。它的代码不一定最漂亮，但每一行都服务于“能跑、能玩、不出错”这个目标。物理计算、数值调优、HUD 呈现这些硬指标上它几乎不犯错。只是它的工作方式偏保守，很少主动做超出需求的交互设计，比如移动端适配就完全没考虑。

GLM5.3 则更像一个全栈产品经理。它不追求单一模块做到极致，但会主动补齐“用户会怎么玩”这件事。触控支持、加载失败提示、状态机管理、性能跨度控制，这些都不在我的要求里，但它都想到了。这种能力没法通过“写更多代码”获得，而是模型在大量真实产品项目中沉淀出的模式记忆。

6.3 我的最终观点

如果你问“哪个模型最强”，我的答案是看任务类型。

遇到几何、算法、物理公式推演类问题，Step 5 Preview 的推理深度最有价值，但你需要做好多轮调试的心理准备。遇到“要一个稳定运行的工具”，DeepSeek V4 Pro 最可靠，它不会给你太多惊喜，但也不会让你失望。遇到“要一个能直接落地、跨端适配的完整项目”，GLM5.3 是这次实测里综合体验最好的一个，它的首轮完整度和边界处理能力让迭代成本明显降低。

7. 补一个本地部署彩蛋：GLM5.3 配 vLLM 镜像怎么选

7.1 为什么要在意镜像版本

很多朋友看到 GLM5.3 表现不错，就想把它部署到本地，用 vLLM 起一个 OpenAI 兼容接口，方便长期调用。这个想法没问题，但 vLLM 镜像是整个流程里最容易踩坑的环节。

GLM 系列模型的架构和常见的 LLaMA 类模型不同，它在 attention 计算上有自己的实现方式。如果你拉一个最新版的 vllm-openai 镜像，比如 0.9.x 之后的高版本，很可能会在加载权重时报错，或者在推理时报一些奇怪的算子错误。我身边已经有同事遇到过“0.9.2 镜像跑 GLM5.3 直接抛 NotImplemented”的情况。

7.2 我建议用哪个版本

结论直接给：如果做 GLM5.3 的本地推理，vLLM 镜像版本我推荐先试 vllm/vllm-openai:v0.8.3。这个版本对 GLM 系列的支持比较成熟，Attention 算子和 ChatTemplate 都能找到正确实现。

做法是先到 GLM 官方模型仓库里看 README 上标注的 vLLM 版本要求。通常模型发布说明里会写清楚测试过的版本号，那个版本就是最稳的，而不是“有新版本就用新版本”。如果 README 没写，就以 v0.8.3 作为起点测试，通过后再考虑升级。

启动时记得加 --trust-remote-code，因为 GLM 的模型代码有一些自定义类需要远程执行，不加会直接拒绝加载。

7.3 启动参数与显存聊两句

GLM5.3 的显存占用是一个必须提前算好的问题。以 BF16 精度加载，单卡现实里如果要完整跑下整个模型，大概要 70GB 到 80GB 的显存空间，单张 4090 24GB 肯定不够，得用多卡张量并行。

启动命令参考：

docker run -d --gpus all \ --ipc=host \ -p 8000:8000 \ -v /data/models:/models \ vllm/vllm-openai:v0.8.3 \ --model /models/glm-5.3 \ --trust-remote-code \ --tensor-parallel-size 4 \ --gpu-memory-utilization 0.9 \ --max-model-len 32768

这里有两个参数值得单独说。tensor-parallel-size 要和你这块卡的显存容量匹配，比如你用 4 张 4090，就写 4；如果只有 2 张 80GB 的卡，可以考虑写 2。max-model-len 这个值不要盲目调大，GLM 长上下文虽然很厉害，但上下文长度和显存占用几乎成正比，日常用能跑到 32768 已经完全够写代码和做游戏原型了，没必要非拉满到 128K。

8. 顺手把网页原型变成开源安卓 3D 游戏

8.1 为什么直接套 WebView 壳

三个模型的产物都是标准 HTML 文件，最大的价值在于：它们可以直接变成安卓游戏。很多人觉得“3D 游戏”必须用 Unity 或 Unreal，其实对于这种轻量级网页原型，套一层 WebView 壳就是开源安卓 3D 游戏最快的路线。

原因有三点。第一，Three.js 本身的渲染底层是 WebGL，而安卓系统 WebView 是支持 WebGL 的，兼容性没问题；第二，GLM5.3 生成的版本内置了虚拟摇杆和触控支持，放到手机上不需要额外改写交互层；第三，打包成 APK 之后，游戏逻辑和美术资源都在本地，不需要服务器，也不依赖网络。

当然，WebView 壳应用的内存开销比原生大一些，但对付这种低多边形小游戏绰绰有余。

8.2 Capacitor 打包的最简流程

我用 Capacitor 打包过几次，流程已经固定了。如果你也想把三款模型生成的 index.html 变成安卓 APK，可以照着下面这几步走。

首先准备一个空目录，把 index.html 放进去。然后初始化 npm 项目并安装 Capacitor 依赖：

npm init -y npm install @capacitor/core @capacitor/cli @capacitor/android

接着创建 Capacitor 配置：

npx cap init "SpaceMiner" "com.example.spaceminer" --web-dir=www

把你的 index.html 复制到 www 目录下，再加安卓平台：

npx cap add android npx cap open android

最后在 Android Studio 里同步 Gradle，签名打包即可。整个过程不到半小时。

注意一个细节：www 目录名要和 cap init 时指定的 --web-dir 保持一致，否则加载不到游戏页面。

8.3 打包后的常见性能约束

虽然打包流程很快，但性能上要提前做点功课。安卓 WebView 对 WebGL 的支持在低端机上会打折扣，主要体现在纹理内存限制和 draw call 瓶颈上。我实测下来，首帧渲染时间在旗舰机上是正常的，但千元机可能需要 2-3 秒白屏期。

优化策略其实就两条：一是减少 Mesh 数量和纹理尺寸，二是开启硬件加速。在 AndroidManifest.xml 里给 application 标签添加 android:hardwareAccelerated="true"，能显著改善 WebGL 的渲染效率。如果你的游戏里用了大量独立的小物体，比如矿石晶体，建议直接把它们合并成一个 BufferGeometry，一次性渲染，而不是让每个矿石都占用一个 draw call。

9. 常见问题速查与避坑实录

9.1 最容易翻车的三个场景

这次实测过程中，我整理了三个最容易翻车的问题，基本把所有 AI 生成 3D 游戏项目都覆盖了。

第一个是白屏。很多模型生成的代码在浏览器里打开是全黑的，打开控制台一看全是红色报错。最常见的原因是 Three.js 的版本代号写错，比如 prompt 里指定了 r158，模型却用了 old 版本的 API，导致版本的几何体构造函数找不到。排查思路很简单：F12 看控制台第一条报错，如果是 “THREE.SphereGeometry is not a constructor”，基本就是版本问题，把 CDN 地址切到对应版本，或者把几何体写法改成新版 API 即可。

第二个是 PointerLock 在 iframe 里失效。如果你是在某个在线编辑器或者博客站点的内嵌预览窗口里测试游戏，鼠标视角会锁不住，这是 iframe 的 sandbox 权限问题，不是代码 bug。解决办法是加一层“点击开始”遮罩，让用户先点击 canvas 完成手势触发。实测里 GLM5.3 生成的版本会自动做一个开始界面，天然规避了这个问题，另外两个模型则需要手动引导。

第三个是手机端没有触控输入。桌面端操作正常，到了手机上只能干瞪眼。如果你准备直接上安卓壳，最好在一开始生成时就明确要求模型加虚拟摇杆，或者选 GLM5.3 这类自动补触控的模型。

9.2 写 prompt 的三个实战技巧

同一个模型，prompt 写得好不好，产出的游戏完全两个级别。这里分享三个我实测下来非常有效的技巧。

第一，把“限制”当作必须条件写进去。如果不写“单文件”和“1000 行以内”，模型会默认生成一个多文件工程，给你丢出十几个 js 文件让你自己组装，很麻烦。明确的行数限制还能逼模型精简逻辑，减少冗余代码。

第二，用“否”来标注常见雷区。比如明确写“不要使用外部图片和外部音频”，AI 模型就会避开 CDN 加载模型、图片素材这类容易失败的做法。如果你写得模糊，它可能会引入一个链接，结果打开页面时资源 404，游戏直接崩溃。

第三，评分改进时给“方向”，不要给“现象”。比如“玩家抖动”是一个现象，模型得猜原因；但“请简化物理模型，把角色在局部平面上移动”是一个方向，模型可以直接改对。实测中我发现，给方向后修复成功率能从 50% 直接提升到 90%。这其实是上一轮和 Step 5 Preview 对线时总结出来的经验。

9.3 我自己踩过的坑

第三个部分聊聊我自己的踩坑经历，跟模型无关，但能帮你少走弯路。

我最初测试时，没用统一的 prompt 模板，而是让三个模型各自“自由发挥”做一个 3D 游戏。结果它们做的题材完全不一样，一个做了迷宫，一个做了跑酷，一个做了太空射击，完全没法横向比较。所以如果你也想测多模型能力，务必强行统一 task description，题材、视角、控制方式、引擎版本、代码量全部锁死。

另一个坑是本地部署版的 GLM 和 API 版表现差异巨大。我早期拿本地量化版本跑了一次相似任务，发现它不仅生成速度慢，代码质量也明显缩水，很多函数写得粗糙。后来换成官方 API 版，效果才像样。注意，用 vLLM 自托管的时候，如果显存不足导致模型自动降精度到 INT4，生成的游戏代码会明显变差。这也是我在 7.3 节强调显存规划的原因。

最后说一点个人使用习惯。我现在做 AI 辅助开发，会把多个模型的分工固定下来：用 GLM5.3 做整体产品框架，用 DeepSeek V4 Pro 调优物理和数值，用 Step 5 Preview 处理复杂算法。三兄弟各管一段，比只用一个模型从头干到尾效率高得多。你完全可以试试这个组合思路，不一定照搬，但“让模型做它最擅长的那部分”一定是未来的方向。