用途
Streaming Response（流式响应）是一种面向开发者的 UX 模式，用于实时 AI 响应流式输出。它的核心目标是让团队以可靠的方式逐步渲染 AI 输出，使用户在完整响应完成之前就能开始阅读或行动。资料指出，该模式在需要聊天和助手回答的场景中最有用。
与相邻模式相比，该模式应在不隐藏用户持续前进所需的状态、规则或恢复路径的前提下减少摩擦。
何时使用
- 聊天和助手回答
- 随时间逐步展开的结构化 AI 输出
- 需要即时阅读的长响应
何时避免
- 当标准非 AI 工作流会更清晰、更可靠时，避免添加 AI 专属 UI。
- 除非用户确实能从中受益，否则不要暴露高级控制。
- 不要仅用精致的视觉效果来掩盖模型的不确定性。
实施工作流
- 在复制示例之前，先确认该模式与问题和约束是否匹配。
- 从 references/pattern.md 中的结构和示例入手，然后选择最小可行的变体。
- 在叠加视觉润色之前，先应用无障碍、性能和交互护栏。
- 使用测试指南在键盘、屏幕阅读器、响应式和失败场景中验证行为。
无障碍护栏
键盘交互：
- 验证仅使用键盘就能完成流式响应相关操作。
- 当该模式打开、更新或显示额外 UI 时，保持焦点顺序合乎逻辑。
- 保持在高倍缩放时仍然可读的可见焦点状态。
屏幕阅读器支持：
- 优先使用语义元素，仅在语义本身不足时才添加 ARIA。
- 在正确的位置、以正确的礼貌程度播报错误、加载或完成等状态变化。
- 在有用时通过 aria-describedby 或结构化标题连接标签、提示和状态文本。
视觉无障碍：
- 不要仅依赖颜色来传达严重程度、完成或选中状态。
性能护栏
- 将网络延迟、token 用量和长响应的客户端渲染作为一个整体来做预算，而不是各自分开考虑。
- 在能改善首次价值时间时对流式或分块内容进行处理，但要稳定布局，避免阅读时出现抖动。
- 追踪昂贵状态，例如长提示、模型切换和重试，以便基于证据调整体验。
常见错误
隐藏系统状态：
- 问题：用户无法判断模型是在等待、流式输出、重试还是已完成。
- 修复方式：暴露清晰的请求生命周期状态，并将其保持在受其影响的内容附近可见。
把失败当作普通表单错误：
- 问题：AI 失败包括安全拦截、上下文限制、模型可用性和部分输出，而不仅仅是请求失败。
- 修复方式：区分不同失败模式，并针对每种模式给出匹配的恢复操作。
忽略 token 和延迟预算：
- 问题：当响应变慢、变短或变贵却没有解释时，体验会显得不可预测。
- 修复方式：从一开始就将 token、延迟和提供商约束设计进界面中。
相关模式
- https://uxpatterns.dev/patterns/ai-intelligence/ai-chat
- https://uxpatterns.dev/patterns/ai-intelligence/ai-loading-states
- https://uxpatterns.dev/patterns/ai-intelligence/context-window
有关完整实现细节、示例和测试说明，请参见 references/pattern.md。
模式页面：https://uxpatterns.dev/patterns/ai-intelligence/streaming-response