1. 三款模型同台竞技的背景与选型逻辑

1.1 为什么选3D游戏作为横向对比的试金石

3D游戏开发一直被视为检验代码生成模型综合能力的"硬骨头"。它不像写一个排序算法或者CRUD接口那样有标准答案，而是同时牵扯到数学计算、图形学管线、状态管理、资源调度、碰撞检测、输入响应等多个子系统。一个模型能不能把3D游戏写明白，基本能反映出它在长上下文理解、空间想象力、API调用准确性和工程结构组织上的真实水平。

我这次拿到的测试场景很具体：用Step 5 Preview、DeepSeek V4 Pro和GLM5.3三个模型，分别从零生成一个可运行的3D游戏原型。选择这个组合的原因也很直接——Step 5 Preview是近期讨论度很高的新选手，DeepSeek V4 Pro在代码任务上一直口碑稳定，GLM5.3则在中文开发者社区里被反复提及。三者放在同一个任务下对比，能比较直观地看出各自的风格差异和能力边界。

需要提前说明的是，我并不是要搞一个"跑分式"的评测。那种用固定prompt跑一遍然后打分的做法，对3D游戏这种复杂任务来说参考价值有限。我更关注的是：模型在生成过程中暴露出的思维路径、代码结构选择、以及对"可运行"这个底线的把控能力。这些细节才是实际开发中真正影响效率的东西。

1.2 测试环境与统一约束条件

为了保证对比的公平性，我给三个模型设置了完全一致的约束条件。运行环境是一台搭载RTX 4060的Windows 11机器，浏览器统一用Chrome 120。技术栈限定为Three.js + 原生JavaScript，不引入React或Vue这类框架，避免框架层面的差异干扰对模型本身能力的判断。

游戏需求也做了明确限定：一个第三人称视角的3D场景，玩家可以控制一个方块角色在平面上移动，场景中随机分布若干可收集的金色小球，收集到一定数量后触发胜利提示。这个需求看起来简单，但实际上涵盖了场景初始化、相机跟随、键盘输入处理、碰撞检测、计分逻辑、UI反馈等完整链路。

提示：如果你也想做类似的横向对比，建议把需求写成一份不超过300字的功能清单，而不是一段模糊的自然语言描述。约束越明确，模型输出的可对比性越强。

三个模型都使用相同的系统提示词，要求它们输出完整的HTML文件，包含所有依赖的CDN引用，确保双击即可在浏览器中运行。这个"单文件可运行"的要求很关键，它能直接筛掉那些只会写片段、不考虑工程完整性的输出。

1.3 三款模型的第一印象差异

在正式跑代码之前，我先让三个模型各自用一段话描述它们打算怎么实现这个游戏。这个环节的差异就已经很有意思了。

Step 5 Preview给出的方案最"教科书"：它明确列出了场景搭建、角色控制、碰撞检测、UI层四个模块，并且主动提到了用requestAnimationFrame做游戏循环、用Vector3做位置计算。这种结构化的表达说明它对3D游戏的基本骨架有清晰认知。

DeepSeek V4 Pro的方案更偏"工程化"：它额外提到了要考虑deltaTime来处理帧率无关的移动，还建议用一个简单的状态机来管理游戏状态（进行中、胜利、重置）。这些细节不是需求里明确要求的，但确实是实际开发中会踩到的坑。

GLM5.3的方案则最"简洁"：它直接说会用Three.js搭建场景，然后给出核心代码结构。没有太多额外的工程考量，但表达很直接。这种风格在快速原型阶段其实也有优势，就是不会过度设计。

2. 核心实现细节的逐层拆解

2.1 场景初始化与相机系统的生成质量

场景初始化是3D游戏的第一块基石。三个模型在这部分的输出质量差异，直接决定了后续代码能不能顺利跑起来。

Step 5 Preview生成的初始化代码非常规范。它先创建Scene，然后设置PerspectiveCamera，相机位置放在(0, 8, 12)，看向原点。这个位置选择很合理——既能看到角色全貌，又不会太远导致角色太小。光照方面它用了AmbientLight加DirectionalLight的组合，环境光强度0.6，平行光强度0.8，这个配比在实际渲染中出来的效果比较柔和，不会出现死黑或者过曝。

DeepSeek V4 Pro在相机这块做了一个额外处理：它把相机初始位置放在(0, 10, 15)，但在注释里说明了这个值可以根据屏幕宽高比动态调整。虽然它没有真的写出自适应逻辑，但这个意识是好的。光照部分它用了HemisphereLight替代AmbientLight，这个选择其实更聪明——半球光能模拟天空和地面的反射差异，场景层次感会更好。

GLM5.3的初始化代码最简短，相机放在(0, 5, 10)，光照只用了AmbientLight加一个PointLight。这个配置能跑，但渲染出来的画面偏平，阴影效果基本没有。对于原型验证来说够用，但如果要往产品方向走，这块需要补不少东西。

2.2 角色控制与输入响应的实现路径

角色控制是玩家感知最直接的部分，也是最能体现模型对"手感"理解的地方。

Step 5 Preview用了最经典的keydown/keyup事件监听方案，维护一个keys对象记录当前按下的键。在游戏循环里根据keys状态计算移动向量，然后更新角色位置。这个方案的好处是移动平滑，不会因为按键重复触发而抖动。它还给角色加了一个简单的旋转逻辑——根据移动方向调整角色朝向，虽然只是绕Y轴旋转，但视觉上已经像那么回事了。

DeepSeek V4 Pro在输入处理上多了一层：它把移动速度定义为一个常量speed = 0.1，然后在每帧更新时乘以deltaTime。这个处理很关键，因为如果不乘deltaTime，在高刷新率屏幕上角色会移动得飞快，在低刷新率设备上又会很慢。这个细节说明DeepSeek V4 Pro确实考虑到了实际运行环境差异。

GLM5.3的输入处理最直接：直接在keydown事件里修改角色位置。这种写法能跑，但有两个问题——一是按键重复触发会导致移动速度不稳定，二是没有keyup处理的话角色会一直移动。实际上GLM5.3确实写了keyup，但整体结构不如前两者清晰。

// Step 5 Preview 的输入处理结构（简化示意） const keys = {}; document.addEventListener('keydown', (e) => { keys[e.code] = true; }); document.addEventListener('keyup', (e) => { keys[e.code] = false; }); function updatePlayer(delta) { const move = new THREE.Vector3(); if (keys['KeyW']) move.z -= 1; if (keys['KeyS']) move.z += 1; if (keys['KeyA']) move.x -= 1; if (keys['KeyD']) move.x += 1; if (move.length() > 0) { move.normalize().multiplyScalar(speed * delta); player.position.add(move); } }

这段代码是Step 5 Preview输出的核心逻辑，结构清晰，normalize()保证了斜向移动不会比直线移动快，multiplyScalar(speed * delta)保证了帧率无关。这两个细节是很多新手容易忽略的。

2.3 碰撞检测与收集逻辑的严谨程度

碰撞检测在3D游戏里通常有两种做法：一种是物理引擎，一种是简单的距离判断。对于这个收集小球的场景，距离判断完全够用，而且性能更好。

Step 5 Preview用的是Vector3.distanceTo()方法，判断玩家和小球的距离是否小于一个阈值（它设的是1.2）。这个阈值选择有讲究——太小了玩家要精确对准才能收集，体验不好；太大了又会出现"隔空收集"的违和感。1.2这个值大概是玩家角色尺寸的1.5倍，实际测试下来手感比较自然。

DeepSeek V4 Pro用了distanceToSquared()来避免开方运算，这是一个性能优化细节。虽然在这个规模下差异可以忽略，但说明它对性能敏感场景有意识。它的收集阈值设的是1.0，比Step 5 Preview稍小，实际体验下来需要更靠近才能收集。

GLM5.3同样用了distanceTo()，阈值设的是1.5。这个值偏大，测试时出现过玩家还没碰到小球就被收集的情况。不过它加了一个简单的收集动画——小球缩小后消失，这个细节倒是加分项。

注意：碰撞阈值没有绝对标准，它取决于你的角色模型尺寸和场景比例。建议先确定角色碰撞体的半径，然后取1.2到1.5倍作为收集阈值，实际跑一遍再微调。

2.4 计分系统与胜利条件的完整度

计分和胜利条件看似简单，但它是游戏闭环的关键。没有这个闭环，前面做得再好也只是个技术演示。

Step 5 Preview的计分逻辑很完整：每收集一个小球，分数加一，同时更新页面上的计分显示。当分数达到预设值（它设的是5），显示胜利提示并停止游戏循环。这个"停止游戏循环"的处理很关键，否则胜利后玩家还能继续移动，体验上会很奇怪。

DeepSeek V4 Pro在计分基础上加了一个重置功能——按R键可以重新开始。这个功能需求里没要求，但确实实用。它的胜利提示用了overlay层，视觉上比Step 5 Preview的直接文字提示更精致一些。

GLM5.3的计分逻辑能跑，但胜利后没有停止游戏循环，玩家还能继续收集已经不存在的小球。这是一个明显的逻辑漏洞，说明它在状态管理上考虑得不够周全。

3. 实操过程与关键环节复现

3.1 从零到可运行：Step 5 Preview的完整流程

我把Step 5 Preview生成的代码完整跑了一遍，记录下关键环节。整个过程可以分成四步：环境准备、代码落地、首次运行、问题修复。

环境准备很简单，只需要一个现代浏览器。Step 5 Preview生成的HTML文件通过CDN引入了Three.js的r160版本，这个版本比较稳定，API和文档匹配度高。如果你本地网络访问CDN有困难，可以把Three.js下载到本地，然后修改script标签的src路径。

代码落地时我注意到一个细节：Step 5 Preview把所有逻辑都放在了一个<script>标签里，没有拆分成多个模块。对于这个规模的项目来说，单文件反而更方便调试。它用了一个init()函数做初始化，一个animate()函数做游戏循环，结构很清晰。

首次运行直接成功，场景正常渲染，角色可以移动，小球可以被收集，计分正常更新。唯一的小问题是阴影有点重，角色下方有一块比较明显的暗区。这个问题通过调整DirectionalLight的shadow.mapSize和shadow.camera参数可以解决。

问题修复环节我只改了一处：把renderer.shadowMap.type从默认值改成THREE.PCFSoftShadowMap，阴影边缘立刻柔和了很多。这个改动很小，但视觉效果提升明显。

3.2 DeepSeek V4 Pro的工程化细节实测

DeepSeek V4 Pro的代码跑起来同样顺利，但它的工程化细节确实更多。我重点测了它提到的deltaTime处理。

为了验证这个处理是否真的有效，我用Chrome的开发者工具把CPU性能降到4倍慢速，模拟低帧率环境。Step 5 Preview的代码在这个环境下角色移动明显变慢，而DeepSeek V4 Pro的代码角色移动速度基本不变。这个对比很直观地说明了deltaTime的价值。

它的状态机设计也值得一提。它定义了一个gameState变量，取值是'playing'、'won'、'reset'。在游戏循环里根据状态决定是否处理输入和碰撞检测。这个设计让胜利后的行为控制变得很干净，不会出现Step 5 Preview那种"胜利后还能动"的问题。

不过DeepSeek V4 Pro的代码有一个小问题：它用的Three.js版本是r150，这个版本里outputEncoding属性还是旧写法，在新版本里已经改成了outputColorSpace。如果你直接用它的代码，控制台会有一个警告。不影响运行，但看着不舒服。

3.3 GLM5.3的快速原型能力与短板

GLM5.3的代码跑起来最快，因为它生成的代码量最少。场景能渲染，角色能移动，小球能收集，基本功能都在。但跑起来之后问题也比较明显。

第一个问题是光照太暗。它只用了AmbientLight加一个PointLight，点光源放在(0, 10, 0)，导致场景边缘区域几乎全黑。我手动加了一个DirectionalLight之后才正常。

第二个问题是角色移动没有做帧率无关处理。在高刷新率屏幕上角色移动飞快，在低刷新率屏幕上又慢得像蜗牛。这个问题在原型阶段可能不明显，但一旦要适配不同设备就会暴露。

第三个问题是胜利后游戏循环没有停止。玩家胜利后还能继续移动，虽然已经没有小球可以收集了，但体验上很割裂。

不过GLM5.3有一个优点：它的代码注释最详细。每一段逻辑都有中文注释说明意图，对于新手理解代码帮助很大。Step 5 Preview和DeepSeek V4 Pro的注释相对少一些。

3.4 三份代码的合并与优化实践

跑完三份代码之后，我做了一件有意思的事：把三者的优点合并成一个"最优版本"。

具体做法是：以Step 5 Preview的代码为骨架，因为它的结构最清晰；把DeepSeek V4 Pro的deltaTime处理和状态机移植过来；把GLM5.3的详细注释风格保留下来；光照部分用DeepSeek V4 Pro的半球光方案；阴影用我手动调整过的PCFSoftShadowMap。

合并后的代码跑起来确实比任何单一版本都舒服。移动手感顺滑，光照层次分明，胜利逻辑干净，代码可读性也好。这个过程让我意识到，模型生成的代码不一定要"选一个最好的"，完全可以根据各自优势做组合。

实操心得：不要指望一个模型一次性生成完美代码。更高效的做法是让多个模型各跑一遍，然后你来当"架构师"，把各自的亮点拼起来。这个过程本身也是学习的过程。

4. 常见问题与排查技巧实录

4.1 模型生成代码跑不起来的典型原因

在实际测试中，我遇到过几类高频问题，这里整理成速查表。

这些问题的共同点是：它们都不是语法错误，代码能跑，但跑出来的结果不对。这类问题最难排查，因为控制台不会报错。我的经验是，遇到这类问题先看渲染结果，再看逻辑，最后看参数。大部分时候问题出在参数上。

4.2 三个模型各自的"脾气"与应对策略

用多了之后，我发现每个模型都有自己的"脾气"，了解这些脾气能帮你更高效地使用它们。

Step 5 Preview的脾气是"稳"。它生成的代码结构规范，很少出现低级错误，但也不会给你太多惊喜。适合需要快速拿到一个可靠基线的场景。应对策略是：把它当骨架生成器，拿到基础代码后再自己加细节。

DeepSeek V4 Pro的脾气是"细"。它会主动考虑很多工程细节，比如deltaTime、状态机、性能优化。但有时候会过度设计，生成一些当前需求用不上的代码。应对策略是：先跑一遍看它的额外处理有没有价值，有价值的保留，没价值的删掉。

GLM5.3的脾气是"快"。它生成的代码最简洁，注释最详细，适合快速理解思路。但工程完整度相对弱一些。应对策略是：用它来快速验证想法，确认可行后再用Step 5 Preview或DeepSeek V4 Pro生成正式版本。

4.3 提升生成质量的提示词技巧

经过这次测试，我总结了几条提升3D游戏代码生成质量的提示词技巧。

第一条是明确技术栈版本。不要只说"用Three.js"，要说"用Three.js r160，通过CDN引入"。版本明确后，模型生成的API调用准确率会明显提升。

第二条是限定输出格式。明确要求"输出单个HTML文件，包含所有依赖，双击可运行"。这个约束能逼着模型考虑工程完整性，而不是只写片段。

第三条是给出验收标准。比如"角色移动必须帧率无关"、"胜利后必须停止游戏循环"。这些标准会直接引导模型在对应位置做正确处理。

第四条是要求注释。明确说"关键逻辑要有中文注释"，这样生成的代码可读性会好很多，也方便你后续修改。

提示：如果你要生成更复杂的3D场景，建议把需求拆成多个步骤，每一步只让模型处理一个子系统。一次性生成太复杂的场景，模型很容易在某个环节出错，而且排查起来很麻烦。

4.4 从原型到可用产品的差距分析

三个模型生成的代码都能跑，但距离"可用产品"还有明显差距。这个差距主要体现在四个方面。

第一是资源管理。原型里所有几何体都是代码生成的，没有加载外部模型和纹理。真实项目里你需要处理GLTF加载、纹理压缩、资源预加载等。

第二是性能优化。原型里小球数量少，没有做实例化渲染。真实项目里如果有几百个物体，需要用InstancedMesh来减少draw call。

第三是交互完善。原型只有键盘输入，真实项目可能需要支持触屏、手柄、鼠标等多种输入方式。

第四是状态持久化。原型没有存档功能，刷新页面就重置。真实项目需要把游戏状态存到本地或服务端。

这些差距不是模型能力问题，而是需求复杂度问题。模型能帮你快速搭出原型，但从原型到产品的那段路，还是得自己走。

5. 关于WorkBuddy在开发流程中的实际定位

5.1 WorkBuddy与代码生成模型的关系

聊完三个模型，再说说WorkBuddy。最近社区里关于WorkBuddy的讨论很多，从安装教程到自定义指令，从skill配置到私有化部署，热度一直不低。但很多人容易把WorkBuddy和代码生成模型混为一谈，其实它们的定位完全不同。

代码生成模型解决的是"写代码"的问题，你给它需求，它给你代码。WorkBuddy解决的是"组织工作流"的问题，它更像一个工作台，帮你把多个工具、多个步骤串联起来。比如你可以用WorkBuddy配置一个流程：先调用模型生成代码，然后自动跑测试，最后把结果整理成报告。这个流程里模型只是其中一个环节。

我实际用下来的感受是，WorkBuddy的价值在于"减少重复操作"。如果你每天都要做类似的事情，比如生成代码、跑测试、整理文档，那WorkBuddy能帮你省不少时间。但如果你只是偶尔写写代码，那直接用模型对话可能更直接。

5.2 给WorkBuddy定规则的实操建议

社区里有个高频问题："给WorkBuddy定几条规则，后续对所有任务都生效"。这个需求很实际，我分享一下我的做法。

我的规则分三类。第一类是输出格式规则，比如"所有代码必须包含中文注释"、"所有报告必须用Markdown格式"。第二类是质量规则，比如"生成的代码必须能直接运行"、"必须包含错误处理"。第三类是安全规则，比如"不生成任何涉及敏感信息的代码"。

这些规则通过WorkBuddy的自定义指令功能配置，配置一次之后对所有任务生效。实测下来，规则越具体，效果越好。比如"代码要有注释"就不如"每个函数上方必须有说明用途和参数的中文注释"来得有效。

注意：规则不要定太多，五到八条就够了。规则太多会互相冲突，而且模型可能顾此失彼。优先定那些你最常遇到的问题对应的规则。

5.3 缓存目录与私有化部署的常见疑问

WorkBuddy的系统缓存目录默认在C盘，很多用户想改到D盘。这个操作本身不复杂，在设置里找到缓存路径选项，改成目标路径后重启即可。但要注意，改路径之前最好把现有缓存迁移过去，否则之前的会话记录可能会丢失。

私有化部署是另一个高频问题。WorkBuddy支持私有化部署，适合对数据安全有要求的企业用户。部署方式通常是Docker，官方有提供镜像。部署前需要确认服务器配置，主要是内存和存储空间。实测下来，基础配置4核8G能跑起来，但如果要处理大量任务，建议8核16G起步。

Linux环境下部署和Windows类似，主要差异在路径配置和权限管理。Windows下用反斜杠，Linux下用正斜杠，这个细节容易忽略。权限方面，确保WorkBuddy的运行用户对缓存目录有读写权限，否则会出现莫名其妙的错误。

5.4 从入门到精通的路径建议

社区里流传着各种"WorkBuddy从入门到精通"的教程，质量参差不齐。我结合自己的使用经验，给一条比较务实的路径。

第一阶段是熟悉基础操作。知道怎么安装、怎么配置、怎么发起任务、怎么看结果。这个阶段不需要看太多教程，直接上手用就行，遇到问题再查。

第二阶段是配置自定义指令。把你最常遇到的重复性需求写成规则，让WorkBuddy自动处理。这个阶段是效率提升最明显的阶段。

第三阶段是配置skill。WorkBuddy的skill机制允许你扩展它的能力，比如接入外部API、处理特定格式的文件。这个阶段需要一些开发基础，但一旦配好，能做的事情会多很多。

第四阶段是私有化部署和团队协作。如果你在团队里推广WorkBuddy，需要考虑部署方式、权限管理、规则统一等问题。这个阶段更多是管理问题而非技术问题。

我个人在实际操作中的体会是，WorkBuddy这类工具的价值不在于它本身有多强，而在于它能不能融入你现有的工作流。如果它需要你改变太多习惯，那学习成本就会抵消掉效率收益。所以我的建议是，先从一个小场景开始用，用顺了再逐步扩展。不要一上来就想着"精通"，先把一个点用透，比什么都强。

最后再分享一个小技巧：WorkBuddy的跨对话记忆功能很实用，但默认可能没开。在设置里找到记忆相关选项，开启后它能在不同对话之间保持上下文。这个功能对于需要连续处理多个相关任务的场景帮助很大，比如你先让它分析需求，再让它生成代码，最后让它写文档，开启记忆后它不需要你每次都重复背景信息。