JeecgBoot AI 专题研究 | Kimi K3、GLM-5.2、DeepSeek V4 Pro 编程实战体验与客观数据交叉验证

写在前面：从 Claude Code 封号开始的折腾

说实话，这篇文章不是纯粹看榜单写出来的，是我真金白银（以及大量加班时间）换出来的踩坑记录。

事情要从 Claude Code 封号潮说起。一夜之间主力工具没了，项目不等人，只能赶紧找替代方案。于是过去一个多月我几乎是「见一个试一个」：DeepSeek Pro4、MiniMax M3、GitHub Copilot、Cursor CLI、Codex 5.5，再到最近刚放出来的 Kimi K3，以及现在稳定当主力的 Kimi 2.7 高速版。

这篇文章只聊一个方向：编程。不是通用问答，不是写作文，不是做数学题，就是实打实的写代码、改代码、理解项目上下文。我的结论可能和榜单不完全一致，但都是键盘上敲出来的真实感受。

DeepSeek V4 Pro：速度快，但低级错误让人头大

DeepSeek 的性价比在国内模型里一直很能打，API 价格几乎是白菜价，所以第一时间就接进来试。

实际编程体验怎么说呢？速度确实可以，响应不拖沓。但问题是低级错误太多了：编译错误、类型不匹配、import 错、把旧 API 当新 API 用…… 经常是它写完一版，我还要花十分钟帮它 debug。最难受的是这些错误不是业务逻辑复杂导致的，而是只要认真看一眼就能避免的「基本功问题」。

客观数据上 DeepSeek V4 Pro 并不弱，参考评测里它在 SWE-bench Verified 上能跑到 80.6%，长上下文 MRCR 1M 也有 83.5 分，参数规模 1.6T，输出长度能到 384K。但落到我的日常开发里，它就是那个「便宜大碗但总要返工」的选手。

如果你预算紧张、任务相对标准化，DeepSeek 依然是好选择；但如果是复杂工程，需要它一次性把活儿干漂亮，我目前不太敢把核心模块交给它。

MiniMax M3：Java 方向稳，但慢到让人崩溃

从 DeepSeek 换到 MiniMax M3 之后，第一感觉是：终于没有那些低级编译错误了。尤其在 Java 后端开发上，M3 的代码结构、Spring Boot 相关写法、依赖注入的理解都算得上规矩，出错的概率明显低一档。

但新的问题接踵而至：太慢了。不是那种「稍微等一等」的慢，是写一段稍微复杂点的逻辑就要盯着光标转圈，长到我开始怀疑是不是网络断了。用久了之后工作效率反而下降，因为思路老是被打断。

参考榜单里 MiniMax M3 虽然没有被单独拿出来和 Kimi K3 / GLM-5.2 / DeepSeek V4 Pro 做同维度比较，但从我自己的使用节奏看，它属于「能力够但体验打折」的类型。如果你不在意等待、对代码稳定性要求高，M3 还能用；但对我来说，慢到受不了就只能再换。

Cursor CLI 与 Codex 5.5：工具层面的遗憾

中间也试过国外工具路线。Cursor CLI 整体交互做得不错，但有个很致命的点：不支持图片。有些场景下需要截图给 AI 看 UI 或报错，直接就没法用，只能放弃。

Codex 5.5 能写代码，但写完总是不满意。它的修改方式更像「哪里报错改哪里」，缺乏对项目全局上下文的理解，改出来的代码经常是东拼西凑，能跑但不优雅，后续维护成本不低。 Claude Code 之前最让我离不开的，恰恰是它能把整个仓库的上下文串起来做决策；Codex 在这方面差了一截。

Kimi K3：周五惊艳，周六掉链子

Kimi K3 出来的那个周五下午，我几乎是抱着「再试最后一次」的心态点开的。结果出乎意料地好：

• 写代码思路清晰，能把需求拆成合理的模块；
• 上下文理解明显强于 Codex，能跨文件找关联；
• 速度比 M3 快很多，响应流畅。

当时的感觉是：终于有一个能接近 Claude Code 体验的国产模型了。

但周六晚上再测，同样的问题同样的复杂度，响应速度却明显慢了下来，慢到让我怀疑是不是用户量暴增、服务资源跟不上了。这个波动让我有点犹豫 —— 如果稳定性不能保证，关键时刻掉链子也是很要命的。

从公开数据来看，Kimi K3 确实是三款国产模型里综合最强的一个：总参数 2.8T，DeepSWE 67.5、FrontierSWE 81.2、SWE Marathon 42.0，代码智能体能力领先；多模态支持文本、视觉、视频；高难度推理 GPQA-Diamond 93.5。榜单和我的周五体验是吻合的，但周六晚上的速度波动也提醒我：能力再强，稳定性也是生产力的一部分。

现在稳定的主力：Kimi 2.7 高速版

折腾了一圈之后，我目前稳定下来的是 Kimi 2.7 模型的 kimi-for-coding-highspeed。

它的优势非常直接：速度快，编码能力也没短板。不需要像等 M3 那样等半天，也不像 DeepSeek 那样时不时冒低级错误，更不像 K3 那样出现明显的速度波动。写 Java、改配置、处理中等复杂度的业务逻辑，它都能比较稳地接住。

当然，它可能不像 Kimi K3 那样在复杂智能体任务和长上下文输出上那么惊艳，但对于日常编程这种高频、重复、需要快速反馈的场景，「没什么弱的感觉」本身就是很高的评价。

榜单数据再验证：综合最强≠最适合你

参考评测对三款国产开放权重大模型做了更系统的横向对比，结论和我上面的体验基本能对应上：

• 综合能力：第一名 Kimi K3，综合指数约 57
• 代码智能体：第一名 Kimi K3，关键数据包括 SWE Marathon 42.0、Automation Bench 30.8
• 长上下文输出：第一名 DeepSeek V4 Pro，最大输出 384K token
• 推理速度：第一名 GLM-5.2，约 168 tokens/s
• 多模态能力：第一名 Kimi K3，覆盖文本、视觉、视频
• API 成本：第一名 DeepSeek V4 Pro，输出约 0.87 美元 / 百万 token

GLM-5.2 在榜单里走的是「小而快」路线，744B 参数规模，速度达到 168 tokens/s，综合能力约 51 分，性价比和响应速度都很突出。如果我没被速度折磨到受不了，可能会更早注意到它。

结论：谁的编码能力第一？

如果只看客观榜单，Kimi K3 是当前国产模型里代码和复杂智能体能力最强的，综合能力、代码智能体、高难度推理、多模态都是它领先。

但如果问我现在日常开发用谁？答案是 Kimi 2.7 高速版。因为它在速度和稳定性上最符合「干活」的节奏。

对于其他几款：

• DeepSeek V4 Pro：适合预算敏感、能接受返工的场景，API 成本优势巨大；
• MiniMax M3：Java 方向代码质量还可以，但速度是硬伤；
• Cursor CLI / Codex 5.5：工具和模型层面还有明显短板，暂不适合作为主力。

所以「谁的编码能力第一」这个问题，其实有两个答案：榜单第一是 Kimi K3，我当前的生产力第一是 Kimi 2.7 高速版。 能力上限和稳定交付，有时候并不是一回事。

总结

Claude Code 封号之后，我被迫把国产模型和国外替代工具试了个遍。最深的体会是：不要只看发布会和 benchmark，真正拿到项目里跑几天，才能知道谁是你的「真生产力」。

Kimi K3 代表了国产模型在代码能力上的上限，DeepSeek V4 Pro 代表了成本效率，GLM-5.2 代表了速度与参数规模的平衡。而我个人的选择，是先把稳定性放在第一位 —— 这或许也是很多一线开发者最朴素的共识。

本文为 JeecgBoot AI 专题研究系列文章。