Elixir 之父 José Valim 前些日子在 X 上发了一篇长文，很快在海外开发者圈里刷了屏。他抛出的问题相当直接：如果未来大部分代码都由 AI Agent 来写，编程语言、开发者社区，乃至 IDE、调试器这些我们习以为常的工具，是不是都要推倒重来？这篇文章把他的核心思考，以及评论区里的激烈交锋，一次讲透。
这篇文章的几个核心判断：
- Elixir 之父 José Valim 发长文，系统讨论 AI Agent 时代编程语言该如何演进
- 他认为：语法层面的“人体工学优化”对 Agent 意义有限，Agent 在乎的是 token，不是好不好看
- 编译器不会消失，因为不同领域需要不同的抽象层次，没有一种底层语言能统一所有场景
- 提出两个关键工具升级方向：用“程序数据库”取代 LSP、用“运行时可观测性”取代调试器
- 评论区分裂成两派：一派认为调试器、社区、人体工学统统会被颠覆；另一派认为“人类需要的，Agent 最终也需要”
Tidewave 创始人、Elixir 创造者 José Valim 长文引爆 X：程序数据库取代 LSP，运行时可观测性取代调试器
引言：一条刷屏推文
9 月 24 日，Elixir 语言的创造者、Dashbit 首席采用官、Tidewave 创始人 José Valim 在 X 上发布了一篇长文，标题很直接：《Evolving programming languages in the AI era》（AI 时代编程语言的演进）。
发布不到一天，这条推文就拿下数百个点赞、几万浏览，评论区也直接吵成了两派。
整篇文章的结构很清晰，分成两部分：
- 反思篇：如果人类不再写大部分代码，编程语言、生态、社区会发生什么变化？
- 工具篇：更具体、也更有操作性——既然 coding agent 已经成了编程语言的“新用户”，我们的工具应该怎么改？
Valim 自己也说，这些观点“很可能会变”，只是当下的一份阶段性思考。但正因为他不是在喊口号，而是在认真拆解每一个细节，这篇文章才格外值得细读。
反思篇：当人类不再写大部分代码
社区还能靠什么粘合在一起？
Valim 先从“社区”聊起。他观察到，几乎每一种主流编程语言背后，都有一套共同的价值取向在支撑社区：
- Python 社区推崇“有且只有一种明显的做法”
- Ruby 社区长期强调“程序员的幸福感”
- Lisp 社区则以“能够重塑语言本身”为荣
问题来了：如果人类不再写大部分代码，这种归属感还剩下什么？这是应该努力守护的东西，还是说社区终究会自己找到新的粘合剂？
他接着向下推了一层，谈到语言生态，包括 Web 框架、张量库、数据处理管道、GUI 工具包等等。他认为 Agent 会从两个相反的方向影响生态：
- 一方面，搭建这些框架本身极其耗时耗力，很多工作是“翻译已有实现”、“照着论文复现算法”，这些恰恰是 Agent 擅长的。小生态可能因此快速追平大生态。
- 另一方面，如果实现一件事的成本变得足够低，人们还有动力凑在一起共建同一个方案吗？如果我需要一个库来解决问题 X，我可能直接让 Agent 按我的需求“量身定做”一个。
Valim 把这称为一种张力：Agent 一边在大幅降低生态搭建的成本，一边又在削弱促使生态形成的原始动力。
人体工学（ergonomics）优化，Agent 真的在乎吗？
这一段是全文最“扎心”的部分之一。
过去十年，很多语言都在往“人体工学”方向进化——比如加入可选链操作符，让人不用再写一长串显式的空值判断。但 Valim 反问：如果人类不再是主要的代码书写者，这些改进还有多大意义？
Agent 不会因为写了一堆样板代码而觉得烦，语法上的美感差异，对模型来说可能微不足道。有人会说这些优化其实也能提升 token 效率，但 Valim 并不认为这个理由能排在优先级前列——尤其是当模型越来越便宜、上下文窗口越来越大的时候，token 效率本就该是最靠后考虑的指标。
他甚至撂下一句挺重的话：任何声称“为 coding agent 而生”，却把重点放在语法上的新语言，本质上都是在围绕今天的局限性打转。他自己用 Agent 写过 HTML、CSS、JavaScript、Elixir、Rust、Lean，在人类眼中天差地别的语法风格，在 Agent 那里似乎没那么重要——对模型来说，一切都只是“token 进，token 出”。
编译器会被淘汰吗？
顺着“语法不重要”的思路，很自然会冒出一个更激进的问题：既然如此，我们还需要编程语言吗？会不会 Agent 干脆绕过编程语言，直接写汇编？
Valim 给出的答案是：不会。理由有两条。
第一，如果你在做桌面应用，你大概率不想为每一种架构分别维护一套汇编实现，你仍然需要一个与架构无关的中间表示，以及能把它降级到目标机器的能力——换句话说，你已经重新发明了编译器和一门高级语言的一部分，即便这门语言从来不是为人类书写而设计的。
第二，人类至今没有找到一种“包打天下”的语言或计算模型。系统编程语言、定理证明器、面向并发、分布式与容错场景的语言（比如 Erlang/Elixir）、查询语言、硬件描述语言……它们编码了不同的语义、不同层次的抽象、不同的保证。指望一门底层语言统一所有这些场景，并不现实。
那么问题就变成了：如果编程语言不会消失，只是不再为“书写它们的人类”做优化，那我们该为谁去优化它？
答案就是文章第二部分的主角：Agent 本身。
工具篇：为 Agent 重新设计开发者工具
Valim 特别强调一点：这部分讨论的工具，并不要求 Agent 写完你所有的代码。哪怕 Agent 只承担了你 20% 的工作量，这些工具依然值得投入。
他还提到一个自己一直坚信的原则：为人类打造好用的工具，最终也会带来好用的 Agent 工具。过去我们已经在朝这个方向努力——让 Agent 写和我们一样的测试、消费和我们一样的程序元数据、读和我们一样的日志。
但如果 Agent 要承担的是我们自己都不太愿意做的事情呢？比如太繁琐、学习曲线太陡，或者需要处理远超人类处理能力的信息量？这正是下面三个方向要回答的问题。
给约束松绑：类型系统该为谁而设计？
编程语言在设计上要在表达力、保证、人体工学这三者之间做权衡。
我们希望语言能表达自己关心的程序，也希望语言能对这些程序建立有用的性质保证，同时还要方便开发者使用。如果 AI Agent 正在写大部分代码，这些权衡就值得重新审视。
一个典型例子是函数签名推断。
对人类来说，显式写出编译器本可以推断出的信息是一种负担；但 Agent 根本不在乎繁琐。相反，把类型和意图明确写出来，反而能给编译器、给其他 Agent、给我们自己提供更多信息。
更重要的是，类型系统能完全推断出的类型集合，通常是能被检查的类型集合的一个子集——也就是说，一味优化“可推断性”，反而限制了表达力和类型系统能提供的保证上限。既然我们已经见过 Agent 能在复杂得多的系统里写形式化证明，为什么还要给它们设这样的限制？
保证也不必只靠静态手段建立。内存安全既可以静态强制，也可以通过运行时（比如垃圾回收）实现；模型检查可以用模型生成的执行轨迹去校验真实系统。一个典型案例就是 Erlang/Elixir 依赖隔离的进程和消息传递来约束并发程序的结构——虽然牺牲了一部分表达力，却换来了隔离性和容错性上更强的保证。不是所有并发算法都能高效映射到这个模型，但能映射的那部分，都能从中继承实实在在的好处。
Valim 总结了当下可以组合使用的四类保证机制：
他认为，未来语言之间的差异化和被采纳的程度，会越来越取决于如何组合这些手段、如何在表达力与保证之间划出自己的边界——尤其是如果你相信 Agent 会让不同生态之间更容易互相追赶，呼应前面“社区”那一节，这一点会变得更重要。
程序数据库，取代 LSP
这是全文最“落地”的一个判断：LSP（语言服务器协议）大概率活不过调试器。
IDE 的“死亡”这几年被反复宣判，一旦这个“讣告”真正落地，LSP 恐怕也难以幸免。
原因在于，LSP 的很多操作是围绕“文件、行、列”这套面向人类交互的定位方式设计的，而 Agent 根本不擅长精确追踪这些坐标。Valim 团队在打造 Tidewave，一个让 Agent 能提出诸如“foo_bar 的文档在哪”或“BarBaz 在哪定义”这类问题的 CLI/工具，过程中发现，比起要求 Agent 提供源码中的精确定位引用，这种问答式的交互方式要顺手得多。
更根本的是，LSP 的信息呈现方式本来就是为人类消费而设计的——一次只给你一小块信息，你需要在文件之间反复跳转、一点点拼凑出全貌。
好消息是，很多语言服务器已经内置或能够访问 Agent 真正需要的信息：符号、引用、调用图、类型信息，有时还有数据流信息。Valim 的建议是：把这些信息暴露成一个可查询的“程序数据库”——不管是通过类似 Datalog 的查询语言，还是别的接口形式。
要求大多数人类开发者去写一条查询，只为了找出对某个函数的所有引用，是不现实的；但对 Agent 来说，写一条程序查询和调用一次 CLI 或 LSP 工具，付出的成本几乎一样。更重要的是，Agent 还能组合出那些原本不适合做成单个 IDE 功能的查询——比如“找出所有最终会调用这个函数的公开函数”，或者“找出程序里所有可能变成 nil 的取值路径”。这些数据库甚至可以被当作 linter，用来约束 Agent 做出不合规范的操作。
不过 Valim 也提醒了一句：局部性依然极其重要，尤其是在大型代码库里。像猴子补丁（monkey-patching）、隐式钩子、动态绑定这类“远程作用”（action at a distance）的写法，会让某一处代码影响整个系统的行为，而这种影响即便有程序数据库在手，也很难被完全追踪清楚。
运行时可观测性，取代调试器
另一个“为人类而生”的经典接口是调试器：打断点、单步执行、边走边看变量。但 Valim 认为，Agent 能做的事情不止于此——它们可以对代码插桩、采集执行轨迹、以远超人类的速度关联信息，我们应该给它们匹配这种能力的接口。
而且，如果我们默认 Agent 将来会承担大部分代码的编写工作，那么合理的推论是：它们也会在整个软件开发生命周期中承担更多职责，包括监控和诊断线上系统，而不只是依赖日志和仪表盘。
Valim 的建议是：把系统的运行时和状态以可编程查询、可探索的方式暴露出来。运行时可观测性可以给 Agent 提供一套统一的接口，让它们能在所有环境下实时诊断故障、定位可靠性问题、发现性能瓶颈。
有意思的是，他认为这恰恰是 Elixir/Erlang 一直以来的强项——得益于 Erlang 虚拟机（BEAM），检查进程、套接字、应用、监督树、ETS 表、消息队列等等，本来就是运行时内建的能力。剩下要补的缺口，只是如何把这些能力安全地暴露给 Agent——不管是通过一套工具集、一门查询语言，还是一个沙箱环境。
评论区炸锅：调试器真的会消失吗？
一条推文引出这么多硬核观点，评论区自然吵得热闹。几个方向的交锋很值得摘出来看看：
“调试器不会死”派
有开发者提出不同意见，认为让 Agent 能像人一样单步执行、回溯程序状态，反而能带来更快的反馈，未必会被淘汰。Valim 的回应是：双方其实并不矛盾——目标始终是给 Agent 提供更好的接口，去触达那些状态、去追踪执行路径，而不必强迫它们像人类一样一步步来。信息是一样的，接口不一样。
“新人怎么办”的忧虑
有人问，如果错误会被 Agent 悄悄修好，初学者可能连自己“卡在哪儿”都不会知道，这类基础问题可能在被社区看见之前就已经消失了——这对语言社区的知识传承是个隐忧。对此 Valim 坦言，自己目前没有答案。
“人类会不会最终连语言设计都插不上手”
有网友追问，如果我们不再读代码、不再争论哪种设计更好，我们又凭什么知道下一个“Elixir”该长什么样？Valim 的判断是，编程语言会继续演进，但驱动力会更多来自主导团队的愿景，而不是社区的需求和呼声——他强调这纯属个人猜测。
“Lisp 诅咒”式的隐忧
也有人联想到“Lisp 诅咒”——因为 Lisp 的可塑性太强，每个人都倾向于自己重新发明一套方案，反而阻碍了社区的凝聚。既然 Agent 让“自己动手实现”的成本大幅降低，这种诅咒会不会变成每个人都要面对的常态？
中文开发者的补充视角
评论区也有不少中文开发者在讨论工具生态的转向，核心意思是——Agent 已经把大部分代码写完之后，真正卡脖子的反而是编译器报错、linter、CI 这些“给人设计”的反馈环节；错误信息的结构化程度和可恢复性，可能比语法本身重要得多。也有开发者提到，只要把最小可复现和一次修复的 diff 结构化，Agent 的返工路径会完全不同。
整体来看，评论区没有形成统一结论，但有一句概括得挺到位：语言的人体工学重不重要，可能不再取决于“谁在敲代码”，而取决于——最终能存活下来的社区，教会 Agent 的到底是“人类的语法品味”，还是别的什么。
小结：这不是终点，是开放性问题
Valim 在文末特意加了一句免责声明：这篇文章在文风和语法上得到了 AI 的辅助润色。这本身也是个不错的注脚——当我们在讨论“AI 会如何改变写代码这件事”的时候，AI 已经在参与“讨论这件事”的过程了。
他给出的答案并不算激进：编程语言不会消失，编译器也不会被绕过，但围绕人类交互设计的那一整套工具——IDE、LSP、调试器——很可能需要被重新想象。程序数据库、运行时可观测性，只是这个方向上两个具体的落点，而不是终局。
至于社区会靠什么重新聚拢、下一门“Elixir”级别的语言会由谁的愿景驱动、初学者的成长路径要怎么保留——这些问题，Valim 自己也没有给出答案。或许这正是这篇文章最诚实的地方：它提出的问题，比它给出的答案更多。
发表于 2 小时前
|
查看: 9|
回复: 0
