如果你把几十行需求压缩成一句话，再让不同模型生成同一个“MC 页游”，你会发现评价标准会变得特别直接：谁给的页面能打开、能动、能玩，谁在“一句话生成”这个场景里就更占优势。拿 Mimo 和 DeepseekV4pro(high) 这类模型对比时，这种体感差别往往比复杂的 benchmark 更明显，因为小程序 demo 对代码完整性、运行依赖和脚本逻辑的要求几乎是硬性的：缺一个文件、引用一张外部图片失败、键盘监听没绑定对，都会直接翻车。与其反复争论“谁更强”，不如把这个问题拆开：先理解为什么一句话 MC 页游适合做模型对比，再聚焦如何写提示词、如何验收代码、如何把生成结果改造成一个可维护的工程。
1. 为什么“一句话 MC 页游”最容易暴露模型差异
1.1 一句话需求的表面是“简单”，实际是“信息密度高”
单独看“做一个 MC 风格页游”这句话，人类开发者会觉得信息严重不足，但 AI 模型恰恰擅长用自己的训练知识补全：它知道 MC（Minecraft）有草地、泥土、矿石、玩家、背包、合成等元素，也知道“页游”意味着浏览器打开就能玩，于是会主动选择 HTML + Canvas + JavaScript 的技术组合。
当这句话被压到“一句话 MC 页游”时，模型之间的差异就从“能不能写代码”转移到了“能不能在缺少明确规格的情况下，补全一个能跑的完整闭环”。这其实是在测试模型对常识性需求的补全质量，而不是测试谁的 API 调用记得更熟。
1.2 生成结果好不好，不在于代码多不多，而在于交付闭环
不少模型写长代码能力很强，但生成一个完整 HTML 页面时，容易把代码拆成两个甚至三个文件，例如index.html、game.js、style.css分开输出。问题在于：
- 用户复制到本地时，经常只复制了其中一个文件。
- 模型没有提醒文件需要放在同一目录。
- CSS 或 JS 使用了 CDN 外部资源，离线环境直接失效。
“一句话 MC 页游”这类任务之所以适合评测模型，是因为它要求模型输出独立的、可直接开箱运行的完整文件。谁能够在单个 HTML 文件内完成样式、脚本和游戏逻辑的闭环，谁在真实使用中的“省心程度”就会明显更高。
1.3 一句话需求背后还有一层隐性能力：拆需求
一个好的模型收到“一句话 MC 页游”，往往不会直接把它理解成“做一个完整 3D 沙盒游戏”，而会默认收缩成一个可演示、可交互的 2D 像素风格 Canvas 游戏原型。这种“需求收敛能力”决定了代码的可行性。
模型如果总是追求完整复刻 Minecraft 的合成、背包、挖掘、生物系统，输出代码会非常长，且很可能中途被截断，或者隐藏大量未实现调用。反之，能把需求收敛成“地图 + 角色移动 + 自动收集 + 得分”的模型，更容易交出一份用户可以直接保存运行的结果。
2. 先别急着对比模型，先学会把一句话需求写准
2.1 一条可以直接测试的提示词
先把一个最小但要覆盖核心体验的提示词写出来。下面这段在大多数支持网页代码生成的模型中都能直接使用：
请为我在一个 HTML 文件中生成一个“MC 风格页游”的可运行 Demo。 要求： 1. 不依赖任何外部图片或 CDN，所有素材都用 Canvas 绘制； 2. 用方向键或 WASD 控制玩家移动； 3. 地图是一块 30x18 的方块平面，里面有草地、泥土、煤矿和钻石矿； 4. 玩家走过煤矿和钻石矿时自动收集并加分； 5. 左上角实时显示当前分数； 6. 关闭自动再生矿物的逻辑，或每隔 1.5 秒随机在非玩家位置生成一个新矿物； 7. 代码必须完整，不需要我再补充其他文件，直接在浏览器打开就能运行。2.2 提示词里的每个约束都有用途
| 约束内容 | 存在的意义 |
|---|---|
| 不依赖外部图片或 CDN | 避免模型引用失败资源，保证离线可运行 |
| 所有素材用 Canvas 绘制 | 让输出收敛到纯 JS 逻辑，减少图片路径问题 |
| 用方向键或 WASD 控制 | 统一键盘事件逻辑，降低测试成本 |
| 玩家走过对应方块自动收集 | 省去复杂的碰撞、挖掘和背包逻辑，最快形成游戏反馈 |
| 左上角显示分数 | 让玩家立刻看到游戏状态变化 |
| 每隔 1.5 秒补充矿物 | 防止矿被采完后页面变成空地图 |
| 不需要我补充其他文件 | 强制模型给出单文件解决方案 |
这里有一个很关键的点：提示词并不是越长越好，而是每个字都在压缩模型的自由度，让它的“合理补全”更接近你真正要的可运行目标。
2.3 一句话和结构化提示词怎么取舍
你当然可以直接用“一句话 MC 页游”来测模型，这种极端简短的输入非常适合看模型的“默认脑补”水平。但如果你要把结果用于实际开发，我建议还是把关键目标写进提示词。
原因很简单：模型的默认生成策略偏向“通用且安全”，但它不知道你接下来要在手机上看，还是要继续改代码。如果你没有提“自动更新矿物”，模型可能让矿物一次性分布后地图逐渐空掉；如果你没有提“不需要外部资源”，模型可能使用网上素材图，导致本地打开时一片空白。
因此，我的做法通常是先给一句话让模型自由发挥一次，再根据输出缺陷补充第二版结构化提示词。这样既能感受到模型原生的创意和实现习惯，也能把它纳入可控的开发流程。
3. 生成目标长什么样？先定好验收标准
3.1 目标产物形态
在做对比之前，应该先确定一个“基准产物”。按照前面提示词，一份合格的 MC 页游 Demo 应该满足：
- 一个
.html文件保存后就能用浏览器打开； - 页面中有一个可供玩家移动的方形角色；
- 地图铺满 30x18 的方块，看起来有像素沙盒风格；
- 煤矿和钻石矿分散在地图中，玩家经过后自动计分；
- 矿物不会永久耗尽，后台会定时补充；
- 不需要安装 Node.js、不需要启动任何服务、不需要联网。
这类基线任务避免了模型之间的“生态位差异”。因为评测的是前端小游戏生成能力，而前端页游生成恰好是所有模型都会去训练的基础能力。
3.2 从哪些维度验收
| 验收点 | 说明 |
|---|---|
| 打开是否报错 | 控制台有没有 JS 语法错误、大小写错误、空指针调用 |
| 角色能否移动 | 键盘事件有没有正确绑定，目标是否被覆盖在非交互元素中 |
| 方块能否被“采集” | 判定玩家与方块的格子是否一致，得分会不会重复累计 |
| 页面是否美观 | 颜色、布局、界面层级是否接近 MC 像素风格 |
| 单文件是否完整 | 有没有把 HTML/CSS/JS 分成多个文件，或链接到外部资源 |
| 代码是否可读 | 函数是否按区域划分， |
