3月27号，智谱GLM-5.1，突然上线了！

这次来得太快、太猛，距离GLM-5发布也才一个多月。

这次发布，官方公告很是低调，只有寥寥一句话：

GLM-5.1现已面向GLM Coding Plan全部用户(Lite/Pro/Max)开放。

别的没再多说，只是默默甩出Coding Evaluation评测结果——

在编程能力上跑分45.3,相比上一代GLM-5直接飙升近10分。

甚至嘛，距离当前全球最强编程模型Claude Opus 4.6，也就只有2.6分之差！！！

换句话说：一个开源模型，做到了闭源天花板94.6%的水平。 这不是渐进式的进步，这是降维打击。

此外值得一提的是，此次的GLM-5.1版本率先向GLM Coding Plan所有用户开放，是的，你没听错，面向所有GLM coding plan用户。（Lite用户也能用了～）

我要哭晕在厕所，我花了大几千块钱的Max包年套餐，是不是白开了😭

翻看官方资料得知，此次官方对GLM-5.1模型的升级定位：它是面向长程任务的开源第一模型，在长时间跨度、长链路依赖、多工具协同、持续执行、目标保持等关键能力方面有显著提升，能像资深工程师一样交付完整工作的目标。

啥意思？❓

什么是长程任务？简单来说，长程任务就是：需要多轮交互、要分很多步骤一步步推进，还得记住前面干了啥、后面该干啥的复杂任务。或者你可以理解为步骤多、链条长、强依赖、需要长期规划、具备状态记忆、跨文件工程、和持续跟进的端到端复杂项目交付任务。

是否具备长程任务能力，是衡量 AI Agent 从 “工具调用” 走向 “自主执行复杂任务” 的核心标尺。也是衡量模型真实智能的新门槛，而GLM-5.1是当前长程任务的开源模型断档第一。

接下来，我用通俗且不失专业的方式，帮你解释一下，这次 GLM-5.1主要升级的核心能力有哪些：

• 拥有更强的长程规划与目标保持： 就是说，你给它一个目标，它自己拆出整条路径。 GLM-5.1支持把复杂目标拆解为可执行的多阶段计划，并在长链路执行中始终围绕最终交付推进——不是”你说一步它做一步”，而是自主规划、自主推进、中途遇到意外自己修正，减少跑偏、遗忘约束或陷入局部最优。模型能够自主完成需要数小时、跨十几个步骤的完整工程任务，交付物可直接使用。
• 更稳的多工具协同与持续执行： 不是”会做一步”，而是”能跑完全程”。 模型在代码编写、工具调用、环境调试、API对接等多个环节之间实现了更稳定的衔接，支持更长时间跨度的连续执行。过去开源模型在长任务后半程容易断链、需要人工介入的问题，在GLM-5.1上得到了显著改善——中间环节出错时能自主排查修复，而不是停下来等你。
• 更好的状态延续与上下文整合：干到第十步，还记得第二步定的规矩。 面对长时间跨度、多轮反馈和大量上下文信息，GLM-5.1能稳定地追踪已完成的内容、当前所处阶段和下一步关键动作，持续整合新信息，保持执行链路的一致性。不再出现”做到一半忘了前面的约束”的问题。

上面讲了这么多文绉绉的内容，作为国产AI大模型的拥立者，这次GLM-5.1模型的发布，没有啥好说的，直接开测。

GLM-5.1 如果从数据上来看，这份成绩单，可以说是直接把牌桌掀了：

编程能力：

• 编程评测得分 45.3（Claude Opus 4.6 为 47.9）
• SWE-bench Verified 77.8%——开源模型史上最高
• 相比上代GLM-5提升了整整 28%

需要强调的是，这个评测只有通过 Claude Code 接入的模型才有数据，Gemini 3.1 Pro（用 Antigravity）和 GPT-5.4（用 Codex）并没有可比数据，所以图里只展示了有真实成绩的模型。

GLM-5.1 这次模型升级，并不是简单的”加参数、堆数据”，它此次的进化路线非常有章法, 先看张表格

什么？你说你看不懂？？？

额🤣，那也没关系，我直接来帮你解释一下：

• 架构升级： 从355B参数（32B激活）扩展到744B参数（40B激活）的MoE架构。注意，激活参数只增加了8B，但能力飞跃式增长——这说明架构效率极高。
• 数据飞轮： 预训练数据从23T token扩展到28.5T token，覆盖面更广、质量更高。
• 长上下文支持： 集成了DeepSeek Sparse Attention（DSA），在保持202K上下文窗口的同时，大幅降低了部署成本。

关键创新——Slime异步强化学习框架： 这是智谱自研的RL训练框架，名字很有意思，叫”史莱姆”。这套框架让模型在推理和代码能力上获得了质的飞跃，而且智谱已经将其开源。

技术牛不牛？牛！

但对于大多数的开发者和普通用户来说，更关注的是价格，你牛，但价格死贵，也不见得所有人都愿意为你牛买单，不是吗？

这次GLM 5.1更让人坐不住的是它的价格，直接上对比：

GLM-5.1的输入成本是Claude Opus的1/5，是GPT-5.4的1/2.5。输出成本更夸张——仅为Claude的1/7.8，GPT-5.4的1/4.7。

简单来说：94.6%的Opus能力，20%的价格。比GPT-5.4也便宜了一大半。

单一维度看不出全貌，我从代码生成、推理能力、上下文长度、工具调用、中文能力、性价比、代理能力七个维度给它们打了分（注意：这是我的个人主观评估，不是官方数据）：

雷达图能直观看出每个模型的偏科情况。GLM-5.1 在中文能力和性价比上遥遥领先，但推理和上下文长度上还有差距。Gemini 3.1 Pro 在推理维度拉满了确实猛。

牛不牛，好不好用，还是得用真实项目来检验，考虑到大多数的读者都是测试/开发领域的小伙伴，因此我们挑一个大家平常工作中最常接触一个提效场景：

【需求文档一键转换测试用例、测试代码】通过这个场景来验证一下GLM-5.1长程能力到底够不够强！

测评设计思路

1、首先，打开cc-switch，将模型配置为GLM-5.1

2、打开命令行终端，进入项目目录，输入claude进入到Claude Code中，

3、先让AI帮我们生成一份需求文档，用于测试GLM-5.1模型 长程理解 + 需求转测试用例 / 测试代码 的能力。

比如，此处我希望 GLM-5.1 帮我自动生成一份完整、规范、可用于测评的「微信支付场景需求文档」。

生成需求文档提示词（你也可直接复用）

你是一名产品经理，请帮我生成一份完整、规范、可直接用于测试开发的【微信支付功能需求文档】。 场景为：移动端 H5 页面 + 后端接口实现的微信支付完整流程。

要求：

1. 文档结构清晰，包含：功能概述、业务流程、接口定义、字段说明、支付状态流转、异常处理、安全规则、边界约束。
2. 覆盖完整支付链路：创建订单、调用微信支付、支付回调、订单状态更新、支付重试、支付超时、退款、关单。
3. 明确字段约束：订单号、金额、商品描述、过期时间、支付状态码、回调签名校验、幂等机制。
4. 加入足够多的业务规则、异常场景、边界条件，以便后续生成高质量测试用例。
5. 语言正式、逻辑严谨，篇幅适中偏长，用于测试大模型长文本理解与一致性能力。

请直接输出完整需求文档，保存到word文档中，不要提问、不要省略。

如果你想让文档更长、更适合测 “长程能力”，可以在末尾加一句（可选，按需）：

请扩展为长篇详细需求，包含完整业务规则、多端交互、安全策略、风控逻辑、退款流程、对账逻辑，整体篇幅不少于10000字。

将上述提示词复制，发送到Claude Code

Claude Code调用GLM-5.1模型，会先创建了一个Python脚本（用于创建Word文档），稍等了几分钟后，就在当前工作目录下，自动生成了一份微信支付功能需求文档PRD.docx

打开看了一下，需求文档中的很多内容细节，还是写的非常详细的。

当然，生成需求文档这一步只是我们准备的测试素材（在日常工作中，这一步都是由产品经理来准备），并不是此次我们测评的重点，接下来，我们就用它来验证一下 GLM-5.1 长文本理解、逻辑一致性、跨段落关联能力。

4、验证GLM-5.1的长程能力，可以有两种玩法：

第一种，采取分段迭代策略：

• 需求文档 → 标准测试用例
• 基于测试用例 → 可运行测试代码（接口 / UI 二选一）
• 长文本压力测试（验证 GLM-5.1 长程能力）

第二种，就显得更为简单粗爆一些，将所有的交付生成要求，一次性喂给GLM-5.1。这种方式，简单且更考验模型对长文本理解、逻辑一致性的能力。

因此，我们采用第二种方式。

输入提示词（可直接使用）

【角色设定】 你是一位资深测试架构师，擅长需求分析、测试设计、自动化测试开发。你的任务是将产品需求文档转换为完整的测试交付物。

【输入材料】 《微信支付功能需求文档PRD.docx》

【任务要求】

请基于上述需求文档，完成以下交付物：

1. 测试用例集（Excel/JSON格式）
   • 按功能模块分组
   • 每条用例包含：ID、模块、标题、前置条件、测试步骤、预期结果、优先级（P0-P3）、关联需求章节
   • 严格覆盖：功能测试、边界测试、异常测试、参数校验、业务流程测试
   • 必须基于需求原文，不臆造功能，不漏测核心逻辑
   • 对长文本需求保持全程理解一致，不出现前后矛盾
   • 业务规则、流程、约束必须前后一致
   • 确保需求文档中所有”必须”“应当”“禁止”等关键词都被覆盖
2. 自动化测试代码（Python + Pytest）
   • 测试用例与代码必须严格对齐需求，不能冲突
   • 代码需有详细注释，且可直接运行，结构规范
     • 包含：页面对象模型（POM）、测试数据构造、异常断言、日志记录
       
       
       
       
       
3. 覆盖度分析报告
   • 列出需求文档中每个章节被哪些用例覆盖
   • 标注未被覆盖的需求点及原因
   • 给出测试策略建议（哪些适合自动化、哪些适合人工）
4. 风险识别
   • 从需求文档中识别模糊、矛盾或难以测试的描述
   • 提出需要产品/开发澄清的问题清单

【输出格式】

• 使用Markdown分章节输出
• 代码块需标注语言类型
• 关键决策点用【说明】标注你的思考过程

【约束条件】

• 必须基于文档原文，不可臆测未提及的功能
• 若需求存在歧义，列出多种理解方案而非猜测
• 保持与需求文档术语一致，不自创概念

  

  生成速度很快，几分钟后，4份交付物就生成好了：

  • 测试用例
  • 自动化测试代码
  • 覆盖率分析报告
  • 风险识别报告

  

  我们分别来验证一下，这些交付物的内容质量。

  

  先来看一下测试用例集，但当前只生成了一份json格式的用例，并没有生成excel格式。

  可能还有人会不解，为什么自动生成用例时，要让它生成一份json格式呢？

  给大家补充一下：

  之所以要求生成 JSON 格式的测试用例，是因为目前绝大多数测试管理工具、用例平台都支持 JSON 直接导入，可以一键批量录入，非常高效。

  同时现在很多团队习惯用思维导图编写用例，而思维导图底层存储和交互的数据本质就是 JSON 结构。

  这意味着：拿到标准 JSON 用例，就能轻松转换成思维导图形式的用例，格式互通、灵活复用。

  这里，为了便于查看，我们还是让它帮我们补充一份excel格式的用例。可以看到它在帮我们生成excel格式用例时，也是以json格式作为基础来转换。

  

  很快，几乎不到一分钟的时间，就帮我们生成好了excel版的测试用例

  

  打开excel版的测试用例，可以看到它帮我们生成的用例基本上都是接口类型的测试用例，怎么说呢？勉强还算可以吧，用例生成的内容是否能达到我们直接可用的程度，一方面与我们自身的测试目标有关，另一方面与提示词本身的质量也有极大影响。

  

  

  

  生成好的代码，可以直接打开一个编辑器，比如PyCharm，尝试运行一下，什么，报错了？别紧张，这是因为，我们并没有一个真实在运行的服务且域名是https://api.example.com/api/v1, 在你的使用场景下，你只需要将你需求文档和测试域名替换成你真实的即可。

  

  除了测试代码，还生成了一份覆盖率分析报告，主要罗列了哪些业务场景是有测试用例覆盖的、未覆盖的需求点原因是什么、哪些场景适合自动化、哪些又需要人工介入。

  而这些内容，其实就是我们测试报告中要体现的一些内容。

  

  

  

  可以看到，这个项目并不是一个真实在运行的项目，测评起来还是差点意思，因为无法直接看到真实场景下的实际效果。

  在AI 进化社中，近期我们准备带着在家，开始开发第四个实战项目，一个全栈应用，这个应用会对标企业真实的项目场景，该项目也会作为后续大模型测评、AI测试、AI智能体学习的实战演练靶场项目。

  AI Coding 正在经历一条非常清晰的能力跃迁路径。

  最早的AI coding，本质上是程序员的效率工具。模型学会写代码、调用工具，但它主要还是一个辅助者，服务对象是专业开发者，作用方式是局部提效。

  而之后的Vibe Coding，Coding从专业行为变成一种更大众的表达方式。人们不需要理解每一行代码，但可以借助更好的 Coding Tools，把想法快速变成产品原型。

  在这个阶段，Code is Cheap，拥有好的idea的值开始凸显。

  再后来则是 Agentic，编程不再只是为了写出一个代码片段，而是为了让 AI 像真正的工程师一样，能够自主理解需求、制定计划、编写代码、测试并迭代修复。

  而我们认为，下一个真正决定模型分层的阶段，是 long horizon (长程任务)。

  因为真实世界里最有价值的任务，往往都不是一句提示词、一次调用可以解决的。它们需要跨步骤、跨工具、跨时间地持续推进，需要记住上下文，保持目标一致，处理中途的意外并在必要时修正路径。模型能否胜任这类任务，取决于是否具备更memory、更成熟的目标保持能力，以及更接近资深专家的行为模式。

  如果说 AI coding 解决的是“让模型会做事”，Vibe Coding 解决的是“让更多人能创造”，Agentic 解决的是“让 AI 能执行”，那么 long horizon 要解决的就是“让 AI 像一个资深专家一样持续工作、交付成果”。

  我相信这是智谱AI团队，打造GLM-5.1的原因。

  GLM-5.1 的发布让我看到了一个趋势：开源模型的编码能力正在快速逼近闭源头部模型，当它在 Claude Code 评测中达到 Opus 94.6% 的编码能力时，那剩下的 5.4% 差距在大多数日常开发场景中是感受不到的。

  GLM-5.1 所代表的 long horizon 能力提升，正在把模型进一步推向下一个阶段：像一个资深工程师一样，在更长时间尺度上持续工作，协调复杂依赖，并交付完整结果。

  长程任务是检验模型智能的下一个标准，当模型能稳定搞定中高级工程任务，人类工程师的不可替代性进一步减少。当GLM-5.1 做到了资深工程师的水准，而我们人类需要找到新的不可替代性。

  技术改变世界！ –狂诗绝剑