我让 GLM-5.2 连跑 86 分钟：烧掉 3240 万 token，单测却全过了

哈喽，大家好，我是徐公。

GLM-5.2 开源那天，我刷到一堆文章。标题都挺统一：1M 上下文、编程全球第三、开源之光。

一篇篇点过去，发现一个问题——没有一篇说，这模型真跑起长任务来，到底什么体感。

跑分会骗人，通稿更别信。国产模型每次发布，有一些自媒体很喜欢这样：又突破了，又领先了，又革命了。看多了，人就麻了。

所以这次我不看跑分，直接拿一个真实项目，让 GLM-5.2 连续干了一个半小时。这篇文章，就是这次实测的真实记录。

顺带交代下背景：我从 GLM-4.7 开始，就一直用国产模型驱动 Claude Code。4.7 够用，但长任务一铺开，它容易在后半程掉链子——改着改着忘了前面的约定，或者中途自己把自己带歪。有一次它改到一半，把前面刚定好的字段名又改回去了，前后对不上，我还得回过头去一条条查。

5.2 号称专门为长程任务而生。那我就真给它上一个长程任务。

这次我测的是什么

我手上有个真实项目，FastAPI 加 Vue3 的全栈系统。

这次的活儿，是给前端"我的文章"加一个批量重写功能。听起来就一句需求，真拆开是个全栈工程。需求原文长这样：

前端我的文章，增加批量重写：可展示已重写/未重写，可编辑，可批量选模板重写。
重写用队列控制，类似生产者消费者，最多同时 n 篇，可配置。

翻译成人话：从数据库加字段，写一个并发队列，改后端接口，改前端列表和编辑页，再补上测试。

这种活儿，不是写个函数就完事，得从数据库一路改到界面。我故意挑它，是因为正好踩在长程任务的痛点上：步骤多、跨度大、前后要咬合。一个环节忘了上一步的约定，后面全得返工。正好拿来试它。

GLM-5.2 把它拆成了 9 个子任务，一口气往下干。

让我最意外的，是它的工程判断

很多人测模型，喜欢盯两件事：写得快不快，代码漂不漂亮。单轮问答谁都能挑几个出彩的例子，可真实干活是多步连着的，前面错了后面全错。

这次让我意外的，是另一回事：它的工程判断力。

讲三个真实例子。

第一，它会主动躲开危险的测试。

项目里有个老的测试文件，能跑，但它会在初始化时清空真实数据库里的数据。GLM-5.2 还没动手，在思考阶段就把它揪出来了：

test_articles.py 是过时的 Flask 测试，setUp 里会清空真实 articles 表——危险，绝不能照搬。
我改用纯单元测试：不碰真实 DB，用 mock 验证队列逻辑。

它没等我踩坑，自己先绕开了。这一点很反直觉——你给大多数模型一个能跑的测试，它就照着跑，不会替你想这一跑会不会把库干没。

第二，它能自己当 DBA 救火。

改数据库结构的时候，迁移报错了。原因是表里有个"孤儿列"——之前某次操作残留的同名字段，挡了路。换别的工具，多半就卡在这，弹个红字等你手动收拾。GLM-5.2 自己查了表结构，翻了 MySQL 的连接列表，发现一堆僵尸连接赖着不走，挨个 KILL 掉，再把孤儿列删掉，重跑迁移。整个过程没问我一句。

这段它花了大概 9 分钟。慢，但活儿是自己干完的。

第三，它会自己发现并修 UX bug。

收尾的时候，它突然冒出一句：列表这一行的点击事件会跟复选框误触发，我加个判断修一下。我根本没报这个 bug，它自己发现，自己改的。

还有两处细节。整个任务改了 20 多个文件，从数据库模型到前端组件，但前后用的字段名——rewrite_status、batch_id、template_id——从头到尾一致，没有哪个文件对不上。跨这么多文件还能咬合住，这其实比写代码本身难。另一个是那个并发队列，它用线程池加队列的单例写法，自己加了一层防重入保护，单测还专门验证了：并发上限设成 2，就真最多同时跑 2 个，一个都不多。

这几件事，没一件是光写代码，靠的都是判断。长程任务里最值钱的，就是这种从头到尾不掉链子的判断。

长程 Coding 的真相：拼的是耐力，不是冲刺

讲到这儿，得说个反常识的事。我们测模型，习惯盯着单次强不强：这道题答对没，这段代码写得好不好。但长程任务不比谁单点爆发，比的是后半程掉不掉速。

GLM-5.2 这个 session，跑了一个半小时。86 分钟，213 条消息，96 次工具调用，62 段思考。

前半程它又快又稳。刚开工那二十分钟，加字段、写队列、调接口，一气呵成，我看着还挺惊喜。但从改数据库那一步起，节奏明显沉了下来——每等一下，它都要先把前面几十轮对话重新捋一遍，才敢动手。越往后，越慢。

我把它的 token 消耗翻出来，找到了原因：

input tokens:     116 万
output tokens:    37.8 万
cache_read:      3240 万

3240 万 cache_read，这数字什么概念？上下文越堆越长，它每一轮都要把这一大坨历史重新读一遍。最后 10 分钟那一段，光 cache_read 就烧掉 1059 万 token。它不光读得多，想得也多——整个 session 光思考就写了 6 万 token，最长一段思考 2.3 万字，在"想"上花的时间一点不比写代码少。

想了这么多，结果呢？交付的代码没有那种"看着对、跑起来崩"的毛病，该过的测试一遍过。

不过这里我得纠正自己一个一开始的判断。我原以为它后半程变慢，全是上下文越长越重拖的。后来一想，不对——慢是 GLM 这条线从 5.1 就传下来的老底子。它习惯把问题想透，这一条你在 5.1 身上也一样等过。1M 上下文不是慢的根源，更像是个放大器：本来就不快的它，上下文越滚越大，每轮还得多背一坨历史，自然越往后越吃力。

说实话，如果让我用一个词概括这次实测——稳，但累。

那它到底慢在哪

我把"慢"拆开看，主要三个地方。

一是它本身就慢。前面说了，这是 GLM 老底子，习惯把问题想透，生成也偏稳，跟 1M 上下文没关系。

二是上下文越滚越大，又给它加了一层。任务一长，每轮都要把前面几十轮历史重新捋一遍。

三是它太谨慎，碰上脏数据还得反复试。整个 session 它 Read 了 27 次，好几回是重复读 articles.py，就为确认一个行号；遇上那个卡 9 分钟的孤儿列，它又前后发了 5 次命令：查表结构、查连接、停服务、清掉残留列、再重跑，才理顺。这种环境问题没法一次命中，得反复试。

中途我实在等得有点烦，手动敲了个"继续"，推它一把。

但公道话说，慢归慢，它一个子任务都没落下。9 个子任务全部完成，队列的单测 15 条全过：

队列管理器单测：15 / 15 通过
前端 npm run build：通过
后端真实冒烟测试：通过

一个半小时交出这么个完成度。说句实在的，这种活儿我自己上手，加调试大半天打底。说它慢，是拿理想速度在比；真跟人手写比，它快得离谱。值不值，你自己掂量。

慢归慢，这账到底值不值

所以回到那个问题：这台又慢又稳的机器，到底值不值得上手？

我的判断很直接：看你拿它干什么。

慢是躲不掉的，前面说了，GLM 老底子加 1M 上下文一起造成的。但慢不一定就是缺点。它适合的场景很明确：大型项目重构、跨多文件改一个功能、需要长期记住项目约定的长任务——这些它能想明白、还扛得住，是 4.7 时代干不了的活。这种时候，你要的是它把活做对，速度慢点能忍。

至于那些跑分——开源 SOTA、长程编码分数超过 GPT-5.5、成本大概只有 Claude 的六分之一——都是真的，可代替不了你自己的体感。

这大概也是为什么，智谱这次搞"先不晒跑分，先让你用上"。用过了，你才知道它对你这个具体场景到底行不行。顺便提一句，它还是华为昇腾训练的，国产算力跑出来的开源模型能站到这个位置，本身挺有意思。

说到底看你怎么用。你只让它写个函数、补个脚本，那 1M 上下文对你意义不大，挑个轻量模型更划算。可你要它接手一个几千行的老项目，从理解到重构全程不丢线，那这点慢，就是为"它真能记住整个项目"付的钱。跟 Claude、GPT 比，单点爆发力它未必占优，但"能扛长任务还开源"这条道上，在国产模型上，现在确实没几个对手。

它不一定适合所有场景，也没必要神化。

小结

长程 Coding 不看哪一步多惊艳，看的是全程掉不掉链子。

GLM-5.2 在我这一个半小时里，交出了一份**“效果不错但慢"的答卷**。效果不错，是因为它的工程判断撑住了整条链路；慢，是 GLM 从 5.1 就传下来的老底子，1M 上下文又给它加了一层。一个是它的长处，一个是它的老毛病，两件事凑成了这份"效果不错但太慢”。

如果是你，你会先拿 GLM-5.2 试长任务重构，还是试跨文件的 Bug 排查？

我是徐公，我们下次见。