1. 三款模型同台竞技这场3D游戏实测到底在测什么最近圈子里讨论度比较高的一件事就是拿 Step 5 Preview、DeepSeek V4 Pro 和 GLM5.3 这三个模型让它们分别从零开始做一个 3D 游戏。我花了大概两天时间把这三套流程都跑了一遍中间踩了不少坑也积累了一些比较实在的体会。这篇文章就把整个实测过程拆开来讲包括我怎么设计测试任务、每个模型在哪些环节表现好、哪些环节翻车、以及最后怎么用 WorkBuddy 这类工具把整个流程串起来。先说清楚这个实测的核心目标。3D 游戏开发是一个典型的多环节串联任务它不像写一个排序算法那样单点可控而是涉及场景搭建、相机控制、光照系统、物理碰撞、交互逻辑、资源加载、性能优化等一大堆互相耦合的模块。用一句话概括3D 游戏是检验一个代码生成模型综合工程能力的试金石。你让它写个贪吃蛇大部分模型都能糊弄过去但你让它做一个带第一人称视角、能走动、能拾取物品、有基本碰撞检测的 3D 场景问题就会集中暴露出来。我这次选的是一个相对克制的题目一个基于 Web 的 3D 第一人称漫游小游戏。技术栈限定在 Three.js 原生 JavaScript不引入额外的物理引擎碰撞检测自己手写 AABB。为什么这么设计因为如果允许用 Cannon.js 或者 Rapier 这类物理引擎模型很可能直接调库把碰撞逻辑甩给引擎反而看不出它对空间几何的理解能力。手写 AABB 碰撞虽然简单但能直接反映模型对坐标系、包围盒、向量运算的掌握程度。测试的评判维度我列了六个场景初始化完整性、相机与控制器逻辑、光照与材质表现、碰撞检测正确性、交互逻辑闭环、代码可运行性。每个维度我按 1 到 5 分打分最后汇总。这个评分标准不是拍脑袋定的而是根据我过去做 Web 3D 项目的经验把最容易出问题的环节单独拎出来。比如光照和材质很多模型生成的代码能跑但场景一片死黑或者全白过曝这就是典型的能运行但不可用。三个模型的接入方式也统一了都通过 WorkBuddy 的工作台来调用这样可以保证提示词、上下文长度、温度参数等外部条件尽量一致。WorkBuddy 在这里扮演的是一个统一调度层的角色它本身不生成代码但负责把任务分发给不同模型、管理对话历史、缓存中间产物。这一点很关键因为如果我用三个不同的客户端分别调用光是环境差异就可能引入干扰变量。提示做这类横向对比测试最重要的原则是控制变量。模型版本、提示词、温度、最大输出长度、甚至网络环境都要尽量拉齐否则测出来的差异你根本分不清是模型能力问题还是环境问题。2. 测试任务设计与提示词工程2.1 为什么选第一人称漫游作为测试场景第一人称漫游看起来简单实际上它把 3D 开发里几个核心难点都覆盖了。首先是相机控制你需要处理鼠标移动映射到相机旋转、键盘输入映射到位移、以及两者之间的坐标系转换。其次是碰撞检测玩家不能穿墙这就需要在每一帧里计算玩家包围盒和场景物体的相交情况。第三是场景组织地面、墙壁、障碍物、可交互物品这些对象的层级关系和坐标摆放需要合理规划。我对比过其他几种测试场景比如做一个旋转的立方体太简单区分度不够做一个带骨骼动画的角色又太偏美术管线代码生成模型在这块本来就不擅长测出来大家都差没有区分意义。第一人称漫游刚好卡在中间难度足够暴露问题但又不至于超出代码模型的能力边界。具体任务描述我是这么写的生成一个完整的 HTML 文件使用 Three.js CDN 引入场景中包含一个 20x20 的地面平面、四面围墙、若干随机分布的立方体障碍物玩家以第一人称视角在场景中移动WASD 控制前后左右鼠标控制视角碰到墙壁或障碍物时停止移动按 E 键可以与最近的障碍物交互改变其颜色。要求代码可以直接在浏览器打开运行不需要构建工具。2.2 提示词里的三个关键约束提示词工程这块我下了点功夫因为如果提示词写得太宽松模型会自由发挥最后三个模型做出来的东西差异太大没法对比。所以我加了三个硬约束。第一个约束是单文件输出。不允许拆分多个 JS 文件不允许用 import 语句所有逻辑写在一个 HTML 里。这个约束的目的是排除模块系统带来的干扰同时也能看出模型对代码组织的能力——单文件里怎么划分函数、怎么管理状态很能说明问题。第二个约束是不使用 OrbitControls 等现成控制器。Three.js 自带的 OrbitControls 虽然方便但它是轨道控制器不是第一人称控制器。如果允许用模型很可能直接套上去那就测不出它对相机矩阵的理解了。我要求手写相机旋转逻辑用 Euler 角或者四元数都行。第三个约束是碰撞检测必须手写。不允许引入任何物理库AABB 也好球体检测也好自己实现。这个约束是最能拉开差距的因为碰撞检测涉及向量运算、包围盒更新、每帧检测逻辑链条比较长模型很容易在某个环节出错。注意提示词里我特意没有给出具体的代码结构建议比如你应该写一个 update 函数之类的。因为一旦给了结构提示就等于替模型做了设计决策测出来的就不是它的真实能力了。2.3 WorkBuddy 在测试流程中的角色WorkBuddy 在这个测试里主要承担三件事。第一是统一调用入口我把三个模型的 API 都配置在 WorkBuddy 里通过它的工作台切换模型这样提示词和参数设置可以复用同一套模板。第二是对话历史管理3D 游戏这种任务往往需要多轮迭代第一版生成后我要指出问题让它改WorkBuddy 的跨对话记忆功能在这里很有用它能记住上一轮生成的代码结构改的时候不会把整个文件重写一遍。第三是缓存目录管理生成的 HTML 文件、截图、日志都统一存在 WorkBuddy 的工作目录下方便我后续对比。这里插一句关于 WorkBuddy 缓存目录的事。默认情况下它的缓存和对话记录是存在系统盘的跑这种多模型对比测试生成的中间文件很快就上 G 了。我把它改到了 D 盘具体操作是在设置里找到存储路径配置改成自定义目录。如果你也用 WorkBuddy 做类似测试建议一开始就把这个改好不然系统盘很快就红了。3. 三个模型的首轮生成表现对比3.1 Step 5 Preview结构最完整但细节有瑕疵Step 5 Preview 的首轮输出让我有点意外。它生成的代码结构非常清晰函数划分合理有 init()、createScene()、createPlayer()、update()、animate() 这几个主要函数职责边界明确。场景初始化部分地面、围墙、障碍物的创建逻辑都写对了坐标计算也没有问题。相机控制这块它用的是 Euler 角方案监听 mousemove 事件把鼠标位移映射到 yaw 和 pitch 两个角度上然后设置相机的 rotation。这个方案本身没问题但它犯了一个经典错误没有限制 pitch 的范围。结果就是鼠标往上一直移相机会翻转过来出现万向节死锁的视觉效果。这个问题在实测中很常见很多模型都知道要用 Euler 角但忘了 clamp 俯仰角。碰撞检测部分Step 5 Preview 写了一个 checkCollision 函数用 AABB 检测玩家和障碍物的相交。逻辑基本正确但它把玩家的包围盒固定成了 1x1x1 的立方体没有考虑玩家实际是一个点加一个半径的概念。这导致玩家在靠近墙壁时视觉上还没碰到墙移动就被挡住了手感很别扭。正确的做法应该是用一个较小的半径比如 0.3来做碰撞检测而不是用一个完整的人形包围盒。交互逻辑它倒是做完了按 E 键会找到最近的障碍物并改变颜色。但最近的判断用的是玩家位置到障碍物中心的距离没有考虑障碍物的大小差异如果障碍物大小不一这个判断就不准了。综合打分场景初始化 5 分相机控制 3 分光照材质 4 分碰撞检测 3 分交互逻辑 4 分可运行性 5 分。总分 24/30。3.2 DeepSeek V4 Pro碰撞检测最扎实DeepSeek V4 Pro 的首轮输出在碰撞检测这块明显更扎实。它没有用简单的 AABB而是用了一个膨胀包围盒的思路把玩家的位置当作一个点然后把所有障碍物的包围盒向外膨胀一个玩家半径再检测这个点是否落在膨胀后的盒子里。这个思路在游戏开发里叫 Minkowski 和是处理点对盒碰撞的标准做法。这个细节让我对 DeepSeek V4 Pro 的评价高了一档因为它说明模型不只是知道 AABB而是理解 AABB 在游戏场景里怎么用才合理。膨胀包围盒的好处是计算量小只需要检测点是否在盒内而且不会出现视觉上没碰到但移动被挡的问题。相机控制它用的是四元数方案通过累积鼠标位移来构造旋转四元数然后应用到相机上。这个方案比 Euler 角更稳健不会出现万向节死锁。但它也有个小问题没有做鼠标灵敏度归一化不同分辨率下鼠标移动同样的像素距离视角旋转角度不一样。这个在实测中影响不大但严格来说是个缺陷。光照部分 DeepSeek V4 Pro 做得比较基础就一个环境光加一个平行光没有阴影。场景能看清但缺乏立体感。材质用的是 MeshLambertMaterial性能好但表现力一般。交互逻辑它做得比 Step 5 Preview 细找最近障碍物时用了包围盒中心距离减去包围盒半径的方式相当于算了表面距离这个更准确。综合打分场景初始化 5 分相机控制 4 分光照材质 3 分碰撞检测 5 分交互逻辑 5 分可运行性 5 分。总分 27/30。3.3 GLM5.3代码最简洁但功能有缺失GLM5.3 的首轮输出走的是极简路线整个 HTML 文件只有两百多行比另外两个模型少了将近一半。代码确实干净可读性好但功能上有明显缺失。最突出的问题是碰撞检测只做了墙壁没做障碍物。它写了一个边界检测函数判断玩家位置是否超出地面范围超出就拉回来。但场景中间那些立方体障碍物玩家可以直接穿过去。这个缺失比较致命因为障碍物碰撞是任务明确要求的。相机控制它用的是和 Step 5 Preview 类似的 Euler 角方案同样没有 clamp pitch。不过它的鼠标事件处理写得比较简洁用了 pointerlock 的 movementX 和 movementY这个比手动算 clientX 差值更准确。光照和材质是 GLM5.3 的弱项它只用了一个环境光没有方向光导致所有物体看起来都是平的没有明暗对比。材质用的是 MeshBasicMaterial完全不响应光照场景看起来像纸片。交互逻辑它做了但触发距离设得太大隔着好几米就能触发体验不好。综合打分场景初始化 4 分相机控制 3 分光照材质 2 分碰撞检测 2 分交互逻辑 3 分可运行性 5 分。总分 19/30。3.4 首轮对比小结把三个模型的首轮表现放在一张表里看更清楚评判维度Step 5 PreviewDeepSeek V4 ProGLM5.3场景初始化554相机控制343光照材质432碰撞检测352交互逻辑453可运行性555总分242719从首轮结果看DeepSeek V4 Pro 在工程细节上最扎实Step 5 Preview 结构最完整但细节有瑕疵GLM5.3 代码最简洁但功能缺失明显。不过首轮只是起点真正能拉开差距的是迭代修改环节。4. 迭代修改环节的实战记录4.1 第一轮修改修复相机翻转问题首轮生成后我给三个模型都发了同样的修改指令修复鼠标上下移动时相机翻转的问题限制俯仰角范围。Step 5 Preview 的修改很直接它在 mousemove 处理函数里加了一行pitch Math.max(-Math.PI/2, Math.min(Math.PI/2, pitch))把 pitch 限制在正负 90 度之间。改完之后相机确实不翻转了但新的问题出现了在接近 90 度的时候视角旋转变得很卡顿。这是因为 Euler 角在接近万向节死锁点时两个旋转轴的耦合会导致数值不稳定。这个问题其实首轮就埋下了只是没翻转的时候看不出来。DeepSeek V4 Pro 因为本来就用四元数所以它没有翻转这个问题。我发给它的修改指令它理解成了确认相机旋转是否稳定回复说当前实现已经避免了万向节死锁不需要修改。我又追问了一句那鼠标灵敏度在不同分辨率下一致吗它才意识到问题加了一个基于设备像素比的归一化系数。GLM5.3 的修改和 Step 5 Preview 类似也是加 clamp。但它加的位置不对加在了设置相机 rotation 之后导致 clamp 的值没有生效。我指出后它才改到正确位置。这个细节说明 GLM5.3 对代码执行顺序的理解还不够细致。实操心得迭代修改时不要只说有问题要具体描述什么操作触发什么问题。比如鼠标往上移到顶时相机会翻转比相机有问题能让模型更准确地定位。4.2 第二轮修改补全碰撞检测第二轮我针对碰撞检测发指令。给 Step 5 Preview 的指令是把玩家包围盒改小用半径 0.3 的球体做碰撞检测。它改完之后玩家贴墙移动的手感好多了但出现了新的 bug在墙角处会卡住。原因是球体和两个墙面同时相交时它的碰撞响应逻辑是分别处理每个轴导致在两个轴上都回退玩家就被推到了墙角外面。正确的做法是先计算碰撞法线然后沿法线方向推出。DeepSeek V4 Pro 这轮不需要大改它的膨胀包围盒方案本来就工作良好。我只让它加了一个滑动效果碰到墙时不是完全停止而是沿墙面方向滑动。它用向量投影实现了这个效果代码写得很干净。GLM5.3 这轮改动最大因为它首轮根本没做障碍物碰撞。我让它参考墙壁碰撞的逻辑给每个障碍物也加上碰撞检测。它改完之后能用了但性能有问题每帧都遍历所有障碍物做检测障碍物一多帧率就掉。我提醒它可以用空间划分或者简单的距离预筛选它加了一个基于玩家位置的粗筛先过滤掉距离远的障碍物性能改善明显。4.3 第三轮修改光照与材质优化第三轮我统一要求三个模型优化光照和材质目标是场景有立体感物体有明暗对比。Step 5 Preview 加了一个方向光开启了阴影映射材质换成了 MeshStandardMaterial。效果提升明显但阴影边缘有锯齿。我让它调 shadow map 的分辨率它从默认的 512 提到了 2048锯齿基本消失。DeepSeek V4 Pro 加了半球光加方向光的组合材质也换成了 MeshStandardMaterial还加了环境贴图。效果是三个里最好的但环境贴图它用的是一个在线 URL我要求改成程序化生成避免外部依赖。它用 PMREMGenerator 生成了一个简单的渐变环境贴图效果也不错。GLM5.3 这轮提升最大从 MeshBasicMaterial 换到 MeshStandardMaterial加了方向光场景一下子从纸片变成了立体。但它忘了设置材质的 roughness 和 metalness默认值下物体看起来像塑料。我提醒后它调了参数质感好了一些。4.4 迭代环节的评分变化三轮迭代后重新打分评判维度Step 5 PreviewDeepSeek V4 ProGLM5.3场景初始化555相机控制454光照材质454碰撞检测454交互逻辑454可运行性555总分263026迭代之后三个模型的差距缩小了但 DeepSeek V4 Pro 依然保持领先。这个结果说明一个规律首轮生成看的是模型的默认水平迭代修改看的是模型的理解能力。有些模型首轮写得好但你指出问题后它改不对有些模型首轮一般但你说什么它都能准确理解并改到位。5. 三个模型的能力画像与适用场景5.1 Step 5 Preview结构型选手Step 5 Preview 最大的特点是代码结构清晰。它生成的代码像是一个有经验的开发者写的函数划分合理命名规范注释到位。这个特点在多人协作或者需要后续维护的项目里很有价值。它的弱项在于细节处理不够严谨。相机 clamp 忘了加、碰撞盒大小不合理、墙角卡住这些都是知道概念但没考虑边界情况的表现。用它的代码你需要有一定的 review 能力把那些边界情况补上。适合场景快速搭建项目骨架、生成结构清晰的样板代码、需要后续人工接手二次开发的项目。5.2 DeepSeek V4 Pro工程型选手DeepSeek V4 Pro 在工程细节上明显更扎实。膨胀包围盒、四元数相机、向量投影滑动这些都不是教科书上的标准答案而是有实战经验的人才会用的方案。它生成的代码可能不是最简洁的但鲁棒性最好。它的弱项是首轮光照材质偏保守需要你主动提要求它才会去优化。另外它的代码有时候会写得比较长如果你追求极简可能需要自己精简。适合场景对稳定性要求高的项目、需要处理复杂交互逻辑的场景、不想花太多时间在 debug 上的快速原型。5.3 GLM5.3简洁型选手GLM5.3 的代码最简洁可读性最好适合快速理解逻辑。但它的功能覆盖度不够首轮经常漏掉一些要求。你需要把需求拆得很细一条一条喂给它它才能做全。它的优势在于迭代响应快你指出问题后它能快速给出修改而且修改的代码量通常不大不会把整个文件重写。这个特点在快速迭代的场景下很有用。适合场景需求明确且拆分细致的小功能开发、需要快速验证想法的原型、对代码体积有要求的场景。5.4 用 WorkBuddy 统一管理多模型工作流这次测试我是用 WorkBuddy 来统一调度的用下来有几个体会。第一是模型切换很方便在同一个工作台里切换模型提示词模板和上下文可以复用不用来回倒腾。第二是对话记录管理三个模型的对话历史分开存不会串回看的时候很清楚。第三是缓存目录要提前改默认在系统盘跑这种测试很快就占满了我改到 D 盘之后舒服多了。WorkBuddy 的自定义指令功能我也用上了。我给它定了几条规则比如生成代码时优先考虑边界情况、修改代码时只输出改动部分这些规则对所有任务生效省得我每次都要重复说。这个功能在批量测试的时候特别省事。提示如果你也用 WorkBuddy 做多模型对比建议给每个模型单独建一个工作区不要混在一起。混在一起的话对话历史会互相干扰模型可能会参考另一个模型的输出测出来的结果就不准了。6. 常见问题与排查技巧实录6.1 代码能运行但场景一片黑这是最常见的问题三个模型首轮都出现过。原因通常是光照没配好或者相机位置在物体内部。排查顺序先看控制台有没有报错再看相机位置是不是在原点如果在原点且场景物体也在原点附近相机可能被包在物体里最后检查光照强度和材质类型是否匹配。MeshBasicMaterial 不响应光照如果你用了这个材质又只加了环境光场景看起来就是平的。MeshStandardMaterial 需要方向光或者点光源才能看出立体感。这个坑我踩过好几次现在养成习惯生成代码后先看材质类型再看光源类型两者要匹配。6.2 鼠标控制视角时灵时不灵这个问题通常是事件监听的问题。有的模型把 mousemove 监听加在 document 上有的加在 canvas 上有的用了 pointerlock。如果没用 pointerlock鼠标移出窗口后视角就不动了。如果用了 pointerlock需要用户先点击一下才能锁定。排查方法打开控制台在 mousemove 回调里打日志看鼠标移动时有没有触发。如果没有就是监听没加上如果有但视角不动就是旋转计算有问题。6.3 碰撞检测导致玩家卡在墙角这是 AABB 碰撞的经典问题。当玩家同时和两个垂直的墙面相交时如果碰撞响应是分别沿 X 轴和 Z 轴回退玩家就会被推到两个墙面外侧的角落。正确的做法是计算碰撞法线然后沿法线方向推出。排查方法把玩家移到墙角看它是被挡住还是被弹开。如果被弹到墙外就是碰撞响应逻辑有问题。修复方案是用向量投影或者用最小平移向量MTV算法。6.4 帧率随障碍物数量增加而下降这是性能问题通常是每帧遍历所有障碍物做碰撞检测导致的。障碍物少的时候看不出来多了就明显。优化方案有两种一是空间划分把场景分成网格只检测玩家所在网格及相邻网格的障碍物二是距离预筛选先算玩家和障碍物的距离超过一定阈值的直接跳过。排查方法打开浏览器的性能面板看每帧的脚本执行时间。如果碰撞检测占了大部分时间就是这个问题。6.5 常见问题速查表问题现象可能原因排查方法修复方案场景一片黑光照未配置或材质不匹配检查光源类型和材质类型加方向光换 MeshStandardMaterial视角翻转未限制俯仰角鼠标上下移动到底看是否翻转clamp pitch 到正负 90 度墙角卡住碰撞响应分轴处理走到墙角看是否被弹开用碰撞法线或 MTV 算法帧率下降每帧遍历所有障碍物性能面板看脚本执行时间空间划分或距离预筛选鼠标控制失灵事件监听未生效控制台打日志看是否触发检查监听目标和 pointerlock物体像纸片用了 MeshBasicMaterial检查材质类型换成响应光照的材质6.6 几个独家避坑技巧第一个技巧生成代码后先跑一遍再改。不要一上来就 review 代码先跑起来看效果很多问题跑一遍就暴露了比看代码快得多。第二个技巧修改指令要具体到函数。比如修改 update 函数里的碰撞检测逻辑比碰撞检测有问题能让模型更准确地定位。模型不知道你的代码里哪个函数负责什么你告诉它它改起来就快。第三个技巧保留每一版的代码。迭代修改的时候模型有时候会把之前改好的地方又改回去。保留每一版出问题可以对比也可以回退。第四个技巧用 WorkBuddy 的跨对话记忆功能。3D 游戏这种多轮迭代的任务如果每次都要重新贴一遍代码效率很低。WorkBuddy 能记住上一轮的代码结构改的时候直接说把第 50 行的碰撞检测改成膨胀包围盒就行。7. 实测后的选型建议跑完这轮实测我对三个模型的定位有了比较清晰的认识。如果你要做的是快速原型验证GLM5.3 够用代码简洁改起来快但你要接受它首轮功能不全需要多轮迭代。如果你要做的是需要稳定运行的项目DeepSeek V4 Pro 是首选它的工程细节最扎实边界情况考虑得最全能帮你省下大量 debug 时间。如果你要做的是需要多人协作或者后续维护的项目Step 5 Preview 的结构优势就体现出来了代码清晰接手的人容易看懂。当然这三个模型不是互斥的。我现在的做法是用 Step 5 Preview 搭骨架用 DeepSeek V4 Pro 补细节用 GLM5.3 做快速验证。三个配合起来用效率比单用一个高不少。WorkBuddy 的多模型管理功能正好支持这种用法切换模型不用重新配置环境提示词和上下文都能复用。最后分享一个我在实测中总结的小经验不要指望任何一个模型一次生成就能直接用的 3D 游戏代码。三个模型首轮都有问题区别只是问题的多少和严重程度。真正决定最终质量的是你的迭代能力和对问题的定位能力。模型是工具你是主导这个关系不能反过来。 
长河君 · 2026/11/3 12:17:11 · 阅读 1.2k 三大代码模型3D游戏实测：Step 5、DeepSeek V4 Pro与GLM5.3工程能力对比
1. 三款模型同台竞技这场3D游戏实测到底在测什么最近圈子里讨论度比较高的一件事就是拿 Step 5 Preview、DeepSeek V4 Pro 和 GLM5.3 这三个模型让它们分别从零开始做一个 3D 游戏。我花了大概两天时间把这三套流程都跑了一遍中间踩了不少坑也积累了一些比较实在的体会。这篇文章就把整个实测过程拆开来讲包括我怎么设计测试任务、每个模型在哪些环节表现好、哪些环节翻车、以及最后怎么用 WorkBuddy 这类工具把整个流程串起来。先说清楚这个实测的核心目标。3D 游戏开发是一个典型的多环节串联任务它不像写一个排序算法那样单点可控而是涉及场景搭建、相机控制、光照系统、物理碰撞、交互逻辑、资源加载、性能优化等一大堆互相耦合的模块。用一句话概括3D 游戏是检验一个代码生成模型综合工程能力的试金石。你让它写个贪吃蛇大部分模型都能糊弄过去但你让它做一个带第一人称视角、能走动、能拾取物品、有基本碰撞检测的 3D 场景问题就会集中暴露出来。我这次选的是一个相对克制的题目一个基于 Web 的 3D 第一人称漫游小游戏。技术栈限定在 Three.js 原生 JavaScript不引入额外的物理引擎碰撞检测自己手写 AABB。为什么这么设计因为如果允许用 Cannon.js 或者 Rapier 这类物理引擎模型很可能直接调库把碰撞逻辑甩给引擎反而看不出它对空间几何的理解能力。手写 AABB 碰撞虽然简单但能直接反映模型对坐标系、包围盒、向量运算的掌握程度。测试的评判维度我列了六个场景初始化完整性、相机与控制器逻辑、光照与材质表现、碰撞检测正确性、交互逻辑闭环、代码可运行性。每个维度我按 1 到 5 分打分最后汇总。这个评分标准不是拍脑袋定的而是根据我过去做 Web 3D 项目的经验把最容易出问题的环节单独拎出来。比如光照和材质很多模型生成的代码能跑但场景一片死黑或者全白过曝这就是典型的能运行但不可用。三个模型的接入方式也统一了都通过 WorkBuddy 的工作台来调用这样可以保证提示词、上下文长度、温度参数等外部条件尽量一致。WorkBuddy 在这里扮演的是一个统一调度层的角色它本身不生成代码但负责把任务分发给不同模型、管理对话历史、缓存中间产物。这一点很关键因为如果我用三个不同的客户端分别调用光是环境差异就可能引入干扰变量。提示做这类横向对比测试最重要的原则是控制变量。模型版本、提示词、温度、最大输出长度、甚至网络环境都要尽量拉齐否则测出来的差异你根本分不清是模型能力问题还是环境问题。2. 测试任务设计与提示词工程2.1 为什么选第一人称漫游作为测试场景第一人称漫游看起来简单实际上它把 3D 开发里几个核心难点都覆盖了。首先是相机控制你需要处理鼠标移动映射到相机旋转、键盘输入映射到位移、以及两者之间的坐标系转换。其次是碰撞检测玩家不能穿墙这就需要在每一帧里计算玩家包围盒和场景物体的相交情况。第三是场景组织地面、墙壁、障碍物、可交互物品这些对象的层级关系和坐标摆放需要合理规划。我对比过其他几种测试场景比如做一个旋转的立方体太简单区分度不够做一个带骨骼动画的角色又太偏美术管线代码生成模型在这块本来就不擅长测出来大家都差没有区分意义。第一人称漫游刚好卡在中间难度足够暴露问题但又不至于超出代码模型的能力边界。具体任务描述我是这么写的生成一个完整的 HTML 文件使用 Three.js CDN 引入场景中包含一个 20x20 的地面平面、四面围墙、若干随机分布的立方体障碍物玩家以第一人称视角在场景中移动WASD 控制前后左右鼠标控制视角碰到墙壁或障碍物时停止移动按 E 键可以与最近的障碍物交互改变其颜色。要求代码可以直接在浏览器打开运行不需要构建工具。2.2 提示词里的三个关键约束提示词工程这块我下了点功夫因为如果提示词写得太宽松模型会自由发挥最后三个模型做出来的东西差异太大没法对比。所以我加了三个硬约束。第一个约束是单文件输出。不允许拆分多个 JS 文件不允许用 import 语句所有逻辑写在一个 HTML 里。这个约束的目的是排除模块系统带来的干扰同时也能看出模型对代码组织的能力——单文件里怎么划分函数、怎么管理状态很能说明问题。第二个约束是不使用 OrbitControls 等现成控制器。Three.js 自带的 OrbitControls 虽然方便但它是轨道控制器不是第一人称控制器。如果允许用模型很可能直接套上去那就测不出它对相机矩阵的理解了。我要求手写相机旋转逻辑用 Euler 角或者四元数都行。第三个约束是碰撞检测必须手写。不允许引入任何物理库AABB 也好球体检测也好自己实现。这个约束是最能拉开差距的因为碰撞检测涉及向量运算、包围盒更新、每帧检测逻辑链条比较长模型很容易在某个环节出错。注意提示词里我特意没有给出具体的代码结构建议比如你应该写一个 update 函数之类的。因为一旦给了结构提示就等于替模型做了设计决策测出来的就不是它的真实能力了。2.3 WorkBuddy 在测试流程中的角色WorkBuddy 在这个测试里主要承担三件事。第一是统一调用入口我把三个模型的 API 都配置在 WorkBuddy 里通过它的工作台切换模型这样提示词和参数设置可以复用同一套模板。第二是对话历史管理3D 游戏这种任务往往需要多轮迭代第一版生成后我要指出问题让它改WorkBuddy 的跨对话记忆功能在这里很有用它能记住上一轮生成的代码结构改的时候不会把整个文件重写一遍。第三是缓存目录管理生成的 HTML 文件、截图、日志都统一存在 WorkBuddy 的工作目录下方便我后续对比。这里插一句关于 WorkBuddy 缓存目录的事。默认情况下它的缓存和对话记录是存在系统盘的跑这种多模型对比测试生成的中间文件很快就上 G 了。我把它改到了 D 盘具体操作是在设置里找到存储路径配置改成自定义目录。如果你也用 WorkBuddy 做类似测试建议一开始就把这个改好不然系统盘很快就红了。3. 三个模型的首轮生成表现对比3.1 Step 5 Preview结构最完整但细节有瑕疵Step 5 Preview 的首轮输出让我有点意外。它生成的代码结构非常清晰函数划分合理有 init()、createScene()、createPlayer()、update()、animate() 这几个主要函数职责边界明确。场景初始化部分地面、围墙、障碍物的创建逻辑都写对了坐标计算也没有问题。相机控制这块它用的是 Euler 角方案监听 mousemove 事件把鼠标位移映射到 yaw 和 pitch 两个角度上然后设置相机的 rotation。这个方案本身没问题但它犯了一个经典错误没有限制 pitch 的范围。结果就是鼠标往上一直移相机会翻转过来出现万向节死锁的视觉效果。这个问题在实测中很常见很多模型都知道要用 Euler 角但忘了 clamp 俯仰角。碰撞检测部分Step 5 Preview 写了一个 checkCollision 函数用 AABB 检测玩家和障碍物的相交。逻辑基本正确但它把玩家的包围盒固定成了 1x1x1 的立方体没有考虑玩家实际是一个点加一个半径的概念。这导致玩家在靠近墙壁时视觉上还没碰到墙移动就被挡住了手感很别扭。正确的做法应该是用一个较小的半径比如 0.3来做碰撞检测而不是用一个完整的人形包围盒。交互逻辑它倒是做完了按 E 键会找到最近的障碍物并改变颜色。但最近的判断用的是玩家位置到障碍物中心的距离没有考虑障碍物的大小差异如果障碍物大小不一这个判断就不准了。综合打分场景初始化 5 分相机控制 3 分光照材质 4 分碰撞检测 3 分交互逻辑 4 分可运行性 5 分。总分 24/30。3.2 DeepSeek V4 Pro碰撞检测最扎实DeepSeek V4 Pro 的首轮输出在碰撞检测这块明显更扎实。它没有用简单的 AABB而是用了一个膨胀包围盒的思路把玩家的位置当作一个点然后把所有障碍物的包围盒向外膨胀一个玩家半径再检测这个点是否落在膨胀后的盒子里。这个思路在游戏开发里叫 Minkowski 和是处理点对盒碰撞的标准做法。这个细节让我对 DeepSeek V4 Pro 的评价高了一档因为它说明模型不只是知道 AABB而是理解 AABB 在游戏场景里怎么用才合理。膨胀包围盒的好处是计算量小只需要检测点是否在盒内而且不会出现视觉上没碰到但移动被挡的问题。相机控制它用的是四元数方案通过累积鼠标位移来构造旋转四元数然后应用到相机上。这个方案比 Euler 角更稳健不会出现万向节死锁。但它也有个小问题没有做鼠标灵敏度归一化不同分辨率下鼠标移动同样的像素距离视角旋转角度不一样。这个在实测中影响不大但严格来说是个缺陷。光照部分 DeepSeek V4 Pro 做得比较基础就一个环境光加一个平行光没有阴影。场景能看清但缺乏立体感。材质用的是 MeshLambertMaterial性能好但表现力一般。交互逻辑它做得比 Step 5 Preview 细找最近障碍物时用了包围盒中心距离减去包围盒半径的方式相当于算了表面距离这个更准确。综合打分场景初始化 5 分相机控制 4 分光照材质 3 分碰撞检测 5 分交互逻辑 5 分可运行性 5 分。总分 27/30。3.3 GLM5.3代码最简洁但功能有缺失GLM5.3 的首轮输出走的是极简路线整个 HTML 文件只有两百多行比另外两个模型少了将近一半。代码确实干净可读性好但功能上有明显缺失。最突出的问题是碰撞检测只做了墙壁没做障碍物。它写了一个边界检测函数判断玩家位置是否超出地面范围超出就拉回来。但场景中间那些立方体障碍物玩家可以直接穿过去。这个缺失比较致命因为障碍物碰撞是任务明确要求的。相机控制它用的是和 Step 5 Preview 类似的 Euler 角方案同样没有 clamp pitch。不过它的鼠标事件处理写得比较简洁用了 pointerlock 的 movementX 和 movementY这个比手动算 clientX 差值更准确。光照和材质是 GLM5.3 的弱项它只用了一个环境光没有方向光导致所有物体看起来都是平的没有明暗对比。材质用的是 MeshBasicMaterial完全不响应光照场景看起来像纸片。交互逻辑它做了但触发距离设得太大隔着好几米就能触发体验不好。综合打分场景初始化 4 分相机控制 3 分光照材质 2 分碰撞检测 2 分交互逻辑 3 分可运行性 5 分。总分 19/30。3.4 首轮对比小结把三个模型的首轮表现放在一张表里看更清楚评判维度Step 5 PreviewDeepSeek V4 ProGLM5.3场景初始化554相机控制343光照材质432碰撞检测352交互逻辑453可运行性555总分242719从首轮结果看DeepSeek V4 Pro 在工程细节上最扎实Step 5 Preview 结构最完整但细节有瑕疵GLM5.3 代码最简洁但功能缺失明显。不过首轮只是起点真正能拉开差距的是迭代修改环节。4. 迭代修改环节的实战记录4.1 第一轮修改修复相机翻转问题首轮生成后我给三个模型都发了同样的修改指令修复鼠标上下移动时相机翻转的问题限制俯仰角范围。Step 5 Preview 的修改很直接它在 mousemove 处理函数里加了一行pitch Math.max(-Math.PI/2, Math.min(Math.PI/2, pitch))把 pitch 限制在正负 90 度之间。改完之后相机确实不翻转了但新的问题出现了在接近 90 度的时候视角旋转变得很卡顿。这是因为 Euler 角在接近万向节死锁点时两个旋转轴的耦合会导致数值不稳定。这个问题其实首轮就埋下了只是没翻转的时候看不出来。DeepSeek V4 Pro 因为本来就用四元数所以它没有翻转这个问题。我发给它的修改指令它理解成了确认相机旋转是否稳定回复说当前实现已经避免了万向节死锁不需要修改。我又追问了一句那鼠标灵敏度在不同分辨率下一致吗它才意识到问题加了一个基于设备像素比的归一化系数。GLM5.3 的修改和 Step 5 Preview 类似也是加 clamp。但它加的位置不对加在了设置相机 rotation 之后导致 clamp 的值没有生效。我指出后它才改到正确位置。这个细节说明 GLM5.3 对代码执行顺序的理解还不够细致。实操心得迭代修改时不要只说有问题要具体描述什么操作触发什么问题。比如鼠标往上移到顶时相机会翻转比相机有问题能让模型更准确地定位。4.2 第二轮修改补全碰撞检测第二轮我针对碰撞检测发指令。给 Step 5 Preview 的指令是把玩家包围盒改小用半径 0.3 的球体做碰撞检测。它改完之后玩家贴墙移动的手感好多了但出现了新的 bug在墙角处会卡住。原因是球体和两个墙面同时相交时它的碰撞响应逻辑是分别处理每个轴导致在两个轴上都回退玩家就被推到了墙角外面。正确的做法是先计算碰撞法线然后沿法线方向推出。DeepSeek V4 Pro 这轮不需要大改它的膨胀包围盒方案本来就工作良好。我只让它加了一个滑动效果碰到墙时不是完全停止而是沿墙面方向滑动。它用向量投影实现了这个效果代码写得很干净。GLM5.3 这轮改动最大因为它首轮根本没做障碍物碰撞。我让它参考墙壁碰撞的逻辑给每个障碍物也加上碰撞检测。它改完之后能用了但性能有问题每帧都遍历所有障碍物做检测障碍物一多帧率就掉。我提醒它可以用空间划分或者简单的距离预筛选它加了一个基于玩家位置的粗筛先过滤掉距离远的障碍物性能改善明显。4.3 第三轮修改光照与材质优化第三轮我统一要求三个模型优化光照和材质目标是场景有立体感物体有明暗对比。Step 5 Preview 加了一个方向光开启了阴影映射材质换成了 MeshStandardMaterial。效果提升明显但阴影边缘有锯齿。我让它调 shadow map 的分辨率它从默认的 512 提到了 2048锯齿基本消失。DeepSeek V4 Pro 加了半球光加方向光的组合材质也换成了 MeshStandardMaterial还加了环境贴图。效果是三个里最好的但环境贴图它用的是一个在线 URL我要求改成程序化生成避免外部依赖。它用 PMREMGenerator 生成了一个简单的渐变环境贴图效果也不错。GLM5.3 这轮提升最大从 MeshBasicMaterial 换到 MeshStandardMaterial加了方向光场景一下子从纸片变成了立体。但它忘了设置材质的 roughness 和 metalness默认值下物体看起来像塑料。我提醒后它调了参数质感好了一些。4.4 迭代环节的评分变化三轮迭代后重新打分评判维度Step 5 PreviewDeepSeek V4 ProGLM5.3场景初始化555相机控制454光照材质454碰撞检测454交互逻辑454可运行性555总分263026迭代之后三个模型的差距缩小了但 DeepSeek V4 Pro 依然保持领先。这个结果说明一个规律首轮生成看的是模型的默认水平迭代修改看的是模型的理解能力。有些模型首轮写得好但你指出问题后它改不对有些模型首轮一般但你说什么它都能准确理解并改到位。5. 三个模型的能力画像与适用场景5.1 Step 5 Preview结构型选手Step 5 Preview 最大的特点是代码结构清晰。它生成的代码像是一个有经验的开发者写的函数划分合理命名规范注释到位。这个特点在多人协作或者需要后续维护的项目里很有价值。它的弱项在于细节处理不够严谨。相机 clamp 忘了加、碰撞盒大小不合理、墙角卡住这些都是知道概念但没考虑边界情况的表现。用它的代码你需要有一定的 review 能力把那些边界情况补上。适合场景快速搭建项目骨架、生成结构清晰的样板代码、需要后续人工接手二次开发的项目。5.2 DeepSeek V4 Pro工程型选手DeepSeek V4 Pro 在工程细节上明显更扎实。膨胀包围盒、四元数相机、向量投影滑动这些都不是教科书上的标准答案而是有实战经验的人才会用的方案。它生成的代码可能不是最简洁的但鲁棒性最好。它的弱项是首轮光照材质偏保守需要你主动提要求它才会去优化。另外它的代码有时候会写得比较长如果你追求极简可能需要自己精简。适合场景对稳定性要求高的项目、需要处理复杂交互逻辑的场景、不想花太多时间在 debug 上的快速原型。5.3 GLM5.3简洁型选手GLM5.3 的代码最简洁可读性最好适合快速理解逻辑。但它的功能覆盖度不够首轮经常漏掉一些要求。你需要把需求拆得很细一条一条喂给它它才能做全。它的优势在于迭代响应快你指出问题后它能快速给出修改而且修改的代码量通常不大不会把整个文件重写。这个特点在快速迭代的场景下很有用。适合场景需求明确且拆分细致的小功能开发、需要快速验证想法的原型、对代码体积有要求的场景。5.4 用 WorkBuddy 统一管理多模型工作流这次测试我是用 WorkBuddy 来统一调度的用下来有几个体会。第一是模型切换很方便在同一个工作台里切换模型提示词模板和上下文可以复用不用来回倒腾。第二是对话记录管理三个模型的对话历史分开存不会串回看的时候很清楚。第三是缓存目录要提前改默认在系统盘跑这种测试很快就占满了我改到 D 盘之后舒服多了。WorkBuddy 的自定义指令功能我也用上了。我给它定了几条规则比如生成代码时优先考虑边界情况、修改代码时只输出改动部分这些规则对所有任务生效省得我每次都要重复说。这个功能在批量测试的时候特别省事。提示如果你也用 WorkBuddy 做多模型对比建议给每个模型单独建一个工作区不要混在一起。混在一起的话对话历史会互相干扰模型可能会参考另一个模型的输出测出来的结果就不准了。6. 常见问题与排查技巧实录6.1 代码能运行但场景一片黑这是最常见的问题三个模型首轮都出现过。原因通常是光照没配好或者相机位置在物体内部。排查顺序先看控制台有没有报错再看相机位置是不是在原点如果在原点且场景物体也在原点附近相机可能被包在物体里最后检查光照强度和材质类型是否匹配。MeshBasicMaterial 不响应光照如果你用了这个材质又只加了环境光场景看起来就是平的。MeshStandardMaterial 需要方向光或者点光源才能看出立体感。这个坑我踩过好几次现在养成习惯生成代码后先看材质类型再看光源类型两者要匹配。6.2 鼠标控制视角时灵时不灵这个问题通常是事件监听的问题。有的模型把 mousemove 监听加在 document 上有的加在 canvas 上有的用了 pointerlock。如果没用 pointerlock鼠标移出窗口后视角就不动了。如果用了 pointerlock需要用户先点击一下才能锁定。排查方法打开控制台在 mousemove 回调里打日志看鼠标移动时有没有触发。如果没有就是监听没加上如果有但视角不动就是旋转计算有问题。6.3 碰撞检测导致玩家卡在墙角这是 AABB 碰撞的经典问题。当玩家同时和两个垂直的墙面相交时如果碰撞响应是分别沿 X 轴和 Z 轴回退玩家就会被推到两个墙面外侧的角落。正确的做法是计算碰撞法线然后沿法线方向推出。排查方法把玩家移到墙角看它是被挡住还是被弹开。如果被弹到墙外就是碰撞响应逻辑有问题。修复方案是用向量投影或者用最小平移向量MTV算法。6.4 帧率随障碍物数量增加而下降这是性能问题通常是每帧遍历所有障碍物做碰撞检测导致的。障碍物少的时候看不出来多了就明显。优化方案有两种一是空间划分把场景分成网格只检测玩家所在网格及相邻网格的障碍物二是距离预筛选先算玩家和障碍物的距离超过一定阈值的直接跳过。排查方法打开浏览器的性能面板看每帧的脚本执行时间。如果碰撞检测占了大部分时间就是这个问题。6.5 常见问题速查表问题现象可能原因排查方法修复方案场景一片黑光照未配置或材质不匹配检查光源类型和材质类型加方向光换 MeshStandardMaterial视角翻转未限制俯仰角鼠标上下移动到底看是否翻转clamp pitch 到正负 90 度墙角卡住碰撞响应分轴处理走到墙角看是否被弹开用碰撞法线或 MTV 算法帧率下降每帧遍历所有障碍物性能面板看脚本执行时间空间划分或距离预筛选鼠标控制失灵事件监听未生效控制台打日志看是否触发检查监听目标和 pointerlock物体像纸片用了 MeshBasicMaterial检查材质类型换成响应光照的材质6.6 几个独家避坑技巧第一个技巧生成代码后先跑一遍再改。不要一上来就 review 代码先跑起来看效果很多问题跑一遍就暴露了比看代码快得多。第二个技巧修改指令要具体到函数。比如修改 update 函数里的碰撞检测逻辑比碰撞检测有问题能让模型更准确地定位。模型不知道你的代码里哪个函数负责什么你告诉它它改起来就快。第三个技巧保留每一版的代码。迭代修改的时候模型有时候会把之前改好的地方又改回去。保留每一版出问题可以对比也可以回退。第四个技巧用 WorkBuddy 的跨对话记忆功能。3D 游戏这种多轮迭代的任务如果每次都要重新贴一遍代码效率很低。WorkBuddy 能记住上一轮的代码结构改的时候直接说把第 50 行的碰撞检测改成膨胀包围盒就行。7. 实测后的选型建议跑完这轮实测我对三个模型的定位有了比较清晰的认识。如果你要做的是快速原型验证GLM5.3 够用代码简洁改起来快但你要接受它首轮功能不全需要多轮迭代。如果你要做的是需要稳定运行的项目DeepSeek V4 Pro 是首选它的工程细节最扎实边界情况考虑得最全能帮你省下大量 debug 时间。如果你要做的是需要多人协作或者后续维护的项目Step 5 Preview 的结构优势就体现出来了代码清晰接手的人容易看懂。当然这三个模型不是互斥的。我现在的做法是用 Step 5 Preview 搭骨架用 DeepSeek V4 Pro 补细节用 GLM5.3 做快速验证。三个配合起来用效率比单用一个高不少。WorkBuddy 的多模型管理功能正好支持这种用法切换模型不用重新配置环境提示词和上下文都能复用。最后分享一个我在实测中总结的小经验不要指望任何一个模型一次生成就能直接用的 3D 游戏代码。三个模型首轮都有问题区别只是问题的多少和严重程度。真正决定最终质量的是你的迭代能力和对问题的定位能力。模型是工具你是主导这个关系不能反过来。