用户反馈GLM-5.2自26日起出现明显降智现象

背景

近期，多位开发者及高级用户反馈称，包括 GLM、Claude 以及 GPT 在内的主流大语言模型出现了明显的性能下降现象，被广泛形容为“降智”。这一现象并非局限于网络高峰期，而是呈现出全天候、持续性的特征。

其中，GLM 模型的“降智”感知尤为强烈且具体。一位资深开发者在 Linux DO 社区分享了他的实测经历：从 5 月 26 日晚间开始，他发现自己封装在「开源」口袋 AI 助理（端午节特供版-L 站特殊适配）中的 GLM 模型，在处理日常高强度任务时频繁报错。该项目旨在替代 L 站收藏夹油猴脚本，并将 Claude code 封装为类似“龙虾助手”的功能，日常不仅用于代码编写，还涉及大量其他高频技能（Skill）调用。

核心内容

该开发者通过具体的工程实践案例，详细阐述了模型“降智”的表现形式及其背后的技术逻辑：

1. 故障现象与触发条件： 自 5 月 26 日晚间起，开发者原本稳定运行的各类 Skill 开始出现大量报错。经过排查，问题根源并非代码逻辑错误，而是 Skill 定义中存在部分“模棱两可”的路径或未定死细节。

2. 模型鲁棒性差异显现： 在 5 月 26 日之前，无论是强模型还是弱模型，均能凭借自身的推理能力填补这些模糊地带，顺利完成全流程。然而，自 26 日起，当模型处于“降智”状态时，面对这些模糊指令，模型无法像以往那样进行合理的推断和补全，而是直接“跑偏”导致流程中断或报错。

3. 对比验证结论： 开发者指出，同样的模型版本、同样的 Skill 代码，在“智商在线”时能完美运行，而在“降智”时则无法处理非确定性场景。这种从“无错”到“全错”的转变，成为了判断模型能力下滑的直接证据。

4. 跨模型普遍性： 除了 GLM，开发者还提到 Claude 和 GPT 也出现了类似的降智迹象。在经历深思熟虑后，开发者曾从 Claude 退款并切换回 GLM，但随即发现 GLM 也未能幸免。

5. 渠道与版本差异： 在后续的二编中，开发者补充了关于不同接入渠道的投票结果，区分了“OpenCode Go”（开源/第三方渠道）与“官方订阅”在降智感知上的差异，暗示不同渠道可能使用了不同的模型版本或后端配置，导致用户体验不一。

关键要点

• 降智非高峰期专属：GLM 的降智现象不分网络高峰期，即使在非高峰时段使用，开发者仍能明显感知到模型能力的下滑。
• 模糊指令作为“压力测试”：未定死路径或存在歧义的 Prompt/Skill 定义，成为了检验模型当前推理能力的试金石。强模型能容错，弱模型（或降智模型）则直接崩溃。
• 全行业性焦虑：从 Claude 到 GPT 再到 GLM，主流商业模型均被用户反馈存在性能波动，导致开发者陷入“无可用模型”的困境。
• 开源渠道与官方渠道的差异：OpenCode Go 等开源或第三方聚合渠道与官方订阅渠道在模型表现上存在差异，用户需根据实际投票结果选择更稳定的接入方式。
• 工程实践的反向验证：开发者通过长期、高强度的自动化工作流（如替代油猴脚本的 AI 助理），以工程化的方式量化并验证了模型能力的隐性衰退，而非仅凭主观感觉。

意义与影响

1. 对 AI 应用开发者的警示： 此案例表明，依赖大模型进行自动化工作流开发时，必须假设模型存在“非确定性”或“能力波动”。开发者应尽可能消除 Prompt 和 Skill 定义中的模糊地带，采用更严格的约束条件（如定死路径、增加校验步骤），以提高应用在不同模型状态下的鲁棒性。

2. 模型质量监控的新维度： 传统的模型评估多基于基准测试集（Benchmark），而此案例展示了“真实世界工作流”作为评估标准的重要性。高频、复杂的实际应用场景能更敏锐地捕捉到模型在推理逻辑、指令遵循等方面的细微退化。

3. 用户信任危机与替代方案探索： 主流模型的频繁“降智”加剧了用户对 AI 服务稳定性的不信任。这将促使开发者更多地转向开源模型、本地部署方案，或探索如 OpenCode Go 等可能提供不同后端配置的第三方渠道，以分散风险。

4. 提示词工程（Prompt Engineering）的演进： 面对模型“智商”波动，提示词工程需要从“如何让模型聪明”转向“如何让模型在笨拙时也能不出错”。结构化输出、思维链（CoT）的强制约束、以及多步验证机制将成为标配。