12 个月的 AI 功能悬崖：为什么你的生产模型在无人标记的日历上悄然衰减

一个功能发布时通过率为 92%。发布演示稿（Launch deck）为此庆祝。12 个月后，同样的功能通过率降到了 78% —— 没有事件报告，没有部署失败，没有任何单一的变更可以追责，仅仅是无人负责监控的缓慢侵蚀。团队将其归咎于“幻觉”或“用户行为转变”，选了一名初级工程师去调查，并设定了一个“提高质量”的季度 OKR。OKR 没能达成。该功能上线了一个道歉对话框，告诉用户 AI 有时会犯错。六个月后，它被弃用，取而代之的是一个发布时通过率为 91% 的新版本，循环再次开始。

这并非运气不好。这是 AI 功能运行的“第二时钟”，一个在发布时没有人会在日程表上标注的时钟。传统软件也有功能衰减 —— 依赖漂移、代码库腐化、缓慢积累的半成品重构 —— 但这些衰减是发生在工程团队已经理解并预留预算的时钟上。AI 功能具备上述所有问题，此外还有一系列传统摊销假设无法建模的并行衰减源：模型弃用、厂商权重轮换、用户输入的分布偏移、不断叠加的 Prompt 补丁、评估器（Judge）校准偏移，以及不再能代表生产流量现状的评估集的悄然老化。

在下一个 AI 功能发布之前，而不是之后，必须落地的架构认知是：AI 功能具有非零的基础维护成本。功能在发布时并没有“完成”。它已经进入了一个无法逃避的维护周期，而那些没有为这个周期预留预算的团队，终将通过惨痛的方式发现这一点。

发布日期下运行的五个时钟

当一个传统服务以 99.95% 的可靠性发布时，下个季度掉到 99.7% 的唯一途径是有人推送了代码、更改了配置或发生了硬件故障。从“良好”到“降级”的路径是由团队可以回溯的事件介导的。AI 功能不具备这种属性。在发布日期之下，至少有五个时钟在运行，其中任何一个都可能导致一年后的回归 —— 通常是多个时钟共同作用的结果。

时钟一：模型弃用。 OpenAI、Anthropic 和 Google 现在都发布了模型弃用时间表，以 6 到 12 个月的节奏淘汰模型。GPT-4o、GPT-4.1、GPT-4.1 mini 和 o4-mini 都将在 2026 年面临弃用。Claude 3.5 Haiku 的弃用时间为 2026 年 1 月 5 日，并于 7 月 5 日关闭。Gemini 2.5 Flash 和 2.5 Pro 将在 2026 年 6 月弃用。如果你的功能是基于这些模型发布的，无论你的团队是否注意到，大限已定。从一个模型版本迁移到其继任者很少是改一行代码就能搞定的，因为 Prompt 是针对旧模型的特定怪癖进行调优的，而继任者对它的解读会有所不同。

时钟二：隐形权重轮换。 固定模型名称并不等同于固定模型行为。厂商在带有日期的别名背后更新权重，“gpt-4o-2024-08-06”虽然比“gpt-4o”更稳定，但仍不能保证今天为你提供流量的模型与六个月前通过评估的模型在字节层面完全一致。一些提供商提供不可变的修订版本锚定（Revision pins）；许多则不提供。那些假设别名就是合同的团队，在审计时会发现该合同仅仅是一个礼貌性的建议。

时钟三：输入分布偏移。 “Prompt 漂移”是这种失效模式的误称，实际上 Prompt 没变，但生产环境的输入分布变了。用户学会了你的 AI 功能擅长什么，并开始提出更难的问题；随着采用率的扩大，异常输入的“长尾”在增长；出现了 Prompt 模板从未测试过的新用例。在发布时通过测试的评估集只是第 0 个月输入分布的快照。12 个月后，评估集对生产环境实际情况的覆盖率正在一个团队未关注的时钟上不断缩减。

时钟四：Prompt 补丁的堆积。 每一个“某个客户报告了 X 问题”的修复都会作为一句话、甚至一段话落在系统 Prompt 中。每一个单独的补丁都是合理的。但总和起来，Prompt 在一年内从 800 个 token 增长到 2400 个，中间的指令被更新指令的近因偏差所取代，而 Prompt 最初的行为意图现在被一堆团队无法整体推理的覆盖逻辑所调停。最近关于“Prompt 债务”（Prompt debt，即 Prompt 漂移的技术债近亲）的研究发现，Prompt 配置是 LLM 项目中自认技术债的主要来源，尤其是基于指令的 Prompt 最为脆弱。

时钟五：评估器（Judge）和评分标准（Rubric）的校准。 如果你使用 LLM-as-judge 来为自己的输出评分，那么该评估器本身就运行在上述四个时钟之一的模型上。发布时给你 92% 通过率的评估器，现在正运行在不同的模型版本上，对照着针对不同生产分布编写的评分标准，它今天报告的分数与一年前的分数不具有直接可比性。评分板正在评估过程中发生偏移，而没有随模型版本一起追踪评估器版本的团队对此一无所知。

让“悬崖”呈现悬崖形状的诊断难题

为什么“悬崖”是一个恰当的比喻——而不是“缓坡”——是因为所有五个时钟都在静静地走动，直到它们停止。每一个时钟都会单独地让指标变动几个点；用户体验会在毫无怨言的情况下吸收这些变动，支持工单会被表述为“AI 出错了”而不是“AI 变差了”，仪表板上的通过率曲线每季度会下降一两个百分点。接着，模型弃用迫使团队在固定期限内进行迁移，这次迁移暴露了累积的“提示词债”（prompt-debt），而评估集（eval set）被证明无法代表当前的流量，导致团队实际上无法验证迁移效果，于是功能跌落悬崖，因为三个季度的累积漂移被一次性审计了。

诊断难题在于，当团队最终审视时，没有任何一个时钟是独立原因。原因在于没有人负责观察它们，因此回归有六个促成因素，而没有清晰的根本原因。复盘报告写着“我们应该监控这一点”，而行动项是“添加一个仪表板”，团队建立了仪表板，看了三周，然后就不再看了，因为下个季度的路线图上有新的功能开发任务。循环往复。

必须在发布前列入日程表的维护节奏

必须落地的纪律——“纪律”是一个准确的词，因为失效模式是结构性的而非技术性的——是 AI 功能在发布时，从第一天起就必须在日程表上列出维护节奏，由拥有该功能的同一个团队负责，并且该节奏的成本在做出发布决策前就已计入功能的总拥有成本（TCO）。

针对最新生产流量的季度重新评估。 评估集不是静态的产物；它是一个鲜活的数据集，每季度从当前的生产流量中提取采样并标记样本。标注成本是真实且经常性的——根据标注的复杂程度，每个功能每季度大约在 $5K 到$30K 之间——它必须是一个预算项目，而不是无资金支持的要求。做得好的团队会在当前的生产模型和提示词上运行新的评估，并将结果分解为“模型贡献”、“提示词贡献”和“分布贡献”，以便对回归进行归因。

每月提示词审计。 上个月落地的每一个提示词补丁（patch）都要作为一个整体进行审查，而不是作为单独的代码差异（diff）。被模型升级所取代的补丁会被停用。相互矛盾的补丁会得到协调。审计会产生一个提示词变更日志（prompt-changelog），指明当前提示词的行为意图以及何处在强制执行该意图，这样下一个必须调试回归的值班人员就可以将提示词作为一个连贯的文档来阅读，而不是历史修复程序的沉积物。

根据供应商弃用节奏进行的模型版本固定审查。 你功能所依赖的每个供应商模型都有一个弃用时间表；团队的发布计划应该与之镜像。模型版本固定（model-pin）审查发生在弃用截止日期之前，而不是截止日期当天，并且迁移目标是在针对候选后续模型进行校准评估后选定的——而不是在 API 开始返回 4xx 错误的那一刻。等到弃用截止日期的团队是在时间压力下进行没有评估余地的迁移；而提前 60 天以上主导弃用流程的团队则有余地将迁移作为正常发布来执行。

裁判模型版本固定与重新校准。 如果你使用“大模型作为裁判”（LLM-as-judge）进行评分，那么裁判模型和评分标准版本应与生产模型和提示词一起进行版本化。当裁判模型本身被弃用时，重新校准就是一个项目：使用旧的和新的裁判模型对保留集进行重新评分，以建立分数之间的对应关系，并公布新的分数基准，而不是让仪表板悄悄地发生偏移。

发布时分配的基准维护预算。 这种纪律中最难的部分不是技术；而是 AI 功能具有传统功能所没有的经常性成本，而像对待传统功能一样为 AI 功能定价的团队低估了其成本。对于 2026 年生产级 AI 功能的一个合理经验法则是，每年持续维护成本为原始开发成本的 15–25%，如果功能涉及高风险或合规性，这一比例还会增加。发布该功能的 PM 负责这笔费用。如果他们无法获得资金，该功能在发布时就带着已知的衰减轨迹和已知的下线日期——这本身也是一个合理的决定，但前提是它是被明确指出的。

导致悬崖的组织失效模式

上述技术纪律写下来并不难。难的是为它们提供资金。导致 12 个月“悬崖”的组织失效模式是结构性的：AI 功能获得了上线预算，但没有维护预算。通过快速发布 AI 功能来实现规模化的工程组织，在其运营模型中没有为那些负责防止已上线功能衰减的工程师留出位置。

PM 的激励来自于新功能上线，而不是去年上线功能的质量保持。评估工程师是由多个功能共享的，并且是上季度博客文章警告过的瓶颈。ML 平台团队负责基础设施，但不负责每个功能的评估。功能工程团队负责功能，但承担了大量新功能开发工作，没有专门的维护工作档期。因此，维护工作落到了任何出现的人身上——在 12 个月的时候，通常是由于客户投诉而被呼叫的值班人员，他们在一周的救火中处理长达一年的复合漂移分流。

解决方法不是编写运行手册（runbook）。解决方法是为维护节奏指定负责人，并在规划时将维护工时计入团队的产能，就像运维人员数量计入 SRE 团队的产能一样。没有维护节奏负责人的 AI 功能终将跌落悬崖；问题只是何时发生。

如果你不支付这项成本，会发生什么变化

一些团队在读到这里时可能会合情合理地认为，并不是每个功能都值得投入维护成本。这是一个站得住脚的立场，而整篇文章背后的架构认知在于：成本是真实的，必须审慎地做出选择。团队可以从三个选项中进行选择，只要明确定义，它们都是可持续的：

选项一：全周期维护。 该功能至关重要，衰退成本很高，团队预算了 15–25% 的年化维护额度并指派了明确的负责人。该功能拥有 5 年的生命周期和受保护的通过率。

选项二：明确下线计划。 该功能有用但非核心支撑。团队在发布时就定好了 12–18 个月的下线日程，发布后不再进行持续维护，并计划在到期时进行替换或移除。用户和利益相关者在发布时就会获知这一期限。该功能会体面地衰退并退出。

选项三：宣告式衰退。 该功能保持运行，但仪表板会诚实地显示不断下降的通过率，并且产品会根据当前的通过率（而非发布时的通过率）提示“AI 可能会出错”。衰退是一种已知的运行状态，而不是隐蔽的。

错误的选项——也是大多数团队默认选择的选项——是选项四：发布后置之不理，然后等待“惊喜”。这条路会导致断崖式下跌、无法溯源的回归、救火式的迁移，以及 12 个月后发表一篇道歉博文，感叹 AI 有多难。

AI 确实很难。但如果你愿意在发布前而不是在出现回归后就做好标记，那么这种难度其实是遵循着日历上早已显现的时间规律的。