★ FEATURED ARTICLE 1. 为什么拿“同一个 3D 游戏”当考题先说结论拿三个 AI 模型同做一个 3D 游戏不是为了看谁“能写代码”——现在能写代码的模型太多了。我想测的是在同一个需求、同一段提示词、几乎没有人为干预的前提下谁能在最短时间内交出一个“能玩的、不翻车的、可以一直迭代的”3D 游戏。这个念头来源于一次实际的工作场景。上个月我在做一个小型产品 Demo需要一个带碰撞检测的 3D 场景来展示交互逻辑。当时随手用某个模型生成了一段 Three.js 代码浏览器打开画面是出来了但是角色直接穿墙、相机疯狂抖动。改了两轮之后发现——改 AI 写的代码比让 AI 自己重写还难。因为你不确定它当初用的是哪个 API 版本、哪个坐标系约定。所以这次我给自己定了个测试规则同一个游戏需求同一个初始提示词三种不同的模型来生成跑通后我再手动验收包括手感、性能、代码可读性。游戏题目选的是“3D 俯视角房间寻物”——不算太简单也没有难到超出大模型的能力边界。它正好覆盖了几个典型的 AI 编码难点三维空间坐标、碰撞检测、相机控制、随机物品生成、交互拾取。这款游戏的需求描述我写得非常具体使用 Three.js 实现一个 3D 房间场景玩家通过键盘 WASD 控制一个小球滚动房间内有随机生成的障碍物立方体和可收集物品小圆球物品收集后左上角显示得分支持鼠标拖拽旋转视角滚轮缩放碰撞检测要求小球碰到障碍物要停下来不能穿模玩家走进物品周围 0.5 米范围内自动拾取为什么选“寻物”而不是“跑酷”或者“射击”因为寻物玩法对空间关系的要求非常高碰撞检测、相机跟随、物体分布这些系统之间的耦合程度恰到好处。太简单了比如一个旋转立方体看不出模型差异太复杂了比如多人联机 FPS又超出了 prompt 一次性生成的能力很难公平比较。我另外加了一个硬性约束尽量让模型一次生成一个完整的 HTML 文件所有 JavaScript 内联在script标签里方便直接双击打开测试。这是考虑到大部分用 AI 做小游戏的读者最关心的就是能不能快速在浏览器里跑起来。三个模型我选择了 Step 5 Preview、DeepSeek V4 Pro 和 GLM5.3。后面我会逐个展开实测过程但先按下不表说说我对它们的基本预期。2. 三个选手的摸底定位不同策略也要不同用 AI 写代码这件事有一个容易被忽略的常识不同模型的“脾气”差异很大。有的模型天生擅长结构性任务——你给它一个清晰框架它填细节填得特别好有的模型则是“生成喷射机”——第一轮就吐出来 500 行代码看起来很壮观但隐藏 bug 同样壮观。我在实测前先给三个模型做了个简单的摸底判断然后针对性地微调了提示词策略。2.1 Step 5 Preview重推理模型的代码表现Step 5 Preview 给我印象最深的是它的推理链路——它会在生成代码之前先给出“思考提纲”把坐标系、碰撞方案、类结构拆解清楚了再动手。这次实测里我特意没有关闭它的推理模式想看看它是否能主动预判到“小球撞到障碍物之后的位置回退计算”这类细节。这一代模型的好处在复杂逻辑上特别明显。三维空间里最常见的一个坑就是碰撞检测的“穿透深度”计算不对导致物体在紧贴墙面的瞬间抖个不停。Step 5 Preview 在首轮生成时就用了“移动前预测 碰撞后回退”的方案而不是先移动再检测这个思路是标准物理引擎的做法算是不错的预判。2.2 DeepSeek V4 Pro代码生成效率与代码量DeepSeek V4 Pro 的策略倾向是“多快好省”。相同需求下它生成的代码比其他两个模型少大约 20%函数封装也更紧凑——但代价是某些边界情况的处理不够显式比如“小球从侧面撞击障碍物”和“小球从顶部斜插入障碍物”用了同一个碰撞分支。实际测试中这种简化的问题就会暴露出来。后面我会详细说。对于追求快速出 Demo 的人来说这个模型很合适——前提是你得自己兜底做一轮 review。2.3 GLM5.3多轮对话的一致性GLM5.3 是我日常用最多的模型之一它的特点是在多轮修改时不容易“钻牛角尖”。很多模型改了一轮之后会偏离用户上一轮的明确指令但 GLM5.3 的上下文跟随能力比较稳。但是它的首轮生成质量相对保守——代码跑通基本没问题但视觉表现和代码结构都偏“教科书”风格。好处是稳坏处是没有惊喜。在需要“按复杂需求一次成型”的场景里这个模型可能需要更多轮次的引导。我基于上面的预判给三个模型准备的初始提示词做了非常微小的差异处理Step 5 Preview 增加了一句“请先给出实现方案再输出代码”DeepSeek V4 Pro 增加了一句“在代码中注释明确碰撞检测的处理边界”GLM5.3 保持原始提示词不变考验它的单轮理解能力。下面进入正题逐一说实测过程。3. Step 5 Preview 实测首轮生成就有“物理课代表”的气质3.1 提示词设计与首轮输出我先贴上我用的基础提示词三模型共用版本用 Three.js 写一个 3D 俯视角寻物小游戏所有代码放在一个 HTML 文件中。 场景要求 1. 房间尺寸 20x20四面有围墙地板为浅色网格纹理 2. 玩家控制一个半径 0.4 的红色小球WASD 控制移动速度 5 单位/秒 3. 房间内随机生成 6 个障碍物不同颜色立方体边长 1~1.5和 8 个收集物金色小球半径 0.3 4. 收集物和障碍物位置必须避开玩家出生点房间中心半径 2 范围内 5. 小球碰到障碍物必须停止移动不能穿模 6. 小球接近收集物 0.8 范围内自动拾取左上角显示得分/总收集数 7. 鼠标左键拖拽旋转相机滚轮缩放 8. 抛物线平滑跟随小球移动Step 5 Preview 回复的思考过程很长具体到“碰撞检测采用 AABB 包围盒”、“相机分为水平旋转和垂直旋转两个自由度”、“物距超过 12 直接剔除渲染”这类细节。这是我看到的三个模型里唯一一个在代码生成前主动做架构推理的。首轮生成的 HTML 文件大约 417 行Three.js 用的是 CDN 引入的 0.128.0 版本这个版本我比较熟悉API 相对稳定。代码里的类划分很清楚——Player、Obstacle、Collectible、GameCamera四个类各自责任单一命名也没有花里胡哨的缩写。3.2 跑通之后的问题碰撞反弹的方向打开浏览器场景加载正常网格地板、围墙、光线都齐全。操作手感方面WASD 移动响应灵敏鼠标拖拽旋转也平滑。但我在房间角落进行了一次斜 45 度撞击测试时发现小球撞墙之后会沿着墙面向下滑动而不是被完全挡住。原因在于代码里碰撞回退的方向处理得太简单——它把碰撞后的position直接拉回到移动之前的位置然后如果新位置仍然在碰撞中就原地不动。这个问题在“正面撞击”场景中不致命因为回退后的位置不再重叠就正常了。可到了“切斜角撞墙”时由于移动前的坐标可能已经紧贴墙面回退后依然处于重叠状态小球就变成了“粘”在墙上并且持续抖动。我在测试记录里写的是“斜向卡墙 bug——回退位置判定缺失。”修复过程我让 Step 5 Preview 自己改第二轮它给出的方案是碰撞前分别拆解 X 轴和 Z 轴移动分轴检测。这是比较标准的做法了我特意验证了四个斜角方向的撞击都能正确停止。3.3 Step 5 Preview 的隐藏加分项除了碰撞修复之外这轮实测还有一个让我意外的点它主动实现了“障碍物与收集物之间的防重叠”。基础提示词里只说了“避开玩家出生点”但它额外处理了障碍物之间、以及障碍物与收集物之间的间距。这个细节在很多生成游戏里会被漏掉直接导致玩家看到两个物体叠在一起穿模或者根本无法拾取。这说明模型的推理能力对“物体生成分布”这类隐性问题确实有帮助。4. DeepSeek V4 Pro 实测代码精简但物理边界是“重灾区”4.1 生成速度与首轮代码量DeepSeek V4 Pro 的生成速度是三模型里最快的首轮代码只有 345 行三段式结构初始化场景、设置事件监听、内部包含一个animate()主循环。它的代码风格很“极简主义”能不用类就绝不用类大量使用闭包和函数内部状态。快速跑通验证打开速度没问题功能也能用WASD 控制小球、收集物品计分都实现了。但手感上有一个非常明显的差别——小球停止时的惯性。原始需求没写“运动惯性”所以这里不加分不扣分。真正的问题是碰撞之后的“位置穿透”。4.2 穿模 bug碰撞判定用的是中心点而不是包围盒DeepSeek V4 Pro 的碰撞检测代码精简到了一个函数获取小球的世界坐标然后遍历障碍物位置用小球中心点到障碍物中心的距离来判断是否碰撞。这种方法在小球半径较小、障碍物较大的情况下会出现视觉穿模——因为小球的外边缘已经嵌进了障碍物但中心点还在距离阈值之外。我把障碍物边长调到 1.5、小球半径 0.4 的时候问题变得明显小球从侧面接近障碍物视觉上已经有大约三分之一嵌入墙体碰撞检测才触发。对俯视角游戏来说这种偏差影响不算毁灭性但如果是第一人称视角玩家会非常明显地感觉到“我还没撞上就被挡住了”或者“我明明穿过了却有碰撞反馈”。修改时我让 DeepSeek V4 Pro 把障碍物的尺寸信息传进碰撞检测函数用 AABB 方法替换中心点距离判断。它第二轮给出的代码基本正确但换成了另一种思路——把障碍物当作球形包围盒碰撞体来处理半径取立方体边长的一半。效果上大差不差因为俯视角下玩家主要从水平方向靠近障碍物垂直方向不做检测问题不大。4.3 同样的需求不同模型的“质量盲区”这个实测最直接的收获就是同一份需求DeepSeek V4 Pro 的盲区在物理边界Step 5 Preview 的盲区在斜向回退GLM5.3 的盲区在视觉丰富度——这就是为什么我认为“让 AI 做游戏”这件事至少应该先摸清模型的盲区类型否则你改 bug 的时候会一头雾水。DeepSeek V4 Pro 还有一个让我无语的问题生成收集物的时候它沿用了 Three.js 的SphereGeometry但把材质设成了MeshBasicMaterial导致收集物在光照下没有立体感看起来像扁平的圆片。这个不是 bug但视觉表现力差一截。我花了一行代码把材质改成MeshStandardMaterial并加了一个emissive属性金色反光的效果马上就出来了。4.4 第二次跑通后的真实感受综合跑通后DeepSeek V4 Pro 的版本代码最少逻辑最紧凑但可扩展性较差——如果你想加入一个新的游戏机制比如跳跃、二段跳或敌人追踪需要在主循环里插入大量条件判断代码会变得混乱。如果只是做原型验证这个模型效率很高如果是想在一个可迭代的代码库上持续加功能它需要你额外做一些重构工作。5. GLM5.3 实测中文理解能力强但代码风格“老派”5.1 一次生成稳定优先GLM5.3 的首轮生成内容是最“规矩”的。417 行左右的代码模块划分和 Step 5 Preview 类似但命名风格非常保守——所有变量名都是player、obstacles、collectibleList、renderer这类常规命名。它没有给出思考提纲而是直接输出代码这一点和 DeepSeek V4 Pro 类似。我本来预期它在中文理解和复杂的中文需求解析上表现最好实际也印证了这一点。我的提示词里有一条“抛物线平滑跟随小球移动”其他两个模型的理解都偏向视角跟随GLM5.3 则做成了相机在 Y 轴方向上带一点阻尼和回弹效果我第一次看到时愣了一下但体验下来确实更接近“流动感”。5.2 发现的问题坐标体系与拾取半径的计算偏差问题出现在拾取判定上。需求里写了“小球接近收集物 0.8 范围内自动拾取”GLM5.3 把这个“0.8”当成了水平距离忽略了 Y 轴差异。由于收集物在地面上Y0.3小球的半径 0.4 导致实际拾取范围在视觉上比预期小了不少。倒也不致命但玩家需要几乎贴着收集物才能拾取手感上有些“迟钝”。修复方式是把两物体间的三维距离改成“水平方向距离小于 0.8 且垂直方向小于 0.5”。这样更符合俯视角游戏的空间直觉我站在物品旁边不管 Y 轴差多少都能拾取。5.3 GLM5.3 的多轮修改表现在后续多轮修改中我测试了几个更复杂的需求变更改变移动方式从键控改为鼠标点击移动、增加障碍物数量、加入倒计时机制。GLM5.3 在“鼠标点击移动”这个改动上表现最好——它重新规划了寻路并给出了射线检测 导航点的实现代码没有破坏原来的碰撞系统。这里我多说一句很多 AI 编写游戏的翻车点不在首轮生成而在需求变更阶段。你让它加一个功能它把原来的系统顺手拆了。GLM5.3 在这方面确实稳。不过缺点也同样明显——如果提示词里要求“增加跳跃功能”它会默认跳跃后先暂停重力导致两次跳跃之间没有惯性玩起来很“木”。这类问题同样需要你主动点出不能设指望模型自己理解“跳跃应该是加速上升、减速下落的过程”。6. 三版结果横向对比除了“跑通”还要比什么三个模型最终都交出了能玩的版本。但如果只看“能不能跑”就错过了这次实测最值得关注的信息。我根据自己的实际体验从七个维度做了一个对比记录对比维度Step 5 PreviewDeepSeek V4 ProGLM5.3首轮代码量417 行345 行402 行首轮跑通率高一次成功高一次成功高一次成功碰撞检测精确度较好分轴检测一般中心距离法中等AABB 有偏差物理真实感强回退逻辑合理弱起始 bug 较多中等依赖几何直觉代码可维护性高类划分清晰低闭包堆叠中常规易读多轮修改稳定性中低高视觉细节处理较好防重叠较差材质平淡中靠手动调节这组数据里藏着一个很关键的信息首轮跑通率都不错但“跑通”本身不是一个足够高的筛选标准。如果只是发一堆“AI 直接做出了 3D 游戏”的内容不往深处看那几乎没有模型差异。可一旦你要把这个游戏往前推加需求、改手感、修 bug差异就非常明显了。对我来说真正的筛选标准是“哪一版代码能让我在改动时仍然保持逻辑清晰”。三个模型里Step 5 Preview 的代码最接近“我自己的代码习惯”DeepSeek V4 Pro 像是“一个熟练但急性子的人写的”GLM5.3 则是“一个认真但保守的实习生写的”。7. 实测之后的经验沉淀用 AI 做 3D 游戏必须跨过的坎这次实测给我留下了几个非常实际的教训如果你也想用 AI 生成 3D 游戏我建议你直接在项目里套用这些经验。7.1 提示词必须明确“坐标轴”和“单位”AI 模型默认不会跟你讨论“以这个世界坐标系为准”。你需要在提示词里就写清楚“房间尺寸 20x20玩家在 XZ 平面上移动Y 轴固定为 0.4”。不然有些模型会自作主张把 Y 轴当成左右方向后患无穷。我在所有提示词前面放了一段坐标系说明这一步能省掉至少一轮修改。两种做法对比一下你就明白了模糊需求“做一个 3D 房间玩家在里面走”明确需求“房间 20x20 的地面位于 XZ 平面玩家球体半径为 0.4中心 Y 坐标恒为 0.4移动时只改变 X 和 Z 值”后者生成的代码基本不会出现“球悬空移动”或者“球陷入地面”这类最常见的翻车。我见过太多 AI 生成的游戏角色在空中行走或者脚埋在地板里说到底就是坐标系没锁死。7.2 不要让 AI 生成超过 500 行的“单文件巨石”这次三个模型都生成了 300 到 420 行左右的代码放在一个 HTML 文件里尚且可控。但在真实项目中如果你让 AI 生成 1000 行以上的玩法逻辑全部塞在一个文件里后续修 bug 基本是灾难——因为 AI 改某一行代码的时候无法全局理解其他部分的依赖关系。我的经验是把游戏拆成几个独立小文件分开生成。比如场景初始化单独一个文件玩家控制单独一个文件物品/碰撞逻辑单独一个文件。每个文件保持 150 行以内AI 单次生成的质量和可维护性都会显著提升。7.3 about 幻觉 API拿不准的先查文档Three.js 的版本迭代还是比较快的——从r150之后一些 API 发生了变化。比如从r151开始THREE.Fog的构造函数不再接受(color, near, far)参数组而是需要new THREE.Fog(color, near, far)显式传入。很多模型会默认使用旧版本 API。这次实测里 DeepSeek V4 Pro 在初始化时使用了renderer.outputEncoding THREE.sRGBEncoding这个写法在 r152 版本中已经废弃了。代码跑起来没问题但如果你用最新版 Three.js控制台会有警告甚至部分后续 API 不兼容。对策我用的是 CDN 固定版本0.128.0版本锁死之后模型对 API 的记忆偏差影响就大大减小。如果你要用最新版我建议你告诉自己用的模型“Three.js 版本是 r160注意 API 差异”不然它们真的可能拿旧 API 凑数。7.4 人的验收环节依然是不可替代的做了这么多测试我得说句实话AI 能给你一个“看起来完整”的游戏但“好玩”这件事它目前还没有理解。它的代码总是缺少一种叫做“手感”的东西——跳跃的滞空时间、碰撞后的缓冲、相机跟随的阻尼感这些都来自真实的游戏调校经验而不是逻辑上的“正确”。举一个具体的例子三个模型都实现了相机跟随但真正玩起来Step 5 Preview 的相机跟随平滑度最好因为它的阻尼系数是动态调整的距离目标远时快速跟随距离近时缓慢微调而 GLM5.3 是固定阻尼远距离视角下会有非常明显的“漂移感”。这不是玄学而是经验封装的差异。“手感”是需要大量实战才能积累出来的隐性知识恰好是大模型目前最欠缺的东西之一。8. 一点个人收尾AI 是靠谱的“代笔”但你必须是那个导演这次实测跑完我的电脑里多了三个“同父异母”的 3D 游戏文件。它们的骨架完全一样但细节体验完全不同——有的照明更有质感有的手感更扎实有的代码能让我想继续改下去。我最想分享的体会有两件事第一请你不要再追求“AI 一次性做出完美游戏”这种幻觉。把 AI 当成一个极其聪明的初级开发它写代码、你负责把关效率最高。你每次在需求里多给一个具体参数就能减少一轮后续修改。第二同一份 prompt不同模型的产出差异恰恰是你可以利用的变量。比如我就发现如果我想快速看效果就找 DeepSeek V4 Pro如果我想在代码基础上继续加新玩法我会优先选 Step 5 Preview 的版本如果我反复改需求但不想破坏原有结构GLM5.3 更耐造。你完全可以按自己的项目阶段来切换工具。如果再往下走一步我打算把这三个版本的游戏各自跑成一个小系列分别加敌人 AI、加道具商店、加关卡切换然后对比它们在三轮迭代过程中的代码膨胀率和 bug 修复效率。那篇如果做出来大概率比今天这篇更有参考价值——毕竟游戏开发中真正难的不是“写出来”而是“一直改下去”。
阅读完成 · 觉得有帮助？
