1. 三款模型同台做3D游戏我为什么选这个题最近这段时间AI编程助手这个赛道热闹得有点不像话。Step 5 Preview、DeepSeek V4 Pro、GLM5.3 这几个名字轮番出现在各种讨论里群里、社区里、甚至我那个做客服主管的朋友都在问“到底哪个写代码更靠谱”。光看跑分和榜单其实没什么体感因为那些测试集大多是算法题、函数补全、单元测试跟真正“从零做一个能跑起来的东西”完全是两码事。我平时的工作流里WorkBuddy 这类工作台工具用得比较多它本质上是一个把模型能力、文件操作、终端执行、多轮记忆串起来的开发环境。你给它一个目标它能自己拆任务、写文件、跑命令、看报错、再改。所以这次我干脆做了个横向实测同一个需求分别让 Step 5 Preview、DeepSeek V4 Pro、GLM5.3 来做一个 3D 小游戏看谁能在最少人工干预下把东西真正跑起来。选 3D 游戏不是故意刁难而是因为它天然是个“综合题”。它同时涉及数学向量、矩阵、四元数、图形学渲染管线、光照、相机、工程结构场景管理、资源加载、主循环、以及交互逻辑输入、碰撞、状态机。一个模型如果只会写孤立函数做 3D 游戏会立刻露馅如果它能把这个东西搭起来还能跑说明它的长上下文理解、跨文件一致性、调试闭环能力都过关。这篇文章适合几类人看一是正在选型、想知道这几个模型在真实项目里表现差异的开发者二是想用 WorkBuddy 这类工作台做实际项目、但不确定怎么组织提示词和规则的人三是对 3D 游戏开发感兴趣、想看看 AI 能帮到哪一步的独立开发者。我会把整个实测过程、每个模型的表现、踩到的坑、以及我总结出来的可复现方法都写清楚你照着做基本能复刻一遍。2. 实测前的环境准备与任务定义2.1 为什么用 WorkBuddy 作为统一测试台要让三个模型公平对比最大的变量其实是“执行环境”。如果我用三个不同的编辑器、不同的运行方式那结果差异可能来自工具而不是模型。所以我把它们统一放进 WorkBuddy 里跑。WorkBuddy 的核心价值在于它是一个“带手”的工作台模型不只是输出代码文本它还能直接创建文件、修改文件、在终端里执行命令、读取执行结果。这一点对 3D 游戏这种多文件项目特别关键因为游戏不可能塞进一个文件里它需要 index.html、若干 js 模块、可能的资源文件还要能启动一个本地服务预览。安装上没什么特别的官网下载对应平台版本即可。Windows 用户注意一点如果你还在 Win7 上部分新版本可能不兼容建议升级系统或者用 Linux 环境。Linux 下安装更顺依赖少。装完之后第一件事是配置模型接入把 Step 5 Preview、DeepSeek V4 Pro、GLM5.3 分别配成可切换的模型源。这里有个实操细节WorkBuddy 的系统缓存目录默认在用户目录下如果你 C 盘紧张可以改到 D 盘。改法是在设置里找到缓存路径选项指向一个你新建的目录比如D:\workbuddy-cache。改完重启一次让它生效。这个操作看起来小但做 3D 项目时会产生不少临时文件和依赖缓存早点改省得后面 C 盘爆红。2.2 给 WorkBuddy 定几条全局规则WorkBuddy 有个很好用的能力叫自定义指令你可以给它定几条规则后续对所有任务都生效。我这次实测前定了这么几条直接决定了后面三个模型的表现差异规则一所有代码必须能直接在浏览器打开运行不依赖构建工具。这条是为了排除“模型写了一堆 webpack 配置但根本跑不起来”的情况。规则二优先使用原生 WebGL 或 Three.js CDN 版本不引入需要 npm install 的重型依赖。3D 游戏用 Three.js 是最现实的路径但版本和引入方式必须明确。规则三每完成一个可运行阶段必须自己在终端启动本地服务并验证页面无报错。这条逼着模型形成“写完就验”的闭环。规则四遇到报错先读错误信息再改不允许盲目重写整个文件。这条能看出模型的调试能力。这四条规则看起来简单但它们把任务从“写代码”变成了“交付一个能跑的东西”。很多模型在自由发挥时喜欢堆砌代码量但一旦要求“必须能跑”它的真实水平就藏不住了。2.3 统一任务描述一个最小可玩的 3D 游戏为了公平我给三个模型的提示词完全一致。任务定义如下用 HTML JavaScript Three.jsCDN 引入做一个 3D 小游戏。场景里有一个地面平面、若干随机分布的立方体障碍物、一个玩家控制的球体。玩家用 WASD 控制球体在地面上移动方向键或鼠标控制相机跟随。球体碰到障碍物时要有简单的碰撞反馈比如变色或弹开。页面右上角显示得分或计时。要求代码分文件组织至少包含主入口、场景构建、玩家控制三个模块。完成后启动本地服务并确认无控制台报错。这个任务的信息量刚好卡在一个临界点它足够具体不会让模型跑偏又足够开放能看出模型的组织能力。3D 游戏里“相机跟随”和“碰撞检测”是两个经典难点前者考验数学理解后者考验工程判断。3. 三个模型的实际表现拆解3.1 Step 5 Preview结构最稳但细节需要盯Step 5 Preview 给我的第一印象是“工程感强”。它接到任务后没有急着写代码而是先列了一个文件结构index.html src/main.js src/scene.js src/player.js src/collision.js这个拆分比我要求的还细把碰撞单独拎出来了。然后它逐个文件生成每个文件职责清晰模块之间用 import 连接。这一点很关键因为 3D 游戏最容易出的问题就是“所有逻辑堆在一个文件里改一处崩三处”。在场景构建上它用了 Three.js 的Scene、PerspectiveCamera、WebGLRenderer标准三件套地面用PlaneGeometry加MeshStandardMaterial障碍物用BoxGeometry循环生成并随机设置位置。光照用了AmbientLight加DirectionalLight的组合这个选择很务实环境光保证整体可见平行光提供方向感阴影。玩家控制部分它用了一个velocity向量配合deltaTime做帧率无关的移动。这个细节值得说很多新手写移动就是position.x speed帧率一高角色就飞了。Step 5 Preview 主动用了clock.getDelta()说明它对游戏循环有基本认知。但问题也来了。它生成的碰撞检测是简单的包围盒判断球体被当成一个点处理导致视觉上球还没碰到方块就已经触发反馈。我让它修它第一次改成了球体半径补偿但还是没考虑方块的中心偏移。第二次我直接把错误现象描述清楚——“球体边缘和方块表面接触时才应该触发”——它才改对。这说明它的调试需要比较明确的反馈不能指望它自己发现视觉层面的偏差。相机跟随它做的是最简单的camera.position.copy(player.position)加固定偏移没有平滑插值。能跑但体验生硬。我后来自己加了个 lerp 才顺眼。3.2 DeepSeek V4 Pro代码密度高但容易过度设计DeepSeek V4 Pro 的风格完全不同。它一上来就写了一个相当完整的单文件版本然后才拆模块。代码密度明显更高一个scene.js里塞了场景、光照、雾效、阴影配置。阴影这块它主动开了renderer.shadowMap.enabled还给平行光配了 shadow camera 的范围这个细节说明它对渲染管线有理解。但它的“过度设计”倾向也很明显。它给障碍物加了一套基于InstancedMesh的批量渲染方案理由是“障碍物数量多时性能更好”。问题是我们的任务里障碍物就十几个用 InstancedMesh 反而增加了代码复杂度而且它第一次写的时候实例矩阵更新逻辑有 bug所有方块叠在一起。我让它简化它才退回普通 Mesh 循环。玩家控制它用了四元数做相机旋转支持鼠标拖拽转视角。这个功能本身不错但它没处理鼠标事件的边界情况鼠标移出窗口后视角会卡住。我提了一句它加了个mouseleave重置。这个反应速度是可以的。碰撞它用的是Box3.intersectsSphere比 Step 5 Preview 的初版更准确因为 Three.js 内置的Box3能直接和球体做相交测试。这一点它选对了工具。但它没做碰撞后的物理反馈只是把球体位置回退导致撞墙时会有轻微抖动。我后来自己补了一个速度反向。DeepSeek V4 Pro 的整体感觉是“聪明但话多”它倾向于把能想到的都写上你需要帮它做减法。对于有经验的开发者这其实是好事因为你可以从它的方案里挑对于新手可能会被它带进过度复杂的坑里。3.3 GLM5.3平衡性最好但启动阶段偏慢GLM5.3 的表现介于两者之间。它的文件拆分和 Step 5 Preview 类似但模块粒度更粗一点把碰撞并进了 player 模块。代码风格比较克制没有 DeepSeek 那种炫技感。它的一个亮点是主动加了一个简单的游戏状态管理用了一个state对象存score、isRunning、startTime。这个设计让后面的计分和计时扩展变得很容易。我让它加一个“碰到障碍物扣分”的逻辑它只改了三行就完成了因为状态是集中的。相机跟随它用了lerp平滑这一点比 Step 5 Preview 的初版好。但它 lerp 的系数写死了 0.1没有暴露成参数我想调快一点还得进代码改。这是个小遗憾。碰撞检测它用的是距离判断自己算球心和方块中心的距离再和半径之和比较。这个方法对轴对齐方块是准确的但如果方块旋转了就会出错。我们的任务里方块没旋转所以能跑。但如果任务再复杂一点这个方案就有隐患。GLM5.3 最明显的问题是启动阶段。它在生成第一个文件之前“思考”的时间明显比另外两个长终端里能看到它在反复读任务描述。我猜测它在做更完整的规划但代价是响应慢。对于赶时间的场景这个等待会有点磨人。3.4 三模型横向对比表维度Step 5 PreviewDeepSeek V4 ProGLM5.3文件组织最细碰撞独立先单文件后拆分中等粒度代码密度适中偏高易过度设计克制碰撞方案包围盒初版不准Box3 相交较准距离判断有局限相机跟随硬跟随需手改四元数功能多lerp 平滑系数写死调试响应需明确反馈反应快中等启动速度快快偏慢适合人群想要清晰结构有经验能挑方案想要平衡省心这张表不是绝对结论因为模型版本会更新而且表现和提示词质量强相关。但它能给你一个选型的起点。4. 用 WorkBuddy 跑通 3D 游戏的关键操作4.1 从提示词到可运行页面的完整流程不管你用哪个模型在 WorkBuddy 里跑这类项目的流程是相似的。我把完整步骤拆一下你可以直接照着做。第一步新建一个工作目录比如D:\projects\3d-game-test。在 WorkBuddy 里把这个目录设为工作区。这一步很重要因为模型的所有文件操作都会限制在这个目录内避免它乱写到你系统其他地方。第二步在对话里把任务描述贴进去同时确认你的全局规则已经生效。你可以在对话开头加一句“请遵守已设定的全局规则”它会去读自定义指令。第三步等模型生成文件。这时候不要急着打断让它把结构搭完。如果它中途问你问题比如“用哪个 Three.js 版本”你就明确回答比如“用 r160 的 CDN 版本”。模糊回答会导致它选一个你不想要的版本。第四步让它启动本地服务。WorkBuddy 一般会用python -m http.server或者npx serve。如果它没主动启动你就说“请启动本地服务并告诉我访问地址”。第五步打开浏览器访问按 F12 看控制台。如果有报错把报错原文复制回对话里让它修。这里有个技巧不要只说“报错了”要把完整的错误堆栈贴给它包括文件名和行号。模型对具体错误信息的处理能力远强于模糊描述。第六步功能验证。移动、碰撞、计分逐个试。发现问题就描述现象比如“球体穿过方块没有反应”而不是“碰撞有问题”。现象描述越具体它改得越准。4.2 本地服务启动与端口排查3D 游戏必须通过 HTTP 访问直接双击 HTML 文件会因为跨域限制导致 Three.js 的模块加载失败。这是新手最常踩的坑。WorkBuddy 启动服务后一般会监听 8000 或 3000 端口。如果访问不了先检查端口是否被占用。Windows 下可以用netstat -ano | findstr :8000看占用情况Linux 下用lsof -i :8000。如果被占用让 WorkBuddy 换一个端口比如 8080。还有一个常见问题是服务启动了但页面白屏。这时候先看控制台大概率是 Three.js CDN 加载失败。解决办法是换一个稳定的 CDN 地址或者让模型把 Three.js 下载到本地再引用。后者更稳但会增加文件体积。提示如果你在公司网络环境下某些 CDN 可能访问不稳定。让模型把依赖本地化是更保险的做法虽然多几步操作但能避免调试时被网络问题干扰。4.3 让模型自己验证的闭环技巧WorkBuddy 最值钱的能力是它能执行命令并读结果。你要充分利用这一点逼模型形成闭环。具体做法是每次它改完代码你都加一句“请重新启动服务并检查控制台是否有报错”。它就会去跑命令、读输出。如果它说“没有报错”你再自己打开页面确认。如果它说“有报错”它通常会接着修。这个闭环能大幅减少你的手动验证次数。我实测下来Step 5 Preview 和 DeepSeek V4 Pro 对这个指令的执行比较到位GLM5.3 偶尔会跳过验证直接说“已完成”需要你再催一次。另外WorkBuddy 有跨对话记忆的能力你可以把这次项目的关键决策记下来比如“Three.js 用 r160”“碰撞用 Box3”后续新对话里它还能记得。这个功能对长期项目很有用不用每次重复背景。5. 实操中踩到的坑与排查记录5.1 碰撞检测为什么总是“差一点”这是三个模型都出过问题的地方值得单独说。3D 游戏里碰撞检测的难点不在于“能不能检测”而在于“检测的时机和精度”。球体碰方块理想情况是球面接触方块表面的瞬间触发。但模型初版往往用球心到方块中心的距离判断这就忽略了球体半径和方块半边长。正确的做法是把球心到方块最近点的距离和球半径比较。Three.js 的Box3.clampPoint能帮你找到方块上离球心最近的点然后算这个点到球心的距离。我实测时Step 5 Preview 第一次改只加了球半径没考虑方块尺寸第二次才用上clampPoint。DeepSeek V4 Pro 直接用Box3.intersectsSphere一步到位。GLM5.3 的距离判断在轴对齐情况下能用但不够通用。注意如果你的方块会旋转距离判断和简单包围盒都会失效必须用OBB有向包围盒或者物理引擎。对于简单项目保持方块不旋转是最省事的做法。5.2 相机跟随的抖动与穿模相机跟随看着简单做起来坑不少。最常见的问题是抖动原因是相机位置直接复制玩家位置而玩家位置每帧都在变导致相机也跟着每帧跳。解决办法是插值。用camera.position.lerp(targetPosition, 0.1)让相机平滑追过去。系数越小越平滑但越滞后0.1 到 0.2 之间比较合适。GLM5.3 主动做了这个Step 5 Preview 和 DeepSeek V4 Pro 需要我提醒。另一个问题是穿模相机跟得太近时会穿进障碍物里。简单做法是给相机加一个最小高度和距离限制复杂做法是做射线检测。对于小游戏限制距离就够了。5.3 帧率无关移动的计算方法这个点很多新手会忽略。如果你写player.position.x speed在 60Hz 屏幕上每秒移动 60 次在 144Hz 屏幕上每秒移动 144 次角色速度完全不一样。正确做法是用deltaTimeconst delta clock.getDelta(); player.position.x speed * delta;这样speed的单位就是“单位每秒”和帧率无关。Step 5 Preview 主动用了这个另外两个需要我提。这个细节能看出模型对游戏循环的理解深度。5.4 常见问题速查表现象可能原因排查方法解决页面白屏CDN 加载失败看控制台网络请求换 CDN 或本地化依赖球体穿墙碰撞检测精度不足打印球心和方块距离用 clampPoint 算最近点移动速度异常未用 deltaTime换高刷屏测试乘 clock.getDelta()相机抖动直接复制位置观察相机每帧变化用 lerp 插值服务启动失败端口占用netstat 查端口换端口模型说完成但跑不了未执行验证要求它启动服务强制闭环验证这张表是我这次实测里实际遇到的问题汇总你遇到类似现象可以直接对照。6. 关于 WorkBuddy 使用的一些经验补充6.1 自定义指令怎么定才有效前面提到的那四条规则是我试了几版之后定下来的。定规则有几个原则第一规则要可验证。比如“代码必须能跑”比“代码质量要高”有用得多因为前者能通过启动服务来验证后者模型不知道怎么执行。第二规则要少而精。定太多规则模型会顾此失彼五条以内比较合适。我见过有人定了二十条结果模型每条都执行一半。第三规则要针对你的痛点。如果你经常遇到模型乱改文件就定“修改前先说明改哪个文件”如果你经常遇到依赖装不上就定“优先用 CDN 或标准库”。WorkBuddy 的规则是跨对话生效的所以定一次就行。但如果你换了项目类型比如从 3D 游戏换到写文献综述可能需要调整规则。这时候可以建不同的工作区每个工作区配不同的规则。6.2 缓存目录和性能的关系前面提过把缓存目录改到 D 盘。这里补充一下为什么。WorkBuddy 在运行时会缓存模型响应、临时文件、依赖包等。3D 游戏项目里Three.js 这类库的文件不小缓存会快速增长。如果 C 盘是系统盘且空间紧张缓存满了会导致 WorkBuddy 卡顿甚至报错。改缓存目录的路径在设置里不同版本位置可能略有差异一般在“高级设置”或“存储”分类下。改完记得重启。如果你用的是 Linux缓存默认在~/.cache下一般不用改除非你的 home 分区很小。6.3 多模型切换的实用场景WorkBuddy 支持配置多个模型源并切换这个能力在实测里很有用。我的用法是搭结构阶段用 Step 5 Preview它的文件组织最清晰。写复杂逻辑用 DeepSeek V4 Pro它的代码密度高能一次给全。调平衡和收尾用 GLM5.3它比较克制不会乱加东西。当然这只是我这次项目的用法你可以根据自己的习惯调整。关键是把模型当成不同风格的同事而不是一个万能工具。6.4 关于私有化部署的考虑如果你对数据敏感WorkBuddy 支持私有化部署。这意味着模型推理可以在你自己的服务器上跑代码和数据不出内网。部署方式一般是 Docker官方会提供镜像。这里要注意的是私有化部署对硬件有要求尤其是跑大模型需要足够的显存。如果你只是个人开发用云端模型源就够了如果是团队协作且有合规要求再考虑私有化。Docker 安装 WorkBuddy 的流程大致是拉镜像、配环境变量、映射端口和数据卷。具体命令官方文档有我不在这里展开因为版本更新快以官方为准。7. 我个人的一些体会这次实测做下来最大的感受是模型之间的差距在简单任务上不明显在 3D 游戏这种综合任务上才拉开。Step 5 Preview 的结构感、DeepSeek V4 Pro 的代码密度、GLM5.3 的平衡性各有各的适用场景。没有哪个绝对最好关键看你要什么。另一个体会是WorkBuddy 这类工作台的价值不在于模型本身而在于它把“生成-执行-验证”串成了闭环。同样一个模型在纯聊天窗口里和在能执行命令的工作台里产出质量完全不一样。因为后者逼着模型面对真实报错而不是自说自话。最后分享一个小技巧如果你要做类似的多模型对比一定要把提示词和规则固定下来只换模型。否则你分不清差异是来自模型还是来自你的描述。我这次就是先把任务描述和四条规则写死然后逐个切换模型跑这样对比才有意义。这个项目后续还可以扩展比如加入敌人 AI、道具系统、关卡切换。每加一个系统都是对模型工程能力的新考验。我打算下次试试让它们做联机对战那个复杂度会再上一个台阶。