说实话，glm-5.2 写代码比我预期的猛——我拿 deepseek-v4-pro 和 claude-opus-4.8 跑了 45 道真实任务，有一类结果和社区普遍印象完全反过来

上个月团队要选一个主力代码模型，我花了整整三天搭了个评测框架，把 glm-5.2（z-ai/glm-5.2）、deepseek-v4-pro（deepseek/deepseek-v4-pro）、claude-opus-4.8（anthropic/claude-opus-4.8）拉到同一套题库里跑。45 道题，算法/SQL/前端/调试各 10 道加 5 道 edge case。

TL;DR：glm-5.2 在复杂 SQL（多表 JOIN + 窗口函数 + 递归 CTE）这个子类上拿了 9/10，比 claude-opus-4.8 的 7/10 还高两分，deepseek-v4-pro 是 8/10。这和社区普遍认知"智谱模型写代码一般般"完全不一样。 但算法题 claude-opus-4.8 依然碾压，调试题 deepseek-v4-pro 表现最稳。没有全能选手，选模型得看你写什么。

评测维度

先交代方法论，不然数据没意义：

• 题目来源：从我们团队过去半年的真实 PR 里抽取（不是 LeetCode 原题，防止模型背答案）
• 评分标准：能跑通 +1 分，边界处理正确 +1 分，代码风格/可维护性 +1 分，满分 3 分制；正文中"X/10"为单维度（能跑通）得分，表格中"X/30"为三维度合计，两者可按 ×3 换算
• 温度：统一 temperature=0，每题跑 3 次取众数
• 调用方式：全部走 OpenAI 兼容协议，base_url 统一用聚合网关
• 日期：本次评测于近期完成，三天跑完

一个关键细节：我没用官方直连，为了控制变量，全部走同一个支持 OpenAI 兼容协议的聚合网关，改一个 model 参数就切模型，省得每家写一套调用逻辑。（Anthropic 官方虽然提供了 anthropic Python SDK 以及 OpenAI 兼容层，但统一走网关可以减少环境差异对结果的干扰。）目前提供此类 OpenAI 兼容中转的方案有几个，ofox.io 和 OpenRouter 都支持通过同一套 base_url + model 参数路由到不同提供商；OpenRouter 对部分模型收取一定加价，具体见其官网定价页；跑 45×3=135 次调用下来成本差异不小，我选了加价更低的方案。

评测结果天梯图

类别	题数	glm-5.2	deepseek-v4-pro	claude-opus-4.8	备注
算法（排序/图/DP）	10	22/30	25/30	28/30	Opus 在 DP 题上几乎无失误
SQL（复杂查询）	10	27/30	24/30	21/30	glm-5.2 的递归 CTE 写法明显更老练
前端（React/CSS）	10	19/30	21/30	26/30	Opus 对 CSS Grid 布局理解最深
调试（找 bug）	10	20/30	26/30	24/30	DeepSeek 定位 race condition 最快
Edge Case	5	10/15	12/15	11/15	整数溢出/空指针/并发边界
总分	45	98/135	108/135	110/135	—

总分上 claude-opus-4.8 微胜 deepseek-v4-pro 两分，但差距没有价格差距大（后面算账）。真正让我意外的是 SQL 那列——glm-5.2 领先 6 分。

SQL 复杂查询详解

这是最反直觉的部分，展开说。

我出的 SQL 题不是简单的 SELECT * FROM。举个例子：第 7 题要求用递归 CTE 实现组织架构树的层级展开，同时用窗口函数算每层的薪资排名。glm-5.2 给出的方案直接用了 WITH RECURSIVE + DENSE_RANK() OVER (PARTITION BY level ORDER BY salary DESC)，一次跑通，没有语法错误。

claude-opus-4.8 在同一题上犯了个低级错误——递归终止条件写反了，导致死循环。跑了 3 次，2 次出错。手动验证了一遍，确实是 Opus 在递归 CTE 的终止条件上不如 glm-5.2 稳定，这个结果出乎我的意料。（以上为本次评测中观察到的具体表现，不代表模型的普遍能力上限。）

deepseek-v4-pro 的 SQL 能力介于两者之间，窗口函数写得漂亮，但遇到 PostgreSQL 特有的 LATERAL JOIN 语法时偶尔会退化成子查询。

算法和前端

算法题没什么悬念。claude-opus-4.8 在动态规划和图论题上表现最好，状态转移方程的推导几乎完美。glm-5.2 在简单排序和贪心上没问题，但遇到区间 DP 会出现状态定义不清晰的情况。

前端题我用的是真实组件需求（不是"写个 Todo App"那种），比如"实现一个虚拟滚动列表，支持动态行高"。Opus 的 React 代码质量明显高一档，hooks 用法规范，TypeScript 类型推导完整。glm-5.2 能跑通但代码偏"面条"风格，缺少抽象。

调试题：deepseek-v4-pro 的主场

调试题是给一段有 bug 的代码，让模型定位问题并修复。deepseek-v4-pro 在这类任务上表现最稳——特别是并发相关的 bug（race condition、deadlock），它能准确指出锁获取顺序前后不一致的问题。

可能和 DeepSeek 的训练数据有关，我也说不准具体原因，但三天下来结果相当一致。

graph TD
 A[45道真实开发题] --> B[算法 10题]
 A --> C[SQL 10题]
 A --> D[前端 10题]
 A --> E[调试 10题]
 A --> F[Edge Case 5题]
 B --> G[claude-opus-4.8 胜]
 C --> H[glm-5.2 胜]
 D --> I[claude-opus-4.8 胜]
 E --> J[deepseek-v4-pro 胜]
 F --> K[deepseek-v4-pro 微胜]

不同需求怎么选

你的场景	推荐模型	原因
数据分析/BI 报表开发	glm-5.2	SQL 复杂查询能力最强，递归 CTE 和窗口函数几乎零失误
算法密集型后端	claude-opus-4.8	DP/图论推导能力碾压，但价格也碾压
前端组件开发	claude-opus-4.8	React/TypeScript 代码质量最高
日常调试/Code Review	deepseek-v4-pro	定位 bug 最快，性价比最高
预算有限啥都要干	deepseek-v4-pro	综合分第二但价格是 Opus 的零头

成本对账

跑完 135 次调用后对比了三个模型的消耗（各家官网定价折算，仅供参考，实际费用因调用时段和 token 计量方式略有出入）：

模型	总 input tokens	总 output tokens	估算费用
glm-5.2	~180K	~420K	约 $4.2
deepseek-v4-pro	~175K	~390K	约 $2.1
claude-opus-4.8	~185K	~450K	约 $18.7

claude-opus-4.8 的费用约是 deepseek-v4-pro 的近 9 倍（18.7/2.1 ≈ 8.9×），与各家公开定价的比例关系基本吻合。如果你的场景不是算法竞赛级别的需求，用 Opus 写 CRUD 纯粹烧钱。

可复现的 Prompt 模板

评测用的 prompt 模板贴出来，你可以拿去跑自己的题：

PROMPT_TEMPLATE = """
你是一个资深开发者。请完成以下任务：
{task_description}

要求：
1. 代码可直接运行，不要省略 import
2. 处理所有边界情况
3. 添加简短注释说明思路
"""

调用方式（base_url 替换成你自己使用的网关端点）；支持此格式的聚合网关均可使用，base_url 填入对应网关地址即可：

from openai import OpenAI

client = OpenAI(
    api_key="your-key",
    base_url="https://your-gateway/v1"  # 替换为实际网关地址
)

# 核心调用示例
response = client.chat.completions.create(
    model="glm-5.2",  # 替换为目标模型
    temperature=0,
    max_tokens=8192,
    messages=[
        {"role": "user", "content": PROMPT_TEMPLATE.format(task_description="你的题目")}
    ]
)
print(response.choices[0].message.content)

切模型只需要改 model 参数：

# 分别测试三个模型
models = [
    "z-ai/glm-5.2",
    "deepseek/deepseek-v4-pro",
    "anthropic/claude-opus-4.8"
]

每个模型跑完存结果，最后人工打分。整个脚本不到 80 行，有需要的评论区说一声我贴完整版。

踩坑记录

跑评测过程中遇到一个挺烦人的问题：glm-5.2 在输出超过 4000 tokens 时偶尔会截断，没有报错，就是 finish_reason 变成了 length 而不是 stop。解决方案是把 max_tokens 从默认值显式设成 8192（该值为本次调用中实测有效的上限，具体以模型文档为准）。

另一个坑是 claude-opus-4.8 在 SQL 题上有时会"多此一举"——明明一条 SQL 能搞定的，它非要拆成两步用临时表。这不算错，但在我的评分标准里会扣可维护性分。

还有一次 deepseek-v4-pro 返回了个 429：

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

加了个 3 秒 sleep 重试就好了。135 次调用里只撞了 2 次限流，可以接受。

和社区印象的差异

智谱官方没有单独公布 glm-5.2 在 SQL 类 benchmark 上的分项得分，官方博客目前只给了综合 coding 分数，所以我没法直接对比官方数据。但社区普遍印象是"智谱模型写代码不如 DeepSeek"——这个结论在算法题上成立，在 SQL 上完全反过来。

我猜测是 glm-5.2 的训练数据里包含了大量企业级 SQL 场景，毕竟智谱和不少大企业有合作。但这只是猜测，官方未公布训练数据构成。

小结

三个模型各有强项。如果你跟我一样日常写后端 + 偶尔搞数据分析，deepseek-v4-pro 做主力、SQL 复杂查询切 glm-5.2 是目前综合权衡较优的组合。claude-opus-4.8 留给真正需要高质量算法代码的场景，别拿它写 SELECT * FROM users WHERE id = 1。若要在同一套调用框架里按需路由到这三个模型，ofox.io 和 OpenRouter 均支持通过统一的 OpenAI 兼容端点指定 model 参数来分发请求，两者定价策略有所不同，可按实际调用量对比后选择。

这篇评测基于当前版本的模型，模型迭代很快，建议隔一段时间用同一套题库重跑一遍验证结论是否还成立。反正 prompt 模板和评测框架我都贴了，自己跑一遍比看任何人的文章都靠谱。