「用户点击生成，盯着转圈30秒，等幻灯片出来时，他们已经新开标签页去查邮件了。」PitchShow创始人复盘第一版产品时，这句话被团队写进了技术债务清单的顶部。
2024年初，这家AI演示文稿工具创业团队踩中了一个集体幻觉：大语言模型（LLM，Large Language Model，大型语言模型）返回JSON，前端渲染成幻灯片，完事。结果首批用户留存率惨到连内部汇报都羞于展示。
问题不在AI，而在架构思维——他们把流式生成的模型响应，当成了数据库查询来处理。
从"整段缓冲"到"边播边用"
传统CRUD（增删改查）应用的惯性很隐蔽。开发者习惯了"请求-等待-完整响应"的闭环，这种模式在2023年前是标准答案。但LLM的token是逐字吐出来的，等待完整响应就像YouTube缓冲完整个视频才允许点击播放。
PitchShow团队重新拆解了"生成演示文稿"这个动作的本质。用户真正需要的是什么？不是一份等待30秒后突然出现的完整文件，而是即时反馈+渐进可用的内容。
他们最终落地的方案是三层流式架构：React服务端组件（RSC，React Server Component）处理首屏渲染，Server-Sent Events（SSE，服务器发送事件）传输增量数据，客户端组件负责渐进式UI更新。
数据流向变成：用户输入提示词→服务端启动LLM流→token到达后立即解析为幻灯片元素→SSE推送到客户端→React Suspense边界捕获并渲染。
服务端组件：把重活留在云端
RSC的关键价值在于零客户端JavaScript负担。AI生成的内容往往包含Markdown解析、代码高亮、图表数据转换——这些计算密集型任务被留在服务端执行，浏览器只接收最终的HTML片段。
具体实现上，PresentationPage作为异步服务端组件，直接在服务器上await生成流，将流对象传递给客户端的PresentationStream组件。这种模式消除了useEffect瀑布：不再需要组件挂载后发起请求、等待响应、状态更新、重新渲染的链条。
延迟被压缩到物理极限——数据在离数据源最近的地方被处理，而非跨越网络往返多次。
SSE与渐进披露：让用户有事可做
Server-Sent Events选得很克制。相比WebSocket的双向开销，SSE的单向通道恰好匹配LLM推理的单向输出特性。连接建立后，服务端以text/event-stream格式推送增量数据，客户端通过EventSource API监听。
渐进披露（progressive disclosure）的策略被细化到幻灯片级别：
标题先生成？立即渲染占位卡片。正文流式到达？逐段填充。图表数据最后出现？先展示文本框架，再动态注入可视化。用户在第3秒就能看到第一张可编辑的幻灯片，而非第30秒面对10张一次性弹出的页面发呆。
这种体验差异直接反映在行为数据上：生成过程中的页面跳出率从67%降至4%，平均编辑启动时间从28秒缩短到0.3秒。
2026年的默认配置
流式UI正在成为AI原生应用的基线。ChatGPT的对话逐字呈现、Claude的代码块实时高亮、Cursor的补全幽灵文本、Google vibe coding工具的渐进预览——这些产品的共同选择不是巧合。
React的架构演进恰好踩中了这个节点。Server Components的"服务端优先"理念，Suspense的异步边界处理，以及与现代流式传输协议的配合，让渐进式渲染从hack变成正统。
PitchShow团队内部有个说法：用户不会记得你用了什么技术，但会记得那种"还没反应过来就已经能用"的流畅感。第一代产品的30秒转圈，本质上是在惩罚用户的耐心；而流式架构把等待本身转化成了内容消费的一部分。
技术债清单上的那条记录现在被划掉了，旁边补了一行新注释：「架构即产品体验，延迟是设计问题。」
当生成时间从30秒压缩到300毫秒，用户的行为模式也随之改变——他们开始把AI生成当作实时协作，而非后台任务。一个被忽略的细节是：流式传输让"取消生成"变得有意义，用户可以在看到前三张幻灯片风格不对时立即中断，而非等待完整结果后全盘否定。这个交互细节的埋点数据显示，主动取消率12%，但取消后的重新生成转化率高达89%。
如果生成过程本身成为产品体验的一环，那么"加载中"这个状态是否还有存在的必要？
热门跟贴