同一提示词实测三大AI：谁生成的三维沙盒Demo更可玩？

这轮横评的思路很简单用完全相同的提示词让三个AI模型分别生成一个网页版的“我的世界”风格3D沙盒Demo然后把生成结果放到同一套标准里看。参与测试的是ds v4 pro 0813、flash和kimi k3任务不是“谁能生成更多代码”而是“谁生成的代码真的能打开、能操作、能继续改”。先说结论。三个模型都能生成一份HTML文件但第一轮生成的可用度差别很大集中表现在三件事上代码是否完整、打开后是否直接报错、鼠标和键盘交互是否真实可用。如果只是写一个静态页面三个模型差距不大一旦要求“可运行的游戏Demo”模型对复杂约束的理解能力立刻拉开距离。这篇文章会把横评的完整思路拆开来讲。包括为什么用同一份提示词、提示词里每一项约束到底在限制什么、三个模型各自的偏向、怎么复现这轮测试以及生成结果翻车时优先排查哪里。1. 横评先定标准不然结果没法对比1.1 为什么要用完全相同的提示词AI写代码这件事输出质量和提示词的关系非常大。同一个模型提示词里多写一句“使用Three.js”生成结果可能从原生Canvas风格直接变成3D场景多写一句“不要外部依赖”输出文件又会完全不一样。所以跨模型对比必须控制变量。给ds v4 pro 0813用A提示词给flash用B提示词给kimi k3用C提示词最后说“谁更强”这没有意义。我把提示词固定成一份文本文件三个模型一字不改直接粘贴。这样能看出模型本身对同一语义的还原能力而不是测试我写提示词的水平。1.2 结果判断不能只看“能不能打开”第一轮测试最容易踩的坑是页面能打开就认为生成成功。实际上很多HTML文件打开后是白屏控制台里全是红色报错或者场景渲染出来了但点击没有反应按WASD不动左键右键没有方块操作。我这次按五个维度记录结果判断维度具体标准可启动生成的HTML能在浏览器里直接打开不依赖本地服务器不报致命错误可操作鼠标能拖拽视角键盘WASD和空格有响应左键右键功能生效可理解代码结构清晰关键函数有注释后续能继续改可修复出问题时把报错信息丢回给同一个模型它能针对性修改可扩展想换方块类型、改地图大小、加音效代码里能快速定位改动点这五条比“生成速度”“参数规模”更实际。因为对普通开发者来说拿回来的代码能不能在真实浏览器里跑起来才是第一位。2. 三个模型在这个任务里的定位差异2.1 ds v4 pro 0813代码完整度优先这轮测试里ds v4 pro 0813给我的第一感受是生成完整HTML文件时结构感更强。文件末尾能正常收尾脚本标签完整闭合不会出现“代码生成到一半突然停住”的情况。对于“网页版我的世界”这种任务代码完整性非常关键。因为这类Demo通常需要三个部分页面HTML结构、CSS样式、Three.js场景脚本。任何一个部分被截断页面就会直接失败。另外它对“方块放置和破坏”这种空间运算理解得更直接。生成的结果里射线检测和网格对齐逻辑相对完整不会出现“放置的方块飘在半空中”这种夸张错误。2.2 flash轻量候选但不要期待全功能flash这类模型通常主打更快的生成速度和更低的资源占用。在这轮“网页版我的世界”任务里它能把基础的地面和方块渲染做出来但如果提示词里要求的功能项太多它容易做出“简化版”。我观察到的典型情况是地面有了视角能转了但鼠标左键和右键的功能没有绑定或者移动逻辑还在跳跃功能被吞掉了。不一定每次都这样但任务复杂度越高简化现象越明显。如果你只是想快速生成一个能看效果的3D页面flash够用。如果要做一个相对完整的交互Demo就需要多轮对话来补功能而且每补一轮都要重新验证前面已经能跑的代码有没有被改坏。2.3 kimi k3长对话修复能力是亮点kimi k3在“首轮生成完整度”上没有明显压倒性优势但有一件事给我的印象很深多轮修复时它更擅长顺着上下文调整。具体表现是你把浏览器控制台的报错直接粘贴给它它能快速定位到问题代码块而不是重新把整个文件生成一遍。重新生成整个文件在Demo开发里是一个很大的陷阱因为模型每次重新输出都可能改变原有逻辑甚至丢失之前修好的内容。如果你的工作流本来就是“生成后不断调试”kimi k3这种对话式修复能力会省很多事。反过来如果你只想拿一个一次成型的结果那么首轮生成的完整度更重要。3. 我给三个模型用的同一份提示词是什么3.1 提示词全文这轮测试我用的提示词如下你是一名资深前端工程师请编写一个“网页版我的世界”风格3D沙盒游戏Demo。 要求如下 1. 使用原生JavaScript和Three.js不依赖其他前端框架。 2. 所有代码必须放在一个HTML文件中可以直接在浏览器中打开运行不需要额外安装依赖。 3. 场景中包含一片由随机方块组成的平坦地面地面大小不少于20x20。 4. 使用第三人称或第一人称视角支持鼠标拖拽旋转视角。 5. 使用键盘WASD控制角色移动空格键跳跃。 6. 鼠标左键放置方块鼠标右键破坏方块。被破坏和放置的位置需要命中检测和方块网格吸附。 7. 至少提供3种不同颜色或纹理的方块。 8. 页面中显示操作提示的HUD移动、跳跃、放置、破坏的按键说明。 9. 不允许引入付费资源、外部字体、外部纹理图片。所有颜色和纹理都通过代码生成或使用内联样式。 10. 代码要完整并对关键函数注释说明。这份提示词不是最长的但每一项都对应一个可验证的功能点。写提示词时最重要的不是字数多而是约束可执行、结果可排查。3.2 每一项约束都在限制什么第一项“原生JavaScript和Three.js”直接决定技术栈。如果不写这个模型可能输出一个纯CSS的伪3D页面或者引入Vue、React等框架打开方式就完全变了。第二项“所有代码放一个HTML文件”是个非常实用的约束。AI生成代码经常出现多文件结构但你拿到的可能只有其中一段代码导致无法运行。强制单HTML文件能最大化保证结果可运行。第三项到第六项是在定义“我的世界”的核心玩法随机方块地面、视角控制、移动跳跃、放置破坏。这些功能缺任何一个Demo都会变成“只是一个3D场景”而不是“可以玩的沙盒”。第七项“至少3种方块”是为了方便对比模型对颜色、材质、纹理生成的能力。第八项HUD提示则是测试模型能不能把游戏内UI和场景渲染放在同一个页面里协同工作。第九项“不允许外部资源”很关键。如果模型生成了一个依赖外部图片纹理的代码本地打开时会因为跨域或资源加载失败而黑屏排查起来很浪费时间。3.3 为什么“单文件”和“无外链”要一起写单独写“单HTML文件”模型可能还是会用网络字体、网络图片、CDN的外部JS库。网络环境不稳定时页面要么加载极慢要么直接失败。所以我同时要求“所有颜色和纹理通过代码生成或使用内联样式”。这样生成结果不依赖任何外部资源任何一台电脑、任何一个浏览器只要打开文件就能跑。这轮测试里能首轮做到这一点的模型后续排查成本明显低很多。一旦页面白屏问题基本集中在JavaScript运行时报错而不是资源加载失败。4. 实测结果同题不同命4.1 第一轮生成谁的代码能直接用第一轮生成完我做了同样的操作把代码保存为HTML文件打开浏览器按F12看控制台。ds v4 pro 0813生成的版本页面能正常加载Three.js场景成功渲染。地面上有随机颜色的方块鼠标拖拽视角能用WASD移动也能跑起来。左键放置方块和右键破坏方块在我的测试环境下可以正常工作。第一轮就具备完整可玩性这在复杂Demo生成里并不常见。flash生成的版本地面和场景能渲染出来但左键和右键没有绑定任何操作。我在页面上点击方块没有反应。这在第一轮结果里属于“能看不能玩”需要进入第二轮修复。kimi k3生成的版本首轮结果介于两者之间。场景能渲染视角能转移动能用但方块拾取和放置的命中判断有点粗糙。点击地面时偶尔会出现方块放置位置不准确的问题需要继续调整。4.2 交互操作谁更像“我的世界”而不是“静态截图”“网页版我的世界”最容易被忽略的难点不是渲染一堆方块而是“射线检测”和“网格对齐”。简单说玩家点击屏幕上的一个像素点需要从相机方向发射一条射线判断射线命中了哪个方块然后把新方块放在命中面的相邻网格位置。这一步如果实现得粗糙就会出现“点击前方地面方块却放在角色脚下”的现象。这轮测试里ds v4 pro 0813实现的命中逻辑基本可用。左键放置时新方块会出现在被点击面的外侧不会嵌入已有方块。flash则需要补全整个点击交互。kimi k3能实现放置和破坏但在边缘方块上操作时网格判定偶尔会偏。交互操作是否稳定直接决定Demo的体验。你不可能要求一个网页Demo达到商业游戏那样的操作手感但至少要做到“点哪放哪点哪挖哪”。4.3 报错处理谁在第二轮纠错里更顺第一轮生成不完美并不代表失败。真实开发过程里AI生成代码几乎总会进入修复轮次。关键在于把报错信息丢回给模型之后它能不能快速改对。我分别把flash缺失交互操作的反馈、kimi k3网格判定不准的反馈发回给各自的模型要求修复。flash在第二轮补上了鼠标点击事件但新的代码里出现了变量命名冲突页面直接报错。第三轮才恢复正常。kimi k3在修复网格吸附问题时能针对我指出的位置调整参数没有大范围重构代码。ds v4 pro 0813第一轮已经可以玩第二轮我让它增加更多方块类型改动也很顺利。所以说首轮生成完整度高不代表后续修改也优秀首轮表现一般的模型也可能在对话式修复里越改越好。这也是为什么横评不能只看一次输出。5. 复现一次完整横评的步骤5.1 准备测试环境任何浏览器都行建议用Chrome或Edge方便按F12看控制台报错。需要能在本地保存HTML文件并建议准备一个本地静态服务器。因为有些版本的Three.js或浏览器策略直接双击打开文件时脚本加载会被限制。如果你只是为了测试最基础的打开效果直接双击HTML文件也可以。但我建议统一用本地静态服务器更接近真实环境。python -m http.server 8080在HTML文件所在目录执行这条命令然后浏览器访问http://localhost:8080/文件名.html即可。端口可以根据自己环境调整关键是避免文件路径里的特殊符号或中文目录带来的加载问题。5.2 统一保存提示词和输出先把提示词存成prompt.txt三个模型共用这一份。然后分别为三个模型建立单独目录compare/ ├── prompt.txt ├── ds_v4_pro_0813/ │ └── index.html ├── flash/ │ └── index.html └── kimi_k3/ └── index.html这样做的目的是保持过程可追溯。每次生成结果都保存成带时间戳的文件方便对比不同轮次的改动。index_v1.html index_v2.html index_v3.html不要覆盖旧文件。模型在修复过程中可能出现“修好A功能弄坏B功能”的情况只有保留历史版本才能快速回退。5.3 按统一清单验收每次拿到新版本不要光看画面按以下顺序检查打开页面后控制台有没有红色报错。场景里有没有地面方块方块数量是否足够。鼠标拖拽视角是否旋转。按W、A、S、D角色是否移动。按空格角色是否跳跃。左键点击地面或方块是否能放置新方块。右键点击方块是否能删除方块。HUD提示是否显示按键说明是否清晰。每一条都记在表格里标注“通过”“不通过”“部分通过”。通过率不是唯一指标还要看报错信息是什么、卡在哪一步、修复一轮需要多少轮对话。5.4 第二轮修复一次只改一个问题进入修复环节后最容易犯的错是“一次性反馈所有问题”。模型会尝试同时处理多个修改点结果可能把原本正常的代码也改乱了。我的习惯是一次只反馈一个最严重的问题。比如“左键点击没有反应”然后附上控制台报错或者描述清楚操作步骤。等模型修完验证通过再反馈下一个问题。如果模型输出的是整段新代码先对比新旧代码差异确认它改动的范围。避免直接替换整个文件否则可能引入新的不一致。6. 常见翻车点和排查顺序6.1 生成页面黑屏或白屏优先打开控制台看是否有红色报错。没有报错再看网络请求面板确认Three.js脚本是否加载成功。如果模型用了外部CDN链接但网络不可用或跨域受限页面就会白屏。排查办法是用本地文件替换外部脚本或者要求模型改为“不使用外部资源”。这轮测试里“所有代码放一个HTML文件”的约束能直接把这类问题挡在门外。6.2 渲染出来了但键盘移动没反应先点击页面确保焦点在页面上然后再按WASD。如果还是没有反应检查代码里事件监听是否绑定在document或window上。有时模型把事件绑定在了一个特定元素上而那个元素没有获取焦点。比较隐蔽的问题是移动逻辑写在了动画循环里但动画循环没有启动。Three.js场景经常有requestAnimationFrame(animate)这行代码一旦缺失渲染画面虽然还在但角色移动和相机更新都不会执行。6.3 放置和破坏方块不准确大部分情况是射线检测的判定范围有问题。常见错误是只检测了“射线与方块相交”但没有记录“命中面的法线方向”导致放置方块的位置计算错误。这类问题很难通过提示词一次解决需要手动检查代码里的intersects[0].face.normal或intersects[0].face.materialIndex相关逻辑。如果模型没有提供网格吸附函数可以要求它补充一个类似getGridPosition的辅助函数对坐标取整后再加上法线方向偏移。6.4 功能都对但画面太“素”代码能运行不假但视觉效果离“我的世界”差距很大。这时候不要重新生成建议单独提一个视觉增强需求增加草地方块、泥土方块、石头方块的纹理差异或者给方块添加边缘线。模型的纹理处理能力参差不齐但基本都能做到“不同方块使用不同颜色”。如果要求更高可以继续要求它用代码生成简单纹理比如随机噪点、渐变条纹。尽量不要要求“引用官方材质包”这超出了AI生成代码的合理边界。6.5 输出被截断或代码不完整长代码生成任务里输出截断非常常见。现象是HTML文件缺少闭合标签JavaScript函数没写完或者Three.js脚本在中间断掉。遇到这种情况不要重新生成整个文件。直接在同一个对话里要求“从上一次中断的位置继续输出”然后把生成结果复制到文件末尾。如果模型重新生成整个文件很可能把已经稳定的逻辑改乱。注意生成代码越长的任务越要保留每一版文件。不要用“index.html”一个名字反复覆盖至少保留index_v1.html、index_v2.html这样的独立版本。7. 横评之外的提醒提示词、边界和模型选择7.1 提示词才是横评的真正变量这轮测试做下来我最深的感受是AI写代码的水平上限很大程度由提示词决定。你不说“鼠标左键放置方块”模型就默认只做视角浏览你不说“不需要外部资源”模型就可能引入一堆CDN依赖。提示词工程不是背固定模板而是“把需求翻译成模型能验证的指令”。每一条要求最好都能在运行结果里被检查。比如“至少3种方块”就是可验证的你打开页面数一下颜色就知道满足没有“更酷的画面”则不可验证模型只会凭感觉瞎猜。7.2 别把Demo当成完整游戏三个模型生成的“网页版我的世界”本质上都是技术演示距离真正的游戏《我的世界》还差得非常远。没有存档、没有合成、没有怪物、没有多生物群系、没有重力优化、没有性能优化。如果你只是想学习Three.js、体验AI辅助开发这个Demo完全够用。如果你想把它扩展成一个可以长期玩的游戏对应的工程复杂度远超单个模型能在一次输出里完成的工作量。后续大概率需要自己维护代码或者把任务拆成若干个子模块分别生成。7.3 模型版本和能力会变化别把结果当永久结论ds v4 pro 0813、flash、kimi k3这些版本号代表着某个时间点的模型快照。模型厂商随时可能更新能力、调整行为。你拿同一个提示词下周或下个月重新测试结果可能完全不同。所以这篇横评给你的不是“谁永远更强”的答案而是一套可以自己复现的方法。当你拿到一个还没用过的新模型完全可以用同一份提示词跑一遍再判断它适不适合你的任务。7.4 按场景选模型而不是按名气选模型这轮测试之后我对选模型这件事有了更明确的标准需要一次生成完成度高的长代码优先看ds v4 pro 0813这类偏向完整输出的版本。只想要一个快速原型对交互完整度要求不高flash这类轻量模型够用速度更快。工作流依赖多轮调试和持续修改kimi k3这类对话修复能力强的模型更顺手。更重要的是同一个模型也常有多档版本。日常问答版本、纯文本版本、编程专用版本在代码任务上的表现差异可能很大。执行具体代码生成任务前先确认你用的是哪个版本、日期是哪一天的。建议把自己常用的提示词模板整理成一个文件遇到新模型时固定跑几个样例。这样比“看宣传、看榜单、看别人评论”更能判断模型是否适合你的真实场景。这次横评的复现方法已经留在这里了。你完全可以拿同一份提示词自己找几个模型跑一遍。跑完之后你会发现决定结果上限的往往不是模型名字而是你提供的约束条件够不够具体、能不能被逐项验证。