GLM 5.2 Unity项目评测：完成度媲美Opus 4.8但耗时45分钟

背景

本次评测由 LINUX DO 社区发起，旨在对近期积累的多个 AI 编程模型进行横向对比。测试项目为一个具体的 Unity C# 项目需求，具体场景为“皮肤系统”的代码编写。评测者已预先制作好预制体（Prefabs），要求模型负责编写核心逻辑代码。

本轮评测沿用了与上一轮完全一致的项目环境、需求文档及测试标准，以确保数据的可比性。评测重点不仅关注代码的最终完成度，还严格记录了各模型从开始阅读代码库到最终生成代码的全流程耗时。

核心内容

评测对象涵盖了包括 GLM 5.2、GPT-5.5 系列、Claude 系列（Sonnet/Opus/Fable）、Qwen 系列、Kimi K2 系列、Gemini 3 系列、DeepSeek V4 系列、Mimo V2 系列、Grok 4 系列、Step-3.5-Flash、Doubao-Seed-2.0 系列、Minimax M2.7/M3 以及 KAT-Coder-Pro V2 在内的 45 个模型或版本。

1. 速度排名与耗时分析 在速度维度上，表现最佳的模型为 Composer 2.5 和 Grok 4.20 0309 Reasoning，耗时均为 3 分钟。GLM 5.2 在本次测试中表现极为迟缓，总耗时高达 45 分钟，位列第 42 名。

• GLM 5.2 的耗时细节：该模型首先花费 25 分钟全盘阅读代码库，并启动两个子代理进行辅助阅读；随后进入代码编写阶段，耗时 20 分钟。这一过程打破了此前由 Kimi K2.7 Code 保持的最长耗时记录，甚至比 K2.7 Code 慢了 6 分钟。
• 对比参照：在 GLM 5.2 完成一轮任务的时间里，速度最快的 Composer 2.5 甚至完成了两轮相同的需求。评测者指出，GLM 5.2 并非通过“大力出奇迹”的方式处理，可能与其 Coding Plan 级别较低或吞吐量（TPS）较低有关。

2. 代码质量与完成度 尽管速度极慢，GLM 5.2 在代码质量上表现优异：

• 代码变更：+1331 行，-7 行。
• 审查结论：完成度非常高，仅出现两个功能错误问题。
• 层级定位：GLM 5.2 被归类为 Tier 1。该层级的定义为“代码正确完整且可编译，仅少量边界问题或轻微不一致”。在此层级中，GLM 5.2 排名第 4，仅次于 Claude-Fable-5、GPT 5.5(xhigh) 和 Claude Opus 4.8(Max)。

3. 整体分层总结

• Tier 0（最高级）：实现与线上基线高度一致。包括 Claude-Fable-5 和 GPT 5.5(xhigh)。
• Tier 1（优秀）：代码正确完整，仅有少量瑕疵。GLM 5.2 位列其中，与 Kimi K2.7 Code、GPT 5.5(high) 等并列。
• Tier 2（良好）：代码可编译，但存在明显功能错误、遗漏或不一致。GLM 5.1、Minimax M3、GLM 5 等位于此层。
• Tier 3（较差）：问题众多，无法编译或存在大量幻觉。包括 DeepSeek V4 Flash(max)、Claude Opus 4.7(Max) 等。

关键要点

• GLM 5.2 的“质优速劣”：GLM 5.2 以 45 分钟的超长耗时，换来了 Tier 1 的高质量代码输出。其完成度与 Opus 4.8 不相上下，是国产模型中表现最好的之一。
• 速度瓶颈明显：GLM 5.2 的慢速主要源于前期大量的代码库阅读（25 分钟）及子代理协作开销。相比之下，顶级模型如 Composer 2.5 仅需 3 分钟。
• 国产模型梯队分化：
  • 第一梯队（Tier 1）：GLM 5.2、Kimi K2.7 Code。
  • 第二梯队（Tier 2）：GLM 5.1、GLM 5、Kimi K2.5。
  • 这表明 GLM 5.2 在代码生成能力上相比前代有显著提升，但在推理效率上仍有巨大改进空间。
• 第三方供应商的可能性：鉴于 GLM 5.2 当前过慢的响应速度，评测者推测通过第三方 API 供应商调用可能获得更好的体验，暗示原生接口或当前部署策略存在优化空间。
• 评测环境的稳定性：由于测试模型众多，表格会定期清理同厂商旧模型，但本轮与上轮保持一致，确保了横向对比的有效性。

意义与影响

本次评测揭示了当前 AI 编程助手在“速度”与“质量”之间的权衡现状。GLM 5.2 的案例表明，即使是最先进的模型，如果在工程实现上（如代码库检索策略、代理协作机制）不够优化，也可能导致用户体验大幅下降（45 分钟 vs 3 分钟）。

对于开发者而言，GLM 5.2 证明了国产大模型在复杂逻辑代码生成能力上已具备与国际顶尖模型（如 Claude Opus 系列、GPT-5.5 系列）竞争的实力，特别是在 Tier 1 层级中占据一席之地。然而，其极高的时间成本限制了其在快速迭代场景下的应用价值。

这一结果也提示模型厂商，未来的优化方向不应仅局限于提升代码准确率，更需关注推理效率、上下文处理速度以及多代理协作的流畅性。对于用户来说，在追求高完成度代码时，可能需要根据具体场景在“快速原型”（选用 Composer 2.5 等高速模型）与“高精度交付”（选用 GLM 5.2 或 Claude Opus 4.8）之间做出选择。