说实话glm-5.2 写代码比我预期的猛——我拿 deepseek-v4-pro 和 claude-opus-4.8 跑了 45 道真实任务有一类结果和社区普遍印象完全反过来上个月团队要选一个主力代码模型我花了整整三天搭了个评测框架把 glm-5.2z-ai/glm-5.2、deepseek-v4-prodeepseek/deepseek-v4-pro、claude-opus-4.8anthropic/claude-opus-4.8拉到同一套题库里跑。45 道题算法/SQL/前端/调试各 10 道加 5 道 edge case。TL;DRglm-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 换算温度统一 temperature0每题跑 3 次取众数调用方式全部走 OpenAI 兼容协议base_url 统一用聚合网关日期本次评测于近期完成三天跑完一个关键细节我没用官方直连为了控制变量全部走同一个支持 OpenAI 兼容协议的聚合网关改一个 model 参数就切模型省得每家写一套调用逻辑。Anthropic 官方虽然提供了anthropicPython SDK 以及 OpenAI 兼容层但统一走网关可以减少环境差异对结果的干扰。目前提供此类 OpenAI 兼容中转的方案有几个ofox.io 和 OpenRouter 都支持通过同一套base_urlmodel参数路由到不同提供商OpenRouter 对部分模型收取一定加价具体见其官网定价页跑 45×3135 次调用下来成本差异不小我选了加价更低的方案。评测结果天梯图类别题数glm-5.2deepseek-v4-proclaude-opus-4.8备注算法排序/图/DP1022/3025/3028/30Opus 在 DP 题上几乎无失误SQL复杂查询1027/3024/3021/30glm-5.2 的递归 CTE 写法明显更老练前端React/CSS1019/3021/3026/30Opus 对 CSS Grid 布局理解最深调试找 bug1020/3026/3024/30DeepSeek 定位 race condition 最快Edge Case510/1512/1511/15整数溢出/空指针/并发边界总分4598/135108/135110/135—总分上 claude-opus-4.8 微胜 deepseek-v4-pro 两分但差距没有价格差距大后面算账。真正让我意外的是 SQL 那列——glm-5.2 领先 6 分。SQL 复杂查询详解这是最反直觉的部分展开说。我出的 SQL 题不是简单的SELECT * FROM。举个例子第 7 题要求用递归 CTE 实现组织架构树的层级展开同时用窗口函数算每层的薪资排名。glm-5.2 给出的方案直接用了WITH RECURSIVEDENSE_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 在这类任务上表现最稳——特别是并发相关的 bugrace 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.2SQL 复杂查询能力最强递归 CTE 和窗口函数几乎零失误算法密集型后端claude-opus-4.8DP/图论推导能力碾压但价格也碾压前端组件开发claude-opus-4.8React/TypeScript 代码质量最高日常调试/Code Reviewdeepseek-v4-pro定位 bug 最快性价比最高预算有限啥都要干deepseek-v4-pro综合分第二但价格是 Opus 的零头成本对账跑完 135 次调用后对比了三个模型的消耗各家官网定价折算仅供参考实际费用因调用时段和 token 计量方式略有出入模型总 input tokens总 output tokens估算费用glm-5.2~180K~420K约 $4.2deepseek-v4-pro~175K~390K约 $2.1claude-opus-4.8~185K~450K约 $18.7claude-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_keyyour-key, base_urlhttps://your-gateway/v1 # 替换为实际网关地址 ) # 核心调用示例 response client.chat.completions.create( modelglm-5.2, # 替换为目标模型 temperature0, max_tokens8192, 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 返回了个 429RateLimitError: 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 模板和评测框架我都贴了自己跑一遍比看任何人的文章都靠谱。
说实话，glm-5.2 写代码比我预期的猛——我拿 deepseek-v4-pro 和 claude-opus-4.8 跑了 45 道真实任务，有一类结果和社区普遍印象完全反过来
说实话glm-5.2 写代码比我预期的猛——我拿 deepseek-v4-pro 和 claude-opus-4.8 跑了 45 道真实任务有一类结果和社区普遍印象完全反过来上个月团队要选一个主力代码模型我花了整整三天搭了个评测框架把 glm-5.2z-ai/glm-5.2、deepseek-v4-prodeepseek/deepseek-v4-pro、claude-opus-4.8anthropic/claude-opus-4.8拉到同一套题库里跑。45 道题算法/SQL/前端/调试各 10 道加 5 道 edge case。TL;DRglm-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 换算温度统一 temperature0每题跑 3 次取众数调用方式全部走 OpenAI 兼容协议base_url 统一用聚合网关日期本次评测于近期完成三天跑完一个关键细节我没用官方直连为了控制变量全部走同一个支持 OpenAI 兼容协议的聚合网关改一个 model 参数就切模型省得每家写一套调用逻辑。Anthropic 官方虽然提供了anthropicPython SDK 以及 OpenAI 兼容层但统一走网关可以减少环境差异对结果的干扰。目前提供此类 OpenAI 兼容中转的方案有几个ofox.io 和 OpenRouter 都支持通过同一套base_urlmodel参数路由到不同提供商OpenRouter 对部分模型收取一定加价具体见其官网定价页跑 45×3135 次调用下来成本差异不小我选了加价更低的方案。评测结果天梯图类别题数glm-5.2deepseek-v4-proclaude-opus-4.8备注算法排序/图/DP1022/3025/3028/30Opus 在 DP 题上几乎无失误SQL复杂查询1027/3024/3021/30glm-5.2 的递归 CTE 写法明显更老练前端React/CSS1019/3021/3026/30Opus 对 CSS Grid 布局理解最深调试找 bug1020/3026/3024/30DeepSeek 定位 race condition 最快Edge Case510/1512/1511/15整数溢出/空指针/并发边界总分4598/135108/135110/135—总分上 claude-opus-4.8 微胜 deepseek-v4-pro 两分但差距没有价格差距大后面算账。真正让我意外的是 SQL 那列——glm-5.2 领先 6 分。SQL 复杂查询详解这是最反直觉的部分展开说。我出的 SQL 题不是简单的SELECT * FROM。举个例子第 7 题要求用递归 CTE 实现组织架构树的层级展开同时用窗口函数算每层的薪资排名。glm-5.2 给出的方案直接用了WITH RECURSIVEDENSE_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 在这类任务上表现最稳——特别是并发相关的 bugrace 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.2SQL 复杂查询能力最强递归 CTE 和窗口函数几乎零失误算法密集型后端claude-opus-4.8DP/图论推导能力碾压但价格也碾压前端组件开发claude-opus-4.8React/TypeScript 代码质量最高日常调试/Code Reviewdeepseek-v4-pro定位 bug 最快性价比最高预算有限啥都要干deepseek-v4-pro综合分第二但价格是 Opus 的零头成本对账跑完 135 次调用后对比了三个模型的消耗各家官网定价折算仅供参考实际费用因调用时段和 token 计量方式略有出入模型总 input tokens总 output tokens估算费用glm-5.2~180K~420K约 $4.2deepseek-v4-pro~175K~390K约 $2.1claude-opus-4.8~185K~450K约 $18.7claude-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_keyyour-key, base_urlhttps://your-gateway/v1 # 替换为实际网关地址 ) # 核心调用示例 response client.chat.completions.create( modelglm-5.2, # 替换为目标模型 temperature0, max_tokens8192, 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 返回了个 429RateLimitError: 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 模板和评测框架我都贴了自己跑一遍比看任何人的文章都靠谱。
