上线 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 月的披露中准确展示了这种模式 —— 质量下降集中在长上下文编码、多步推理和迭代问题解决上，而非头条基准测试中。等到模型提供商承认事故时，你已经发布了变通方案。

加载中…