企业官网建设流程全解析

说实话，这阵子我一直在纠结一个事：AI写代码到底能不能直接拿来做一个游戏，尤其是3D游戏。正好最近拿到了 Step 5 Preview 的测试资格，我就想着不吹不黑，直接拉上 DeepSeek V4 Pro 和 GLM5.3，用同一个需求开发同一个 3D 游戏，看看谁更能打。测了整整一个晚上，结果比我想象的更有意思，踩的坑也够写一篇长文，今天就把完整过程、代码表现和排查心得全部分享出来。

这个实测适合谁看？如果你平时用AI辅助写前端、做小游戏，或者正想着用开源安卓3D游戏练手，这篇文章应该能帮你省点时间。我会把提示词、验收标准、生成结果、联调修复全部摊开来讲，还会放上三个版本的真实对比，而不是只说“某某很厉害”这种空话。

1. 为什么拿同一个3D游戏去测三个AI

1.1 测试动机：AI写游戏到底靠不靠谱

现在随便打开一个AI编程工具的官网，宣传语都一个比一个猛，好像你只要说一句话，它就能把游戏成品交付到你手里。但实际用下来，很多人应该和我有同感：聊天时什么都懂，一让它生成完整可运行的项目，就开始各种翻车。

所以我一直觉得，评价一个AI写代码的能力，最有效的办法不是跑基准题、刷算法题，而是丢给它一个真实的小型项目，让它从头到尾生成，然后看能不能直接跑起来。游戏这种项目尤其实用，因为它同时涉及场景搭建、用户输入、物理碰撞、UI交互和性能优化，任何一个环节出问题，玩家都会立刻感受到，不像普通的CRUD页面，糊弄一下就过去了。

这次测试，我给自己定了一个规矩：同一个需求描述，同一个目标效果，同一个验收清单，三个AI分别独立完成。我不在中间帮它们改需求，只做运行必需的修复，最后再记录每个人的真实表现。

1.2 为什么选3D迷宫寻宝

选游戏题材时我纠结过几版，比如第一人称射击、赛车、割草无双，最后定了“3D迷宫寻宝”。原因很简单：迷宫可以用二维数组生成，本质上考验AI对数据结构的理解；墙体和角色用几何体拼装，考验空间想象力；金币收集、怪物巡逻、倒计时和步数统计，又能把交互逻辑串起来。

这个项目有一个很关键的好处：复杂度刚好卡在“几百行代码能实现”和“不认真写一定翻车”之间。你要是让AI做一个“扫雷”或者“贪吃蛇”，它已经背熟了，体现不出差异；让AI做大型MMORPG，那又超纲了，谁也做不出来。迷宫寻宝这种项目，AI一眼就能看懂需求，但真正写的时候会遇到视角控制、碰撞边界、寻路策略这些需要动脑子的地方，特别适合横向对比。

更重要的一点是，它很适合作为开源安卓3D游戏的起点。后面我会讲到，网页版跑通之后，套一层壳就能变成移动端可玩的原型，这也是我选这个方向的原因之一。

1.3 三个参赛选手的基本定位

先说 Step 5 Preview。我拿到的是内测预览版，它的宣传重点是“把自然语言需求直接拆成工程结构”，据说特别擅长生成前端交互项目。这次算是我第一次拿完整游戏去压它。

DeepSeek V4 Pro 这段时间风头很足，我平时也常用它做算法题和代码解释，优点是逻辑清晰，缺点是我担心它对游戏场景这类“非典型工程”理解得不够细。

GLM5.3 同样是个熟面孔，对话能力很强，写长文本、做总结都是一把好手，但代码生成方面我有一个刻板印象：功能想得很全，代码结构偶尔会乱。这次正好验证一下。

我刻意没有让三个AI互相交流，也没有把某一家的生成结果喂给另一家去参考。每轮测试都从同一个空白HTML文件开始，避免“抄作业”式的公平性问题。

2. 提示词设计：同一个需求如何公平测试

2.1 原始提示词公开

想让三个AI公平竞争，提示词不能太模糊，也不能把答案喂到嘴边。我最终使用的提示词长这样：

请用 Three.js 写一个可直接在浏览器运行的 3D 迷宫寻宝游戏，要求： 1. 单 HTML 文件，使用 CDN 引入 Three.js，不要使用其他框架； 2. 迷宫由 0/1 二维数组生成，1 表示墙，0 表示路，用立方体生成墙体； 3. 玩家角色用圆柱体或立方体表示，第三人称俯视视角； 4. 用 WASD 控制前后左右移动，需要做穿墙碰撞检测； 5. 场景里有 5 个旋转的金币，全部收集后显示通关； 6. 游戏界面显示计时器和当前步数； 7. 场景中有一个简单巡逻的怪物，碰到怪物后玩家回到起点； 8. 代码尽量简洁，关键地方写中文注释。

这个提示词没有指定迷宫尺寸、没有指定相机初始位置、没有指定怪物移动算法，等于把“实现细节”的决策权留给了AI。我故意这么干，因为我想看的正是AI在自由发挥时会不会做出合理选择。

2.2 三款AI对需求的理解差异

提示词发出去之后，第一轮就体现出了明显差异。

Step 5 Preview 没有急着写代码，而是先输出了一段“我打算怎么实现”的思路，把迷宫生成、碰撞检测、怪物巡逻、UI状态四个模块拆得很清楚，然后才开始写。这种“先列结构再填代码”的节奏，对我来说非常友好，因为后期定位Bug不用在大泥潭里捞针。

DeepSeek V4 Pro 属于典型的技术型风格，二话不说直接给了一整份 HTML。它特别注重算法正确性，迷宫生成用的是深度优先回溯，代码里的边界条件处理也很扎实，但前期缺少结构规划，后面所有逻辑都写在几个大函数里，读起来会有点累。

GLM5.3 的理解最“发散”。它不但做了提示词里的功能，还额外加了一个鼠标点击移动、一个自动跟随相机、一个简单的开始菜单。听起来很丰富，但代价是它把金币数量写成了 8 个，和需求里的 5 个不一致。这种“自己加戏”的行为，在这次测试里既算惊喜也算隐患。

2.3 我为什么要强调“单文件”和“CDN”

这里多解释一句，提示词里强调单HTML和CDN，不是因为我偷懒，而是为了控制变量。

如果允许AI自由选择技术栈，一个可能用Vite，另一个可能用Next.js，那到了运行环节就说不清到底是“AI不行”还是“环境配置不对”。单文件意味着所有逻辑都塞在一个文件里，打开就能测，省去一堆依赖安装。CDN引入Three.js则是为了不依赖本地npm包，测试过程更干净。

实际测试也证明这个约束很有用。三个AI都规规矩矩用了Three.js的CDN版本，没有谁擅自引入Vue或React，这让我能专心对比核心游戏逻辑。如果你以后想让AI做小游戏，我也强烈建议你先把“技术栈和交付形式”钉死，否则AI的自由发挥很容易变成灾难现场。

3. 生成与运行实录：一遍遍跑起来的现场

3.1 环境准备与验收标准

测试环境非常朴素：一台装了Node.js的电脑，一个Chrome浏览器，外加一个本地静态服务器。用Live Server直接打开也可以，但我更习惯用npx serve .起一个临时服务器，避免浏览器直接加载本地文件时出现的跨域限制。

在开始之前我列了一个验收标准表，每个AI生成后都按这个清单打分：

每个AI我都给了同样的15分钟“救助窗口”，也就是说，如果第一次运行失败，我可以手动修复，但修复的代价会计入最终的“翻车指数”。超过15分钟修不好，就直接判为不及格。

3.2 Step 5 Preview：一次过，结构最舒服

第一轮上场的是 Step 5 Preview。生成耗时大约40秒，输出是完整的HTML文件，代码量约600行。我把它放到服务器里打开，画面直接出来了，淡蓝色的天空背景，白墙灰地，玩家是一个橙色圆柱体，五个金币分布在迷宫里，怪物是一个红色立方体，在通道里来回巡逻。

最让我吃惊的是它的碰撞检测写得干净利落，核心逻辑只有几句话：

// 判断目标坐标是否在墙格子内 function canMove(targetX, targetZ) { const gridX = Math.floor(targetX / cellSize); const gridZ = Math.floor(targetZ / cellSize); if (maze[gridZ]?.[gridX] === 1) return false; return true; }

这个实现不是最精细的，但配合后续的墙体模型位置，效果出人意料地好。玩家不会穿墙，也不会在不该停下的地方卡住。唯一的缺点是怪物移动逻辑比较简单，只会沿着固定路径来回走，没有什么追击感，但这本来就是需求里允许的“简单巡逻”，所以我不扣分。

而且在UI方面，它把计时器和步数放在左上角，金币计数放在右上角，这种细节说明它对游戏HUD有基本的概念，不是随手把文字贴到页面上。

3.3 DeepSeek V4 Pro：算法强，但手感偏硬

第二轮是 DeepSeek V4 Pro。生成耗时约1分20秒，明显比Step慢，代码量反而更少，约450行，整体风格很像“算法工程师写的游戏”：迷宫生成部分很漂亮，深度优先回溯跑出来的地道特别规整。我看了一下它的迷宫生成函数，结构很标准：

function generateMaze(width, height) { const grid = Array.from({ length: height }, () => Array(width).fill(1)); const stack = [[1, 1]]; grid[1][1] = 0; while (stack.length) { const [x, z] = stack[stack.length - 1]; const dirs = shuffle([[2, 0], [-2, 0], [0, 2], [0, -2]]); const next = dirs.find(([dx, dz]) => grid[z + dz]?.[x + dx] === 1); if (next) { const [dx, dz] = next; grid[z + dz][x + dx] = 0; grid[z + dz / 2][x + dx / 2] = 0; stack.push([x + dx, z + dz]); } else { stack.pop(); } } return grid; }

一眼看过去没什么大问题，跑起来也确实能生成迷宫。但DeepSeek V4 Pro的手感比较“硬”：它是俯视角，但相机的移动速度没有随角色位置变化做缓动，导致玩家跑到墙角时，镜头一甩，容易晕。角色速度又稍微偏快，碰撞检测的阈值卡得太严，有时候明明离墙还有一小段距离，就被判定撞墙停下。

最后我给它扣了一点手感分，但算法部分它确实做到了三家里最扎实。如果一个项目特别看重迷宫生成质量，我会优先选它。

3.4 GLM5.3：功能最全，黑屏也来得最快

第三轮是 GLM5.3。生成耗时约50秒，代码量最多，约780行，还自动拆出了开始菜单、触屏摇杆和鼠标点击移动。我第一次打开时，页面一片漆黑，控制台上报错renderer.setSize is not a function。检查之后发现它创建渲染器的代码里漏了.setSize，这是很基础的一处遗漏。

我手动补上这一行：

renderer.setSize(window.innerWidth, window.innerHeight);

再刷新，画面就出来了。从这里开始，GLM5.3的“功能狂魔”属性开始显现：它的UI很完整，开始游戏有菜单，结束时有效果文案，手机屏幕上还多了一个虚拟摇杆，直接就能在触屏设备上玩。

不过它的代码结构确实最乱。一个文件里同时混着多个全局事件监听，金币和怪物管理在一个大循环里轮询，如果我想继续往上加功能，大概率要重构。在“功能完成度”上它排第一，在“代码可维护性”上它排倒数第一。

3.5 三版实现的功能完成度横向对比

为了让你有个直观感受，我把这次实测的数据整理成了表格。所有数据都来自同一轮测试，带有随机性，但足以反映趋势。

这个结果非常有意思：没有一个全能选手。擅长结构的，算法不一定最漂亮；功能最全的，代码阅读成本最高。所以指望“一个AI搞定所有事”目前还是不太现实，更合理的方式是按项目阶段换工具。

4. 跑起来之后的联调、性能与移动端适配

4.1 第一个晚上就卡在“文件打不开”

测试过程中最容易劝退新手的问题，不是AI写的代码有多烂，而是文件打不开。我见过太多人直接双击生成的HTML文件，然后发现Three.js加载失败。这不是代码问题，是浏览器安全策略限制了本地文件对资源的访问。尤其是用ES Module方式引入Three.js时，直接在file://下打开一定报跨域。

解决方法很简单，本地起一个静态服务器就行。我习惯用：

npx serve .

或者用Python：

python3 -m http.server 8080

然后浏览器访问http://localhost:8080就能正常打开。如果你用VS Code，也可以安装Live Server插件，右键“Open with Live Server”一键搞定。这个坑我踩过一次之后，现在每次让AI生成Web项目，第一件事就是先开服务器，而不是傻傻双击文件。

4.2 碰撞检测和移动手感的真实调优

三款AI生成的版本都能玩，但手感都谈不上好。最典型的问题有两个：一是帧率波动导致移动速度忽快忽慢，二是碰撞边界和角色模型半径不匹配。

帧率问题的根源是游戏循环里直接按“每帧移动固定距离”的方式更新位置。60帧的屏幕和一帧掉到30帧的屏幕，角色移动速度会完全不同。修复方法是用时间增量delta来约束移动距离：

const delta = clock.getDelta(); const speed = 5 * delta; player.position.x += moveX * speed; player.position.z += moveZ * speed;

碰撞检测的手感调优更微妙。AI生成的canMove函数通常把玩家当成一个点判断，但3D角色是有体积的，结果就是角色贴墙时总感觉“嵌进去一点”。我习惯在判断时把碰撞半径缩小0.2个单位，给玩家一条“宽容通道”：

const playerRadius = 0.4; function canMove(x, z) { const gridX = Math.floor((x + Math.sign(x) * playerRadius) / cellSize); const gridZ = Math.floor((z + Math.sign(z) * playerRadius) / cellSize); return maze[gridZ]?.[gridX] !== 1; }

这种细节AI有时候写不出来，但人对“手感”的判断是秒级的。所以我的经验是：让AI生成初版，真正调手感还得自己上。

4.3 从网页原型到开源安卓3D游戏的演化路线

热词里提到“开源安卓3d游戏”，很多人第一反应是从零写一个OpenGL或者Vulkan项目，那学习成本确实高。但这次测试给我的启发是：你完全可以把网页版3D游戏当作原型，再往安卓方向走。

一套成熟的路线大概是：先把Three.js游戏在浏览器里跑通，确认玩法和手感都没问题，然后使用Capacitor把Web项目打包成Android工程，或者直接在App里嵌一个WebView加载本地页面。这样做的好处是，你只需要维护一套游戏逻辑，同时保留后续用原生代码替换高性能模块的路径。

当然，如果你追求的是极致性能、纯离线、上架Google Play，那最后还是得把核心渲染用原生方案重写。但作为开源项目的第一步，先把Web原型做好，绝对是成本最低的方式。这次三个AI生成的游戏，我个人认为三份代码合并一下，是一个不错的移动端原型基础。

5. 常见问题与排查技巧速查表

5.1 我遇到最多的5个问题

一个晚上测试下来，我把遇到最多的问题整理成了速查表，涵盖三个AI的“爆点”。如果你也准备用AI写3D游戏，大概率会碰到这几件事。

黑屏这个问题，三个AI里有两个都出现过，属于最常见的通病。所以如果你让AI生成Three.js项目，第一件事就是检查渲染器创建和尺寸设置。手机白屏，则大概率是忘记限制像素比，高分辨率手机的性能会被直接拖垮。

5.2 三个AI写代码的通用避坑思路

让AI写游戏，本质上是“人机协作”而不是“人机交接”。我自己的避坑思路可以总结成一套小流程：

第一步，拿到AI生成的代码之后，先别急着跑，而是先看它的整体结构。如果结构乱成一锅粥，跑通也救不回来，后面每次改需求都要花十倍时间。

第二步，建议AI先生成一个任务拆分文档，再让它按文档写代码。这次Step 5 Preview的表现之所以让我舒服，就是因为它先拆了模块。如果你用的AI不主动拆，你可以在提示词里要求它必须拆。

第三步，给AI一个“出错预算”。我每轮测试都只给15分钟修复时间，超过预算就重新生成一版。AI生成代码有很大的随机性，这一版翻车，换一个角度重新提问，有时候反而能跑通。

最后，一定要自己动手看代码。AI给你的是“能跑的代码”，不是“你理解的代码”。如果你看不懂它写的东西，出了问题你连修的方向都没有。

6. 我的使用建议与一点个人体会

6.1 如果只让我选一个主力

这次实测之后，如果非要选一个主力，我的答案不是代码最漂亮的DeepSeek V4 Pro，也不是功能最全的GLM5.3，而是Step 5 Preview。原因很实际：我写游戏的过程中，最怕的不是AI不会算法，而是它在代码结构上给我挖坑。Step 5 Preview先拆结构再写代码的习惯，让我后续调手感、加功能都很省力。它生成的内容不是一个“一次性代码片段”，而更像一个可以持续迭代的小工程。

但这不代表DeepSeek V4 Pro和GLM5.3不值得用。DeepSeek V4 Pro特别适合用来解决具体问题，比写迷宫生成、寻路算法这种单点技术活；GLM5.3则适合当你需要一大套UI、按键、菜单这些交互细节时，它能帮你把全面的“架子”搭得很丰富，但你需要花时间做减法。

6.2 一个提高成功率的测试习惯

最后分享一个我觉得特别有用的习惯：不要一上来就让AI写全部代码，而是先让它生成一份“游戏功能拆解文档”，把场景、玩家、敌人、金币、UI、音频、关卡拆成独立模块。这步走完，你再让它按模块逐个生成代码，成功率会高很多。

我在这次测试后，已经把三版代码合到一起，保留Step 5 Preview的工程结构、DeepSeek V4 Pro的迷宫算法、GLM5.3的触屏摇杆，形成了一个可以继续往开源安卓3D游戏方向迭代的原型。如果你也想做类似的事，我建议你试试这个流程：先拆任务，再写代码，最后自己动手修手感。AI可以帮我们写出很多东西，但一个好用的游戏，终究还是需要人站在玩家的角度去把关。