上周三我接了个活，要把一个老项目的 monolith 拆成微服务。手头刚好有三家最新旗舰模型的 API 额度，就想着干脆做个系统评测——反正代码都得写，顺手记录一下谁强谁弱。

TL;DR 结论：50 道真实编程任务跑完，deepseek-v4-pro（deepseek/deepseek-v4-pro）在多文件重构类任务上通过率 90%，比 claude-opus-4.8 高 10 个百分点；但 gpt-5.5 在 SQL 生成上意外翻车，通过率只有 60%，被另外两家按在地上摩擦。没有全能王，选型看任务类型。

评测维度

我把 50 道题分成 5 类，每类 10 道，全部来自我过去半年真实遇到的工程场景（不是 LeetCode 刷题那种）：

任务类别	题目来源	判定标准
算法实现	实际业务中的排序/搜索/图算法	单元测试全过
代码重构	单文件 → 提取函数/类	重构后测试不挂 + 可读性人工评分
调试修复	真实 bug 复现，给报错让它修	修复后 CI 通过
多文件重构	跨 3-5 个文件的架构调整	所有文件改动后集成测试通过
SQL 生成	业务需求 → 复杂查询（JOIN/窗口函数/CTE）	在测试数据库上结果正确

评测环境：统一用 OpenAI 兼容 SDK，temperature 0，max_tokens 4096，每道题跑 3 次取多数结果。

评测结果天梯图

直接上数据：

任务类别	deepseek-v4-pro	gpt-5.5	claude-opus-4.8	备注
算法实现（10题）	8/10 (80%)	9/10 (90%)	9/10 (90%)	前两名并列
代码重构（10题）	7/10 (70%)	7/10 (70%)	8/10 (80%)	Claude 略优
调试修复（10题）	7/10 (70%)	8/10 (80%)	7/10 (70%)	GPT 定位 bug 更快
多文件重构（10题）	9/10 (90%)	7/10 (70%)	8/10 (80%)	DeepSeek 碾压
SQL 生成（10题）	8/10 (80%)	6/10 (60%)	8/10 (80%)	GPT 爆冷
总计（50题）	39/50 (78%)	37/50 (74%)	40/50 (80%)	—

总分 Claude 最高，但差距不大。真正有意思的是单项——DeepSeek 在多文件重构上 90% 的通过率，以及 GPT-5.5 在 SQL 上 60% 的翻车。

graph TD
 A[50道编程任务] --> B[算法实现 10题]
 A --> C[代码重构 10题]
 A --> D[调试修复 10题]
 A --> E[多文件重构 10题]
 A --> F[SQL生成 10题]
 B --> G[GPT-5.5 & Claude 并列第一 90%]
 C --> H[Claude 第一 80%]
 D --> I[GPT-5.5 第一 80%]
 E --> J[DeepSeek 第一 90%]
 F --> K[DeepSeek & Claude 并列第一 80%]

DeepSeek-V4-Pro 多文件重构为什么这么猛

这是我没预料到的。举个具体例子——第 7 题是把一个 Express 项目的路由层从 controller 里拆出来，涉及 4 个文件的改动（routes/index.js、controllers/user.js、middleware/auth.js、app.js）。

DeepSeek 的输出让我愣了一下：它不光拆了代码，还主动把 require 改成了 ESM 的 import，并且在 app.js 里加了一行注释说明为什么改了模块系统。三次运行结果完全一致。

需要注意的是，在未经明确需求确认的情况下擅自迁移模块系统（CommonJS → ESM）属于超出任务范围的改动，在实际工程中可能引发兼容性问题（例如依赖包不支持 ESM、Node.js 版本限制等）。这里把它记录为"DeepSeek 主动补全了上下文关联改动"，但生产环境中这类行为需要人工审查，不能直接合并。

GPT-5.5 在同一道题上的问题是：它改了 routes/index.js 和 controllers/user.js，但忘了同步修改 middleware/auth.js 里的引用路径，导致集成测试直接挂掉：

Error: Cannot find module '../controllers/user'
 at Function.Module._resolveFilename

这种"改了 A 忘了 B"的错误在 GPT-5.5 的多文件任务里出现了 3 次。我猜是上下文窗口利用策略的问题——它似乎倾向于逐文件处理而不是全局规划。

如果你的日常工作是架构级重构（微服务拆分、模块化改造），deepseek-v4-pro 目前是三家里最靠谱的。但这个结论仅基于我这 10 道题，样本量有限，厂商自报的 benchmark 我没找到针对多文件场景的单独数据。

GPT-5.5 SQL 生成为什么翻车

说实话这个结果出来的时候我反复确认了三遍。GPT-5.5 在简单 JOIN 上没问题，但一旦涉及窗口函数嵌套 CTE，它就开始犯低级错误。

第 4 题要求：「查询每个部门中工资排名前 3 的员工，同时显示部门平均工资」。GPT-5.5 第一次生成的 SQL：

WITH ranked AS (
 SELECT *, ROW_NUMBER() OVER (
 PARTITION BY dept_id ORDER BY salary DESC
 ) as rn FROM employees
)
SELECT r.*, AVG(salary) OVER () as dept_avg
FROM ranked r WHERE rn <= 3

问题在哪？AVG(salary) OVER () 算的是全表平均，不是部门平均。应该是 AVG(salary) OVER (PARTITION BY dept_id)。三次运行有两次犯了同样的错误。

DeepSeek 和 Claude 在这道题上都一次过。

我翻了一下社区讨论，发现不止我一个人遇到这个问题。GPT-5.5 在窗口函数的 PARTITION BY 子句上似乎有某种系统性偏差——它倾向于省略 PARTITION BY 或者把分区键搞错。这和官方榜单上 GPT-5.5 "coding 能力全面领先"的宣传有明显出入。

官方 benchmark（如 HumanEval、SWE-bench）是由 OpenAI 和普林斯顿团队等第三方发布的通用评测集，SQL 生成尤其是复杂分析查询并不在主要评测维度里。所以官方数据和实际体验出现差异并不矛盾——只是评测覆盖面不同，不代表官方数据造假，也不代表我的 50 道题更权威。

不同需求怎么选

你的主要场景	推荐模型	原因
算法题/面试准备	claude-opus-4.8 或 gpt-5.5	两家并列 90%，都很稳
单文件重构/代码优化	claude-opus-4.8	可读性评分最高
多文件架构重构	deepseek-v4-pro	90% 通过率，全局一致性最好
调试定位 bug	gpt-5.5	报错分析能力强
SQL/数据分析	deepseek-v4-pro 或 claude-opus-4.8	避开 GPT 的窗口函数坑
预算有限	deepseek-v4-pro	体感上价格最低（见下方成本说明）

调用方式和成本

三个模型我都是通过聚合 API 调用的。OpenRouter 收取一定比例的手续费（具体费率随模型和时间变化，建议查询 openrouter.ai 当前定价页，本文写作时约为 5% 上下）；ofox.io 声称 0% 加价，改个 base_url 就能切。我用的后者，代码长这样：

from openai import OpenAI
client = OpenAI(
 api_key="your-key",
 base_url="https://api.ofox.io/v1"
)

然后 model 参数分别填 deepseek/deepseek-v4-pro、openai/gpt-5.5、anthropic/claude-opus-4.8。

50 道题跑下来，每道题平均输入约 800 tokens、输出约 1500 tokens，三次重复。粗算一下总消耗：

• 输入总量：50 × 800 × 3 = 120,000 tokens（约 120K）
• 输出总量：50 × 1500 × 3 = 225,000 tokens（约 225K）

具体花了多少钱我没细算到分（后台能看到每笔调用的费用明细）。这三个模型目前官方均未公布统一的定价页面，所以我没法给出精确的成本对比数字——体感上 DeepSeek 最便宜，另外两家贵不少，但"零头"这个说法我没有数据支撑，不敢写死。

一些补充观察

延迟方面：deepseek-v4-pro 的首 token 时间（TTFT）体感在 1.2-1.8s 左右，gpt-5.5 大概 0.8-1.2s，claude-opus-4.8 最慢，经常 2s+。跑批量评测的时候 Claude 那边偶尔还会 429（以下错误格式基于 anthropic-sdk Python 版，不同 SDK 版本异常类名可能有差异，建议以实际安装版本文档为准）：

anthropic.RateLimitError: Error code: 429 -
{'type': 'error', 'error': {'type': 'rate_limit_error',
'message': 'Number of request tokens has exceeded
your per-minute rate limit'}}

烦。得加个 exponential backoff。

输出风格：DeepSeek 的代码注释最少但逻辑最紧凑，Claude 喜欢写大段注释解释思路（有时候太啰嗦了），GPT 介于两者之间。如果你用 Claude Code（Anthropic 官方 CLI 工具）或 Cline（开源 VSCode 插件，两者定位不同但都支持自定义 API）这类工具接入，Claude 的长注释反而有用——agent 需要理解自己上一步干了什么。

一致性：三次运行结果完全一致的比例——DeepSeek 82%、GPT 76%、Claude 84%。Claude 最稳定，GPT 偶尔会"灵感爆发"写出不同方案（有时更好有时更差）。

和官方 Benchmark 的对比

维度	官方榜单排名（第三方评测集，各厂商自报分数）	我的实测排名	差异原因
整体编程	Claude ≈ GPT > DeepSeek（基于公开数据，具体分数见各厂官网）	Claude > DeepSeek > GPT	任务分布不同
多文件工程	官方未单独公布	DeepSeek >> Claude > GPT	这类场景被低估
SQL 生成	官方未单独公布	DeepSeek ≈ Claude >> GPT	GPT 窗口函数有坑

⚠️ 我的 50 道题样本量有限（统计学上置信度不够），不能替代大规模 benchmark。但作为个人选型参考够用了。HumanEval、SWE-bench 等评测集更侧重"修 GitHub issue"或通用算法能力，和日常写业务代码、写 SQL 的场景有明显差异——这是评测覆盖面的问题，不是谁对谁错。

我也不确定的事

1. DeepSeek 多文件重构强，到底是模型架构优势还是训练数据里工程代码比例高？不知道，官方没公布训练细节。
2. GPT-5.5 的 SQL 问题是不是可以通过 system prompt 里加"注意 PARTITION BY"来缓解？我试了一下，好像有点用但没完全解决，样本太少没法下结论。
3. 这三个模型的定价我没找到官方统一公布的页面（DeepSeek-V4-Pro 是新模型），所以成本对比我没敢写具体数字。等官方定价页更新了再补。

小结

跑完这 50 道题最大的感受：别信任何单一 benchmark，也别信任何"全面领先"的宣传。模型强弱完全取决于你的具体任务类型。

如果让我只留一个模型——日常写业务代码 + 偶尔重构，我会留 deepseek-v4-pro，性价比太高了。需要高质量调试的时候再切 gpt-5.5，写复杂业务逻辑需要稳定性的时候上 claude-opus-4.8。

反正通过 ofox.io 或者 OpenRouter 这类聚合平台，切模型就是改一个 model 参数的事，不用纠结只选一个。多试，看数据说话。

---

评测日期：2026 年 6 月 28 日。模型版本以当日聚合平台可用版本为准。50 道题的具体内容和测试结果我放在了 GitHub gist 上，链接：[待补充——原文以"评论区找我要"代替直接提供，建议作者在此处直接贴出链接以便读者核实原始数据]。