deepseek-v4-pro 和 qwen3.7-max 写代码谁更猛——我用同一套 50 道真实开发题跑了两轮，有一类任务结果和官方榜单完全反过来

上个月团队在做一个老项目的微服务拆分，涉及大量多文件重构和复杂 SQL 改写。我同时开了deepseek/deepseek-v4-pro和bailian/qwen3.7-max两个模型轮着跑，想看看到底谁更适合当"重构搭子"。结论先放这儿：deepseek-v4-pro 在单文件 bug 定位和单元测试生成上依然是第一梯队，但 qwen3.7-max 在超过 60K token 上下文的多文件重构场景里反超了——通过率高出 17 个百分点。这个结果跟社区里"DeepSeek 代码无敌"的印象有出入，下面展开说。

评测维度

我不想搞那种"让两个模型写快排然后比谁漂亮"的玩具评测。锁定四个维度，全是日常开发真会遇到的：

1. 多文件重构（12 题）：给 3-8 个文件的上下文，要求按指定模式重构
2. SQL 复杂查询（15 题）：多表 JOIN + 窗口函数 + CTE，从真实业务需求描述生成
3. 单元测试生成（13 题）：给业务代码，生成 pytest/jest 测试用例
4. Bug 定位（10 题）：给报错堆栈 + 相关代码，定位根因并给修复方案

每道题跑 2 遍取较好结果，人工判定通过/部分通过/失败。

评测结果天梯图

总分几乎打平，但分布差异很大。这就是为什么只看综合 benchmark 会误判。

多文件重构：qwen3.7-max 反超的核心场景

这类任务我喂进去的上下文普遍在 50K-90K token 之间（包含多个文件内容 + 重构要求描述）。

deepseek-v4-pro 在上下文超过 60K 之后开始出现一个很烦人的模式：它会"遗忘"前面文件里的类型定义，然后在后面的文件重构里用错类型。比如我给了types.ts里定义的OrderStatus枚举，到第 5 个文件重构时它自己又编了一个status: string。

qwen3.7-max 在这个场景下明显更稳。我怀疑跟它的长上下文训练策略有关，但官方没公布具体细节，这里只是个人猜测，不代表官方说法。

graph TD A[50道真实开发题] --> B[多文件重构 12题] A --> C[SQL复杂查询 15题] A --> D[单元测试生成 13题] A --> E[Bug定位 10题] B --> F[qwen3.7-max 胜出] C --> G[deepseek-v4-pro 小幅领先] D --> G E --> G

SQL / 单元测试 / Bug 定位

这三类 deepseek-v4-pro 都赢了，但赢的方式不一样：

SQL：两者都能写出能跑的查询，区别在于 deepseek-v4-pro 生成的 CTE 命名更清晰，窗口函数的 PARTITION BY 选择更合理。qwen3.7-max 有两次把 LEFT JOIN 写成了 INNER JOIN 导致数据丢失。

单元测试：deepseek-v4-pro 生成的 mock 对象更贴近真实场景。qwen3.7-max 有个毛病——它特别喜欢 mock 掉所有依赖，导致测试其实什么都没测到。

Bug 定位：这个差距最大。给一段 Java 堆栈 + 3 个相关类文件，deepseek-v4-pro 10 题里有 8 题通过（80%），其中多数能直接指出根因行号。qwen3.7-max 更倾向于给你一个"可能的原因列表"，需要你自己再排查。

Token 成本换算

这是实际跑完 50 题的账单（两轮合计）：

⚠️ 说实话这里要诚实标注：截至 2026 年 7 月 3 日，deepseek/deepseek-v4-pro和bailian/qwen3.7-max的官方定价页我没找到明确的公开数据。如果参考前代模型（DeepSeek V4 Pro 输出 $1.10/M，Qwen3-235B-A22B 输出 ¥16.00/M，此价格来自阿里云百炼平台，读者使用前建议自行核实官方定价页），deepseek 系列的 token 单价大概率还是 qwen 旗舰的一半左右。但 V4-Pro 和 3.7-Max 作为各自最新旗舰，定价可能有调整，这个结论仅供参考。

还有个隐藏成本：qwen3.7-max 的输出 token 量比 deepseek-v4-pro 多了约 18%。它更"话痨"，喜欢输出解释性文字。如果你只要代码不要废话，记得在 prompt 里加一句"只输出代码，不要解释"。

调用方式对比

两个模型都兼容 OpenAI SDK。如果你跟我一样两个都想用，可以通过 OpenRouter、ofox.io 这类聚合平台统一管理，一个 Key 切模型就行，省得维护两套密钥。注意：直接对接官方平台时，DeepSeek 和阿里云百炼各有自己的api_key格式和base_url（百炼为https://dashscope.aliyuncs.com/compatible-mode/v1），并非只改base_url就能通用；下面示例使用的是聚合平台地址，并非官方端点。

from openai import OpenAI # 使用聚合平台（ofox.io），一个 Key 同时访问两个模型 # 注意：这里的 base_url 是第三方聚合平台地址，非 DeepSeek 或阿里云官方端点 client = OpenAI(api_key="sk-xxx", base_url="https://api.ofox.io/v1") # deepseek-v4-pro resp = client.chat.completions.create( model="deepseek-v4-pro", messages=[{"role": "user", "content": prompt}] )

# qwen3.7-max，复用上方同一个 client 对象，只换 model 字符串 resp = client.chat.completions.create( model="qwen3.7-max", messages=[{"role": "user", "content": prompt}] )

我现在的工作流是：短上下文任务（bug 定位、写测试）扔 deepseek-v4-pro，长上下文重构扔 qwen3.7-max。在 ofox.io 或 OpenRouter 这种聚合网关上切模型就是改一个字符串的事。

不同需求怎么选

踩坑记录

跑评测的时候遇到几个坑，记一下：

DeepSeek 高峰期 429：工作日下午 2-5 点，deepseek-v4-pro 连续触发限流：

openai.RateLimitError: Error code: 429 - {'error': {'message': 'Rate limit reached for model', 'type': 'requests', 'code': 'rate_limit_exceeded'}}

解决办法要么错峰跑，要么走聚合平台的多通道路由。

qwen3.7-max 输出截断：开了 thinking mode 之后 token 消耗暴涨，max_tokens设小了会直接截断代码输出到一半。但设太大又会报：

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

我最后的方案是关掉 thinking mode 跑代码生成，只在 debug 场景开。

小结

跑完这 50 题的体感是：两个模型总分接近但特长完全不同。社区里"DeepSeek 代码无敌"的说法在单文件短上下文场景确实成立，但一旦上下文拉到 60K+，qwen3.7-max 的稳定性优势就出来了。

差距背后是架构还是训练数据分布的问题，目前没有公开资料可以下定论，这里不做猜测。实用层面的结论是：两个都用，按任务类型切换，聚合平台上改一个 model 字符串就能搞定。