每日突破性工具推薦｜json-render

工具定位

json-render 是 Vercel Labs 推出的 Generative UI 框架。它的目標不是讓模型直接產生任意 React／HTML 程式碼，而是讓開發者先定義可使用的 Catalog（元件、Actions、Functions 與型別約束），再讓 AI 產生符合這套契約的 JSON UI Spec，由應用程式自己的 Registry 對應到真正的原生元件。

這種設計特別適合 AI Dashboard、動態表單、Copilot、Agent UI、個人化工作台，以及「畫面結構本身需要由 AI 決定」的產品。

為什麼今天推薦它

json-render 不是今天才出現，但近期仍快速演進，因此本次採用「近期快速成長且具代表性工具」的 fallback。專案在 2026 年 8 月完成 v0.20.0 發布流程，目前官方文件已涵蓋 React、Vue、Svelte、Solid、React Native、TanStack Start、Image、PDF、Remotion、Ink 等多種 renderer；Vercel Labs 官方 GitHub 頁面目前也將它列為熱門專案之一。

它代表一個值得關注的 Generative UI 架構轉變：AI 不再直接生成可執行 UI 程式碼，而是生成受限制、可驗證、可串流的 UI 描述。

突破性重點

1. 把 Generative UI 從「Code Generation」改成「Contract Generation」

傳統 AI UI 生成常見流程是：

Prompt → LLM → JSX / HTML / JavaScript → Sandbox / Runtime

json-render 則變成：

Developer Catalog
       ↓
Prompt → LLM → JSON Spec → Validation → Registry → Native UI

模型只能使用 Catalog 中允許的元件與 Action，因此開發者可以控制 AI 能組合什麼，而不是事後再嘗試檢查任意生成程式碼。

這讓 Generative UI 的安全邊界從「執行後隔離」往前移到「生成時約束」。

2. Catalog 與 Registry 分離

Catalog 描述 AI 可以做什麼：

• Components
• Typed props
• Slots
• Actions
• Functions

Registry 則決定這些抽象元件在特定平台上 如何實作。

因此同一套 Generative UI 概念可以對應不同 renderer，而不必讓模型知道底層 React、Vue 或 Native implementation。

3. SpecStream：UI 可以逐步生成

json-render 使用 JSONL 型式的 SpecStream，每一行是 RFC 6902 JSON Patch operation，例如 add、replace、remove。

模型不需要等待完整 UI Spec 生成完畢才顯示畫面，而可以：

LLM token stream
→ JSON Patch
→ Spec state 更新
→ Renderer 更新
→ 使用者逐步看到 UI

這對 AI 介面很重要，因為它把長時間等待完整 JSON 的問題轉換成 Progressive Rendering。

4. Schema-agnostic

@json-render/core 並不把整套架構綁死在單一 UI schema。官方文件明確將 A2UI、Adaptive Cards、AG-UI、OpenAPI 與 Custom Schema 列為可對接的 schema 類型。

這使 json-render 更像一個 AI → Structured UI → Renderer 的中介層，而不是單純 React 元件庫。

5. 跨輸出媒介

官方 renderer 已不只 Web UI，還涵蓋：

• React
• Vue
• Svelte
• Solid
• React Native
• TanStack Start
• SVG / PNG
• PDF
• Remotion Video
• Ink Terminal UI

因此同一種「模型生成受控 Spec」模式可以延伸到文件、圖片、影片與 CLI，而不只是網頁。

核心架構與運作方式

json-render 可以拆成四層：

┌──────────────────────────┐
│        AI / LLM          │
└─────────────┬────────────┘
              │ JSON / SpecStream
              ▼
┌──────────────────────────┐
│ Catalog + Schema         │
│ 元件 / Props / Actions   │
└─────────────┬────────────┘
              │ validated spec
              ▼
┌──────────────────────────┐
│ Registry                 │
│ abstract → implementation│
└─────────────┬────────────┘
              ▼
┌──────────────────────────┐
│ Renderer                 │
│ React / Vue / Native ... │
└──────────────────────────┘

Catalog 是 AI 與應用程式之間的 capability contract；Spec 是模型產生的 UI 描述；Registry 把抽象元件映射到實際 implementation；Renderer 最後輸出平台原生 UI。

這種分層使 AI 決定「組合方式」，但真正可以執行的元件與 Action 仍由開發者控制。

主要優勢

安全性比直接生成程式碼更容易推理

模型無法任意新增未註冊的 Component 或 Action，也不需要把生成的 JavaScript 直接交給 Runtime 執行。

這不代表應用程式自動變成完全安全，但它大幅縮小 Generative UI 的能力表面。

UI 與模型解耦

模型只需要理解 Catalog 與 Spec，不必理解完整前端 Repository。更換模型時，不需要重新設計整套 UI Runtime。

適合 Streaming UX

SpecStream 將 UI 更新拆成 JSON Patch，因此能在模型生成期間逐步呈現畫面。

跨框架與跨媒介

核心 Spec／Catalog 思維可以延伸到 Web、Native、PDF、Image、Video 與 Terminal，這比只提供 React Renderer 的 Generative UI library 更有平台層潛力。

開發工具逐漸完整

官方 Devtools 可以檢查 Spec、State、Actions、Stream、Catalog，並從 DOM 元素反查 Spec key。對 AI 生成 UI 來說，可觀測性非常重要，因為問題可能來自 Prompt、Spec、State、Action 或 Renderer，而不只是傳統 Component code。

與其他方案相比

相較「LLM 直接產生 React / HTML」

json-render 的自由度較低，但可預測性、安全邊界與 Runtime control 明顯更好。Production 系統通常不希望任意模型輸出直接成為可執行前端程式碼，因此 Catalog 模型更容易治理。

相較固定 Chat UI

傳統 Chat UI 通常只有 Markdown、Tool Card 或少量預定義 message type。json-render 則允許模型在受控元件集合內重新組合整個介面，因此動態性高很多。

相較單一平台 Generative UI SDK

json-render 將 Core、Schema、Catalog 與 Renderer 拆開，並已支援多種前端框架與非 Web 輸出，因此更適合希望建立自己 Generative UI platform layer 的團隊。

缺點與限制

仍是 0.x 階段

近期版本仍位於 0.x，代表 API 與架構仍可能快速變動。若導入大型 Production 專案，需要鎖定版本並建立自己的 compatibility tests。

Catalog 設計會成為新的工程工作

Generative UI 並沒有消除 UI architecture。團隊仍需要仔細設計：

• 哪些元件可以暴露給 AI
• Props 要允許哪些值
• 哪些 Action 可以被觸發
• State 如何綁定
• 哪些操作需要額外授權

Catalog 太小會限制 AI；Catalog 太大則會增加模型選擇困難與治理成本。

JSON Patch 對模型仍有格式壓力

Streaming Spec 需要模型產生正確的 JSON Patch 與 JSON Pointer。雖然比任意程式碼容易驗證，但長時間、多次修改的複雜 UI 仍可能產生錯誤 patch，因此應保留 validation、retry 與 fallback。

不能把「沒有任意程式碼執行」等同完整安全

Action handler 最終仍可能觸發 API、資料修改或其他副作用。Catalog 限制的是模型可以要求哪些能力，不代表所有註冊 Action 都天然安全；Production 系統仍應實作 Authentication、Authorization、input validation 與 server-side policy enforcement。

適合的使用者與專案

適合：

• AI-first SaaS
• AI Dashboard / Analytics
• Agent Control Panel
• 動態表單與 Workflow Builder
• Copilot / Assistant UI
• 個人化工作台
• 需要 Generative UI，但不能接受任意 AI-generated code 的 Production 系統
• 希望同一 AI UI architecture 延伸到 Web、Native、PDF 或其他媒介的團隊

不適合的情境

不太適合：

• UI 幾乎完全固定的傳統 CRUD
• 不需要 AI 動態決定 layout 的網站
• 對 bundle、dependency 與 Runtime complexity 極度敏感的簡單頁面
• 團隊不願維護 Catalog / Schema contract
• 必須使用高度自由、任意生成 JavaScript 的 AI prototyping environment

結論

json-render 最值得注意的地方不是「AI 可以生成漂亮 UI」，而是它重新定義了 AI 與 UI Runtime 之間的契約。

與其讓模型直接輸出任意 JSX，再依賴 Sandbox 控制風險，它讓模型只輸出 受 Catalog 約束的 Structured UI Spec，真正的 Component implementation 與 Action execution 仍掌握在應用程式手中。

如果 Generative UI 從 Demo 逐漸進入 Production，這種 Catalog → Spec → Registry → Renderer 的架構很可能比「直接生成程式碼」更容易測試、治理與跨平台擴展。

目前仍是 0.x 專案，因此不應把它視為完全成熟的標準；但就架構方向、生態擴張與近期活躍度而言，json-render 是目前值得追蹤的 Generative UI 基礎設施之一。