Vercel 发布新语言 Zero:代码不是写给人看的,而是写给 AI 的

InfoQ 中文 2026-08-13T06:57:47.783508

Vercel Labs 发布了实验性系统编程语言 Zero,其核心思路是让编译器输出的主要阅读者从人类变成 AI 智能体。该语言以机器可读的诊断与修复计划、显式副作用管理和图优先存储为特色,目前仍处于实验阶段。对于关注 AI 编程的开发者来说,这是一个观察工具链设计风向的样本。

面向智能体的系统语言

2026 年 5 月 15 日,Vercel 的 Chris Tate 发布了基于“编译器输出主要面向 AI 智能体”这一前提设计的实验性系统编程语言 Zero。官方将其定位为一门“速度更快、体积更小,而且更便于智能体使用和修复”的系统语言。项目发布后进展迅速,目前已更新至 v0.3.4,并在 GitHub 上获得了超过 5200 个 Star。

Zero 使用 .0 作为文件扩展名,采用 Apache 2.0 许可证,可编译为 Linux、macOS 和 Windows 的原生二进制文件。早期报道多聚焦于其体积和构建速度:据称一个 Hello World 程序可以在一毫秒内构建完成,体积仅有 16.2 KiB。

工具链契约:让机器读懂错误

比体积和速度更值得关注的是 Zero 的工具链设计。单一 zero 二进制文件的每个子命令都支持统一的 --json 标志,并且使用一致的诊断模式。错误信息不再只是给人看的一段文字,而是携带稳定代码(如 NAM003)和带类型的修复元数据(如 declare-missing-symbol)。同时,zero fix --plan --json 会输出一份机器可读的修复计划,智能体可以接受、编辑或拒绝这份计划,而不是盲目套用自动修复。

这种设计意图很明显:让 AI 智能体像开发者一样理解代码库的状态,并在有依据的前提下参与修改,而不是只靠猜测生成补丁。

显式副作用:可验证的能力边界

Zero 在副作用处理上也很直接。任何与外部世界交互的函数,其签名中都必须显式接受一个 World 能力参数,并由编译器强制执行。这意味着,只看函数签名就能判断代码是否可以访问网络、文件系统或标准输出。对安全敏感场景来说,这种能力边界可以被静态检查和自动审计。

图优先创作:从文本到图的转变

Zero 的更大变化出现在 v0.3.0 中,该版本将图优先创作设为常规工作流。现在,二进制 zero.graph 存储是编译器的输入,.0 文件则沦为供人类阅读的投影。智能体通过 zero queryzero patch 操作底层图数据,补丁受图哈希保护,过期或无效的编辑会在写入存储之前失败。

对于早期用户,这一系列变化影响不小。v0.1.4 使用行语法,v0.2.0 将规范化的 .0 文本提升为原生源码载体,v0.3.0 则在编译器边界彻底拒绝把源码投影作为输入。现有文本优先的软件包需要通过 zero import 将源代码导入图中,再用 zero exportzero verify-projection 完成人工审查和 CI 漂移检查。官方将这一流程写进了入门指南和语言参考。v0.3.2 还让大型程序的 zero import 速度提升了约 12 倍,降低了这种转换的成本。

社区争议:AI 时代的语言应该为谁设计?

社区对 Zero 的讨论也反映出不小的分歧。

有开发者认为:“它唯一的新东西就是能力机制,而官方对此并没有解释。”另一位评论者则表示,结构化错误消息已经有了几十年历史,算不上新鲜事。但随即有人反驳:

作为开发者,我知道这类错误消息已经存在几十年了,我同意这对多数开发者来说不是大问题。但这不能成为不去开发一种 AI 智能体也能使用的东西的理由。这里关注的不是开发者,而是智能体。

还有人对采用率提出疑问:“智能体最擅长的语言,将会是那些在预训练数据中出现最多的语言。”kandros 则回应称,Svelte 等项目的重大 API 变更表明,训练数据的重要性可能低于预期。

与成熟语言相比,Zero 在二进制体积和显式分配方面更接近 Zig,而不是 Rust。它不具备 Rust 借用检查器的成熟度和生态,同时以类似 Go 的绿色线程和较大运行时为代价,换取了体积小巧、不依赖外部组件的构建产物。

Zero 由 Vercel Labs 开源,项目方明确警告:它仍处于实验阶段,预计会发生破坏性变更,只适合在隔离的工作区中运行,不应用于生产系统或敏感数据处理。

关键要点

查看原文