Python 最适合 AI 写代码吗?我让 Codex 用四种语言各跑了 5 次

QUOTE

20 次实现都通过了公开测试。到了隐藏测试，有一次栽在一个很不起眼的数字上。

如果只看速度，这次实验的答案很干脆。

Python 用时最短，输出 token 也最少。Go 和 TypeScript 不相上下，Rust 排在最后。

可我把隐藏测试跑完后，排名突然没那么干脆了。

下文仍按行业习惯，把这套 Agent 事先看不到的验收题称为隐藏测试。

20 份实现都通过了 Agent 看得见的公开测试。到了隐藏测试，Python 有一次栽在一个很不起眼的数字上。

这次错误，让整场实验比一张速度排行榜有意思得多。

本文看点

过去选编程语言，团队经验、运行性能和生态成熟度通常占据主要位置。Coding Agent 进入开发流程后，又多了一个问题。

什么语言更方便 Agent 写、测和修？

动态语言的支持者有一套直观解释。Python 语法紧凑，模型熟悉，写相同功能往往只需较少代码。静态语言的支持者也有充分理由。编译器和类型检查器 能及时给出错误位置，相当于 Agent 身边多了一个随叫随到的检查员。

2026 年 3 月，Mame 公开了一组 MiniGit 实验。他让 Claude Code 用 15 种语言配置实现同一套功能，每种配置运行 20 次。在那个原型规模的任务里，Ruby、Python 和 JavaScript 位于速度与成本前列。实验仓库也提醒，这个结果只适用于小规模原型，不能直接推广到大型项目。

后来有人把同一思路搬到 Codex 上。新的复现实验里，75 次语言实验全部通过测试，TypeScript 排到第三，Go 也进入上半区。作者的判断很直接，简单概括成动态语言胜过静态语言 并不成立。

所以我没有再找一道小算法做演示，而是让 Codex 完成一段可以被黑盒测试 的程序。

任务叫 jsonx，是一个 NDJSON 转换命令行工具。

它读取规则文件和数据文件，完成字段选择、重命名、默认值填充以及字符串、整数、数字、布尔值之间的严格转换。程序还要处理非法 JSON、空行、Unicode、错误行号、跳过或中止策略，以及不同错误对应的退出码。

这类任务代码量不算大，却有不少容易含糊的边界。它也适合做行为验收。四种实现的目录结构可以不同，只要对同一输入给出相同输出 即可。

这种黑盒思路和 ProgramBench 接近。ProgramBench 给 Agent 一份程序及文档，再用端到端行为测试检查重建结果。研究者特意指出，有限测试只能覆盖规范的一部分，漏掉一项测试也可能意味着程序存在根本缺陷。

本次实验使用下面四种语言。

我使用 Codex CLI 0.147.0，模型统一为 gpt-5.6-terra，推理强度为 medium。

四种语言各运行 5 次，共 20 个独立会话。每次都从全新目录开始，只能使用标准库和机器上已有的工具链，不能联网下载依赖。Agent 可以看到任务说明和 8 项公开测试，看不到 20 项隐藏测试。单次时限为 720 秒，过程中不进行人工纠错。

正式开跑前，任务、公开测试和隐藏测试的 SHA-256 都已冻结。运行顺序也预先写入清单，失败不能重跑后覆盖。

四种语言的中位数如下。

20 次运行全部正常结束，没有超时和进程错误。公开测试累计执行 160 次断言，全部通过。隐藏测试累计执行 400 次，最终通过 399 次。

正文选用 Output token，是因为它最接近 Agent 实际生成内容的多少。输入 token 会反复包含任务、源码和工具返回，还受到缓存命中的影响。这里没有把 token 强行折算成一个看似精确的综合成本。

Python 的中位完成时间为 108.2 秒，比 Go 少 22.5 秒，比 TypeScript 少 26.4 秒，比 Rust 少 38.3 秒。

它的中位 Output token 也是四种语言里最低的。五次运行中，Python 最慢的一次用了 127.8 秒，依然低于 TypeScript 和 Rust 的中位数，并且只比 Go 的中位数慢约 7 秒。

在这道从零实现的 CLI 任务上，Python 的紧凑表达和模型熟悉度 确实转化成了实际速度。至少这部分结果，与动态语言适合快速原型的经验一致。

Python 官方文档也写得很清楚，运行时不会强制执行函数和变量的类型标注，类型检查需要交给额外工具。这会减少默认约束，也把更多责任交给测试与实现者。

出错的是第 13 次正式运行。

这份 Python 实现通过了 8 项公开测试，也通过了 20 项隐藏测试中的 19 项。失败用例依次输入 +1、NaN、1e309 和 3.5。按照规范，前三项都该被跳过，最终只输出 3.5。

Agent 使用 Python 的 Decimal 解析数字字符串。Python 的高精度数字类型 Decimal 能装下 1e309，所以程序误以为它是合法结果。但普通 JSON 程序通常使用浮点数，解析这个数字后会溢出成无穷大，程序因此被判失败。

这个问题没有语法错误，也没有触发运行时异常。它属于规范边界上的语义偏差。

问题在于，Agent 自己跑过的公开测试全绿。只要不跑隐藏测试，这份实现就会被当成完成。

这里不能据此断言 Python 更容易出错。每种语言只有 5 次机会，唯一缺陷也可能来自随机生成差异。不过它至少提醒我们，Agent 能否可靠交付，很大程度取决于测试有没有覆盖真正危险的边界。

Go 的中位时间比 TypeScript 快 3.9 秒，中位 Output token 少 104。放进五次运行的波动范围里，这点差距不够支持明显的高下判断。

两种语言的 10 份实现都通过了全部隐藏测试。

Go 的优势主要体现在工程流程简单。官方工具链内置测试支持，go test 能直接执行约定目录里的测试并返回失败位置。

TypeScript 则提供渐进式约束。它也留有 any 这个出口，官方文档明确说明，使用 any 会关闭后续类型检查。因此评估 TypeScript 时，是否启用严格模式以及 Agent 有没有绕开类型系统，都会影响结果。

本次任务里，两者交出的结果很接近。Go 略省时间和输出，TypeScript 没有为类型与配置付出夸张代价。

Rust 的中位完成时间为 146.6 秒，中位 Output token 为 6,088，两项都排在最后。它的五份实现全部通过隐藏测试。

Rust 官方文档展示了所有权规则如何在编译期阻止错误使用变量。这些反馈能帮助 Agent 提前修正一部分问题，也会增加生成和修改量。

有趣的是，Rust 最快的一次只用了 105.3 秒。这个成绩比 Go 和 TypeScript 的中位数都快，甚至接近 Python 的中位数。

如果我只挑这一次展示，完全可以写出另一种结论。五次结果放在一起后，Rust 仍是中位数最慢、波动也很明显的一组。

对这道中等规模、标准库可完成、从零实现的 CLI 任务，Python 是最快的原型语言。它省下了约两成到三成时间，也使用了最少的 Output token。

Go 和 TypeScript 提供了更均衡的结果。速度落后 Python，幅度还能接受，五次隐藏测试全部通过。Rust 付出的生成成本最高，五份实现同样全部过关。

正确率的差异还不足以归因给类型系统。样本太小，四种语言总共也只出现一个错误。那次错误倒是揭示了另一件更实际的事。类型检查、编译器和公开测试都无法代替一份严谨的行为规范与隐藏测试。

今后如果用 Agent 从零搭一个脚本、数据工具或短命原型，我仍会优先考虑 Python。需要长期维护的服务，我会把团队熟悉度、生态、部署和静态反馈一起放进选择。无人值守地交给 Agent 执行时，测试设计 的优先级还要继续上调。

一门语言给 Agent 的实际开发成本，来自语言语法、编译器反馈、测试体系、依赖生态和模型熟悉度的共同作用。脱离任务谈一个永远最适合 AI 的语言，结论很难稳定。

这次最重要的数字也许并非 108.2 秒。

是 399/400。

那一个没通过的测试，正好提醒我们，AI 写得快和软件可以放心交付之间，还隔着一套认真设计的验证系统。

REFERENCE

资料与实验文件

· MiniGit 多语言实验https://github.com/mame/ai-coding-lang-bench

· MiniGit 的 Codex 复现实验https://github.com/banteg/minigit-bench

· ProgramBench 论文https://arxiv.org/abs/2605.03546

· GPT-5.6 Terra 官方说明https://developers.openai.com/api/docs/models/gpt-5.6-terra

· Python typing 文档https://docs.python.org/3/library/typing.html

· Go 测试文档https://go.dev/doc/tutorial/add-a-test

· TypeScript 文档https://www.typescriptlang.org/docs/handbook/2/everyday-types.html

· Rust 所有权文档https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html