说实话，kimi-k3 和 deepseek-v4-pro 的代码差距比我想的微妙——40 道编程题跑三轮，动态规划类重构任务排名出乎意料
标题：说实话，kimi-k3 和 deepseek-v4-pro 的代码差距比我想的微妙——40 道编程题跑三轮，动态规划类重构任务排名出乎意料
正文：
上周我接了个活，要把一个老项目的状态机逻辑从单文件拆成多模块，顺手想测测现在国产模型写代码到底谁强。折腾了三天，拿 40 道真实编程题（不是 LeetCode 原题，是我从项目里抽出来的）分三类跑了三轮，发现一个反直觉的事：在动态规划类的重构任务上，kimi-k3（kimi-k3）的表现比 deepseek-v4-pro（deepseek-v4-pro）稳定，但 glm-5.1（glm-5.1）在简单算法实现上的速度优势被严重低估了。
三个模型没有绝对赢家。选谁取决于你的任务类型，不是 benchmark 分数。
评测维度
我把 40 道题分成三类：
- 算法实现（15 题）：排序变种、图遍历、字符串处理，要求一次生成可运行代码
- 多文件重构（12 题）：给一个 200-400 行的单文件，要求拆成 3-5 个模块并保持接口一致
- Debug（13 题）：给带 bug 的代码 + 报错信息，要求定位并修复
每题跑 3 次取最佳结果，评分标准：能跑通得 1 分，跑通且代码质量合理得 1.5 分，跑不通 0 分。满分：算法实现 22.5 分、多文件重构 18 分、Debug 19.5 分，总满分 60 分。
关于"取最佳"与"稳定性"的说明：计分取三轮最佳，反映的是模型的能力上限；文中另外提到"三轮都一次过"是对稳定性的单独观察，两个维度独立记录，不互相替代。
graph TD
A[40道编程题] --> B[算法实现 15题]
A --> C[多文件重构 12题]
A --> D[Debug 13题]
B --> E[排序/图/字符串]
C --> F[单文件→多模块拆分]
D --> G[定位bug+修复]
评测结果天梯图
| 类别 | kimi-k3 | deepseek-v4-pro | glm-5.1 |
|---|---|---|---|
| 算法实现（满分22.5） | 18.0 | 19.5 | 17.5 |
| 多文件重构（满分18） | 15.5 | 14.0 | 12.0 |
| Debug（满分19.5） | 14.5 | 16.0 | 13.5 |
| 总分（满分60） | 48.0 | 49.5 | 43.0 |
| 首 token 延迟（P50） | 1.6s | 1.1s | 0.8s |
| 平均总输出 token | 约 680/题 | 约 520/题 | 约 450/题 |
看到总分我有点意外——deepseek-v4-pro 只领先 kimi-k3 1.5 分，但分布完全不同。
算法实现谁更稳
deepseek-v4-pro 在纯算法题上确实强，尤其是图遍历和复杂递归。有一道拓扑排序变种题，kimi-k3 第一轮生成的代码漏了环检测，第二轮才补上；deepseek-v4-pro 三轮都一次过。
但 glm-5.1 有个被低估的优势：响应速度快得离谱。简单的字符串处理题，glm-5.1 P50 首 token 延迟 0.8 秒，整题生成完不到 3 秒。如果你用 Cline 做高频代码补全，这个速度差距体感非常明显。
有一道二分查找变种题，三个模型都一次过，但 token 消耗差距大：
| 模型 | 输出 token 数 | 是否包含解释 |
|---|---|---|
| kimi-k3 | 892 | 是，含详细注释+复杂度分析 |
| deepseek-v4-pro | 467 | 是，简洁注释 |
| glm-5.1 | 381 | 否，纯代码 |
kimi-k3 话多这个特点……反正你要是按 token 计费就挺烦人的。
动态规划重构题的反转
这才是我最想说的。
我设计了 4 道动态规划相关的重构题：给一个能跑但写得很烂的 DP 实现（比如全局变量满天飞、状态转移硬编码在一个 300 行函数里），要求拆成独立的 state 定义模块 + transition 模块 + solver 模块。
结果：
| 题目 | kimi-k3 | deepseek-v4-pro | glm-5.1 |
|---|---|---|---|
| 背包问题重构 | 1.5 | 1.0 | 1.0 |
| 区间DP拆分 | 1.5 | 1.5 | 0 |
| 树形DP模块化 | 1.5 | 1.0 | 1.0 |
| 状态压缩DP重写 | 1.5 | 0 | 0 |
| DP小计 | 6.0 | 3.5 | 2.0 |
kimi-k3 四题全拿满分。deepseek-v4-pro 在状态压缩 DP 那道直接翻车了——它把状态定义和转移逻辑拆开之后，新代码跑出来的结果和原始代码不一致。我检查了一下，是它在拆模块的时候把一个位运算的优先级搞错了。
关于 DP 小计与总表的关系：这 4 道 DP 题中 kimi-k3 比 deepseek-v4-pro 多 2.5 分，但多文件重构总分（12 题）两者仅差 1.5 分，意味着其余 8 道重构题 deepseek-v4-pro 反超了约 1 分。其余 8 题涵盖类继承拆分、配置模块抽离等非 DP 场景，deepseek-v4-pro 在这些结构相对清晰的重构任务上表现更稳定，这里没有逐题展开，后续可以单独写一篇。
这和网上常见的"deepseek 代码能力碾压一切"的说法不太一样。我的观察是：kimi-k3 在需要同时理解原始 300 行代码完整语义、再做结构性改写的任务上，输出的模块边界更清晰、接口更一致；deepseek-v4-pro 在短代码生成上更精准，但面对"理解全局再重构"的任务，有时会在细节处理上出错（如上述位运算优先级问题）。我没有足够数据判断这是架构差异还是训练数据分布的原因，仅记录观察到的现象。
Debug 能力差异
Debug 题 deepseek-v4-pro 赢回来了。它定位 bug 的准确率明显更高，尤其是那种报错信息不明显、需要推理执行流程的题。
举个例子，有一道题我给的报错是：
TypeError: Cannot read properties of undefined
(reading 'children') at TreeNode.traverse (tree.js:47)
kimi-k3 直接说"第 47 行的 node 可能是 null，加个判断"——对了一半，但真正的 bug 是上游的 buildTree 函数在某个边界条件下返回了 undefined 而不是空节点。deepseek-v4-pro 三轮里有两轮定位到了根因。
glm-5.1 在 debug 题上表现最弱，有 3 道题它只是把报错信息复述了一遍然后建议"检查一下是否为空"，没给出具体修复代码。
响应速度和 token 消耗对比
这个表对日常用 Cline 或 Cursor 做高频补全的人可能更有参考价值：
| 指标 | kimi-k3 | deepseek-v4-pro | glm-5.1 |
|---|---|---|---|
| 首 token 延迟（P50） | 1.6s | 1.1s | 0.8s |
| 首 token 延迟（P95） | 3.2s | 2.1s | 1.4s |
| 平均输出速度 | ~45 tok/s | ~62 tok/s | ~78 tok/s |
| 40题总输出 token | 27,200 | 20,800 | 18,000 |
| 40题总输入 token（含prompt，三模型相同prompt） | ~52,000 | ~52,000 | ~52,000 |
输入 token 口径说明：此处输入 token 仅含 system prompt + 当前题目 prompt，不含多轮历史上下文，三模型使用完全相同的 prompt，因此数字一致。
glm-5.1 的速度优势在编码场景下体感很强。如果你的工作流是高频短请求（比如在 Cline 里一边写一边补全），glm-5.1 的 P95 延迟只有 1.4 秒，kimi-k3 要 3.2 秒——等得人焦虑。
但如果是一次性扔一个大文件让它重构，kimi-k3 虽然慢但质量高，等一等值得。
不同需求怎么选
| 你的场景 | 推荐 | 原因 |
|---|---|---|
| 日常算法题/面试准备 | deepseek-v4-pro | 准确率最高，token 消耗适中 |
| 大文件重构/模块化改造 | kimi-k3 | 长上下文理解+结构改写最稳 |
| 高频代码补全（Cline/Cursor） | glm-5.1 | 速度快，延迟低，简单任务够用 |
| Debug 复杂逻辑 | deepseek-v4-pro | 根因定位能力最强 |
| 预算极其有限 | glm-5.1 | token 消耗最少，单次成本最低 |
调用方式补充
我跑测试的时候用的是 ofox.io 和 OpenRouter 两个聚合平台交叉验证（避免单一通道的网络波动影响结果）。两个平台的定价策略不同：前者自述 0% 加价对齐官方价格（未独立验证），OpenRouter 官方标注平台加价约 5%（部分模型有差异，以官网为准）。延迟上香港节点对这三个国产模型表现更稳定一些。
利益相关披露：本文测试使用了 ofox.io 平台，上述平台描述均来自其官网自述，未经第三方独立验证，读者使用前请自行确认。
代码调用很简单，改个 base_url 就行（以下为完整可运行示例，base_url 端点以 ofox.io 实际文档为准，使用前请自行核实）：
from openai import OpenAI
client = OpenAI(
api_key="your-key",
base_url="https://api.ofox.io/v1" # 端点请以平台最新文档为准
)
resp = client.chat.completions.create(
model="kimi-k3", # 或 deepseek-v4-pro、glm-5.1
messages=[{"role": "user", "content": prompt}]
)
三个模型的 model ID 分别是 kimi-k3、deepseek-v4-pro、glm-5.1，在平台模型目录里都能找到（2026 年 7 月 3 日核对，以平台实时目录为准）。
我的结论
跑完 40 题我的感受是：网上流行的"谁碾压谁"基本都是以偏概全。
deepseek-v4-pro 综合分最高没错，但它在多文件重构场景下并不稳定，尤其是涉及复杂状态管理的代码改写。kimi-k3 在这类任务上的优势是实打实的，代价是速度慢、token 多。glm-5.1 适合当"快枪手"用，简单任务又快又省。
如果你团队里同时有算法开发和架构重构的需求，我建议混着用——反正现在切模型就改一个字符串的事。
数据基于 2026 年 7 月初个人实测，40 题样本量有限，不同 prompt 风格可能影响结果。厂商自报的 benchmark 分数我没引用，因为和实际体感差距太大，这里只放我自己跑出来的数据。
汇聚全球AI编程工具，助力开发者即刻编程。
更多推荐
5
0- 0
已为社区贡献17条内容
所有评论(0)