30秒生成1份PPT，用戶卻集體跳車：AI工具踩了哪3個坑

我們第一版產品上線時，生成一份演示文稿要30秒。用戶點擊按鈕，盯著轉圈動畫，等幻燈片出現時，他們早就新開標簽頁查郵件去了。問題不在AI，在我們對"生成"這件事的理解還停留在2019年。

這篇文章講我們怎么修好的。不是靠新框架或神級庫，而是重新想明白：2026年做AI演示工具，"生成"到底意味著什么。

答案不是批處理，是流式界面（Streaming UI）。

批處理思維是怎么害死產品的

如果你用過AI演示工具，應該熟悉這個流程：輸入主題→等待→收到完整JSON→渲染整份幻燈片。這套模式做CRUD應用時沒問題，但LLM（大語言模型）是逐字吐token的，等完整響應再展示，就像YouTube緩沖完整個視頻才允許播放。

我抓住技術負責人問："為什么我們把AI響應當數據庫查詢處理？"

流式界面不只是文字實時出現。核心是漸進式披露——信息可用時立即呈現，且對用戶當下就有用。對演示文稿來說，這意味著：先生成標題讓用戶確認方向，再逐頁流出內容，邊生成邊渲染，而非最后一次性彈出10頁。

2026年這個模式無處不在：ChatGPT、Claude、Cursor AI，甚至Google的新vibe coding工具。React的架構，尤其是服務端組件（Server Components），恰好完美適配。

三層漸進架構：數據怎么流起來

我們最終確定的流程分三層：服務端生成流→SSE傳輸→客戶端漸進渲染。數據從服務端流向客戶端，逐層遞進，而非打包投遞。

React服務端組件（RSC）讓我們在服務端渲染組件，不把JavaScript發往客戶端。這對AI生成內容至關重要——內容常包含Markdown、需要清理的HTML、甚至圖表數據。與其把這些邏輯塞進客戶端，不如服務端處理：

// app/generate/[id]/page.tsx
async function PresentationPage({ params }: { params: { id: string } }) {
// 這段在服務端運行
const stream = await generatePresentation(params.id);
return ;
}

關鍵洞察：數據獲取貼近數據源，降低延遲。再也不用"mount時用useEffect取數據"的瀑布流了。

我們用SSE（服務端發送事件）把數據從AI管道推到客戶端：

// lib/presentation-stream.ts
export async function* generatePresentation(prompt: string) {
const llmStream = await openai.chat.completions.create({
model: "gpt-4-turbo",
messages: [{ role: "user", content: prompt }],
stream: true,
});
let currentSlide = "";
for await (const chunk of llmStream) {
// 逐塊處理，實時推送給客戶端
}
}

漸進渲染：讓用戶提前參與進來

客戶端用Suspense邊界包裹每個幻燈片組件。服務端流到達時，對應幻燈片從骨架屏漸變為完整內容。用戶看到的不是30秒白屏，而是1秒內出現標題，3秒看到第一頁，10秒拿到完整大綱。

有個細節我們踩過坑：早期版本每收到一個token就重渲染，結果CPU飆高、界面卡頓。后來改成50ms批處理窗口，平衡了實時感和性能。

另一個教訓是錯誤處理。流式傳輸中，服務端可能在第8頁崩潰。我們學會了"優雅降級"——已生成的頁面保留，錯誤信息以 toast 形式出現，用戶可以選擇重試剩余部分而非全盤重來。

上線三個月后，數據很直白：平均生成時間從30秒降到4.2秒，用戶完成率（點擊生成到保存成品）從23%漲到67%。最意外的是，用戶開始把"看AI寫幻燈片"當成產品體驗的一部分，有人在社媒發錄屏，配文"看它比我想得快"。

這讓我們重新理解"延遲"——有時候用戶討厭的不是慢，是不知道在發生什么。30秒轉圈是黑箱，4秒漸進是共創。

現在我們在實驗更激進的方案：讓用戶在生成過程中點擊任意幻燈片實時編輯，AI會據此調整后續內容走向。如果這能跑通，"生成"和"編輯"的邊界就徹底模糊了——你不再是在等AI做完，而是在和它一起想。

流式界面改的不只是技術架構，是用戶和AI的協作關系。批處理時代，AI是后臺黑箱；流式時代，AI成了同桌辦公的人——你看得見它一筆一畫寫，隨時插嘴改方向。

有個用戶反饋我記到現在："以前用AI工具像交作業，等老師批完；現在像開會，邊說邊改。"