本文由體驗技術團隊OpenTiny項目負責人莫春輝老師原創。

引言

2025 年 11 月 18 日，螞蟻集團全模態通用 AI 助手——靈光 App 發佈，上線兩週用户已創建 330 萬個閃應用。這一現象級數據的背後，不僅是開發效率的提升，更是人機交互範式正在從圖形用户界面（GUI）向生成式用户界面（GenUI）的跨越。在新的範式下，應用不再是預先固化的靜態資產，而是根據用户自然語言意圖實時生成。閃應用所展現的數十秒構建能力，是生成式 UI 將界面從預先設計轉變為即時生成的體現，它讓應用“按需生成、用後即棄”。本文將深入剖析生成式 UI 的基本概念、技術特徵與渲染原理，並結合我們 OpenTiny 產品的落地實踐，探索生成式 UI 在推動企業應用智能化的巨大潛力。

1. 從阿里推出千問 App 和靈光 App 談起

1.1 千問 App：覆蓋全場景的 AI 智能中樞

2025 年 11 月 17 日，千問 App 正式發佈，這是阿里大模型戰略從技術後台走向市場前台的關鍵一步。這款定位為“會聊天、能辦事”的個人 AI 助手，不僅僅是一個停留在“幫用户思考” 1.0 時代的聊天工具，它直接邁入了替用户行動的 2.0 階段。阿里表示，千問 App 將快速迭代，通過意圖驅動的方式深度整合地圖、外賣、訂票、辦公等生活場景。這意味着用户不再需要在大腦中構建複雜的應用菜單索引，只需表達目標，千問 App 即可直接完成任務閉環。

AI 助手註定將取代傳統 App 甚至操作系統，成為未來數字世界的“超級入口”。這一形態的護城河在於“認知適應性”，它能記錄用户的習慣偏好，隨着交互加深而變得更加默契，形成極強的粘性。 在這一“兵家必爭之地”，阿里擁有得天獨厚的先發優勢：其背後龐大的生態體系（電商、導航、商旅、辦公）構成豐富的“原子化能力池”。一旦這些服務被深度打通，千問 App 將不再是一個簡單的應用，而是一個聚合阿里全生態的“智能編排器”，真正形成覆蓋生活全場景的超級入口。

千問 App 如何無縫連接這龐大的生態？答案是生成式 UI 技術。在傳統的交互模式下，用户需在不同 App 間頻繁跳轉。而在千問 App 的對話中，系統不會強迫用户跳出當前語境，而是利用生成式 UI 技術，根據用户的需求，實時構建並渲染出一個 UI 界面。 例如，當用户提出購物需求時，不是跳轉到淘寶，而是在對話中直接生成一個流式渲染的、可交互的商品卡片。這種“用後即棄”的界面消除了體驗斷點，將服務以原子化能力的形態直接呈現在用户面前。這正是生成式 UI 技術的核心價值——讓應用界面“隱形”，讓服務與意圖實現“零距離對接”，從而提升用户在千問 App 內的停留時長與活躍度。

1.2 靈光 App：填補長尾場景的即時生成引擎

2025 年 11 月 18 日，就在千問 App 發佈次日，阿里系螞蟻集團推出了全模態通用 AI 助手——靈光 App。其突破性在於將生成式 UI 的能力引入移動端，實現自然語言 30 秒生成小程序。靈光 App 整合了靈光對話、靈光閃應用、靈光開眼三大功能，不僅支持傳統的圖文音視輸出，還具備生成 3D 動畫、動態地圖及全功能小程序的全模態能力。

傳統 AI 助手往往受限於“文本堆砌”或“靜態模板”，而靈光對話基於生成式 UI 技術，重構了信息呈現方式。 當用户詢問“怎麼做麻婆豆腐”時，App 並非簡單羅列步驟，而是實時構建一個包含色澤紅亮的菜品圖、圖文並茂的教程。並且所有內容，無論是財報數據的交互式圖表、天宮空間站的 3D 模型，還是量子糾纏的生成式動畫，均由大模型在“運行態”即時生成，無需調用“預設模板”。這種“讓複雜變簡單”的設計，消除了信息獲取的認知障礙，體現了生成式 UI 技術將數據轉化為直觀體驗的價值。

僅需一句指令 30 秒內生成實用工具，靈光閃應用是“即時生成”理念的完美詮釋。 例如用户輸入“溏心蛋要煮多久”，App 立刻生成一個包含雞蛋大小選擇、熟度參數調節的溏心蛋時間計算器。這些閃應用是為了滿足“無限長尾需求”而實時構建的完整應用，也具備按需生成、用後即棄的特性。它跳出傳統應用開發的“覆蓋率陷阱”，讓每一個微小的、個性化的需求都能擁有專屬的應用界面，實現從“開發應用”到“生成應用”的範式跨越。

1.3 生成式 UI 技術的雙輪驅動搶佔未來入口

將千問 App 與靈光 App 結合來看，阿里的 AI 戰略版圖清晰浮現：千問 App 利用生成式 UI 界面聚合主流服務，解決高頻、標準化的大場景需求；靈光 App 則利用生成式小程序填補個性化、非標準化的小場景空白。兩者互為補充，共同構建了一個“無死角覆蓋”用户意圖的高粘性生態。不遠的將來，誰能同時掌握原子化能力的調度、長尾需求應用的即時創建，誰就真正掌握了通往未來的“超級流量入口”。

2. 生成式 UI 的基本概念

2.1 從命令到意圖的交互範式轉移

人機交互的歷史，本質上是一部不斷降低用户意圖與機器執行之間“翻譯損耗”的歷史。在計算時代的早期，命令行界面（CLI）佔據統治地位，用户任何字符的輸入錯誤都會導致交互失敗。這種“以機器為中心”的交互範式要求用户必須“像機器一樣思考”，即將用户意圖轉換成精確的命令字符。

隨後圖形用户界面（GUI）的出現降低了認知門檻。然而 GUI 建立在一個假設之上——“確定性”。在傳統的 GUI 範式中，設計師與開發者在應用發佈前，基於對目標用户羣體的“平均假設”，預先構建所有的頁面佈局、導航路徑與交互組件。這種確定性導致用户體驗本質上是靜態的。用户必須調整自己的思維模型，來適應固定的操作流程，通過在複雜的菜單樹中進行“導航”來逼近其意圖。換言之，GUI 雖然圖形化了，但依然迫使用户去“適應工具”，而非工具適應用户。

生成式 UI 的崛起，標誌着確定性交互範式正向“意圖驅動”範式轉移。在生成式 UI 的框架中，界面不再是“靜態資產的集合”，而是“流動性組件的集合”。應用不再依賴預先定義的界面，而是基於大語言模型對用户自然語言指令、當前上下文環境及歷史行為模式的理解，動態生成最適合當前任務的界面組件。這種轉變將交互設計的重心，從“界面佈局設計”轉移到“意圖結果導向設計”，即直接呈現完成任務所需的交互實體，而非讓用户在工具箱中尋找工具。

2.2 關於生成式小程序的定義與應用

生成式小程序與微信小程序不同，不是預先開發、靜態部署的移動端應用。它是指由 AI 根據用户意圖和上下文實時生成的、短暫存在的、功能完備的交互式應用。其核心特徵主要包括以下三個方面：

• 意圖驅動：用户無需在複雜的菜單或界面中尋找“功能入口”，只需直接表達目標，AI 即可自動規劃實現路徑，並動態生成對應的小工具或應用界面。
• 動態流式構建：小程序不再依賴預先下載的靜態代碼包，而是隨着 AI 的“實時推理”，通過流式傳輸等技術將所需的界面組件，按順序推送到前端並即時渲染。
• 原子化能力封裝：後端複雜的業務邏輯被封裝為獨立的“原子化能力”，AI 在運行時根據當前場景和需求，動態調用並組裝這些能力，快速構建出完整功能。

生成式小程序的實際落地應用需要依靠“端側大模型”。傳統模式下，商家需通過編寫代碼來開發微信小程序，而在“端側生成技術”的加持下，商家只需描述服務需求，端側大模型實時生成對應的交互應用。當用户訪問該商家時，其本地的大模型能根據“服務描述文件”，實時渲染出交互界面。這意味着，小程序的形態從“預先下載的代碼包”轉變為“下載的意圖描述 + 本地實時生成 UI”。

此外，生成式小程序在企業級應用中展現出獨特的“隱私保護”優勢。以醫院掛號或銀行業務辦理為例，這些場景通常涉及大量敏感信息填寫。端側大模型可在本地內存中直接處理用户證件照、自動提取信息並填入表單，或者結合用户歷史記錄動態生成個性化界面。所有推理與界面生成均在本地完成，規避因數據上傳雲端導致的隱私泄露與合規風險。

3. 流式輸出機制的深度解析

3.1 推理延遲與流式輸出的必要性

儘管生成式 UI 描繪了理想的交互方向，但在工程落地上面臨物理瓶頸：大語言模型的“推理延遲”。與傳統 REST API 毫秒級的響應速度不同，大模型生成完整響應往往需要數秒甚至更久。在傳統的“請求-等待-響應”模型下，這種延遲會導致用户在空白屏幕前等待時間過長，進而放棄交互。

因此，流式輸出不僅是一種性能優化手段，也是生成式 UI 能夠成立的基礎。通過流式傳輸，在服務端生成的第一個 Token 就開始在客户端渲染界面，將用户的“等待時間”轉化為“用户閲讀與交互時間”。這種機制既解決了技術上的超時問題，也讓用户對 AI 的思考過程有了感性的認知。

上圖是流式輸出示例Demo，接下來將深入剖析生成式 UI 流式輸出的技術原理，重點圍繞 Markdown 文本流與結構化對象流（StreamObject）中的技術差異、渲染原理及 Diff 局部刷新機制等。

3.2 Markdown 純文本流的侷限性與渲染瓶頸

3.2.1 技術實現機理

早期的生成式 UI 形式（以 ChatGPT 為代表）主要依賴 Markdown 純文本流。其技術鏈路相對直觀：大模型輸出包含 Markdown 標記的文本流，前端利用 Server-Sent Events (SSE) 或 HTTP 分塊傳輸接收數據塊，然後使用 markdown-it 等工具庫，將接收到的字符串實時轉換為 HTML。

這種方式的優勢在於“通用性”與“低耦合”。幾乎所有的大模型都經過 Markdown 語法的微調，能夠穩定輸出格式化文本。然而它的侷限性在於缺乏交互。Markdown 本質上是一種靜態文檔描述語言，它無法定義複雜的交互邏輯（如表單驗證、動態圖表交互等），它生成的界面是“只讀”的，用户只能看不能操作。

3.2.2 渲染性能瓶頸

從渲染原理上看，Markdown 流存在嚴重的“性能隱患”。由於 Markdown 的語法具有高度的“上下文相關性”，例如，一個星號 * 是列表項還是斜體，完全取決於後面的字符序列，這意味着大多數 Markdown 解析器難以實現真正的“增量解析”。

每當新的文本塊到達，前端通常需要將累積的上下文相關文本重新送入解析器，生成新的抽象語法樹，並銷燬舊的 DOM 節點以構建新節點。隨着生成內容的變長，這種 O(N) 甚至 O(N^2) 的計算開銷可能會導致明顯的頁面閃爍與滾動條抖動，破壞用户體驗。這種“重繪”不僅消耗客户端資源，導致設備發熱，還會打破流式輸出的“流暢感”。

3.3 結構化對象流（StreamObject）與部分解析技術

為了突破 Markdown 的交互限制，以 Vercel AI SDK 和 TheSys 為代表的技術方案轉向了“結構化對象流”。這一路徑的核心是強制大模型輸出符合嚴格 Schema 定義的 JSON 或 DSL 數據，並在客户端進行實時的“部分解析”與渲染。

3.3.1 Vercel 的 StreamText 與 StreamObject

Vercel AI SDK 提供了 streamText 與 streamObject 兩種 API，分別對應非結構化與結構化流，其主要區別如下：

streamObject 的核心價值在於它允許開發者定義一個 Zod Schema，並要求大模型嚴格按照該結構輸出。這使得前端可以直接將生成的數據映射為 React/Vue 組件（例如 <LineChart data={...} />），而非簡單的 HTML 元素。

3.3.2 結構化流的部分 JSON 解析器

結構化流的最大技術挑戰在於 JSON 格式的“非流式特性”。標準的 JSON.parse() 方法要求輸入必須是完整閉合的 JSON 字符串。然而在流式傳輸過程中，客户端在任意時刻接收到的數據都可能是“殘缺的”。例如，大模型可能輸出了 {"users":。

為了解決這個問題，生成式 UI 框架引入了複雜的“部分解析器”（Partial Parsers），例如 json-river 或 Vercel 自研的解析邏輯。這些解析器已不是簡單的反序列化工具，而是基於“狀態機”的編譯器，其主要能力如下：

• 詞法分析：解析器實時掃描字符流，識別出 JSON 詞法元素，比如對象定界符、數組定界符、鍵值分隔符等。
• 類型安全修復：Vercel AI SDK 引入了 experimental_repairText 機制，利用微型模型或啓發式算法，修復因大模型偶爾輸出非法 JSON（如錯誤的轉義字符）導致的數據流斷裂。

3.3.3 TheSys C1 的 XML-like DSL 流式響應

與 Vercel 堅守 JSON 不同，TheSys 的 C1 API 選擇了一條獨特的實現方式：基於 XML 或自定義 DSL 的流式響應。其響應流可能包含 <thinking>（展示推理過程）和 <content>（UI 描述）等標籤。

TheSys 這條技術路線的優勢在於：XML 結構的起始標籤和結束標籤提供了明確的“邊界定界符”。流式解析器可以更容易利用正則或簡單的棧結構來分割數據塊，無需像解析 JSON 那樣深度遞歸地追蹤嵌套層級。這種設計在處理大規模併發流時往往表現出更高的“魯棒性”與“解析效率”，尤其是在企業級高吞吐場景下，能夠有效防止因單個 Token 丟失導致的整個 JSON 結構崩塌。

3.4 界面渲染的 Diff 機制與局部刷新

在解決界面初始化渲染的數據傳輸與解析後，如何在不阻塞主線程的情況下高效更新 UI 界面？這裏涉及到數據層與視圖層的雙重“Diff 機制”。

3.4.1 數據層 Diff：JSON Patch 與 Delta 更新

為了減少網絡帶寬佔用並降低客户端的解析壓力，生成式 UI 系統（如 LangDiff）不再傳輸累積的完整數據，而是傳輸“變更集”（Deltas）。

更新原理：服務端並不發送整個更新後的 JSON 對象，而是計算當前幀與上一幀的差異，並生成符合 RFC 6902 標準的 JSON Patch 操作指令。例如：

[
  { "op": "add", "path": "/chart/series/0/data/-", "value": 25 },
  { "op": "replace", "path": "/status", "value": "generating" }
]

性能優勢：客户端僅需維護一個狀態對象，並根據接收到的 Patch 指令進行“局部修改”。這極大地降低了數據處理的時間複雜度，從全量解析的 O(N) 降低到了 Patch 應用的 O(1) 或 O(M)（M 為變更量），對於移動端低算力設備尤為重要。

3.4.2 視圖層 Diff：React 與 Vue 的更新機制

當新的數據片產生後，前端框架需要將其映射到 UI 界面，以下分別從 React 和 Vue 的角度講解視圖層的 Diff 更新機制。

在 React 生態中，這依賴於 Fiber 架構的“協調算法”。Vercel AI SDK 的 useObject Hook 內部維護了隨時間變化的數據狀態。每當流更新時，它觸發組件重渲染。為了防止高頻（如每秒 20 次）的數據流導致頁面卡頓，生成式 UI 組件通常採用 React.memo 進行包裹，並使用“深層比較”或“不可變數據結構”作為 Props。這意味着，如果 Patch 僅僅更新了頁面底部表格的最後一行，頁面頂部的圖表組件因 Props 未變，將直接跳過渲染過程。這種“細粒度的局部刷新”是生成式 UI 實現流暢動畫效果的關鍵。

在 Vue 生態中，視圖更新依賴於其“響應式系統”與“虛擬 DOM Diff”的雙重機制。當響應式數據變化時，Vue 的響應式代理會精準追蹤依賴關係，僅觸發相關組件的更新。其虛擬 DOM Diff 採用雙端比較 + 最長遞增子序列算法，結合編譯時的“靜態提升”、“補丁標記”和“樹結構壓平”等優化，實現高效的 DOM 更新。對於高頻數據流場景，開發者可通過 v-memo 指令、shallowRef 淺層響應式、computed 計算屬性緩存以及 KeepAlive 組件實例複用等策略，實現細粒度的局部刷新。這種響應式驅動與編譯時優化相結合的機制，確保了生成式 UI 在持續數據流下的流暢渲染體驗。

3.5 非 Web 端的技術實現方式

儘管基於 Web 的 HTML/JSON 是目前的主流實現方式，但為了滿足特定的性能需求、安全隔離或跨平台場景，業界探索出了多種替代實現方式。

3.5.1 移動端：Flutter 生成式 UI 與 A2UI 協議

在移動應用中，通過 WebView 渲染流式 HTML 往往面臨“性能”（幀率不足、內存佔用高）和“體驗”（非原生交互手感）的雙重挑戰。Google Flutter 團隊推出的生成式 UI SDK 展示了一種完全原生的，以 “Widget Catalog” 與 “A2UI 協議” 為核心的解法。Flutter 的生成式 UI 不生成代碼，也不生成 DOM，它採用了一種“預製件組裝”的策略：

• Widget Catalog（組件目錄）：開發者在 App 編譯階段預先定義一系列原生的 Flutter Widget（如 WeatherCard, ProductList），並將這些組件的元數據（名稱、參數 Schema、描述）註冊到生成式 UI Manager 中。
• A2UI (Agent to UI) 協議：大模型與客户端之間的通信不再是自由的文本，而是遵循 A2UI 協議的“指令流”。這些指令類似於遠程過程調用（RPC），指示客户端：“使用參數 X、Y 實例化組件 Z”。

客户端接收到指令後，Flutter 應用利用其底層的 Skia 或新一代 Impeller 圖形引擎直接在 GPU 層繪製 UI。這意味着生成的界面與手寫原生界面在性能上完全一致，可以輕鬆實現 120fps 的滾動與動畫，且完全支持原生的手勢操作。這種“服務端決策邏輯 + 客户端原生渲染”的模式，解決了 Web 生成式 UI 在移動端的用户體驗問題。

3.5.2 服務端：Server-Driven UI 的 AI 化演進

服務端驅動 UI（SDUI）是一種成熟的架構模式，廣泛應用於 Airbnb、Uber 等大型 App 中。SDUI 的“生成”發生在服務端，傳統的 SDUI 由後端業務邏輯拼裝 JSON 配置，而生成式 UI 下的 SDUI 則由服務端的“大模型 Agent”動態生成佈局樹。

SDUI 的技術優勢在於：將生成邏輯完全收斂在服務端，使得企業可以在服務端部署重量級的“安全護欄”和“校驗邏輯”，確保下發給客户端的 UI 結構安全合規。客户端完全淪為“界面渲染器”，這極大簡化了客户端的邏輯複雜度。

Next.js 的 React Server Components 是 SDUI 在 Web 前端的現代進化版。與傳輸 JSON 數據不同，RSC 允許服務端直接流式傳輸序列化後的組件樹（Flight 數據格式）。在 RSC 架構下，大模型生成的不再是待解析的數據，而是直接生成的 React 組件節點。這些節點在服務端被渲染成流格式，客户端接收到後直接“水合”（Hydrate）進現有的 DOM 樹中。這種方式模糊了數據與 UI 的界限，實現了真正的“UI 流式傳輸”。

4. 實時生成與設計態預設

在生成式 UI 中除了流式輸出技術不同，界面的來源也存在分歧——“實時生成”與“設計態預設”。這個分歧的根本在於 AI 的定位：AI 究竟是一個擁有自主意識、能夠即興創作界面的“設計師”，還是一個僅僅在預設規則下進行檢索與調度的“管理員”？下圖是生成式 UI 實時渲染的工作流程：

4.1 實時生成範式：意圖驅動與即時生成

“實時生成”是生成式 UI 的理想形態。在這種模式下，用户界面不再是靜態的軟件資產，而是“對話語境”的即時產物。

4.1.1 即時生成與用後即棄

在傳統軟件工程中，開發一個功能頁面通常需要經歷漫長的週期，且頁面是“永久存在”的。然而在實時生成範式中，用户提出一個個性化或一次性的需求時，AI 會“即時”編寫代碼或生成描述語言，渲染出一個僅服務於當前時刻、當前用户的“微應用”。用户使用一次後，這個應用即被銷燬。

4.1.2 用户認知適應性

實時生成允許應用“感知”用户的專業程度和當前狀態。例如，對於數據分析師，它可能生成包含複雜迴歸曲線的交互式儀表盤；而對於普通管理層，同樣的查詢可能生成簡明的摘要卡片和趨勢箭頭。這種“佈局層面”的即時調整是傳統“響應式設計”（僅基於屏幕尺寸調整）無法企及的。

4.1.3 代碼生成與沙箱環境

最激進的實時生成方式是讓大模型直接輸出“可執行的代碼”（如 React/JSX, Vue, HTML/CSS 等）。大模型輸出代碼塊，前端應用內嵌一個“沙箱環境”，實時編譯並掛載這些代碼。這種方式非常靈活，AI 可以創造出前所未見的佈局、動畫效果，甚至發明新的交互控件。但在企業級應用中，這種方式極少直接使用，因為存在巨大的安全隱患（XSS 攻擊）和“樣式失控”風險（AI 生成的樣式可能破壞原有品牌規範）。

4.2 設計態預設範式：確定性的避風港

作為實時生成的對立面，“設計態運作”代表了工業界對生成式 UI 的“務實妥協”，尤其是在金融、醫療等對“準確性”要求極高的領域。

4.2.1 預製件組裝策略

在設計態模式中，界面的構建權迴歸開發人員。產品經理與設計師在設計態規劃並構建界面組件，並將其“註冊”到組件庫中。在運行態，AI 的角色被“降級”為意圖識別和參數填充。AI 輸出的不是界面描述，而是“調度指令”，例如 Call Widget: WeatherCard(city="Beijing")。這種做法的好處顯而易見：

• 不可預測性的消除：企業可以確保用户看到的每一個像素都是經過人工審核的，完全符合品牌規範。
• 安全與合規：不會出現 AI 捏造虛假的按鈕（“幻覺 UI”）或誘導性交互的情況。
• 性能優勢：原生渲染（如 Flutter Impeller 引擎）通常比實時生成的 Web DOM 性能更高，體驗更流暢。

4.2.2 覆蓋率陷阱與體驗退化

設計態的“有限預設”註定無法覆蓋無限的意圖，這就是“覆蓋率陷阱”。當用户提出一個並未在設計態預設的請求時，應用會遭遇“匹配預製件失敗”，並退化到“純文字描述”階段。這種“體驗斷層”是目前基於設計態的產品面臨的主要痛點。

例如，在一個旅遊 App 中，如果預置了“機票”和“酒店”組件，但用户問：“我想找個既能看海又能滑雪的地方”，App 無法找到對應的預製組件，只能回覆一段純文本建議。這種從 GUI 到 Chatbot 的“退化”，被用户視為體驗的“降級”。

4.3 工作流編排：折中方案的侷限

為了緩解覆蓋率問題並增強控制，業界普遍採用智能體“工作流編排引擎”（如 n8n, Dify, Coze, LangFlow）。開發者通過可視化的 DAG（有向無環圖）編排業務流程。

然而，這種方案本質上是設計態預設的變體。AI 在這裏並不進行真正的“規劃”，它只是一個“智能編排器”。這種模式限制了大模型的推理能力，使得交互變得“線性化”和“僵化”，無法處理非線性的、跳躍的人類對話。真正的大模型推理能力體現在“動態規劃”上，即 AI 面對問題自主決定第一步做什麼、第二步做什麼，而不是沿着人類畫好的箭頭走。

4.4 兩者的融合與演進

既然實時生成擁有“無限的適應性”但缺乏“可控性”，而工作流編排擁有“可控性”但限制了 AI 的智能，生成式 UI 必然走向兩者的融合。這種融合的關鍵在於：在“設計態”定義約束，在“運行態”釋放自由。

4.4.1 動態設計系統

生成式 UI 架構不再是簡單的全自動或全手動，而是“基於規則的即興演奏”。我們應將組件視為語言中的“單詞”，並按照以下方式組裝成“句子”：

• 設計態約束：設計師構建一套原子化的設計系統（Buttons, Cards, Lists, Charts），並定義它們的使用規則（“語法”）。這些是確定性的、安全的。
• 運行態組合：AI 不再直接生成 HTML，而是像寫文章一樣，調用這些“組件單詞”來動態生成“界面句子”。

在這種模式下，不需要預設僵化的流程圖。AI 擁有一個“工具箱”，根據用户意圖，它可以自主決定：“我先拿一個 Chart 組件，再拿一個 Table 組件，把它們拼在一起，展示給用户。” 這既保留了 AI 的推理決策能力（決定拼什麼），又保證了界面的規範性（拼出來的東西是基於標準組件的）。

4.4.2 約束下的推理

為了解決實時生成的不可預測性，技術重心將從“限制流程”轉向“限制輸出結構”：

• 結構化流與類型校驗：利用 Zod Schema 或 TypeScript 接口，強制 AI 的思維過程符合特定的數據結構。這是一種“軟性約束”，它允許 AI 在框定的範圍內自由發揮，而不是像工作流那樣規定每一步必須怎麼走。
• 上下文注入：利用 MCP 等協議，將業務規則、組件文檔實時注入到大模型的上下文中，使得 AI 變成了一個“熟悉業務的專家”，它不需要被硬編碼的流程圖牽着鼻子走，而是能夠根據原則自主處理各種突發情況。

5. 生成式 UI 驅動應用智能化演進

生成式 UI 技術的落地，標誌着軟件架構正從“以界面為中心”邁向“以意圖為中心”的轉變。其最終形態，並非僅是生成簡單的文本或 UI 交互頁面，而是能夠實時創建複雜、交互完整的輕量級應用（生成式小程序）。這些應用功能被進一步封裝為原子化能力單元，供 AI 按需調度。在這一新範式下，應用的核心價值不再是提供一套固定的操作界面讓用户“學習與導航”，而是化身為一個由 AI 根據用户意圖“實時組裝與驅動”的“能力池”。

作為企業應用智能化改造的超級加速器，將生成式 UI 技術與 OpenTiny 的 WebMCP 技術相結合，能夠以較低的侵入性甚至是非侵入性實現智能化改造：將傳統“人手動操作界面”的模式，升級為“AI 理解意圖 - 調度原子能力 - 動態生成界面”的智能交互閉環，從而替代或協助人完成任務。

當前，企業應用的智能化改造主要有以下三種路徑，體現了從高侵入性到非侵入性的漸進式演進：

5.1 後端 API 的 MCP 協議化改造（高侵入性）

這是最直接但侵入性最高的方案。其核心是“繞過前端”，直接將後端 API 改造為符合 MCP 協議的接口，供 AI 直接調用與編排業務邏輯。此方案將後端服務徹底轉成原子化能力，但面臨以下挑戰：

• 改造複雜與權限重構：由於 AI 直接調用後端 MCP 服務，繞過了原本前端應用已經建立的權限機制，因此，必須基於 MCP 協議的鑑權體系重新建立一套新的權限機制，確保 AI 僅以“代表用户”的身份令牌執行操作。
• 雙軌運維成本高：將遺留 API 改造成 MCP 服務，要求圍繞 AI 的特點，實現 API 的“AI 友好化”和“智能化”。開發者通常需要維護現有 API 服務和新的 MCP 服務的兩套代碼，導致開發和運維成本顯著增加。
• 新型安全挑戰：在缺乏生成式 UI 構建的交互界面進行關鍵操作確認的情況下，由於大模型尚未完全成熟，純自然語言交互易遭受“誘導性指令攻擊”，可能導致 AI 越權或執行惡意操作。

5.2 前端頁面的 MCP 工具聲明（低侵入性）

這種路徑實現了應用從傳統模式到智能模式的“平滑過渡”。它在不改變現有前後端邏輯的前提下，通過使用 OpenTiny 的 WebMCP 技術，在前端將現有頁面功能“聲明”為 MCP 工具，使其成為 AI 可調度的原子能力，為後續智能化演進奠定基礎。該路徑的特點如下：

• 低成本與平滑過渡：無需改動現有後端 API 服務或前端交互邏輯，僅通過在前端添加腳本“聲明” MCP 工具，將頁面功能定義為原子化能力，使得改造成本較低。
• 邊界與權限可控：AI 能獲取的頁面信息及調用的功能，完全取決於該應用的開發人員在前端聲明的 MCP 工具腳本。由於這些工具僅在用户登錄可見，因此 AI 調用該 MCP 工具是以“登錄用户”的身份執行，這讓權限邊界更清晰。
• 實現交互轉移：基於聲明的前端 MCP 工具，生成式 UI 技術可將複雜操作流程轉化為“對話式的確認交互”。AI 無需“模擬點擊”，即可生成包含“執行計劃”的交互卡片，實現高效的人機協同閉環。

5.3 瀏覽器擴展插件的 MCP 能力注入（非侵入性）

對於無法修改源碼的遺留系統，這是理想的非侵入式改造方案。用户通過安裝 OpenTiny 提供的瀏覽器擴展插件，向 Web 應用“動態注入” MCP 工具，同時插件連接 OpenTiny 的 Agent 代理服務器，使得 AI 可以通過代理遠程調用已注入的 MCP 工具。相比前兩種路徑，此方案的主要改進點體現在：

• 真正的非侵入性改造：通過瀏覽器擴展機制，無需修改現有應用源代碼，即可實現將應用功能原子化。只需為相應的 Web 應用預先開發 MCP 工具腳本，由插件匹配網址後注入。
• 支持多環境執行：支持在“主世界”（與頁面同權限）和“擴展隔離環境”中執行。例如，既可在主世界通過執行腳本動態注入 MCP 工具，也能在瀏覽器擴展隔離環境中通過執行腳本註冊 MCP 工具。
• 可擴展的技能：通過 Agent 代理服務器，AI 不僅能調用注入的 MCP 工具，還能集成地圖、文檔處理等“雲端或本地技能”。另外，還可結合 Computer Use 等 RPA 技術，使 AI 具備“視覺感知”與“模擬操作”能力。

6. 生成式開發平台

生成式小程序如果讓 AI 完全自由發揮，雖能覆蓋海量長尾場景，卻會引入不可控的工程與業務風險。為解決“AI 的概率性創造”與“企業所需的確定性交付”之間的衝突，確保生成式小程序在安全、合規與體驗上的一致性，我們需要構建“生成式開發平台”。

6.1 為何需要生成式開發平台

生成式開發平台的核心使命，是為 AI 的創造力設立“安全的軌道”，使其在滿足企業級嚴苛要求的前提下，高效生成可靠、可用的交互界面。

6.1.1 消除幻覺 UI 與保障企業級安全

大模型本質是概率模型，讓 AI 自主生成極易產生“幻覺 UI”。例如調用不存在的方法、傳遞虛構參數，或在關鍵業務界面中生成具有誤導性的危險操作按鈕。而在金融、政務、醫療等領域，每一個像素、每一次交互都須準確無誤且經過合規審核，這是“自主 AI”無法保證的。

生成式開發平台通過嚴格的“類型安全校驗”（如 Zod Schema）和“預審的設計系統”，強制 AI 只能在預定義的、安全的組件庫範圍內進行選擇與組裝，從根本上禁止 AI 自行繪製像素或編寫不受控的樣式代碼，從而杜絕幻覺 UI 的產生。

6.1.2 構建動態設計系統與原子化能力池

前面提到過，生成式 UI 的演進將融合實時生成與設計態預設，為此需要構建“動態設計系統”，將標準化組件視為語言中的“單詞”，作為設計態約束，然後在運行態組合，即調用這些“組件單詞”來動態生成“界面句子”。

生成式開發平台需要維護一個龐大的“原子化能力池”，包含基礎的原子組件（Design System）和可複用的“業務技能”（Agent Skills）。通過定義這些原子化能力，使得 AI 能夠使用原子組件進行渲染，實時組裝出一個可用的小程序，而不會退化為純文本，從而解決設計態預設覆蓋率不足的問題。

6.1.3 保證品牌一致性與 UI 規範

如果讓 AI 隨意生成，它可能在佈局、色彩和交互上偏離企業的品牌規範，導致“樣式失控”和用户認知混亂。生成式開發平台通過將設計系統轉化為 AI 的“系統提示詞”，或者通過“UI 規範知識庫”等方式，將品牌規範注入模型的上下文中，形成一個“安全護欄”，從而確保 AI 生成的 UI 結構和樣式始終符合企業的品牌規範。

6.1.4 提升 AI 推理的效率和質量

沒有平台規劃的 AI 可能會浪費大量的 Token 和算力來生成冗餘或低效的代碼。生成式開發平台將組件和邏輯動作封裝為 Agent Skills，AI 不再是在自由地寫代碼，而是在“調用能力”。這大幅減少了 AI 的“決策複雜度”與 Token 消耗，確保最終生成的界面代碼具備高性能與可維護性，提升整體推理效率與輸出質量。

6.2 低代碼平台的新角色

傳統低代碼平台致力於構建“長效、穩定”的應用（如企業 CRM 系統），其界面結構與業務流程在發佈週期內基本固定，用户需適應預設的導航與操作路徑。

在生成式 UI 的驅動下，低代碼平台正經歷根本性變革：其核心角色從“可視化搭建工具”轉變為“意圖驅動的實時開發平台”。平台在設計態維護一個豐富的原子化能力池（含組件、業務技能與數據連接器）；在運行態則根據用户自然語言意圖（例如分析銷售數據並預測趨勢）實時組裝出功能完整的小程序界面（包含圖表、篩選器與導出面板等）。任務完成後，該界面可自動銷燬，將應用的“生命週期”從年月級縮短至分鐘級。

6.2.1 自然語言替代拖拽

傳統的拖拽式低代碼平台雖然降低了編碼門檻，但在面對複雜業務場景時，其交互效率存在明顯的“邊際效應遞減”：

• 操作複雜度線性增長：構建一個包含 50 個字段的表單，用户至少需要進行 50 次拖拽操作，以及數百次屬性配置點擊。這種“物理操作”的累積導致了巨大的時間成本。
• 高維意圖的翻譯損耗：用户腦海中的意圖是“高維”的（例如，一個帶有審批流的請假單），但拖拽工具迫使會將這一意圖降維拆解為底層的“原子操作”（拖入容器、拖入文本框、設置標籤、綁定數據）。這種從“意圖”到“實現”的翻譯過程是低代碼開發中最耗神的部分。

生成式開發平台利用自然語言作為構建入口，能將操作複雜度大大降低。用户只需描述高維意圖，由大模型承擔繁瑣的拆解與配置工作，原因如下：

• 精準的語義理解：當前的 SOTA 模型（如 GPT-5, DeepSeek v3.1）在理解 UI 語義方面表現卓越。它們能夠準確地推斷出：收集用户反饋需要包含姓名、評分、意見和提交按鈕。
• 隱式需求的上下文推斷：大模型不僅能生成界面，還能根據上下文推斷“隱性需求”。例如，用户要求“創建一個面向老年人的頁面”，引擎會自動生成大字體、高對比度且交互簡單的界面，這是傳統拖拽工具無法自動實現的認知適應性。

6.2.2 通過畫布標註修改

自然語言的“模糊性”與 UI 的“精確性”存在天然矛盾。為此，平台引入“人在迴路”的交互修正機制。用户可在 AI 生成的初稿上直接“標註”（如圈選、批註），平台通過實時維護的 “DOM-DSL 映射表”，定位並僅將相關 DSL 片段與修改指令發送給模型，實現“局部增量更新”。這避免了全量重生成導致的“上下文丟失”，在體驗上實現了“所指即所得”的精準調控。下面是畫布標註的示例Demo：

6.2.3 應用的定義描述語言

傳統低代碼依賴 JSON 描述頁面結構，但在生成式場景中暴露明顯短板：

• Token 效率低下：JSON 語法中大量的花括號、引號和逗號佔用了寶貴的上下文窗口，且不承載任何業務語義。
• 流式傳輸的脆弱性：標準的 JSON.parse 方法要求輸入必須是完整閉合的字符串。在大模型“逐字流式輸出”的過程中，客户端無法實時解析一個“殘缺的 JSON”。雖然存在 json-river 等部分解析庫，但處理複雜的嵌套結構依然極其困難，容易導致渲染阻塞或失敗。
• 缺乏推理痕跡：JSON 只能描述結果，不能包含“思考邏輯過程”。

生成式開發平台，利用 Markdown 和 Agent Skills 替代 JSON，實現更優的表述與傳輸方案：

• Markdown 作為設計態載體：Markdown 的非結構化特性使其成為承載大模型“思維鏈”的最佳格式。平台的運行時渲染引擎應允許大模型在輸出具體的 UI 定義前，先輸出一段 Markdown 格式的“思考塊”，提供可解釋性和容錯性。
• Agent Skills 作為動態組件定義：這裏的 Agent Skills 可以理解為將低代碼平台中的組件和邏輯動作封裝為大模型可調用的工具或原子化能力。大模型不再是在“填空”（即填充 JSON），而是在“調用能力”。這使得 AI 能夠更靈活地組合組件，甚至在沒有預設模板的情況下創造出新的佈局組合。
• XML/JSX 流式渲染界面：在運行態，採用標籤結構明確的 XML 或類 JSX 語法進行流式輸出與渲染。解析器可在收到“開始標籤”時即刻創建容器框架，無需等待完整閉合，極大提升流式響應體驗。

6.2.4 生成式開發平台的架構

生成式開發平台的整體架構可概括為以下四個協同部分，如下圖所示：

• 生成式 UI 渲染引擎
  將大模型輸出的文本流，實時轉換為界面描述的 Schema 流，並渲染為包含智能組件的動態界面。
• 生成式小程序設計工具
  允許設計師通過自然語言描述小程序的頁面外觀與交互邏輯，AI 從生態中心獲取相關智能組件，結合描述自動生成小程序預覽。
• 生成式小程序運行引擎
  根據用户意圖，從生態中心資源池獲取小程序描述，並基於描述實時生成代碼並渲染，直接嵌入對話內容界面中。
• 生成式小程序生態中心
  匯聚垂直領域的智能組件資產，支持設計工具調用，保存設計工具發佈的小程序描述至資源池，為 AI 提供調用接口。

7. 設計師的角色跨越

設計行業正處於自圖形用户界面（GUI）誕生以來最為深刻的危機與機遇之中。長期以來，設計師與用户之間的“契約”建立在“確定性”的基礎之上：設計師在軟件發佈前的“設計態”預測用户需求，構建固定的導航路徑與靜態頁面，用户則在“運行態”通過適應這些預設路徑來達成目標。然而生成式 UI 技術的爆發，正在瓦解這一契約。

7.1 從靜態頁面到流體界面

在傳統的 GUI 設計中，設計師的核心產出物是“頁面”（Page）或“屏幕”（Screen）。通過線框圖定義佈局，通過視覺稿定義樣式，通過原型圖定義跳轉邏輯。這種工作流隱含了一個假設：能夠窮盡用户的所有使用場景。然而，這種預設性的 GUI 迫使用户適應軟件的邏輯，使得用户必須在複雜的菜單樹中“導航”，以逼近其真實意圖。生成式 UI 打破了這一假設。它引入了“按需生成，即用即棄”的概念，讓界面僅為當前的一個特定任務而生，任務完成後即刻銷燬。

在這種語境下，設計師不再設計最終的頁面，而是設計組件的“詞彙量”與組裝的“語法”。

• 從畫圖到定義元數據：設計師需要為每一個組件（圖表卡片、信息列表等）定義詳細的“語義描述”。這不僅包括它長什麼樣，更包括它能做什麼，以及什麼情況下該用它。例如，設計師需要明確定義：“當數據量超過 50 條且包含地理位置信息時，優先展示地圖組件，而非列表組件”。
• Vibe Coding 與氛圍設計：隨着 “Vibe Coding”（氛圍編碼）技術的興起，開發可以通過自然語言描述應用的功能，而設計師的工作則變成將感性的“形容詞”（Vibe）轉化為可被 AI 理解的“參數”（Design Tokens）。設計師需要建立一個“風格映射庫”，比如，定義“活力感”對應的是哪一套色彩飽和度、圓角半徑、動效曲線。

7.2 從導航到對話的交互維度

在靜態設計中，交互的核心是“導航”。設計師需要優化信息架構，確保用户能以最少的點擊找到功能。而在生成式 UI 中，交互的核心變成了“對話”與“意圖識別”，這對設計師的日常工作產生影響：

• 提示詞工程作為設計技能：設計師必須掌握“提示詞工程”，軟件生成的界面質量，很大程度上取決於系統提示詞的設計。設計師需要編寫類似這樣的指令：“你是一個專業的財務分析師助手。在展示虧損數據時，請使用中性的色彩，避免使用大面積的紅色引起用户恐慌，並優先展示改進建議而非純粹的負面數據”。這種自然語言的指令，實際上成為了新時代的 “CSS” 和“交互規範”。
• 空狀態的重新定義：在傳統設計中，空狀態是“邊緣情況”。在生成式 UI 中，“空狀態”（即用户輸入前的等待狀態）成為了主界面。設計師需要精心設計“引導性提示”，幫助用户建立對 AI 能力的正確“心理模型”。

7.3 監控埋點與意圖分析

傳統的頁面埋點分析工具是建立在頁面結構相對固定的基礎之上，如果頁面結構是“流動”的，那麼基於 DOM 元素的埋點將徹底失效。因此，設計師和數據分析師必須從監控“操作”轉向監控“意圖”：

• 意圖日誌：分析的原子單位不再是 Page View (PV)，而是 Intent Resolution (IR)。我們需要記錄：用户產生了查詢物流的意圖 -> 系統生成了物流地圖組件 -> 用户在組件上進行了縮放操作。
• 組件級分析：埋點需要下沉到“組件層級”。無論購買按鈕出現在頁面的左上角還是右下角，出現在模態彈窗裏還是側邊欄裏，它都必須攜帶統一的“語義標籤”。設計師在定義設計系統時，必須為每個組件預埋“遙測信標”。

在靜態頁面中，如果用户點擊了按鈕但沒反應，那是 Bug。在生成式 UI 中，如果用户看着生成的界面發愣，或者頻繁修改自己的輸入指令，那可能是 AI 的“設計幻覺”，即 AI 生成了一個不符合用户預期的界面。因此設計師需要關注的新維度：

• 提示詞修正率：用户在生成結果出來後，是否立即修改了自己的指令？（例如：我不是要表格，我要圖表”）。高修正率意味着 AI 的意圖理解或界面生成邏輯存在缺陷，這是設計師優化系統提示詞的關鍵線索。
• 組件廢棄率：如果 AI 經常生成“下載 PDF”的按鈕，但用户從來不點擊，或者點擊後報錯，這説明 AI 對系統能力的理解有誤。設計師需要分析這些“廢棄組件”，並在元數據中從 AI 的“工具箱”中移除或降權它們。
• 生成耗時與跳出率的相關性：生成式 UI 涉及大模型推理，會有顯著的延遲。設計師需要精細化分析“等待時間”對用户滿意度的影響。當“骨架屏”展示超過 2 秒且沒有實質內容流出時，用户焦慮感會指數級上升。這將直接指導設計師優化“加載態”的“情感設計”。

7.4 設計系統的適應性轉變

傳統的設計系統是一套靜態的積木。在生成式 UI 時代，這套積木必須變得可被 AI 理解且“防呆”。

7.4.1 從原子設計到神經符號

傳統原子設計關注的是視覺層級的嵌套（原子 -> 分子 -> 組織）。生成式 UI 需要引入“神經符號”架構：

• 神經層：負責“靈活性”。允許 AI 根據用户意圖，創造性地組合組件。例如，AI 決定將圖表和聊天框並排顯示。
• 符號層：負責“約束性”。這是設計系統的“憲法”。無論 AI 如何發揮，它必須遵守設計師定下的“硬性規則”。例如：“錯誤提示必須是紅色的”，“主操作按鈕在移動端必須吸底”。

生成式 UI 還需要設立度量模型的新維度：

• 組件覆蓋率：這是一個全新的關鍵指標。它衡量的是用户的自然語言意圖有多少能被現有的 UI 組件承接。如果用户想要日曆視圖，但設計系統裏只有列表視圖，AI 就只能退化為生成純文本。設計師需要通過監控這一指標，識別組件庫的缺口，防止掉入“覆蓋率陷阱”。
• Schema 魯棒性：設計師需要與工程師緊密合作，為每個組件定義 Zod Schema 或 TypeScript 接口。度量維度變成了：Schema 的約束是否足夠嚴格，以防止 AI 傳入錯誤的數據類型（例如給圖片組件傳了文本），同時是否足夠靈活，能適應不同的上下文。

7.4.2 品牌一致性的護欄設計

當頁面由 AI 生成時，最大的風險是“品牌失控”。設計師的工作重心從產出頁面轉向制定“護欄”。

• 風格注入：利用業務知識庫等技術，設計師需要將品牌規範轉化為 AI 的“系統提示詞”。
• 負向約束：設計師不僅要告訴 AI 做什麼，還要明確告訴它“不做什麼”。例如：“永遠不要在同一個頁面展示超過 3 個主操作按鈕”、“不要在深色背景上使用黑色文字”。這些規則需要被編碼進設計系統的“校驗層”，在 UI 渲染給用户之前進行自動攔截。

8. 結論與展望

通過對生成式 UI 技術的深入研究，我們得出以下結論：

• 技術演進的必然性：生成式 UI 技術的出現標誌着軟件架構從“以應用為中心”向“以意圖為中心”的範式轉移。未來，傳統應用的界面將逐漸“隱形”，取而代之的是由 AI 即時生成的、高度個性化的微型交互單元。
• 企業智能化的加速器：對於深受遺留系統困擾的企業而言，生成式小程序提供了一條“最具性價比”的智能化之路。它不需要推翻重建核心系統，而是通過 API 編排和視覺控制，為舊系統“穿上新衣”。它讓企業能夠以分鐘級的速度構建內部工具，以自動化代理重構業務流程，從而實現生產效率的數量級提升。

展望未來五到十年，我們可能會迎來“無應用時代”。用户不再需要下載安裝成百上千個 App。每個企業只需維護一套核心的能力 API 和業務知識庫。當用户（無論是員工還是客户）產生需求時，一個超級 AI 助理會即刻調用各方能力，實時生成一個專屬的小程序來解決問題。

在這個新時代，企業的核心競爭力不再是擁有多少個 App 或者 UI 界面，而是其業務能力的 API 化程度、知識的數字化程度以及 AI Agent 的治理能力。生成式 UI，正是通往這個未來的第一張船票。

關於OpenTiny

歡迎加入 OpenTiny 開源社區。添加微信小助手：opentiny-official 一起參與交流前端技術～

OpenTiny 官網：https://opentiny.design
OpenTiny 代碼倉庫：https://github.com/opentiny
TinyVue 源碼：https://github.com/opentiny/tiny-vue
TinyEngine 源碼： https://github.com/opentiny/tiny-engine
歡迎進入代碼倉庫 Star🌟TinyEngine、TinyVue、TinyNG、TinyCLI、TinyEditor~
如果你也想要共建，可以進入代碼倉庫，找到 good first issue 標籤，一起參與開源貢獻~