上线 AI 功能后的头 100 个工单

AI 功能上线后的 Bug 数量并非质量问题。它是一个发现序列——一个非常可预测的序列，以至于你可以在发布公告发布之前，在白板上逐周、逐个工单地勾勒出来，并且在仪表盘数据跟上时，你会发现自己预测得惊人地准确。每个上线 AI 功能的团队都会经历这个序列。唯一的选择是，你是带着操作手册（runbook）去执行，还是通过一系列临时的紧急会议来应对。

我已经观察了足够多的发布，足以相信这个序列实际上与工程质量无关。它关乎信息差。发布前，团队拥有合成流量组合、精选的评测集（eval set）、理想路径的演示和董事会演示文稿。发布后，真实用户带着合成流量从未模拟过的意图蜂拥而至，市场团队开展了工程团队仅略有耳闻的营销活动，模型提供商发布了未经团队授权的更改，而隐私审查员在功能上线时正在休假。下面的序列就是当这两个世界碰撞时产生的摩擦。

如果你即将发布，提前规划该序列的价值不在于它能让工单停止。而在于工单不再是意外，这就是能安稳睡觉的轮值值班与无法安睡的值班之间的区别。

第 1–2 周：成本激增与 Slack 截图

第一周几乎总是关于成本。不是因为模型坏了，而是因为市场部的某人安排了一场没人告诉工程部门的营销活动，而你的合成流量成本模型到周三时正面临着 4 倍的超支。这种模式非常一致，以至于你可以提前写好复盘报告：大多数成本激增可以追溯到六个原因之一——失控的智能体（agent）循环、导致 Token 数量激增的 Prompt 回归、意外的模型升级、重试风暴、嘈杂的租户（noisy tenant）或泄露的 API 密钥。这些都不是新的故障模式。新的是每一个背后的价格标签。

在第一周真正有效的解决方案不是“添加预算警报”。预算警报按月触发，且是在账单产生之后。解决方案是按群组（per-cohort）的消耗率报警——像 AWS 的上限燃烧警报一样向前预测 Token 成本，并按意图类别、按租户、按 Prompt 版本进行划分。如果你的成本仪表盘显示的数字与财务仪表盘不同，那么关于为什么发布超出预算的讨论在开始之前就会破裂。在上线前核对这两个视图，而不是之后。

第二周是截图。客户拍下一张 AI 说出奇怪话语的截图，发在公共 Slack 频道里，一小时后它就出现在了 P1 级回顾中。截图的内容很少是教训本身。教训是，团队中没有人知道模型正在回答的 Prompt、产生响应的模型版本、输入的检索上下文或用户的历史对话。没有这些，你就无法复现，无法分类，无法判断问题是影响了一个用户还是上千个。捕获完整的 Prompt-上下文-版本（prompt-context-version）三元组的日志记录是不起眼的基础设施，但在第一周它就能值回票价。跳过它，你就会在第三周的压力下重新构建它。

第 3–4 周：评测偏移与隐私审查

到第三周，你的评测集（eval set）开始与你的用户产生分歧。基准测试（benchmark）数字看起来不错。用户报告却不然。这并非由于任何一种信号的 Bug——而是离线评测与生产系统之间的差距。离线评测假设 Prompt 固定、标签固定且正确性定义固定，而生产系统在用户到达的那一刻就打破了这三点。即使基准测试准确率保持稳定，现实世界的性能也可能发生偏移，因为基准测试不再反映系统的实际使用方式。从业者将这一阶段描述为准确率下降是一个症状，而非领先指标：当指标发生变动时，偏移早已脱离了语义层。

出路不是“运行更多评测”。而是将评测视为一个持续的系统，而不是发布门槛。每周将真实的生产流量采样到评测队列中，标注一部分，与你的合成评测进行对比，并将两者的差异视为一项独立指标。当精选评测集与生产采样评测集开始出现分歧时，你的评测集正在腐烂，而生产采样集才是事实。计划在第三个月重写评测集。要明确地计划，而不是将其视为清理工作。

第四周是隐私审查。一个租户的 Prompt 上下文出现在另一个租户的支持回复中，或者标记为私有的内部字段出现在模型输出中，又或者自动补全建议包含了一个匿名用户不该看到的片段。原因几乎从来不是“模型泄露了它”。而是共享基础设施——以租户 ID 以外的内容为键的缓存、作用域比 API 更宽松的内存层、访问控制与应用程序不匹配的向量数据库。这是 AI 时代的 IDOR 漏洞，它不会出现在发布前的测试中，因为发布前的测试很少涉及两个租户并发执行同一路径。生产 AI 系统中真正的跨会话泄露事件通常追溯到配置错误的缓存、共享内存或作用域错误的会话上下文——这正是发布前测试无法覆盖的边界。

发布前的跨会话隐私审计——让模拟租户 A 和租户 B 的流量通过每个共享组件，并断言每一层的严格隔离——是你所能编写的最廉价的测试，也是大多数团队跳过的测试。

第 5–6 周：延迟尾部与无声的拒绝偏移

第五周，你为演示优化的重量级检索路径变成了用户的主流流程。该路径原本应该是备用方案。真实用户发现只有它能回答他们的实际问题，因此你之前作为 P99 追踪的长尾延迟现在变成了 P50。现有的监控假设了之前的分布。仪表板显示一切健康，但用户反映产品很慢。

架构上的教训是，延迟预算不是一个单一的数字。它应该是针对每个意图的预算，因为用户运行的不是平均情况 —— 他们运行的是自己的特定情况，且是重复运行，你的长尾延迟就是某人的中位数。为每个请求标记其实际采用的检索和推理路径，然后追踪每个路径的 P50/P95/P99。当备用路径的流量占比超过 10% 时，将其视为主要路径并重新制定预算。

第六周是拒绝偏移。模型提供商发布了他们所谓的微小更新。基准测试数据看起来都很稳定，内部监控显示为绿色。但在特定类别的合法用户请求中，拒绝率在一夜之间悄然翻倍，客服开始联系你，说用户反映 AI “变差了”。Anthropic 自己在 2026 年 4 月的披露中准确展示了这种模式 —— 质量下降集中在长上下文编码、多步推理和迭代问题解决上，而非头条基准测试中。等到模型提供商承认事故时，你已经发布了变通方案。

防御手段并不华丽：固定模型版本，在采用新版本前运行回归测试套件，并将任何提供商发起的变更视为需要与你自己的代码部署同等审查的部署。“自动升级到最新版本”是一个在仪表板层面看起来很负责任、但在实践中表现得像未经审查的依赖项升级的设置。

第 7–8 周：运行手册与不存在的功能旗标

第七周，轮值人员意识到他们继承的运行手册（runbooks）没有涵盖任何这些内容。手册告诉他们在服务返回 500 错误时该怎么做，而不是在返回带有错误内容的 200 响应时该怎么做。AI 事故的形态是不同的 —— 信号是定性的，回滚目标有时是提示词（prompt），有时是模型，有时是检索逻辑，而切断开关（kill switch）存在于与部署不同的层级。

运行手册的差距是可以弥补的，但必须填充 AI 特有的内容。一份有效的 AI 功能事故响应手册包括检测（确认告警，界定受影响的端点、区域和租户）、激活（选择可能缓解问题的最小范围切断开关 —— 记录操作者、事故 ID、原因、预期到期时间）和验证（合成交易和真实用户指标；如果错误率降至基准线，标记为已稳定；如果 5–10 分钟内未恢复，则升级为更大范围的回滚）。切断开关需要是一个真实的产品界面，而不是轮值人员必须在凌晨 2 点学习编辑的配置文件。

第八周是不存在的功能旗标（feature flag）。产品经理要求能够为特定用户群禁用该功能，同时保持其他人的开启状态，或者在不重新部署代码的情况下回滚提示词，或者对两个版本进行 A/B 测试。如果回滚提示词变更需要超过 15 分钟，说明该系统尚未准备好投入生产。成熟的团队通过使用环境指针或将提示词版本与部署解耦的功能旗标，报告回滚时间少于 60 秒。旗标必须是设计进去的，而不是在事故压力下临时加固的。

发布方案应预先准备的内容

这八周展现出的模式是：答案确实存在，但通常是补救性的。预先准备这些答案的发布方案如下。

预设的分流分类法。在发布前，写下你预期看到的类别 —— 幻觉、拒绝过严、拒绝过松、延迟、成本、隐私、提示词注入、检索丢失 —— 并预先为每个类别指定负责人。这些类别会有误，这没关系。重点是发布后的第一张工单有去处，而不是无处投递。

在发布前而非发布后配置 Eval 偏移告警。从第一天起就将生产流量采样到评测队列中。将人工精选评测与生产采样评测之间的偏离度计算为一个独立指标。针对偏离度告警，而不仅仅是绝对分数。

作为一个真实产品界面的切断开关。不是配置文件。不是需要部署的环境变量。一个轮值人员可以按下的按钮，支持按租户、用户群或功能划分范围，并记录按下者和原因。将紧急操作员角色的 RBAC 权限分配给少数人。在发布前进行演练。

针对提示词而不仅仅是代码的回滚策略。独立追踪代码版本、模型版本和提示词版本。了解每一层的“回滚”意味着什么。明确固定模型版本。将提示词变更视为部署，采用与代码变更相同的审查和回滚纪律。

针对不同用户群的成本消耗率告警。预测支出趋势。按租户、意图类别和提示词版本进行标记。在发布前将工程视角与财务视角对齐，这样第一周的对话内容将是关于响应措施，而不是关于谁的数据才是正确的。

跨会话隐私审计。两个合成租户，每个共享组件，在每一层断言隔离性。在发布前运行，并在架构发生变更时重新运行。

无人记录的组织模式

这个过程最难的部分并非技术挑战。而是发布 AI 功能的团队很少是第六十天负责运维的那个团队。发布团队脑子里装着模型、提示词和检索逻辑。而运维团队继承的是代码库、仪表板和 Slack 频道。

弥合这一鸿沟的交接文档通常并不存在，而在事后补写比事前编写更难。最小可行交接文档（minimum viable handoff）很短：该功能的作用、使用了哪些提示词、模型和检索路径、紧急开关（kill switches）是什么以及如何调用、已知故障模式及其对应的排查负责人、按意图类别划分的成本构成，以及评估队列（eval queue）的位置。在发布前一周写好这份文档。把它交给运维团队。并在发生第一次事故时与他们坐在一起共同应对。

在第三个月左右，领导层通常会意识到：AI 功能运维既不是质量保证（QA）问题，也不是传统意义上的 SRE 问题。它们是每个团队都会经历的一个探索过程。PagerDuty 的《2026 年 AI 优先运维现状报告》指出，在某些组织中，计划外中断的成本每小时超过一百万美元，而这些中断的性质始终符合上述的八周模式。受影响最小的团队并非那些试图阻止这一过程的团队——这几乎是不可能的。而是那些预先准备好答案的团队。

配合运维手册（runbook）来运行这个流程。账单、截图、评估漂移（eval drift）、隐私审查、突发的延迟、供应商的静默更新、运维手册的漏洞以及缺失的标志位（flags）无论如何都会出现。唯一的变量是你的团队是从仪表板发现问题，还是从客户那里得知。