说实话，deepseek-v4-pro 写代码比 qwen3.7-max 猛——但我拿 glm-5.1 跑了 45 道真实任务，有一类重构题结果让我没想到

上个月团队在做技术选型，要给内部的 Code Review 工具接一个代码生成/重构的后端。我花了差不多一周时间，拿 deepseek-v4-pro、qwen3.7-max、glm-5.1 三个模型跑了 45 道真实编程任务。结论先放这儿：算法题 deepseek-v4-pro 碾压，业务逻辑 qwen3.7-max 稳，但代码重构这个维度——glm-5.1 拿了 15 道题里的 11 道最高分，逆袭得我有点懵。

不是水文，下面全部附测试用例、评分标准和可复现的 prompt，你拿去自己跑一遍就知道了。

评测维度与评分标准

我把 45 道题分成三类，每类 15 道：

维度	题目来源	评分标准（满分 10）	权重说明
算法题	LeetCode Medium/Hard 真题	正确性 5 分 + 时间复杂度 3 分 + 代码风格 2 分	pass@1，不给第二次机会
业务逻辑	真实项目需求（CRUD/权限/状态机）	功能完整 4 分 + 边界处理 3 分 + 可维护性 3 分	一次生成，不追问
代码重构	屎山代码片段（200-500 行）	结构改善 4 分 + 命名/抽象 3 分 + 不改变行为 3 分	必须保持原有测试通过

评分由我和另一个同事独立打分取平均，有争议的题目（分差 > 2）拉第三人仲裁。不是什么严谨论文，但比拍脑袋强。

评测结果

直接上总表：

模型	算法题均分	业务逻辑均分	代码重构均分	总均分
deepseek-v4-pro	8.4	7.6	6.9	7.63
qwen3.7-max	7.8	8.1	7.2	7.70
glm-5.1	6.9	7.0	8.5	7.47

没看错——总分三者差距很小（0.23 分），但单维度拉开得很明显。

graph LR
 A[45道编程任务] --> B[算法题 x15]
 A --> C[业务逻辑 x15]
 A --> D[代码重构 x15]
 B --> E[deepseek-v4-pro 胜出]
 C --> F[qwen3.7-max 胜出]
 D --> G[glm-5.1 逆袭]

算法题：deepseek-v4-pro 确实猛

这个维度没什么悬念。我拿了 LeetCode 的「合并 K 个排序链表」「最长有效括号」「编辑距离」这类 Hard 题，deepseek-v4-pro 的 pass@1 正确率达到 13/15。

一道典型测试 prompt：

# 测试用例：LeetCode 32 最长有效括号
prompt = "实现 longestValidParentheses(s: str) -> int，要求 O(n) 时间 O(1) 空间"

deepseek-v4-pro 直接给了双指针解法（O(n) 时间、O(1) 空间），还标注了复杂度。qwen3.7-max 也给了正确解但用了 O(n) 空间的栈方案，没满足 O(1) 空间约束。glm-5.1 在这道题上直接写了个 DP，复杂度没达标扣了 3 分。

这个结果符合预期——DeepSeek 系列在纯算法推理上一直很强。

业务逻辑：qwen3.7-max 的工程感最好

业务逻辑题我出的是真实需求，比如「实现一个支持优先级队列的任务调度器，要求支持取消、超时、重试三种策略」。

qwen3.7-max 生成的代码有几个让我印象深刻的点：

• 主动加了 TypedDict / dataclass 做类型约束
• 边界条件（空队列、重复取消、超时后重试上限）处理得很全
• 会拆文件，告诉你"这个建议放 scheduler/retry.py"

deepseek-v4-pro 功能也全，但风格更像"竞赛选手"——一个函数 80 行，能跑但你不想维护。glm-5.1 在这个维度中规中矩，偶尔漏掉一两个边界。

重点：代码重构——glm-5.1 为什么逆袭？

这是我最想聊的部分。

我的重构测试题长这样：给一段 200-400 行的"屎山"Python/TypeScript 代码（真实项目里扒出来的，脱敏过），要求模型重构但不改变外部行为。评分核心是「改得好 + 没改坏」。

一道真实测试 prompt（简化版）：

# 原始屎山：一个 300 行的 process_order 函数
# 包含：嵌套 if 7 层、重复的数据库查询、硬编码的业务规则
prompt = f"重构以下代码，要求：1.拆分职责 2.消除重复 3.保持所有现有测试通过\n\n{ugly_code}"

glm-5.1 在 15 道重构题里拿了 11 道最高分。具体分析原因：

1. 保守策略反而是优势。

deepseek-v4-pro 重构时太"激进"——它会把整个架构推翻重来，引入设计模式、抽象工厂什么的。结果 15 道题里有 6 道改完跑不过原有测试（改变了外部行为），直接扣 3 分。glm-5.1 的风格是"小步重构"：先提取方法、再消除重复、最后才动结构，每一步都尽量不碰接口签名。

2. 命名和注释的质量出奇地好。

glm-5.1 重构后的变量名、函数名比另外两个模型更贴近业务语义。我怀疑这跟智谱的 CodeGeeX 技术积累有关——它对"代码可读性"这个维度似乎有专门优化。

3. 会主动标注"我没动这里，因为不确定业务意图"。

这个太加分了。其他两个模型是闷头改，glm-5.1 会在注释里写 # TODO: 此处逻辑疑似冗余，但涉及 legacy 兼容，未做修改。作为 reviewer 看到这种输出，信任度直接拉满。

反面案例——deepseek-v4-pro 在一道重构题里把原来的回调式异步全改成了 async/await，代码确实漂亮，但原项目锁定在 Python 3.6 环境，而改写后的代码用到了 asyncio.run() 等 Python 3.7+ 才引入的 API，实际跑不了。这种"过度重构"在 15 道题里出现了 4 次。

测试环境与可复现配置

我统一通过 OpenAI 兼容接口调用，用的是 OpenRouter 或 ofox.io 这类聚合网关做中转（改个 base_url 就能切模型，省得管三套 Key）：

from openai import OpenAI

# 以 OpenRouter 为例；换 ofox.io 只需替换 base_url 和对应 api_key
client = OpenAI(
    api_key="your-key",
    base_url="https://openrouter.ai/api/v1"
)

三个模型的 model ID 分别填 deepseek-v4-pro、qwen3.7-max、glm-5.1。temperature 统一 0.2，max_tokens 统一 4096。每道题跑 1 次取结果，不 cherry-pick。

跑完 45 道题大概花了 ¥47（三个模型加一起），其中 qwen3.7-max 最贵占了大头。具体价格没法精确到分——各家最近都在调价，建议去 OpenRouter 或各官方平台查实时报价。

不同需求怎么选

你的场景	推荐模型	原因
刷题/竞赛/算法原型	deepseek-v4-pro	推理能力最强，pass@1 最高
写业务代码/CRUD/后端服务	qwen3.7-max	工程规范好，边界处理全
Code Review/重构遗留代码	glm-5.1	保守稳健，不会改坏现有行为
预算紧/高频调用	deepseek-v4-pro	DeepSeek 系列定价一直很激进
想要免费额度试水	glm-4.7-flash:free	智谱有免费模型可以先跑通流程

踩坑记录

坑 1：glm-5.1 的 max_tokens 设太大会报错

之前习惯性设 max_tokens=8192，结果：

openai.BadRequestError: Error code: 400 - {'error': {'message': 'max_tokens is too large', 'type': 'invalid_request_error'}}

改成 4096 就好了。各家上限不一样，挺烦人的。值得一提的是，通过聚合网关调用时，max_tokens 的上限校验逻辑由网关层处理，不同模型的限制会有差异，建议在初始化 client 时针对每个 model ID 单独测一遍边界值，避免批量任务中途报错中断。

坑 2：qwen3.7-max 对 prompt 格式更敏感

同样的重构 prompt，如果代码块没用 ```python 包裹而是直接贴纯文本，qwen3.7-max 偶尔会把代码当自然语言"解读"而不是重构。deepseek-v4-pro 和 glm-5.1 没这个问题。

坑 3：三家的 streaming 行为不完全一致

deepseek-v4-pro 的 stream 在结束时会发送 choices[0].delta.content 为 None 的 chunk，如果你的解析逻辑没处理这种情况会炸。这在 SSE 流式接口中是常见现象，加个判空就行：

content = chunk.choices[0].delta.content
if content is not None:
    print(content, end="")

小结

跑完这 45 道题我的感受：没有"最强代码模型"，只有最适合你当前任务的模型。deepseek-v4-pro 在纯智力题上确实碾压，但如果你的日常工作是维护一坨遗留系统、做 Code Review，glm-5.1 那种"克制"的重构风格反而更实用。

三个模型现在都能通过 OpenAI 兼容接口调用，OpenRouter、ofox.io 等聚合网关均已支持上述三个 model ID，base_url 对应替换即可，切换成本几乎为零。建议拿你自己项目里的真实代码跑一遍——别人的评测永远只是参考，你的屎山只有你自己最懂。