最近AI写代码这块又打起来了各家都像是商量好了一样一个接一个地放新模型。我拿到 Step 5 Preview 的体验资格之后第一反应不是去跑那些标准测试集而是直接把它和手头的 DeepSeek V4 Pro、GLM5.3 拉到同一个考场做完全一样的事情生成一个可以打开就玩的3D游戏。为什么选3D游戏因为这玩意儿对模型的要求太全面了。写一个增删改查接口看不出水平差距但3D游戏要懂坐标系统、相机投影、动画循环、碰撞检测、资源加载任何一环出问题页面就是黑屏或者满地乱跳。这比任何排行榜都更能反映一个模型真实写代码的段位。这篇就完整记录这次三方实测的过程、翻车现场、和一些能直接拿去用的经验包括后面单独聊一下 GLM5.3 本地部署时 vLLM 镜像版本的选型问题。1. 为什么拿3D游戏当试金石1.1 三个模型分别是什么水平段位先说下三个参赛选手的定位。Step 5 Preview 是刚放出来的预览版本带强化推理的特征长上下文处理能力很突出但我心里清楚预览版就意味着某些角落还没有打磨好容易出现低级错误。DeepSeek V4 Pro 是目前的旗舰推理模型代码生成一贯以结构规整著称不少团队已经把它接进了日常开发流程。GLM5.3 则是中文场景下的热门选手中文理解、指令跟随一直很稳而且生态上开源权重可自部署讨论度一直很高。这三个放一起其实不是简单的“谁强谁弱”而是三种不同产品路线的碰撞。Step 5 Preview 更像一个激进的进攻手DeepSeek V4 Pro 像稳扎稳打的主力GLM5.3 则是强调实用性的全能型选手。同一个题目让它们各自发挥差异会非常有意思。1.2 评测维度怎么打分我没有用复杂的自动评分脚本而是按一个真实开发者拿到 AI 代码后最关心的几个角度来评一次性成功率生成完直接丢进浏览器能不能跑起来不黑屏、不报错。可玩性操作是否流畅碰撞、跳跃、计分这些机制是否真的生效而不是只能截图好看的静态场景。代码可读性变量命名、注释、模块划分能不能让人一眼看懂并二次修改。迭代修复成本如果出了问题模型能不能冷静地定位原因还是只会死记硬背地重写一遍。中文需求理解精度我给出的提示词是完整的中文需求包含多个约束条件模型是否做到了全部执行而非遗漏。3D游戏的代码量并不小一次生成往往要几百行甚至上千行这正好考察大模型的长期上下文保持能力。那些只擅长写函数级代码的模型一旦面对需要全局状态协调的任务立刻就会露馅。2. 评测前的提示词设计与参数约定2.1 提示词定稿同样的需求同样的约束为了让三个模型站在同一起跑线我准备了一份统一的提示词。写提示词时我特别注意两点一是把核心机制讲清楚二是把技术栈限定死避免每个模型各自发挥导致结果没法对比。我用的是这样的提示词请用 Three.js 和原生 JavaScript 写一个可在浏览器中直接运行的3D迷宫寻宝游戏要求如下 1. 使用 Three.js 官方 CDN 引入库文件页面为单个 index.html不依赖构建工具。 2. 迷宫由墙壁和地板组成墙壁使用不同的颜色地板使用统一的深色材质。 3. 玩家操控一个小球使用键盘 W A S D 控制移动小球遇到墙壁时不能穿过。 4. 迷宫中随机放置 3 个金色宝箱小球碰到宝箱后宝箱消失并加分右上角显示当前分数。 5. 小球加上简单阴影相机以第一人称跟随小球移动。 6. 页面加载后自动开始游戏控制台不能出现未捕获的报错。 7. 代码要添加中文注释变量命名清晰。这个提示词里每个约束都是我挖的坑。第3条碰撞检测是最容易翻车的第5条相机跟随是第二容易翻车的第6条控制台报错往往是隐藏杀手。三个模型能不能把这些坑都填上就看各自的真实功力了。2.2 环境与运行方式的统一评测环境尽量简单统一一台普通办公笔记本Chrome 浏览器使用本地 HTTP 服务打开页面保证 CORS 不会干扰资源加载。Three.js 用的是 CDN 版本三个模型生成的代码都指向同一个 r160 版本避免版本差异影响判断。生成参数上我全部采用默认设置温度取 0.7不做多轮追问而是让模型一次性输出。这样测的才是模型本身的真实水平而不是“经过人工反复调教后的结果”。之后每个模型都有一次机会针对运行报错进行自修复我把这个单独作为迭代修复能力的考察点。3. 三家的实测过程全记录3.1 Step 5 Preview框架漂亮第一印象翻车先跑的是 Step 5 Preview。它生成代码的速度确实快几乎是提示词发出去十几秒就开始输出而且没有多余的解释直接给完整 HTML。这个响应速度在三个模型里是最快的给人感觉非常“爽快”。代码结构也确实漂亮。场景初始化、光照设置、迷宫生成函数、小球控制模块都分得清清楚楚每段代码前面都有中文注释甚至还在顶部写了“迷宫寻宝游戏 - 主入口”。我当时以为这会是最省心的一个。结果把 HTML 拖进浏览器黑屏。打开控制台才看到问题其实不复杂——渲染器创建后没有加背景颜色也没有设置渲染器的大小跟随窗口导致 canvas 默认是 0 高度整个画面就是一块黑。但更坑的是另一个问题相机初始位置被写死在迷宫内部的地板下面也就是说就算 canvas 高度正常玩家也只会看到一片地面纹理根本不处于可玩的视角。这个模型的推理能力没体现在结果上因为它在“理解需求”阶段没有做反向验证。它生成了一个结构完美的外壳但内部关键的运行参数却错了。这就是典型的“只见树木不见森林”式代码生成局部很精致全局没有串起来。3.2 DeepSeek V4 Pro一次跑通但手感差点意思DeepSeek V4 Pro 的输出风格明显不一样。它先给了一段简短的方案说明然后是完整的代码整个 HTML 大约六百多行。代码结构同样清晰而且它注意到一个细节迷宫生成用了一个简单的二维数组标记墙壁位置再用 Three.js 的 BoxGeometry 逐个生成墙体。这种做法的好处是数据结构透明后期想做任何调整都方便。打开页面顺利跑通没有黑屏小球在迷宫入口处等着右上角分数显示为 0。第一印象非常稳。但玩了三十秒问题就暴露了。小球移动还算流畅但碰撞检测写得非常粗糙——它只检测小球中心点的下一个位置是否落在墙壁的网格坐标上如果落点坐标对应的是墙就禁止移动。这样做在小球速度慢的时候勉强能用一旦把移动速度调快小球就会因为中心点跨过了墙体的边界网格而发生“穿模”直接卡进墙里甚至直接穿墙而过。另外相机跟随是硬绑定的。相机直接放在小球正后方固定距离没有任何平滑插值。小球转向时相机跟着瞬间硬转画面晃动非常剧烈玩十几秒就有眩晕感。这个模型的代码正确性很好但在体验细节上暴露了短板它完成需求但不理解“玩起来舒服”这个隐含目标。3.3 GLM5.3中文需求理解最透彻代码迭代最快最后是 GLM5.3。它的生成速度略慢于前两个输出前会有一小段“思路分析”但没有长篇大论直接给出完整 HTML。代码长度跟 DeepSeek 差不多但有一个非常明显的区别——它对中文需求的理解明显更到位。它把“随机放置 3 个金色宝箱”理解成了完整的需求闭环不仅生成了宝箱模型和碰撞加分还在游戏底部加了一行提示文字告诉玩家迷宫里有三个宝箱找齐后可以按 R 键重置游戏继续挑战。这个细节是另外两个模型完全没有想到的说明它不只是在执行指令而是把需求当成一个产品场景来理解。首次运行同样是一次通过但控制台有一个警告纹理映射格式未指定。这个不影响游戏运行也不是致命错误但按照提示词的约束“控制台不能出现未捕获的报错”未捕获的报错它确实没有只是有个警告。GLM5.3 在迭代修复这个环节表现最舒服我把警告信息发回去它只用了两分钟就给出了修复方案精准定位到了texture.colorSpace的设置缺失没有牛头不对马嘴的重写。4. 代码质量与运行表现横向对比4.1 首次运行成功率与错误修复三个模型里只有 DeepSeek V4 Pro 和 GLM5.3 做到了首跑成功Step 5 Preview 因为相机位置和 canvas 尺寸问题黑屏需要一轮修复。这个结果其实挺反直觉的——Step 5 Preview 推理能力账面最强却忽视了最基本的运行环境初始化。不过后续修复的考察里Step 5 Preview 的进步空间就突出来了。我把控制台报错原样贴给它它在第二轮就找齐了两个问题canvas 高度缺默认值、相机初始坐标在地下。修复后的代码能跑但在碰撞检测和相机平滑上已经没有机会再去优化了因为我已经记录完第一轮表现进入对比环节。4.2 效果细节与代码风格对比三个模型在效果细节上的差异远比“能不能跑”更值得品。我把几个关键维度拆开做了个对照表。考察点Step 5 PreviewDeepSeek V4 ProGLM5.3场景初始化有瑕疵需修复完整正确完整正确迷宫生成算法二维数组循环二维数组循环二维数组偏移微调碰撞检测中心点网格判断中心点网格判断包围盒重叠检测相机跟随硬绑定无平滑硬绑定无平滑带插值的平滑跟随宝箱互动有加分逻辑有加分逻辑宝箱提示重置中文注释清晰简洁清晰简洁清晰且带需求背景首轮修复效率两处错误第二轮修复无需修复无需修复包围盒和中心点判断的差距是我觉得最值得讲的一点。前两个模型做碰撞检测都是拿小球的中心点去和墙体坐标做比对本质上是一维的思维。GLM5.3 则直接使用了Box3包围盒的相交检测把小球的边界和墙体的边界做成两个三维盒子每帧检测是否重叠。这个方案才是游戏开发里真正靠谱的做法无论小球速度多快只要没有直接瞬移穿过整面墙都不会漏判。4.3 从体验看选型不是越强越好而是越合适越好如果你直接问我推荐哪个模型来生成3D游戏我的答案取决于你的使用场景。如果你要的是“能跑就行我自己改”DeepSeek V4 Pro 最合适。它生成的代码结构规整变量命名统一注释到位二次修改时定位逻辑模块非常省力。而且它的格式稳定性很高整个代码没有无意义的空行或片段重复基本可以直接交付。如果你要的是“中文需求复杂我自己都不确定要写多细”GLM5.3 更合适。它对需求意图的推理更充分能把暗示的需求也补上比如提示、重置、平滑相机这些细节。这种能力在描述复杂产品特性时尤其重要它能把模糊的描述变成具体可执行的代码逻辑。Step 5 Preview 目前看更像是“用来探索新能力的玩具”对结果稳定性要求高的项目我不会第一时间选它。但它生成代码的速度和结构感非常强如果后续正式版本补上运行稳定性的短板会是很有竞争力的选择。5. 延伸GLM5.3 本地部署的镜像版本经验5.1 本地部署与开源生态的联动聊到 GLM5.3就绕不开它的开源属性。很多人拿到模型权重之后第一件事就是想用 vLLM 把它跑起来服务。但这里头有个非常容易踩的坑GLM 系列的新版本架构更新频繁vLLM 各版本对模型的支持程度差异比较大。不同版本的 vLLM 对注意力机制的实现、自定义算子的编译支持都不一样选错版本很可能出现模型加载失败或者某些算子走回慢速的 fallback 路径速度退化成原来的三分之一。我在本地部署 GLM5.3 时使用的经验是vLLM 镜像版本优先看模型卡或者官方示例推荐的那个组合不要贪新追最新版。GLM5.3 这类新模型权重发布后需要 vLLM 侧同步合并对应的模型实现代码官方会标明建议使用的 vLLM 版本号。翻车最少的做法是直接用官方容器镜像配合文档给出的版本标签而不是自己在裸环境里从源码编译。5.2 显存配置与会话式部署建议GLM5.3 的量化版本在本地跑需要多少显存很多人会低估。简单来说如果你想跑完整的 BF16 精度权重做高并发推理一块 80GB 级别的显卡是起步配置。如果换成 6bit 或 8bit 量化24GB 显存可以勉强跑起来但并发度会非常有限。我实际测下来量化后推理速度并没有想象中降那么多但在长上下文的场景下KV Cache 占用会快速膨胀显存预算最好留出 30% 的余量。再一个细节是本地部署时推荐用vllm/vllm-openai这个镜像的对应 release 标签并且按官方锁定的 Pytorch 版本组合来跑。如果自己手动改 Pytorch 版本非常容易出现 CUDA 算子库不匹配报错往往五花八门排查成本极高。这一步直接决定了你能不能把 GLM5.3 稳定服务化我见过不少人在这一步被劝退。6. 实测中的常见翻车点与避坑心得6.1 黑屏、穿墙、相机眩晕AI 生成 3D 游戏的三座大山把三个模型的输出放在一起看所有问题高度集中在三个地方基本就是 AI 生成 3D 游戏最容易翻车的三座大山。黑屏类问题本质上是对渲染环境初始化细节的遗漏。Three.js 的场景、相机、渲染器三者缺一不可环环是同步声明的。AI 模型经常生成一个逻辑正确的 renderer却没有给 renderer 设置尺寸、没有设置背景色或者把相机初始位置放在场景死角。这类问题排查起来也不难打开控制台看有没有报错然后逐个检查renderer.setSize、scene.background、相机坐标三个点即可。穿墙类问题根源是碰撞检测实现得太粗糙。只用点坐标判断碰撞遇到快速移动的物体就是漏判。解决思路就是改用包围盒或射线检测把“我的中心点是否在墙里”变成“我的整个体积是否与墙重叠”。这个思路在任何一个成熟游戏引擎里都是基本功但模型经常为了省代码而写简版。相机眩晕问题理论上是相机跟随算法没做平滑。硬绑定相机位置看起来很直接玩家操作时画面会剧烈抖动。加一个阻尼系数或者 Lerp 插值就能让相机像被弹簧拉着一样温和地跟随观感立刻提升一个档次。6.2 一个高效的评测姿势让模型自己当观众我这次踩了一只特别喜欢的评测姿势推荐大家试试跑完第一轮之后把页面在浏览器里打开让模型扮演一个“刚打开页面的玩家”然后用自然语言描述自己看到了什么、操作感受如何再让它根据描述自动修改。三个模型在这个环节的表现GLM5.3 的自我纠错能力明显更强它会主动去检查自己生成的相机代码是否存在延迟问题而其他两个模型更多是按描述补丁式修改。这种评测方式其实比单纯看代码质量更有参考价值因为它模拟了普通用户的使用路径。大多数用户不会去读生成的代码写得好不好他们只会看你给的产品能不能玩、玩起来爽不爽。从产品完成度的角度看这次的差距比代码质量差距更明显GLM5.3 在这个维度几乎碾压了另外两个。6.3 如果想继续提升3D 迷宫还能怎么扩展如果你也想拿这个场景继续练习或者做内容我建议你按这条线往下走先解决基础的移动和碰撞然后加入第三人称镜头切换再把迷宫改成随机种子生成并支持难度分级最后加一个计时系统和排行榜。每一步都是对模型逻辑能力的进一步考察比反复生成全新游戏更能看出模型的迭代能力。我自己目前更期待 GLM5.3 的下一步迭代以及 Step 5 Preview 正式版本在运行稳定性上的表现。从这次实测来看能生成代码的模型已经很多了但能生成“跑得起来、玩得下去”的完整产品的模型还远没到大结局的时候。
最近AI写代码这块又打起来了各家都像是商量好了一样一个接一个地放新模型。我拿到 Step 5 Preview 的体验资格之后第一反应不是去跑那些标准测试集而是直接把它和手头的 DeepSeek V4 Pro、GLM5.3 拉到同一个考场做完全一样的事情生成一个可以打开就玩的3D游戏。为什么选3D游戏因为这玩意儿对模型的要求太全面了。写一个增删改查接口看不出水平差距但3D游戏要懂坐标系统、相机投影、动画循环、碰撞检测、资源加载任何一环出问题页面就是黑屏或者满地乱跳。这比任何排行榜都更能反映一个模型真实写代码的段位。这篇就完整记录这次三方实测的过程、翻车现场、和一些能直接拿去用的经验包括后面单独聊一下 GLM5.3 本地部署时 vLLM 镜像版本的选型问题。1. 为什么拿3D游戏当试金石1.1 三个模型分别是什么水平段位先说下三个参赛选手的定位。Step 5 Preview 是刚放出来的预览版本带强化推理的特征长上下文处理能力很突出但我心里清楚预览版就意味着某些角落还没有打磨好容易出现低级错误。DeepSeek V4 Pro 是目前的旗舰推理模型代码生成一贯以结构规整著称不少团队已经把它接进了日常开发流程。GLM5.3 则是中文场景下的热门选手中文理解、指令跟随一直很稳而且生态上开源权重可自部署讨论度一直很高。这三个放一起其实不是简单的“谁强谁弱”而是三种不同产品路线的碰撞。Step 5 Preview 更像一个激进的进攻手DeepSeek V4 Pro 像稳扎稳打的主力GLM5.3 则是强调实用性的全能型选手。同一个题目让它们各自发挥差异会非常有意思。1.2 评测维度怎么打分我没有用复杂的自动评分脚本而是按一个真实开发者拿到 AI 代码后最关心的几个角度来评一次性成功率生成完直接丢进浏览器能不能跑起来不黑屏、不报错。可玩性操作是否流畅碰撞、跳跃、计分这些机制是否真的生效而不是只能截图好看的静态场景。代码可读性变量命名、注释、模块划分能不能让人一眼看懂并二次修改。迭代修复成本如果出了问题模型能不能冷静地定位原因还是只会死记硬背地重写一遍。中文需求理解精度我给出的提示词是完整的中文需求包含多个约束条件模型是否做到了全部执行而非遗漏。3D游戏的代码量并不小一次生成往往要几百行甚至上千行这正好考察大模型的长期上下文保持能力。那些只擅长写函数级代码的模型一旦面对需要全局状态协调的任务立刻就会露馅。2. 评测前的提示词设计与参数约定2.1 提示词定稿同样的需求同样的约束为了让三个模型站在同一起跑线我准备了一份统一的提示词。写提示词时我特别注意两点一是把核心机制讲清楚二是把技术栈限定死避免每个模型各自发挥导致结果没法对比。我用的是这样的提示词请用 Three.js 和原生 JavaScript 写一个可在浏览器中直接运行的3D迷宫寻宝游戏要求如下 1. 使用 Three.js 官方 CDN 引入库文件页面为单个 index.html不依赖构建工具。 2. 迷宫由墙壁和地板组成墙壁使用不同的颜色地板使用统一的深色材质。 3. 玩家操控一个小球使用键盘 W A S D 控制移动小球遇到墙壁时不能穿过。 4. 迷宫中随机放置 3 个金色宝箱小球碰到宝箱后宝箱消失并加分右上角显示当前分数。 5. 小球加上简单阴影相机以第一人称跟随小球移动。 6. 页面加载后自动开始游戏控制台不能出现未捕获的报错。 7. 代码要添加中文注释变量命名清晰。这个提示词里每个约束都是我挖的坑。第3条碰撞检测是最容易翻车的第5条相机跟随是第二容易翻车的第6条控制台报错往往是隐藏杀手。三个模型能不能把这些坑都填上就看各自的真实功力了。2.2 环境与运行方式的统一评测环境尽量简单统一一台普通办公笔记本Chrome 浏览器使用本地 HTTP 服务打开页面保证 CORS 不会干扰资源加载。Three.js 用的是 CDN 版本三个模型生成的代码都指向同一个 r160 版本避免版本差异影响判断。生成参数上我全部采用默认设置温度取 0.7不做多轮追问而是让模型一次性输出。这样测的才是模型本身的真实水平而不是“经过人工反复调教后的结果”。之后每个模型都有一次机会针对运行报错进行自修复我把这个单独作为迭代修复能力的考察点。3. 三家的实测过程全记录3.1 Step 5 Preview框架漂亮第一印象翻车先跑的是 Step 5 Preview。它生成代码的速度确实快几乎是提示词发出去十几秒就开始输出而且没有多余的解释直接给完整 HTML。这个响应速度在三个模型里是最快的给人感觉非常“爽快”。代码结构也确实漂亮。场景初始化、光照设置、迷宫生成函数、小球控制模块都分得清清楚楚每段代码前面都有中文注释甚至还在顶部写了“迷宫寻宝游戏 - 主入口”。我当时以为这会是最省心的一个。结果把 HTML 拖进浏览器黑屏。打开控制台才看到问题其实不复杂——渲染器创建后没有加背景颜色也没有设置渲染器的大小跟随窗口导致 canvas 默认是 0 高度整个画面就是一块黑。但更坑的是另一个问题相机初始位置被写死在迷宫内部的地板下面也就是说就算 canvas 高度正常玩家也只会看到一片地面纹理根本不处于可玩的视角。这个模型的推理能力没体现在结果上因为它在“理解需求”阶段没有做反向验证。它生成了一个结构完美的外壳但内部关键的运行参数却错了。这就是典型的“只见树木不见森林”式代码生成局部很精致全局没有串起来。3.2 DeepSeek V4 Pro一次跑通但手感差点意思DeepSeek V4 Pro 的输出风格明显不一样。它先给了一段简短的方案说明然后是完整的代码整个 HTML 大约六百多行。代码结构同样清晰而且它注意到一个细节迷宫生成用了一个简单的二维数组标记墙壁位置再用 Three.js 的 BoxGeometry 逐个生成墙体。这种做法的好处是数据结构透明后期想做任何调整都方便。打开页面顺利跑通没有黑屏小球在迷宫入口处等着右上角分数显示为 0。第一印象非常稳。但玩了三十秒问题就暴露了。小球移动还算流畅但碰撞检测写得非常粗糙——它只检测小球中心点的下一个位置是否落在墙壁的网格坐标上如果落点坐标对应的是墙就禁止移动。这样做在小球速度慢的时候勉强能用一旦把移动速度调快小球就会因为中心点跨过了墙体的边界网格而发生“穿模”直接卡进墙里甚至直接穿墙而过。另外相机跟随是硬绑定的。相机直接放在小球正后方固定距离没有任何平滑插值。小球转向时相机跟着瞬间硬转画面晃动非常剧烈玩十几秒就有眩晕感。这个模型的代码正确性很好但在体验细节上暴露了短板它完成需求但不理解“玩起来舒服”这个隐含目标。3.3 GLM5.3中文需求理解最透彻代码迭代最快最后是 GLM5.3。它的生成速度略慢于前两个输出前会有一小段“思路分析”但没有长篇大论直接给出完整 HTML。代码长度跟 DeepSeek 差不多但有一个非常明显的区别——它对中文需求的理解明显更到位。它把“随机放置 3 个金色宝箱”理解成了完整的需求闭环不仅生成了宝箱模型和碰撞加分还在游戏底部加了一行提示文字告诉玩家迷宫里有三个宝箱找齐后可以按 R 键重置游戏继续挑战。这个细节是另外两个模型完全没有想到的说明它不只是在执行指令而是把需求当成一个产品场景来理解。首次运行同样是一次通过但控制台有一个警告纹理映射格式未指定。这个不影响游戏运行也不是致命错误但按照提示词的约束“控制台不能出现未捕获的报错”未捕获的报错它确实没有只是有个警告。GLM5.3 在迭代修复这个环节表现最舒服我把警告信息发回去它只用了两分钟就给出了修复方案精准定位到了texture.colorSpace的设置缺失没有牛头不对马嘴的重写。4. 代码质量与运行表现横向对比4.1 首次运行成功率与错误修复三个模型里只有 DeepSeek V4 Pro 和 GLM5.3 做到了首跑成功Step 5 Preview 因为相机位置和 canvas 尺寸问题黑屏需要一轮修复。这个结果其实挺反直觉的——Step 5 Preview 推理能力账面最强却忽视了最基本的运行环境初始化。不过后续修复的考察里Step 5 Preview 的进步空间就突出来了。我把控制台报错原样贴给它它在第二轮就找齐了两个问题canvas 高度缺默认值、相机初始坐标在地下。修复后的代码能跑但在碰撞检测和相机平滑上已经没有机会再去优化了因为我已经记录完第一轮表现进入对比环节。4.2 效果细节与代码风格对比三个模型在效果细节上的差异远比“能不能跑”更值得品。我把几个关键维度拆开做了个对照表。考察点Step 5 PreviewDeepSeek V4 ProGLM5.3场景初始化有瑕疵需修复完整正确完整正确迷宫生成算法二维数组循环二维数组循环二维数组偏移微调碰撞检测中心点网格判断中心点网格判断包围盒重叠检测相机跟随硬绑定无平滑硬绑定无平滑带插值的平滑跟随宝箱互动有加分逻辑有加分逻辑宝箱提示重置中文注释清晰简洁清晰简洁清晰且带需求背景首轮修复效率两处错误第二轮修复无需修复无需修复包围盒和中心点判断的差距是我觉得最值得讲的一点。前两个模型做碰撞检测都是拿小球的中心点去和墙体坐标做比对本质上是一维的思维。GLM5.3 则直接使用了Box3包围盒的相交检测把小球的边界和墙体的边界做成两个三维盒子每帧检测是否重叠。这个方案才是游戏开发里真正靠谱的做法无论小球速度多快只要没有直接瞬移穿过整面墙都不会漏判。4.3 从体验看选型不是越强越好而是越合适越好如果你直接问我推荐哪个模型来生成3D游戏我的答案取决于你的使用场景。如果你要的是“能跑就行我自己改”DeepSeek V4 Pro 最合适。它生成的代码结构规整变量命名统一注释到位二次修改时定位逻辑模块非常省力。而且它的格式稳定性很高整个代码没有无意义的空行或片段重复基本可以直接交付。如果你要的是“中文需求复杂我自己都不确定要写多细”GLM5.3 更合适。它对需求意图的推理更充分能把暗示的需求也补上比如提示、重置、平滑相机这些细节。这种能力在描述复杂产品特性时尤其重要它能把模糊的描述变成具体可执行的代码逻辑。Step 5 Preview 目前看更像是“用来探索新能力的玩具”对结果稳定性要求高的项目我不会第一时间选它。但它生成代码的速度和结构感非常强如果后续正式版本补上运行稳定性的短板会是很有竞争力的选择。5. 延伸GLM5.3 本地部署的镜像版本经验5.1 本地部署与开源生态的联动聊到 GLM5.3就绕不开它的开源属性。很多人拿到模型权重之后第一件事就是想用 vLLM 把它跑起来服务。但这里头有个非常容易踩的坑GLM 系列的新版本架构更新频繁vLLM 各版本对模型的支持程度差异比较大。不同版本的 vLLM 对注意力机制的实现、自定义算子的编译支持都不一样选错版本很可能出现模型加载失败或者某些算子走回慢速的 fallback 路径速度退化成原来的三分之一。我在本地部署 GLM5.3 时使用的经验是vLLM 镜像版本优先看模型卡或者官方示例推荐的那个组合不要贪新追最新版。GLM5.3 这类新模型权重发布后需要 vLLM 侧同步合并对应的模型实现代码官方会标明建议使用的 vLLM 版本号。翻车最少的做法是直接用官方容器镜像配合文档给出的版本标签而不是自己在裸环境里从源码编译。5.2 显存配置与会话式部署建议GLM5.3 的量化版本在本地跑需要多少显存很多人会低估。简单来说如果你想跑完整的 BF16 精度权重做高并发推理一块 80GB 级别的显卡是起步配置。如果换成 6bit 或 8bit 量化24GB 显存可以勉强跑起来但并发度会非常有限。我实际测下来量化后推理速度并没有想象中降那么多但在长上下文的场景下KV Cache 占用会快速膨胀显存预算最好留出 30% 的余量。再一个细节是本地部署时推荐用vllm/vllm-openai这个镜像的对应 release 标签并且按官方锁定的 Pytorch 版本组合来跑。如果自己手动改 Pytorch 版本非常容易出现 CUDA 算子库不匹配报错往往五花八门排查成本极高。这一步直接决定了你能不能把 GLM5.3 稳定服务化我见过不少人在这一步被劝退。6. 实测中的常见翻车点与避坑心得6.1 黑屏、穿墙、相机眩晕AI 生成 3D 游戏的三座大山把三个模型的输出放在一起看所有问题高度集中在三个地方基本就是 AI 生成 3D 游戏最容易翻车的三座大山。黑屏类问题本质上是对渲染环境初始化细节的遗漏。Three.js 的场景、相机、渲染器三者缺一不可环环是同步声明的。AI 模型经常生成一个逻辑正确的 renderer却没有给 renderer 设置尺寸、没有设置背景色或者把相机初始位置放在场景死角。这类问题排查起来也不难打开控制台看有没有报错然后逐个检查renderer.setSize、scene.background、相机坐标三个点即可。穿墙类问题根源是碰撞检测实现得太粗糙。只用点坐标判断碰撞遇到快速移动的物体就是漏判。解决思路就是改用包围盒或射线检测把“我的中心点是否在墙里”变成“我的整个体积是否与墙重叠”。这个思路在任何一个成熟游戏引擎里都是基本功但模型经常为了省代码而写简版。相机眩晕问题理论上是相机跟随算法没做平滑。硬绑定相机位置看起来很直接玩家操作时画面会剧烈抖动。加一个阻尼系数或者 Lerp 插值就能让相机像被弹簧拉着一样温和地跟随观感立刻提升一个档次。6.2 一个高效的评测姿势让模型自己当观众我这次踩了一只特别喜欢的评测姿势推荐大家试试跑完第一轮之后把页面在浏览器里打开让模型扮演一个“刚打开页面的玩家”然后用自然语言描述自己看到了什么、操作感受如何再让它根据描述自动修改。三个模型在这个环节的表现GLM5.3 的自我纠错能力明显更强它会主动去检查自己生成的相机代码是否存在延迟问题而其他两个模型更多是按描述补丁式修改。这种评测方式其实比单纯看代码质量更有参考价值因为它模拟了普通用户的使用路径。大多数用户不会去读生成的代码写得好不好他们只会看你给的产品能不能玩、玩起来爽不爽。从产品完成度的角度看这次的差距比代码质量差距更明显GLM5.3 在这个维度几乎碾压了另外两个。6.3 如果想继续提升3D 迷宫还能怎么扩展如果你也想拿这个场景继续练习或者做内容我建议你按这条线往下走先解决基础的移动和碰撞然后加入第三人称镜头切换再把迷宫改成随机种子生成并支持难度分级最后加一个计时系统和排行榜。每一步都是对模型逻辑能力的进一步考察比反复生成全新游戏更能看出模型的迭代能力。我自己目前更期待 GLM5.3 的下一步迭代以及 Step 5 Preview 正式版本在运行稳定性上的表现。从这次实测来看能生成代码的模型已经很多了但能生成“跑得起来、玩得下去”的完整产品的模型还远没到大结局的时候。
