OpenUI：用一門串流優先的語言，把模型輸出變成可渲染的 UI

問題不在生成，而在生成過程中的解析與渲染

讓模型吐出 UI，多數團隊的第一步是要求它輸出 JSON，前端再 JSON.parse 後映射成元件。這條路在一次性生成時可行，一旦改成串流就會出現兩個具體麻煩。第一，JSON 是不完整的：token 陸續到達時，字串往往停在半個物件或半個字串字面量上，前端必須自己寫容錯解析器，或者乾脆等全部收完再渲染，串流的意義就沒了。第二，JSON 的括號、引號與重複的鍵名在長輸出裡佔掉相當比例的字元，而這些字元對模型而言是純粹的負擔。OpenUI 針對的就是這兩點：它定義了一門叫 OpenUI Lang 的語言，README 稱其為串流優先（streaming-first），並宣稱相較 JSON 最多可少用 67% 的 token。這個數字來自專案自己的說法，文件沒有附上測量腳本或語料，採用前應視為方向性指標而非保證。適合的讀者是正在做助理、copilot 或互動式產品流程，且已經被「邊生成邊渲染」卡住的工程團隊。

元件庫反過來決定模型能生成什麼

OpenUI 的資料流在 README 裡用一張流程圖交代得很清楚：Component Library 產生 System Prompt，提示送進 LLM，模型回傳 OpenUI Lang 串流，交給 Renderer，最後變成即時 UI。關鍵在第一步。你不是先寫提示再祈禱模型吐出合法結構，而是先宣告一組可被渲染的元件，由這組元件產生模型指令。模型能生成的東西被元件庫的邊界限制住，解析器也就只需要處理這組元件的語法。這是一個明顯的設計取捨：換來的是可預期的輸出與較小的解析面，付出的是靈活性。如果模型需要生成一個你沒有預先定義的元件，它做不到，你只能回到元件庫裡補上定義並重新產生提示。對於產品介面相對穩定的團隊，這個約束是好事；對於想讓模型自由發揮版面創意的場景，這套機制會直接擋住你。

套件分層：從無框架的解析核心到預建聊天介面

README 的套件表把職責切得相當細。@openuidev/lang-core 是核心解析器、提示生成、執行期求值與型別層，不依賴 React、Vue 或 Svelte，適合框架無關的場合。往上，@openuidev/react-lang 負責在 React 裡定義元件庫、產生提示並渲染串流；@openuidev/react-headless 提供無樣式的聊天狀態、串流適配器與訊息格式轉換，讓你自己接 UI；@openuidev/react-ui 則是預建的聊天版面、獨立 UI 元件與兩套內建元件庫，README 稱之為最快的完整 React 聊天體驗路徑。其他框架走社群整合路線：@openuidev/vue-lang 對應 Vue 3，@openuidev/svelte-lang 對應 Svelte 5。還有兩個較特別的套件：@openuidev/langchain 提供 agent transformer 與伺服器端輔助，讓 OpenUI 透過 AG-UI 串流；@openuidev/react-email 則把 React Email 元件定義與提示選項接上，用於模型生成郵件與 HTML 匯出。這張表的實務意義是：你可以只取 lang-core，也可以整包用 react-ui，中間的每一層都是獨立可選的。

啟動一個可跑的範例只需要三行指令

README 給的 Quick Start 相當直接：先執行 npx @openuidev/cli@latest create --name genui-chat-app 產生專案，cd 進去，把 OPENAI_API_KEY=sk-your-key-here 寫入 .env，然後 npm run dev。這個腳手架產出的是一個端到端起點，內含串流、內建 UI 與 OpenUI Lang 支援。要注意的是它預設綁定 OpenAI 的 API key 環境變數，如果你用的是其他模型供應商，這個變數名稱與對應的呼叫端需要自行調整，README 沒有示範替代路徑。另外，專案在 README 開頭放了一段醒目的聲明：OpenUI 沒有任何官方加密貨幣、代幣或代幣資產，任何使用 OpenUI 名稱的資產都與本專案無關。對於會搜尋專案名找資源的人來說，這段話的存在本身就是一個提醒。

串流渲染是賣點，也是你必須自己驗證的部分

整個框架的價值集中在「Renderer 逐步解析模型輸出」這件事上，README 的核心能力列表也把它列為 Streaming renderer：在 React 裡隨著 token 到達逐步解析並渲染。但這份材料沒有說明當串流中途出現語法錯誤時會發生什麼，也沒有描述部分渲染的節點在後續 token 抵達後如何被替換或丟棄。這是評估時最該自己動手確認的地方，因為它決定了使用者會看到畫面閃動、殘缺元件，還是穩定的漸進呈現。同樣沒有交代的是效能：解析器在長輸出下的表現、每 token 的解析成本，材料裡都沒有數字。把這套框架放進正式產品前，建議直接用它附的 Playground 或 CLI 範例，餵一段你自己領域的長提示，觀察渲染過程中的中間狀態。

與直接要求模型輸出 JSON 的差異

最現實的替代方案不是某個競品，而是「叫模型吐 JSON，自己寫解析與映射」。兩者的差別在約束放在哪裡。JSON 路線把結構正確性的責任交給模型的輸出品質與你的容錯解析器，語言本身沒有語意，模型可以生成任意鍵名，前端必須為每個鍵寫映射邏輯。OpenUI 路線把結構定義前移到元件庫，提示由元件庫生成，模型只在這個封閉集合裡組合，解析器因此可以假設語法邊界。代價是多了一層學習成本：你的團隊要理解 OpenUI Lang 的寫法、要維護元件定義與提示之間的同步。若你的輸出只有三、四種固定結構，JSON 加上一個手寫的增量解析器可能更省事；當可生成的元件數量成長到十幾二十種、且輸出必須邊到邊顯示時，元件庫驅動提示的作法才開始划算。

維護成本、授權與該先確認的事

授權是 MIT，README 與 LICENSE 檔一致，這對商業採用是相對寬鬆的條件。這裡只陳述授權識別，不構成法律意見，實際條款與你產品中的其他依賴是否相容，仍應由法務確認。維護面上，這份材料顯示專案未封存、預設分支為 main、最後推送時間為 2026-09-09，主題標籤包含 help-wanted 與 looking-for-contributors，代表專案在主動尋找貢獻者。這同時是一個訊號：React 以外的框架整合被標為社群支援，Vue 與 Svelte 的綁定能否跟上核心演進，取決於社群投入，而不是維護團隊的承諾。由於檢索不到任何近期 release，版本節奏無法從這份材料判斷，升級路徑也就無從評估。採用前請先確認三件事：lang-core 的解析器是否覆蓋你需要的語法；react-ui 內建的兩套元件庫與你現有設計系統的落差有多大；以及當 OpenUI Lang 語法變動時，你的元件定義需要改多少。

編輯結論

如果你已經在用 React，而且模型輸出必須邊生成邊顯示成圖表、表單或表格，OpenUI 的分層設計值得先跑一次 CLI 產生的範例應用，再決定要不要把自家元件庫接上 lang-core 的提示生成。若你的產品只需要純文字回覆，或前端不是 React、Vue、Svelte 其中之一，這套框架帶來的解析器與語言約束只會變成負擔。動手前先確認兩件事：你要用的元件是否已經有對應的套件支援（react-ui 內建兩套元件庫，其他框架屬於社群整合），以及 OpenUI Lang 在你自己領域的提示下是否真的比 JSON 省下可觀的 token，這一點官方文件只給了「最多 67%」的說法，沒有公開可複現的測量方法。

官方來源

1. Issues
2. License: MIT
3. Project website
4. README
5. thesysdev/openui on GitHub