这篇不是想证明 DeepSeek 不行。恰恰相反，DeepSeek V4 Pro 已经很强了。

我用 https://cn.crazyrouter.com/v1 做了一轮真实 API 兼容和编程测试，两个模型都走 OpenAI-compatible /chat/completions：

• claude-opus-4-7
• deepseek-v4-pro

结论很明确：

DeepSeek V4 Pro 已经可以进入生产模型池，但如果是编程、结构化输出、工具调用、稳定性优先的场景，Claude Opus 4.7 依旧更适合作为默认首选。

测试环境

Base URL: https://cn.crazyrouter.com/v1
Endpoint: /chat/completions
接口风格: OpenAI-compatible

测试项不是跑榜单，而是偏真实开发：

• Chat Completions 基础调用
• JSON object 输出
• Tool calling
• 代码生成隐藏单测
• Bug 修复
• Unified diff patch
• Streaming 兼容
• 多语言摘要

核心结果

测试项	Claude Opus 4.7	DeepSeek V4 Pro
LRUCache 隐藏单测	✅ 通过，3.87s	✅ 通过，14.55s
retry 语义 Bug 修复	✅ 通过，3.44s	❌ 失败，20.74s
JSON object 高 token	✅ 通过，4.08s	✅ 通过，26.70s
Unified diff patch	✅ 通过，3.75s	✅ 通过，23.37s
Streaming 兼容	✅ 通过，1.99s	✅ 通过，1.80s

扩展测试总分：

• Claude Opus 4.7：5 / 5
• DeepSeek V4 Pro：4 / 5

平均延迟：

• Claude Opus 4.7：3.43s
• DeepSeek V4 Pro：17.43s

DeepSeek V4 Pro 强在哪里？

DeepSeek V4 Pro 不是弱模型。

这轮测试里，它通过了：

• Tool calling
• Streaming
• LRUCache 代码生成隐藏单测
• Unified diff patch
• 高 token JSON object 输出

所以它的问题不是“能力不够”，而是 在一些开发工作流里不够稳定、不够快、不够可预测。

尤其是涉及 reasoning tokens 时，它可能会为了思考消耗大量 token 和时间。

Claude Opus 4.7 为什么还是更适合编程？

Claude 的优势是稳定。

在同样的任务下，它更快、更短、更直接，而且输出更容易被程序消费。

最典型的是 retry bugfix 测试。

任务要求修复一个重试函数：

• retries=3 表示第一次调用失败后，最多再重试 3 次
• 全部失败后不能吞掉异常
• 要重新抛出最后一次异常

Claude 一次通过。

DeepSeek V4 Pro 这轮出现了：

finish_reason = length
reasoning_tokens = 1000
content = ""

也就是说，它思考了很久，消耗了输出预算，但最后没有给出可用代码。

这就是生产环境里最怕的情况：不是慢一点，而是慢完之后还没有结果。

兼容性结论

Chat Completions

两个模型都能通过 https://cn.crazyrouter.com/v1/chat/completions 调用。

Tool Calling

两个模型都通过。

JSON object

Claude 首轮直接稳定通过。

DeepSeek V4 Pro 在低 max_tokens 下曾返回空内容，提高 token budget 后通过。

这说明 DeepSeek 做结构化输出时，需要更谨慎设置 max_tokens 和 fallback。

Streaming

两个模型都通过。

怎么选？

选 Claude Opus 4.7：

• 编程任务
• Coding agent
• IDE assistant
• JSON / tool call 稳定性要求高
• 用户实时等待
• 生产自动化
• 高风险业务逻辑

选 DeepSeek V4 Pro：

• 成本敏感任务
• 内部工具
• 批处理任务
• 可以容忍更长延迟
• 有验证和 fallback 的推理任务

最佳做法不是二选一，而是路由。

Claude Opus 4.7：核心编程、高风险、强稳定性任务
DeepSeek V4 Pro：成本敏感、批处理、内部分析任务
Crazyrouter：用一个 OpenAI-compatible API 在两者之间路由

为什么用 Crazyrouter 测？

这轮测试最大的意义是：两个模型都通过同一个接口调用。

https://cn.crazyrouter.com/v1

这意味着应用不需要改 SDK，不需要重写业务代码，只需要换模型名，就可以测试 Claude、DeepSeek、Gemini、GPT、Qwen 等模型。

真正的生产策略不是“押注一个模型”，而是：

• 按任务路由
• 按失败类型 fallback
• 按延迟和成功率评估
• 按 cost per successful task 优化

最终结论

DeepSeek V4 Pro 已经很强，值得进入生产模型池。

但如果问题是：谁更适合作为编程和生产自动化的默认模型？

我的答案仍然是：Claude Opus 4.7。

DeepSeek 正在快速逼近，但 Claude 在代码质量、稳定性、结构化输出和生产可预测性上，依旧是更稳的选择。