當AI不再只會聊天，生成式UI來了！這個開源框架讓React應用秒變AI原生

你有沒有發現，現在幾乎每個軟件都在瘋狂添加AI聊天功能？打開任何一個產品，右下角必然有個閃爍的聊天圖標。你點進去，問一個問題，AI給你回復一大段文字。然后呢？你還是得自己回到界面上，點擊那些按鈕，填寫那些表單，完成你想做的事。這個所謂的AI助手，只是把用戶手冊用自然語言復述了一遍而已。

我最近一直在思考一個問題：為什么我們要把AI困在一個聊天框里？人類使用軟件的方式從來不是只靠文字描述。我們需要看到圖表、操作表格、填寫表單、拖拽組件。當我問"上個月的銷售數據怎么樣"時，我真正想要的不是一段文字告訴我"銷售額增長了15%"，我想要的是一個可交互的圖表，讓我能立刻看到趨勢、篩選區域、對比不同產品線。文字描述永遠無法替代真實的UI交互。

這就是為什么當我看到Tambo 1.0發布時，我意識到軟件界面正在經歷一場根本性的范式轉變。這不是又一個AI聊天機器人工具，而是一個讓AI能夠真正操控和渲染UI組件的框架。它的創始人Michael Milstead和Michael Magan在一次黑客松上相遇后，就開始癡迷于一個想法：我們使用的應用應該適應我們想要做的事情，而不是強迫我們學習它們的結構。這聽起來很理想化，但他們真的做出來了。

傳統AI界面的根本缺陷

我想先聊聊為什么當前這波AI聊天界面的熱潮本質上是有缺陷的。過去兩三年，我用過無數個號稱"AI賦能"的產品。它們的模式都一樣：在原有產品上硬塞一個聊天窗口，接入GPT或Claude，然后就宣稱自己是AI原生應用了。但用戶的反應如何？他們試用一次就再也不回來了。

問題的核心在于，文字不是人們使用應用的方式。想象一下你在訂機票。傳統AI會告訴你"23E座位可用"。但這個信息對你來說毫無意義。這是靠窗還是過道？是中間座位嗎？附近有沒有空行？離廁所近不近？你腦海中浮現出一堆問題，然后還得繼續問AI，或者干脆放棄，自己去點開座位圖查看。

但如果AI直接給你渲染一個座位圖呢？你瞬間就能看到23E的位置，周圍座位的占用情況，甚至可以直接在這個座位圖上點選你想要的座位。這就是UI的力量。一張圖勝過千言萬語，一個可交互的組件更是勝過無數輪對話。

從Indeed的雇主分析工具，到Convoy的卡車司機搜索產品，再到各種開發者工具。每一家公司都面臨同樣的核心問題，而且我們用同樣的老辦法解決了30年。那就是功能發現的問題：如何在正確的時間把正確的功能展示給正確的用戶？我們在會議室里花費了無數小時討論導航欄、菜單結構、哪個功能應該放在哪里。我們永遠都做不對。因為根本就沒有一個完美的靜態結構能滿足所有用戶。

另一個長期困擾產品團隊的問題是用戶層次的悖論。你想讓界面簡單到新手能立刻上手，但同時又要滿足高級用戶對復雜功能的需求。大多數現代應用只能在這兩個極端中選一個。要么做一個功能簡陋但易用的入門版，要么做一個功能強大但需要大量培訓的專業版。這種權衡是痛苦的，而且往往意味著你會失去一半的潛在用戶。

我們怎么解決這些問題的？寫文檔。做培訓。錄視頻教程。安排專人講解產品使用方法。這些方法能用，但效率極低，成本極高。更關鍵的是，它們把學習成本完全轉嫁給了用戶。我們本質上是在說："這是我們的產品，你們自己花時間學吧。"

Generative UI的真正含義

當人們談論"generative UI"時，往往在說不同的東西。有人認為是讓LLM實時生成前端代碼。有人認為是動態生成HTML。這兩種方法都有它們的應用場景，但對于大多數實際應用來說，有一條更好、更可靠的路徑。

我理解的generative UI，是一種能夠根據用戶上下文實時適應的界面。這個上下文包括用戶的自然語言輸入、他們過去的交互歷史、系統數據等等。不再是一個固定的、所有人都必須學習的體驗，而是軟件學會了適應每個用戶在當下時刻的需求。

這里有個很關鍵的類比。AI代碼生成就像每次都從零開始制造塑料零件。你需要設計模具、加熱材料、等待固化。每一次都這樣。而使用預定義組件就像樂高積木。工程師們把積木塊設計好、測試好，確保它們可靠耐用，隨時可以拼接。AI只是把它們組裝成用戶需要的樣子。

我們不會期望AI為每個操作都生成代碼，對吧？我們給它們工具，比如MCP協議，來幫助執行任務。同樣的邏輯也適用于UI。當你已經有了設計精良的組件時，為什么還要讓AI從零開始生成UI代碼？那樣做不僅慢，而且容易出錯，可能漏掉HTML標簽，可能產生不一致的樣式，可能引入安全漏洞。

Tambo采用的就是這種組件模型。你構建帶有類型化props和schemas的UI組件。比如一個折線圖、一個航班選擇器、一個預填充的表單。AI的工作是選擇使用哪些組件以及如何配置它們。LLM填充圖表數據、選擇可用的航班、為具體情況設置最佳的表單默認值。用戶得到的是個性化的界面，但不需要定制代碼。

這種方法帶來了巨大的優勢。你獲得了用戶想要的靈活性，但沒有實時生成代碼的風險。你的組件是經過測試的、可靠的。它們遵循你的設計系統。它們有適當的錯誤處理。它們經過了性能優化。這些都是從頭生成UI代碼無法保證的。

Tambo如何解決這個難題

Tambo的核心創新在于它找到了一條讓現有應用快速獲得generative UI能力的路徑。這點非常關鍵，因為沒有公司會為了試驗一個新概念而重寫整個應用。Tambo讓你能用現有的React組件，通過簡單的注冊過程，就能讓AI agent理解和使用它們。

工作原理其實很直觀。你注冊現有的React組件到Tambo。當用戶發出請求時，agent選擇合適的組件，流式傳輸props數據，然后渲染出來。用戶說"顯示我最近的訂單"，他們得到的是你真實的OrderTable組件，已經正確篩選過的，而不是一堆Markdown格式的文字。

但Tambo不只是一個客戶端SDK。它是一個托管后端，處理對話線程、agent執行、認證和狀態管理。你不需要自己搭建agent框架或運行agent基礎設施。Agent已經包含在內了。把它放進你的React應用，就可以發布了。

這里有個很多人想不到的復雜性：狀態管理。假設你的組件有狀態，比如一個篩選器、一個表單值、一個開關。Agent渲染了這個組件,然后用戶修改了它。Agent知道新的值嗎？當用戶重新加載對話線程時，這個值會怎樣？Agent也能更新它嗎？如果對話中有三個相同組件的實例怎么辦？Agent能更新所有的，還是只能更新最新的？你如何通過一個在React組件中感覺自然的接口暴露所有這些？

再想想流式渲染的問題。Agent選擇了一個組件并開始生成props。它們不是一次性到達的。你需要在props還不完整的情況下渲染出有意義的東西，避免界面閃爍，還要處理流式傳輸中途出錯的情況。這些聽起來簡單，但合在一起就變得非常復雜。所有這些問題都必須解決，AI應用才能真正可用。

更麻煩的是技術生態在不斷變化。你想支持MCP，現在你需要實現elicitation、sampling、tool discovery。每個新協議都意味著在回到實際產品開發之前，你要先做大量基礎工作。這些細節看似瑣碎，實際上會困住團隊好幾個月，有些團隊甚至永遠無法投入生產。

Tambo把這些都處理好了。他們在代碼庫中解決了這些邊緣情況。他們支持MCP的完整功能集，不只是工具調用，還包括resources、prompts、elicitations。如果你熟悉MCP，你會知道這意味著什么。對于開發者來說，這意味著你可以專注于構建真正獨特的功能，而不是重新發明輪子。

看看早期用戶的反饋。Solink的高級全棧工程師Jean-Philippe Bergeron說："Tambo簡直太容易上手了，這就是你如何在幾分鐘內從前端到后端搭建一個完整聊天機器人的方法。我周五把它接入UI，周一就演示給團隊看了。"這種速度是革命性的。從想法到可演示的原型，只需要一個周末。

為什么現在是關鍵時刻

我觀察到一個有趣的現象。Tambo的GitHub倉庫已經有8000多個star。Zapier、Rocket Money、Solink這些公司都在用Tambo構建generative UI。已經有超過50萬條用戶消息被處理。這種關注度不是偶然的。

整個行業正在趨同于一個共識：AI agent應該渲染真實的UI，而不是文字。新的規范每周都在出現。Anthropic的MCP Apps、Google的A2UI、Vercel的json-render。但規范不等于實現。開發者在構建這些體驗時不斷得出同樣的結論：他們需要一個可以直接放進應用的工具包。Tambo就是為此而生。

我認為我們正處在一個技術拐點。過去兩年，大家都在玩AI聊天界面。每個公司都想證明自己"有AI能力"。但現在用戶已經不買賬了。他們試過了，發現聊天框解決不了實際問題。他們需要的是能真正幫他們完成任務的工具，而不是另一個會說話的機器人。

Generative UI代表了下一個階段。它解決了聊天界面的根本缺陷：缺乏可視化、缺乏交互性、缺乏上下文。當軟件能夠根據你的需求動態組裝界面時，學習曲線急劇下降，生產力大幅提升。新手用戶能立刻開始做事，高級用戶保留了全部控制權。

讓我用一個具體例子來說明。傳統的電子表格要求用戶預先學習。公式、單元格引用、圖表配置。學習曲線陡峭，很多人永遠學不會。但有了generative UI，用戶從自然語言開始。用戶說"計算這些數據的復合年增長率"。AI自動選擇相關單元格、應用公式、格式化結果、創建可視化。復雜性仍然存在，但它是漸進式揭示的，只在需要時才出現。新手立刻開始使用，專家仍然擁有完全控制權。

我看過Tambo團隊在會議上的演示。他們展示了一個基于Strudel（一種音樂編程語言）構建的應用。開發者在入職第一周就做出來了。Strudel本身是一個強大但復雜的工具，需要理解音樂理論和編程概念。但通過generative UI，完全不懂音樂的人可以說"給我生成一段歡快的節奏"，然后立刻得到可播放、可修改的音樂代碼。用戶可以繼續通過自然語言調整，也可以直接編輯代碼參數。兩種方式無縫結合。

這種交互模式打破了"簡單易用"與"功能強大"之間的傳統權衡。界面可以既強大又易用，因為復雜性是按需顯示的。用戶不需要事先知道所有功能在哪里，他們只需要表達想做什么，界面就會適應他們的需求。

這意味著什么

如果generative UI真的成為主流，軟件開發會發生什么變化？我認為這不是一個小調整，而是整個范式的轉變。

開發者的工作重心會改變。過去我們花大量時間設計完美的導航結構、優化信息架構、做用戶測試來確保界面直觀。這些工作不會完全消失，但重要性會大大降低。相反，我們會更多關注組件設計和API設計。你的組件需要足夠靈活，能夠應對各種可能的使用場景。你的API需要清晰明確，讓AI能夠理解何時調用以及如何調用。

有個來自Spendflo的CTO的評論很能說明問題。他說："Adopt從根本上改變了我們思考產品構建的方式。它讓我們更快進入市場，完全控制AI行為，在不需要重建任何東西的情況下實現了產品功能的全面覆蓋。它完全適配我們現有的基礎設施，規范了我們設計API的方式，讓我們能專注于核心產品開發，而讓工具處理AI的繁重工作。"注意"規范了API設計"這個表述。Generative UI迫使你更認真地思考你的數據模型和接口設計。

產品設計的思路也會轉變。不再是設計屏幕流程和點擊路徑，而是設計可能的用戶意圖和相應的響應。設計師需要思考：用戶可能如何描述他們想做的事？在不同上下文下，什么是最合適的UI響應？這個組件應該暴露哪些配置選項給AI？

對企業來說，這解決了一個長期困擾他們的問題：軟件投資回報率。企業花費數百萬購買復雜的SaaS產品，但員工只用了其中一小部分功能。不是因為其他功能不好，而是因為沒人知道它們的存在，或者覺得學習成本太高。Generative UI讓所有功能都變得可訪問。用戶不需要知道功能藏在哪個菜單的第三級子項里，他們只需要描述想做什么，軟件就會調用相應功能。

這也改變了軟件培訓的經濟學。傳統上，企業需要投入大量資源培訓員工使用復雜軟件。培訓師、文檔、視頻教程、在線課程。這些成本加起來非常可觀。但如果軟件能夠理解自然語言并自動組裝所需界面，培訓需求會大幅下降。新員工的上手時間從幾周壓縮到幾小時甚至幾分鐘。

我還注意到一個更深層的變化：軟件使用的民主化。現在，很多強大的工具只有技術人員才能充分利用。數據分析工具、開發工具、設計工具，都需要專業知識。但generative UI降低了這個門檻。一個銷售人員不需要學習SQL就能查詢數據庫。一個市場人員不需要懂代碼就能定制報表。技術不再是使用強大工具的前提條件。

實踐中的挑戰

當然，任何新技術都不是完美的。我在思考generative UI的未來時,也看到了一些需要解決的挑戰。

可靠性是最大的問題之一。當AI選擇組件和填充props時，它可能會犯錯。選錯組件、填錯數據、誤解用戶意圖。在關鍵業務場景中，這種錯誤的代價可能很高。這就是為什么Tambo強調給開發者完全的控制權。你可以精細調整agent的行為、在沙盒環境中測試、設置驗證規則。但歸根結底，LLM的非確定性意味著你永遠無法保證100%正確。

狀態同步是另一個復雜問題。當用戶通過自然語言和直接UI操作混合交互時，保持所有狀態同步變得非常困難。用戶讓AI渲染了一個表單，然后手動修改了某些字段，又通過對話要求更新其他字段。整個系統需要追蹤所有這些變化，確保UI狀態、對話上下文和后端數據都保持一致。Tambo的useTempoState就是為了解決這個問題，但這仍然是個需要仔細處理的領域。

性能也是考慮因素。實時生成和渲染UI組件比簡單返回文本要慢。雖然Tambo使用流式傳輸來緩解這個問題，讓組件在props完全到達之前就開始渲染，但仍然會有延遲。用戶會接受這個延遲嗎？特別是當他們習慣了即時響應的傳統UI時。

還有學習曲線的問題。雖然generative UI的目標是降低軟件使用的學習曲線，但用戶仍然需要學習如何有效地與AI交流。什么樣的請求會得到好的結果？如何描述復雜的需求？如何利用上下文讓AI做出更好的判斷？這是一種新的技能，需要時間培養。

隱私和安全也需要仔細考慮。當AI能夠訪問和操作用戶數據時，必須有嚴格的權限控制。哪些數據可以被AI讀取？哪些操作可以被AI執行？如何防止AI被誘導執行不安全的操作？Tambo提供了工具和MCP協議的集成來處理這些問題，但最終還是需要開發者做出明智的決策。

開源的力量

Tambo選擇完全開源是一個重要決定。整個代碼庫在GitHub上可見，你可以fork、修改、自己托管。這不僅僅是一個營銷策略，它反映了構建這類基礎技術的正確方式。

開源意味著透明。開發者可以看到agent是如何工作的，組件是如何被選擇的，狀態是如何管理的。這種透明度對于建立信任至關重要，特別是在處理敏感數據或關鍵業務邏輯時。你不是在盲目信任一個黑盒，你可以審查代碼，理解機制，甚至根據需要進行修改。

開源也加速了創新。已經有8000多名開發者給倉庫點了star。這些開發者會發現bug、提出改進建議、貢獻新功能。社區的智慧遠超過任何一個公司的工程團隊。Tambo的創始人在演講中明確表示："我們在公開環境中構建，因為這個社區讓產品更好。"

更重要的是，開源讓Tambo成為了一個平臺而不只是一個產品。開發者可以基于它構建自己的工具、創建新的組件庫、開發特定行業的解決方案。這種生態系統效應是閉源產品很難實現的。

同時，Tambo也提供托管服務。你可以選擇自己托管，完全控制基礎設施，或者使用他們的云環境，獲得開箱即用的體驗。這種混合模式給了用戶最大的靈活性。初創公司可以快速啟動，不用擔心基礎設施。大企業可以自己托管，滿足合規要求。現在Tambo 1.0已經通過了SOC 2和HIPAA認證，這意味著它可以用于受監管的行業。

我的展望

我相信generative UI不是一個短暫的趨勢，而是軟件界面發展的下一個重要階段。就像圖形用戶界面取代了命令行、觸摸界面重新定義了移動體驗，generative UI將重新定義我們與復雜軟件交互的方式。

未來五年內，我預計會看到越來越多的企業軟件采用這種模式。不是作為附加功能，而是作為核心交互方式。那些早期采用的公司會獲得顯著的競爭優勢：更高的用戶采用率、更低的培訓成本、更好的用戶滿意度。

我也預計會看到新的設計模式和最佳實踐的出現。現在我們還在探索階段，每個團隊都在摸索什么方法有效。但隨著更多公司采用generative UI，行業會逐漸形成共識。哪些類型的組件最適合AI操控？如何設計清晰的props schema？怎樣平衡靈活性和約束？這些問題的答案會逐漸清晰。

Tambo在這個過程中處于獨特的位置。作為開源項目，它能夠吸收整個社區的智慧。作為已經被實際公司使用的產品，它經過了真實場景的檢驗。作為一個專注于React生態的工具，它能夠深度整合現有的開發工作流。

但我認為最重要的是,Tambo代表了一種思維方式的轉變。不再是"我們怎么讓用戶學會使用我們的軟件"，而是"我們怎么讓軟件學會理解用戶的需求"。這種轉變看似微妙，實則深刻。它改變了我們設計、開發和思考軟件的整個方式。

軟件不應該是用戶必須征服的工具，而應該是理解用戶意圖并幫助他們實現目標的合作伙伴。點擊界面的時代建立在一個假設上：用戶應該學習軟件的語言。Generative UI建立在一個新的假設上：軟件應該學習用戶的語言。這不只是技術的進步，更是哲學的轉變。

當我看到一個完全不懂音樂的人能夠通過Tambo驅動的Strudel應用在幾分鐘內創作出音樂，當我看到銷售人員能夠用自然語言查詢復雜的數據分析，當我看到新員工能夠在第一天就使用企業軟件的高級功能，我知道這不是科幻小說，而是正在發生的現實。界面正在從我們需要學習的東西，轉變為能夠學習我們的東西。

結尾

也歡迎大家留言討論，分享你的觀點！

覺得內容不錯的朋友能夠幫忙右下角點個贊，分享一下。您的每次分享，都是在激勵我不斷產出更好的內容。

歡迎關注深思圈，一起探索更大的世界。