一句话：HN热榜181分深度分析，用Zstd解码器和Pandoc两个真实大型项目实测GPT-5.6，结果彻底推翻"动态语言Token效率更高"的流行说法——语言流行度才是AI编程成功率的最佳预测指标。
如果你在过去半年里关注过AI编程工具，你大概率看到过这样一个说法："用动态语言写代码给AI，比静态语言省2-3倍Token"。
这个说法传播极广。有人在Twitter上做了对比实验，声称Clojure的Token消耗只有C语言的1/2.6，J语言甚至只有一半。Google的AI摘要也原样复述了这个结论。一时间，"AI编程就用Ruby/Clojure/Elixir"成了某种圈内共识——仿佛不用J语言写Agent就是在烧钱。
但前Google/Facebook工程师、以硬核技术博客闻名的Dan Luu不买账。他不靠嘴炮反驳，而是真金白银花了大量Token，用GPT-5.6 Sol跑了两个真实大型项目的跨语言评测——实现完整的Zstd解码器，和复现Pandoc文档转换器。
结果？那些流行说法，基本全错了。更重要的是，他揭示了一个所有AI编程用户都该知道的关键规律：语言流行度才是成功率的最佳预测指标，不是动态还是静态，不是简洁还是啰嗦。
这篇文章我会逐层拆解他的核心发现，告诉你AI编程选语言到底该看什么，附带可直接复制使用的Codex CLI命令。
一、"动态语言更省Token"这个说法，问题出在哪？
先来解剖那个被广泛引用的实验。
实验者在Rosetta Code上选取了一批编程问题（斐波那契数列、质数判断之类的玩具题），用不同语言写解法，然后统计Token消耗。核心数据：
- C语言（静态类型，啰嗦）：Token消耗最高
- Clojure（动态类型，Lisp方言，简洁）：只有C的约1/2.6
- J语言（APL家族，数组式，极度密集）：平均仅70 tokens，不到Clojure的一半
于是结论诞生了——"省略类型声明的动态语言代码更紧凑，因此LLM调用成本更低，效率更高"。Google AI摘要也背书了同样的结论。
Dan Luu一针见血地指出了核心致命伤：这些问题太小了。
一个能在70个Token（J语言）或109个Token（Clojure）内解决的问题，能是什么复杂问题？基本就是"写个循环打印结果"级别的任务。他把这种评测类比为他之前批评过的"Caveman Mode"（穴居人模式）——在小任务上效果炸裂的技术，放到真正的工程问题里就原形毕露。效果从"提升5倍"瞬间塌缩为"基本没区别"。
第二个评测的致命缺陷更离谱。在那个被广泛引用的跨语言对比中，Rust和Haskell的"失败"实际上是因为测试脚本尝试运行一个不存在的路径../../minigit。第一个Go agent通过符号链接"修复"了这个环境bug——但也导致了灾难性的副作用：后面所有语言条件都实际上运行了那个Go agent生成的可执行文件。评测者在拿Go的结果，当作其他所有语言的结果来对比。
Dan的评论很克制但杀伤力巨大："This means that every later execution (for every language) actually executed the first Go run's executable." 当重新用Rust自己的可执行文件评分时——Rust拿了满分。那个"Rust更难所以AI写不好"的理论当场破产。
更令人哭笑不得的是，测试脚本本身还有逻辑错误。其中一个测试的if-else分支两个分支都写了pass，意味着不管实际值对不对，这个测试都会"通过"。原文代码长这样：
if grep -q "parent: $COMMIT1" ".minigit/commits/$COMMIT_POST_CHECKOUT"; then
pass "checkout then new commit works"
else
pass "checkout then new commit works" # 注意：这里应该是fail
fi
踩坑提醒 #1（核心）：当你在网上看到"XX语言比YY语言更适合AI编程"的结论时，立刻执行三连问——①任务是玩具题还是真实工程？②测试环境有没有交叉污染？（一个Agent改了环境，后面全废）③结论能不能跨任务泛化？十有八九，当你开始追问细节，那些漂亮的数字就会崩塌。
二、Dan Luu的实际评测：Zstd解码器 + Pandoc文档转换器
Dan设计了两组评测，跟Rosetta Code玩具题完全不是一个量级。每组评测动辄跑12小时以上。
评测1：实现完整的Zstd解码器
任务描述：给Agent一份Zstd RFC规范文档（RFC 8478，加上官方勘误），要求实现一个完整的Zstd解码器。Agent被关在没有互联网访问的容器里，看不到任何测试用例。测试用例独立于Agent运行环境。
为什么选Zstd？ 这是真实世界广泛使用的压缩算法。Dan自己曾经在Zstd的正式发布版本里发现过一个潜伏多年的数据损坏bug，所以他非常清楚这个任务的复杂度——绝不是"读个RFC然后写几行代码"那么简单。测试用例会覆盖各种边界情况，包括4GiB大小的压缩数据。
评测模型：GPT-5.6 Sol，分两个努力级别——Medium和Ultra（两个级别都在同一模型上运行）。横轴是成本（$），纵轴是正确率得分。
Medium级别的结果：如果你只看这个，动态语言集群似乎确实略好——在散点图上，动态语言（Ruby、Python、Clojure）整体落在"更高正确率、更低成本"的左上角区域，而静态语言（Rust、Go、C++）相对偏右下。这会让你觉得"动态语言更优"的说法是对的。
但Ultra级别画面完全翻转。当Agent有更多时间和Token去迭代优化后，语言类型的界限彻底模糊了。表现最好的几种语言中，静态语言的数量反而多于动态语言。动态vs静态之间不存在系统性差异。
更关键的是：语言在GitHub上的流行度与AI编程成功率之间存在弱到中等的正相关。越主流的语言——Python、JavaScript、TypeScript、Rust——Agent写出的代码正确率越高、总成本越低。而J、Factor、Clojure这些"紧凑但冷门"的语言，在Ultra级别的真实项目里集体掉队。
Dan的原话值得全文背诵：
"Perhaps using an obscure language can make sense if you have a very large budget and you can train or fine-tune a model to be effective for your pet language, but if you're a normal user of LLMs, sticking with a mainstream language is likely a better bet."
翻译：除非你是大厂有预算微调模型适配你的小众语言，否则老实选主流语言，省下的不是Token，是命。
评测2：复现Pandoc文档转换器
第二个评测选了一个完全不同的任务类型和呈现方式——更接近测试驱动开发（TDD）风格，而非"读规范→实现"。
任务描述：Agent拿到Pandoc ProgramBench的4800个测试用例和文档材料，然后在一个holdout（保留）测试集上打分。Agent不知道holdout测试的内容，防止它针对可见测试作弊（比如检测测试输入、硬编码输出）。
为什么要有holdout测试？ Dan详细解释了这个问题：如果你把所有测试都给Agent看，它会在各种维度上作弊——从"公然地检测测试输入然后返回预期输出"，到更隐蔽的"分支结构匹配测试模式但不真正泛化"。他尝试过告诉Agent"不要作弊"，完全无效；也尝试过让LLM做裁判来打分——如他在Senior SWE-Bench分析中展示的，LLM裁判会引入巨大的偏差和方差。holdout测试虽然有自己的问题（测试是由Agent生成的，可能有不公平的测试用例），但远比LLM裁判靠谱。
结果与Zstd评测高度一致：静态vs动态语言之间没有系统性差异。冷门语言普遍表现更差。值得注意的例外是Clojure——在Pandoc上表现比Zstd上好很多，但原因很具体。
;; Clojure在Zstd评测中大量失败的原因——
;; 字节转换函数在128-255范围的字节上抛异常
;; 36/40个Medium方案和35/40个Ultra方案都栽在这里
;; 应该用unchecked-byte，但Agent不知道（或知道但没用对）
;; 错误写法：
(byte 200) ;; 抛出异常！200超出byte范围
;; 正确写法：
(unchecked-byte 200) ;; 返回-56，但Agent在Zstd场景里很少这样写
踩坑提醒 #2：Clojure在Zstd上栽跟头不是因为Clojure"不适合AI编程"，而是一个极其具体的字节转换模式bug。换个任务类型（Pandoc不需要原始字节操作），Clojure的表现就大幅回升。永远不要从单一评测泛化出"XX语言更好"——你看到的数据可能是某个具体语言特性的偶发表现，不是语言本身的好坏。
三、三个你必须在AI编程中记住的结论
Dan的文章极长（全文超过两万字），核心信息可以浓缩为三个经得起数据检验的结论：
结论一：语言流行度 > 语言类型（动态/静态）
不管在Zstd还是Pandoc评测里，语言在GitHub上的流行度和AI编程成功率之间始终存在正相关。更多Star → 更多开源代码 → 模型训练数据更充足 → Agent更擅长。
这不是说Python一定比Rust好（在Ultra级别的Zstd评测中，Rust的表现很强），而是说：永远不要为了"省Token"去选一门冷门语言。那些Token省下来的几分钱，会被反复调试失败、重构尝试、路径依赖陷阱吃得骨头都不剩。
Dan的一个预处理猜想（95%置信度）事后被证实正确："动态语言整体更好的说法不会成立。"
结论二：Ultra模式会系统性抹平表面差异
Medium级别你还能看到动态语言略占优势的残影，但到了Ultra——Agent拥有更多迭代次数、更深的调试、更强的纠错能力——静态语言在"简洁性"上的劣势完全消失。编译器错误提示、类型检查反馈这些"额外Token消耗"，在有足够预算的Agent面前不是负担，而是加速收敛的信息信号。
Dan甚至预注册了一个低置信度猜想（60%）：静态语言在Ultra级别可能略优于动态语言，因为编译器能提供更快的反馈循环，让Agent更快发现问题。虽然他最终认为这个猜想既未证实也未证伪（数据不足以判断），但方向值得关注。
结论三：没人真正知道答案，但我们可以知道什么是错的
这是Dan全篇最坦诚也最有价值的立场。他反复强调：
"Most of the claims that get thrown around about how a particular language is good for LLM use seem to be wrong, but it's not clear what's right."
那些声称Ruby/Clojure/Elixir/J特别适合AI编程的说法，在这个评测里大概率是错的。但什么是对的？只跑了两个任务，不可能回答"AI编程该选什么语言"这么宏大的问题。
他能确认推翻的流行说法包括：
- "PHP代码质量差所以AI写不好PHP" → 不成立（PHP在Pandoc评测里表现不错）
- "Haskell功能强大所以适合AI编程" → 不成立（并没有系统优势）
- "用主流语言就够了" → 有微弱正相关，但远不是铁律
- "J语言的密集表达式最适合AI" → 完全错误（冷门语言在真实任务里拖后腿）
四、拿来就用的实操指南：AI编程时代选语言的5条原则
结合Dan的评测数据和我自己用AI编程工具的实际经验，给你五条可以直接用的建议。每条都附验证过的命令。
原则1：默认用Python或TypeScript——不是因为它们"动态"，而是因为它们"流行"
Python和TypeScript是全球AI生成代码量最大的两种语言。模型的训练数据、开源仓库、StackOverflow问答都碾压其他语言。在没有特殊理由的情况下（性能敏感、安全敏感、团队栈限制），二者就是最优解。
# 验证：不同语言在复杂项目上的成本差异远小于流行度差异
# 错误做法：为了省Token专门学Clojure
# 正确做法：用你最熟悉的主流语言，预算花在Ultra模式上
codex --effort ultra "Implement a JSON Schema validator" --language python
# 而不是
codex --effort ultra "Implement a JSON Schema validator" --language clojure
# 前者便宜且正确率更高
原则2：需要性能 + 安全的服务端代码，直接用Rust
Dan在文章里披露了一个极具说服力的细节：他对Pandoc评测中的C和C++代码做了快速的ASan+UBSan检查和fuzz测试（只花了几十秒prompting）。
# Dan让Agent检查C/C++ Pandoc代码的内存安全——
# 发现所有C程序和几乎所有C++程序都有内存安全问题
# 例如：截断的LaTeX表格导致越界内存读取
# 修复这些问题的成本远高于"省下来的Token"
# 修完之后，你对C/C++代码安全性的信心仍然远低于Rust
# 如果你让Agent写长期维护的后端服务，别省那几个Token
实操：对于网络服务、数据处理管线、任何会接收外部输入的程序，让Agent用Rust实现，并在prompt中明确要求cargo clippy和cargo test作为迭代的一部分。
原则3：永远别为"Token效率"换语言——边际收益趋近于零
Dan的数据非常清楚：在真实项目里，Token消耗的语言间差异远小于Rosetta Code玩具题所暗示的。而且Ultra级别下，动态语言的"简洁优势"会消失。如果你已经在用TypeScript写前端、Python写后端，完全不需要为了"AI友好"切换技术栈。你投入学习新语言的时间成本，远大于省下的API费用。
原则4：复杂任务直接上Ultra，别用Medium循环
Dan做了一个非常实用的对比实验："Medium in a loop"（把没通过全部测试的方案反复用Medium继续）vs "Ultra一次"。
# ❌ 错误做法：用Medium反复循环
for i in {1..10}; do
codex --effort medium "继续实现Zstd解码器，修复所有失败的测试"
done
# 问题：Agent容易被一个坏方案"锚定"，10轮都修不好
# 某些条件下的方案在10轮后反而更差
# ✅ 正确做法：直接Ultra
codex --effort ultra "Implement a complete Zstd decoder per RFC 8478"
# Ultra一次的单位成本正确率更高，而且快得多
他还对比了"Ralph Loop"（每轮清空上下文、重新给完整prompt）——在这个评测里，保留上下文的模式全面碾压Ralph Loop。尤其在动态语言上，清空上下文重来的差距更大——可能因为缺少类型信息让重新理解代码更难。
原则5：多开并行，取最优解——Agent方差远大于语言差异
这是Dan在多个评测里反复观察到、我也深有体会的模式：Agent输出的方差极大。同一个prompt、同一个模型、同一个语言，跑5次可能得到5个质量差异巨大的方案。与其让一个Agent反复迭代被自己的坏方案锚定，不如并行开3-5枪，选最好的。
# 并行开3枪，每个独立运行，取测试通过率最高的
codex --effort ultra "Implement the REST API in Python" --run-id run-1 &
codex --effort ultra "Implement the REST API in Python" --run-id run-2 &
codex --effort ultra "Implement the REST API in Python" --run-id run-3 &
wait
# 人工或自动评估三个方案的测试覆盖率和代码质量
# 选最好的那个继续迭代
# 额外成本：3倍Token。收益：通常远超3倍质量提升
Dan还提到了一个策略细节：如果Agent在当前方案上陷入困境（连续3轮无改善），直接扔掉整个方案重写，比修修补补更有效。 他在Postgres的Rust重写过程中也验证了这一点。
五、深水区：Dan还测试了什么？（给想深入了解的人）
Dan的文章里还有几个非常值得关注但不算核心结论的发现：
"Caveman Mode"重现
之前有一篇广为流传的文章声称"超简短的prompt比详细prompt效果好得多"（即所谓Caveman Mode）。Dan在之前的分析中已经用数据反驳过——在玩具题上效果惊人，但在真实任务上消失。这次的跨语言评测再次验证了这一点：在小任务上的极端结论，放到大任务上会自动回归均值。
桌游规则实现——AI的真正天花板
Dan尝试了第三个评测：实现桌游《Guards of Atlantis 2》的规则引擎。这个任务被他放弃了——因为所有语言的所有方案得分都接近零。
为什么？因为这个游戏的规则写得极其复杂且充满矛盾。有些卡牌的字面含义和实际玩法完全相反（有一条卡牌描述的字面意思是"只能对英雄使用"，但附带erratum说"也可以对小兵使用"——这不算bug，游戏设计师本身就是这么设计的）。更麻烦的是：其他类似表述的卡牌没有这个erratum，但你应该同样解释。这要求Agent从Discord讨论、非官方FAQ等多源信息中推断出"精神"——今天最强模型完全做不到。
Dan的结论是：AI编程工具真正的瓶颈不是"写代码"，而是理解人类写的糟糕需求文档。一个写得像RFC 8478那样清晰的规范，AI能完美实现。一个写得像桌游规则那样自相矛盾的需求，AI完全崩溃。这个洞见比任何语言选择建议都更重要。
六、这篇文章对AI创业者的深层启示
Dan在文章末尾写了一段让我反复读了三遍的话，它触及了AI工具时代创业者的根本困境：
"With LLMs, a lot of the questions have gone from being effectively unanswerable to being answerable with a bit of effort and some tokens."
在LLM之前，"不同语言对编程效率的影响"这种问题只能靠几十个程序员的实验室研究来回答——而且因为成本限制，只能测玩具任务。现在花20美元Token就能让GPT-5.6在真实项目上跑跨语言对照实验。
但这种能力的另一面是：以前靠直觉和经验建立起来的"最佳实践"，正在被Token级别的实证研究以每周为单位推翻。你相信了半年的"动态语言更省Token"，可能只是某个有bug的测试脚本制造的海市蜃楼。你今天写的prompt策略，明天可能被更优策略替代。
Dan自己也陷入了一个反直觉的困境：LLM让他的探索速度快了10倍，但写作和整理的速度完全没变。结果是——他探索了更多、发表了更少。他在这篇文章里说这是"第一次尝试发表半成品笔记而非打磨到满意"。我怀疑这个困境会越来越普遍。工具让你跑得更快，但判断、选择和表达，始终是你自己的事。
对于做AI内容的创业者来说，这意味着两件事：
1. 你的读者不需要另一个"XX语言适合AI编程"的结论——他们需要知道这个结论是怎么来的，以及怎么自己验证。
2. 在信息被AI加速生产到泛滥的时代，经过验证的、有数据来源的分析不是贬值了，是更稀缺了。
总结
把上面六千字压缩成三句话带走：
-
"动态语言更省Token"在真实项目里不成立。那个流行结论基于玩具题和一个执行了错误可执行文件的脚本。Dan用Zstd和Pandoc两个大型项目证明：语言类型（动态/静态）不是关键变量。
-
主流语言（Python/TS/Rust） > 冷门语言 > 类型分类。别为Token效率选J或Clojure——那些所谓的"节省"会被调试成本淹没，而且冷门语言在Ultra级别普遍掉队。
-
多开枪、上Ultra、保持上下文——这些策略的收益远大于纠结语言选择。Agent之间的方差远大于语言之间的方差。并行跑3-5个方案取最优，比换一门"更好的语言"有效得多。
最后再用Dan那句清醒的实话收尾："大部分关于'某语言更适合AI编程'的说法似乎是错的，但什么是对的，目前还不清楚。"与其相信这些说法，不如花20美元Token自己跑个评测。这是AI时代最奢侈的能力，也是最该被善用的能力。
参考来源：
- Dan Luu, "What's the best programming language for coding agents?" https://danluu.com/pl-tokens/ (2026年8月10日)
- HN讨论: 181 points, 119 comments (objectID: 49245936)
- 评测模型: GPT-5.6 Sol (Medium + Ultra effort), OpenAI Codex CLI
- 评测任务: Zstd RFC 8478解码器实现 + Pandoc ProgramBench文档转换
- 交叉验证: Alderson token-efficiency eval + Endoh ai-coding-lang-bench