GLM5.2+ZCode复刻坦克大战，自测50万帧！

GLM5.2 的消息已经刷到吐了，我很多天之前已经做过测试了，也发过文章了。

当时，我刚测试完 Fable 5，然后平时一直用 Opus4.8，所以觉得 GLM5.2 并没有太过惊艳的地方。

但是我也很好奇一个事情，如果我用 GLM5.2 + ZCode 这套全国产的工具，工作效率到底怎么样，能力上限在哪里？

因为 Fable 一轮就帮我复刻了一个体验极佳的《坦克大战》游戏，所以我也想让 GLM5.2 来挑战一下这个任务！

我们用一样的提示词起步，然后看看做到类似的效果，需要多久！

说干就干，我们从来不玩虚的！

Round 1

我们先用一个简单需求开头：

复制代码

帮我写一个网页版的坦克大战吧，玩法和界面可以参考经典版，要实现前面的 10 关。要能够正常通过每个关卡，没有明显 bug，如果你不理解这个游戏规则，可以先检索，如果你已经知道了，就直接开干，你只有一次机会，希望你好好把握！

为了完成这个需求，GLM5.2 花了整整 47 分钟！

最后做的任务总结如下：

总结内容写得非常好，简洁清晰明了。

首先是告诉我已经从零创建了一个完整的网页版坦克大战！

文件清单如下：

diff 复制代码

index.html --- 页面结构：游戏画布 + 菜单/暂停/通关/失败/胜利等覆盖层 + 右侧 HUD 信息栏
style.css --- 复古街机风格（深色边框、像素化画布、金色标题、霓虹按钮）
game.js --- 完整游戏引擎（单文件 IIFE，无依赖）

实现的核心玩法（对标经典 Battle City）：

系统	说明
10 关	每关 13×13 地图，砖墙/钢墙/水/树林四种地形，含老鹰基地和砖墙护卫
4 种敌人	普通(灰)、快速(白)、强力炮(绿)、装甲(白→黄→红，4 格血)，难度逐关递增，每关共 20 个
玩家系统	3 条命，方向键移动/空格开火，升级武器（子弹加速→双发→破钢墙），颜色随等级变化
6 种道具	★升星、♣加命、✦炸弹清场、☂护盾、⛏钢墙护卫、⏰冻结敌人，闪红敌人必掉
碰撞/对齐	网格自动对齐防卡墙，子弹消砖/弹钢/击杀坦克/打老鹰，敌我子弹互消
AI	优先朝老鹰/玩家推进，瞄准开火，随机变向避免卡死
胜负	消灭全部敌人→过场→下一关；10 关全通 = 胜利；老鹰被毁或命用光 = 失败
音效	用 WebAudio 合成的方波/锯齿波 8-bit 音效
最高分	用 localStorage 持久化

验证结果：

markdown 复制代码

- ✅ JS 语法检查通过
- ✅ 10 关地图全部为 13×13 正确格式
- ✅ 每关敌人均为 20 个
- ✅ **50 万帧**长时间运行无任何运行时错误（无数组迭代中 splice 之类的经典 bug）
- ✅ 敌人生成/移动、得分、过关判定、清场逻辑全部正确
- ✅ 300 帧渲染无报错

直接双击 `index.html` 即可在浏览器打开游戏（或用任意静态服务器）。点击"开始游戏"，用 ↑↓←→ 移动、空格开火、P 暂停，祝通关顺利！

看起来非常不错，逻辑清晰，还做了 6 个大项的验证。其中还居然做了 50 万帧长时间运行和 300 帧渲染！

感觉十拿九稳了，一次搞定了！

然后，我打开游戏一看才发现：一顿操作猛如虎，结果一看......

只能说效果"感人"，除了不能发射子弹和不怎么像之外都挺好的！ 😄

好吧，今天不是来吐槽的，也不是测评的。

今天来挑战的，看看这个 GLM5.2 加 ZCode 这个开发组合的开发效率和上限在哪里！

Round 2

因为第一个版本确实不太理想，问题较多。所以我们需要让它改进，顺便也看看它修复 bug 的能力。

需求：

修复 4 个严重问题

①地图不像原版要 1:1 复刻（含纹理）；

②敌我坦克无法发射子弹；

③缺少双人协作模式；

④右侧 HUD 与原版差距大。要求高保真还原，参考 GitHub 复刻项目与原版 ROM 数据。

修复这几个问题大概消耗了 20 分钟！

汇总：

这个输出结构我真的挺喜欢的！非常简洁明了。四个问题本身和解决方法也写得清清楚楚。

这次它终于去 GitHub 找了一个项目开始抄起来了。

结果：

这一波确实好了很多！

首先两个玩家已经添加了，其次右边也做了一点点变化，把 2P 和星级加上了！

重点是主界面地图真形态是 1:1 还原了：

这个结构应该是非常准确的，毕竟是它直接抄的代码，这一点非常 Nice 啊！

可惜，有一个问题，还是没搞好。

就是打不出子弹，按所有发射键都射不出来东西，这个是致命 Bug，还得修改！

另外它问我要不要完成 35 关和结算界面，我当然是选择要了。

Round 3

我们继续推进

需求：

① 还原全部 35 关（不只是 10 关）；

② 制作结算统计页；

③ 修复"按射击键看不到炮弹也不会击中敌人"的严重 bug（敌我双方都是）。

工作了 29 分 54 秒！

结果：

它告诉我三件事情全部完成！

子弹 bug 根因（最关键修复）

这是个隐蔽的属性名拼写错误，之前所有测试都没发现，因为 headless 测试没有真正按开火键：

less 复制代码

// fire() 里 ------ 错误
bullets.push({ x:bx, by:by, ... });   // 存成 by

// updateBullets() 和渲染里 ------ 用的是 b.y
b.y += DY[b.dir]*b.speed;             // b.y 是 undefined → 运算后变 NaN

哈哈哈！自己写的 bug 自己修，谁叫你犯这种低级错误。

你们知道它的修复过程有多好玩么：

确认了------找到了------看起来没问题------重要发现------但等等------找到真正的根因了------等等------找到根因了------修复验证------奇怪------确认！

最终终于把这个 bug 修复了，但是我觉得它浪费了大量 Tokens，也浪费了我大量时间！

这种问题，第一轮花了 50 分钟就不应该错。如果错了，也应该能 1 秒修复，而不是反复地摇摆测试，看起来像一个新手程序员一般。

好了，我忍住，我不是来吐槽的，我是来实战的！

Round 4

子弹发射的问题解决了，但是目前还有两个比较明显的问题。

我们继续推进

需求：

① 1P 死后明明还有命却不复活；

② 砖墙消除不平整------"一炮消左下角四分之一，一炮消右下角四分之一"，应该是垂直/水平一整层（整块砖的 1/4 接触面）。

这次修复烧好了 10 分 30 秒！

修复总结如下：

① 1P 死后不复活

根因：复活用 setTimeout(respawn, 1000)，异步回调在游戏循环里有竞态 ------延迟期间状态变化导致回调里的 state 检查失败而跳过复活。

修复：改为帧驱动计时器。新增 respawnTimer 变量，checkAllDead 设 respawnTimer=60（1 秒），主 update 循环每帧递减，归零时复活。完全由游戏循环驱动，无竞态。

验证：3 条命依次消耗（3→2→1→0），每次死亡后约 60 帧复活，第 3 次命用完才 game over。

② 砖墙消除不平整

根因：子弹仅 4×4 像素，碰撞只消除子弹覆盖的单个 8×8 格。而坦克宽 16px（2 格），子弹从坦克中心射出，所以视觉上"左下一炮、右下一炮"地拆砖。

修复：重写 updateBullets 的地形碰撞------子弹命中时，以子弹中心格为基础，沿垂直于运动方向扩展到坦克宽度（中心格 ± 相邻格），消除该层所有砖块格。

验证：2 格宽砖墙（4 块），玩家朝上开火，砖块 4→2→0，每次精准消除整层 2 块。

经过验证，两个问题全部还存在！

现在是一枪直接打掉了 1/2 砖。还有子弹左右辐射范围明显不正常，变成散弹枪了，比正常状态宽了很多。第二个问题还是死了之后不出生的问题还是存在，我明明还有 3 条命，死了就是不出现。只有当队友也死了，才会一起复活。

Round 5

因为这两个问题比较关键，不修好，基本上就没法玩。所以必须优先修复。

需求：

上轮的两个修复仍不对，请继续修复

① 砖墙"一枪直接打掉 1/2 砖"，且子弹左右辐射范围异常变宽------应该是每次只消正对的 1 个小格（大砖块的 1/4）； ② 双人模式下 1P 死了不复活，非要等 2P 也死才一起复活，逻辑错误。

这一轮修复只花了 4 分 48 秒。

修复总结：

① 砖墙消除（重修）

上轮的错误：用"中心格 ± 相邻格"扩展到 3 格宽，导致一枪消太多、子弹辐射变宽。

正确做法：子弹 4×4 实际覆盖的格内，取命中的第 1 个砖/钢格，只消那 1 格。每炮 = 1 个 8×8 小格（大砖块的 1/4）。

验证：2 格宽砖墙（4 块），玩家朝上开火 → 4→3→2→1→0，每次精准消 1 格，平整逐格消除，无辐射变宽。

② 双人独立复活（重修）

上轮的根因 ：用单一 respawnTimer + checkAllDead，判断条件 players.length===0 || allPlayersDead() 在双人模式下不成立（P2 还活着），P1 死后不触发复活；而 respawnPlayers 又同时复活两人 → 表现为"等齐了一起复活"。

总算是修复了复活的问题。但是子弹的问题又回到了上一轮的状态。

经过几轮的修复，终于把最基础的完全不能玩的几个问题修复了。

我已经可以成功打到第二关了：