值班负担的转移：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 名工程师的组织来说，这种开销每年转化为数百万的生产力成本。