React + AI 应用开发

AI 应用如何设计模型 fallback、离线降级和错误恢复？

成熟的 AI 前端不会把所有故障都变成“请重试”，而是根据错误类型和任务风险选择恢复路径。

适合阶段：资深前端 / 稳定性面试核心能力：降级策略 · 错误分类 · 恢复 UX

面试官想考什么

• 主模型超时是否自动切换模型？ 考察成本与语义一致性。
• 离线时 Chat 怎么办？ 考察能力探测与队列。
• 安全拒绝能否 fallback？ 考察错误边界。
• 降级后用户是否知道？ 考察透明度和信任。

一句话回答

先按错误类型区分重试、模型 fallback、功能降级和人工接管，fallback 必须受策略、预算和能力矩阵约束；离线只保存草稿和明确可离线任务，所有降级都给出可恢复动作并记录原因。

面试回答详解

1. 错误分类

• 网络断开：恢复连接后重连或查询任务。
• 429/配额：等待、排队或提示升级，不立即高频重试。
• 模型超时/5xx：可切换兼容模型，但要查询原任务状态。
• 能力不支持：不要 fallback 到语义不等价的模型。
• 安全拒绝/权限拒绝：不能通过换模型绕过策略。

2. Fallback 矩阵

服务端根据任务类型、数据敏感级别、模型能力、租户预算和地区可用性选择模型。前端只接收 degraded: true、reason code 和用户可理解的文案，不直接决定使用哪个密钥或模型。

3. React 状态

running -> retrying -> running
        -> degraded
        -> needs_user_action
        -> handoff

错误组件提供保留输入、重试、复制草稿、切换到人工或稍后查看等动作。Error Boundary 负责隔离渲染错误，不能替代请求错误状态。

4. 离线边界

离线可以保存未发送草稿、已缓存历史和本地帮助；有副作用的 tool call、实时生成和敏感数据同步不应假装支持离线。恢复联网后提交队列必须有幂等键和过期策略。

5. 观测与产品策略

记录 fallback rate、degraded success rate、retry budget、人工接管率和用户放弃率。降级不是越多越好；如果备用模型质量明显差，应宁可清晰失败，也不要静默给出高风险错误答案。

可直接背诵的 30 秒回答

我会先把错误分类，再决定重连、有限重试、模型 fallback、功能降级或人工接管。模型切换由服务端按能力、敏感级别和预算决定，安全和权限拒绝不能靠换模型绕过。前端保留输入、显示降级原因和恢复动作；离线只保存草稿和允许的缓存，恢复提交仍用幂等键。

扩展知识

降级层级

完整 AI -> 较快/较便宜模型 -> 非流式结果
-> 模板化能力 -> 人工处理 -> 明确失败

每一级都要说明语义变化和风险，不要把不同能力包装成同一个“成功”。

面试官追问链

追问一：备用模型应该由前端选择吗？

• 考察点：密钥、策略和一致性。
• 回答方向：不应该。前端可传业务意图，服务端按策略和能力矩阵选择。

追问二：离线队列会不会重复创建资源？

• 考察点：副作用风险。
• 回答方向：只允许明确支持的操作入队，每项有幂等键、过期时间和用户确认，服务端状态查询后再执行。

追问三：怎么判断 fallback 是成功还是假成功？

• 考察点：质量评估。
• 回答方向：看任务完成率、人工修改率、用户反馈、安全事件和成本，不只看 HTTP 200。

推荐阅读

• Network Information API - MDN
• Service Worker API - MDN
• OpenAI Models
• React Error Boundaries