开闭源模型实测 - 横评 Sonnet 5 与四大国产开源模型编程能力

今天发点开闭源模型的对比实测。

Sonnet

Claude

Sonnet 5用了一套新的分词器，同一段文字现在被切成了更多份Token，算下来的总费就比以前高。

我选了四个开源模型：

Kimi K2.7 Code

01. 实测对比

case 1 bug修复

提示词：

下面是一段 Python 代码，用于把金额字符串转成 cents。线上发现 “1,234.50”、”$0.99″、” -12.30 “、”12” 会出错或结果不一致。请修复函数，并补 pytest 测试。

def parse_money_to_cents(value: str) -> int:

value = value.replace(“$”, “”)

dollars, cents = value.split(“.”)

return int(dollars) * 100 + int(cents)

Sonnet 5：

Sonnet 5 计算方式很稳，用 Decimal 处理金额，避免浮点误差。问题是输入清洗太宽松，1,2,3 会被当成 123，1$2 会被当成 12，$$12 也会被当成 12，对脏数据防守不够。

Kimi K2.7 Code：

Kimi K2.7 Code 有格式检查，也拒绝超过两位小数的金额，比如 12.345。但先删掉 $ 和逗号，再检查格式的做法，会导致 1,2,3、1$2、$$12 被洗成合法数字。 而且+$12.30 这种正号加货币符号会被拒。

GLM 5.2

GLM 5.2修掉了题目里的核心问题，比如 1,234.50、$0.99、-12.30、12 都能处理。但没有先做完整格式判断。比如 –12.30 会被算成正数，12.-3 会被算出结果，1,2,3 也会被接受。

MiniMax M3

MiniMax M3 会先判断输入是否符合正常金额格式，再进入计算，所以 1,2,3 这种乱逗号会被拒掉，不会被误算成 12300 分。但规则略保守，像 .99、$.99 这种用户常见简写会被拒掉，$-12.30 这种符号位置也不兼容。

DeepSeek V4 Pro：

DeepSeek V4 Pro 主流程能跑通，但边界最弱。比如空字符串、空白、单独 $ 都会返回 0，这在金额场景里很危险；$-12.30 会算成 -1170，不是 -1230；–12.30 也会被错误接受，缺少一层“先判断输入是不是合法。

本case排名：MiniMax M3 > Sonnet 5 > Kimi K2.7 Code > GLM 5.2 > DeepSeek V4 Pro

case 2 边界条件推理

提示词：请实现一个 TypeScript 函数 groupByWindow(events, windowMs)。events 是按时间升序排列的数组，每项是 {id, ts}。函数要把相邻事件分组：只要当前事件和当前组第一条事件的 ts 差值小于等于 windowMs，就放进同组，否则开新组。请给出实现和 6 个边界测试。

Sonnet 5：

Sonnet 5 思路很清晰，特别点出了“链式漂移”问题。还覆盖了空数组、单元素、等于边界、超出边界、windowMs=0。但少了一点输入保护，比如负数窗口怎么处理没交代。

Kimi K2.7 Code：

Kimi K2.7 Code的实现是对的，而且项目很完整，package.json、tsconfig、Vitest 都配好了。但类型比较普通，返回值会丢掉事件上的额外字段类型。

GLM 5.2：

GLM 5.2 的分组机制很清楚：每次都拿当前事件和“本组第一条”比，还检查了 windowMs，负数、无限值会直接报错，比较适合真实函数。类型也保留得好，传什么事件类型，返回还是对应类型。

MiniMax M3：

MiniMax M3 核心逻辑正确，测试数量也多，覆盖了 windowMs=0、刚好等于窗口、刚好超过窗口、组首锚点，还检查了每个事件的 ts 是不是有效数字。但 id 类型写成了 string，数字 id 的场景类型上过不去；windowMs 没有拦负数。

DeepSeek V4 Pro：

DeepSeek V4 Pro 函数本身的主逻辑是对的，用最后一组的第一条做基准。但测试文件有乱码，空数组那条断言被注释吞掉了，第五条断言开头也被注释吞掉，后面的语句看起来跑不起来；第六条里 id:5 那行也被注释掉了，输入和期望对不上。

本case排名：GLM 5.2 > Sonnet 5 > Kimi K2.7 Code > MiniMax M3 > DeepSeek V4 Pro

case 3 代码审查

提示词：

请审查下面这段 Node.js 代码，找出会导致线上故障、安全问题或数据错乱的点。按严重程度排序，每个问题给出原因和最小修复方案。

app.post(‘/transfer’, async (req, res) => {

const { from, to, amount } = req.body

const user = await db.user.findFirst({ where: { id: from } })

if (user.balance < amount) return res.send(‘no money’)

await db.user.update({ where: { id: from }, data: { balance: user.balance – amount } })

const target = await db.user.findFirst({ where: { id: to } })

await db.user.update({ where: { id: to }, data: { balance: target.balance + amount } })

res.send(‘ok’)

})

Sonnet 5：

Sonnet 5 抓住了转账代码的核心机制问题：钱相关操作必须同时满足“扣款成功、收款成功、失败回滚、并发时不能超扣”。它给的方案用事务包住两边更新，还把“余额够不够”和“扣款”合成一步，能拦住并发双花。鉴权、负数金额、账户不存在、状态码、重复提交也都覆盖到了。

Kimi K2.7 Code：

Kimi K2.7 Code 重点抓得准：认证来源、输入校验、原子扣款、事务放款。明确说 from 应该来自登录用户，不能信请求体，这点很关键。小问题是金额单位处理有点跳：先说接口金额可能是元，再转成 cents，但示例默认数据库余额也已经是 cents。

GLM 5.2：

GLM 5.2 能看出是在想真实线上系统：并发、余额不足、目标账户不存在、鉴权、金额精度、幂等、限流、超时都提到了。机制解释也细，但修复方案有点分散，鉴权排到第五也偏低，任意人指定 from 转走别人钱应该排在最前面。

MiniMax M3：

MiniMax M3 把幂等、审计日志、限流、错误体都提到了，像上线前安全清单。问题是有几处说法不够稳：Prisma 示例里把 balance: { gte: amount } 放进 update.where；req.body 没解析那段也判断错了，解构 undefined 会直接报错。

DeepSeek V4 Pro：

DeepSeek V4 Pro 抓到了主问题：无事务、无鉴权、负数金额、目标账户不存在、浮点金额、幂等。但第一个修复：DeepSeek V4 Pro 仍然先读余额再判断，再扣款。并发下还可能出错。最低限度应该用“余额足够才扣款”的单步更新。

本 case 排名：Sonnet 5 > Kimi K2.7 Code > GLM 5.2 > MiniMax M3 > DeepSeek V4 Pro

case 4 代码重构

提示词：

请把下面函数重构成更易维护的版本，要求行为不变，并写出你会加的测试用例。不要引入第三方库。

function price(order) {

let total = 0

for (const item of order.items) {

if (item.type === ‘book’) total += item.price * item.qty * 0.9

else if (item.type === ‘food’) total += item.price * item.qty

else if (item.type === ‘luxury’) total += item.price * item.qty * 1.2

else total += item.price * item.qty

}

if (order.country === ‘US’) total *= 1.07

if (order.country === ‘DE’) total *= 1.19

if (order.vip) total *= 0.95

return Math.round(total * 100) / 100

}

Sonnet 5：

Sonnet 5 最贴题：拆函数、用查表、保留原来的计算顺序和 Math.round(total * 100) / 100。还解释了为什么循环累加顺序、税后 VIP、未知类型默认值都没有变。

Kimi K2.7 Code：

Kimi K2.7 Code7 个测试通过，代码也保住了原行为，属于合格重构。但测试覆盖面偏常规；没有单独压一遍 food 默认分支和无 country 这种小但常见的行为。

GLM 5.2：

GLM 5.2 的 11 个测试都通过，代码很干净，类型也补得合适。ITEM_MULTIPLIERS / TAX_RATES 让新增品类和国家更容易，整体没有乱加需求。

MiniMax M3：

MiniMax M3代码工程味很重，22 个测试也都过，但这轮题目是“重构”，MiniMax 主动改了行为：加了输入校验、限制 vip 类型、拒绝负数和小数数量，还把舍入从 Math.round 换成 toFixed。

DeepSeek V4 Pro：

DeepSeek V4 Pro本地用 vite-node 跑通了测试，实际是 13 个都过。实现方向没问题：表驱动、单品计算、税、VIP、舍入都保住了。还单独测了无 country、组合场景、多类型、两个舍入例子。

本 case 排名：Sonnet 5 > GLM 5.2 > DeepSeek V4 Pro > Kimi K2.7 Code > MiniMax M3

case 5 中文写作

提示词：

请把下面这段产品介绍改成一段自然、有说服力的中文官网文案。要求：不要 AI 腔，不要空泛形容词，不要“赋能、闭环、重塑、极致”等词。保留关键信息，控制在 180 字以内。

[墨斗可以整理零散素材、提炼文章结构、改写不同语气、检查 AI 味和敏感表达，还能保存作者常用词和固定说法。]

Sonnet 5：

Sonnet 5 开头从素材散在备忘录、聊天记录、录音转写里这些痛点切进去，后面自然带出整理、改写、查 AI 味、保存个人表达，很像真实产品文案。

Kimi K2.7 Code：

Kimi K2.7 Code 长度、对象、功能、场景都满足要求，也没有乱加设定。

GLM 5.2：

GLM 5.2 的：少几轮返工，这句不错。但 40 分钟访谈，二十分钟，能直接发，这些属于自己加的功能。

MiniMax M3：

MiniMax M3 超出 180 字，还加了，桌面端，敏感词清单，这些没给的设定。读起来也像产品页详情，不像产品介绍。

DeepSeek V4 Pro：

DeepSeek V4 Pro 更像博主推荐语；其中：一股脑扔进去，当然不一样，太口语化了，离官网介绍这个属性远了一点。

本 case 排名：Sonnet 5 > Kimi K2.7 Code > GLM 5.2 > MiniMax M3 > DeepSeek V4 Pro

case 6 数据分析

提示词：

下面是某产品 8 周的数据，请判断增长是否健康，并指出最该优先解决的问题。

week, visitors, signup_rate, activation_rate, paid_rate, churn_rate

1, 10000, 8.0%, 42%, 6.0%, 3.0%

2, 12000, 7.5%, 39%, 5.8%, 3.4%

3, 15000, 6.8%, 35%, 5.2%, 4.1%

4, 18000, 6.1%, 31%, 4.7%, 4.8%

5, 22000, 5.4%, 28%, 4.2%, 5.6%

6, 26000, 4.9%, 24%, 3.8%, 6.3%

7, 30000, 4.4%, 21%, 3.4%, 7.1%

8, 35000, 3.9%, 18%, 3.0%, 8.0%

Sonnet 5：

Sonnet 5 抓住了，所有转化率一起平滑下滑，这个信号，优先怀疑低质量流量。但是付费人数算法有口径问题：它说按顺序漏斗算，但表里付费人数没有乘激活率。

Kimi K2.7 Code：

Kimi K2.7 Code 简洁、清楚的说明了 paid_rate 的假设。但对流量质量的原因判断放得太靠后。

GLM 5.2：

GLM 5.2 算数基本对，分析也完整，但结论偏， 激活是唯一瓶颈，容易错过第 2 到第 3 周渠道变化这个更大的线索。

MiniMax M3：

MiniMax M3 能看到流量质量和激活承接，但关键算错了。

DeepSeek V4 Pro：

DeepSeek V4 Pro 算出了第 8 周付费人数从约 20 掉到约 7，判断：访问涨、激活和付费绝对人数下降，很准。机制也讲清楚了：问题表面在激活率，根子大概率在流量质量，处理动作也落到按渠道拆分。

本 case 排名：DeepSeek V4 Pro > Sonnet 5 > Kimi K2.7 Code > GLM 5.2 > MiniMax M3

case 7 网页生成

提示词：

请做一个单页商品官网，品牌名叫 VelaRun，新品是一双城市训练跑鞋 VelaRun Tempo。

要求：

1. 首屏必须让用户一眼看到鞋子，不要把产品藏在卡片或小图里。

2. 页面包含：

– 顶部导航

– Hero 区：产品大图、产品名、价格、颜色选择、尺码选择、加入购物车

– 卖点区：缓震、透气、稳定、重量

– 图片故事区：城市跑步场景，不要用抽象插画

– 规格参数区

– 用户评价区

– 移动端固定购买栏

3. 交互：

– 颜色切换会更新主图和选中状态

– 尺码未选时点击购买要提示

– 加入购物车后显示小型 toast

4. 风格：干净、有运动感，不能像模板站。避免大面积蓝紫渐变和圆角卡片堆叠。

5. 响应式要完整，手机端图片、按钮、文案不能重叠。

6. 用 React + TypeScript 实现，CSS 自写。

7. 给出完整可运行代码。

Sonnet 5：

Sonnet 5 购物机制做得很完整：颜色、尺码、缺尺码提示、售罄尺码、购物车数量、toast、移动端购买栏都有，页面结构也完整。

Kimi K2.7 Code：

Kimi K2.7 Code 布局也基本完整，但感觉很模板化。但购物车没有数量反馈，交互只做到颜色、尺码和提示。

GLM 5.2：

GLM 5.2 视觉干净，规格、卖点、城市测试故事这些内容比较像真实商品页。但交互很浅，购物袋数字是静态的，页面更像展示页。

MiniMax M3：

MiniMax M3 是暗色风格，组件拆得清楚，页面信息量足，购买和心愿单按钮也有电商感。但中间这个绿色的设计我看不懂。

DeepSeek V4 Pro：

DeepSeek V4 Pro 除了用 SVG 画了鞋，画得有点像简化模型，质感不如真商品图，其他地方都很好。

本 case 排名： Sonnet 5 > DeepSeek V4 Pro >MiniMax M3 > GLM 5.2 > Kimi K2.7 Code

case 8 3D动画

提示词：

请做一个单页 3D 产品官网，产品名叫 EchoStone，是一款桌面智能音箱。

技术要求：

1. 使用 React + TypeScript + Three.js。

2. 首屏必须是全屏 3D 场景，不要把 3D 放在小卡片里。

3. 3D 场景里要有一个可旋转的智能音箱模型，可以用 Three.js 基础几何体组合建模，不要依赖外部 3D 文件。

4. 音箱需要包含：

– 圆柱主体

– 顶部触控环

– 扬声器网孔纹理或孔阵列

– 一条发光状态灯

5. 交互：

– 鼠标拖拽旋转产品

– 滚轮缩放有限制

– 点击颜色按钮切换机身颜色

– 点击“播放演示”后，状态灯和声波动画开始运动

6. 页面内容：

– 顶部导航

– Hero 文案覆盖在 3D 场景上

– 颜色选择

– 三个卖点

– 技术参数区

7. 风格：高级消费电子，克制、干净，不要蓝紫渐变，不要发光球背景。

8. 响应式：桌面和手机端 3D 构图都不能空白、裁切严重或遮住主要按钮。

9. 给出完整可运行代码。

Sonnet 5：

Sonnet 5 的3D 本体首屏就出来了，圆柱机身、顶部触控环、网孔、灯条、声波圈都有，拖拽旋转和滚轮缩放也完整。机制上有 resize、清理资源、实例化网孔，像一份能继续维护的产品 demo。

Kimi K2.7 Code：

Kimi K2.7 Code 功能齐，OrbitControls、颜色切换、声波动画都有，整体能跑。问题是结构偏集中，视觉完成度有点粗糙。

GLM 5.2：

GLM 5.2 的顶部刻度、网孔都没有。音波出来的方向有点怪，而且模型太大，压到标题和控件了。

MiniMax M3：

MiniMax M3 模型细节和动画机制很强，底座、灯带、悬浮动效都做了，但是声波做没出来。

DeepSeek V4 Pro：

DeepSeek V4 Pro 不知道为啥，模型多了一个环，这个扣大分。其他都还挺不错的，该有的都有。

本 case 排名：Sonnet 5 > MiniMax M3 > Kimi K2.7 Code > GLM 5.2 > DeepSeek V4 Pro

02. 各模型评价

Sonnet 5 看起来还是比较稳的。8 个 case 里，Sonnet 5 在代码审查、代码重构、中文写作、网页生成、3D 动画这些综合任务上排第一；没拿第一的几项，也基本排在第二。

四个开源模型各有长板：

• GLM 5.2 在边界条件和类型保护上最好。
• Kimi K2.7 Code 执行稳定，测试、说明都比较完整。
• MiniMax M3 容易给出工程感很强的方案，金额解析和 3D 模型细节都不错。
• DeepSeek V4 Pro 在数据分析里表现最好。

03. 挖一挖

开源模型已经能承担很多真实工作了。GLM 5.2 的边界推理很细，Kimi K2.7 Code 交付完整，MiniMax M3 在视觉和工程化上有惊喜，DeepSeek V4 Pro 做数据判断时很敏锐。

单看某个 case，Sonnet 5 经常会被追上，甚至会被超过。

但把 8 个 case 连起来看，Sonnet 5 的优势还在。代码审查、重构、中文写作、网页生成、3D 动画这些任务里，Sonnet 5 更少出现低级错误，也更能照顾一些细微要求。

这种稳定性会直接影响返工时间、上线风险和人工审核成本。

所以价格差很多的时候，选择方式反而更清楚了。低风险、高频、可批量验证的任务，可以先交给开源模型。

高风险任务更适合 Sonnet 5，比如复杂重构、上线前代码审查、要直接交付给客户的页面、对文案口吻要求很高的内容。

最好的省钱的方式是把模型分开跑：开源模型负责多跑、多试、多产出，Sonnet 5 负责关键判断和最后收口。