背景
今年国产大模型的宣传声量确实很高，几家新品一出来，基本都会拿自己去对标 Claude Opus 这一档。
尤其是最近出来的 GLM 5.1。
还有 Kimi K2.6。
看起来都很能打，但真实体验往往都有点“跑分没输过，实战没稳过”的味道，所以我把最近几个真实使用场景里的体验记录了一下。
这篇文章不做通用 benchmark，也不讨论从 0 到 1 写 demo 的能力，而是聚焦两个更接近日常工作的维度：一是已有项目、已有规范前提下的真实完成效果；二是几家国产模型的 Coding Plan 订阅，大致能提供多少额度。
本文里的 GPT 和 Claude 通过 VS Code 内置的 Copilot 使用；GLM 5.1 和 Kimi K2.6 通过 Kilo Code 使用。测试时 GLM 5.1 的思考强度为 High，Kimi K2.6 为 Max。以下结论基于 2026 年 4 月的个人真实工作流，仅供同类场景参考。
实际体验效果
MiniMax M2.5 和千问 3.6 Plus 我之前简单测过。即便是比较简单的任务，也经常出现理解错误或执行中断。和 Kimi、GLM 的差距还是比较明显的——我个人猜测和参数规模有关，参数量差距摆在那儿，再怎么优化也很难完全抹平。所以这次后续对比里，我主要关注的是 Kimi 和 GLM 这两个系列。
这两个模型在日常简单任务里的表现都不差。虽然整体仍然打不过 GPT 和 Claude，但胜在性价比高，而且国内使用基本没有障碍。
我这次测试和很多公开评测最大的不同在于：我们不是让模型从零开始造一个新东西，而是要求它遵守既有项目的规范、接口风格和设计约束。
很多评测喜欢看“从零造轮子”的效果，但那其实偏离了大多数工程团队的真实 AI 使用场景。大语言模型通常在 0 到 1 阶段更容易给人惊艳感，但在 1 到 100 的增量开发里，背景知识更多、历史包袱更重、边界条件也更复杂，模型更容易出现幻觉和误修。
另外，AI 写出来的代码，在很多情况下比有架构经验的工程师写的代码更难维护。它经常会生成大量“看起来差不多、实际上隐患不少”的相似实现：单元测试也许能过，但里面埋着一些不自己顺逻辑就很难发现的坑。
之前我让 Claude Opus 4.7 参考一份 C++ 接入层实现去写一个 Golang 版本，结果它没有限制缓冲区长度，存在溢出风险。 断线重连时的 token 验证又刚好被单元测试绕过去了，逻辑其实根本不对。 另外它也没有实现恢复期的容灾逻辑，一旦出故障就直接 GG。 所以，只要不是写小工具或玩具项目，AI 生成的代码我都建议必须认真 Review。 否则它在服务端链路里到处埋坑，平时可能靠“刚好没出事”勉强跑通；一旦某个环节轻微抖动，业务就可能跟着出问题。
本次测试的大致任务如下：
- 编写一套 AI agent 指令和 skills，告诉 AI 如何访问阿里云 API、如何鉴权、如何查询文档以及文档目录。
- 让大语言模型操作阿里云 SLS 服务，执行以下任务：
- 分析已有的日志结构和索引；
- 创建 LogStore 和定时 SQL 任务，用于数据清洗并入库；
- 补充遗漏字段和索引设置；
- 创建仪表盘并编写查询语句。
第一个场景：自动阅读文档并创建阿里云资源
在编写查询语句和访问 API 这类任务上，GPT 5.4（高思考强度）、Claude Opus 4.7、GLM 5.1 和 Kimi K2.6 基本都没遇到明显问题。
只有一个查询语句里，Kimi K2.6 把原本应该返回多个分组的逻辑写成了 sum 聚合，算是一个比较明确的失误。
但有意思的是，所有模型——包括 GPT 5.4（高思考强度）和 Claude Opus 4.7——在第一版 SQL 里，都漏掉了 JOIN 相关表的数据范围限制，导致扫描集明显偏大。
好在这类问题在提示一次之后，所有模型都能重新分析并修正到正确方向。
另一个更能拉开差距的问题，是阿里云某个仪表盘的图表单位设置异常。这个问题我分别让 GPT 5.4（高思考强度）、GLM 5.1 和 Kimi K2.6 去处理，差别就明显多了。
| 人工交互阶段 | GPT 5.4（高思考强度） | GLM 5.1 | Kimi K2.6 |
|---|---|---|---|
| 问题提出 | 能分析出大致原因，尝试修复但失败 | 能分析出大致原因，尝试修复但失败 | 能分析出大致原因，尝试修复但失败 |
| 第一次反馈 | 尝试从 UI 可选项中反推设置项，找到正确值后修复成功 | 发现自己第一次分析失败，转而提示用户先设置一个正确样例，再基于样例继续修复 | 能分析出失败原因，但再次尝试仍然失败 |
| 第二次反馈 | - | 人工修正一个图表后，能把其他有问题的图表一并修对 | 能分析出失败原因，但再次尝试仍然失败 |
| 第三次反馈 | - | - | Andante 订阅的 5 小时限频耗尽，任务终止 |
第二个场景：修复仪表盘错误
Kimi K2.6 创建的图表里，系列标签没有按要求正确显示分组信息。
这个问题的起因是阿里云对应的文档页面失效了。也就是说，数据分组本身其实是正常的，SQL 也没写错，问题主要出在图表展示层。
- Kimi K2.6
- 两次收到错误反馈并尝试修复后，仍然没能修对。
- GLM 5.1
- 第一次反馈错误后，先通过 API 拉取数据，但拉取流程有问题，最终没拉到任何有效数据。随后又启动浏览器辅助分析。浏览器登录仍然需要我手动完成，并不是全自动流程；最后依然没解决。
- 第二次通过截图反馈修复失败，但 Kilo Code 没有正确调用 GLM 提供的视觉识别 MCP，导致截图也没分析起来。
- 第三次反馈修复失败后，我在提示词里额外要求它阅读文档，并自动修复失效文档链接。执行过程中应该触发了 Kilo Code 的 Auto Compact，随后直接卡死。
- 失败结束
- GPT 5.4（高思考强度）
- 第一次反馈错误后，先尝试通过 API 拉取数据进行分析，但修复失败。
- 第二次反馈修复失败后，改成写死
series的方式。虽然能显示多条线，但不符合“动态拆线”的原始目标，只能算一次有效但不满足需求的尝试。 - 第三次在我指出不符合需求后，又回退到了原来的实现。
- 第四次我主动提示“换一种图表试试”之后，它正确分析出了可以使用流图，但把图直接改没了（图表类型字段设置错了）。
- 第五次我指出图表消失后，它认为是类型参数传错，于是又还原回了之前那个有问题的版本。
- 失败结束
- Claude Opus 4.7
- 第一次反馈错误后，先判断数据本身是正确的。
- 第二次在我明确“数据没问题，问题出在绘图显示”之后，AI 尝试继续优化，但修复仍然失败。
- 第三次我主动提示“换一种图表试试”之后，它选了柱状图——这个结论本身就是错的，最终依然没修成。
- 失败结束
在没有人工明确提示方向的情况下，这几个模型都没能把问题修掉。
其中 GLM 5.1 还出现过一次卡死（之前我也遇到过其他任务里出现类似情况），这里不排除是 Kilo Code 本身的 Bug。
虽然最后都没解决，但 GPT 5.4 在人工提示后的分析路径基本是对的；Claude Opus 4.7 也在第一次就正确识别出“数据是正确的”这一点。
第三个场景：分析 Kilo Code 的模型调用量
- GLM 5
- 日志里同时存在老版本和新版本的数据记录，但它一次就找到了正确的新版本数据。
- Kimi K2.6
- 第一次找到的是老版本数据，没法分析出结果；
- 第二次在提示“新版本数据的位置和格式可能不一样”之后，才能正确找到数据并分析出结果。
整个操作过程中，Kimi K2.6 的响应速度最快，明显快于另外两个；GLM 5.1 最慢。
Coding Plan 额度
虽然各家模型的缓存命中价和未命中价差得很大，但问题在于：你很难知道它到底什么时候命中了缓存。
所以这里我不再细分“命中缓存”和“未命中缓存”，而是直接按正常使用过程里的真实消耗来估算。这样得到的结果，和日常使用场景下的平均体感更接近一些。
腾讯云和阿里云 Coding Plan
腾讯云和阿里云的 Coding Plan 刚出来那阵子，性价比确实很高，属于典型的“量大管饱”。
以我的使用频率来说，平时并不算高强度，但基本也很难把任何一个限额打到 5% 以上，所以再去放大使用倍率做推算，意义并不大。
这里先贴一下官方文档里目前仍然可以续费的套餐额度，作为后面对比的基线。
| Coding Plan 订阅 | Pro（200 元/月） |
|---|---|
| 5 小时限频 | 6000 次 |
| 周限频 | 45000 次 |
| 月限频 | 90000 次 |
腾讯云和阿里云 Token Plan
各个云厂商的 Token Plan 价格都贵得离谱。我自己没有买，只把它放在这里作为后面对比的参考。
| 腾讯云 Token Plan | Lite（39 元/月） | Standard（99 元/月） | Pro（299 元/月） | Max（599 元/月） |
|---|---|---|---|---|
| 月限制（Token 数） | 35M | 100M | 320M | 650M |
月之暗面 / Kimi
我之前一直没买 Kimi 会员，因为它官方介绍页里对限额的描述一直比较模糊，总让人感觉有点猫腻。
但现在各大云厂商的 Coding Plan 基本都不怎么更新了，反而都在推更贵得离谱的 Token Plan。
为了体验新模型的效果，我这次从最便宜的一档开始，一档一档往上升（由于贫穷，最高档没买，没测），就是想看看它实际到底能给多少用量。
Andante 的额度测试里，我大概两次就消耗掉了 5 小时额度的 166%；Moderato 和 Allegretto 则都是测到周限额约 5%、5 小时限额约 23%。 后面的额度是按比例折算出来的，只能作为一个大致参考。
下面的参考价格按年付折算后的月价来写，这样更接近日常购买成本。
| Kimi 会员 | Andante（39 元/月） | Moderato（79 元/月） | Allegretto（159 元/月） |
|---|---|---|---|
| 5 小时限频（预估请求数 / Token 量） | 86 / 3.8M | 600 / 34M | 1100 / 101M |
| 周限频（预估请求数 / Token 量） | 411 / 18M | 2820 / 158M | 5020 / 466M |
| 4 周限频（预估请求数 / Token 量） | 1622 / 72M | 11280 / 632M | 20080 / 1864M |
从这组数据看，Kimi 的限额大概率主要是按 Token 量在算。
智谱 / GLM
智谱这边我测到的使用情况，大致是 5 小时额度用了 31%，周额度用了 6%。
| 智谱 / GLM | Pro（119 元/月；我较早期的订阅价格是 1200 / 年） |
|---|---|
| 5 小时限频（预估请求数 / Token 量） | 763 / 30M |
| 周限频（预估请求数 / Token 量） | 4200 / 200M |
| 4 周限频（预估请求数 / Token 量） | 16800 / 800M |
GLM 看起来也主要是按 Token 量来计算；至少现在页面上展示的核心统计项，也已经是 Token 数了。
总结
如果只看我这次几个真实工作流里的综合表现，我个人会更偏向 GLM 5.1。 它虽然整体还达不到 GPT 和 Claude 的水平，但作为补充方案，去完成一些不那么深度的编码任务或者比较长的任务，基本是够用的。
我还是挺怀念当初那种“量大管饱”的 Coding Plan。 之前我一直觉得 Kimi 会员偏贵，但这次真用下来，感觉其实还行。它最大的问题不是绝对价格，而是额度描述长期比较模糊，给人的信任感不太好；如果后面再调整计算方式，用户也很难第一时间感知。
单看我这次的粗略估算，Kimi 会员的价格比 GLM 贵 50%，但给到的量大概翻了一倍；再算上其他附加服务，目前阶段它的性价比反而可能更高一点。
不过现在各家云厂商的 Coding Plan 基本都绝版了，我也在犹豫：如果后面长期不更新，是不是干脆退订算了。 无论如何，希望这篇记录能给后面要选模型、选订阅的人提供一点实际参考。