一周备稿 · 2026-08-10 · 21:00
相关：Tool 超时与降级矩阵 · 下篇预告：w2-agent-memory
AI 产品上线后，你最怕的往往不是模型回答不对，而是------用户疯狂点「发送」，然后页面卡住，然后骂娘。
限流（Rate Limit）是每一个 AI 产品的必修课。但技术限流简单，用户感知限流的方式才是产品体验的分水岭。
结论先说：限流 UX = 排队队列可见 + 降级路径清晰 + 告知文案诚恳 + 用户能「做点什么」而不是干等。
你将学到
- 限流在 AI 场景下和传统 API 限流的本质区别
- 排队 vs 拒绝：两种限流策略的 UX 代价
- 降级设计：当模型不可用时，怎么让用户不白来
- 告知文案怎么写才不招骂
- 一个最小可用的限流看板组件
一、AI 限流的特殊性
传统 API 限流
- 用户打一次请求，拿到 429 Too Many Requests
- 重试退避即可，体验在「一次调用」内完成
AI 流式限流
- 用户可能已经等了 5 秒首 Token，才被掐断
- 一次会话可能包含 10 轮对话，中断在中间轮的感受比「一开始就拒绝」差五倍
- 用户对「AI 慢」的容忍度其实很低------用户容忍延迟，但不容忍不确定性
三种限流场景
| 场景 | 触发条件 | 用户体验风险 |
|---|---|---|
| 瞬间并发 | 同一秒 100 人点击发送 | 页面无响应、消息丢失 |
| 日额度耗尽 | 免费用户每日 50 次用完 | 功能突然消失 |
| 模型降级 | 贵模型超预算，切到便宜模型 | 质量下降但用户不知情 |
二、排队队列可见：让用户看见「我在第几位」
做对了
text
「当前有 12 位用户在排队，预计等待 1～2 分钟。
你可以先翻看下面的历史回答，轮到你时会自动进入。」用户看到这个，通常不会走。因为他获得了确定性。
做错了
text
「系统繁忙，请稍后再试。」用户看到这个，大概率不会再回来。你让他「稍后」，但没告诉他「多久后」、也没告诉他「为什么」。
排队组件的最小实现思路
tsx
// 排队状态组件示意
function QueueStatus({ position, estimatedWaitSec }: {
position: number;
estimatedWaitSec: number
}) {
if (position === 0) return null; // 已轮到你
return (
<div className="queue-banner">
<span className="queue-icon">⏳</span>
<span>
排队中：第 <strong>{position}</strong> 位，
预计等待 <strong>{Math.ceil(estimatedWaitSec / 60)} 分钟</strong>
</span>
<button onClick={() => /* 订阅通知 */}>好了叫我</button>
</div>
);
}关键：实时推送位置变化（SSE 或轮询），让排队进度可感知。
三、拒绝 vs 降级：两种策略的 UX 代价
策略 A：直接拒绝
429 Too Many Requests适合：非核心功能 （如翻译、总结）、付费墙
代价：用户可能这次「顺便用一下」就走了，永远不回来
策略 B：自动降级
- 用户超限后，模型从 GPT-5 自动切到本地小模型
- 回答速度不变，但质量下降 10～20%
- 面板提示：「当前使用量较高，已自动切换为轻量版模型」
适合：核心对话流 、不想打断用户
代价：质量下降用户可能察觉，需要提前告知
决策树
用户是否在核心会话流中？
├─ 是 → 降级（提示但不中断）
└─ 否 → 拒绝（明确告知额度）
├─ 是否有付费方案？
│ ├─ 是 → 引导升级
│ └─ 否 → 告知恢复时间四、告知文案设计：别让用户觉得被惩罚
坏例子
「您今日的对话次数已用完，请明天再来。」
用户感受：你把我赶走了。
好例子
「今日免费额度已用完（50/50 次）。
升级 Pro 可立即恢复使用，或等待明天 08:00 自动重置。
你还可以继续浏览历史对话和收藏的回复。」
用户感受：我还有选择，而且历史数据没丢。
告知原则
- 说明原因（不是「系统错误」而是「超出用量」）
- 给出选项（等待 / 升级 / 降级）
- 保留价值（历史数据、收藏、设置都在）
- 预估时间（「约 2 小时后恢复」比「请稍后」好十倍）
五、降级矩阵：什么时候降、降到什么程度
| 当前状态 | 降级目标 | 用户感知 |
|---|---|---|
| 大模型超限 | 小模型 + 固定 Prompt | 回答变短，但速度不减 |
| 流式通道拥堵 | 限速为 1 轮/5 秒 | 输入框变灰，显示倒计时 |
| 向量库超限 | 切 BM25 关键词检索 | 召回率下降，但仍然可答 |
| 工具调用超限 | 跳过非关键工具 | 部分功能不可用，核心对话保留 |
降级的关键：不要在用户没察觉时偷偷降级。诚实告知 + 给出恢复预期，比偷偷降级更让用户信任。
六、限流看板组件：用户可见的最小闭环
tsx
function RateLimitStatus({ quota }: { quota: Quota }) {
const pct = (quota.used / quota.limit) * 100;
const color = pct > 80 ? 'red' : pct > 50 ? 'yellow' : 'green';
return (
<div className={`quota-bar ${color}`}>
<div className="quota-fill" style={{ width: `${pct}%` }} />
<span className="quota-label">
{quota.used} / {quota.limit}
{quota.resetsAt && ` · 重置于 ${quota.resetsAt}`}
</span>
</div>
);
}放在侧边栏或输入框上方，持续可见，不要等用户触发了才跳提示。
七、与工具超时 / 降级矩阵的衔接
限流和工具超时是两个不同维度，但 UX 设计应统一：
- 超时：单个工具执行太久（见 w2-tool-timeout）
- 限流：用户整体请求频率或额度超限
- 两者在 UI 上表现为同一个「输入框变灰 / 降级提示」组件，用户不需要区分是超时还是限流
踩坑清单
- 排队窗口只显示数字，不显示预计时间：用户不知道是 10 秒还是 10 分钟
- 降级不告知：用户发现回答变差了，以为模型退步了，其实只是被限流了
- 额度用完直接清空输入框：用户打了一大段话全丢了，体验极差
- 限流提示和正常错误提示混在一起：用户分不清是「网络问题」还是「用超了」
小结
AI 限流的 UX 设计，本质上是在回答用户三个问题：
- 发生了什么？（原因）
- 要等多久？（预期）
- 我能做什么？（选择）
把这三个问题回答清楚，用户不会因为限流而流失。
下一篇聊 Agent 记忆设计：短期会话、长期画像与什么不该记。
相关阅读 ：w2-tool-timeout（Tool 超时与降级矩阵）· w2-context-window-budget（上下文窗口预算）