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主要升级的核心能力有哪些：
上面讲了这么多文绉绉的内容，作为国产AI大模型的拥立者，这次GLM-5.1模型的发布，没有啥好说的，直接开测。
GLM-5.1 如果从数据上来看，这份成绩单，可以说是直接把牌桌掀了：
编程能力：
需要强调的是，这个评测只有通过 Claude Code 接入的模型才有数据，Gemini 3.1 Pro（用 Antigravity）和 GPT-5.4（用 Codex）并没有可比数据，所以图里只展示了有真实成绩的模型。
GLM-5.1 这次模型升级，并不是简单的"加参数、堆数据"，它此次的进化路线非常有章法, 先看张表格
| 参数项 | 规格 |
|---|---|
| 总参数数量 | 744B (MoE 架构，256个专家) |
| 活跃参数 | 40B |
| 上下文窗口 | 200K tokens |
| 最大输出 | 131,072 tokens |
| 架构特性 | MLA + DeepSeek Sparse Attention |
| Claude Code 编码评分 | 45.3 (Opus 4.6 为 47.9，达 94.6%) |
什么？你说你看不懂？？？
额🤣，那也没关系，我直接来帮你解释一下：
架构升级： 从355B参数（32B激活）扩展到744B参数（40B激活）的MoE架构。注意，激活参数只增加了8B，但能力飞跃式增长——这说明架构效率极高。
数据飞轮： 预训练数据从23T token扩展到28.5T token，覆盖面更广、质量更高。
长上下文支持： 集成了DeepSeek Sparse Attention（DSA），在保持202K上下文窗口的同时，大幅降低了部署成本。
关键创新——Slime异步强化学习框架： 这是智谱自研的RL训练框架，名字很有意思，叫"史莱姆"。这套框架让模型在推理和代码能力上获得了质的飞跃，而且智谱已经将其开源。
技术牛不牛？牛！
但对于大多数的开发者和普通用户来说，更关注的是价格，你牛，但价格死贵，也不见得所有人都愿意为你牛买单，不是吗？
这次GLM 5.1更让人坐不住的是它的价格，直接上对比：
| 模型 | 输入价格（/百万token） | 输出价格（/百万token） |
|---|---|---|
| GLM-5.1 | $1.00 | $3.20 |
| Claude Opus 4.6 | $5.00 | $25.00 |
| GPT-5.4 | $2.50 | $15.00 |
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技术感兴趣，想学习更系统的AI测试、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 做到了资深工程师的水准，而我们人类需要找到新的不可替代性。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。