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 代码无敌的印象有出入下面展开说。评测维度我不想搞那种让两个模型写快排然后比谁漂亮的玩具评测。锁定四个维度全是日常开发真会遇到的多文件重构12 题给 3-8 个文件的上下文要求按指定模式重构SQL 复杂查询15 题多表 JOIN 窗口函数 CTE从真实业务需求描述生成单元测试生成13 题给业务代码生成 pytest/jest 测试用例Bug 定位10 题给报错堆栈 相关代码定位根因并给修复方案每道题跑 2 遍取较好结果人工判定通过/部分通过/失败。评测结果天梯图维度deepseek-v4-pro 通过率qwen3.7-max 通过率差距备注多文件重构58% (7/12)75% (9/12)qwen3.7-max 17%上下文 60K 时差距最明显SQL 复杂查询73% (11/15)67% (10/15)deepseek-v4-pro 6%窗口函数场景两者都不太行单元测试生成85% (11/13)77% (10/13)deepseek-v4-pro 8%deepseek 生成的 mock 更合理Bug 定位80% (8/10)70% (7/10)deepseek-v4-pro 10%堆栈分析 deepseek 明显更强总计74% (37/50)72% (36/50)总分接近但分布完全不同总分几乎打平但分布差异很大。这就是为什么只看综合 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 -- GSQL / 单元测试 / 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 题的账单两轮合计模型总输入 token总输出 token单价输入/输出总费用deepseek-v4-pro~2.1M~890K官方未公布 deepseek-v4-pro 定价待确认qwen3.7-max~2.1M~1.05M官方未公布 qwen3.7-max 定价待确认⚠️ 说实话这里要诚实标注截至 2026 年 7 月 3 日deepseek/deepseek-v4-pro和bailian/qwen3.7-max的官方定价页我没找到明确的公开数据。如果参考前代模型DeepSeek V4 Pro 输出 $1.10/MQwen3-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_keysk-xxx, base_urlhttps://api.ofox.io/v1) # deepseek-v4-pro resp client.chat.completions.create( modeldeepseek-v4-pro, messages[{role: user, content: prompt}] )# qwen3.7-max复用上方同一个 client 对象只换 model 字符串 resp client.chat.completions.create( modelqwen3.7-max, messages[{role: user, content: prompt}] )我现在的工作流是短上下文任务bug 定位、写测试扔 deepseek-v4-pro长上下文重构扔 qwen3.7-max。在 ofox.io 或 OpenRouter 这种聚合网关上切模型就是改一个字符串的事。不同需求怎么选你的场景推荐模型原因微服务拆分/大规模重构qwen3.7-max长上下文保持力更强日常 bug 修复deepseek-v4-pro堆栈分析精准废话少写单元测试deepseek-v4-promock 策略更合理复杂 SQL 编写deepseek-v4-pro小幅CTE 结构更清晰预算紧张deepseek 系列参考前代定价约为 qwen 旗舰的一半需要思维链CoT输出推理过程qwen3.7-max支持enable_thinking参数可输出推理过程DeepSeek V4 Pro 系列本身不具备此功能踩坑记录跑评测的时候遇到几个坑记一下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 代码无敌的说法在单文件短上下文场景确实成立但一旦上下文拉到 60Kqwen3.7-max 的稳定性优势就出来了。差距背后是架构还是训练数据分布的问题目前没有公开资料可以下定论这里不做猜测。实用层面的结论是两个都用按任务类型切换聚合平台上改一个 model 字符串就能搞定。