GLM-5.2 开发者测评 | 1M 上下文 + 强规划,单会话搞定跨语言工程项目
活动 GLM-5.2 全量上线 Coding Plan · 致敬开发者 测评场景:xianyu-auto(闲鱼自动上货技能包)完整开发 测评人:woshihoujinxin(开发者)
测评背景
我用 GLM-5.2 在 Claude Code 里从零做了一个完整项目 xianyu-auto——一套"网盘资料自动上架闲鱼"的开发者技能包。整个过程单会话贯穿,涉及多语言、多仓库、真实交付(npm 发布 + 电商上架),是一个能压测模型工程能力的真实场景。
| 维度 | 规模 | 说明 |
|---|---|---|
| 代码文件 | 79 个 | git ls-files 实测 |
| 涉及语言 | 5 种 | Python / Bash / Batch / TOML / TypeScript |
| 开源仓库 | 3 个 | xianyu-auto + quarkpan fork + xhs-cli fork |
| 部署目标 | 6 种 AI 应用 | Claude / OpenClaw / Cursor / Codex / 灵码 / Generic |
| 真实交付 | npm 包 + 闲鱼商品 + 小红书帖 | 非模拟,均已上线可验 |
下面围绕三个最打动我的能力点展开,都是真实体验,不堆虚的。
一、1M 上下文:Claude Code 长会话不再"压缩失忆"
这是最直观的体感提升。
在 Claude Code 里用模型写代码,最头疼的就是上下文压缩(context compact)。以前用标准窗口的模型,一个稍复杂的项目写到一半,系统就提示"上下文已满,需要压缩",一压缩前面的决策细节就糊了——之前约定好的目录结构、命名规范、安装方式,全得重新解释一遍。一个项目断断续续改几十轮,光"重新同步上下文"就耗掉大量来回。
GLM-5.2 给到 1M 上下文,这次 xianyu-auto 项目我单会话跑了 90+ 轮,跨十几个子任务(整合技能 → 解决夸克网盘安装 → 双仓库推送 → fork xhs-cli → npm 发布 → 小红书发帖调试 → 写教程文档),全程没有触发过一次上下文压缩。
更关键的是,早期约定全程不漂移。比如项目一开始定的:
- 凭证统一放
~/.config/<技能名>/(不散落各处) - quarkpan 走
git clone + pip install .(因 PyPI 同名包冲突,不走 pip 直装) - install.sh 用 TOML 声明式驱动多目标部署
这些约定在第一轮就定了,到第 90 轮我做小红书发帖时,模型仍然严格遵守,没一次记错或推翻。这种"长程一致性"对工程项目太重要了——不用人盯着"你是不是又忘了我们之前怎么定的"。
一句话:1M 不是噱头,是真能让一个跨语言、多仓库的项目在单会话里不失忆地连续推进。这在以前的标准窗口下基本做不到。
二、复杂任务规划:边界把控 + 主动拆解
第二个让我惊喜的是任务规划和边界感。
我扔给它的不是"写个函数"这种小活,是"把 5 个独立技能整合成一个可一键安装到 6 种 AI 应用的项目"。这种复杂需求,以前的模型容易要么一上来就埋头乱写,要么大包大揽啥都答应最后做砸。
GLM-5.2 的做法是:先拆解,再管控边界。
拆解:它把整合需求拆成了 18 个有依赖顺序的开发任务(代码迁入 → install 入口 → 部署声明 → 卸载 → 烟测 → 文档),用 Task 系统全程追踪,做完一个标一个,不会漏步骤也不会乱序。
边界把控(更难得):有几处它主动"踩刹车":
- 我想让它顺手把 quarkpan 源码内嵌进项目,它分析后说"这会和上游维护分叉,建议保持 pip 依赖关系,不内嵌"——主动拒绝了越界方案。
- 我让它加一个统一凭证环境变量,做到一半它发现"这违背了各技能自管凭证的约定",主动回滚,改成按技能分目录。
- 发帖功能调试时,它没有无脑改源码,而是先诊断(dump DOM、截图分析),确认根因(按钮在 iframe)再动手。
这种"知道哪些该做、哪些不该做、什么时候该停下确认"的分寸感,对复杂项目是防烂尾的关键。模型不瞎答应、不越界,人才能放心把大块任务交给它。
三、主动完善:超出指令的细节补全
第三点,也是日常用起来最舒服的:它不只是"吩咐啥做啥",会主动补你没顾上的细节。
几个真实例子:
- 我让它改一个配置文件,它改完顺手把引用这个配置的其他文件也检查了一遍,还提醒我"有处路径可能在新机器上不存在"。
- 写 install 脚本时,我只说了"装依赖",它主动加了 Python/Node 版本检测、失败兜底、凭证目录创建这些我没明说但确实需要的工程细节。
- 提交代码前,它主动做了一遍全仓库敏感信息扫描(grep token/key/cookie),确认没有把我的真实凭证误提交——这种安全意识我没要求,它自己做的。
- npm 发布失败后,它不只报错,主动诊断是 2FA 还是 token 问题,并给出"用 automation token 绕过"的具体方案。
这种"主动劲儿",让它从"听指令的工具"变成了"会替你想一层的搭档"。你给它一个方向,它能把周边该处理的都覆盖到,而不是你漏一句它就漏一块。
四、量化数据(均可 git 核验)
| 指标 | 数值 | 来源 |
|---|---|---|
| 修复的 bug | 10+ | git log |
| 会话轮次 | 90+ 用户消息 | 单会话 |
| 子任务完成 | 89 个 | Task 系统 |
| 跨语言改动 | 5 种 | Python/Bash/Batch/TOML/TS |
| npm 发布版本 | 1.4.5(@easyasstudio/xhs-cli) | npm registry |
| 产出文档 | 10+ 篇 | docs/ |
| 真实交付 | npm 包 + 闲鱼商品 + 小红书帖 | 均上线可验 |
代表性 bug 修复(展示排查深度):
| 问题 | 根因 | 模型排查路径 |
|---|---|---|
| quarkpan 装成 PyPI 同名包 | 包名冲突 | 查 pip 行为 → 改 git clone 装 |
| 小红书发布按钮找不到 | 按钮在 iframe | dump DOM → 截图 → 定位 iframe |
| npm publish OTP/403 | 2FA 策略 | 诊断 → automation token |
| 坐标点击页面隐藏失效 | mouse 依赖可见 | 屏幕/viewport 自动转换 |
五、诚实:短板与人工触发
测评不能只说好话。以下都是人工指出后模型才修正的,模型贡献在"接受纠正后彻底重构 + 固化":
- 小红书发布按钮在 iframe —— 是我看截图后才定位的,模型一开始只搜主 document
- 坐标点击页面隐藏失效 —— 是我反馈"隐藏就点不到",模型才改屏幕/viewport 转换
- 内容风控 —— 测试帖带"自动化"被下架,是我指出后模型才写禁用词规范
- 循环依赖 —— publish 冲突才暴露,不是模型主动发现
模型不是全能,但指出一次就彻底改 + 固化成规范/护栏,不犯第二次——这种"纠正即免疫"的特性,比"从不犯错"更实用。
六、总结:为什么开发者该试 GLM-5.2
结合 xianyu-auto 这个真实项目,GLM-5.2 对开发者的核心价值:
- 1M 上下文 → 长项目不失忆,不用反复同步上下文,Claude Code 里不再动不动压缩
- 强规划 + 边界感 → 复杂任务能拆解、敢拒绝越界方案,防烂尾
- 主动完善 → 超出指令补细节,像搭档不像工具
- 真实交付力 → 不是跑 demo,是真发 npm 包、真上架商品、真发帖
一句话定位:GLM-5.2 是能在「跨语言、多仓库、含真实交付」的工程级项目里不失忆、不越界、还会主动补位的模型。它不"不犯错",但人指一次就能彻底改并固化——从"需要人盯"到"人指一次即稳定"的可用性跨越。
本测评基于真实开发过程,数据均可核验。
