我先给大家一个判断这类“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 srchttps://cdn.jsdelivr.net/npm/three0.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 先给你一个能点、能看、能跑的版本。然后你再一步步把它打磨成你想要的样子。这才是大模型时代普通开发者和创作者最容易抓住的杠杆。 AI大横评：相同提示词生成网页版我的世界，四种模型能力分层
我先给大家一个判断这类“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 srchttps://cdn.jsdelivr.net/npm/three0.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 先给你一个能点、能看、能跑的版本。然后你再一步步把它打磨成你想要的样子。这才是大模型时代普通开发者和创作者最容易抓住的杠杆。