人工智能时代编程语言的演变

# AI时代编程语言的演进 来源：https://dashbit.co/blog/evolving-ai-era - José Valim - 2026年9月24日 - AI (https://dashbit.co/blog/tags/AI), 运行时 (https://dashbit.co/blog/tags/runtime), 保证 (https://dashbit.co/blog/tags/guarantees) 本文是关于编程语言在AI时代可能如何演进的短篇随笔合集。 全文分为两部分：反思与智能体工具化。第一部分探讨当人类不再编写大部分代码时，编程语言、其生态系统及社区将面临的问题。第二部分更具体且更具观点性：当编码智能体成为我们语言的用户后，我们的工具应如何改进。 我对这些主题的观点可能会变化，但这近期是我思考的合理总结。 ## 反思 本节探讨当智能体编写我们大部分代码时，编程语言及其社区可能如何变化。虽然这仍是个有争议的话题，但对许多开发者和团队而言已成现实。因此，无论我们认为这种转变会变得多么普遍，我们都有责任去探索它可能如何影响我们。 让我们开始吧。 ### 关于社区 大多数编程语言的核心，都有一个围绕共同理念聚集的社区。Python强调用明显的方式做事情，Ruby长期培养对程序员幸福感的重视，Lisp社区则传统上推崇重塑语言本身的能力。 但当我们停止编写大部分代码时会发生什么？这将如何影响我们的归属感？我们是否应该努力保持这种归属感？还是社区应该去寻找下一个能将大家凝聚在一起的事物？ 同样，我们围绕语言构建生态系统以解决难题并创建共享抽象：Web框架、张量库、数据处理管道、GUI工具包等。编码智能体可能从两个相反的方向影响这些生态系统。 首先，生态系统之间的差距可能会缩小。构建所有这些框架需要大量的时间和精力，而智能体有可能削减其中大部分。当问题涉及实现已知算法、翻译论文中的想法或在语言间移植现有实现时尤其如此，这能让较小的社区更快地追赶较大的社区。 另一方面，如果实现某样东西变得足够廉价，人们是否还会联合起来为同一个解决方案协作？如果我需要一个库来解决问题X，我可能只会让智能体构建我确切需要的东西。 这产生了一种有趣的张力。编码智能体可以大幅降低构建生态系统的成本，但同时又削弱了最初导致生态系统形成的力量之一。 ### 关于人机工程学 编程语言演进的一个重要方面，是通过添加语法便利性和长期改进人机工程学。然而，如果人类不再编写大部分代码，这些变化还重要吗？ 例如，在过去十年里，我们看到许多语言添加了可选链运算符，这对人类来说比显式的空值检查序列要友好得多。另一方面，智能体不介意样板代码，这种差异的意义要小得多。 有人认为这些便利性也让编码智能体更节省token。但我认为，token效率是我们优化编程语言时应考虑的最不重要的特性之一，尤其是随着模型变得更便宜、更高效，以及上下文窗口不断扩大。 我甚至认为，任何声称“为编码智能体打造”且最终专注于语法的编程语言，实际上都是在围绕当前的局限性构建。我曾使用智能体编写HTML、CSS、JavaScript、Elixir、Rust和Lean，对我来说感觉差异巨大的语法差异，对它们来说似乎远不那么重要。从它们的角度看，这都是输入token和输出token。 ### 关于编译器 每当我们在这种背景下讨论编程语言时，一个常见的后续问题是：我们首先还需要编程语言吗？也许编码智能体会取代编译器，直接编写汇编代码？ 我不接受这种说法，原因如下： 首先，如果你在构建桌面应用，你可能不想为每种支持的架构维护不同的汇编实现。你仍然需要某种与架构无关的表示形式，以及能够将其转换为目标机器语言的东西。换句话说，你至少重新发明了部分编译器和一种更高级的语言，即使这种语言从来不是为人类编写而设计的。 其次，我们尚未找到一种能在所有方面都表现出色的单一语言或计算模型。我们有系统编程语言、定理证明器、用于并发、分布式和弹性软件的语言（例如 Erlang/Elixir）、查询语言、硬件描述语言等等。它们编码了不同的语义、不同的抽象级别，以及不同的保证。期望一种单一的低级语言统一所有这些是不合理的。 如果编程语言不会消失，但我们停止为编写它们的人类优化编程语言，那么我们应该为谁优化？ ## 智能体工具化 过去我说过，为人类创建出色的工具也会为智能体带来出色的工具。我相信这将永远是正确的。这引导我们构建了自动化现有工作的解决方案：智能体编写与我们相同的测试，使用与我们相同的程序元数据，并读取与我们相同的日志。 但如果我们开始使用智能体来执行我们自己通常不会做的事情呢？也许因为它们太繁琐、学习曲线陡峭，或者需要处理的信息量对人类来说不切实际？这就是本节探讨的内容。 本节中的工具并不要求智能体编写大部分代码。即使你只使用智能体处理20%的代码，它们也能从这里概述的工具中受益。 ### 更强保证优于用户约束 编程语言需要平衡几个相互竞争的目标，包括表达力、保证和人机工程学。我们希望表达我们关心的程序，我们希望语言为这些程序建立有用的属性，我们希望它对开发者易于使用。如果智能体编写了大部分代码，我们可以重新审视这些权衡。 其中一个例子是函数签名的推断。这对人类很有价值，因为显式编写编译器可以推断的信息是乏味的。编码智能体不在乎乏味。如果非要说的话，让类型和意图显式化，能为编译器、其他智能体和我们自己提供更多可用信息。更重要的是，类型可以被完全推断的语言，通常是那些类型可以被检查的语言的子集，因此为推断而优化最终可能会限制表达力和类型系统能提供的保证。当我们已经看到智能体能够在更复杂的系统中编写证明时，为什么还要对它们施加这些限制呢？ 保证也不必总是静态建立的。内存安全可以通过静态方式或运行时强制执行，例如通过垃圾回收。模型检查可以通过使用模型生成的执行跟踪来验证实际系统，从而弥合模型与实现之间的差距。例如：Erlang/Elixir 依赖隔离进程和消息传递来约束并发程序的构建方式，牺牲一些表达力以获得围绕隔离和容错的更强属性。并非每个并发算法都能高效地映射到这个模型，但能做到的程序会从中继承有用的保证。 总的来说，现在是为我们软件提供更强保证的最好时机。我们无法对所有软件进行形式化验证，但我们可以结合不同的方法来增强它： - **构造即正确**：语言使无效状态或程序难以或不可能表达。 - **静态建立**：类型、证明和静态分析在执行前建立属性。 - **运行时强制**：内存管理、隔离、能力边界及其他运行时强制的属性。 - **经验验证**：通过测试、基于属性的测试和模糊测试进行程序验证。 我相信，语言组合这些技术并推动表达力与保证边界的方式，将在它们如何差异化和被采用方面发挥越来越重要的作用。特别是如果你相信智能体会让生态系统更容易相互追赶（正如在“关于社区”中所讨论的）。同样地，框架也必须在其自身的抽象层面上采用一些这样的实践。 ### 程序数据库优于LSP IDE的消亡在过去两年已被多次宣告。一旦讣告最终发布，我不认为LSP能幸存下来。 语言服务器协议主要是为IDE设计的，其许多操作偏向于文档和位置：文件、行和列，而智能体并不精确跟踪这些。根据我们构建Tidewave (https://tidewave.ai/) 的经验，一个智能体可以询问“`foo_bar`的文档在哪里？”或“`BarBaz`在哪里定义？”的CLI或工具，比要求它们提供源代码中这些符号出现的精确引用要合适得多。 此外，LSP旨在呈现供人类消费的信息，而非探索性信息。你通过在源文件之间跳转来一次收集一条信息。 好消息是，许多语言服务器已经构建或可以访问编码智能体所需的大部分信息：符号、引用、调用图、类型信息，有时还包括数据流信息。我的建议是将这些信息作为程序数据库暴露出来，并配备查询语言，无论是SQLite、Datalog还是自定义DSL。 要求大多数开发者编写查询只是找到函数的所有引用是不合理的。另一方面，编码智能体很乐意这样做：编写程序查询的工作量与调用CLI或LSP工具相同。更重要的是，它们可以组合查询，而这些查询作为单独的IDE功能是不切实际的：找到所有最终调用此函数的公共函数，或程序中给定值可能变成`nil`的所有路径。这些数据库也可以用作代码检查工具，防止智能体采用不良实践。 这意味着局部性仍然极其重要，尤其是在大型代码库中。猴子补丁、隐式钩子、动态重绑定等远端操作形式意味着在一个地方编写的代码可能影响整个系统的行为，即使在程序数据库可用的情况下也难以追踪。 ### 运行时可观测性优于调试器 调试器是另一个主要为人类设计的接口。我们设置断点，一次一行地单步执行，并在过程中检查变量。然而，智能体可以比我们更快地检测代码、收集跟踪信息并关联信息。我们应该为它们提供能利用这一优势的接口。 此外，如果假设编码智能体将编写我们的大部分代码，那么期望它们也承担软件开发生命周期中更多的责任也是合理的，包括监控和诊断生产系统运行时的状态，而不是依赖日志和仪表板。 我们应该以智能体能够以编程方式查询和探索的方式，暴露我们系统中的运行时和状态。运行时可观测性可以为智能体提供一个通用接口，用于实时诊断故障、识别可靠性问题，并在所有环境中检测瓶颈。 幸运的是，这是一个Elixir一直擅长的领域，这要归功于Erlang虚拟机。检查进程、套接字、应用程序、监督程序、ETS表、消息队等等多是运行时的内置能力。剩下的差距是如何安全地将这些能力暴露给智能体，无论是通过一组工具、一种查询语言，还是一个沙箱。 --- 致谢：我要感谢Quinn Wilton、Chris McCord、Ryan Lopopolo、Chad Fowler、Rob Knight、Danila Poyarkov以及在ElixirConf遇到的许多人，他们的讨论和分享的作品帮助塑造了本文中的许多想法。所有观点均为个人看法。 免责声明：AI用于处理文章中的风格和语法问题。