上周三我接了个活要把一个老项目的 monolith 拆成微服务。手头刚好有三家最新旗舰模型的 API 额度就想着干脆做个系统评测——反正代码都得写顺手记录一下谁强谁弱。TL;DR 结论50 道真实编程任务跑完deepseek-v4-prodeepseek/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 兼容 SDKtemperature 0max_tokens 4096每道题跑 3 次取多数结果。评测结果天梯图直接上数据任务类别deepseek-v4-progpt-5.5claude-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 第一次生成的 SQLWITH 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-pro90% 通过率全局一致性最好调试定位 buggpt-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_keyyour-key, base_urlhttps://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.2sclaude-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 CodeAnthropic 官方 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 GPTGPT 窗口函数有坑⚠️ 我的 50 道题样本量有限统计学上置信度不够不能替代大规模 benchmark。但作为个人选型参考够用了。HumanEval、SWE-bench 等评测集更侧重修 GitHub issue或通用算法能力和日常写业务代码、写 SQL 的场景有明显差异——这是评测覆盖面的问题不是谁对谁错。我也不确定的事DeepSeek 多文件重构强到底是模型架构优势还是训练数据里工程代码比例高不知道官方没公布训练细节。GPT-5.5 的 SQL 问题是不是可以通过 system prompt 里加注意 PARTITION BY来缓解我试了一下好像有点用但没完全解决样本太少没法下结论。这三个模型的定价我没找到官方统一公布的页面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 上链接[待补充——原文以评论区找我要代替直接提供建议作者在此处直接贴出链接以便读者核实原始数据]。