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

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

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

傳統(tǒng)AI界面的根本缺陷

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

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

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

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

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

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

Generative UI的真正含義

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

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

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

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

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

這種方法帶來了巨大的優(yōu)勢。你獲得了用戶想要的靈活性，但沒有實時生成代碼的風(fēng)險。你的組件是經(jīng)過測試的、可靠的。它們遵循你的設(shè)計系統(tǒng)。它們有適當(dāng)?shù)腻e誤處理。它們經(jīng)過了性能優(yōu)化。這些都是從頭生成UI代碼無法保證的。

Tambo如何解決這個難題

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

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

但Tambo不只是一個客戶端SDK。它是一個托管后端，處理對話線程、agent執(zhí)行、認證和狀態(tài)管理。你不需要自己搭建agent框架或運行agent基礎(chǔ)設(shè)施。Agent已經(jīng)包含在內(nèi)了。把它放進你的React應(yīng)用，就可以發(fā)布了。

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

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

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

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

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

為什么現(xiàn)在是關(guān)鍵時刻

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

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

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

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

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

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

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

這意味著什么

如果generative UI真的成為主流，軟件開發(fā)會發(fā)生什么變化？我認為這不是一個小調(diào)整，而是整個范式的轉(zhuǎn)變。

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

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

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

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

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

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

實踐中的挑戰(zhàn)

當(dāng)然，任何新技術(shù)都不是完美的。我在思考generative UI的未來時,也看到了一些需要解決的挑戰(zhàn)。

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

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

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

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

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

開源的力量

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

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

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

更重要的是，開源讓Tambo成為了一個平臺而不只是一個產(chǎn)品。開發(fā)者可以基于它構(gòu)建自己的工具、創(chuàng)建新的組件庫、開發(fā)特定行業(yè)的解決方案。這種生態(tài)系統(tǒng)效應(yīng)是閉源產(chǎn)品很難實現(xiàn)的。

同時，Tambo也提供托管服務(wù)。你可以選擇自己托管，完全控制基礎(chǔ)設(shè)施，或者使用他們的云環(huán)境，獲得開箱即用的體驗。這種混合模式給了用戶最大的靈活性。初創(chuàng)公司可以快速啟動，不用擔(dān)心基礎(chǔ)設(shè)施。大企業(yè)可以自己托管，滿足合規(guī)要求?，F(xiàn)在Tambo 1.0已經(jīng)通過了SOC 2和HIPAA認證，這意味著它可以用于受監(jiān)管的行業(yè)。

我的展望

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

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

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

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

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

軟件不應(yīng)該是用戶必須征服的工具，而應(yīng)該是理解用戶意圖并幫助他們實現(xiàn)目標的合作伙伴。點擊界面的時代建立在一個假設(shè)上：用戶應(yīng)該學(xué)習(xí)軟件的語言。Generative UI建立在一個新的假設(shè)上：軟件應(yīng)該學(xué)習(xí)用戶的語言。這不只是技術(shù)的進步，更是哲學(xué)的轉(zhuǎn)變。

當(dāng)我看到一個完全不懂音樂的人能夠通過Tambo驅(qū)動的Strudel應(yīng)用在幾分鐘內(nèi)創(chuàng)作出音樂，當(dāng)我看到銷售人員能夠用自然語言查詢復(fù)雜的數(shù)據(jù)分析，當(dāng)我看到新員工能夠在第一天就使用企業(yè)軟件的高級功能，我知道這不是科幻小說，而是正在發(fā)生的現(xiàn)實。界面正在從我們需要學(xué)習(xí)的東西，轉(zhuǎn)變?yōu)槟軌驅(qū)W習(xí)我們的東西。

結(jié)尾

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

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

歡迎關(guān)注深思圈，一起探索更大的世界。