GLM5.2+ZCode复刻坦克大战全记录：50万帧压力测试下的AI编程实战与差距
GLM5.2 的消息铺天盖地，其实我在很多天前已经实测过，也分享过详细体验。当时刚试完 Fable 5，而日常一直在用 Opus4.8，所以对 GLM5.2 并没有太惊艳的感觉。
但我特别好奇一件事：如果用 GLM5.2 搭配 ZCode 这套纯国产工具，工作效率到底如何？上限在哪里？因为之前 Fable 只用一轮就帮我复刻出了一个体验极佳的《坦克大战》，这次我决定让 GLM5.2 也来挑战同样的任务！
我们用一模一样的提示词开局，然后看看做出类似效果，需要多长时间。
说干就干，从来不玩虚的。
Round 1
先用一个简单的需求开场：
帮我写一个网页版的坦克大战吧，玩法和界面可以参考经典版，要实现前面的 10 关。要能够正常通过每个关卡，没有明显 bug，如果你不理解这个游戏规则，可以先检索，如果你已经知道了，就直接开干，你只有一次机会，希望你好好把握！
为了完成这个需求，GLM5.2 整整花了 47 分钟！
最后它给的任务总结如下：
总结内容非常清晰，简明扼要：它告诉我，一个完整的网页版坦克大战已经从零创建完毕。
文件清单：
index.html — 页面结构：游戏画布 + 菜单/暂停/通关/失败/胜利等覆盖层 + 右侧 HUD 信息栏
style.css — 复古街机风格（深色边框、像素化画布、金色标题、霓虹按钮）
game.js — 完整游戏引擎（单文件 IIFE，无依赖）
核心玩法对标经典《Battle City》：
| 系统 | 说明 |
|---|---|
| 10 关 | 每关 13×13 地图，砖墙/钢墙/水/树林，含老鹰基地和砖墙护卫 |
| 4 种敌人 | 普通、快速、强力炮、装甲（4 格血），难度逐关递增，每关共 20 个 |
| 玩家系统 | 3 条命，方向键移动/空格开火，升级武器（子弹加速→双发→破钢墙），颜色随等级变化 |
| 6 种道具 | ★升星、♣加命、✦炸弹清场、☂护盾、⛏钢墙护卫、⏰冻结敌人，闪红敌人必掉 |
| 碰撞/对齐 | 网格自动对齐防卡墙，子弹消砖/反弹/击杀坦克/打老鹰，敌我子弹互消 |
| AI | 优先朝老鹰/玩家推进，瞄准开火，随机变向避免卡死 |
| 胜负 | 全灭敌人→过场→下一关；10 关全通 = 胜利；老鹰毁或命光 = 失败 |
| 音效 | 用 WebAudio 合成的 8-bit 音效 |
| 最高分 | 用 localStorage 持久化 |
验证结果：
- ✅ JS 语法检查通过
- ✅ 10 关地图全部为 13×13 正确格式
- ✅ 每关敌人均为 20 个
- ✅ **50 万帧**长时间运行无任何运行时错误（无数组迭代中 splice 之类的经典 bug）
- ✅ 敌人生成/移动、得分、过关判定、清场逻辑全部正确
- ✅ 300 帧渲染无报错
直接双击 `index.html` 即可在浏览器打开游戏（或用任意静态服务器）。点击"开始游戏"，用 ↑↓←→ 移动、空格开火、P 暂停，祝通关顺利！
看起来逻辑严密，还做了六项大验证，甚至跑了 50 万帧长时间运行和 300 帧渲染！感觉十拿九稳，一次搞定了。
然后我打开游戏一看才发现：一顿操作猛如虎，结果……
只能说效果“感人”，除了不能发射子弹、不怎么像原版之外，都挺好的。😂
好吧，今天不是来吐槽的，也不是来测评的，而是来真正挑战这套开发组合的效率和上限的。
Round 2
因为第一个版本确实不太理想，问题很多，所以必须让它改进，顺便也看看它修复 bug 的能力。
需求：修复 4 个严重问题
① 地图不像原版，需要 1:1 复刻（含纹理）；
② 敌我坦克都无法发射子弹；
③ 缺少双人协作模式；
④ 右侧 HUD 与原版差距大。要求高保真还原，参考 GitHub 复刻项目与原版 ROM 数据。
这次修复大约消耗了 20 分钟。
汇总：
这个输出结构我真的很喜欢，问题本身和解决方法都写得清清楚楚。这一轮它终于去 GitHub 找了个项目开始抄代码了。
结果：
这一波确实好了很多！双人模式已添加，右侧面板也做了改动，把 2P 和星级加上了。重点是主界面地图真形态是 1:1 还原的：
这个结构应该非常准确，毕竟它是直接参考代码实现的，这一点非常不错。
可惜，有一个致命问题还是没解决：打不出子弹，所有发射键都射不出东西。还得继续修！另外它问我是否要完成 35 关和结算界面，我当然选择要。
Round 3
我们继续推进。
需求：
① 还原全部 35 关（不只是 10 关）；
② 制作结算统计页；
③ 修复"按射击键看不到炮弹也不会击中敌人"的严重 bug（敌我双方都是）。
这次工作了 29 分 54 秒！
结果：
它告诉我三件事全部完成，并给出了子弹 bug 的根因：
这是个隐蔽的属性名拼写错误，之前所有测试都没发现，因为 headless 测试没有真正按开火键：
// fire() 里 —— 错误
bullets.push({ x:bx, by:by, ... }); // 存成 by
// updateBullets() 和渲染里 —— 用的是 b.y
b.y += DY[b.dir]*b.speed; // b.y 是 undefined → 运算后变 NaN
自己写的 bug 自己修！我全程看着它像新手程序员一样反复摇摆：确认了——找到了——好像没问题——重要发现——等等——找到真正的根因了——等等——又找到了——修复验证——奇怪——确认！还好最终终于把子弹问题修好了，只是浪费了大量 Token 和时间。
这种问题，第一轮花了 50 分钟就不该错；如果错了，也应该能秒修，而不是反复来回测试。
忍住，我不是来吐槽的，我是来实战的！
Round 4
子弹发射解决了，但还有两个明显的问题。
继续推进：
需求：
① 1P 死后明明还有命却不复活；
② 砖墙消除不平整——“一炮消左下角四分之一，一炮消右下角四分之一”，应该是一次消整层（整块砖的 1/4 接触面，即一个 8×8 小格）。
这次修复花了 10 分 30 秒。
修复总结：
① 1P 死后不复活
根因：复活用 setTimeout(respawn, 1000)，异步回调在游戏循环里存在竞态，延迟期间状态变化导致回调里检查失败，跳过复活。
修复：改为帧驱动计时器，新增 respawnTimer，checkAllDead 设为 60 帧（1 秒），主循环每帧递减，归零时复活。完全由游戏循环驱动，无竞态。
验证：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 又同时复活两人 → 表现为"等齐了一起复活"。
总算是修复了复活问题，但子弹问题又回到了上一轮的状态。经过多轮折腾，最基础的“完全不能玩”那几个问题终于解决，我已经可以成功打到第二关了：
地图布局已做到比较好的复刻，因为可以直接抄代码。
但开始界面和右侧面板还是离原版效果很远，并且这种东西越来越难以单纯用语言描述。再加上敌方坦克的运行逻辑在速度和轨迹上也有点不正常。
Round 6
当细节越来越深时，很多问题已经说不清楚了。这时光靠文字已经不够，必须上图。GLM5.2 不是多模态模型，只能通过 MCP 解决。
我给了它两张原版截图：
需求：重做开始菜单的样式与进入效果、重做游戏界面右侧面板，参考原版截图高保真还原。
这一波速度很快，只用了 4 分多钟。相比开头动不动的 40 分钟，这 4 分钟我已经觉得快到飞起了。
下面就是它修改后的结果：
看到这个界面，我只能说，它真的很努力在克隆，但就是完全没有那种感觉。开头界面远远没有达到我的期望！
游戏界面好像好了一些：
大致布局都在了，但各种细节完全不一样。这种感觉实在难以描述，就是没有那种老游戏的味道。
现在我被彻底卡住了。我知道还有很多细节没做好，没到达我心目中的样子，但我已经很难通过“自然语言”继续提升效果。这基本触及了我个人的上限。如果还要往下走，就得无限细化每一个细节，一个像素一个像素地调，那基本上就回到传统开发工作流了。
相比之下，Fable 确实省力很多，效果也好很多。下面是 Fable 一轮跑出来的结果，没有给参考图：
这个界面虽然和原版不一样，但那种老游戏的感觉却出来了。尤其是那个字体，我甚至无法想象它是怎么实现出那种上世纪马赛克风格的。
再看游戏界面：
它一次性就把整个氛围做出来了。除了地图没有 1:1 拷贝之外，右侧面板、坦克造型、道具效果、敌方坦克运转逻辑，全都充满了那个时代的质感。这么多复杂的细节，也是一轮几十分钟搞定，而且键盘操作体验极其丝滑，各种按键顺手极了。
我原本是想夸一波 GLM5.2 的，它这版确实比之前强了一些。但当你吃过一顿真正的好菜，再尝“还可以”的，就再也难有兴奋感了。我还是坚持上次的结论：GLM5.2 模型本身的能力并没有质的提升，它更多是优化了工程能力，靠反复消耗 Token 和时间来增加容错、提升 bug 修复能力。可它依旧会产生低级 bug，然后再花费大量资源去修自己弄出来的问题。
同样是“智能体 + 模型”，或许在各种基础指标上只差零点几，但在实际开发中，综合能力的上限、开发效率的差距，还是非常巨大的！
Claude + Fable 5 再由 Opus4.8 收尾，短短几天已经把 3D 版都做出来了，并且迭代了多个版本，基本已经能做到指哪打哪：
如果让 GLM5.2 来操刀，我不是很有信心能做到这种程度。
目前编写网页版坦克大战这个例子，已经测试了 4 个模型！
虽然大家都叫 Agent 和 Model，但差距还是有不少的！有的时候甚至是云泥之别。