我把两个 App 的全部源码一次性喂给了 GLM-5.2，让它找茬

公众号名称：三元同学

作者名称：三元同学

发布时间：2026-06-19 10:38

最近几天 GLM-5.2 发布了，我看了下官方的发布内容，感觉就两个关键词：1M 上下文、Coding 国产 / 开源第一。API 今天也上线了，我直接用上了。

说实话，“1M 上下文”这词我现在已经有点免疫。这一年标称 1M 的模型一抓一大把，可真用过的人就知道，长上下文到底行不行，还是得靠实测，因为大部分情况上下文一膨胀起来，模型很容易降智。

大部分不知道的是，这里头藏着个被容易被混淆的概念：标称长度，不等于有效长度。 窗口开得下，不代表你喂到 80 万 token 的位置它还记得住前面定的规矩。很多模型喂到 25、30 万往后就开始”失忆”。再加上长上下文又慢又贵，“能跑”和”用得起”是两码事。

所以我对 1M 的问题一直保持质疑：这个 1M 上下文到底是参数表上的数字，还是能用在日常工作流里面的一个强大能力。

GLM-5.2 这次说自己从注意力结构上去做文章（KV8、HiSparse 那一系列优化技术），把长序列的成本和效果衰减一起压了下来。先给大家看看我自己本地实际的案例吧。

实测：我把两个 App 的全部源码一次性塞了进去

这里我挑了一个只有不降智的 1M 才做得到、而且每个做多端产品的人都被坑过的事情：跨端一致性。

背景是这样。我自己的 Sitor 产品有四个端：Web、小程序、iOS、安卓。同一个功能，四端各写各的，写着写着就出跨端问题了——同一个业务规则，这端是这么校验的，那端不知不觉变了个样。这种 bug 最阴险，单看哪一端代码好像都没毛病，一起看的时候就发现总有一个端有问题。

这次我拿”账号绑定”这个功能来作为案例——绑定邮箱、绑定手机号，四端都有。我把 iOS（Swift）和安卓（Kotlin）两个原生端的全量源码一次性喂给 GLM-5.2，让它自己定位到绑定相关的实现，然后逐项比对两端的差异。

注意，我喂的不是我手工挑好的那几个文件，是两个工程的全量代码——让它自己去大海里捞针、再两两对照。

整库投进去，API 返回的真实用量是差不多 470K，也就是接近 0.5 M（一次请求里的 prompt_tokens，没分段、没切片），耗时 125 秒，一把过了。

你拿 200K 的模型根本没法这么干。光一个端的代码就快把窗口塞满了，更别说同时拿住两端来对比。

两端全量源码一次性投喂的真实 token 用量 —— GLM-5.2 API 返回的 usage：prompt_tokens 471,184，单次请求，125s 跑完

结果是：它是确确实实读进去了。

我把它给出的审计报告打印出来，挑出几条自己回去逐行核对过、确实存在的不一致（函数名、字段名我都对过，没有瞎编的细节）：

1. 绑定成功后，两端更新本地状态的来源不一样。 这条最隐蔽，我自己之前都没注意到。

绑邮箱成功后，iOS 用的是后端返回的response.user.email 去更新本地；安卓用的是用户刚才输入的那个email：

// iOS - AuthManager.swift：用后端返回值
self.currentUser = AppUser(id: response.user.id, email: response.user.email, ...)

// Android - SelfHostedAuthManager.kt：用用户输入值
_userEmail.value = email

听着没区别，但只要后端对邮箱做了规范化（比如统一转小写），安卓本地显示的就跟服务器实际存的对不上了。这种 bug 平时根本测不出来，等用户投诉反馈才发现。

2. 有个 @wechat.sitor.cc 的邮箱过滤逻辑，是安卓独有的，iOS 根本没有。

安卓在绑手机号成功后，会特意过滤掉微信登录生成的那种占位邮箱：

data.user?.email?.takeIf { it.isNotEmpty() && !it.endsWith("@wechat.sitor.cc") }

iOS 这边没这个判断。也就是说微信用户绑完手机号，两端显示的邮箱状态是不一样的。

**3. 邮箱格式校验，两端的校验严格程度差一大截。**安卓是正儿八经的正则 ^[^@\s]+@[^@\s]+\.[^@\s]+$判断的，iOS 就弱不少。同一个绑邮箱入口，iOS 就没做好校验（仅仅判断有没有 @ 符号和 . 符号），判断条件明显有问题。

4. 安卓设了一句”绑定成功”的提示文案，但界面里压根没把它显示出来。 等于写了行死代码，用户绑完是没有任何成功反馈的。这种问题，光看单个文件根本发现不了，太坑了，感谢 GLM 5.2。

它甚至还能分清登录页和绑定页是两套手机号校验逻辑，个人觉得这个部分出乎我意料了，还是比较屌的。下面是节选的部分报告：

GLM-5.2 跨端审计报告节选 —— 编号列出的不一致点、风险定级、以及末尾”必须对齐的高优先级问题”

看一下数据

前端编程的盲测榜 Code Arena——全球上百万用户两两盲投出来的排名，这次 GLM-5.2 的成绩在下面标注出来了：

Code Arena 前端榜 —— GLM-5.2 在所有可用模型里排第一

榜上 GLM-5.2 排第 2，1595 分。第 1 是 Claude Fable 5——但你注意看那个小星号：Fable 5 已经不再采样了（就是前阵子被下架那事，我之前还专门写过）。

换句话说，在所有你现在还能真正用上的模型里，GLM-5.2 就是第一，而且把 Opus 4.8 那几档（1561、1541）都压在了身后。

接入方法

Coding Plan 全量用户（Max/Pro/Lite 都包括）现在就能直接用，API 也同步上了。

在 Claude Code 里切换很简单。最简单的办法是直接改 ～/.claude/settings.json 里的模型字段：

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://open.bigmodel.cn/api/anthropic",
    "ANTHROPIC_AUTH_TOKEN": "你的智谱 API Key",
    "ANTHROPIC_MODEL": "glm-5.2",
    "ANTHROPIC_SMALL_FAST_MODEL": "glm-5.2"
  }
}

然后用 GLM 干活的时候，直接用下面这个命令起起来就可以用了：

claude

最后

平心而论，我发现我现在工作流里面有大量的长程任务，但这些任务其实不需要特别顶尖的智能程度就能做。这种活对上下文的长度要求比较高，最好不要做到一半压缩（/compact）。GLM 这次发布无疑在这个场景下给了我另一个选择，价格低、上下文充足，完全可以在平时的工作里面用起来了。

再继续往大了说一句哈，我觉得这两年模型的进步，关键早就从回答的惊艳程度挪到了下一个阶段：能不能把它一个 agent 扔那儿干一下午、回来发现它真把活干好。后者带来的是工作方式的质变。

GLM-5.2 的战略是死磕”长任务”能力，我觉得押对了方向。

你呢？你平时有那种需要长时间时间执行、需要占用长上下文的任务吗？评论区聊聊。

---

内容效果不满意？点此反馈