Vercel Zero 直接對 AI 說話

Vercel Labs 的 Zero compiler 會輸出 JSON 診斷與修復提示，讓 AI coding agents 直接修 code，不用先翻成人話。

Zero 是 Vercel Labs 推出的系統語言。它在 2026 年 5 月 15 日發布。這東西很直白。它不是先把錯誤寫給人看，再等 AI 猜意思。它直接把錯誤包成 JSON，讓 agent 讀得懂。

講白了，這是把 compiler 的溝通對象換掉。以前是 developer。現在先看 agent。這個方向很有意思。因為像 Claude Code、Cursor、GitHub Copilot 這類工具，已經不是只會補字。它們會跑流程、改檔案、重試、再修一次。

Zero 到底在解什麼問題

傳統 compiler error 很會罵人，但不太會幫忙。它會丟一串人類看得懂、AI 也可能看得懂的字。問題是，這些訊息常常不夠穩定。格式會變。語意會飄。agent 看到後，還要自己猜下一步。

Zero 想處理的，就是這個翻譯成本。它把診斷結果結構化。重點不是寫得漂亮。重點是能讓程式代理直接抓欄位。哪裡壞了。怎麼修。修完要不要再驗一次。這些都能變成欄位，而不是一段散文。

我覺得這很像把 compiler 變成 API。以前你拿到的是一封信。現在你拿到的是資料。對 AI 來說，資料比文案有用太多。因為 agent 不需要感動。它需要可預測的輸入和輸出。

• 錯誤訊息改成 JSON。
• 修復提示可以直接給 agent。
• 減少人類手動轉述。
• 讓重試流程更穩定。

為什麼這對 AI coding 很重要

現在的 AI coding 工具，早就不是單次補全而已。它們會讀 repo、跑測試、看 log、改檔案，再把結果丟回去。問題是，只要其中一個環節語意不清，整條流程就會歪掉。這時候，compiler 的輸出格式就很要命。

如果錯誤訊息是自由文字，agent 就得自己做 NLP。它要先猜是哪個檔案。再猜是哪個型別錯。接著還要猜修法。這種猜法，通常比你想像的更浪費 Token。也更容易修錯方向。

Zero 的思路比較狠。它不先服務人類閱讀習慣。它先服務機器處理習慣。這會讓開發流程更像串接服務。不是每一步都靠聊天。是每一步都有明確結構。這對大型團隊很實際，因為錯誤處理可以被自動化。

「The future is already here — it’s just not evenly distributed.」— William Gibson

這句話放在這裡很合適。因為 agentic coding 不是概念。它已經在不少團隊裡跑了。差別只在於，有些工具還在用人類語言溝通。有些工具開始用機器語言溝通。Zero 就是後者。

如果你在做內部開發平台，這種設計會很有吸引力。因為它能把修錯流程接進 CI、IDE、bot，甚至自動化客服腳本。你不一定要喜歡它的語言設計。你只要看懂它在解哪個痛點就夠了。

• 降低 agent 解析錯誤的機率。
• 減少人工介入次數。
• 讓 CI 回饋更標準化。
• 讓多輪修復更容易追蹤。

跟 Claude Code、Cursor、Copilot 比什麼

Claude Code、Cursor、GitHub Copilot 都在做 agent 化工作流。差別在於，它們多半是建立在既有語言和既有 compiler 上。Zero 則是往下挖一層，直接改 compiler 的輸出模型。

這差很多。因為前者是在應用層補強。後者是在基礎層改資料格式。應用層的好處是快。基礎層的好處是穩。你如果做過平台整合，就知道這兩種路線的成本差在哪裡。

另一個比較點，是可移植性。若一個工具只懂自然語言錯誤，它就得靠 prompt engineering 補洞。若 compiler 直接吐結構化診斷，agent 就能更穩地接招。這對多語言、多 repo、多環境的團隊，會省很多麻煩。

• Zero：從 compiler 層改格式。
• Claude Code：偏工作流執行。
• Cursor：偏 IDE 內協作。
• Copilot：偏補全與代理整合。

講白了，Zero 不一定是要打贏這些工具。它比較像在問一個更底層的問題：如果 AI 是主要使用者，compiler 為什麼還要先講人話？這問題很刺，但也很合理。

這種設計會怎麼影響開發團隊

第一個影響，是 debug 方式會變。以前你看 console log。現在你可能先看 JSON diagnostics。這代表團隊要更重視 schema、欄位命名、錯誤代碼一致性。說真的，這很工程。也很無聊。但它有效。

第二個影響，是工具鏈會開始分層。上層給人看。下層給 agent 看。這種雙軌設計，可能會變成新常態。因為人類還是要可讀性。AI 則要可解析性。兩邊需求不一樣，硬塞在同一段字裡，通常只會兩邊都不好用。

第三個影響，是測試會更早自動化。當錯誤和修復建議都結構化後，agent 可以直接接管一部分修正流程。這不代表人會消失。只是人會把時間花在更難的 bug，而不是一直重複改 typo、補型別、對欄位。

• 團隊要定義 error schema。
• CI 會更依賴結構化回饋。
• IDE 可能要支援雙格式訊息。
• Agent 修復流程會更像 pipeline。

背景脈絡：這不是單一產品的事

這波變化，其實跟整個 AI 開發工具市場有關。過去一年，大家都在比誰的模型更會寫 code。現在開始比誰的工具鏈更會接 code。模型只是腦。工具鏈才是手腳。Zero 這種設計，就是在補手腳那一段。

你也可以把它看成一種語言設計上的反撲。以前語言設計重視人類可讀。現在多了一個 AI 可操作。這會逼 compiler、runtime、IDE、測試框架一起改。不是每個專案都要跟進，但大型平台很可能會先試。

我自己的判斷很簡單。未來 12 到 18 個月，會有更多工具把診斷做成結構化資料。不是因為潮。是因為 agent 太常需要這種資料了。當你的使用者是 LLM，輸出格式自然就要跟著變。

結尾：開發者現在該看什麼

如果你在做內部工具、語言服務、或 AI coding 平台，先看兩件事。第一，錯誤訊息能不能結構化。第二，修復建議能不能被 agent 直接吃進去。這兩件事做得好，後面很多自動化才接得起來。

我會建議團隊先從最常見的 10 種錯誤開始改。像型別錯、匯入錯、測試失敗、schema 不合。先把這些變成 JSON 或類似格式。你很快就會知道，AI 真的能少掉多少翻譯成本。說真的，這比再多一個花俏 demo 實在多了。