GLM-5.2 能进工具箱，但还没到替代 Opus

TechStackups 做了一个很能戳痛点的测试：同一条 one-shot 提示，同一批素材，让 GLM-5.2 和 Claude Opus 4.8 从零写一个 3D 平台游戏。

难点不在“写个网页小游戏”。要求是 raw WebGL，不用 Three.js，不用游戏引擎，还要处理 GLB 解析、渲染、动画、碰撞、相机和浏览器运行。页面可以糊弄，游戏交付很难糊弄。跳不跳得过去、刺会不会死人、旗帜算不算胜利，都是硬账。

这次测试说明了什么

这不是总榜排名。单次 3D 游戏任务，不能推出“谁全面强于谁”。它更像一个高信息量样本：看模型在长任务 coding agent 场景里，能不能把东西做完。

结果很直接。Opus 更快，也更像一次完整交付。GLM-5.2 更便宜，开放权重更有长期可控性。

成品差距也不绕。

GLM-5.2 做出了能跑的游戏，但基础问题不少：材质缺失，角色朝向和头部显示有 bug，尖刺不致死，到旗帜没有胜利条件。它不是完全失败，而是最后闭环没收住。

Opus 的问题偏边缘：coyote-time 过宽，角色能在平台边缘“站空气”；胜利触发距离过早。但材质、动画、控制、相机、胜利条件都更顺。

网上关于 GLM-5.2 的讨论里，有真实进步，也有炒作混杂。这个测试的价值不在给情绪加码，而在把一个现实问题摆出来：模型会写代码之后，下一关是会不会交付。

分水岭不是跑分，是能不能看见自己的错

我更在意自检。

Opus 是多模态，能看截图。它发现画面里有 debug 信息，删掉后再结束。GLM-5.2 是文本-only，看不了图，只能写脚本采样像素颜色：有绿色草地、棕色泥土、金色金币、红色旗帜，于是判断“差不多完成”。

但角色材质丢了。debug overlay 还在。它没看见。

这就是 coding agent 的硬分水岭。长任务不是把文件生成出来就结束。它还要验收自己的输出。前端、游戏、设计工具、数据可视化，尤其如此。

老话讲“知错能改”。放到 AI 编程里，顺序更冷：先看见错，再定位错，再修掉错。看不见，后面全免谈。

这件事有点像早期网页时代。会写 HTML 不等于会交付产品。真正拉开差距的，是浏览器兼容、视觉还原、交互细节和线上稳定性。今天换成 AI agent，也是同一套旧账。技术换皮，验收不变。

所以我不太买账那种简单说法：开源已经打穿闭源，或者闭源永远压着开源。都太省事。

GLM-5.2 的问题不是“不会写”。它已经会写很多东西。问题是当任务进入多文件、长链路、视觉反馈、交互闭环时，它还不够稳。Opus 贵，但贵在更少返工。

对开发者和团队，动作应该不一样

如果你是 AI 编程工具重度用户，这次测试给的信号很清楚：别把 GLM-5.2 当玩具，也别急着把 Opus 扔掉。

更现实的用法是分层。

对技术负责人，动作更具体：采购别只看单次调用价格，也别只看榜单。要把任务拆开测。

视觉类、交互类、上线前验收类任务，继续给闭源旗舰模型留预算。GLM-5.2 可以进入内部工具链，用在成本敏感、数据边界更敏感、或需要长期可用性的环节。

如果团队正在做模型选型，我会建议延后“全面迁移”的决定，但可以开始做“双轨”。一条轨跑 Opus 这类闭源旗舰，负责高价值交付；一条轨跑 GLM-5.2，负责批量、可控、可审计的开发任务。

接下来最该看的不是新一轮口水战。看三件事就够了：GLM-5.2 在 Max thinking 下能补多少短板；开源权重模型什么时候补上稳定的视觉自检；同类长任务在多次重复测试里，失败率能不能降下来。

闭源 API 的结构性风险也不能装看不见。价格、速率、地区、功能、模型下线，都不由使用者控制。开源权重的好处很朴素：刀可能没那么锋利，但刀在你手里。

真正的选型从来不是信仰投票。天下熙熙，皆为利来。开发者最后买单的不是参数表，是少返工、少失控、少被供应商卡脖子。

GLM-5.2 已经能进严肃工具箱。但现在让它坐主驾，尤其是视觉和交互任务，还是早了点。