AI浪潮正以前所未有的速度重塑软件开发范式。编程语言不再仅仅是人类编写指令的媒介,更正逐渐成为智能体协作的接口。José Valim近期发布的文章《Evolving programming languages in the AI era》引发了业界对语言演进方向的深度思考。文章将探讨分为「反思」与「智能体工具」两大部分,首先审视当人类不再撰写大部分代码时,语言社区、生态系统及设计理念将如何变迁;随后聚焦于工具层面,探讨如何重构语言特性以适应智能体的使用习惯。本文将基于这些观点,从社区归属感、语法人体工学、编译器必要性、类型系统保证、程序数据库与LSP的替代、运行时观测性等多个维度,展开对编程语言在AI时代演进的深入剖析。社区是每门编程语言的灵魂。
Python以「显而易见的做法」凝聚了一批追求简洁的开发者,Ruby则长期培养 programmer happiness 的理念,Lisp 社区更以语言自身的可重塑性为傲。然而,当智能体接管了大部分代码撰写工作,社区的凝聚机制将面临前所未有的考验。如果不再有大量人类直接贡献代码,原本围绕语言特性、库选型、最佳实践形成的共享 sensibility 是否还能维持?社区是否需要寻找新的粘合剂,例如围绕特定的领域抽象、模型或是工具链展开?另一方面,生态系统的构建本身也在被重新定义。过去构建 web 框架、张量库、数据处理管道需要社区成员投入大量时间与协作,而智能体在实现已知算法、翻译纸上想法或跨语言移植现有实现方面的能力,可能让小社区更快追上大社区。但也随之而来一个悖论:若实现某功能的成本足够低,开发者是否仍会选择贡献共享库,还是直接让智能体按需生成专属解决方案?这种张力在于,智能体可能既降低了生态构建的成本,又削弱了形成生态的协作动力。语言的未来社区或许不再仅围绕语法糖或库的使用,而更倾向于围绕某种共同的抽象模型、验证框架或是运行时特性展开。
语法与人体工学的演进历来是语言迭代的重要组成部分。 optional chaining 操作符、空安全语法等特性在过去 decade 中层出不穷,它们的确让人类编写代码时的体验更为顺畅。然而,如果人类不再是主要的代码撰写者,这些语法糖的重要性便大打折扣。智能体并不在意样板代码的繁琐,对于它们而言,无非是 tokens 的输入与输出。有观点认为,这些affordance 也能提升 token 效率,但随着模型成本下降、上下文窗口扩大,token 效率已不再是语言设计的核心优化点。更有甚者,任何声称「为智能体设计」却最终只关注语法的新语言,本质上是围绕当前模型的局限性构建。
作者在尝试让智能体编写 HTML、CSS、JavaScript、Elixir、Rust 甚至 Lean 时观察到,那些对人类而言巨大的语法差异,对智能体来说微乎其微。这提醒语言设计者,未来的语言演进不应仅为了适应智能体的当前处理能力,而应展望更广的可能性。编译器的角色亦在受到挑战。有人会问:在智能体时代,我们是否仍然需要编程语言,甚至直接编译为汇编?作者并不以为然。对于桌面应用而言,支持多种架构的汇编实现维护成本极高,仍然需要一种架构无关的中间表示,以及能够将其降低到目标机器的能力。换言之,即便未设计给人类书写,本质上也重新造轮了编译器与高级语言的部分功能。
此外,尚未找到能在一切领域表现卓越的单一语言或计算模型。系统编程语言、定理求证器、并发分布式软件语言(如 Erlang/Elixir)、查询语言、硬件描述语言等,各自编码不同的语义、抽象层级与保证。期望单一低级语言统一所有这些,在实际层面是不合理的。如果编程语言注定不会消失,但人类不再是主要代码编写者,语言应被优化的目标又该何在?这或许是表达能力、保证强弱、以及对智能体友好程度之间新平衡的重新权衡。在类型系统与保证方面,语言需要在表达力、保证与人体工学之间寻找新的平衡点。当智能体撰写大部分代码时,函数签名的推断就不再仅仅是为了省去人类显式声明的繁琐。
反而,让类型与意图显式化,能为编译器、后续的智能体以及人类自身提供更多可供利用的信息。那些类型可全推断的语言,其表达能力往往也因此被限制,类型系统能提供的保证也随之收窄。既然智能体已经展现出在更复杂系统中编写证明的能力,为何还要在推断与检查之间设限?内存安全或许可以静态确认,也可以由运行时通过垃圾回收 enforcement;模型检查可以通过生成的执行轨迹去验证实际系统。以 Erlang/Elixir 为例,它们通过孤立的进程与消息传递来约束并发程序的结构,虽然并非所有并发算法都能高效映射到这一模型,但做到的程序因此获得了更强的隔离与容错保证。不应只在静态类型与运行时管理之间二元对立,正确的构造、静态建立的保证、运行时强制的属性、以及经验性的验证(测试、基于属性的测试、模糊测试)可以相互补充。不同语言组合这些技术、推动表达力与保证边界的方式,将在AI时代决定语言的差异化采用度。
尤其在生态快速跟上的趋势下,语言在保证层面的差异将成为关键的竞争优势。IDE 与语言服务协议(LSP)的命运也在被重新审视。LSP 原本是为 IDE 设计的,其大量操作偏向于文档与位置 - - 文件、行、列 - - 这些对于智能体并不精确追踪。在实际体验中,智能体更倾向于通过 CLI 或工具提问:「foo_bar 的文档在哪里?」或 BarBaz 在哪里定义?这比要求其提供精确的源码引用更为适合。而且,LSP 最初设计之初是为了呈现信息给人类消费,而非支持探索。你需要一个个在源文件间穿梭才能汇聚信息。
好消息是,许多语言服务器已构建或可访问大量智能体所需的信息:符号、引用、调用图、类型信息,有时甚至包含数据流信息。建议将这些信息暴露为程序数据库,并配备查询语言 - - 无论是 SQLite、Datalog 还是自定义 DSL。对人类来说,编写查询找出函数的所有引用可能有些大材小用;但对智能体而言,编写程序查询的工作量与调用 CLI 或 LSP 工具无异。更重要的是,它们可以编写一些作为单一 IDE 功能难以暴露的复合查询:查找所有最终调用某函数的公开函数,或是查找程序中某值可能变为 nil 的所有路径。这些数据库也可作为lint 工具, guard 智能体免受不良实践的影响。这意味着,在大型代码库中,局部性依然极其重要。
monkey-patching、隐式钩子、动态 rebinding 等距离操作,让代码在一处影响整个系统的行为,即便有程序数据库可查,也难以追踪。语言设计若希望兼容智能体,需在设计之初就考量这种可追踪性。运行时观测性正逐渐取代调试器,成为智能体的重要接口。调试器设计初衷是给人类用的:设置断点、单行步进、检查变量。然而智能体可以更快地对代码进行仪器化、收集追踪并关联信息。若假设智能体将编写大部分代码,也应期待它们在软件开发生命周期的更多环节承担责任,包括运行中的系统监控与诊断,而非仅依赖日志与仪表盘。
我们应以编程的方式暴露系统的运行时与状态,让智能体能查询与探索。运行时观测性可以为智能体提供统一的接口,用于诊断故障、识别可靠性问题、实时检测瓶颈 across 所有环境。幸运的是,这是 Elixir 一直擅长的领域,归功于 Erlang 虚拟机。 inspect 进程、socket、应用、supervisor、ETS 表、消息队列等能力是运行时内置的。剩余的差距在于安全地将这些能力暴露给智能体,无论是通过工具集合、查询语言还是沙箱。这也意味着,语言的运行时特性不再仅仅是人类调试的工具,更成为智能体感知与干预系统状态的基础设施。
综上所述,AI 时代的编程语言演进,不再仅仅是人类视角的迭代。社区的归属感将从单纯的语法共鸣转向更抽象的模型共识;语法人体工学的优化需权衡智能体的 token 效用与语言的长远可塑性;编译器的必要性因架构抽象需求而非消失;类型系统的设计应在推断与检查之间寻找表达力与保证的最佳平衡;LSP 向程序数据库的转型,将更好地支持跨文件、跨路径的智能体查询;而运行时观测性则成为智能体诊断与优化的核心基础。各种语言如何组合正确性构建、静态保证、运行时 enforcement 与经验性验证,以及如何在这些维度上推动边界,将决定它们在 AI 流中的生存与发展之道。编程语言的未来,或许正站在人类创造力与智能体计算力交汇的十字路口,共同书写下一代软件构建的范式。 。
