企业官网建设流程全解析

这事儿我得先自嘲一句：测AI写代码，最爽的不是看它秒出几百行代码，而是拿同一个需求来回折腾，看它什么时候开始胡言乱语。前阵子跑测 Step 5 Preview 的时候，我顺手把 DeepSeek V4 Pro 和 GLM5.3 拉进来，做了一个特别适合当“照妖镜”的测试——让它们仨用 Three.js 写同一个3D跑酷小游戏。今天就把整个实测过程、踩过的坑、以及最后得出的选型结论一次性聊透。

这篇内容适合谁？如果你是重度使用AI辅助编程的开发者、想做3D小游戏但没空啃数学原理的独立创作者、或者正在纠结“团队到底该接哪个大模型”的技术选型人，这篇实测能帮你省下不少试错成本。我会把测试设计逻辑、完整的提示词模板、三轮PK实录、Debug协作技巧全部放出来，你可以直接照着复现。

1. 为什么拿“3D游戏”当考题：拆解这次实测的设计逻辑

1.1 3D游戏恰好踩中AI编程的三大命门

很多人测AI写代码，喜欢让它写个登录页面、写个九九乘法表、或者来一段排序算法，说实话这些题太“温顺”了。现在的模型基本都能在小学题上拿满分，根本看不出差距。我这次选3D游戏，是因为它天然踩中AI编程的三个高压区：

第一是三维数学。场景里涉及世界坐标系、相机位置、障碍物运动方向、速度向量，只要哪个轴的正负号反了，物体就会以诡异的方式飞出屏幕。模型如果没有形成空间直觉，代码看起来挺像样，一运行就是灾难现场。

第二是复杂状态循环。一个完整的跑酷游戏至少要有“游戏中”“碰撞后”“重新开始”三种状态，状态之间还要切换得干净利落。很多模型在生成代码时只顾着画画面，忘了把状态管理写完整，于是碰撞之后游戏既不结束、也不计分，角色直接卡在障碍物中间抽搐。

第三是渲染与逻辑的耦合。Three.js 的渲染循环 requestAnimationFrame 每秒被调用几十次，新生成的障碍物需要不断往前移动，已过场的障碍物要回收删除。如果模型不理解“增量更新”这个概念，代码会越跑越卡，最后内存直接爆掉。

换句话说，3D游戏是对模型的代码生成能力、空间推理能力、状态管理能力的三重压力测试，而且结果非常直观——能不能玩、好不好玩、一跑起来哪里崩，一眼就看出来了。

1.2 评判标准：让“能不能玩”说话

为了避免“我觉得A好所以A好”的主观偏差，我把评价维度定成了五个可量化的指标：

后面三轮实测就是照这个表打分的，每个模型都会经历从生成、提Bug到对话修复的完整链路。

2. 赛前准备：同一份需求文档怎么写给三个模型

2.1 测试环境：一个HTML文件跑Three.js，别搞重型工程

我先说环境，这一步看起来简单，但容易成为后续差异的放大器。我用的不是React工程，也不是Vite脚手架，而是最简单的方式：一个HTML文件，通过 CDN 引入 Three.js 和它的核心组件。这样三个模型各自生成的代码，都能直接复制进同一个HTML壳子里跑。

这里有个小技巧：因为浏览器对 file:// 协议有限制，如果代码里用到 module 导入或者贴图加载，直接双击HTML文件容易跨域报错。我给每个模型都加了同一句话：“请把全部代码放在一个HTML文件里，并且只通过CDN加载Three.js，保证用户可以直接双击运行。”这能提前挡掉一大半环境坑。

实测下来，三个模型对这句话的遵守程度不一样。有的会乖乖用全局脚本引用，有的偏要从 ES Module 导入，硬生生在纯HTML里塞 import map。所以环境要求必须在提示词里写死，宁可啰嗦。

2.2 用同一份需求提示词，尽量消除变量

接下来是重头戏：给三个模型喂同一份需求提示词。我设计的需求非常明确，但刻意留了一些让模型自己发挥的空间。完整提示词如下：

请用 Three.js 写一个3D跑酷游戏，单HTML文件，通过CDN引入Three.js，保证可以直接双击打开运行。 游戏规则： 1. 玩家是一个彩色立方体，初始站在三条车道的中间车道。 2. 游戏开始后，障碍物会从远处朝玩家方向不断生成并移动，玩家需要切换到旁边车道来躲避，或者原地跳起越过障碍物。 3. 键位：键盘左右方向键切换车道，空格键跳跃。 4. 游戏有实时计分，分数随时间自动增加，速度会逐渐变快。 5. 玩家撞到障碍物后游戏结束，显示最终得分和一个“重新开始”按钮。 6. 视角使用第三人称追尾视角，方便看到前方障碍物。 请在代码里加入清晰的中文注释，标明每个核心函数的作用。

这个提示词里包含了玩法、键位、计分、视角、注释要求，但没有指定障碍物的形状、颜色、间距等审美细节，留给模型自行决策。我的想法是：这些细节恰好能反映出模型的设计品味和“默认偏好”。

2.3 设计的“暗坑”和预期的难度差异

这个需求看着简单，里面至少埋了四个坑：

坑一：玩家碰撞后要“游戏结束”而不是“角色消失”。很多模型写碰撞检测时会把碰撞物体直接删除，导致玩家“人间蒸发”。

坑二：车道切换要固定“三车道”而不是“自由移动”。如果模型没理解车道这个概念，往往会做成用方向键控制立方体自由移动，玩起来手感松散。

坑三：障碍物要“从远处移向玩家”，而不是“静止摆在那里”。如果方向向量写错，障碍物会从玩家身后冒出来，吓人一跳。

坑四：重新开始时要清空所有障碍物并复位分数，否则点一下重开，前面积压的障碍物会一起涌过来。

我预判到三模型的初版可能都在坑二和坑三上翻车，结果也确实如此，后面实录里会细说。

3. 三轮实测实录：三个模型逐一过招

3.1 第一轮：直接生成，看谁的一次成型率高

测试现场我把三个模型的输出分别放进同环境的HTML文件里，通过浏览器控制台查看报错，再用笔记本记录第一视觉印象。

先看 DeepSeek V4 Pro。它给出的代码最快，结构也很完整，甚至主动开了阴影效果，并且给障碍物设置了一个旋转动画。第一轮它能直接跑起来，五要素里移动、跳跃、计分、碰撞都有，但问题恰恰出在我预埋的坑一：碰撞后玩家立方体直接消失了，连游戏结束画面都来不及弹。我盯着屏幕愣了半秒，随后意识到它用的是“移除碰撞体”方案，把玩家也给移除了。这个问题在代码里其实就是一行 flag 判断的位置写错了。

再看 GLM5.3。它的代码风格非常友好，中文注释极其到位，每个变量名都像是给新手准备的教材。它能够跑通基础场景，但坑二踩得比较实：左右方向键控制的不是“切换车道”，而是“自由沿X轴移动”，也就是说玩家可以停在两条车道中间，障碍物反而会从没有障碍的缝隙里穿过去。这算是没搞清“车道”的边界和步进逻辑。

最后看 Step 5 Preview。这轮它给我的惊喜最大。初版代码就采用了“车道下标 + 目标X坐标 + 平滑插值”的实现方式，碰撞检测写在玩家坐标更新之前，碰撞后立刻锁定操作并显示结束画面。一次生成下来，五个要素全齐了，视觉效果虽然朴素，但逻辑非常硬。唯一的小遗憾是跳跃的“起跳高度”曲线太陡，手感偏硬，不过这属于迭代优化，不是结构性问题。

我把第一轮的打分记下来：DeepSeek V4 Pro 在“直观效果”上最华丽，但出现了状态管理的致命伤；GLM5.3 对玩家意图理解最到位，但实现细分配置不足；Step 5 Preview 逻辑最稳，视觉表现偏原生态。

3.2 第二轮：故意提一个“不指名道姓”的Bug，看谁听懂潜台词

第一轮之后，我给三个模型发了同一条修复消息：

运行游戏时，玩家撞到障碍物之后，画面直接静止并且控制台报错说无法读取某属性。请修复这个逻辑问题。

注意，我并没有直接说“玩家消失是因为碰撞检测里没有判断游戏结束”，而是让它自己从报错症状反推原因。这一轮考验的是“修复指令的理解能力”。

DeepSeek V4 Pro 的响应非常快，它直接从报错信息逆推出“在碰撞检测里访问了已删除物体的位置属性”，然后给出了一个新的碰撞处理函数：先设置 gameOver = true，再禁用输入，最后把玩家的高亮改为灰色。修改完以后，游戏确实能正确结束并弹出分数，但从“移除物体”改成“禁用物体”这个思路上，它还是保留了初始生成的一些习惯。

GLM5.3 的响应风格更“教师”一点。它先解释了为什么会出现“碰撞后读取不到属性”的报错，再说明游戏逻辑里应该用状态机来管理玩家状态。修复代码给得也很完整，但有个副作用：它把之前“自由移动”的逻辑改成了“三车道步进”。所以这轮修完，GLM5.3 反而一跃成为玩法最标准的选手。

Step 5 Preview 在看到这条消息后，先要了一份控制台的具体报错文本和分析过程，然后给出了一个更加“防御式”的修复方案：碰撞处理不再依赖物体是否被移除，而是直接检查距离阈值，把碰撞判定和高光材质变化解耦。这个方案相当优雅，后续想加“碰撞音效”或者“无敌帧”都变得非常简单。

第二轮打完，我的最大感受是：AI修复代码的能力几乎不取决于“它懂多少语法”，而取决于“它是否能在定位环节多问一句”。Step 5 Preview 在这里表现出的细腻度很打动我。

3.3 第三轮：加需求，看谁能在已有代码上做“微创手术”

第三轮的追加需求是这样的，我也原样发给了三个模型：

我想在游戏里加入一个简单的提示面板：开局时显示“按空格键开始”，游戏过程中显示“使用左右方向键切换车道，空格跳跃”。请在现有代码上直接修改，不要重写整个文件。

这个需求看起来很简单，实际上考察三件事：第一，模型是否找到合适的DOM位置插入提示文字；第二，是否知道“按空格键开始”需要改变空格键的功能逻辑；第三，是否听话地只改了必要的部分。

GLM5.3 在这个环节表现得相当稳妥，它找到了一个已经在使用的“分数显示容器”，在旁边新建了一个提示容器，然后根据不同状态切换显示或隐藏。代码改动量很小，几乎没有破坏原有逻辑。

DeepSeek V4 Pro 则出现了一个有趣的问题。它为了“让已有代码更完美”，连带着把障碍物的生成频率和速度曲线也改了一遍。我要的是提示面板，它却顺手调了难度曲线。虽然游戏确实变得更好玩了，但如果你是带着“只改指定区域”的预期来的，就会觉得它有点越界。

Step 5 Preview 在这轮没有突出表现，也没有出问题，属于“把需求做完了但不多给”的类型。它甚至保留了第18行的“空格键入场”逻辑没动，这正是我对“微创手术”的预期。

三轮走完，我心里对三位选手的真实水平已经有了数。

4. 逐个点评：三个模型的脾气、强项与短板

4.1 Step 5 Preview：结构感极强，像一位严谨的技术主管

Step 5 Preview 给我的整体印象是“代码组织能力强到离谱”。它在第一轮主动把游戏初始化、场景搭建、障碍物管理器、碰撞检测、输入处理、UI更新这几个模块分得清清楚楚，甚至每个模块都加上了注释块。

但它的代价是“视觉风格极其克制”。它默认不太会给你加上华丽的粒子效果或后处理滤镜，配色很朴素，阴影能不开就不开。如果你追求的是“给客户演示要好看”，它的初版会让你觉得太干巴。可一旦进入迭代维护阶段，这种结构化的优势就全出来了，后续加、改、删功能都非常舒服。

它适合的使用场景是：项目原型搭建、需要长期维护的代码库、团队协作时大家要一起读代码的场合。

4.2 DeepSeek V4 Pro：生成效率高，但偶尔会“好心办坏事”

DeepSeek V4 Pro 给我的第一感觉是“灵感型选手”。初版代码就能开阴影、加旋转动画、做障碍物大小变化，视觉完成度是三者中最高的。它生成代码的速度也最快，几乎不需要等待思考过程。

但它的风险在于“自作主张”。第二轮修Bug时，它会顺手优化难度曲线；第三轮加提示面板时，它会顺手改变玩法数值。如果你不想让它在小改动里夹带私货，就要在提示词里反复强调“不要改其他内容”。

另一点是它对状态管理的细节有时不够敏感，比如初版的“玩家消失”问题。这让我判断它在处理“多个系统同时修改同一个对象”的场景时，容易出现覆盖或竞态问题。

它适合的使用场景是：快速出效果做演示、不需要长期维护的验证性原型、或者你有精力去收敛它的“顺手优化”的时候。

4.3 GLM5.3：中文理解能力强，像一位耐心的教学老师

GLM5.3 的最大优势是“它真的读懂了需求”。第一轮它虽然把车道切换实现成了自由移动，但它对“躲避障碍物”“跳跃”“计分”这些核心概念的把握是最准的，几乎没有废代码。

而且它的对话修复过程非常舒服：不会直接用新代码砸你一脸，它会先解释问题出在哪、为什么出、我打算怎么改，然后才给代码。这种风格非常适合初学者，也适合需要“边学边写”的场景。

它的短板是“对技术栈的默认参数记忆有时偏保守”。比如它早期生成的阴影配置、相机仰角设置，都像照着某个旧版Three.js教程写的，显得比较传统。

它适合的使用场景是：中文项目文档、教学演示、快速验证想法、以及你跟代码协作时希望“理解每一行为什么这么写”的场景。

4.4 综合对比

我这个测试规模不大，只能说明在“单文件3D游戏”这个特定任务上它们的大致表现，不代表全部能力。但如果你让我给一个没有测试成本的选型建议，我会这么说：要长期维护选 Step 5 Preview，要快速出效果选 DeepSeek V4 Pro，要中文交流和稳定教学选 GLM5.3。

5. 多轮Debug的避坑心得：跟AI协作写3D游戏的技巧

5.1 一次只修一个问题，别让模型“全量优化”

实测中发现，当你同时提交“修Bug+改配色+加特效”三个需求时，模型的输出质量会明显下降，而且最致命的那个逻辑Bug往往会被花里胡哨的需求掩盖。正确做法是一次只提一个明确问题，让模型的注意力集中在最小改动面上。每轮修复之后，我会先跑一次确认没有副作用，再提出下一个需求。

如果你提了一堆需求，模型往往会选择“重写关键函数”而不是“修改关键语句”，这样很容易把其他地方弄坏。把需求拆开，每个对话轮次只做一件小事，看起来多花了几轮对话，实际上总用时反而更少。

5.2 用“边界条件”堵住模型的高频失误点

模型在写3D代码时，最常犯的错不是语法问题，而是“忽略边界条件”。比如碰撞检测里没有判断“玩家已经死亡，不能再操作”；障碍物生成时没有判断“当前已有多少个障碍物在场景里”；重开时没有把计时器归零。

我的经验是在需求描述里直接把这些边界条件写清楚。例如：

游戏结束后，键盘操作必须全部失效。 重新开始时，必须清空场景中的所有障碍物，并将分数和速度恢复初始值。

这两行听起来像废话，但它能把初版运行成功率拉高很多。AI不会自动想到你没提的边界条件，但它会在你提到之后非常忠实地实现。

5.3 让AI“别动我不碰的地方”，减少连锁破坏

在第三轮加提示面板时，DeepSeek V4 Pro 顺手改了难度曲线，给我留下了深刻印象。从那之后，我养成了一个习惯：任何“只加功能”的请求，结尾都必须附带一句“请只添加或修改与本次需求直接相关的逻辑，不要重构、不要优化其他功能。”

这句话在实测中非常有效。Step 5 Preview 和 GLM5.3 听完之后都会乖乖听话，DeepSeek V4 Pro 收敛效果有改善，但偶尔还是会夹带一点私货。如果你想进一步降低风险，还可以让它在回答里用 diff 式说明，比如“我只改了第几行到第几行”。

5.4 让AI打印坐标和状态值，而不是靠肉眼猜

当你发现“跳跃后角色位置不对”“障碍物穿模”“重力不生效”这类问题时，与其让AI直接盲目重写物理逻辑，不如先让它加一行调试输出。比如：

请在每次更新帧的时候，用 console.log 输出玩家当前坐标和跳跃状态，持续10秒。

一旦把坐标数据打出来，问题定位会变得极其快。你甚至可以把控制台的报错和输出信息原样发给模型，让它根据真实数值修改逻辑。这比发一句“跳跃感觉不太对”要靠谱得多。

这招的实际效果远超想象，它能减少大量来回对话。因为很多时候模型不是“不知道怎么修”，而是“看不到真实运行数据”，只能靠猜。有了坐标输出之后，它就像有了仪器一样，判断路径完全不同。

5.5 遇到神秘Bug时，先让AI解释代码再下结论

有一次模型给出的代码里，障碍物生成速度越来越快，导致几秒后游戏根本无法操作。我没让它直接修，而是先问它“请解释这个障碍物生成和移动的完整流程，重点说明速度递增逻辑。”

它解释到一半就发现了自己的问题：速度增量写在更新函数里，每帧都执行，相当于幂次增长。这个Bug通过“让AI自述代码流程”就暴露出来了。这个方法特别适合排查那种“你明明知道有问题，但说不清楚问题在哪”的模糊场景。

6. 高频问题自查表与可复用的上手方案

6.1 3D游戏生成中的高频问题速查

这张表是我在这次实测、以及过去多个项目里总结出来的通用卡片，拿去救急非常好使。

6.2 一个可复用的“3D游戏”提示词模板

如果你不照着我上面那套复杂提示词来，只想先跑通一个小游戏，我建议直接复制下面这个模板：

请用 {技术栈} 做一个 {游戏类型}。 要求： 1. 单HTML文件，所有代码内联。 2. 使用 {CDN或框架地址} 加载核心库。 3. 玩家控制方式为 {键盘具体要求}。 4. 必须有清晰的开始、失败、重开逻辑。 5. 开局前显示操作提示文字。 6. 使用明亮清晰的配色，不要暗色主题。 7. 每次修改只针对指定问题，不要重构其他代码。 8. 关键函数写中文注释。

把花括号里的内容替换成你的项目参数即可。这个模板最精华的地方在于第4条和第7条，它把AI最容易犯的病提前挡住了一多半。

6.3 顺便聊聊本地跑开源模型的一个坑

因为最近总看到有人问“GLM5.3使用vLLM的哪个版本镜像”，我也多说一句。本地部署这种开源模型，镜像版本和模型Release的匹配关系很敏感，最佳方式是直接查模型页面或官方仓库里标注的匹配版本，而不是自己随便拉最新镜像。版本不匹配时会报各种奇怪的显存和算子错误，排查起来极度耗时。如果你只是为了跑对话评测，我还是建议先用在线API，等确定了要做私有化部署再研究镜像。这个顺序能帮你省下大量无意义的环境排查时间。

另外，如果你做的是移动端或者安卓环境的3D游戏，单文件模板的优势会稍微打折，因为手机上还需要处理触摸事件、横竖屏切换和WebView兼容问题。这种情况下建议先让模型生成桌面版并跑通逻辑，再通过“把键盘事件改成触摸事件”的方式逐步迁移，千万别一开始就要求模型做“安卓3D游戏”，否则它会把渲染方案和平台适配混在一起，生成的代码质量会明显下降。

最后分享一个我自己的使用习惯

连续三轮PK下来，我并没有打算“只留一个模型”。我的实际工作流是按阶段切换：项目刚开始、需求还模糊的时候，我会先让 DeepSeek V4 Pro 自由发挥，用它的“灵感”快速铺出版本；等版本定下来进入迭代期，我会把代码交给 Step 5 Preview 继续改，因为它最擅长做结构化的局部修复；如果中途需要跟非技术同事讨论玩法逻辑，我会用 GLM5.3 把设计思路解释得明明白白。

所以说这次实测的最大价值，不是给你一个“谁更强”的结论，而是帮你理解每个模型的“脾气”和“习惯”，知道你哪句话要说重一点、哪类需求要交给谁来处理。AI协作本身就有点像是带三个性格各异的实习生，找到彼此的默契，产出自然就上来了。