简而言之

我让 Claude Code 用 13 种语言实现了一个非常简化的 Git 版本。Ruby、Python 和 JavaScript 速度最快、成本最低、稳定性也最好。静态类型语言的速度慢 1.4 到 2.6 倍，而且成本更高。

介绍

哪种编程语言最适合用于人工智能编码代理？

“静态类型可以防止人工智能出现幻觉错误！”
“不，跳过类型注解可以节省令牌！”

关于定性问题的讨论很多，但定量数据却很少。所以我做了一个实验。

实验

我请 Claude Code 用多种语言实现一个“迷你版 Git”（Git 的简化版本），并分别测量了每种语言所需的时间和成本。Git 是 Linus 仅用两周时间就开发的，因此这似乎是一项不错的任务。

这项任务分为两个阶段：

• v1（新项目） ：实现 init 、 add 、 commit 和 log 。
• v2（功能扩展） ：添加 status 、 diff 、 checkout 和 reset 。

提示很简单：“阅读 SPEC-v1.txt ，实现它，并确保 test-v1.sh 通过。” v2 也类似。

比较的语言：

Python/mypy 生成完全类型注解的 Python 代码，并使用 mypy --strict 进行验证。Ruby/Steep 生成 RBS 类型签名，并使用 steep check 进行验证。这使得我们可以直接比较同一语言中类型检查的开销。

每种语言运行了 20 次。模型为 Claude Opus 4.6（高难度）。

结果

20 次试验的平均结果，按平均成本排序。

在 600 次运行（15 种语言 × 2 个阶段 × 20 次试验）中，只有 3 次失败（测试未通过）。失败的语言分别是 Rust（2 次）和 Haskell（1 次）。在其中一次 Rust 失败的日志中，智能体声称“测试有误”。由于所有其他 Rust 试验都成功了，这似乎是智能体的幻觉。

总时间和成本

总时间（v1 + v2）的散点图：

成本：

Ruby、Python 和 JavaScript 位列前三：耗时 73-81 秒，成本 0.36-0.39 美元，标准差低——快速稳定。

从第四名（Go、Rust、Java）开始，方差急剧增加。Go 的平均时间为 102 秒，但波动范围为 ±37 秒。

时间和成本密切相关：

代码行数

v2 版本完成后的 LOC：

OCaml（216 行）、Ruby（219 行）和 Haskell（224 行）最为精简。C 语言以 517 行代码脱颖而出。

有趣的是，代码行数减少并不意味着生成速度更快或成本更低。OCaml 和 Haskell 代码量虽小，但生成速度和成本效益都处于中低水平。

v1/v2 详细结果

按阶段分解：

“Turns”是指在一次提示执行过程中 API 的往返次数（工具调用 → 结果 → 下一个响应）。

v1（新项目）时间

v1 版本显示了不同语言之间最大的差距。Python（32.9 秒）和 Ruby（33.2 秒）领先，其次是 JavaScript（36.0 秒）。Ruby/Steep 耗时 105.0 秒，比纯 Ruby 慢 3.2 倍。Lua（96.4 秒）和 OCaml（80.9 秒）的速度也很慢。

v1 版本从一个空目录开始，因此需要项目配置文件（ Cargo.toml 、 package.json 等）的语言会产生额外的开销。Python、Ruby 和 JavaScript 只需要生成一个 minigit 文件，这或许可以部分解释两者之间的差异。

v2（功能扩展）时间

在 v2 版本中，差距缩小。排名前三的仍然是 #Ruby (40.0 秒)、Python（41.8 秒）和 JavaScript（45.1 秒）。Perl（45.7 秒）、OCaml（47.1 秒）和 Lua（47.2 秒）紧随其后。

Haskell 在 v2 版本中仍然是最慢的，尽管代码行数最少（224 行），平均运行时间却高达 99.6 秒——它似乎在思考令牌上花费了大量时间。C 语言的运行时间为 90.8 秒，主要原因是其代码行数过高（517 行）。

类型检查器开销：Python/mypy 比 Python 慢 1.6-1.7 倍；Ruby/Steep 比 Ruby 慢 2.0-3.2 倍。

数据和复制

所有实验代码和结果均可在 GitHub 上获取：

https://github.com/mame/ai-coding-lang-bench

每次运行的结果都保存在 report.md 文件中。执行日志和生成的源代码位于数据分支上。

注意：benchmark.rb 使用了 --dangerously-skip-permissions ，因此如果您想重现该实验，请务必小心（我是在 Docker 中运行的）。

讨论

以下是我个人的解读。我是一名 Ruby 代码提交者，所以请注意我的主观倾向。此外，我也没有详细分析所有生成的代码。

造成速度/成本差异的原因是什么？

这项实验无法指出单一原因，而且我认为也不存在单一原因。但我们可以根据这些趋势提出假设：

• 类型系统 ：动态语言始终速度更快、稳定性更高。
• 简洁性 ：较短的代码通常意味着更快的生成速度——但 OCaml 和 Haskell 虽然代码紧凑，但生成成本却很高，这显然是由于大量使用了思考标记。
• 过程式与函数式 ：除了排名前三的语言之外，过程式语言和函数式语言之间的差距并不大。值得注意的是，OCaml v2 的 TIME 为 47.1s，足以与 JavaScript 相媲美（尽管 OCaml 可以用过程式风格编写，因此很难进行纯粹的函数式比较）。
• 语言特有的困难 ：C 语言的内存管理和 Rust 的所有权模型可能会增加开销。
• AI 熟悉度 ：Python、Ruby 和 JavaScript 拥有远超其他语言的训练数据。Scheme 和 Haskell 的训练数据可能较少，结果也反映了这一点。Ruby/Steep 的开销（2.0-3.2 倍）高于 Python/mypy（1.6-1.7 倍），这可能也反映出 AI 对 Steep 的熟悉度低于对 mypy 的熟悉度。

很可能是这些因素共同作用导致了观察到的结果。

缺少类型岂不是会导致更多 bug 吗？

有可能。测试通过了，但动态类型语言中未经测试的路径可能存在类型错误。

也就是说，类型错误是最容易检测和修复的错误之一。如果一个代理程序在没有类型检查器的情况下频繁引入类型错误，那么它很可能也会以类似的频率引入逻辑错误——这时问题就不仅仅是类型检查就能解决的了。

值得注意的是，在 600 次运行中，仅有的 3 次失败分别发生在 Rust（2 次）和 Haskell（1 次）中——这两种语言都是静态类型语言，都具有所有权和 monad 等独特概念。这或许只是巧合，但类型并不能完全杜绝 bug。

2倍的差距不算太大，对吧？

我认为是的。

在实际开发中，你会不断迭代：提示 → 等待 → 思考下一个任务 → 再次提示。等待 30 秒和等待 60 秒之间的差别至关重要——不仅体现在总时间上，还体现在专注度和流程效率上。响应时间在迭代开发中至关重要。

“花更多时间打造稳健的产品”这种说法固然有道理，但当竞争对手的出货速度是我们的两倍时，等待真的是正确的选择吗？开发速度本身就是质量的一个维度。

也就是说，如果未来两者之间的差距缩小到 1 秒对 0.5 秒，那么就真的无关紧要了。

任务规模太小。静态类型应该在大规模场景下才能发挥优势。

我同意。但是，要设计一个能够公平地涵盖15种语言的大规模基准测试，确实很有挑战性。应该有人尝试一下。

难道生态系统和运行时性能对于语言选择不是更重要吗？

当然。从代码生成的角度来看也是如此——如果你能利用现有的生态系统，需要生成的代码量就会减少，速度更快，成本更低。如果运行时速度对你的应用程序至关重要，那就没有理由选择速度慢的动态语言。

为了进行这项实验，我特意选择了一个不依赖任何外部库的任务，以隔离语言层面的差异。因此，规范中使用了自定义哈希值而非 SHA-256。

结论

我使用 Claude Code 对哪些编程语言最适合代码生成进行了定量评估。至少对于原型开发规模的任务而言，Ruby、Python 和 JavaScript 似乎是最佳选择。

静态类型在大规模应用中可能具有优势——应该有人测试一下。

经典策略——先使用动态语言，然后随着项目成熟迁移到静态语言——或许仍然是正确的选择。编码代理似乎非常擅长跨语言迁移（尚待验证），这使得该方案越来越现实可行。

笔记

• 评估时间为 2026 年 3 月。鉴于人工智能的发展速度，几个月后结果可能会有所不同。
• 这项实验得到了 Claude for Open Source Program 的支持。感谢 #Anthropic 公司提供 6 个月的免费 #Claude Max 20x！