我先给大家一个判断：这类“AI 大横评”真正有价值的，不是看谁生成的画面更炫、代码跑起来有多流畅，而是看同一个任务、同一段提示词，在不同模型手里会被拆解成什么样的执行路径。
最近我抽了一下午，用“相同提示词生成一个网页版我的世界”这个任务，横向对比了四个代表性模型：ds v4 pro、0813、flash、kimi k3。这个过程比结果更有意思，因为我发现它们四个对“我的世界”这个三个字的理解、对“网页版”这三个字的落地方式、对“用代码实现”这件事的工程判断，差异大到像是四个不同资历的开发者在回答同一个面试题。
这篇文章不打算做评分排行榜，也不打算给模型排名。我想拆的是：为什么同一个任务，不同模型的写法差异这么大？这些差异背后反映出什么能力分层？以及，如果你想用 AI 写代码、做小游戏、做互动页面，应该用什么样的思路去驾驭它。
1. 为什么“网页版我的世界”是一个特别适合做横评的任务
很多人做 AI 编程对比，喜欢让模型写一个登录页面、一个 todo list、一个博客系统。这些任务不是不好，而是太规范化了。训练数据里这类代码量大，模型很容易“背”出答案，看不出真实水平。
“网页版我的世界”就不一样。
1.1 这个任务天然自带三层复杂度
从任务本身来看，它有三个层层递进的难点。”
第一层是概念理解。“我的世界”包含方块世界、玩家移动、第三人称或第一人称视角、挖矿、建造、重力、碰撞检测。一个 AI 如果只是知道“Minecraft 是游戏”，写出来可能是一个静态页面；只有理解了“它是由方块组成的、可交互的体素世界”，才能走向正确方向。
**第二层是技术选型。**网页版意味着要用 HTML、CSS、JavaScript，可能涉及 Canvas、Three.js、或者纯 DOM 绘制。不同模型会做不同的选型判断。有人用纯 Canvas 2D 做一个俯视图 2D 版本，有人用 Three.js 拉一个 3D 场景，有人甚至直接给你铺一个 fullpage 的伪 3D 效果。选型差异背后，是模型对“可行性”和“复杂度”之间的权衡。
**第三层是交互完整性。**真正能“玩”的网页版我的世界，至少要有视野旋转、方块放置、方块破坏、背包或方块类型切换。很多模型写出来的版本看起来像模像样，实际上只能前后左右走，方块不能放不能挖，只能算“场景浏览器”，不能算“游戏”。
这三个层次，把一个模型的理解能力、代码生成能力、工程取舍能力全部暴露出来了。
1.2 为什么“相同提示词”这个前提很关键
对比实验里，提示词必须是完全相同的。因为提示词就是任务说明书，说明书一样，才能看出执行者的差异。如果我给 A 模型写一段非常详细的提示词，给 B 模型只写一句话，那对比的不是模型能力，而是我自己写的提示词水平。
这里也有一个很容易踩的坑：很多人做对比时，会给每个模型单独优化提示词，甚至每个模型用不同的“最佳实践”写法。这样的对比结果，本质上是在对比“提示词工程师的适配能力”，不是模型能力本身”。
所以这次我用的提示词是中性偏简单的：
请用 HTML、CSS、JavaScript 写一个网页版的我的世界。要求：可以放置方块、破坏方块、切换方块类型，有视野控制，有重力，画面风格接近原版我的世界。
就是这么一段。没有指定引擎、没有指定 2D 还是 3D、没有指定操作方式。让每个模型自己发挥。
2. 四个模型的真实表现：同一道题，四种答法
先说明一下，模型生成结果会随版本更新和采样参数变化，下面描述的是我这次实际测试的体感，不是长期结论，更不是官方背书。
2.1 ds v4 pro：工程感最强，代码完成度像老手交作业
ds v4 pro 拿到任务后的第一反应是确认需求而不是直接写。它会先输出一段思考过程，说明它准备用什么方案：用 Three.js 做 3D 渲染，用 PointerLockControls 做鼠标视野控制，用简单的 mesh 组合做方块，用 Raycaster 做方块选中和放置。看到这段思路的时候，我的第一反应是：它懂 Web 3D 编程的常规技术栈。
生成出来的代码比较完整，文件结构是一个 HTML 文件内嵌全部脚本。打开以后是一个灰蓝色天空、绿色草地、棕色泥土的方块世界。移动是 WASD，跳跃是空格，鼠标拖拽旋转视野，左键破坏方块，右键放置方块，顶部有方块类型切换栏，包含草、泥土、石头、木头、树叶几种基础方块。
整个代码大概在 400 到 500 行左右。它选择了 Three.js CDN 的方式加载依赖，没有让我本地装包。这个选择对于网页版项目来说是合理的：单文件、零构建、直接打开浏览器就能玩。
ds v4 pro 还做了一些细节处理，比如射线检测的距离限制、方块高亮轮廓、放置方块时避免和玩家重叠、简单的地面碰撞。这些不是花哨功能，但它们决定了这个 demo 能不能“玩下去”。至少我试玩的过程中没有出现穿模到地底、方块放在自己身上无法动弹这种致命问题。
**缺点也很明显。**性能一般。打开页面后帧率尚可，但如果连续放置几百个方块，画面会出现可感知的卡顿。它没有做 Mesh 合并，每个方块都是独立网格，这是性能瓶颈的主因。不过对于一个单文件 demo 来说，这属于可接受的初级阶段问题。
2.2 0813：思路很新，但完成度更像原型验证
0813 交出来的方案给了我一种“聪明但不够稳”的感觉。它没有用 Three.js，而是用纯 Canvas 2D 实现了一个类似 2.5D 斜视角的方块世界。
画面效果其实挺有意思：地面是斜向网格，方块有简单的明暗面模拟立体感，玩家是一个可以在地图上移动的圆形角色。操作方式不是鼠标视野旋转，而是方向键移动 + 空格跳跃 + 鼠标点击放置/破坏。
**这个方案的优势是轻量。**打开页面后秒加载，即使在没有 GPU 加速的电脑上也能流畅运行，因为 Canvas 2D 的绘制开销远小于 WebGL。从兼容性角度看，用纯 Canvas 2D 写一个“我的世界”风格页面，反而是一个更稳、更保守、更适合在低性能设备上跑的选择。
**但问题也很明显：它离“我的世界”三个字差得有点远。**因为它是 2D 的，没有第一人称沉浸感，也没有真正的三维空间关系。你可以在这个世界里走来走去，可以挖掉方块、放上方块，但这个世界更像一个“俯视角沙盒小游戏”，而不是“我的世界”。
从“需求满足度”角度看，0813 的版本只能算部分达标：它能放置和破坏方块，但没有 3D 视野控制，画面风格和原版差别也比较大。
2.3 flash：速度快，但贪快导致读题不细
flash 模型最大的特点是快。按下回车，几乎是一眨眼的功夫就开始生成代码了。如果你在乎的是“等我三秒就要看到一个能玩的页面”，flash 的体验确实无敌。
但快速生成也带来了短板上限。flash 给的版本像是“用 2D 方式模拟 3D 世界”的混合体：地图用 Canvas 2D 俯视图渲染，玩家用一个小方块表示，放置和破坏功能都有，但操作逻辑更接近“地图编辑器”而不是“第一人称游戏”。
它确实理解了“放置方块、破坏方块”这两个核心动作，但没有认真处理“视野控制”和“重力”。它更像是老师布置作业后，快速交了一个能运行、功能点都点到、但完成度不高的版本。”
这里要夸一个点：flash 给出了非常清晰的代码注释。每一段逻辑都有中文注释说明，甚至标注了“如果你想调整重力，改这个变量”“如果你想增加方块类型，在这里加”。对于想基于 AI 生成代码学习的人来说，这是四个版本里最友好的。
如果你是一个学生，或者刚接触前端编程的人，flash 的答案反而是最适合入门的：代码结构清楚、注释丰富、改起来容易。如果你想直接拿来做游戏项目，它还需要大量的手工迭代。
2.4 kimi k3：最接近“产品需求文档”的交付物
kimi k3 的答案让我犹豫了一下，因为它的思考方向跟前三者完全不一样。它不是直接给你一个能跑的 HTML 页面，而是先给你一个“技术方案对比表”，列出了三种实现路径：
- 用 Three.js 做真正 3D 场景，沉浸感最强，但代码量最大。
- 用 Canvas 2D 做 2.5D 效果，平衡性能和完成度。
- 用 div + CSS 拼方块，适合表现静态建筑，不适合交互。
然后它告诉你：基于当前需求“快速得到一个能玩的网页版”，推荐方案 2，并给出了理由。
紧接着它才写代码。代码结构是分文件组织的，它给出了 index.html、style.css、main.js 三段代码，并告诉你如何保存到同一个目录下运行。这个结构对于单独玩具 demo 来说偏重，但如果后续要继续扩展，比单文件 HTML 要清晰得多。
kimi k3 实现的玩法是 2.5D 侧视角，不是第一人称。玩家可以在一个横版的世界里跑跳，可以破坏和放置方块，地图里有草地、泥土、石头，还加了一个简单的背景云朵飘动效果。整体完成度比 0813 高一点，动画也平滑一些，代码组织和注释明显占了优势。
**缺点是：**它没有遵循“网页版我的世界”这个核心提示词里的 3D 预期。当然你可以说它是在“需求不明确时做了合理范围界定”，也可以说是它读题不充分。我倾向于认为它是在“实现一个可玩原型”这个目标上做了权衡，这个选择本身符合工程逻辑。
3. 表面是模型对比，本质是四种能力分层
把四个模型放在一起，不看代码细节，而是看它们的决策差异，会发现一个明显分层。
3.1 理解层：谁能抓到“体素世界”这个本质
“我的世界”的关键词不是“世界”，而是“体素”。体素意味着三维空间里的立方体网格，每个格子可以独立替换。理解到这个层面，代码设计就会往 3D 方向走；理解不到，就会在 2D 网格上打转。
ds v4 pro 和 kimi k3 都对“体素”有理解。ds v4 pro 直接选择了 Three.js 的 BoxGeometry 逐个生成方块，并从地图数据里管理每个方块的位置和信息。kimi k3 虽然选择了 2.5D 方案，但在代码设计里保留了三维数组作为地图数据核心，说明它理解底层逻辑，只是在渲染层做了降级。
flash 和 0813 的地图数据也用了二维或三维数组，但在交互呈现上没有围绕“三维空间”这个点去设计，更像“2D tile map”的沙盒游戏，理解层停留在“用网格模拟世界”。
3.2 取舍层：会不会在约束条件下做技术选型
任何一个有经验的开发者都知道，代码从来不是“写得越复杂越好”，而是“在约束条件下选最合适的方案”。
这四个人里，取舍最明显的是 kimi k3。它先去对比三种实现方案，然后选择一个“不一定最强但最合适”的路径。这种思维模式已经接近人的工程决策。
ds v4 pro 也做了取舍。它选择了 Three.js 这个重依赖，说明它愿意牺牲加载速度换取 3D 表现力。代价是如果用户网络不好，CDN 加载失败，整个页面就白屏了。它没有做备用渲染方案。
flash 的取舍是“先有，再完善”。它的代码明确留了改进接口，算是四个里最容易二次开发的。
0813 的取舍是“最求稳”。纯 Canvas 2D 的效果上限最低，但出问题的概率也最低。
**没有标准答案。**但如果你的目标是一个有沉浸感的可玩 demo，选三和选一的优先级应该高于选二和选四。
3.3 工程层：代码是否具备“可长期演进”的结构
单页面 demo 和真正能长期迭代的项目，差别就在这儿：数据结构是否独立、渲染逻辑是否和游戏逻辑解耦、新增方块类型是否容易。
从这四个版本看：
- ds v4 pro：数据结构清晰，方块类型以配置对象管理，新增方块只需加一行配置。但渲染逻辑和游戏逻辑耦合在一个大函数里，扩展起来需要仔细读代码。
- kimi k3：文件分离，职责清晰。main.js 里分成初始化、输入处理、方块操作几个模块。这是最接近真实项目结构的写法。
- flash：代码注释很友好，但逻辑整体在一个 canvas 循环里，属于典型的教学型代码。
- 0813：逻辑集成度高，更像“完成题目”，而不是“搭建项目”。
3.4 交付层：是不是开箱即用
“开箱即用”这个词，对 AI 生成代码这个场景来说，比什么都重要。
ds v4 pro 是单文件、零依赖本地代码、双击 HTML 就能跑。虽然它引用了 CDN 依赖，但只要网络正常就能直接跑。最符合“我要立刻看到效果”的诉求。
kimi k3 是三个文件，需要用户自己保存到同一个目录下再打开。多了一个步骤，但对后续维护友好。
flash 是单文件，而且注释详细，对新手最友好。
0813 也是单文件，但运行后没有给任何操作提示，我第一次打开都不知道按什么键能走、按什么键能挖。这个细节很影响体验。
4. 相同提示词之外：决定成败的五个隐性变量
对比实验做到这一步，我有一个很强烈的感觉：提示词只是启动器，真正决定生成结果质量的，是一批隐藏在表面之下的变量。如果只盯着提示词，忽略这些变量，很容易得出“某模型不行”的错误结论。
4.1 模型对“不明确信息”的处理方式
“我的世界”这三个字充满歧义。它可以是游戏，可以是网页小游戏，可以是教学项目，可以是产品原型。一个模型看到这个词，怎么理解全凭训练数据里的倾向。
ds v4 pro 倾向于“尽可能接近原版体验”，所以选了 3D。 kimi k3 倾向于“先定义范围再动手”，所以先给方案对比。 flash 倾向于“快速产出可运行代码”，所以选最简单路径。 0813 倾向于“在已有能力范围内尽力完成”，所以选择自己最擅长的渲染方式。
没有谁对谁错。但理解每个模型的倾向后，你就可以用提示词里的限定词去约束它的倾向。比如你想让 flash 不要走 2D 路线，那就在提示词里明确写“必须使用 Three.js 实现 3D 第一人称”。你想让 kimi k3 不要先讲方案，直接写代码，就写“不要解释，直接给出完整代码”。
4.2 生成时的一次性又是不可控的
同样的模型、同样的提示词，两次生成结果不一定完全一样。因为大模型生成时存在采样随机性，生成时温度参数设置不同，输出会有波动。
这带来两个实操建议：
- 如果你对某个版本不满意，不要立刻换模型，先重新生成几次，有时候只是运气不好。
- 如果你对某个版本特别满意，在关闭页面之前把代码完整复制保存下来。AI 生成的对话关掉之后就找不回来了。
4.3 版本差异大于模型能力差异
模型名称后面带的数字、日期后缀，代表的是训练版本或蒸馏版本。比如 ds v4 pro 和 0813 就是两种不同配置的版本。它们的能力侧重点不同，不完全是“新版本一定碾压旧版本”。
多个模型版本对比时，最容易犯的错误是把“版本差异”误判成“品牌能力差异”。正确的做法是分别测试同一模型的不同版本，再做横向比较。
4.4 输出长度限制和 Code Interpreter
很多 AI 生成代码写一半就断掉，不是因为它不理解，而是因为它一次能输出的字符有限。遇到长代码，有些模型会选择截断或缩短实现。
如果你生成一个较大的项目，建议把需求拆成多次对话，每次让模型生成一个模块，而不是一次性让它输出完整项目。对于网页版我的世界这种规模的任务，单次生成还勉强可以，如果换成用 Python 实现一个完整 2D 沙盒游戏，就建议拆分：先生成地图系统，再生成玩家控制系统，最后生成方块交互系统。
4.5 用户的本地位能力决定了最终效果
这句话听起来像废话，但却是整个横评里最重要的结论。
AI 生成的代码，本质上是一个“初稿”。能不能把它变成一个真正好用的东西，取决于你能不能读懂代码、会不会改参数、能不能修 bug。同一个 ds v4 pro 生成的版本，一个有经验的前端开发者拿到手十分钟就能改成可发布的小游戏；一个没有编程经验的普通用户，可能连“怎么把代码保存为 HTML 文件”都卡住了。
所以我的态度是：AI 生成代码降低了“从 0 到 1”的门槛，但没有降低“从 1 到 N”的门槛。后者仍然需要人力，需要懂一点编程，需要至少会用开发者调试工具。
5. 从“会写代码”到“能交付”，需要补上的四块拼图
如果你满足于“AI 帮我生成一个可以打开的小页面”这个阶段，前面的内容已经够了。但如果你想把这类生成结果用在实际项目里，还需要在生成之外补上工程化能力。
5.1 第一块：代码运行环境的确认
AI 生成的代码依赖是隐形的。你看到它写了一个<script src="https://cdn.jsdelivr.net/npm/three@0.160.0/build/three.min.js"></script>，如果没网络这个页面就是白屏。
所以在使用 AI 生成的前端代码之前，第一件事就是确认依赖加载方式。建议：
- 打开浏览器开发者工具（F12），切到 Network 面板。
- 刷新页面，看有没有红色的请求失败。
- 如果有 CDN 加载失败，换成其他 CDN 源或者本地引入依赖文件。
这一步看起来简单，但实际使用中 80% 的“黑屏/白屏”都是依赖加载失败导致的。
5.2 第二块：代码能否在本地稳定复现
AI 生成的代码能在网页在线编辑器里跑，不代表在本地也是同样的表现。涉及本地文件路径、图片资源、音效文件时，容易出现相对路径错误。
建议每个 AI 生成的网页项目，都按这个顺序验证：
- 先在本地文件系统里跑通一次。
- 再放到一个静态服务器上跑一次。
- 对比两次运行结果是否一致。
如果你不知道什么是静态服务器，可以用python -m http.server启动一个简单的本地服务器，或者用 VS Code 的 Live Server 插件。这算是前端开发里最低门槛的本地预览方式了。
5.3 第三块：代码的异常处理和边界条件
AI 生成的代码大多数只覆盖“正常流程”：正常走路、正常挖方块、正常放置。但真实使用中会遇到很多边界情况：
- 玩家走到地图边界之外怎么办？
- 放置方块时周围都是方块，玩家被卡住怎么办？
- 方块破坏后掉到虚空里，需不需要回收？
- 快速连点鼠标，会不会重复创建同一个方块？
这些边界条件，AI 不会主动考虑。你需要自己添加出来，或者把这些问题作为后续提示词的一部分，让 AI 继续补充。
还有一个很常见的例子：AI 生成的 Canvas 小游戏，在窗口大小变化后，游戏画面比例失衡。这时候就需要添加 resize 事件监听，重新调整画布尺寸和坐标系。这个补丁基本每个 AI 生成的小游戏都要打。
5.4 第四块：性能优化和资源控制
AI 生成代码的性能表现，普遍存在“功能越多，越卡”的情况。以这次测试为例，ds v4 pro 生成的 Three.js 版本，在放置了几百个方块后出现了明显卡顿，根本原因是每个方块都是独立的三维对象，没有做实例化或合并。
如果你想做一个小体量的沙盒游戏，需要掌握的优化手段至少有这些：
- 用 InstancedMesh 代替大量重复的 Mesh。
- 对不在视野范围内的物体做剔除。
- 将地图数据与渲染对象分离，不要每次遍历所有方块做更新。
- 使用 requestAnimationFrame 而不是 setInterval 做游戏循环。
这些优化点在你想做一个“能发布给别人玩”的版本时，是必须处理的。否则游戏一开始有趣，玩着玩着就变成“PPT 演示”。
6. 一个可复用的 AI 写小游戏五步法
通过这次对比测试，我总结出一个适用于“用 AI 生成互动网页或小游戏”的通用路径。它不一定适合所有场景，但对 AI 写小游戏这个场景，尤其是生成代码后还想继续迭代的情况，很有效。
6.1 第一步：明确“最小可玩版本”的定义
先不管 AI，问你一个问题：如果这个页面只保留一个核心功能，你会保留什么？ 对于我的世界，答案大概率是“放置方块”和“破坏方块”。如果这两件事做不出来，其他一切免谈。
所以你的第一次提示词，应该围绕“最小可玩版本”来设计，而不是一口气要一个完整的游戏。一次提示词只追一个功能目标，比一次把所有功能都写完，成功率高得多。
6.2 第二步：把需求拆成“功能块”再喂给模型
把游戏拆成几个功能块：地图生成、玩家控制、方块操作、UI 显示、音效动画。一次对话只生成一个功能块，测试通过后再让 AI 把新功能融合进去。
比如先让 AI 生成“一个第一人称视角，可以在地图上走动”，测试通过后再让它加“鼠标点击方块可以破坏”，再下一步加“右键放置方块”。这样每一步出问题的范围都很小，排查成本低。
6.3 第三步：用“让 AI 补丁”代替“彻底重写”
AI 生成代码经常有 bug。遇到 bug 时，先不要急着让它重新生成整个项目。你要做的是：
- 描述报错信息。
- 描述你做了什么操作触发的。
- 显示出错的那段代码。
- 让 AI 在这个基础上修复。
用补丁方式，保留了已经验证过的部分，避免“修复一个 bug 引出两个新 bug”的情况。
6.4 第四步：所有生成的代码都要在浏览器里实测
发布前必须做一遍完整的人工测试，AI 不能替你做。你自己走一遍：
- 打开页面，确认资源加载没有报错。
- 每个按钮、每个交互都要试一遍。
- 把窗口拉大、缩小，看布局有没有崩。
- 刷新页面，确认状态有没有正确重置。
6.5 第五步：沉淀“项目提示词备忘”
这个步骤很多人忽略，但它的价值最高。当你把一个项目的提示词调通后，把整段对话、关键提示词、踩坑记录保存下来。下次做一个类似项目时，直接把它们整理成一套模板，成体系地复用。
这次测试我用的提示词文本就非常短，但最后四个模型的差异已经足够说明问题。如果你希望稳定获得高质量结果，需要的不是更长的提示词，而是更清楚的需求拆解、验证路径和补丁策略。
7. 现在，如果你也想做一次自己的 AI 横评
前面讲的是我的方法和结果。但我不希望你只是看完就结束。我觉得 AI 横评这件事，最重要的价值是建立自己的判断坐标系，而不是借用别人的结论。因为你真正要落地的场景、设备、用户，和我的测试环境必然不同。
7.1 按这个清单准备你的测试
- 准备 3 到 5 个模型，能力侧重最好不同。
- 准备两到三个任务：一个偏逻辑（比如让模型写一个排行算法），一个偏视觉（比如生成一个可视化图表），一个偏交互（比如网页小游戏）。
- 统一提示词，用“角色 + 任务 + 输出要求 + 边界条件”的结构。
- 准备相同的运行环境，比如同一台电脑、同一个浏览器版本。
- 记录每个模型的生成速度、代码完成度、第一次运行成功率、修改成本。
你在本地测试后会发现，某一个模型在你这台电脑、这个任务上表现特别好，换一个任务可能完全反转。这就是横评里最珍贵的信息：没有“万能模型”，只有“合适场景”。
7.2 用这五个信号快速判断一个 AI 生成结果的好坏
如果不看代码质量，只看结果，你可以用五个信号做快速判断：
- 首屏能不能直接看到内容？白屏意味着大概率有资源加载或语法错误。
- 交互操作有没有即时反馈？按了按键、点了鼠标，画面有没有立刻变化。
- 核心功能有没有完成闭环？比如“放置方块”是否真的出现了一个方块，且可以持续增加。
- 报错信息重不重要？遇到崩溃时，控制台报错是否说得清楚。
- 二次修改需要多大成本？是改一个参数就生效，还是要重写函数。
7.3 最终一句话收货
这次的横评让我想明白了一件事：AI 写代码的真实价值，不是替你完全解决生产问题，而是把原本需要几个小时从零搭建的雏形，压缩到几分钟就能看到一个能跑的原型。它负责把“从无到有”变容易，你负责把“从有到好”变靠谱。
如果你手头有一个小游戏、互动页面或工具站的想法，不要再去翻教程从零学起了。打开任何一个模型，把需求拆成我能记住的最小步骤，让 AI 先给你一个能点、能看、能跑的版本。然后，你再一步步把它打磨成你想要的样子。
这才是大模型时代，普通开发者和创作者最容易抓住的杠杆。
