编制 AI 客服故障降级预案

这个场景解决什么问题

机器人突然大量答错、转人工失败或订单接口超时，值班客服不知道先关什么、找谁。WorkBuddy 可以把实际系统能力和业务责任整理成可执行预案；生成文档不等于已经具备降级开关，也不意味着可以自行停生产服务。

开始前需要准备什么

准备已上线服务范围、异常告警、现有停止／转人工／关闭接口能力、值班联系人、业务与技术责任，以及测试环境。明确哪些开关能由谁操作、人工接待容量和备用渠道。没有实际开关就标待建设，不写“一键可关”。

具体怎么做

第一步：定义业务故障信号。 从重复错答、漏转、隐私泄露、接口超时和成本异常等建立检查入口。等级按影响范围、资金和隐私风险由负责人确认，不机械沿用示例编号。

第二步：写清降级路径。 逐项列全量转人工、停某类回答、关闭写接口保留查询的实际操作条件、执行人和备用路径。人工队列满了，提供已确认留言或回联安排，不继续自动承诺。

第三步：准备前期处置卡。 要求确认告警、圈定影响、执行经授权的止损动作并保存会话 ID、知识／提示词／模型版本、接口请求号和发生时间。对客稿说明现状与下一步，不编造恢复时点。

第四步：演练恢复检查。 在测试环境用历史故障及相邻正常场景验证修复、转人工和日志。技术与业务确认后小范围恢复，再看异常；不能未经测试直接全量开启。

可以直接交给 WorkBuddy 的完整要求

根据已上线客服服务清单、实际开关说明、告警和联系人，起草故障降级预案。
每类故障写触发证据、影响判断、建议等级、允许的止损动作、执行权限、联系人及备份、人工队列满时兜底、现场保存字段和对客说明草稿。
开关或接口不存在则标待建设，不虚构功能。恢复检查覆盖原故障、相邻场景、转人工、日志及小流量观察；给明确批准人。
只编制预案和测试情境，不访问生产、不关闭服务、不发送公告。未知恢复时间保持待确认，钱款和隐私事故由负责人决定补救。

完成后会得到什么

示例：故障：退款接口异常｜动作建议：停写入、保留查询并交专员｜权限：值班技术负责人｜保存：请求号和会话版本｜对客稿：已转专员，请勿重复申请｜恢复：测试原失败与正常订单。

结果应该怎么检查

每个动作确有可用入口和执行权限；联系人包含备份；人工兜底有容量；不会在接口失败后重复退款；恢复检查有具体用例与批准人。预案中的待建设项单列，不能报告已具备应急能力。

遇到这些情况怎么处理

值班人员无法操作开关，按真实升级渠道找技术，不指挥绕过权限。日志含敏感信息，限范围保存。事故原因未确认时先按权限止损，避免把推测写成对客说明。

哪些必须人工决定

业务和技术负责人确认等级、降级与恢复；重大钱款、隐私与合同事件由相应授权人员决定补救。AI 起草预案，不自主实施生产变更。