值班负担的转移：AI 功能如何打破你的事故响应手册

你的监控仪表盘一片绿色。延迟正常，错误率持平。而你的 AI 功能在过去六个小时里一直在捏造客户账号信息。

这就是当前在交付 AI 功能的公司中，值班工程师面临的新常态。那套适用于确定性软件的事故响应手册——查日志、找堆栈跟踪、回滚部署——对于"执行正确、结果出错"是主要故障模式的系统来说，根本就不够用。根据 2025 年的行业报告，五年来运营性繁琐工作首次从 25% 上升至 30%，即使各组织已投入数百万美元购置 AI 工具。工具越来越聪明，事故却越来越奇怪。

你的运行手册没有覆盖的故障模式

传统事故响应假设世界是二元的：服务要么在运行，要么宕机；请求要么成功，要么失败；出了问题，就会有错误码、堆栈跟踪、可关联的部署记录。AI 功能打破了上述所有假设。

AI 引入的全新事故类别包括：

• 静默语义退化。 模型返回语法上合法但事实上错误、偏题或有潜在危害的响应。健康检查通过，延迟 SLO 达标，但 AI 刚刚告诉客户他们的退款已处理，而实际上根本没有。
• 服务商侧静默变更。 LLM 服务商更新模型权重或弃用某个接口，你精心调优的提示词开始产生不同的输出。OpenAI 在 2026 年 2 月下线了 GPT-4o、GPT-4.1 及其他多个模型——那些硬编码模型名称的团队发现自己的流水线在变更发生后数天才因 404 报错而崩溃。
• 提示词注入攻击。 恶意内容通过用户输入或检索流水线进入系统，劫持模型行为。与 SQL 注入不同，没有任何 WAF 规则能可靠地拦截它。攻击面就是自然语言接口本身。
• 向量索引损坏。 上游的 schema 变更悄然降低了 RAG 流水线的检索质量。系统继续响应，但现在拉取的是过时或不相关的上下文。这种情况可能持续数天，才有人将数据流水线的变更与 AI 输出退化联系起来。
• 随机性退化。 一次提示词修改提升了平均输出质量，却同时在边缘案例中引入了长尾的糟糕响应。你的 A/B 测试显示了统计上显著的改进，但遗漏了那 2% 使新提示词彻底失败的查询。

这些故障没有一个会产生堆栈跟踪，没有一个会触发传统告警，也没有一个能通过回滚部署来修复——因为这个"部署"可能是发生在别人基础设施上的模型更新。

为什么"AI 在乱说话"现在是合法的事故报告

每个负责支持 AI 功能的值班工程师都收到过这种工单："AI 在乱说话。"在确定性系统中，你可能会以"信息不足"为由关闭它。但在 AI 系统中，这个模糊的报告可能是静默退化演变成客户级灾难之前你收到的唯一信号。

难点在于分诊。当用户报告 AI "在乱说话"时，你需要区分至少四种可能性：

1. 正常方差。 LLM 在设计上就是非确定性的。有些输出会出人意料，但仍在可接受范围内。
2. 提示词退化。 近期对系统提示词、检索上下文或护栏的修改，以用户能感知但指标无法捕捉的方式改变了输出分布。
3. 模型级退化。 底层模型的行为发生了变化——可能是服务商更新，也可能是微调模型的数据漂移。
4. 主动攻击。 有人正在通过提示词注入或对抗性输入对系统发动攻击。

传统升级路径在这里行不通。你无法把这个问题移交给数据库团队或基础设施团队。你需要一个了解完整 AI 技术栈的人：提示词工程、检索流水线、模型行为和评估框架。2026 年，大多数 SRE 团队仍然不具备这方面的专业知识，而这正是值班负担转移的核心所在。

验证税：AI 越多，繁琐越多

直觉上，AI 应该减少值班负担——自动化分诊、建议根因、起草事后复盘。这些能力确实存在。但数据讲述的是另一个故事：部署了 AI 功能的组织，其运营性繁琐工作不降反增。

原因在于业界开始称之为"验证税"的东西。当你上线一个 AI 功能时，你不仅仅是增加了该功能的运营负担，还在所有现有工作之上叠加了一层新的监控、评估和人工核验。想想一个负责任的 AI 部署实际上需要什么：

• 持续评估流水线，对生产输出运行黄金测试集并在漂移时发出告警。
• 人工审核队列，用于处理自动评估标记为模糊的边缘案例。
• 影子部署，用于提示词或模型变更，在路由真实流量之前比较语义输出。
• 行为日志，不仅捕获输入和输出，还捕获完整的工具调用链、检索结果和中间推理过程。

每一项在运营上都代价不菲。而由于 69% 的 AI 驱动决策仍需要人工核验，你实际上并没有把人从循环中移除——你把 AI 加入了循环，同时把人也留了下来。对一个拥有 250 名工程师的组织来说，这种开销每年转化为数百万的生产力成本。

管理得好的团队把 AI 监控视为一门独立的学科，而不是附加在现有基础设施监控之上的东西。他们拥有专用的评估基础设施、专属的 AI 问题值班轮换，以及专门针对非确定性行为的运行手册。

重建手册：真正有效的方法

在观察了各团队在 AI 事故响应上挣扎的两年之后，什么有效、什么无效，清晰的模式已经浮现。

对所有内容版本化，而不仅仅是代码。 每一次对提示词、系统指令、检索配置、模型版本和护栏规则的变更都需要版本化，并具备回滚能力。当 AI 事故发生时，你的第一个问题应该是"什么改变了？"——你需要工具来回答整个 AI 技术栈的这个问题，而不仅仅是应用代码。

建立语义基线，而不仅仅是性能基线。 传统监控跟踪延迟、错误率和吞吐量。AI 监控还需要额外跟踪输出质量指标：幻觉率、相对于已知正确答案的事实准确性、安全合规分数和任务完成率。这些指标需要基线和告警阈值，就像你的 p99 延迟一样。

实施 30 天告警规则。 实践了"删除任何在 30 天内未被处理的告警"的团队，其平均告警确认时间（MTTA）降低了 40%。这对 AI 系统尤其关键，因为来自嘈杂语义评估的告警疲劳可能掩盖真正的退化。如果一个告警持续触发而没有人处理，那它不是监控——那是噪音。

创建 AI 专属运行手册。 你现有的运行手册假设的是确定性故障模式。AI 事故需要专属的决策树：

• 这是模型级问题还是应用级问题？
• 我们能用相同输入复现糟糕的输出吗，还是它是随机的？
• 模型服务商最近有什么变更吗？
• 我们的评估指标是否显示漂移，还是这只是一个孤立报告？
• 我们能通过回退到缓存/确定性响应来缓解吗？

对值班轮换人员进行 AI 技术栈培训。 AI 事故响应中最常见的失败是交接缺口：被呼叫的 SRE 了解基础设施但不懂提示词工程，而了解模型的 ML 工程师却不在值班轮换中。通过对 SRE 进行 AI 基础培训，或创建与基础设施轮换并行工作的专属 AI 值班轮换，来弥合这一差距。

服务商依赖问题

AI 事故响应的一个独特之处在于，有相当一类事故完全起源于你自己的基础设施之外。当你的 LLM 服务商推送模型更新、弃用某个 API 版本或遭遇局部故障时，你的 AI 功能会以你无法直接修复的方式退化。

缓解策略很直接，但鲜少在第一次服务商导致的故障之前得到实施：

• 明确固定模型版本，升级前进行测试，像对待数据库迁移一样对待模型版本变更。
• 实施服务商故障转移，通过 API 网关，当主要服务商触达速率限制、发生故障或出现意外行为变更时，能够路由到备用服务商。
• 将服务商变更日志的监控纳入你的运营实践，而不是事后才想到。订阅状态页面、API 变更日志和弃用公告。像对待 CVE 一样对待模型弃用公告——它需要一个响应计划。
• 维护一套本地评估集，可以针对任何模型版本运行，以在行为退化到达生产环境之前检测出来。这是你的金丝雀——如果你的评估集在服务商更新后显示质量下降，你就拦截上线，而不是通过用户报告来发现问题。

事后复盘的缺口

传统事后复盘记录发生了什么、为什么发生、下次如何预防。AI 事故暴露了这一实践的缺口：根本原因往往是"模型产生了糟糕的输出"，这既是真的，也毫无用处。

有效的 AI 事后复盘需要深入挖掘。与其写"模型产生了幻觉"，不如记录：

• 哪些具体输入触发了幻觉
• 检索流水线是否提供了充分的上下文
• 护栏是否本应拦截该输出
• 评估流水线是否覆盖了这种故障模式

AI 事后复盘的可操作产出几乎总是以下三者之一：评估集中的一个新测试用例、捕获特定故障模式的护栏规则，或减少模型产生意外输出时爆炸半径的架构变更。如果你的事后复盘没有产出上述之一，它实际上并没有降低未来的风险。

随着 AI 功能从差异化优势变为必备基础，对非确定性系统的事故响应成熟度，将决定哪些团队能够可靠地交付，哪些团队将深陷持续的"救火"状态。这份手册需要重写——而现在就着手重写的团队，将比那些等待第一个 AI 专属 SEV-1 来倒逼改变的团队，积累起复利式的优势。