开闭源模型实测

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

开闭源模型实测

今天，我们来一场开闭源模型之间的精彩对决，看看它们在实际应用中的表现究竟如何。

本次评测，我精心挑选了四款备受瞩目的开源模型：Kimi K2.7 Code、GLM 5.2、MiniMax M3 和 DeepSeek V4 Pro，并将它们与闭源模型 Sonnet 5 进行了一番硬碰硬的较量。旨在深入探究 Sonnet 5 的真实实力。

在此之前，Sonnet 系列的上一次更新已是二月。而此次随着 Fable 5 的发布，Sonnet 也迎来了一次重要的迭代。Claude 官方数据显示，Sonnet 5 在整体性能上超越了 Oups 4.6 和 4.7，略逊于 Oups 4.8。然而，在实际运行成本上，Sonnet 5 的花费却比 Opus 还要高。

究其原因，Sonnet 5 采用了一套全新的分词器。这意味着，同一段文本在被切分时，会产生更多的 Token，从而推高了整体的计费。现在，就让我们一同揭开 Sonnet 5 的真实面纱，看看它在与这些开源模型的较量中，能有怎样的表现。

01. 实战演练：模型性能拼

案例一：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”也会被错误接受，缺乏必要的“输入合法性判断”这一关键步骤。

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

案例二：边界条件下的推理挑战

提示词：
请用 TypeScript 实现一个名为 groupByWindow 的函数，它接收 events（按时间升序排列的 {id,ts} 对象数组）和 windowMs（毫秒窗口值）。函数功能是将相邻进行分组：若当前与当前组的第一个时间戳（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 行也被注释掉了，使得输入与预期不符。

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

案例三：代码审查的深度洞察

提示词：
请审查以下 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 依然先读取余额再进行判断和扣款。在并发场景下，这仍可能导致问题。最低限度的安全措施应是采用“余额充足时才进行扣款”的单步更新。

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

案例四：代码重构的艺术升华

提示词：
请将以下函数重构为更易于维护的版本，确保行为不变，并列出您会添加的测试用例。禁止引入第三方库。
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 Code 的 7 个测试用例均通过，代码也保持了原有的行为，堪称一次合格的重构。但其测试覆盖面偏向常规，未能单独针对 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、组合场景、多类型以及两个舍入示例。

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

案例五：中文写作的魅力呈现

提示词：
请将以下产品介绍改写成一段自然、富有说服力的中文官网文案。要求：避免 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 的文案更倾向于博主推荐语，其中“一股脑扔进去，当然不一样”等表达过于口语化，与官网介绍的正式属性相去甚远。

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

案例六：数据分析的洞察力较量

提示词：
以下是某产品连续 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，并判断出“访问量增长，但激活和付费绝对人数下降”，这一结论非常准确。它还清晰地解释了机制：表面问题在于激活率，深层原因很可能在于流量质量。其提出的处理动作也直击要害，即按渠道进行细分。

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

案例七：网页生成的创意实现

提示词：
请设计一个单页商品官网，品牌名为 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 绘制了鞋子模型，虽然造型有些简化，质感上略逊于真实商品图，但其余方面表现出色。

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

案例八：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. 提供完整可运行的代码。