AI 值班手册：当 Bug 是一次错误预测时的故障响应
凌晨两点，报警器响了。仪表盘显示没有 5xx 错误、没有超时激增、没有异常延迟。然而客服已经被淹没："AI 给出了奇怪的回答。"你打开运行手册——立刻意识到它是为完全不同的系统写的。
这是 2026 年 AI 故障响应的标志性失效模式。系统在技术上完全健康。Bug 是行为上的。传统运行手册假设存在离散的失败信号：堆栈跟踪、错误码、不响应的服务。基于 LLM 的系统彻底打破了这一假设。输出语法正确、延迟正常、内容却完全错误。没有任何告警能捕捉到它。唯一的信号是某些东西"感觉不对"。
这篇文章是我第一次不得不响应生产 AI 故障时希望就存在的手册。
为什么你现有的运行手册在这里毫无用处
传统故障响应建立在确定 性失败的基础上。服务崩溃、返回 503、或者超时。爆炸半径是有界的：你可以追踪哪个服务失败、影响了哪些调用，并恢复到已知的良好状态。恢复手段是回滚部署或重启服务。
LLM 的失败违反了这个模型中的每一个假设。
静默的自信：模型返回一个看似合理、格式良好的响应。没有异常可以捕获。系统成功处理并将其提供给用户。从基础设施的角度来看，一切正常。
不可重现性：相同的输入在不同调用中可能产生不同的输出。失败的请求通常无法按需重现，这使得"重现 Bug"——任何传统运行手册的第一步——实际上具有误导性。你可能会花几个小时追逐幽灵。
扩散的爆炸半径：在智能体系统中，一次错误预测会级联传播。如果智能体基于幻觉事实决定删除一条记录或发送一封邮件，损害已经扩散到智能体触及的每个下游工具。你不是在回滚代码，你是在审计副作用。
延迟检测：研究表明，42% 的团队只能通过支持工单或 Slack 消息发现生产 AI 故障——往往在问题开始很久之后。追踪请求成功率和延迟的仪表盘完全忽略了质量下降。
结果：大多数将传统运行手册应用于 AI 故障的团队都在玩错误的游戏。他们在一个只在意义上失败的系统中寻找错误代码。
四种根本原因（以及如何快速区分它们）
当"输出感觉不对"时，你的首要任务是避免最常见的 错误：责怪模型。实际上，模型行为变化只占 AI 故障的少数。分诊问题不是"模型坏了吗？"——而是"哪一层发生了变化？"
有四个不同的层次可能导致输出质量下降：
数据漂移发生在输入分布偏离模型设计处理范围时。一个训练于英文查询的客服机器人开始接收大量西班牙语输入。文档分类器遇到了新的文档格式。模型没有改变，但世界变了。通过监控输入分布——语言代码、文档长度、实体类型、模式模式——并在统计偏差时告警来检测数据漂移。Evidently AI 等工具使这成为可操作的。
提示词回归更为隐蔽。每次修改提示词——添加示例、调整说明、改变语气——你都改变了隐式的监督信号。通过积累的变化，提示词可能偏离其原始意图，每一次单独来看都似乎合理。提示词回归表现为输出的一致性方向偏移：模型开始截断响应、变得过于谨慎，或者误解特定输入模式。检测需要一个回归测试套件：在每次提示词变更后与基线输出进行比较的固定输入集。
模型回归发生在模型本身改变时——这可能在你毫不知情的情况下发生。LLM API 提供商会静默更新。一月份的 GPT-4o 与四月份的 GPT-4o 并不完全相同。行为在没有版本标记或变更日志的情况下发生偏移。模型回归表现为输出分布变化：不同的默认长度、不同的拒绝率、不同的格式规范。最好的防御是行为指纹：在固定提示词集上捕获关键输出特征的测试套件，在生产中持续运行。
基础设施故障往往是团队假设模型故障时的真正罪魁祸首。返回过时或不相关上下文的检索组件、索引损坏的向量数据库、不再匹配模型预期的工具模式、静默截断重要信息的上下文组装 Bug——任何这些都 会产生看起来像模型故障但实际上不是的输出。研究表明，42% 的生产幻觉源于检索和上下文组装故障，而非模型本身。
分诊顺序：先检查基础设施（过去 24 小时内的新部署、配置变更、依赖更新）。然后检查数据（输入分布偏移）。再检查提示词（过去 48 小时内的任何提示词变更）。最后才是模型回归——它是真实存在的，但需要更多证据来确认。
升级决策树
一旦确定了根本原因，下一个问题是在哪里修复它。这个决策比看起来更为重要：升级到你的 LLM 提供商很慢（至少 24-48 小时）、消耗信誉，而且通常是不必要的。
先在本地修复。 大多数故障——跨越所有四个根本原因类别——可以在不涉及提供商的情况下解决：
- 提示词回归 → 回滚提示词变更或应用针对性补丁
- 数据漂移 → 添加输入验证、规范化边缘输入，或添加分别处理新分布的路由层
- 基础设施故障 → 恢复检索组件、纠正模式、修复上下文组装 Bug
- 轻微模型回归 → 调整示例、添加明确约束或更改温度参数
对大多数团队来说，提示词变更可以在几分钟内测试并在 30 分钟内部署。这几乎总是正确的第一步。
在同一提供商内回退。 如果本地修复无法解决问题且需要快速恢复服务，切换模型层级。GPT-4o → GPT-4o-mini 保持高提示词兼容性，同时提供不同的行为特征。Claude Opus → Claude Sonnet 是类似的切换。这在你调查根本原因的同时，为无用户影响的恢复争取 3-5 小时。
路由到替代提供商。 如果主要提供商遇到性能下降或部分中断，在持续错误率超过 5-10% 时，自动回退到备用提供商是合适的。这需要预先在提供商之间构建提示词兼容性——这是值得在故障发生前而非期间进行的投资。
升级到提供商。 只有在穷尽上述层级后才提交支持工单。提供：模型版本、温度设置、一个最小可重现示例（或考虑到不确定性的最接近近似）、以及你观察到的具体行为偏移，包含前后对比示例。提供商工程团队可以调查他们这边的静默模型更新或基础设施问题。对于非trivial问题，预计需要 24-48 小时。
关键洞见：大多数升级决策都过于仓促。当他们可以在 20 分钟内修复提示词时，跳到"联系 OpenAI"的团队会浪费数小时等待他们本已有工具解决的问题的回应。
评估作为生产监控
传统监控告诉你系统在运行。你需要一个单独的层来告诉你系统运行良好。这就是评估——evals——成为运营基础设施而非仅仅是测试工具的地方。
模式：对 1-5% 的实时生产流量进行采样，并通过自动评分管道运行。LLM 作为评判者的设置使用一个单独的模型，根据定义的标准评估你的主模型输出——正确性、事实依据、语气、安全合规、格式遵守。你在上线前定义评分卡。评估分数成为你告警的时序指标。
这给了你强大的能力：一个基于质量的告警，在输出准确率降至阈值以下时触发，在用户开始提交工单之前。你不再在凌晨两点通过 Slack 消息发现故障，而是在指标越过你精心划定的线时被寻呼。
运营设置需要：
- 一个定义的评估评分卡，标准映射到用户价值（不只是通用的"有帮助性"）
- 生产流量的采样机制
- 异步评分管道（增加关键路径的延迟适得其反）
- 基于基准性能而非任意百分比校准的告警阈值
LangSmith、Langfuse、Arize 和 Datadog 的 LLM 可观测性模块等平台使这具有可组合性。重要的不是平台——而是在需要之前定义质量标准的规律。
AI 故障复盘
AI 复盘从软件复盘模板改编而来时会失败。软件复盘的根本原因部分问"哪些代码发生了变化？"AI 复盘需要同时回答六个问题：
- 生产中的哪个模型版本？
- 哪个提示词版本？
- 哪个检索组件版本，使用哪个索引？
- 哪个工具模式版本？
- 故障发生前 48 小时内输入分布如何？
- 是否有任何静默的上游变化（API 更新、数据管道变化）？
没有全部六个，你的图景就不完整，会错过真正的原因。
在实践中有效的结构：
范围部分 — 精确数字：受影响的请求数量、哪个用户群体、时间窗口、以及第一个检测方法（自动告警 vs 支持工单本身就是关于你监控成熟度的信号）。
请求级别证据 — 提取 5-10 个具体的失败请求 ID 及其完整会话上下文：每个 LLM 调用、每个工具调用、发送的确切提示词、收到的确切输出，以及正确输出应该是什么样子。
故障分类 — 哪一层失败、支持证据、以及——重要的是——你排除了什么以及为什么。负面证据防止未来的混淆。
时间线 — 增量时间很重要：变更何时部署、第一个错误输出是何时（如果可以确定）、何时检测、何时升级、何时缓解、何时恢复确认。部署和检测之间的差距是大多数团队有改进空间的地方。
流程改进 — 大多数复盘跳过的一个问题："什么能更快地发现这个？"不只是"什么能预防它"，而是什么监控、评估或告警缺口让这个问题未被检测到运行了那么长时间。
在解决后 48 小时内运行复盘。记忆会衰退。人们在凌晨三点在故障频道进行的对话包含了两周后无法准确回忆的关键背景。
LLM 的金丝雀部署是什么样的
在需要之前值得构建的一个运营模式：模型和提示词变更的金丝雀部署。
机制类似于服务金丝雀发布——将 1% 的流量路由到新版本，监控关键指标，在数小时内扩展到 5%、20%、50%、100%。不同之处在于回滚触发器：你不是在观察错误率和延迟，而是在观察评估分数、幻觉率和输出分布。
自动回滚应该在以下情况触发：
- 质量评估分数相对基准下降超过 5%
- p99 延迟增加超过 20%
- 在采样流量中检测到任何安全策略违规
- 每次查询成本增加超过 15%
影子模式是前驱步骤：同时将生产流量路由到新旧版本，但只向用户提供旧版本的输出。记录并评分两者。这在你开始 金丝雀推出之前，给你提供了新版本的真实生产数据，而不会对用户产生任何影响。
两种模式都要求你的评估基础设施在生产中运行，并以足够快的速度产生分数，以在几分钟内触发回滚。如果评分太慢或太贵，你就失去了安全网。
这对你的值班轮换意味着什么
AI 值班的工程师需要与传统 SRE 不同的技能。他们需要足够理解提示词机制，以便在压力下进行热修复。他们需要了解检索管道的工作方式、分布偏移在散点图中是什么样子，以及如何读取跨多个 LLM 调用的会话跟踪。
这是大多数组织尚未弥合的差距。传统的 SRE 运行手册（"重启服务"、"回滚部署"、"寻呼 DBA"）无法直接转换。所需技能更接近于懂得如何发布代码的数据科学家，或理解统计分布的软件工程师。
对于构建此能力的团队：从会话跟踪开始（记录每个带有完整上下文的 LLM 调用），添加提示词的回归测试套件，并在生产中测量一个评估指标。这三项投资使第一次 AI 故障比在深夜盲目飞行要容易应对得多。
目标不是完美预防——AI 系统会出现意外行为。目标是将"出了问题"到"我确切知道是什么以及为什么"的时间从数小时缩短到数分钟。
关键要点
- 传统运行手册假设存在错误代码 和有界爆炸半径——AI 故障是静默的、扩散的，且通常不可重现。
- 按顺序分诊：基础设施 → 数据漂移 → 提示词回归 → 模型回归。不要首先责怪模型。
- 大多数故障可在本地修复；只有在穷尽提示词修复、层级切换和提供商回退后才升级到你的 LLM 提供商。
- 评估是生产监控基础设施，不仅仅是测试工具。在上线前定义你的评分卡，对实时流量进行采样，并对质量下降发出告警。
- AI 复盘需要追踪六个版本（模型、提示词、检索、索引、工具模式、数据管道），并应在解决后 48 小时内运行。
- LLM 的金丝雀部署使用评估分数作为回滚触发器，而不仅仅是延迟和错误率。
