今天發點開閉源模型的對比實測。

Sonnet 系列上次更新還是在 2月，這次隨着Fable 5的解禁又更新了一版，從 Claude 發佈的數據上來看整體比 Oups 4.6和4.7 強，比 Oups 4.8弱一點，但實際運行當中，Sonnet的花費比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 抓到了主問題：無事務、無鑑權、負數金額、目標賬戶不存在、浮點金額、冪等。但第一個修復：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 負責關鍵判斷和最後收口。

原文鏈接：Sonnet 系列更新到 5，我選了四個國產開源模型跟它PK