企业官网建设流程全解析

最近我干了一件挺能折腾的事：让 Step 5 Preview、DeepSeek V4 Pro、GLM5.3 三个模型，用同一个需求说明，各写一个 3D 游戏。对，你没看错，是 3D 游戏，不是待办事项 App，也不是静态网页。选这个题目是因为 3D 游戏开发能同时考验模型的代码能力、数学功底、逻辑组织能力和审美判断——这四样正好是现在大模型最容易露怯的地方。这篇文章就是这次实测的完整复盘，从 Prompt 设计、生成过程、代码审阅到最终能玩的版本，全给你摊开讲。如果你正准备用 AI 辅助做游戏，或者纠结哪个模型更适合写复杂前端/3D 项目，这篇应该能帮你省不少时间。

1. 为什么要让模型们同做一个 3D 游戏

1.1 3D 游戏是检验模型综合能力的试金石

很多人喜欢拿模型写“贪吃蛇”“待办事项”“简历页面”来测试，我不反对，但这类任务对模型来说已经快变成肌肉记忆了。你给它一个常见需求，它可以从训练数据里翻出一个八九不离十的模板，跑起来并不意外。但 3D 游戏不一样，尤其是用 Three.js 写一个带碰撞检测、计分、场景切换的小游戏，对模型的综合能力要求高得多。

首先是数学能力。Three.js 里的坐标系统、摄像机朝向、物体位移和碰撞盒计算，每一步都在和三维向量打交道。模型一旦把 x、y、z 的顺序搞混，或者忘了把碰撞盒位置随物体移动更新，游戏就会变成“看着正常但一玩就穿模”。其次是逻辑组织能力。一个游戏至少要拆成初始化场景、创建角色、生成障碍物、更新状态、渲染循环、监听键盘事件这几大块。模型需要把这些模块按正确的顺序串起来，而不是把所有代码堆在一个函数里。最后是审美判断。同样是一个跑酷游戏，有的版本会做渐变天空、地面网格、阴影，有的版本就是一片灰地板加几个方块，区别非常大。

我当时跟朋友开玩笑：写普通网页好比做一荤一素，写 3D 游戏好比做一桌宴席。食材都有，但火候、顺序、摆盘，处处都能看出厨师的水平。模型也一样，越是复杂任务，越能看出它的“内功”。

1.2 测试目标与预期

这次测试的目标很明确：不是比谁生成的代码行数多，也不是比谁的注释文笔好，而是比谁能在最短时间内，给出一份“打开就能玩”的成果。然后我再人为制造一些运行错误，看它能不能自己修复。毕竟真实开发中，AI 写出来的代码很少能一次跑通，后续的调试和修复能力同样重要。

在测试前我心里有一个预期：三个模型应该都能写出基本框架，但在细节处一定会出问题。区别只在于问题的数量和类型。Step 5 Preview 是刚放出来的预览版，我对它的稳定性没抱太大期望；DeepSeek V4 Pro 是老牌产品了，生成速度应该最快；GLM5.3 则擅长理解长文本，我猜它在拆解需求时会有惊喜。结果没想到，三家的翻车方式各不相同，修起来也各有各的乐趣。

2. 评测环境与统一游戏需求

2.1 硬件与运行环境

为了公平，我把它们放在完全相同的环境里测试。

• 操作系统：Windows 11，浏览器用 Chrome 最新稳定版。
• 模型接入方式：通过各自官方 API 调用，统一关闭流式输出，方便对比完整代码。
• 无额外 Agent 工具：不接代码解释器，也不让模型自动运行代码，只做“一次生成 + 人工反馈修复”的循环。
• 静态服务器：用 Python 的http.server起本地服务，避免file://协议下模块加载问题。

这台电脑的显卡是 RTX 4070 Ti，不算顶级，但跑这种轻量级 Three.js 场景绰绰有余。顺带提一句，如果后面要本地部署 GLM5.3，显卡显存就非常重要，这个我放到第 5 部分再说。

2.2 统一的游戏需求说明

我给三个模型发了完全相同的 Prompt，原话如下：

请用 HTML + Three.js 制作一个 3D 跑酷游戏。要求如下：所有代码放在一个 HTML 文件中，通过 CDN 引入 Three.js。场景包含三条跑道，玩家控制一个小球，障碍物是随机生成的方块，从远处向玩家移动。玩家按方向键左右切换跑道，按空格键跳跃。需要实现碰撞检测，碰到障碍物游戏结束。屏幕左上角显示得分，游戏结束后显示重新开始按钮。不需要外部贴图，用基础材质和网格辅助线即可。请输出完整可运行的代码。

我特意把“完整可运行”这四个字写进去，后面你会看到，即便如此，模型们还是会给你留点惊喜。

这个需求有几个刻意的设计：三条跑道看似简单，实则考验模型对 x 坐标和 z 坐标的理解；跳跃需要处理重力加速度，这是很多模型容易写错的地方；碰撞检测需要每帧更新包围盒，如果模型只检测一次，就会出现“隔空撞车”或“怎么也撞不到”的 bug。而这些恰好是新手最容易踩的坑。

2.3 评测维度与评分规则

我没有跑那种复杂的基准测试，而是用了五个维度做主观打分，每项 10 分：

• 一次可用率：生成的代码首次运行能不能直接玩。
• 代码完整度：有没有缺函数、缺变量、缺 CDN 引用。
• 逻辑正确性：跑起来后玩法是否符合需求描述。
• 可修复性：报错信息是否容易定位，修复成本高不高。
• 注释可读性：代码命名和注释能不能让人快速看懂。

这个评分标准比较主观，但恰恰贴近真实开发者的体验。你不需要 100% 精确的指标，只需要知道哪个模型能让你少加班。

3. 三个模型的生成过程全记录

3.1 Step 5 Preview：架构最稳，但卡在交互细节

先说 Step 5 Preview。它是三个模型里响应速度最接近“中位值”的，第一次生成用了大约 40 秒，输出约 300 行代码。我第一眼看完它的代码结构就觉得舒服：定义了一个Game类，里面拆了init、createScene、createPlayer、createObstacle、update、render六个方法，变量命名也很规范，比如playerMesh、lanePositions、gameOver。它甚至自己加了startGame和pauseGame的状态机逻辑，这是一个让我有点意外的加分项。

但第一次运行就发现一个很蠢的 bug：场景、跑道、小球都出来了，障碍物也出来了，但它们全都停在原地不动。我打开控制台看，没有任何报错。又仔细翻了一遍代码，才发现问题出在动画循环里——它在animate函数中只调用了renderer.render(scene, camera)，压根没有调用update()。update方法里写了障碍物移动、碰撞检测、得分增加，但整个游戏循环根本不会执行它。这种 bug 不报错、不崩溃、不红屏，唯一的表象就是“世界静止了”。

修复方法只需在animate中加一行this.update()。我把这行代码补上后，游戏立刻活了起来，障碍物开始从远方滑向玩家，碰撞检测也正常工作。当时我甚至怀疑它是故意留一手来测试我的耐心。

3.2 DeepSeek V4 Pro：生成速度快，代码却藏了三个 bug

DeepSeek V4 Pro 是我这次最期待的一个，毕竟它一直以速度快著称。实际也的确如此，大约 25 秒就输出了 400 多行代码，比 Step 5 Preview 多了三分之一。然而代码一打开，问题接踵而至。

第一个 bug 在跑道坐标上。它将三条跑道的 x 坐标设成了[-2, 0, 2]，这本身没问题，但生成障碍物的逻辑里，又把障碍物的 x 坐标按照一个随机数组去映射，结果角色明明切到右边跑道，遇到的障碍物却对应到中间跑道的位置，玩起来就是“明明躲开了，还是被撞”。我检查代码后发现，它把“跑道索引”和“世界坐标”混为一谈，本质上是坐标系抽象没做好。

第二个 bug 在碰撞检测。它确实写了Box3碰撞检测，但在动画循环里只计算了一次包围盒，之后没有随着小球和方块的位置变化去更新。这导致碰撞检测只在第一帧生效，之后小球可以堂而皇之穿过障碍物。从玩家视角看就是：底下的碰撞盒子还在原点，而小球已经跑出去十万八千里了。

第三个 bug 比较隐蔽：键盘事件里同时用了keydown和keyup触发跳跃。空格键按下时跳一次，松开时又跳一次，结果玩家按一下空格，小球原地弹跳两下，手感非常奇怪。修复这三个 bug 花了我大概二十分钟，比前一个版本多耗了不少时间。不过话说回来，DeepSeek V4 Pro 的生成速度确实快，如果是简单需求，这个优势会非常明显。

3.3 GLM5.3：理解力强，差一步就能跑通

GLM5.3 是我最近用得比较多的模型，它给我的印象是“听得懂人话”。这次它输出大约 350 行代码，开篇甚至先用注释把需求拆成了五个模块：相机、跑道、玩家、障碍物、UI 交互。我一度以为它会是三个模型里最稳的，结果跑起来之后发现障碍物依旧没有出现。

原因很有意思。它在createObstacle前面加了一个倒计时变量spawnTimer，打算每隔 3 秒生成一个障碍物。但它只写了if (spawnTimer <= 0) { this.createObstacle(); this.spawnTimer = 3; }，而spawnTimer的初始值是 0，按道理第一次循环就该触发生成。我继续往下看才发现，它忘记在update()里做this.spawnTimer -= deltaTime的递减，倒计时永远停在 0 和 3 之间来回边沿，可因为没有任何递减，条件永远成立倒是会疯狂生成障碍物才对……等等，我读到这里自己也乱了。

进一步跟踪代码后我才理清楚：它确实做了倒计时递减，但是递减的代码写在render()方法里，而render()只在渲染一帧时执行一次，并且它用的是固定帧率参数，导致倒计时减少的幅度非常小，玩家玩到第 20 秒才看到第一个障碍物。我改成了基于deltaTime的更新，障碍物生成速度立刻恢复正常。GLM5.3 唯一的另一个问题是缺少重新开始按钮，游戏结束后卡在静止画面，按空格也没反应。这也是典型的“模块没接全”问题。

3.4 横向对比：代码量、运行成功率、可维护性汇总

三个模型都跑起来之后，我做了一张简单的对比表：

这里说的“首次可运行率”，是指打开页面后能否看到正常场景和角色。Step 5 Preview 虽然漏了update()调用，但至少场景和角色都出来了，直观损失最小。DeepSeek V4 Pro 代码量大，问题也最分散，属于“看似完整实则处处漏风”。GLM5.3 的模块拆分很舒服，修复起来最容易。

但要注意，这个推荐分只针对“生成 3D 游戏”这个任务。如果换成写业务后端、写文案、做数据分析，排名可能完全不一样。

4. 实际运行与修复过程：一个游戏从报错到能玩的真实路径

4.1 把三个版本跑起来的步骤

很多朋友看到“3D 游戏”四个字就以为需要很复杂的工程环境，其实完全不是。我已经把它们全部做成了单文件 HTML，所以运行只需要三步：

1. 将模型生成的代码保存为index.html。
2. 在项目目录下执行python -m http.server 8080。
3. 浏览器访问http://localhost:8080。

为什么不直接双击打开 HTML？因为新版浏览器出于安全策略，对本地file://请求会限制部分模块加载。Three.js 老版本直接 script 引入还能凑合，但有些模型会输出import语法，必须走 HTTP 服务。另外，如果你在使用 VS Code，装一个 Live Server 插件也可以，效果一样。

这一步里最容易踩的坑是 CDN 地址。三个模型写的 Three.js CDN 链接各不相同，有的用https://cdnjs.cloudflare.com/ajax/libs/three.js/r128/three.min.js，有的用https://unpkg.com/three@0.128.0/build/three.min.js，理论上都能用，但如果你所在的网络环境访问某些 CDN 特别慢，页面就会一直白屏，控制台提示THREE is not defined。我的做法是统一替换成https://cdn.jsdelivr.net/npm/three@0.128.0/build/three.min.js，这个在国内外访问都比较稳定。这种情况不属于模型代码问题，属于基础设施选型。

4.2 逐个修复典型编译与运行错误

在调试过程中，我遇到了三类典型错误，整理成表给你参考：

这三个模型都没有出现语法级错误，生成的 JavaScript 都能被浏览器解析，问题全部出在运行时逻辑和状态管理上。这说明模型在“局部代码”层面已经很熟练了，但在“程序随时间运行”的维度上还容易犯迷糊。

4.3 游戏效果对比：渲染、交互、帧率

修复完所有 bug 之后，我把三个版本放在一起玩了几轮。Step 5 Preview 的版本做了淡蓝色渐变天空和柔和阴影，视觉上最舒服；障碍物是随机颜色方块，落在地面网格上很有“原型游戏”的质感。它的缺陷是角色移动采用瞬间改坐标的方式，没有补间动画，手感偏硬。

DeepSeek V4 Pro 的版本色调偏灰，没有阴影，地面网格密度很高，看起来更像一排实验室地板。它最大的优势是帧率非常稳定，就算障碍物堆叠很多也没有明显掉帧。这可能和它没有做太多材质计算有关，视觉上简单，性能反而好。

GLM5.3 的版本则把重心放在了跳跃手感上。它把重力加速度设成 0.005，跳跃高度大约是障碍物高度的两倍，起跳和落地的时刻刚好匹配障碍物到达，玩起来容错率很高。它的缺点是没有游戏结束后的弹窗提示，只会把画面定格在碰撞瞬间，第一次玩的人很容易以为是电脑卡住了。

我在浏览器性能面板里瞟了一眼，三个版本在普通场景下都是 60fps 满帧运行，只有 DeepSeek V4 Pro 在障碍物数量超过 20 个时掉到 45fps 左右，原因是它每一帧都在创建新的网格对象，没有做对象池复用。这个问题在小型游戏里不致命，但如果你想扩展成更复杂的作品，还是要手动优化。

5. 模型输出背后的规律与避坑技巧

5.1 模型们爱犯的共性问题

三个模型翻车的点看起来五花八门，但归纳下来其实高度一致。

第一是生命周期意识缺失。很多模型能够写出“创建对象”和“更新对象”的代码，但容易忽略“在循环中调用更新”这个动作。它们把函数定义和生产出来，却忘了函数需要被主循环不断驱动。放在游戏里就是静态画面，放在服务器代码里就是只执行一次的任务。

第二是坐标轴理解偏差。尤其是 x 和 z 轴的使用。Three.js 里水平方向通常用 x，纵深方向用 z。模型写障碍物移动时，有时会对 z 进行递减，但生成障碍物的位置却全部放在 x 轴上，导致物体从侧面飞过来。这个错误很隐蔽，但只要玩第一关就会暴露。

第三是事件处理边界不清晰。比如跳跃不能只依赖按键事件触发，还要判断角色是否在地面上，否则空降时也能二段跳。模型往往能写出setInterval或requestAnimationFrame，但对用户操作频率的约束和抖动处理几乎没有概念。

第四是忽略对象清理。DeepSeek V4 Pro 的版本里，障碍物移出屏幕后并没有从场景中移除，导致物体越攒越多，内存和渲染压力持续上升。这在短时间测试中看不出来，但玩超过五分钟，帧率就会肉眼可见地下滑。

出现这些问题的原因很本质：LLM 是在生成“看起来合理的文本”，而不是在模拟程序的真实运行。它不知道用户在某一帧按了空格，也不知道前面 100 个障碍物占了哪些坐标。它只能依靠训练数据里的模式去猜测，所以你在 prompt 里把事情说得越精确，它的表现就会越好。

5.2 如何根据模型特点设计提示词

既然摸清了模型的臭毛病，我们就能在提示词里提前打补丁。我把这次实测中三个模型都表现更好的 prompt 版本贴在下面，供你参考：

请用 HTML + Three.js 制作一个 3D 跑酷游戏。场景中有三条跑道，跑道坐标建议为 x = -2、0、2，玩家的球初始位于 x = 0、y = 0、z = 4。障碍物是一个 BoxGeometry 方块，从 z = -30 远处向玩家方向移动，每次移动单位应为 0.1。请定义一个 Game 类，建议包含 init、setupScene、update、render、keydownHandler 五个方法，在 update 方法中统一处理障碍物位移、碰撞检测、得分更新。游戏循环中要同时调用 update 和 render。碰撞检测请使用 Box3，并确保每一帧都重新计算碰撞盒位置。跳跃时请判断 player.isJumping 状态，防止二段跳。请输出完整可运行的 HTML 代码。

多出来的关键信息有三个：明确的坐标系、明确的循环职责、明确的二段跳约束。我把这些写进去后，三个模型的“一次可用率”都有肉眼可见的提升。你可以发现，这些信息并不是什么高深知识，只是让模型不需要猜测你的意图。

另外还有一个非常有用的技巧：把控制台报错原封不动地粘贴回模型，让它自己修。在这次测试中，GLM5.3 和 Step 5 Preview 都能根据报错快速定位问题，DeepSeek V4 Pro 有时候会“越修越错”，因为它喜欢把没有报错的部分也顺便重构掉。我后来给它加了“只做最小修复，不要改动无关代码”的约束，偏差立刻小了很多。

5.3 顺带一提：本地部署 GLM5.3 时 vLLM 镜像的选择

聊到 GLM5.3，有一个很现实的问题是：很多人不想走 API，想本地部署。我自己的经验是，用 vLLM 跑 GLM5.3 是可行的，但镜像版本一定要选对，否则容易出现各种奇怪问题。

我用的是 NVIDIA 驱动 + Docker 环境，最初直接拉vllm/vllm-openai:latest，结果启动就报显存分配失败。后来检查发现是镜像里的 CUDA 版本和本机驱动不兼容。如果你也遇到类似问题，先确认显卡驱动版本，再反推应该用哪个 CUDA 版本的镜像。比较稳妥的做法是查看 GLM 官方仓库在 vLLM 发布说明里推荐的版本，而不是盲目追求 latest。

另外一个坑是 vLLM 镜像是否带 OpenAI 兼容接口。如果你只是用vllm serve启动模型，通常没问题，但有些精简镜像只提供了离线推理入口，返回格式和 OpenAI 完全不同，这就导致你可能写了半天的游戏测试脚本根本没法调用模型。我后来换成官方推荐的带vllm serve命令的镜像，才顺利跑通。

如果你只是做小范围评测，不想折腾 Docker，直接用transformers加载 GLM5.3 也能跑，但速度会慢很多。我的建议是：本地部署能摸 API 就摸 API，能省下大量调环境的时间。省下来的时间，不如多给模型想几个更好的提示词。

6. 这次实测给我的几点真实体会

6.1 模型写游戏，最大的价值是“脚手架”

经过这一下午折腾，我最大的感受是：别指望模型一键生成完美游戏，但它能把你从一张白纸直接送到“大概能跑”的状态。这个价值非常大。以前我想在 Three.js 里做一个跑酷原型，光查文档、调坐标、修碰撞就要一晚上。现在让 AI 生成初版，我再花半小时改改，一个可玩的 demo 就到手了。它像是一个特别聪明的实习生，你需要检查它的工作，但效率依然比自己从零开始高一个量级。

6.2 提示词和验收习惯比模型本身更重要

三个模型各有各的强项，但最终决定游戏质量的并不是“谁更强”，而是我的 Prompt 写得清不清楚，以及我有没有耐心看控制台报错。我在不同 prompt 下使用同一个模型的体验差异，甚至比不同模型之间的差异更大。如果你想让 AI 写游戏，最值得花时间的不是纠结选哪个模型，而是把需求拆到“坐标、循环、事件、边界条件”这种颗粒度。

6.3 给想这么做的人一个建议清单

如果你也想复现类似的测试，我建议你按这个流程走：先准备一个非常具体的游戏需求，明确坐标系和玩法；让多个模型各自生成，不要中途打扰；把结果保存好，同一环境运行，记录报错；再把报错喂回模型，做两轮修复；最后亲自玩三遍，感受一下操作手感。相信我，这个过程比你刷十篇评测文章有用得多。

这次实测之后，我再也不会相信谁能让 AI“一键生成完整游戏”了。但我更加相信：一个会写 prompt、会看控制台、会把报错喂回模型的人，加上 AI 的脚手架能力，真的可以在一个下午做出一个能和朋友分享的小作品。这本身就是件值得开心的事。