Claude Code 生成 13 種編程語言代碼基準(zhǔn)測(cè)試：動(dòng)態(tài)語言更快更省成本

作者 | Steef-Jan Wiggers

譯者 | 明知山

Ruby 代碼提交者 遠(yuǎn)藤裕介（Yusuke Endoh）進(jìn)行了一項(xiàng)新的基準(zhǔn)測(cè)試，評(píng)估 Claude Code 使用 13 種編程語言生成可用代碼的效率。經(jīng)過 600 多次測(cè)試運(yùn)行，動(dòng)態(tài)語言（尤其是 Ruby、Python 和 JavaScript）始終是速度更快、成本更低且更穩(wěn)定的選擇，而靜態(tài)類型語言的運(yùn)行速度要慢 1.4 至 2.6 倍，成本也更高。

這項(xiàng)實(shí)驗(yàn)發(fā)布在 DEV Community 上，所有代碼和結(jié)果均可在 GitHub 獲取。實(shí)驗(yàn)要求 Claude Code（Opus 4.6）用每種語言實(shí)現(xiàn)一個(gè)簡(jiǎn)化版的 Git。任務(wù)分為兩個(gè)階段：v1 從空目錄開始實(shí)現(xiàn) init、add、commit 和 log 命令；v2 對(duì)項(xiàng)目進(jìn)行擴(kuò)展，增加 status、diff、checkout 和 reset 功能。每種語言各運(yùn)行 20 次。作者使用了自定義哈希算法，而非 SHA-256，用于消除不同語言間庫(kù)依賴帶來的差異。

Ruby 平均每次運(yùn)行成本 0.36 美元，耗時(shí) 73.1 秒；Python 為 0.38 美元，耗時(shí) 74.6 秒；JavaScript 為 0.39 美元，耗時(shí) 81.1 秒。這三種語言的方差均很低，且全部 40 次運(yùn)行都通過了所有測(cè)試。從第四名開始，成本上升，方差急劇擴(kuò)大。Go 語言平均成本 0.50 美元，耗時(shí) 101.6 秒，但標(biāo)準(zhǔn)差高達(dá) 37 秒。Rust 平均成本 0.54 美元，耗時(shí)跨度最大，達(dá)到 54.8 秒，同時(shí)也是僅有的兩種出現(xiàn)測(cè)試失敗的編程語言之一。C 語言是成本最高的主流語言，達(dá)到 0.74 美元，原因是它生成了 517 行代碼，而 Ruby 僅生成 219 行。

類型系統(tǒng)對(duì) AI 生成代碼的影響或許是對(duì)評(píng)估 AI 編碼工作流的團(tuán)隊(duì)最具實(shí)用價(jià)值的發(fā)現(xiàn)。在 Python 中添加 mypy 嚴(yán)格類型檢查會(huì)使其速度降低 1.6 至 1.7 倍；在 Ruby 中添加 Steep 類型檢查則會(huì)帶來更大的性能損耗，速度比純 Ruby 慢 2.0 至 3.2 倍。TypeScript 的成本明顯高于 JavaScript，平均 0.62 美元對(duì)比 0.39 美元，盡管二者生成的代碼行數(shù)相近。作者指出，這類開銷不僅來自類型注解的生成，還可能源于模型在推理類型約束時(shí)消耗了更多的思考詞元。

遠(yuǎn)藤很坦誠(chéng)地說明了這項(xiàng)實(shí)驗(yàn)存在的局限。作為 Ruby 代碼提交者，他主動(dòng)說明自身可能存在的偏向性。本次生成的程序約 200 行代碼，嚴(yán)格來說屬于原型規(guī)模，他也承認(rèn)靜態(tài)類型在更大規(guī)模的代碼庫(kù)中可能更具優(yōu)勢(shì)。該實(shí)驗(yàn)還得到了 Anthropic 的 Claude 開源計(jì)劃支持，獲得了為期六個(gè)月的 Claude Max 免費(fèi)使用權(quán)限。此次基準(zhǔn)測(cè)試僅衡量代碼生成的成本與速度，不涉及代碼質(zhì)量、可維護(hù)性或運(yùn)行時(shí)性能。

Lobsters 上有人質(zhì)疑基于 200 行代碼的原型規(guī)模得出的結(jié)論是否可靠。有評(píng)論者指出，實(shí)用的原型很少會(huì)這么短小。也有人提出，該基準(zhǔn)測(cè)試并未考慮語言生態(tài)優(yōu)勢(shì)——擁有完善包生態(tài)的語言在實(shí)際任務(wù)中需要生成的代碼會(huì)更少。DEV Community 帖子下有評(píng)論者表達(dá)了定性層面的擔(dān)憂：如果生成的代碼后期更難維護(hù)，那么 2 倍的生成速度優(yōu)勢(shì)可能會(huì)被抵消；此外，Rust 和 Haskell 出現(xiàn)測(cè)試失敗，不應(yīng)簡(jiǎn)單歸為 bug，因?yàn)楦鼑?yán)格的類型系統(tǒng)本意就是要盡早捕獲錯(cuò)誤，避免其流入生產(chǎn)環(huán)境。

遠(yuǎn)藤直接回應(yīng)了其中幾個(gè)觀點(diǎn)。關(guān)于規(guī)模問題，他認(rèn)同更大型的基準(zhǔn)測(cè)試會(huì)更有價(jià)值，但也指出，設(shè)計(jì)一套對(duì) 15 種語言都公平的測(cè)試難度較大。對(duì)于 2 倍的速度差異，他認(rèn)為在迭代式 AI 輔助開發(fā)中等待 30 秒與 60 秒的區(qū)別對(duì)開發(fā)者的心流狀態(tài)影響顯著，不過他也承認(rèn)，如果未來模型能將生成時(shí)間縮短至秒級(jí)以內(nèi)，這種差異就不再重要。而在生態(tài)系統(tǒng)影響方面，他刻意排除了庫(kù)依賴，以隔離語言本身的差異，使用自定義哈希函數(shù)也正是出于這一目的。

在總共 600 次運(yùn)行中，僅有 3 次失敗：Rust 兩次，Haskell 一次。在其中一次 Rust 的失敗日志里，智能體判定測(cè)試本身存在錯(cuò)誤，作者將其判定為幻覺，因?yàn)槠溆嗨?Rust 測(cè)試均順利通過。

完整的數(shù)據(jù)集（包含每次運(yùn)行的結(jié)果、執(zhí)行日志及所有生成的源代碼）均可在該 基準(zhǔn)測(cè)試倉(cāng)庫(kù) 中獲取。

查看英文原文：

https://www.infoq.com/news/2026/04/ai-coding-language-benchmark/

聲明：本文為 InfoQ 翻譯，未經(jīng)許可禁止轉(zhuǎn)載。

會(huì)議推薦

QCon 全球軟件開發(fā)大會(huì)·2026 北京站將于 4 月 16 日 -18 日正式舉辦。本屆大會(huì)以“Agentic AI 時(shí)代的軟件工程重塑”為主題，聚焦 100+ 重磅議題，匯聚來自阿里、騰訊、字節(jié)跳動(dòng)、小米、百度等一線科技企業(yè)與創(chuàng)新團(tuán)隊(duì)的技術(shù)專家，圍繞 AI 工程化、系統(tǒng)架構(gòu)與研發(fā)模式演進(jìn)展開深入探討。更多詳情可掃碼或聯(lián)系票務(wù)經(jīng)理 18514549229 進(jìn)行咨詢。

今日薦文

你也「在看」嗎？