Vercel Zero：专为AI智能体设计的编程语言详解

当AI成为主要程序员，编程语言该如何进化

过去几十年，编程语言的设计几乎都围绕着一个核心假设：代码由人类编写、阅读和维护。变量命名、缩进规范、注释风格——这些约定的存在，本质上都是为了服务人类开发者的认知习惯。然而，随着AI编程智能体（AI agents）的能力快速提升，一个根本性的问题浮出水面：如果未来大部分代码都由AI生成和修改，我们是否还需要沿用为人类设计的编程范式？

Vercel给出的答案是否定的。Vercel在Product Hunt上发布了实验性编程语言 Zero，其标语直白而大胆——"为AI智能体打造的编程语言"。这不是又一个语法糖工具，而是从底层重新思考"代码是什么"的尝试。

Zero的核心理念：从编辑文本到操作语义图

抛弃源代码文本，直接操作程序图

Zero最具颠覆性的设计在于它彻底改变了AI与代码的交互方式。在传统模式下，AI智能体和人类一样，把代码当作纯文本来处理——生成字符串、插入行、替换片段。这种方式带来了诸多问题：AI可能引入语法错误、破坏代码结构，或者在大规模修改时产生难以追踪的副作用。

Zero的做法完全不同。根据官方描述，AI智能体不再"编辑源代码文本"，而是查询并修补一个语义化的程序图（semantic program graph），同时编译器会对每一次改动进行检查。换句话说，代码在Zero中被表示为结构化的图，而非扁平的字符序列。AI操作的是节点和关系，编译器则像守门员一样，确保每个patch都符合语言规则。

语义图（Semantic Graph）的概念源自编译器理论中的中间表示（Intermediate Representation, IR）。传统编译器在将源代码转化为机器码的过程中，会先将代码解析为抽象语法树（AST），再转化为控制流图（CFG）和数据流图等中间表示形式。AST保留了代码的层次结构但仍与文本形式紧密关联，而CFG和数据流图则捕捉了程序的执行逻辑和数据传递关系。Zero的创新在于将这种中间表示直接暴露为AI操作的主界面，跳过了文本源代码这一层。在图数据库（如Neo4j）和知识图谱领域，类似的结构化表示已被广泛用于表达实体间的语义关系——节点代表实体，边代表关系，每个元素都携带丰富的属性信息。将这一理念引入编程语言设计，意味着代码不再是线性排列的字符流，而是由类型节点、函数节点、变量节点、依赖边、调用边等组成的有向图，每个节点携带精确的语义信息（如类型签名、作用域、生命周期等）。这种表示天然具备结构完整性约束——比如一个函数调用节点必须连接到一个有效的函数定义节点，参数边的数量和类型必须匹配函数签名——使得非法的代码修改在图操作层面就会被拒绝，而无需等到编译或运行阶段才发现错误。

这种设计的价值显而易见：它把"生成合法代码"这件事从概率性的文本预测，变成了受编译器约束的确定性操作。AI犯低级语法错误的空间被大幅压缩。

人类只需描述结果，代码变成可读投影

Zero重新定义了人类在编程流程中的角色。官方描述称："人类只需提出期望的结果，然后在需要时审阅可读的代码投影（readable code projections）。"

这里的"代码投影"是一个关键概念。既然底层是语义图，那么面向人类展示的"源代码"就成了一种可选的、按需生成的视图。人类不再需要逐行编写代码，而是转向更高层次的意图表达——描述想要达成的目标，由AI在图上完成实现，再在需要时把图渲染成人类可读的形式。

代码投影（Code Projection）的概念与投射式编辑（Projectional Editing）密切相关，后者在计算机科学领域已有超过二十年的研究历史。投射式编辑的核心思想是：程序的"真实"表示不是文本，而是一个结构化的数据模型（如AST或语义图），而开发者看到和操作的"代码"只是这个模型的一种投影或视图。JetBrains的MPS（Meta Programming System）是目前最成熟的投射式编辑器之一，它允许用户通过可视化界面直接操作AST，而非编辑文本文件。MPS已被用于嵌入式系统开发（如mbeddr项目）和保险精算等领域特定语言的构建。此外，早期的Intentional Programming（由微软的Charles Simonyi在1990年代提出）也探索了类似的理念——Simonyi后来创立了Intentional Software公司继续这一方向的研究，该公司最终于2017年被微软收购。

然而，投射式编辑面临的一个核心难题是"双向同步"问题：当底层结构（图或AST）发生变化时，投影需要准确反映这些变化；反过来，如果用户修改了投影（比如人类开发者在审阅时直接改动了代码视图），这些修改需要被正确地反向映射回底层结构。这不仅是一个技术问题——需要建立投影文本与图节点之间的精确对应关系——还涉及语义一致性保证：某些投影层面看似合理的修改可能在图层面产生歧义或冲突。例如，在文本投影中重命名一个变量看起来简单，但在图层面可能涉及多个作用域中同名节点的消歧。Zero如何解决这一经典难题，将直接影响其在实际开发工作流中的实用性。

这实际上把编程从"实现"层面拉升到了"意图"和"审阅"层面，与当下"氛围编程"（vibe coding）的趋势不谋而合。氛围编程这一概念由AI领域知名人物Andrej Karpathy在2025年初提出，他在社交媒体上描述了自己使用AI编程工具的体验——不再逐行审查AI生成的代码，而是凭直觉和感觉来判断结果是否正确，像是在"根据氛围来编程"。这一概念迅速在开发者社区引发热议，因为它精准捕捉了AI辅助编程时代的一个关键趋势：开发者的角色正从"代码编写者"转向"意图表达者和结果审阅者"。在氛围编程的实践中，开发者更多地扮演"产品经理"或"架构师"的角色，描述需求和约束，而将具体实现委托给AI。Zero的设计哲学与此高度契合——人类描述期望结果，AI操作底层语义图，人类在需要时审阅代码投影。不同之处在于，氛围编程目前仍基于传统编程语言和文本代码（如使用Cursor、Claude等工具生成Python或TypeScript），而Zero试图从语言基础设施层面为这种新范式提供原生支持，让"意图到实现"的转化不再受限于为人类设计的文本代码格式。

为AI智能体优化的工程特性

Token效率与性能优势

Zero强调自己是"从零开始为智能体编程而构建"，并列出了几项针对性优化：Token效率、快速构建、低内存占用、零依赖。

其中"Token效率"尤为值得关注。当AI智能体需要读取和理解代码时，代码占用的token数量直接决定了推理成本和上下文窗口的消耗。在大语言模型（LLM）的实际应用中，Token是计费和上下文管理的基本单位——它大致对应于一个词或词的一部分（对于代码而言，一个token可能是一个关键字、一个变量名的一部分、或一个标点符号）。以GPT-4为例，其上下文窗口有128K token的上限，而每次API调用的费用与输入输出的token数量直接挂钩（GPT-4 Turbo的输入价格约为每百万token 10美元）。一个中等规模的代码仓库（数万行代码）轻松就能达到数十万token，这意味着AI智能体在理解和修改大型项目时，可能需要多次分段读取代码，导致上下文碎片化和信息丢失——AI无法同时"看到"相互依赖的代码片段，进而可能做出不一致的修改。

传统文本代码往往包含大量对机器理解而言冗余的信息——大括号、分号、缩进空格、换行符、重复的类型声明等。以一个简单的JavaScript函数为例，function add(a, b) { return a + b; } 中的 function 关键字、花括号和分号占据了近一半的token，但对语义理解贡献有限。基于语义图的表示可以更紧凑地编码同样的逻辑——只需要一个函数节点、两个参数节点、一个加法运算节点和一条返回边。这种表示消除了冗余的语法标记，只保留语义核心信息，可以显著减少token消耗（估计可减少30%-60%，具体取决于代码类型）。这不仅降低了API调用成本，还让AI在单次推理中能"看到"更多的程序逻辑，对于降低大模型调用成本、提升长程任务（如跨文件重构、架构级修改）的处理能力都有实际意义。

从更宏观的视角来看，Token效率的优化还与"推理计算"（inference compute）的经济学密切相关。随着AI智能体从简单的代码补全（如GitHub Copilot的单行建议）发展到多步骤的自主编程（如规划、实现、测试、调试的完整循环），单次任务消耗的token量可能从数千上升到数十万甚至数百万。McKinsey在2024年的报告中估计，大型企业的AI推理成本可能占其AI基础设施总支出的60%以上。在这一背景下，从编程语言层面减少token消耗，相当于从源头优化了AI编程的经济模型。

零依赖的工程哲学

"零依赖"（zero dependencies）的定位也颇具深意——这或许也是语言命名为"Zero"的原因之一。在现代软件开发中，依赖地狱（dependency hell）、供应链安全、版本冲突是长期困扰开发者的问题。

以JavaScript生态为例，一个典型的Node.js项目可能间接依赖数百甚至数千个npm包，形成深度嵌套的依赖树。npm注册表上有超过200万个包，平均每个项目的依赖链深度达到7-8层。2016年的"left-pad事件"中，一个仅11行代码的包被作者从npm删除，导致全球大量项目（包括Facebook和Airbnb的项目）构建失败，暴露了包管理系统的脆弱性。2021年的Log4Shell漏洞（CVE-2021-44228）则暴露了依赖链中的安全风险——一个底层Java日志库Apache Log4j的远程代码执行漏洞波及了数十万个项目，影响了从iCloud到Minecraft的众多服务，被美国网络安全和基础设施安全局（CISA）称为"最严重的漏洞之一"。2024年的xz Utils后门事件更进一步证明了供应链攻击的隐蔽性和危害性——一名攻击者通过多年的社区贡献获得了项目维护权限，然后在压缩库中植入后门代码，几乎影响了所有主要Linux发行版的SSH认证机制。

对AI智能体而言，复杂的依赖关系还带来额外挑战：它需要理解不同版本间的API差异（某个函数在v2.x中存在但在v3.x中被废弃）、处理依赖冲突（两个库依赖同一个包的不同版本）、判断安全风险（某个传递依赖是否包含已知漏洞），这些都大幅增加了自主编程的复杂度，并且很容易超出AI当前的可靠推理能力范围。研究表明，当前最先进的LLM在处理涉及多层依赖的任务时，准确率会显著下降——一项2024年的基准测试显示，AI在涉及第三方库API调用的代码生成任务中，错误率比纯标准库任务高出2-3倍。

Zero选择从设计层面规避这些负担，让智能体面对的是一个自洽、可控的环境。语言运行时自身不引入外部依赖，从根本上简化了AI智能体的操作环境——它不需要理解包管理器的配置文件、不需要解析依赖版本约束、不需要评估供应链安全风险。这使得AI可以将全部"认知资源"集中在业务逻辑的实现上。这一设计哲学与Go语言的理念有相似之处——Go在设计之初就强调标准库的全面性和最小外部依赖，其创建者Rob Pike和Ken Thompson认为过度依赖外部包会增加系统的不确定性。Zero将这一理念推向了极致。

行业意义与潜在争议

编程工具变革的方向性信号

无论Zero最终能否成为主流，它都释放了一个明确的行业信号：编程工具正在从"辅助人类写代码"向"服务AI写代码"转变。从GitHub Copilot到Cursor，再到各类自主编程智能体（如Devin、OpenHands等），AI已经深度参与软件开发。而Vercel作为前端和全栈开发领域的重要玩家，选择直接重构编程语言本身，代表了一种更激进的押注。

Vercel由Guillermo Rauch于2015年创立（最初名为ZEIT，2020年更名为Vercel），是Next.js框架的核心维护者和前端部署平台的领导者。Rauch此前还创建了Socket.io（最流行的WebSocket库之一）和Mongoose（MongoDB的Node.js驱动），在JavaScript社区有着深远影响力。公司在2024年的估值已超过33亿美元，累计融资超过5.6亿美元，服务着从个人开发者到《华盛顿邮报》、Nike、Notion等大型企业的广泛用户群。Vercel的核心业务是提供前端应用的部署和托管平台，其"边缘计算"基础设施使网站能在全球范围内实现毫秒级加载。

近年来Vercel在AI领域持续布局：推出了Vercel AI SDK帮助开发者快速构建AI应用（支持OpenAI、Anthropic等多种模型的统一接口）；通过v0产品让用户用自然语言生成前端界面代码，该产品上线后迅速获得数十万用户；收购了多个AI相关团队以增强技术储备。发布Zero可以视为Vercel战略的自然延伸——从部署平台到开发框架（Next.js），再到AI开发工具（AI SDK、v0），最终到编程语言本身，Vercel正在尝试重新定义整个AI时代的开发工具栈。这种纵向整合的野心使得Zero不仅仅是一个学术实验，而是有可能获得工业级资源支持的方向性探索。如果Zero的理念被验证可行，Vercel有能力将其整合进自己的整个产品生态，为数百万开发者提供AI原生的开发体验。

值得一提的是，Zero在Product Hunt发布首日便获得了80个投票、排名第6，被归入"编程语言"、"开发者工具"和"人工智能"三个分类，显示出社区对这一方向的关注度。

在更广泛的行业背景下，Zero的出现并非孤例。2024-2025年间，多个项目和研究开始探索"AI优先"的编程范式。例如，学术界有关于"LLM友好"代码表示的研究，探索如何重构代码格式以提升AI理解效率；工业界则有多家公司在构建专门为AI智能体设计的开发环境和工具链。Anthropic的Claude团队发布的"计算机使用"（Computer Use）能力、OpenAI的Codex以及Google的AlphaCode/AlphaCode 2等项目，都在从不同角度推动AI编程能力的边界。Zero的独特之处在于它选择从编程语言本身——而非工具或模型层面——来解决AI编程的根本性挑战。

尚需验证的关键问题

当然，作为一个"实验性"（experimental）项目，Zero面临的挑战不容忽视：

• 适用性边界：语义图的抽象是否真的比文本更适合所有编程场景？对于某些高度特化的领域（如嵌入式系统编程、操作系统内核开发或高频交易系统），开发者可能需要对底层细节（如内存布局、CPU指令选择、时序控制）保持精确控制，语义图的抽象层可能反而成为障碍。此外，对于探索性编程（如数据科学中的交互式分析）或创意编程（如生成艺术），文本代码的灵活性和即时反馈可能仍是不可替代的。历史上，高度抽象的编程范式（如4GL——第四代编程语言在1980-90年代曾被寄予厚望，但最终因灵活性不足而退居小众）的命运值得借鉴。

• 一致性保障：当AI操作图、人类审阅投影时，两者之间的一致性如何保证？如果人类修改了投影，图又该如何同步？这是投射式编辑领域数十年来持续面对的经典难题。更深层的问题是：当多个AI智能体并行操作同一个语义图时，如何处理并发冲突？传统版本控制系统（如Git）的merge机制基于文本行的差异比对，而图结构的合并需要全新的冲突检测和解决策略。学术界已有一些关于图合并（graph merging）的研究，如基于操作转换（Operational Transformation）或CRDT（Conflict-free Replicated Data Types）的方法，但将其应用于完整编程语言语义图的规模和复杂度，仍是一个开放问题。

• 生态建设：一个全新的语言生态需要工具链（调试器、性能分析器、测试框架）、社区（教程、最佳实践、问答资源）和大量实践的支撑，从实验室走向生产环境的道路漫长。编程语言历史上不乏设计优秀但因生态薄弱而最终被边缘化的案例——如Haskell长期被赞誉为设计精良但缺乏工业应用，D语言试图改进C++但未能建立足够的社区规模。即使是Rust这样被广泛认可的新语言，从2010年首次公开到被大规模采用也花了近十年时间。不过，Zero可能面临的生态挑战与传统语言有所不同：如果它主要由AI智能体使用而非人类直接编程，那么"社区"和"教程"的形态可能需要被重新定义——它可能更需要的是模型训练数据、智能体适配层和基准测试套件，而非Stack Overflow上的问答帖子。

• 掌控力问题：把人类从代码编写中"解放"出来，究竟是效率的飞跃，还是对开发者掌控力的削弱？当代码变成AI操作的图、人类只看投影时，调试、审计和责任归属都会变得更加复杂。如果一个AI操作的语义图中存在逻辑漏洞导致了安全事故，责任应归属于AI模型开发者、语言设计者还是审阅投影的人类开发者？这不仅是技术问题，还涉及法律和伦理层面的深层考量。欧盟的AI法案（EU AI Act，2024年正式通过）已开始对AI系统的责任归属做出规定，要求高风险AI应用必须具备可解释性和人类监督机制。如果Zero被用于关键系统的开发，其语义图的可审计性和投影的完整性将面临监管层面的审视。

结语

Zero或许不会立刻改变日常开发工作流，但它提出的问题足够深刻：如果代码的主要作者不再是人类，我们为人类设计的一切编程范式是否都值得重新审视？Vercel用一个实验性语言给出了自己的探索方向——把代码从文本解放为语义图，让AI高效操作，让人类专注于意图与审阅。

这是否是AI原生编程时代的正确打开方式，还需要时间和实践来检验。但可以确定的是，这类尝试正在把"AI写代码"从工具层面推向编程语言层面的根本变革。正如结构化查询语言（SQL）在1970年代将数据操作从过程式代码中解放出来，让用户只需声明"想要什么数据"而非"如何获取数据"，Zero或许代表着编程领域类似的范式跃迁——从"如何实现"到"实现什么"的根本转向，只不过这一次，承担实现工作的不再是数据库引擎，而是AI智能体。