Vercel 发布新语言 Zero：代码不是写给人看的，而是写给 AI 的
Vercel Labs 发布了实验性系统编程语言 Zero，其设计前提很激进：编译器输出的主要阅读者不再是人类，而是 AI 智能体。Vercel 的 Chris Tate 于 2026 年 5 月 15 日发布了这门语言，定位为"速度更快、体积更小，而且更便于智能体使用和修复"的系统语言。截至文章发布，项目已推进到 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返回机器可读的修复计划，智能体可以接受、编辑或拒绝，而非盲目应用
对前端工程师来说，这类似于把 ESLint 的 --fix 和 TypeScript 的 tsc 诊断输出标准化到一个统一的 JSON schema 上——但更进一步，修复本身是一个可审查的 plan，不是黑盒自动 apply。
显式副作用：World 能力参数
任何与外部世界交互的函数都必须接受一个 World 能力参数，由编译器强制执行。只看函数签名就能判断代码是否可以访问网络、文件系统或标准输出。
这让人联想到 React 的纯函数理念（useEffect 的依赖声明、memo 的纯渲染），但 Zero 把它做到了语言层面——副作用不是约定，是类型系统的一部分。
v0.3.0 的范式转变：图优先
v0.3.0 将图优先创作设为常规工作流，这是一个根本性转向：
zero.graph二进制存储是编译器的真正输入.0文件降格为供人类阅读的投影- 智能体通过
zero query和zero patch直接操作图 - 补丁受图哈希保护，过期或无效的编辑在写入前就会失败
版本演进路径：v0.1.4 行语法 → v0.2.0 .0 文本为原生源码载体 → v0.3.0 彻底拒绝源码投影输入。现有文本优先包需用 zero import 导入图，zero export 和 zero verify-projection 做人工审查及 CI 漂移检查。v0.3.2 将 zero import 速度提升约 12 倍。
社区反馈：两极分化
Hacker News 上争议激烈：
- killerstorm：没劲，唯一的新东西就是能力机制，而他们对此并没有解释
- 另一位评论者认为结构化错误"已经存在几十年了"，但回复反驳：重点在于智能体而不是开发者
- 关于采用前景，有人指出"智能体最擅长的语言，将会是那些在预训练数据中出现最多的语言"；kandros 则以 Svelte 等项目的重大 API 变更为例，认为训练数据的重要性可能低于预期
语言定位
Zero 在二进制体积和显式分配上更接近 Zig 而非 Rust——缺乏 Rust 借用检查器的成熟度和生态，并以 Go 的绿色线程和较大运行时为代价，换取体积小巧且不依赖外部组件的构建产物。
项目仍处于实验阶段，官方警告预计会出现破坏性变更，应在隔离工作区运行，不可用于生产或处理敏感数据。
My Take
Zero 的核心洞察是对的：当前所有编程语言的工具链都是为人眼设计的，但越来越多的代码消费方是 AI 智能体。把诊断、修复计划、副作用声明都标准化为机器可读的 JSON 契约，这个方向有实际价值——就像 REST API 之于浏览器，Zero 试图成为"之于智能体的原生接口"。
但 v0.3.0 的图优先转向暴露了一个根本矛盾：如果 .0 文件只是投影，人类开发者被降格为"审查者"而非"作者"，那开发者体验（DX）本质上被牺牲了。作为一个深度 React 用户，我见过太多"理论上更优"的范式（比如当年 ReasonML、Elm）因为生态和 DX 问题没能起飞。Zero 当前的 5200 Star 更多是对 Vercel 品牌和 AI 叙事的溢价，而非语言本身成熟度的证明。
更关键的问题在于：LLM 真的需要一门"为它设计"的语言吗？智能体最擅长的恰恰是处理训练数据中高频出现的语言（Python、JS/TS）。Zero 试图逆这个趋势而行——它赌的是"未来智能体能胜任任意语言"，而不是"顺应智能体当前的能力分布"。这个赌注很大，也可能很大胆。但在它证明自己能跑通一个真实项目（而非 Hello World）之前，我会保持关注但不会投入。