如果只看一句“能运行”，这三份代码都过关了。

但真正打开浏览器，玩上几分钟，再把代码翻一遍，差距很快就出来了：有的版本已经接近一个可以交付的小产品，有的版本胜在短小精悍，也有的第一眼很漂亮，底层却埋着一些典型的游戏开发问题。

这次我把目录里的三个单文件 HTML 游戏都实际跑了一遍，统一用 1280×900 的浏览器窗口截图，并从画面、玩法、代码结构、运行稳定性和后续维护成本几个角度做了一次对比。

先说结论：GPT-5.6 Sol 完成度最高，Kimi K3 的原型效率最好，GLM-5.2 的视觉包装最抢眼，但工程稳定性还需要补课。

说明：本文只比较当前目录中的三个具体样本，不等同于对模型全部能力做绝对排名。一次生成结果会受到提示词、上下文、工具链和是否允许反复修改等因素影响。

我怎么测的？

我使用提示词是：

请用 HTML5 + JavaScript（Canvas）实现一个简化版的经典坦克大战游戏，参考红白机（FC）《Battle City》的核心玩法：

一、基本功能

玩家控制一辆绿色坦克，方向键移动，空格键发射子弹

敌方 AI 坦克自动巡逻并随机发射子弹

砖墙、钢墙、草丛、水域、基地（老鹰）等地形元素

子弹可击毁砖墙，无法穿透钢墙

基地被摧毁则游戏失败

玩家有 3 条生命

二、画面与表现

俯视角 2D，像素风格

画布分辨率：416 × 416

每个格子 16×16 像素

使用简单色块即可，不依赖图片资源

三、技术细节

使用 requestAnimationFrame实现游戏循环

使用对象（Player、Enemy、Bullet、Wall）管理游戏实体

碰撞检测基于矩形 AABB

代码结构清晰，便于后续扩展（如多关卡、道具）

四、可选增强（如空间允许）

敌方坦克被击杀后随机掉落道具（如升级子弹、加生命）

玩家子弹等级系统（单发 → 双发 → 加速）

简单音效（用 Web Audio API）

五、输出要求

给出单个 HTML 文件，直接浏览器打开即可运行

代码中加入必要注释，方便理解

先给出整体结构说明，再给完整代码

为了尽量公平，我没有只盯着截图看，而是做了四件事：

1. 直接用 Chrome 打开三个 HTML 文件，确认页面能够独立运行；
2. 检查移动、射击、敌人刷新、基地判定、生命值和重新开始等核心流程；
3. 阅读主要类、碰撞逻辑、游戏循环、地图生成和输入处理代码；
4. 记录代码规模、功能完整度，以及那些短时间试玩不一定能发现的问题。

三个版本都使用 416×416 的 Canvas，都是纯前端单文件实现，没有依赖外部图片素材。这个前提很重要，因为它考验的不只是“会不会写 Canvas”，还考验模型能不能把游戏状态、实体关系和交互细节收拢到一个可维护的结构里。

GPT-5.6 Sol：最像一个认真做完的小产品

GPT-5.6 Sol 版：固定关卡、像素化地形、完整 HUD，整体观感最接近传统 FC 坦克大战。

GPT-5.6 Sol 版给我的第一感觉是：它不满足于“画几辆坦克互相打”，而是在努力把一局游戏该有的东西补齐。

这份实现一共约 1033 行、34 KB，是三者中代码量最大的。大并不天然代表好，但它确实把更多篇幅用在了有效功能上：砖墙、钢墙、水面、草丛和基地都有独立规则；玩家有三条命、受击重生和短暂无敌；敌人有数量上限和整波胜利条件；子弹能互相抵消；击毁敌人还可能掉落升级或加命道具。

更难得的是，它考虑了手机操作。桌面端可以用方向键和空格，窄屏下会出现触控方向键和开火按钮。对一个准备拿出去展示的网页小游戏来说，这个细节很加分——很多“能跑”的 Demo，一到手机上就只剩下围观。

从代码组织看，它把 Player、Enemy、Bullet、Wall、PowerUp 和 Game 分开，地形规则也集中管理。地图采用字符数组描述，而不是把几十个墙块坐标散落在代码里。以后想换第二关，至少有一条比较清晰的路。

游戏循环使用 dt（两帧之间的时间差）计算移动距离，这意味着 60Hz 和 144Hz 屏幕上的速度更容易保持一致。它还处理了窗口失焦后清空按键、玩家子弹数量限制、敌方子弹清场、音频初始化失败不影响游戏等边角问题。单看这些细节，就能看出它更偏“工程交付”思路。

它的优点可以概括为：

• 玩法最完整，道具、音效、爆炸效果、胜负状态都在；
• 响应式布局和触控按钮，对移动端最友好；
• 固定地图可控，碰撞和出生点更稳定；
• 数据驱动的地图与地形规则，后续扩展相对自然；
• 受击无敌、子弹互撞等细节，明显经过规则层面的思考。

当然，它也不是没有代价。最大的问题是所有内容仍然塞在一个 HTML 里，1000 多行之后，继续加关卡、Boss 或更多道具会越来越难维护。敌人 AI 也还是随机转向和随机射击，玩久了会显得机械。除此之外，它默认直接开战，缺少一个正式的开始界面，仪式感反而不如 Kimi K3。

如果让我选一个版本继续开发，我会选它。原因不是它画得最花，而是它已经把最容易出事故的底层骨架搭得比较稳。

Kimi K3：368 行做出完整原型，效率真的高

Kimi K3 版：画面朴素，但固定地图、开始界面、道具和音效都保留了。

Kimi K3 版只有约 368 行、16 KB，不到 GPT-5.6 Sol 代码量的一半。打开文件时我本来担心它只是一个“坦克能动”的极简样例，实际看完发现，它把核心闭环压缩得相当不错。

方向键移动、空格射击、18 辆敌人、基地保护、砖墙和钢墙、水域与草丛、生命值、得分、升级道具、加命道具、胜负判定、音效和重新开始，基本都在。它还有一个很有 FC 游戏味道的开始遮罩，按 Enter 后再进入战斗，体验上比“网页一打开敌人已经冲过来”更自然。

它同样采用基于时间差的移动，而不是简单地每帧加固定像素，所以基础运行稳定性是合格的。固定地图也让出生点和道路更可控。更值得肯定的是，这么短的代码里仍然保留了类结构，并且处理了敌我子弹相撞。

但 Kimi K3 的短，也带来了一些明显取舍。

首先，坦克只有 14×14 像素，画面信息比较轻，敌人和玩家在大屏幕上显得偏小。其次，页面没有触控操作区，手机端基本没法认真玩。大量状态直接放在全局变量中，后续功能一多，变量之间的耦合会迅速上升。

我还在升级射击逻辑里发现了一个很典型的小问题：玩家等级达到 2 级后，代码连续调用两次 shoot()，想实现双发；但第一次射击会立刻进入冷却，第二次调用随即被冷却条件拦住。结果就是“代码看起来写了双发，实际只打出一发”。这类 Bug 很适合提醒我们：AI 生成代码不能只读分支，还得真的走一遍状态变化。

它的优点是：

• 代码最短，核心玩法覆盖率却不低；
• 固定地图、时间步移动和开始界面，让原型比较稳；
• 有音效、掉落物和子弹对消，不是纯演示壳子；
• 阅读成本低，适合教学或快速二次开发。

它的不足也很明确：

• 没有移动端触控；
• 视觉细节和角色辨识度偏弱；
• 全局状态较多，继续扩展会吃力；
• 二级“双发”存在冷却逻辑冲突；
• 缺少更完整的受击保护和工程化验证入口。

如果任务是“一个小时内做出能玩的 MVP”，Kimi K3 很讨喜。它不是最豪华的版本，却是三份代码里最能体现“少写但别漏掉主循环”的那一个。

GLM-5.2：第一眼最亮，随机地图却是一把双刃剑

GLM-5.2 版：渐变背景和卡片式容器很醒目，地图每次启动都会变化。

GLM-5.2 版约 848 行、29 KB。三者放在一起，它是第一眼最容易吸引普通用户的版本：蓝紫渐变背景、黑色游戏面板、简洁的中文状态栏，截图发出去很有“作品展示”的感觉。

它也使用了比较清晰的面向对象结构，坦克、玩家、敌人、子弹、墙体、地形和基地都拆成了类。敌人总数设置为 20，地图中的砖墙、钢墙、水域和草丛每次随机生成，所以每次刷新都不完全一样。这种变化感很适合现场演示。

问题也恰恰从“随机”开始。

地图生成时，障碍物没有做重叠校验，也没有为玩家出生区、敌人出生点、基地防线和关键通道预留安全区域。于是随机墙块可能叠在一起，也可能把出生点或路线堵得很难走。敌人刷新时同样没有检查目标位置是否已经被墙体或另一辆坦克占用。随机带来了变化，但没有约束的随机，也把关卡设计变成了碰运气。

另一个更关键的问题是移动逻辑按“每帧固定像素”推进，没有使用时间差。简单说，同一段代码在不同刷新率、不同性能的设备上，游戏速度可能不一样。对普通网页动画，这个问题未必立刻暴露；对需要碰撞和射击节奏的游戏，它会直接影响手感和公平性。

另外，这一版没有音效、道具、子弹对消、触控按钮和受击无敌。玩家复活后如果附近正好有敌方子弹，可能很快再次掉血。视觉层做得很积极，但底层规则还停留在“可演示”的阶段。

它的优点包括：

• 页面包装最醒目，适合截图和演示；
• 类结构直观，新手比较容易顺着读；
• 随机地图有新鲜感；
• 基础移动、射击、基地、得分和胜负流程齐全。

主要短板是：

• 按帧移动，设备刷新率会影响游戏速度；
• 随机地图缺少重叠、出生点和可通行性约束；
• 敌人生成位置没有充分碰撞检查；
• 没有音效、道具、触控和复活保护；
• 代码量不算少，但功能密度低于 Kimi K3。

这个版本很适合当作“视觉原型”，但如果要继续做成稳定游戏，我会先重写时间步和地图生成规则，再往上加功能。

横向对比：三个模型分别赢在哪里？

如果把三个版本放到真实项目里，我的选择会很直接：

• 要继续做产品：选 GPT-5.6 Sol 作为底座。
• 要快速教学或验证玩法：选 Kimi K3，代码更容易讲清楚。
• 要做一张好看的演示截图：GLM-5.2 很合适，但别急着直接上线。

这次对比，真正值得技术人员记住的五件事

第一，“能运行”只是最低门槛，不是交付标准。 游戏有没有稳定时间步、出生保护、输入清理和明确状态机，决定了它能不能从 Demo 走向成品。

第二，代码短不等于能力弱。 Kimi K3 用三百多行覆盖了相当完整的主循环，说明结构压缩得好，往往比机械堆代码更有价值。当然，压缩之后也更容易藏住状态类 Bug。

第三，随机不是天然高级。 随机关卡至少要有重叠校验、安全区、连通性和出生点检查。否则所谓“每局不同”，可能只是“每局坏法不同”。

第四，前端小游戏也要考虑设备差异。 采用 requestAnimationFrame 并不代表速度天然一致，移动距离仍然应该和真实时间挂钩。

第五，提示词里要写验收条件。 与其只说“帮我写一个坦克大战”，不如明确要求：固定画布尺寸、移动端控制、基于时间的运动、出生点保护、敌人数量上限、地图可通行性检查，以及至少一轮自动化状态测试。

最后一句

这三个版本最有意思的地方，不是谁“秒杀”谁，而是它们展现了三种很不同的生成倾向：

GPT-5.6 Sol 更像一个会先想交付清单的工程师；Kimi K3 更像一个熟练的原型开发者，先用最短路径把闭环跑通；GLM-5.2 更像一个重视第一印象的前端创作者，愿意先把舞台搭漂亮。

如果只是周末做个小游戏，三份都能带来乐趣。但如果代码要交给同事、交给用户，甚至准备继续迭代，那么真正拉开差距的，永远是那些截图里看不见的东西：时间步、状态管理、边界条件，以及验证。

而这，也正是今天用 AI 写代码时，我们最不能外包给 AI 的部分。