Vercel 发布新语言 Zero：代码不是写给人看的，而是写给 AI 的
Vercel Labs 发布的实验性系统编程语言 Zero，最值得关注的并不是又多了一套语法，而是它重新设定了编程语言的主要使用者：人负责表达意图和审查结果，AI 智能体负责理解、修改和修复程序。
这也是“代码不是写给人看的，而是写给 AI 的”真正激进之处。它改变的不是代码风格，而是编程工具链的基本契约。
把编译器变成智能体接口
Zero 的每个子命令都支持统一的 JSON 输出，诊断信息带有稳定的错误代码和类型化的修复元数据。智能体得到的不再是一段需要猜测的自然语言报错，而是可以直接解析和处理的结构化信息。
它提供的修复机制也不是自动替用户改代码，而是先生成机器可读的修复计划，允许智能体接受、编辑或拒绝。
我认为，这比“AI 能不能写出某种新语言”更重要。AI 编程真正的瓶颈，往往不是生成代码，而是工具缺少稳定、明确、可验证的反馈接口。
副作用必须写在明处
Zero 要求所有与外部世界交互的函数接受一个 World 能力参数，并由编译器强制执行。
这样一来，只看函数签名，就能判断代码是否可能访问网络、文件系统或标准输出。对于人类，这是更清楚的权限边界；对于智能体，这更是一种可以机械检查的安全约束。
当越来越多代码由智能体修改时，隐含行为会成为风险来源。把能力和副作用显式化，不只是语言设计选择，也是智能体时代的安全设计。
文本不再是唯一源码
Zero 在 v0.3.0 中走得更远：编译器真正读取的是二进制图存储 zero.graph，.0 文本只是供人阅读的投影。智能体通过查询和补丁命令操作程序，而不是直接改写文本文件。
补丁受到图哈希保护。基于旧版本生成的修改，或者不符合当前状态的编辑，会在写入前失败。
这相当于把程序从“一组文本文件”变成“一个具有结构和版本状态的对象”。文本仍然重要，但不再天然拥有最高地位。
这也是 Zero 最有争议、同时最有想象力的部分。过去的软件工具普遍把文本视为唯一事实来源，图结构只是编译器内部产物。Zero 反过来把图放在中心，把文本变成人类审查界面。
激进设计必然带来迁移成本
Zero 的早期版本变化很快：v0.1.4 使用行语法，v0.2.0 把规范化文本提升为原生源码载体，v0.3.0 又拒绝直接以文本投影作为编译输入。
已有项目必须先把文本导入图存储，再通过导出和投影校验支持人工审查及 CI 漂移检查。v0.3.2 把大型程序的导入速度提高了约 12 倍，但这只能降低转换成本，不能消除认知和工具迁移成本。
这说明 Zero 目前更像一场快速推进的语言实验，而不是已经稳定的生产方案。项目自身也明确警告，破坏性变更仍会出现，应该在隔离工作区运行，不应用于生产系统或敏感数据。
新语言仍要面对旧问题
社区对 Zero 的质疑并不轻。有观点认为，能力机制和结构化错误都不是新发明；也有人指出，智能体更擅长训练数据中大量出现的成熟语言，新语言天然缺少语料和生态。
这些批评都有道理，但还没有击中 Zero 最值得观察的地方。它的创新未必来自单个语言特性，而在于把已有机制统一组织成一套面向智能体的工作流。
结构化错误过去主要是给工具和开发者使用的，现在则可能成为智能体稳定工作的基础设施。某项技术是否新颖，和它是否在新的生产关系中产生价值，是两件不同的事。
关键不是取代哪门语言
从系统语言特征看，Zero 在小型二进制文件和显式分配方面更接近 Zig。它没有 Rust 借用检查器的成熟度和生态，也不同于用较大运行时换取绿色线程体验的 Go。
但现在就讨论它能否取代 Rust、Zig 或 Go，我认为为时过早。Zero 当前最大的价值，是提出了一个更具体的问题：如果未来软件主要由智能体持续修改，编程语言、编译器和源码存储应该怎样重新设计？
答案可能不是 Zero，也未必是图存储。但稳定的机器接口、显式的能力边界、可审查的修改计划和带状态保护的补丁，很可能会进入下一代开发工具。
Zero 是否成功并不确定。它已经揭示的一点却很清楚：AI 编程的下一阶段，不只是让模型适应人类留下的工具，而是开始让工具适应智能体。