哪些语言适合AI编程？

下文数据与结论均来自作者在 Claude Opus 4.6 上的定量基准测试；作者本人是 Ruby 核心提交者，文中已声明这一偏见。实验任务为原型规模的 mini-git， 不能直接外推到大型工程 。

1. 相关争论很多，数据很少

AI 编程智能体该用哪种语言？两边吵得热闹：

「静态类型能防止 AI 幻觉 bug！」 vs「不写类型注解才能省 token！」

定性口号满天飞，定量结果却稀缺。Ruby 核心提交者 mame [4] 决定跑一次实验：让 Claude Code [5] 用多种语言实现同一个 mini-git （简化版 Git），测量耗时、费用和代码行数。

任务刻意选得很「像真开发」：Git 是 Linus 两周写出来的经典，提示词也极简——读规格、实现、让测试通过。完整规格与测试脚本见仓库里的 SPEC-v1.txt [6] 和 test-v1.sh [7] 。

2. 实验怎么设计

任务拆成两阶段：

v1（从零建项目） ： init 、 add 、 commit 、 log
v2（在已有代码上扩展） ：再加 status 、 diff 、 checkout 、 reset

对比语言分成四组：

类别	语言
动态类型	Python、Ruby、JavaScript、Perl、Lua
动态 + 类型检查	Python/mypy、Ruby/Steep
静态类型	TypeScript、Go、Rust、C、Java
函数式	Scheme（动态）、OCaml（静态）、Haskell（静态）

Python/mypy 写满类型注解并用 mypy --strict ；Ruby/Steep 写 RBS 并用 steep check ——这样可以在 同一语言内部 直接看「加类型检查」的开销。

每种语言跑 20 次 ，模型为 Claude Opus 4.6（high effort） 。代码与原始结果开源在 ai-coding-lang-bench [8] 。

3. 结果：前三甲很稳，后面开始抖

按平均费用排序（v1+v2 合计）：

语言	测试通过	耗时	平均费用	LOC（v2）
Ruby	40/40	73.1s ± 4.2s	$0.36	219
Python	40/40	74.6s ± 4.5s	$0.38	235
JavaScript	40/40	81.1s ± 5.0s	$0.39	248
Go	40/40	101.6s ± 37.0s	$0.50	324
Java	40/40	115.4s ± 34.4s	$0.50	303
Rust	38/40	113.7s ± 54.8s	$0.54	303
TypeScript	40/40	133.0s ± 29.4s	$0.62	310
C	40/40	155.8s ± 40.9s	$0.74	517
Haskell	39/40	174.0s ± 44.2s	$0.74	224
Ruby/Steep	40/40	186.6s ± 69.7s	$0.84	304

不同语言成本的消耗如下图所示：

Ruby / Python / JavaScript 费用最低且点更密；靠后语言费用更高、散得更开。

三个信号很清楚：

Ruby、Python、JavaScript 包揽前三：大约 73–81 秒、$0.36–0.39 ，标准差也小——又快又稳。
从 Go / Rust / Java 起，方差陡增 。Go 平均约 102 秒，波动却有 ±37 秒。
TypeScript 明显慢于 JavaScript （133s / 0.39）。「给 JS 加上类型」并没有让生成更快更便宜。

600 次运行（15 种语言 × 2 阶段 × 20 次）里， 只有 3 次测试失败 ：Rust 2 次、Haskell 1 次。其中一次 Rust 失败日志里，智能体声称「测试写错了」——其余 Rust 试验都成功，作者判断这更像幻觉。

4. 代码短 ≠ 生成快

v2 完成后，OCaml（216）、Ruby（219）、Haskell（224）行数最少；C 到了 517 行 。

但短并不等于省。Haskell、OCaml 代码紧凑，速度与费用却只排中游偏下——作者推测大量开销花在了思考 token（thinking tokens）上，而不是吐字数本身。

5. 新项目最吃亏，扩展时差距会收窄

v1（空目录起步）语言差距最大：Python 32.9s、Ruby 33.2s、JavaScript 36.0s；Ruby/Steep 却要 105.0s ，约 3.2 倍 于纯 Ruby。需要 Cargo.toml 、 package.json 等脚手架的语言，从零搭项目会多一轮往返。

v2（已有代码上加功能）差距收窄：前三仍是 Ruby / Python / JS（40–45s），Perl、OCaml、Lua 也挤进 45–47s 一带。Haskell 仍最慢（约 99.6s）。

类型检查器的成本也很实在：

Python/mypy 比 Python 慢约 1.6–1.7×
Ruby/Steep 比 Ruby 慢约 2.0–3.2×

6. 作者解释：别只怪类型

作者同时也强调这是个人解读，且带 Ruby 偏见；也没有逐行审完所有生成代码。他提出的假说包括：

类型系统 ：动态语言整体更快、更稳
简洁性 ：短代码通常有利，但函数式语言可能把时间烧在推理上
语言固有难度 ：C 内存管理、Rust 所有权可能增加纠错轮次
训练数据熟悉度 ：Python / Ruby / JS 语料远多于 Scheme / Haskell；Steep 也可能不如 mypy「眼熟」

关于「没类型会不会更多 bug」：测试通过不代表未覆盖路径没有类型错误。但作者认为类型错误往往最好修；若智能体在无类型检查时大量出类型错，逻辑错大概也不会少。更刺眼的是：仅有的 3 次失败，都落在带所有权 / Monad 等「重概念」的静态语言上—— 类型并不能挡住所有 bug 。

7. 两倍差距值不值得纠结？

作者认为值得。真实用法是：提示 → 等待 → 想下一步 → 再提示。等 30 秒和等 60 秒，不只是总时长翻倍，还会打断专注与心流。

「多花时间换更稳健」说得通；但对手若以两倍速度交付，等待本身也是质量维度上的损失。当然，若未来差距缩到 1s vs 0.5s，讨论就没意义了。

他也承认任务偏小，静态类型或许在更大规模项目里更有优势——只是要做对 15 种语言都公平的大基准很难。生态与运行时性能同样重要：本实验故意不引外部库、甚至用自定义哈希代替 SHA-256，就是为了 尽量隔离语言本身 的差异。

8. 结论：原型阶段，动态语言仍是好默认

至少在 原型规模 任务上，作者的定量结论是：

Ruby、Python、JavaScript（不是 TypeScript）看起来最适合 Claude Code——最快、最便宜、也最稳。

经典路径——先动态语言起盘，成熟后再迁到静态语言——或许仍然成立；作者甚至觉得编程智能体已经挺会做跨语言迁移，但这点仍需验证。

实验完成于 2026 年 3 月 ，AI 迭代很快，几个月后排名可能改写。明细报告见 report.md [9] ，日志与生成源码在 data 分支 [10] 。复现时注意 benchmark.rb 使用了 --dangerously-skip-permissions ，作者是在 Docker 里跑的。

编者观点： 这份基准最大的价值不是「宣布某种语言胜利」，而是把「感觉上静态类型更适合 AI」这件事放到了可复现的数字上。选语言时，把生成速度、费用方差、脚手架开销和你真正的运行时约束放在一张桌上，比站队更有用。