30秒加載逼走用戶后，他們用流式UI把AI生成時間砍到0.3秒

「用戶點擊生成，盯著轉(zhuǎn)圈30秒，等幻燈片出來時，他們已經(jīng)新開標(biāo)簽頁去查郵件了。」PitchShow創(chuàng)始人復(fù)盤第一版產(chǎn)品時，這句話被團隊寫進了技術(shù)債務(wù)清單的頂部。

2024年初，這家AI演示文稿工具創(chuàng)業(yè)團隊踩中了一個集體幻覺：大語言模型（LLM，Large Language Model，大型語言模型）返回JSON，前端渲染成幻燈片，完事。結(jié)果首批用戶留存率慘到連內(nèi)部匯報都羞于展示。

問題不在AI，而在架構(gòu)思維——他們把流式生成的模型響應(yīng)，當(dāng)成了數(shù)據(jù)庫查詢來處理。

從"整段緩沖"到"邊播邊用"

傳統(tǒng)CRUD（增刪改查）應(yīng)用的慣性很隱蔽。開發(fā)者習(xí)慣了"請求-等待-完整響應(yīng)"的閉環(huán)，這種模式在2023年前是標(biāo)準(zhǔn)答案。但LLM的token是逐字吐出來的，等待完整響應(yīng)就像YouTube緩沖完整個視頻才允許點擊播放。

PitchShow團隊重新拆解了"生成演示文稿"這個動作的本質(zhì)。用戶真正需要的是什么？不是一份等待30秒后突然出現(xiàn)的完整文件，而是即時反饋+漸進可用的內(nèi)容。

他們最終落地的方案是三層流式架構(gòu)：React服務(wù)端組件（RSC，React Server Component）處理首屏渲染，Server-Sent Events（SSE，服務(wù)器發(fā)送事件）傳輸增量數(shù)據(jù)，客戶端組件負責(zé)漸進式UI更新。

數(shù)據(jù)流向變成：用戶輸入提示詞→服務(wù)端啟動LLM流→token到達后立即解析為幻燈片元素→SSE推送到客戶端→React Suspense邊界捕獲并渲染。

服務(wù)端組件：把重活留在云端

RSC的關(guān)鍵價值在于零客戶端JavaScript負擔(dān)。AI生成的內(nèi)容往往包含Markdown解析、代碼高亮、圖表數(shù)據(jù)轉(zhuǎn)換——這些計算密集型任務(wù)被留在服務(wù)端執(zhí)行，瀏覽器只接收最終的HTML片段。

具體實現(xiàn)上，PresentationPage作為異步服務(wù)端組件，直接在服務(wù)器上await生成流，將流對象傳遞給客戶端的PresentationStream組件。這種模式消除了useEffect瀑布：不再需要組件掛載后發(fā)起請求、等待響應(yīng)、狀態(tài)更新、重新渲染的鏈條。

延遲被壓縮到物理極限——數(shù)據(jù)在離數(shù)據(jù)源最近的地方被處理，而非跨越網(wǎng)絡(luò)往返多次。

SSE與漸進披露：讓用戶有事可做

Server-Sent Events選得很克制。相比WebSocket的雙向開銷，SSE的單向通道恰好匹配LLM推理的單向輸出特性。連接建立后，服務(wù)端以text/event-stream格式推送增量數(shù)據(jù)，客戶端通過EventSource API監(jiān)聽。

漸進披露（progressive disclosure）的策略被細化到幻燈片級別：

標(biāo)題先生成？立即渲染占位卡片。正文流式到達？逐段填充。圖表數(shù)據(jù)最后出現(xiàn)？先展示文本框架，再動態(tài)注入可視化。用戶在第3秒就能看到第一張可編輯的幻燈片，而非第30秒面對10張一次性彈出的頁面發(fā)呆。

這種體驗差異直接反映在行為數(shù)據(jù)上：生成過程中的頁面跳出率從67%降至4%，平均編輯啟動時間從28秒縮短到0.3秒。

2026年的默認配置

流式UI正在成為AI原生應(yīng)用的基線。ChatGPT的對話逐字呈現(xiàn)、Claude的代碼塊實時高亮、Cursor的補全幽靈文本、Google vibe coding工具的漸進預(yù)覽——這些產(chǎn)品的共同選擇不是巧合。

React的架構(gòu)演進恰好踩中了這個節(jié)點。Server Components的"服務(wù)端優(yōu)先"理念，Suspense的異步邊界處理，以及與現(xiàn)代流式傳輸協(xié)議的配合，讓漸進式渲染從hack變成正統(tǒng)。

PitchShow團隊內(nèi)部有個說法：用戶不會記得你用了什么技術(shù)，但會記得那種"還沒反應(yīng)過來就已經(jīng)能用"的流暢感。第一代產(chǎn)品的30秒轉(zhuǎn)圈，本質(zhì)上是在懲罰用戶的耐心；而流式架構(gòu)把等待本身轉(zhuǎn)化成了內(nèi)容消費的一部分。

技術(shù)債清單上的那條記錄現(xiàn)在被劃掉了，旁邊補了一行新注釋：「架構(gòu)即產(chǎn)品體驗，延遲是設(shè)計問題。」

當(dāng)生成時間從30秒壓縮到300毫秒，用戶的行為模式也隨之改變——他們開始把AI生成當(dāng)作實時協(xié)作，而非后臺任務(wù)。一個被忽略的細節(jié)是：流式傳輸讓"取消生成"變得有意義，用戶可以在看到前三張幻燈片風(fēng)格不對時立即中斷，而非等待完整結(jié)果后全盤否定。這個交互細節(jié)的埋點數(shù)據(jù)顯示，主動取消率12%，但取消后的重新生成轉(zhuǎn)化率高達89%。

如果生成過程本身成為產(chǎn)品體驗的一環(huán)，那么"加載中"這個狀態(tài)是否還有存在的必要？