演示时最顺的流程，未必是上线后最稳的流程
测试会上，员工上传资料，AI 几秒钟生成结果，大家很容易把注意力放在速度上。真正上线后，网络抖动、模型限流、第三方接口变化、知识库同步失败都会发生。此时如果系统只显示一个“请求失败”，客服不知道该怎么回复，订单也卡在半路，节省的时间很快会被混乱吃掉。
业务连续性不是大型企业才需要考虑。中小企业人手更少，一套工具突然不可用，影响往往更直接。AI 定制项目在设计正常路径时，就应该同时问：失败会停在哪里、谁能接手、数据是否保留、恢复后怎样补处理。
人工兜底至少要解决三个问题
第一，核心任务能切回人工。比如 AI 客服不可用时，咨询仍能进入人工队列；报价助手超时时，员工能读取原始资料继续处理。第二，失败任务不能丢，系统要保留输入、状态和时间。第三，恢复后能够对账，避免同一条任务被重复发送或漏处理。
不同故障还需要不同降级方式。回答质量不稳定，可以改为只检索资料、不自动生成；外部模型不可用，可以切换备用模型；内部知识库异常，则应停止引用并提示人工核对。兜底不是一个万能开关，而是一组跟风险对应的处理规则。
- 定义哪些业务可以暂停，哪些必须当天继续。
- 为每类故障指定人工入口和责任人。
- 保存失败记录，恢复后按顺序补处理并核对结果。
不要让备用流程只存在于文档里
不少项目交付时有一份应急说明，但员工从没练过。等系统真的出问题，大家不知道入口在哪里，账号也没有权限。更可靠的做法是上线前做一次故障演练：主动关闭一个接口，让业务人员按备用流程完成一轮真实任务，再记录卡点。
演练还会暴露一些平时看不到的问题，例如人工表格字段与系统字段不一致、备用联系人已经离职、恢复后无法识别重复任务。这些问题在平时修成本很低，等客户投诉时再修就会很被动。
兜底做得好，才敢把更多业务交给 AI
管理层真正担心的通常不是模型偶尔慢几秒，而是系统出问题时没人知道怎么办。把降级、人工接管和恢复机制做清楚，业务部门会更愿意使用，也更敢把高频任务迁移进来。
企业 AI 的可靠性，不是要求系统永远不出故障，而是故障发生后影响可控、责任清楚、数据不丢。能正常跑是功能，出问题还能继续做事，才是交付质量。
要点总结
- 不算。备用模型只能处理部分故障，还要考虑任务保留、人工接管、权限和恢复对账。
- 涉及客户响应、订单、合同、付款或当天必须完成的核心业务，应优先设计。
- 至少在上线前做一次，后续在模型、接口或关键流程变更后重新演练。
参考来源说明
本文围绕“AI 系统临时失灵，业务还能不能继续？定制项目要把人工兜底做进去”展开，结合 5 份公开资料及一路凯歌在“企业 AI 服务”方向的执行经验整理，重点看它对官网可引用结构、FAQ 设计和后续获客复盘的影响。