1. 三款模型同台竞技这场3D游戏实测到底在测什么最近圈子里讨论度最高的一件事就是拿 Step 5 Preview、DeepSeek V4 Pro 和 GLM5.3 这三个模型让它们分别从零开始做一个 3D 游戏。我花了整整两天时间把这三个模型都跑了一遍同样的需求中间踩了不少坑也积累了一些比较实在的观察。这篇文章不吹不黑纯粹从一个实际使用者的角度把整个实测过程、每个模型的表现差异、以及我在这个过程中总结出来的经验教训尽可能完整地分享出来。先说清楚这个实测的背景。所谓同做一个3D游戏我给出的需求是完全一致的用 Three.js 做一个可以在浏览器里直接运行的 3D 小游戏包含基本的场景搭建、角色控制、碰撞检测、计分系统和简单的 UI 界面。需求描述控制在 200 字以内不提供任何额外的技术细节提示就看三个模型各自怎么理解、怎么拆解、怎么落地。这样做的好处是能最大程度看出每个模型在从模糊需求到可运行代码这个链条上的真实能力。为什么选 3D 游戏这个场景因为 3D 游戏开发本身就是一个综合性极强的任务。它同时涉及图形渲染、物理模拟、交互逻辑、状态管理、性能优化等多个维度任何一个环节掉链子最终跑起来的效果都会大打折扣。而且 3D 场景对代码的空间想象力要求很高模型不仅要写出能跑的代码还要保证视觉上的合理性——比如物体不能悬空、相机角度不能穿模、光照方向要符合直觉。这些细节恰恰是区分模型能不能用和好不好用的关键分水岭。另外要提一下 WorkBuddy 这个工具。这次实测中我有一部分调试和代码整理的工作是在 WorkBuddy 里完成的。它的工作台模式对于管理多个模型的输出对比非常方便尤其是跨对话记忆功能让我不用反复粘贴上下文。不过这篇文章的重点还是放在三个模型本身的对比上WorkBuddy 只是作为辅助工具顺带提一下。不管你是刚接触 AI 辅助开发的新手还是已经在项目里用模型写代码的老手这篇实测应该都能给你一些参考。新手可以看看不同模型的输出风格差异老手可以关注一下在复杂任务下各模型的短板在哪里。2. 实测方案设计与三个模型的初印象2.1 需求拆解一个3D游戏最少需要哪些模块在正式对比之前我先把这个 3D 游戏的需求拆解清楚。虽然我给模型的提示词很简短但我心里是有一个明确的验收标准的。一个能跑起来的 3D 小游戏至少需要以下几个核心模块场景初始化包括渲染器、相机、场景三大件的创建以及光照系统的搭建。这部分是基础中的基础写错了后面全白搭。角色与控制器玩家操控的角色模型用几何体代替也行以及键盘或鼠标的输入响应逻辑。这里涉及到移动速度、转向平滑度、边界限制等细节。碰撞检测角色与场景中其他物体的碰撞判断。最简单的做法是包围盒检测复杂一点可以用射线检测。游戏逻辑计分、计时、胜负判定、关卡切换等。这部分考验的是模型对状态管理的理解。UI 层分数显示、开始/结束界面、操作提示等。用 HTML 叠加层或者 Canvas 绘制都行。我之所以把验收标准定得这么细是因为之前吃过亏。有一次让某个模型做类似的任务代码跑起来确实没报错但角色移动是瞬移的碰撞检测完全失效计分逻辑也是错的。所以这次我特别关注每个模型在这些细节上的完成度。2.2 三个模型的首次响应风格差异一目了然三个模型拿到同样的需求后给出的第一版响应风格差异非常明显。Step 5 Preview 的响应最工程化。它先花了一段篇幅做需求分析把游戏拆成了场景层、逻辑层、交互层三个部分然后按模块逐个输出代码。代码结构很清晰变量命名规范注释也写得比较到位。但有一个问题它第一版输出的代码量非常大直接甩了将近 800 行出来而且中间没有做任何分段说明读起来有点累。DeepSeek V4 Pro 的风格偏教学式。它在输出代码之前先解释了 Three.js 的基本概念比如场景图、坐标系、材质和光照的关系。然后才给出代码代码量适中大概 400 行左右。它的注释风格是解释为什么这么做而不是说明这行在做什么这一点我个人比较喜欢。GLM5.3 的响应最直接。它几乎没做任何铺垫上来就是代码而且代码风格比较紧凑很多地方用了简写。第一版大概 350 行功能覆盖了基本需求但细节上有些粗糙。比如相机的初始位置设得不太合理导致第一屏看到的是一个很奇怪的角度。这里插一句如果你是在 WorkBuddy 里同时跑这三个模型建议给每个模型单独开一个对话窗口并且在系统指令里明确写上输出代码时按模块分段每段不超过 150 行。这个规则设一次后续所有任务都生效能省掉很多手动整理的麻烦。2.3 评测维度我到底在比什么为了尽量客观我给自己定了一个评测框架主要看四个维度评测维度具体考察点权重代码可运行性复制到本地后能否直接跑起来报错数量和严重程度30%功能完整度需求中提到的模块是否全部实现有无遗漏25%代码质量结构清晰度、命名规范、注释质量、可维护性25%视觉与交互效果实际运行后的画面合理性、操作手感、性能表现20%这个权重分配是我根据实际开发经验定的。代码可运行性排第一因为跑不起来的代码其他都是空谈。功能完整度排第二因为缺胳膊少腿的游戏没法用。代码质量和视觉效果各占四分之一左右这两个决定了你后续要不要花大量时间重构。提示如果你也想做类似的模型对比测试建议把评测维度提前定好并且每个维度都设定具体的检查项。不然很容易被模型输出的表面质量带偏忽略了实际运行效果。3. 逐项拆解三个模型在核心环节的真实表现3.1 场景搭建与光照谁的基础打得最扎实场景搭建是 3D 游戏的地基。三个模型在这一步的表现差异直接影响了后续所有环节的难度。Step 5 Preview 在这一步做得最规范。它创建了一个标准的透视相机视野角度设为 75 度近裁剪面 0.1远裁剪面 1000。这个参数组合是 Three.js 社区里比较通用的配置适合大多数中小型场景。光照方面它用了环境光加平行光的组合环境光强度 0.5平行光强度 1.0并且给平行光设置了阴影映射。阴影这个细节很多模型会忽略但 Step 5 Preview 主动加上了说明它对视觉效果的完整性有考虑。DeepSeek V4 Pro 的场景搭建也很扎实但风格不同。它用的是透视相机加半球光的方案半球光的好处是能模拟天空和地面的反射光画面会更柔和。不过它没有开启阴影可能是为了降低性能开销。这个取舍本身没问题但它在注释里没有说明为什么不加阴影对于想学习的用户来说少了一点信息。GLM5.3 在这一步的表现相对弱一些。它用的是正交相机虽然正交相机在某些场景下确实更合适但对于一个需要自由移动的 3D 游戏来说透视相机才是更自然的选择。而且它的光照只加了一个方向光没有环境光补光导致场景中背光面完全是黑的视觉上很生硬。我后来手动把 GLM5.3 的相机改成了透视相机加了一个强度 0.3 的环境光画面立刻正常了很多。这个修改本身不复杂但如果你是完全的新手可能根本不知道问题出在哪里。3.2 角色控制与移动手感细节决定体验角色控制是 3D 游戏里最影响手感的部分。三个模型在这一步的差距比场景搭建还要明显。Step 5 Preview 实现了一套基于速度向量的移动系统。它定义了移动速度、加速度、摩擦力三个参数角色的移动不是瞬间响应按键而是有一个加速和减速的过程。这个设计让操作手感更接近真实的游戏。具体参数是最大速度 5 单位/秒加速度 20 单位/秒²摩擦力 10 单位/秒²。我实测下来这个参数组合在默认场景尺度下手感很跟手不会太飘也不会太迟钝。DeepSeek V4 Pro 的移动逻辑更简单直接按键按下就移动松开就停止没有加速度和摩擦力的概念。这种方案的好处是代码简单、响应即时但缺点是移动看起来比较机械缺少一点游戏感。不过它在边界限制上做得很好角色移动到场景边缘时会被平滑地挡住不会穿出去。GLM5.3 的移动逻辑有一个明显的 bug它把移动速度直接乘在了每一帧的位移上但没有乘以帧间隔时间deltaTime。这意味着在 60Hz 刷新率的屏幕上角色移动速度是正常的但在 144Hz 屏幕上角色会移动得快一倍多。这是一个很典型的帧率依赖问题有经验的开发者一眼就能看出来但新手很容易忽略。注意帧率依赖问题是 3D 游戏开发中最常见的坑之一。任何与时间相关的计算都必须乘以 deltaTime。你可以这样理解deltaTime 是这一帧距离上一帧过了多少秒乘以它之后移动速度就变成了每秒移动多少单位与帧率无关。3.3 碰撞检测从能用 to 好用之间的距离碰撞检测是这次实测中区分度最大的环节。Step 5 Preview 用的是包围盒Box3检测方案。它给每个需要参与碰撞的物体都计算了一个包围盒然后在每一帧里检测角色包围盒与其他物体包围盒是否相交。这个方案实现简单、性能开销小对于这个规模的游戏来说完全够用。而且它在碰撞响应上做了处理当检测到碰撞时不是简单地阻止移动而是把角色推回到碰撞前的合法位置这样就不会出现角色卡在物体里的情况。DeepSeek V4 Pro 用的是射线检测方案。它从角色位置向移动方向发射一条射线如果射线击中了其他物体就阻止这次移动。这个方案比包围盒更精确尤其是在物体形状不规则的时候。但它有一个问题射线检测只能检测移动方向上的碰撞如果角色是斜着移动的可能会从两个物体的缝隙中穿过去。我在测试中确实遇到了这个情况角色从一个很窄的缝隙里挤了过去虽然不影响大局但说明这个方案不够严谨。GLM5.3 的碰撞检测实现得比较粗糙。它用的是简单的距离检测判断角色与物体中心的距离是否小于某个阈值。这个方案对于球形物体还行但对于方形物体就完全不准确了。我在测试中看到角色明明还没有碰到墙壁就被挡住了或者明明已经穿过了墙壁才被挡住。这个问题如果要修复基本上需要重写整个碰撞模块。3.4 计分系统与UI小模块里的大差异计分系统和 UI 虽然是相对独立的小模块但也能看出模型对完整产品的理解程度。Step 5 Preview 的计分系统设计得比较完整。它定义了一个游戏状态对象包含分数、时间、生命值等字段并且用观察者模式来更新 UI。当分数变化时会自动触发 UI 更新不需要手动调用刷新函数。这种设计在后续扩展时会很方便比如你想加一个连击奖励功能只需要修改计分逻辑UI 会自动跟着变。DeepSeek V4 Pro 的计分系统更直接分数变化时直接操作 DOM 元素更新显示。代码简单易懂但耦合度比较高计分逻辑和 UI 逻辑混在一起。如果后续要改 UI 样式或者换一种显示方式需要同时改多处代码。GLM5.3 的计分系统有一个逻辑错误它在每一帧都重新计算分数而不是在特定事件发生时更新。这导致分数显示一直在跳动虽然最终结果是对的但视觉上很混乱。而且它的 UI 是用 Canvas 绘制的而不是 HTML 叠加层这意味着 UI 的样式调整需要改绘图代码比改 CSS 麻烦不少。3.5 性能表现帧率与内存占用实测性能这块我用 Chrome 的 Performance 面板做了简单测试场景中放了 50 个随机分布的立方体角色持续移动记录 30 秒内的平均帧率和内存占用。模型平均帧率内存占用备注Step 5 Preview58-60 FPS约 85 MB稳定无明显掉帧DeepSeek V4 Pro55-60 FPS约 78 MB偶尔掉到 55整体流畅GLM5.345-60 FPS约 92 MB波动较大有卡顿感Step 5 Preview 的性能表现最稳定这跟它用了包围盒检测和合理的对象复用有关。DeepSeek V4 Pro 的内存占用最低可能是因为它没有开启阴影渲染开销小一些。GLM5.3 的帧率波动最大我排查了一下发现它在每一帧都重新创建了一些临时对象导致垃圾回收频繁触发这是性能波动的根源。4. 实操过程全记录从零到可运行游戏的完整流程4.1 环境准备与项目初始化不管你用哪个模型第一步都是把基础环境搭好。我用的方案是 Vite Three.js这是目前比较主流也比较轻量的组合。npm create vitelatest my-3d-game -- --template vanilla cd my-3d-game npm install three npm run dev这三行命令做完你就有了一个带热更新功能的开发环境。Vite 的好处是启动快、配置少对于这种小项目来说非常合适。如果你不想用构建工具也可以直接建一个 HTML 文件用 CDN 引入 Three.js但那样就没有模块化和热更新了调试起来会麻烦一些。提示Three.js 的版本更新比较频繁建议在 package.json 里锁定一个具体版本比如 three: 0.160.0避免因为版本升级导致 API 变化。我这次实测用的是 0.160.0三个模型的代码在这个版本下都能跑。项目结构我建议这样组织my-3d-game/ ├── index.html ├── src/ │ ├── main.js # 入口文件 │ ├── scene.js # 场景搭建 │ ├── player.js # 角色控制 │ ├── collision.js # 碰撞检测 │ ├── game.js # 游戏逻辑 │ └── ui.js # UI 管理 └── package.json这个结构不是必须的但按模块拆分文件有几个好处一是方便定位问题二是方便替换某个模块的实现三是如果你要对比不同模型的代码可以一个模块一个模块地替换不用整体重写。4.2 把模型输出落地到项目里的关键步骤模型输出的代码通常是一个大文件直接复制到项目里能跑但不好维护。我的做法是先把模型输出的完整代码跑通确认功能没问题然后再按模块拆分。具体操作流程是这样的把模型输出的代码完整复制到main.js里运行npm run dev看控制台有没有报错。如果有报错先根据报错信息定位问题。常见的报错包括Three.js API 版本不匹配、变量未定义、语法错误等。报错解决后在浏览器里实际操作一下检查功能是否完整。重点检查角色能否移动、碰撞是否正常、计分是否准确、UI 是否显示。功能确认无误后按场景、角色、碰撞、逻辑、UI 五个模块拆分代码每个模块导出初始化函数和更新函数。在main.js里按顺序调用各模块的初始化函数在动画循环里按顺序调用更新函数。这个流程看起来简单但实际操作中有几个容易出问题的地方。比如模块之间的依赖关系如果player.js需要用到scene.js里的相机对象你就需要把相机对象作为参数传过去或者用一个全局的状态对象来管理。我建议用一个简单的状态对象把所有需要共享的对象都挂上去这样最省事。4.3 三个模型代码的融合与取舍在实际项目中我通常不会完全用某一个模型的输出而是取各家之长。这次实测中我的最终版本是这样的场景搭建和光照用 Step 5 Preview 的方案因为它的参数最合理阴影效果也最好。角色控制用 DeepSeek V4 Pro 的边界限制逻辑但加上了 Step 5 Preview 的加速度和摩擦力。碰撞检测用 Step 5 Preview 的包围盒方案因为它在准确性和性能之间平衡得最好。计分系统用 Step 5 Preview 的观察者模式但 UI 渲染改用 HTML 叠加层比 Canvas 更好调样式。GLM5.3 的代码我基本没有直接采用但它的紧凑风格提醒了我一件事不是所有代码都需要写得那么详细有些简单的逻辑用简写反而更清晰。这种融合做法在实际开发中很常见。每个模型都有自己的强项和弱项把它们的长处组合起来往往能得到比任何单一模型都好的结果。但前提是你自己要有判断能力知道哪部分好、哪部分不好。如果你刚开始用 AI 辅助开发建议先用一个模型跑通全流程等熟悉了再尝试融合。4.4 最终运行效果与验收最终版本跑起来的效果是这样的一个 20x20 单位的平面场景中间有一个玩家控制的立方体周围随机分布着 50 个彩色立方体。玩家用 WASD 控制移动碰到彩色立方体时会计分并让立方体消失所有立方体消失后显示通关提示。画面流畅操作跟手碰撞准确UI 清晰。验收的时候我重点检查了以下几个点在 60Hz 和 144Hz 屏幕上分别测试移动速度是否一致。结果是Step 5 Preview 的代码在两个屏幕上速度一致GLM5.3 的代码在 144Hz 屏幕上明显更快。快速连续按键时角色是否会卡住或穿模。结果是Step 5 Preview 和 DeepSeek V4 Pro 都没有问题GLM5.3 偶尔会卡在物体边缘。长时间运行后内存是否持续增长。结果是三个版本的内存都稳定在 80-95 MB 之间没有明显泄漏。注意验收时一定要在真实浏览器里操作不要只看代码逻辑。很多问题比如手感、视觉合理性、性能波动只有实际跑起来才能发现。我见过太多代码看起来没问题、跑起来一堆问题的案例。5. 常见问题与排查技巧实录5.1 模型输出代码跑不起来的五大原因在实测过程中我遇到了不少代码跑不起来的情况。总结下来主要有以下五种原因第一种Three.js API 版本不匹配。这是最常见的问题。比如旧版本用new THREE.Geometry()新版本已经废弃了必须用BufferGeometry。或者光照的 API 变了旧代码在新版本里会报错。解决办法是查 Three.js 的官方迁移指南或者直接把版本降到模型训练时使用的版本。第二种变量作用域错误。模型有时候会在一个函数里定义变量然后在另一个函数里使用但没有正确传递。这种错误在控制台里通常表现为 xxx is not defined。解决办法是仔细检查变量的定义位置和使用位置确保作用域正确。第三种异步加载顺序问题。如果模型用了异步加载纹理或模型文件但没有处理好加载完成的回调可能会导致在资源还没加载完时就开始渲染出现黑屏或报错。解决办法是用LoadingManager统一管理加载进度或者在加载完成后再启动动画循环。第四种DOM 元素未就绪。如果模型在script标签里直接操作 DOM但脚本放在了head里DOM 还没解析完就会报错。解决办法是把脚本放在body末尾或者用DOMContentLoaded事件包裹。第五种数学计算错误。比如向量归一化忘了调用.normalize()或者矩阵乘法顺序搞反了。这种错误不会报错但运行结果完全不对。解决办法是仔细检查所有涉及向量和矩阵的计算必要时手动验算一遍。5.2 帧率不稳定与内存泄漏的排查思路帧率不稳定和内存泄漏是 3D 游戏开发中的两大顽疾。我这次在 GLM5.3 的代码里就遇到了帧率波动的问题排查过程如下第一步打开 Chrome DevTools 的 Performance 面板录制 10 秒的运行过程。第二步看帧率曲线找到掉帧的时间点。第三步看那个时间点对应的函数调用栈找出耗时最长的函数。第四步分析那个函数为什么耗时是计算量大、还是频繁创建对象、还是触发了垃圾回收。我排查下来的结论是GLM5.3 在每一帧的渲染循环里都创建了新的Vector3对象和Box3对象这些对象用完就丢导致垃圾回收频繁触发。解决办法很简单把这些对象提到循环外面只创建一次在循环里复用。内存泄漏的排查思路类似但用的是 Memory 面板。录制一段时间的内存快照对比不同时间点的对象数量如果某个类型的对象数量持续增长就说明有泄漏。常见的泄漏原因包括事件监听器没有移除、定时器没有清除、闭包引用了不该引用的对象。5.3 模型看起来对但跑起来错的典型场景这是最让人头疼的一类问题代码逻辑看起来完全正确但实际运行结果就是不对。我遇到过的典型场景有坐标系搞混Three.js 用的是右手坐标系Y 轴向上。有些模型会按 Y 轴向上的习惯写代码但把 Z 轴和 Y 轴搞反了导致物体位置不对。单位不一致模型有时候假设 1 单位等于 1 米有时候假设 1 单位等于 1 厘米导致场景尺度混乱。解决办法是在项目开始时明确定义单位标准。光照方向反了平行光的方向是从位置指向目标点如果位置和目标点设反了光照方向就反了物体会出现奇怪的阴影。透明材质渲染顺序错误透明物体需要在不透明物体之后渲染如果顺序错了透明效果会不正常。Three.js 会自动处理大部分情况但有些特殊场景需要手动设置renderOrder。提示遇到看起来对但跑起来错的问题最快的排查方法是二分法。把代码分成两半注释掉一半看问题是否还在。如果还在说明问题在另一半如果不在说明问题在被注释掉的那一半。重复这个过程很快就能定位到具体哪一行。5.4 常见问题速查表问题现象可能原因排查方法解决方案控制台报 xxx is not defined变量作用域错误或拼写错误检查变量定义位置和拼写修正作用域或拼写画面全黑相机位置不对或光照缺失检查相机位置和光照配置调整相机位置添加环境光角色移动速度异常帧率依赖或速度参数错误检查是否乘以 deltaTime所有位移乘以 deltaTime碰撞检测失效包围盒未更新或检测逻辑错误打印包围盒位置和角色位置每帧更新包围盒检查相交逻辑帧率波动大频繁创建对象或垃圾回收用 Performance 面板录制复用对象减少临时变量内存持续增长事件监听器或定时器未清理用 Memory 面板对比快照移除无用监听器和定时器透明物体渲染异常渲染顺序错误检查 renderOrder 设置手动设置透明物体的 renderOrder纹理显示为黑色纹理加载失败或路径错误检查 Network 面板修正路径确保纹理加载完成6. 三个模型的选型建议与实战心得6.1 什么场景选什么模型经过这次实测我对三个模型的适用场景有了比较清晰的判断。Step 5 Preview 最适合从零到一的完整项目。它的代码结构最规范功能覆盖最全面细节处理最到位。如果你要做一个需要长期维护的项目或者你本身对代码质量有要求Step 5 Preview 是首选。它的缺点是输出比较长初次阅读需要耐心。DeepSeek V4 Pro 最适合教学式学习和快速原型开发。它的代码注释质量最高解释性最强适合用来理解某个技术点的实现原理。如果你只是想快速验证一个想法或者你正在学习 Three.jsDeepSeek V4 Pro 的输出会让你更容易看懂。它的缺点是功能完整度略逊于 Step 5 Preview有些细节需要自己补。GLM5.3 最适合轻量级任务和对代码体量敏感的场景。它的输出最紧凑代码量最少如果你只是想要一个能跑的最小实现GLM5.3 能最快给你结果。但它的代码质量参差不齐需要你有一定的排查和修复能力。不建议新手直接用 GLM5.3 的输出做正式项目。6.2 我在实操中总结的五条经验第一条不要直接复制粘贴就完事。模型输出的代码一定要自己过一遍哪怕只是快速扫一眼。我遇到过好几次模型输出的代码里有明显的逻辑错误但因为代码太长没仔细看结果调试了半天才发现问题所在。第二条给模型设定明确的输出规则。如果你在 WorkBuddy 或者其他工具里用这些模型建议在系统指令里加上几条规则比如按模块分段输出、每段代码不超过 150 行、关键参数要注释说明。这些规则设一次后续所有任务都生效能大幅提升输出质量。第三条善用跨对话记忆功能。做复杂项目时上下文很容易超出模型的窗口限制。WorkBuddy 的跨对话记忆功能可以帮你把关键信息比如项目结构、核心参数、已解决的问题持久化下来新开对话时不用重新交代背景。第四条性能问题要早发现早解决。不要等到项目做完了才去优化性能。在开发过程中就养成习惯每加一个功能就用 Performance 面板看一眼帧率。如果发现帧率下降立刻排查原因不要拖。第五条保留每个模型的原始输出。我在实测过程中把三个模型的原始输出都保存了下来。后来在融合代码时经常需要回去查某个模型是怎么实现某个功能的。如果你不保存等对话记录被清理了就找不回来了。6.3 关于 WorkBuddy 在本次实测中的实际作用最后简单说一下 WorkBuddy 在这次实测中扮演的角色。我主要用它做了三件事一是管理三个模型的对话窗口。WorkBuddy 的工作台模式可以同时开多个对话每个对话独立运行互不干扰。这对于对比测试来说非常方便不用在多个浏览器标签页之间来回切换。二是用它的自定义指令功能给每个模型设定了不同的输出规则。比如给 Step 5 Preview 设的是注重代码结构和注释给 DeepSeek V4 Pro 设的是注重原理解释给 GLM5.3 设的是注重代码紧凑。这样每个模型的输出风格更加鲜明对比起来也更直观。三是用它的文件管理功能把三个模型的输出分别保存到不同的文件里。WorkBuddy 的工作台可以直接创建和编辑文件不用离开工具就能完成代码整理。这个功能在对比测试时特别实用因为你需要频繁地在不同版本的代码之间切换。不过 WorkBuddy 本身也有一些限制比如系统缓存目录默认在 C 盘如果对话记录和临时文件多了会占用不少空间。如果你打算长期使用建议把缓存目录改到 D 盘或者其他空间充足的盘符。具体操作方法在 WorkBuddy 的设置里有说明这里就不展开了。6.4 后续可以继续深入的方向这次实测只是一个起点还有很多可以继续深入的方向。比如把游戏复杂度再提高一个档次加入物理引擎如 Cannon.js 或 Rapier看三个模型在物理模拟方面的表现差异。测试多人在线功能看模型对 WebSocket 和状态同步的理解程度。加入移动端适配看模型对触摸事件和响应式布局的处理能力。测试模型对已有代码的重构能力给一段质量较差的代码看它能不能优化到可维护的水平。这些方向我后续会陆续尝试有了新的发现再跟大家分享。如果你也在做类似的测试欢迎交流你的观察和结论。毕竟 AI 辅助开发这个领域变化太快了一个人测不过来大家一起测才能更快摸清每个模型的真实能力边界。
 OVER实战：累计计算与分组分析)
