今天，我们来深入实测一组闭源与开源模型的编程能力。Sonnet 系列上次更新停留在今年2月，随着Fable 5的解禁，Sonnet 5终于迎来升级。根据Claude官方数据，其整体表现优于Oups 4.6和4.7，略逊于Oups 4.8，但实际运行时，Sonnet 5的调用成本甚至比Opus更高。

Sonnet 5采用了一套全新的分词器，同一段文字会被切分成更多Token，导致总费用明显上涨。

本次对比测试，我们选取了四款主流开源模型：Kimi K2.7 Code、GLM 5.2、MiniMax M3、DeepSeek V4 Pro，与Sonnet 5进行多轮正面交锋，看看Sonnet 5的真实实力究竟如何。

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

本 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 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、组合场景、多类型、两个舍入例子。

本 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 个测试案例中，它在代码审查、代码重构、中文写作、网页生成、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 负责关键判断和最终收口。