GLM-5.2 实测：代码能力到底什么水平（含 1M 上下文场景）
GLM-5.2 在代码补全、Bug 修复、单元测试生成三个高频场景上没有明显短板，部分指标（解释深度、注释完整性）甚至略优于对照组。真正拉开差距的是 1M 上下文场景：一次性吃下整个中型代码仓库做整体重构这件事，GLM-5.2 是目前国产模型里第一个能跑稳的。所有测试通过 OpenStarry 统一接口完成，切换模型只改一个
model参数。
一、为什么做这次实测
智谱 6 月 13 日宣布 GLM-5.2 全量开放、定位"迄今能力最强的开源模型，支持真正可用的 1M 上下文"。作为每天都在调各家大模型 API 的开发者，我们关心的不是发布会上的措辞，而是三个真问题：
- 代码能力到底是不是"对标一线"？
- 1M 上下文是真的能塞下整个仓库，还是营销话术？
- 在 OpenStarry 上接入成本、速度、配额，够不够日常开发用？
本文是 OpenStarry 工程团队花了两天时间、用 5 个场景 × 50 个用例做出来的对比结果。对照组：DeepSeek-V4、Qwen3-Coder（国产代码模型目前公认第一梯队）。所有用例已开源在文末，可复现。
二、测试设计
我们刻意避开了"让模型写个冒泡排序"这种演示级测试——那种 prompt 跑分高，跑不到生产里。
5 个场景、50 个用例的设计如下：
| 场景 | 任务说明 | 用例数 | 评分方式 |
|---|---|---|---|
| A. 代码补全 | 给定函数签名 + 一行注释，补全实现 | 15 | 正确性（pass/fail）+ 风格分（1-5） |
| B. Bug 修复 | 给一段有 bug 的代码（10-80 行），要求定位并修复 | 10 | 修复正确 / 部分修复 / 未修复 |
| C. 单元测试生成 | 给定一个函数，生成可运行的单元测试 | 10 | 覆盖率（行/分支）+ 测试有效性 |
| D. 跨文件理解 | 3-5 个文件的项目，问"哪里有安全漏洞/性能问题" | 5 | 找到的漏洞数 / 假阳性数 |
| E. 1M 上下文场景 | 一次性喂 ~700K tokens 的真实代码仓库，要求做整体重构 | 2 | 任务完成度 + 一致性 |
对照组：
DeepSeek-V4（长上下文 + 强代码）、Qwen3-Coder（代码专精） 统一接口：所有测试通过 OpenStarry 聚合网关调用，切换模型只改model字段 评分方法：每个用例 3 次采样取众数；Bug 修复和跨文件理解由 2 位工程师独立打分
三、测试结果
3.1 代码补全（15 用例）
典型用例：
# 输入：函数签名 + 简短注释
class LRUCache:
def __init__(self, capacity: int):
"""初始化 LRU 缓存，capacity 为缓存容量"""
# GLM-5.2 补全结果（节选）
self.capacity = capacity
self.cache = OrderedDict()
def get(self, key: int) -> int:
if key not in self.cache:
return -1
self.cache.move_to_end(key)
return self.cache[key]
补全正确，主动用了 OrderedDict——说明模型理解了 LRU 的核心数据结构选择，不是机械背答案。
15 用例汇总（pass rate）：
| 模型 | 通过率 | 风格均分（1-5） | 备注 |
|---|---|---|---|
| GLM-5.2 | 14/15（93%） | 4.2 | 注释详细、解释清楚 |
| DeepSeek-V4 | 13/15（87%） | 4.0 | 代码风格更简洁 |
| Qwen3-Coder | 12/15（80%） | 3.6 | 偶尔过度实现（边界检查冗余） |
结论：基础代码补全三者差距不大，GLM-5.2 略胜在注释完整度和解释意图。
3.2 Bug 修复（10 用例）
典型用例（一个经典的 DJB2 哈希函数整数溢出 bug）：
// 原代码（有 bug）
unsigned int hash(char *str) {
unsigned int hash = 5381;
int c;
while ((c = *str++))
hash = ((hash << 5) + hash) + c; // 可能溢出
return hash;
}
GLM-5.2 的修复：直接指出溢出问题，给出 unsigned long long 改进版本，并解释了为什么 5381 是 DJB2 算法的标准初始值。这个细节让我们有点意外——它不只修 bug，还解释背后的原理。
10 用例汇总：
| 模型 | 完全正确 | 部分修复 | 未修复 | 解释深度 |
|---|---|---|---|---|
| GLM-5.2 | 7 | 2 | 1 | ⭐⭐⭐⭐ |
| DeepSeek-V4 | 8 | 1 | 1 | ⭐⭐⭐ |
| Qwen3-Coder | 6 | 3 | 1 | ⭐⭐⭐ |
结论：Bug 修复三者非常接近，DeepSeek-V4 略好，但 GLM-5.2 的"解释原因"是最详尽的——对实际开发场景（Code Review、学习场景）更有价值。
3.3 单元测试生成（10 用例）
给定一个 parse_config 函数（30 行，处理 YAML/JSON/TOML 三种格式），让 3 个模型分别生成 pytest 测试。
GLM-5.2 生成的测试覆盖了：
- ✅ 正常输入（3 种格式各 1 个）
- ✅ 边界条件（空文件、最大嵌套层级、特殊字符）
- ✅ 异常输入（类型错误、文件不存在、编码错误）
- ✅ 主动用 pytest 风格，没随机挑 unittest
10 用例汇总（行覆盖率）：
| 模型 | 平均行覆盖率 | 平均分支覆盖率 | 假测试数（重复/无效） |
|---|---|---|---|
| GLM-5.2 | 89% | 76% | 0.3 / 用例 |
| DeepSeek-V4 | 85% | 71% | 0.8 / 用例 |
| Qwen3-Coder | 82% | 68% | 1.2 / 用例 |
结论：GLM-5.2 在单测生成这个场景上明显胜出——覆盖率最高、假测试最少、对测试框架有偏好（pytest）而不是随机挑。
3.4 跨文件理解（5 用例）
给了一个 3 个文件的 Python Flask 项目（app.py / models.py / utils.py，共 800 行），问："这个项目的认证逻辑有没有安全漏洞？"
| 模型 | 找到的真漏洞 | 假阳性 | 漏掉的真漏洞 |
|---|---|---|---|
| GLM-5.2 | 1 | 0 | 1（藏在 utils.py 的工具函数里） |
| DeepSeek-V4 | 2 | 0 | 1 |
| Qwen3-Coder | 0 | 1 | 2 |
结论：跨文件理解是所有模型都还在爬坡的方向。GLM-5.2 不是最强，但在"不假报"上更稳。期待 1M 上下文能不能改善这个场景（见 3.5）。
3.5 1M 上下文场景（2 用例，⭐ 本文最关键的新增测试）
GLM-5.2 官方最强调的能力是 1M 上下文"真正可用"。我们专门设计了两个用例，只有 1M 上下文能跑、200K 跑不下来：
用例 1：整体重构
- 输入：一个 Python 中型代码库（87 个文件 / 723K tokens），要求把
print语句全部替换为logging，且按模块拆分到各自的 logger - 任务：跨文件、跨模块、不破坏现有 import 关系
| 模型 | 上下文窗口 | 能否一次跑完 | 完成度 | 一致性 |
|---|---|---|---|---|
| GLM-5.2 | 1M | ✅ | 92% | ⭐⭐⭐⭐（同一 logger 命名风格贯穿） |
| DeepSeek-V4 | 200K | ❌（需切片） | 78%（切片后丢上下文） | ⭐⭐⭐ |
| Qwen3-Coder | 128K | ❌ | 65% | ⭐⭐ |
用例 2：整体架构问答
- 输入：一个 Go 微服务代码库（142 个文件 / 680K tokens），问"这个系统的订单创建流程经过了哪些模块、每个模块的职责是什么？"
- 任务：跨文件追踪调用链、给出完整答案
| 模型 | 能否完整回答 | 答案覆盖的模块 | 假报模块 |
|---|---|---|---|
| GLM-5.2 | ✅ | 18/18 | 0 |
| DeepSeek-V4 | ⚠️（切片） | 12/18（漏掉 6 个） | 0 |
| Qwen3-Coder | ❌ | 9/18 | 2 |
结论：1M 上下文是 GLM-5.2 真正的差异化能力——对手不是做不好，是窗口根本塞不下。这两个用例里，GLM-5.2 是唯一能"看完整个仓库再做判断"的国产模型。
四、速度与成本
通过 OpenStarry 统一接口调用（base_url 指向我们的聚合网关）：
| 模型 | 平均首 token 延迟 | 输出速度 | Token Plan 单价（输入/输出 ¥/1M） |
|---|---|---|---|
| GLM-5.2 | ~0.8s | ~35 token/s | 9.80 / 30.80（85 折后 8.33 / 26.18） |
| DeepSeek-V4 | ~0.6s | ~42 token/s | 3.00 / 6.00 |
| Qwen3-Coder | ~0.9s | ~30 token/s | 2.31 / 13.65 |
速度：GLM-5.2 处于中等水平，不影响日常开发体验。如果你做的是实时代码补全（Copilot 类场景），DeepSeek-V4 仍是首选。
成本：GLM-5.2 单价高于对照组，但配合 1M 上下文减少的"切片往返"开销，整仓库重构这类任务的总成本可能反而更低。1M 上下文跑一次 vs 200K 跑 4 次，token 总量是降的。
五、怎么接入 GLM-5.2（以 Hermes Agent 为例）
如果你已经在用 Hermes Agent 做日常开发，三步把 base_url 切到 OpenStarry，所有 agent loop / subagent / cron / gateway 自动继承 GLM-5.2。
Step 1 — 把 Key 写进 ~/.hermes/.env：
OPENSTARRY_API_KEY=sk-你的Key
Step 2 — ~/.hermes/config.yaml 注册为 custom provider：
providers:
openstarry:
name: OpenStarry
base_url: https://api.openstarry.com/v1
api_key: ${OPENSTARRY_API_KEY}
api_mode: chat_completions
context_length: 1048576
default_model: glm-5.2
model:
provider: openstarry
default: glm-5.2
Step 3 — /reset 起新 session，跑一下：
# 跑 1M 上下文实测里的那个"整体替换 print 为 logging"任务
hermes chat -m glm-5.2 -q "把当前仓库的 print 全部替换为 logging，按模块拆分 logger"
零额外配置覆盖：交互式 CLI /
hermes chat -q/delegate_task子 agent /hermes cron定时任务 / Gateway 多平台 /hermes acp接 IDE /hermes -w多 worktree 并行。保留双模型：
/model glm-5.2或hermes chat -m glm-5.2随时切，不锁死 provider。
没用 Hermes？OpenStarry 也兼容 OpenAI / Anthropic SDK，Cline / Continue / Cursor / OpenCode / Claude Code 直接换 base_url 就能用，详见 OpenStarry 接入文档。
六、总结
GLM-5.2 在代码能力上的定位：
| 维度 | 评价 | 量化 |
|---|---|---|
| ✅ 代码补全 | 合格，没有明显短板 | 15/15 用例，14 通过（93%） |
| ✅ Bug 修复 | 接近一线水平 | 10/10 用例，7 完全正确 + 解释最详尽 |
| ✅ 单测生成 | 表现突出 | 10/10 用例，89% 行覆盖 / 0.3 假测试 |
| ✅ 1M 上下文 | 国产首个跑稳 | 87 文件 / 723K tokens 一次跑完 |
| 🟡 跨文件理解 | 所有模型都有提升空间 | 5/5 用例，找 1 漏 1 |
| 🟡 速度 | 中等，不影响日常使用 | ~35 token/s |
适合谁用：
- 做代码生成、单元测试、代码解释的开发者，GLM-5.2 值得作为主力模型
- 已经在用 OpenStarry 多模型路由的，建议把 GLM-5.2 作为长上下文任务的默认选项
- 做实时代码补全的（Copilot 类），DeepSeek-V4 仍是最优解
一句话结论：
GLM-5.2 是第一个在代码能力和 1M 上下文上同时能打的国产开源模型——尤其适合需要"整仓库级别"理解的场景。