“动态语言对 AI 编程更友好，因为少了类型声明，代码更紧凑，token 消耗更少。”这个说法在过去一年被反复引用，几乎成了 AI 编程语言选择的常识。Dan Luu 设计了三组严格实验，给出了一个不那么舒服的答案：这个说法在小任务上可能成立，但在真实规模的编程任务面前，它消失了。
实验设计：为什么值得先讲清楚
Dan Luu 的实验设计值得先讲清楚。他不做简单的“请用 Python 写一个排序函数”这类玩具题，而是模拟真实开发场景：给定一个已有代码库，要求 AI 在其中完成一项功能修改或缺陷修复。代码库的规模从几百行到数千行不等，涉及多种语言。
三组实验分别对应三个维度：
- 任务规模：从单文件小函数到跨多文件的大型重构。
- 语言配对：动态语言（Python、JavaScript）与静态语言（TypeScript、Go、Java）的对比。
- 上下文长度：限制 AI 可读取的代码上下文窗口大小，模拟真实 token 预算。
第一组实验：小任务上的“优势”确实存在
当任务局限在单个函数或几十行代码内时，动态语言确实表现出更低的 token 消耗。原因很直观：没有类型注解，代码量更少，AI 需要生成的 token 数自然更少。在简单的“实现一个数组去重”或“写一个日期格式化函数”这类任务上，Python 的平均 token 消耗比 TypeScript 低约 18%。
但这组实验也暴露了一个细节：正确率并没有因为 token 少而提升。动态语言生成的代码虽然短，但出错率与静态语言相当，甚至在某些边界条件处理上略逊一筹。
第二组实验：真实规模下的逆转
当任务切换到真实代码库时，情况发生了逆转。在一个约 2000 行的 Python 项目中修复一个 bug，AI 需要反复读取多个文件来理解数据流。由于没有类型约束，AI 经常需要额外的“探索性”token 来推断变量类型和函数签名。
相比之下，TypeScript 项目中的同名任务，AI 通过类型定义就能快速定位问题。实验数据显示：在 2000 行以上的代码库中，静态语言的 token 消耗反而比动态语言低 12% 到 25%。原因在于，类型声明虽然增加了初始代码量，但显著减少了 AI 在推理过程中的“猜测”成本。
“在小任务上，动态语言省下的 token 是显性的；但在大任务上，静态语言省下的 token 是隐性的——它避免了大量无效的上下文读取。”Dan Luu 在实验笔记中写道。
第三组实验：上下文窗口的放大器效应
第三组实验最值得关注。当把 AI 的上下文窗口从 32K 压缩到 8K 时，动态语言的表现急剧下滑。在 Python 项目中，AI 经常因为无法同时容纳所有相关代码而“遗忘”关键信息，导致生成错误代码或重复读取。
而静态语言项目在同样的限制下，AI 可以依赖类型签名快速重建上下文，错误率上升幅度远小于动态语言。实验结论很明确：上下文窗口越小，静态语言的优势越明显。
结论：常识需要修正
Dan Luu 的结论不是“静态语言更好”，而是“动态语言对 AI 更友好”这个说法过于简化。真实情况是：
- 在 100 行以内的任务中，动态语言确实更省 token。
- 在 500 行以上的任务中，静态语言的类型信息成为 AI 的“路标”，反而更省 token。
- 在上下文受限的部署场景中，静态语言的鲁棒性显著更强。
这个实验提醒我们：选择 AI 编程语言，不能只看单次生成的 token 数，而要计算整个任务完成过程中的总 token 消耗。对于真实项目开发，类型声明不是负担，而是给 AI 的“压缩提示”。
当然，实验也有局限。Dan Luu 只测试了 GPT-4 级别的模型，且代码库规模未超过 5000 行。但至少，它给那个被反复引用的“常识”打上了一个问号。