AI 时代，编程语言该改哪里

一门「为 AI 设计」的编程语言，最容易做的改动是语法：少写括号、少写类型、少写样板。Elixir 的作者 José Valim 说，这些恰恰是最不值得改的。

他的理由很直接：模型不在乎样板，也不会因为少打几个字符就变聪明。

一、发生了什么

9 月 24 日，Valim 在 Dashbit 博客发了一篇长文，谈编程语言在 AI 时代会怎么演化。文章分两部分：一部分是疑问，一部分是明确的主张。

疑问集中在社区和周边工具。语言不只是一套语法，还有围绕它形成的一群人：Python 讲究「只有一种明显做法」，Ruby 讲究写代码的快乐，Lisp 讲究语言可以被改写。如果大部分代码不再由人写，这些共识还剩下什么？周边工具也有两种相反的走势：一方面，agent 能快速把别的语言里的框架移植过来，小社区和大社区的差距会缩小；另一方面，既然实现一个库变得便宜，人可能干脆让 agent 给自己造一个，不再参与共建。

主张集中在工具。他列了四条：第一，别再把「容易推断」当成类型系统的目标，模型不怕啰嗦，把类型和意图写清楚，编译器和别的 agent 才有信息可用；第二，语言应该在四个层面加强保证——让非法状态写不出来、静态检查、运行时约束、测试与模糊测试；第三，用「程序数据库」替代 LSP，让 agent 直接查询符号、引用、调用图，而不是让它报出文件名和行列号；第四，用运行时可观测性替代调试器，让 agent 自己埋点、取轨迹、查状态。

他还补了一句限制：局部性仍然重要。Monkey patch、隐式钩子、动态重绑定这类「隔空改行为」的写法，会让代码库即使有数据库也难以追踪。

二、跟你有什么关系

设计内部语言或框架的。 如果你的「AI 友好」只体现在语法糖上，方向大概错了。把类型、约束、错误信息做扎实，收益更持久。

维护开发者工具的。 LSP 是给 IDE 和人的眼睛设计的，按文件、行、列组织信息。agent 要的是「这个函数在哪定义、谁调用它」，是一个可查询的库，不是一屏高亮。

写代码的。 你未来审的不是每一行，而是规格和约束。语言能不能把意图固定下来，比它写起来顺不顺手更重要。

三、今天能照着做的四件事

1. 把类型写全，别省。 推理出来的类型对人友好，对协作的 agent 不友好。函数签名、返回值、可空性，能写就写。
2. 把约束前移。 能在类型里表达的状态，不要留到运行时用 if 判断。非法状态写不出来，比写出来再报错省事。
3. 给 agent 一个查询入口。 哪怕只是把符号表、调用关系导出成一张表，让它用 SQL 查，也比让它 grep 整个仓库强。
4. 把运行时暴露出来。 进程、队列、连接、缓存命中，这些能被程序查询，agent 才能自己诊断，而不是让你贴日志。
5. 减少隔空改行为。 隐式钩子越多，agent 越容易改 A 处、坏 B 处，而且查不出来。

四、三个别信的说法

「为 AI 造语言，就是让语法更简单。」 Valim 的原话更狠：只盯着语法的「AI 语言」，是在围绕当前模型的局限做设计。模型在进步，语法优势会消失，约束和工具不会。

「agent 会写汇编，所以高级语言没用了。」 他给了两个反驳：桌面应用不可能为每种架构维护一套汇编；也没有哪一种语言能同时胜任系统编程、定理证明、并发容错和硬件描述。抽象层不会消失，只会换服务对象。

「工具做好了，人就没事了。」 文章开头就在问社区怎么办。工具能替人干活，替不了人形成共识。工具是共建出来的，不是 agent 各自造一个库堆出来的。

五、一句话结论

别为模型今天的短板改语法，要为它明天的责任加约束。

信息来源

• Evolving programming languages in the AI era，Dashbit Blog，2026-09-24

功能与价格以官方公告为准。本文写于 2026 年 10 月 19 日。