想听听 GLM5 的使用感受

[mikifuns]

各路大佬们，在用 GLM5 （尤其是用智谱自己的 coding plan 的用户）
想跟大家请教下各位的使用体验，尤其是中小项目的 vibecoding 选手。
我没抢到官方的订阅，所以入手了腾讯的 coding plan ，用了一个月了，我发现个问题
腾讯的 plan 里面其他模型啥事没有都挺正常的 ，只有 GLM5 这一个模型，很傻
vibecoding 里很多时候都要模型自己想自己调工具，一条的上下文会长点甚至要压缩，
但是 GLM5 官方宣称 200+k 上下文，我配置也按腾讯官方的配置文档走的，
实际使用中，100K 左右时就开始出现包括但不限于：死机（反复复读）、失语（输出乱码）、失忆（不会调用工具，思考链疯狂输出代码）、背叛（开始疯狂输出不知道哪来的问题的回答...驴唇不对马嘴）
这个问题我已经开工单在调查中，但是鉴于网上没见过有人吐槽这个问题以至于我都怀疑是不是我一个人克这个模型，
我虚心向各位大神请教各位在使用 GLM 模型（尤其是 GLM5 ）过程中是否存在以上问题。
如果不存在，我会去 试着抢一下智谱的 plan ，但我现在就怕智谱自家都这样...那就浪费时间了。
跪谢大佬们抽时间回复...ORz

已结案，应该就是这个模型的问题。5.1上线了的话我再试试，不上线就算了，kimi也挺好的。唉。

[CapNemo]

有，但需要到 120k 左右出现

[frantic]

我由于抢不到 zhipu 的买的是 z.ai 的。
已知的问题:
1. 偶见代码编写甚至会漏大括号导致代码报错（很低端的错误）
2. 高端模型的并发过低，不能通过站起来蹬，见 https://www.v2ex.com/t/1204366#reply0
3. 经常 `The service may be temporarily overloaded, please try again later [retrying in 20s attempt #7]`
4. 很慢，感觉 claude opus 或者 GPT 5.4 5 分钟干完的活它要小半个小时，叠加问题 2 你有时候只能干等着

代码能力感觉还行，大概在 claude sonnet 4.6 和 opus 4.6 之间。

[mikifuns]

@CapNemo 差不多，基本上就 100~140k 左右那样，最坏 80 多 k 也出现过，不过算是偶然复读半天了又圆回来了，大部分回答作废的情况都是 100k+的时候坠机

[bleeontheway]

经常遇到，而且是 80K 就比较容易碰到了，所以我一般会尽量控制上下文不超过 80K
遇到复读的情况通常都是 ESC 然后/rewind ，然后重来，基本上都会好

[mikifuns]

@frantic 并发什么的 tpm 什么的我都无所谓了，能干好活就行，犯低级错误的话怕不是它编辑完回过头审查的时候就开始有点忘东西了（健忘症前兆怕不是）。不知道是算力不足还是真的就“不拘小节”...

[mikifuns]

@bleeontheway 80k 对 vibecoding 感觉是不太能接受的... = =|| 碰到前后端交替着改逻辑的情况 128k 都危险

[wat4me]

现在的大模型上下文利用率就 50%，只有 Claude 好一点，70%多，上下文用多点就会有发癫的问题

[kuviki]

官方说乱码问题 5 和 5.1 都修好了

[dalibaxiaoli191]

我跟你用一样的套餐，用 openspec 做会好一点，一般我到 100 多 k 的时候就会手动 compact 一次

[onedge]

聪明，慢，卡

[onedge]

我是 Zai 的 Pro ，GLM5 ，你要走阿里百炼，很稳，也很聪明，帮我定位过很多 BUG 原因；
GLM 5.1 我用的 Zai 官方（目前只有官方），聪明，基本超过 SOnnet4.6 一点，速度问题不谈，没办法解决，上下文的问题你可以通过调整 cc 的配置 100000 的自动 compact：

"CLAUDE_AUTO_BACKGROUND_TASKS": "1",
"CLAUDE_CODE_AUTO_COMPACT_WINDOW": "90000",
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1",
"DISABLE_NON_ESSENTIAL_MODEL_CALLS": "1",
"ENABLE_TOOL_SEARCH": "true"

这几个变量全开，我更激进点，90000 就自动 compact ，这样体验会好很多，问题在于 compact 的多，整个流程会慢上加慢，但是不会断。

[jojopro]

腾讯用的是开源自己搭建的 glm-5 又不是官方自己调教的 肯定不一样啊

[mikifuns]

@jojopro 就是寻思官方自己的可能更好点才来问一下大家 :) 听听大家的感受

[Sezxy]

腾讯的思考死循环遇到，官方的倒好像没遇到过，现在官方的用 glm-5.1

[PerFectTime]

很垃圾，用的海外版。给他一个模块让他了解，使用计划模式提出修改意见，继续沟通方案的时候直接开始写了；另外写出来的东西幻觉太深了，项目里面没有的东西他一直在幻想，根本就跑步起来

[andyskaura]

我是去年便宜的老套餐，GLM5 基本无法使用。
倒不是模型质量问题，像是官方给老用户的排队权重很低，下午 90%概率跑不了需求。

[shilianmlxg]

@Sezxy #14 就是一直重复一段字符串，那大佬你是咋解决的呢？

[pulutom40]

我们公司买的企业版本，不限量使用。感觉还行吧，能用，但就是太慢了。也挺贵的，我一个人，一天干 400 500 块钱的 token

[GopFei]

用的阿里的 coding plan
glm-5 前端写的依托，连 kmini 2.5 都比不了。
后端也还可以，但是有时候让它改什么的时候，动都不动，瞎输出一堆东西。

[mikifuns]

@pulutom40 公司付款版的不限量 XD 我们公司也用了智谱，看起来貌似也还行，但是我们公司不是拿来做开发所以实战上对 coding 影响不好判断

[mikifuns]

@PerFectTime 是的，幻觉这个问题我很担心，输出乱码啥的还是“小白”能明显感知到的，但是如果幻觉的话不仔细看就让他胡诌了。我也是那天看，明明没用到 Google 的资源但是他输出说一个“GoogleXXX 的调用的完善”，后面又说什么销售啊购物车啥的（但是我就再做一个简单的旅行记事本），我才意识到他幻觉了，立即中断了幻想

[PerFectTime]

@mikifuns #21 建议你不要浪费时间在国内模型上，现在 gpt plus 开小号，站内有渠道是 15 块钱一个号一个月，可以搜索一下，囤 3 个号够你猛猛干了

[mikifuns]

@PerFectTime 就 vibe 来说 25%用得到 GPT 的那种战力（所以我有一个 plus 号），但是剩下 75%都属于大部分正经程序员都会改但扔给小白就抓瞎的玩意。
所以才会需要 glm/kimi 一类的平替。如果是公家事也就算了，自己的 ，不赚钱，纯爱好，完了五十一百往里扔，gpt plus 那点额度问 4 轮 5 小时没了，6 轮下来周剩 75%，无法支撑。
就我这个月的花销，50 的火山 lite+腾讯 200Code+GPT120(下个月去🇹🇷订），300+的花销，hmmmm 。
钱毕竟不是刮来的。

[mikifuns]

@PerFectTime 而且长期看 codex 这个玩法不可持续了，毕竟要转成什么 token 代币计费？最近几周... :( Team 车都开走了不是。

[jqknono]

@CapNemo
@frantic
@mikifuns
@andyskaura

和我的体感一样, 120k 有效上下文, 括号低级错误, 下午 lite 套餐 glm5.1 完全不给用.

[hdfg159]

现在明确告诉你，智谱家也会，还是经常出现

[mikifuns]

@hdfg159 谢谢。我决定老实用其他模型了。GLM 还是吹的太厉害了。

[Sezxy]

@shilianmlxg 停止任务后，再继续。

[lyhiving]

如果我说比之前的版本还差点你信不信，目前发现退步了

[defaw]

5-turbo 挺强的，gpt5 水平，知识面差点，思考能力是有的。

[mikifuns]

@lyhiving 信的，就是不知道“自营”怎么样才找各位取经，不信不问嘛~

@defaw 思考上看样子是可以，但是上下文硬伤在这里就属于脑子好使记不住事，小事做的精大事干不成...

[PerFectTime]

@mikifuns #24 能用一天是一天不是, 再不济订阅正价 plus 会员也可以

[spediacn]

智谱我是断然不续费了，比视觉不如 Kimi ，比推理不如 GPT ，却把自己标榜成 Opus 级别的神话，价格提上去就没那么香了。都是干粗活儿的模型吗？我选择了 MiniMax 的 Max ，量大管饱，不要求你自作主张，按精确提示词接受调度干活儿就行了。

[wm5d8b]

终于看到有分享腾讯 coding plan 的 op 了。就搞不懂为啥大家都只讨论百炼，拉人买也是百炼，大家的套餐都一样。

[Jack927]

我的 GLM 去年 10 月订阅的，使用体验上是国内最好的了。注意是国内，和 gpt-5.4 以及 claude code 还是有明显差距。

其他国内的 coding 套餐， 火山的买过，最差劲，模型很老，而且猜测是量化版本，相同问题上的遵循程度和产出都很差。
腾讯没买过，但是使用过 code buddy 中的 glm ， 模型似乎保真，但是适配程度比智谱自己的差好多。
阿里的 coding 拿同事的用过，很好，速度甚至能比智谱自己的还快。

[Jack927]

另外关于复读机，乱码等问题，说实话自己在 claude code 内接智谱的 GLM 这么半年下来没出现过。
补充不是我下上文不够长，因为是在 claude code 默认选的 opus 1M ，有时候忘记手动压缩，直接触发 API 请求报错，也没出现过乱码。 不过长度较长之后，效果确实会明显下降。

[xiangqiankan]

用过几家云厂商和智谱纯血的，字节的 coding plan 最拉垮，模型最老，而且是量化版本，三两下就用完了，体验最好的是官方的和阿里云百炼 coding plan ，量大速度快不排队，也不是量化版本

[V1ncent7]

@onedge glm 5.1 是不是最好也配置 自动 compact

[qqqqqqqq233]

首先你要拆分任务，细化到一次只做一件事，然后再交给子 agent 去做，控制好你的上下文，还是很好用的

[mikifuns]

@PerFectTime 谢谢佬，已找到，先把这个月的开发支棱起来了 OTz
@spediacn 是的，Minimax 虽然没那么神逻辑但是性价比、任务完成度都可以接受的
@wm5d8b tx 的这个感觉有点闷声发财哈哈哈，现在开始推 token plan 了 coding plan 反而没什么讨论，但是就 tpm 与降智与否上我觉得腾讯是一视同仁，保障做的挺好的。我已经开始第二个月的 Pro 订阅了
@Jack927 是的，好像用 claude code 的话好像问题还轻一点，我也打算试着用 claude 接入看看有没有改善。
@xiangqiankan 同样的描述，同样 cli 与模型同样项目提示词，腾讯跑大约 45 个请求（腾讯能看到请求数比较透明，挺好），大约 0.6%，但是火山就跑了 5%（虽然是 lite ，但是 lite：pro=1:5 ，所以折合下来就是 1%，明显多了 0.4%），而且如果是用在 Trae 上，那五小时跑的嗖嗖的，一天跑掉 25%的月额不成问题。火山侧只能看百分比，这就不直观了。反正对比着我 tx 的套餐来看，字节这边的花的最快。。。但是两家请求数一样，单次简单复杂调用数介绍上都一样...差在哪呢.//

[ProphetN]

国产模型使用下来都是一样，编码还行，做项目不行。必须搭配 Claude 、ChatGPT 去做计划，然后再编码。作为省钱工具，不能完全独立使用。

[mikifuns]

@qqqqqqqq233 额对 vibecoding 最大的挑战就是，你就算一次只做一件事，但如果碰到前端、后端，涉及到逻辑要想的情况下，emmm 上下文压不住。而且子 agent 的话现在的 cli 基本上都能同时开几个 sub 干活，如果是其他开 sub 的方法的话我就不知道了，有相关的教程的话 希望能分享学习下 [heart]

[onedge]

@V1ncent7 对，cc 里要设 compact window ，opencode 设 reserve 100000

[NizumaEiji]

能力还行，拿来干活是比较 ok 的，实话说糟心的点虽然多但省在便宜。
不过强烈不推荐智谱的服务，非常差。第三方的例如腾讯云的 glm 反而更好点。

[hassonE1]

lite 用户，glm5.1 速度慢，偶尔会出现 429 报错

[suarez]

pro 用户，用 glm5.1 动不动就速率限制，简直没法用的节奏特别是下午

[SwordSong]

老 pro 用户，200/月那个。glm5.1 情况和 36 楼的差不多，cc 接入的情况下干活没出现过什么问题，顶多就是慢。还有上下文压缩，和 36 楼一样用的默认 opus 1M ，有时要手动压缩。如果遇到实在难啃的问题就是让 gemini 去生成指令然后指挥。

[repus911]

cc 的上下文管理有过特别的设计，我用的事 z.ai 的 glm-5.1 ，慢确实慢。
我一般开过多个窗口，挑一个不重要的，有空看看，效果还是不错的跟 sonet 差不多

[seagoat]

@frantic 同样抢不到 zhipu, 想买 z.ai. 好奇问下, 国内调用 z.ai 需要梯子么?

[VicoHu]

glm pro 用户，glm-5.1 下午直接就是不可用状态，10 次模型交互（不是 prompt 交互）至少 9 次是 429.

[frantic]

@seagoat 这个不太清楚，我梯子基本 7x24 在线的

[sunwangme]

我自己的体感也是，官方标的上下文上限和“能稳定干活的窗口”不是一回事。

很多模型写参数时看着都很大，但一旦进入多轮改代码、反复调用工具、前后端来回切的场景，真正可用的安全区往往会比标称值小很多。尤其是这种需要自己规划再执行的任务，问题通常不是单纯“记不下”，而是上下文一长之后开始复读、跑偏、工具调用变形。

所以我现在会更偏向把它当成工程问题处理：
1. 不等快到上限才处理，80k 到 100k 左右就主动 compact ；
2. 把一个大任务拆成更短的闭环，减少一次会话里跨太多文件和目标；
3. 优先看“长任务能不能稳定完成”，而不是只看短 benchmark 或首轮回答。

如果一个模型标 200k+，但你在 80k 到 120k 就要开始频繁救火，那对实际开发来说，它的可用窗口就还是只有那么大。

[IAmSimon]

max 用户，glm-5.1 已经限制了两次速率了，果断切换讯飞的 glm-5 ，虽然蠢点但是快多了，但智力水平又比不过自己买的 gpt-codex5.3 ，所以个人感觉 glm-5.1 介乎于 gpt-codex5.3 水平，但是很慢，期待百炼 coding plan 接入