提示词资产贬值：你团队中缺失的 AI 维护时间表

工程主管们对“代码腐烂”这一概念已经习以为常。依赖项需要更新，基础设施有生命周期管理，证书会在无人质疑的日期过期。然而，提示词仓库（prompt repository）却往往被视为一种“一次编写，多次读取”的产物——尽管它定义了你的产品如何与一个每六周就发布一次行为变更的概率引擎进行对话。

六个月前针对当时主流模型调优的系统提示词，现在依然在生产环境中使用。针对早已变更的分词器（tokenizer）挑选的 Few-shot 示例，仍在每次调用时被注入。重排序提示词是针对供应商上季度已废弃的嵌入端点调优的。没有人安排审查。也没有人打算去安排。

这并非假设性的失效模式。当一个团队将其精心针对 GPT-4-32k 稳定化的提示词套件迁移到 GPT-4.1 和 GPT-4.5-preview 时，其回归测试的通过率分别仅为 95.1% 和 97.3%。在生产环境中，3-5% 的隐性质量退化绝非可以忽略的误差；在任何具有一定规模的场景下，这都是一种用户可见的退化，而团队中没人是有意发布这种退化的。而且，这些还是拥有回归测试套件的团队。中等水平团队的“回归测试”，不过是值班工程师在处理上一次事故时凭感觉形成的印象。

我们缺失的范畴是提示词资产折旧（prompt asset depreciation）：这是一种维护纪律，它将每个生产环境中的提示词视为具有已知寿命的折旧资产，而非一成不变的常数。

没人追踪的三种衰减模式

提示词不需要经过修改也会发生隐性降级。这里至少存在三个独立的衰减向量，而大多数团队对其中任何一个都没有遥测（telemetry）。

脚下的模型漂移（Model drift）。 供应商发布了检查点更新。拒绝回答的风格发生了变化。JSON 格式发生了变化——以前输出 {"foo": "bar"} 的模型现在偶尔会输出 ```json\n{"foo": "bar"}\n```，而处理第一种格式的解析器捕获到了低频异常，但没人将这些异常路由给人工处理。你的 API 依然返回 200。你的延迟仪表盘看起来依然正常。这种缓慢移动的曲线是数周内复合而成的质量退化。

分词器更迭导致账单增加。 供应商在次要版本之间更换了分词器。上个月分词结果为 1.0 倍长度的同样一段英文，这个月变成了 1.3 倍——在极端情况下甚至达到 3 倍。你的 Few-shot 示例、模板化的系统提示词、模板化的输出指令成本全都突然增加，而由于业务量也在增长，这种成本退化在你的综合仪表盘中是不可见的。

世界在变，提示词却止步不前。 上个季度的产品规则引用了你已不再提供的服务层级。上个季度的 Few-shot 示例演示了调用一个 Schema 已发生变更的工具。提示词依然能通过评估（eval），因为评估标准和提示词是在同一时间被冻结的。两者都已脱离现实。

这三种情况的共同模式是：提示词在编写当天是正确的，但到今天就是错误的，而团队的日程表中没有任何标记来填补这一鸿沟。

必须落地的维护纪律

解决方法并不光鲜。这与你已经应用在证书、依赖升级和运行手册（runbooks）上的纪律相同——只是扩展到了大多数团队尚未命名的一类资产上。包含四个原语：

每个生产环境的提示词都有负责人。 不是指“AI 团队”，而是具体的人。如果该负责人离职，提示词会自动进入审核队列；“孤儿提示词”是没人能解释的承重组件，当底层模型最终发生变化时，它们的失效表现最为剧烈。

每个提示词都有“上次评审日期”和“重新验证日期”。 默认重新验证间隔为一个季度。某些提示词（高流量、用户可见、涉及财务）的周期应更短。某些（内部工具、低风险摘要）可以放宽。重点不在于具体的数字，而在于“我们是否应该重新验证这个？”不再凭感觉，而是成为一个可以用比较运算符决定的日期。

漂移是一个数字，而不是一种感觉。 在上次评审和现在之间，针对当前的生产模型运行相同的评估。差值就是你的证据。如果结果持平，记录下来并继续。如果是负增长，你就有了一个取证问题——是模型、提示词、评估裁判（eval judge），还是上游输入分布的问题？——而且你是在客户发起投诉之前就掌握了这一情况。

折旧运行手册路由逾期提示词。 工具标记任何已超过 revalidate_by 日期的提示词，并将其路由到具有明确 SLA 的评审队列中。大多数公司已经针对过期的密钥和证书建立了这种模式；同一个调度程序也可以运行提示词。

将此扩展到清单之外的关键是对系统本身的所有权。必须有人维护注册表、运行节奏，并催促逾期提示词的负责人。将此角色称为提示词管家（prompt steward）——既是图书馆员，也是 ML 工程师，还是产品经理。该角色在结构上与开发新功能的工程师不同，因为新功能工程师的动力是发布下一个东西，而不是重新验证上个季度的东西。如果你不明确资助这个角色，它就会落在碰巧调试下一次事故的人身上，这意味着在某些东西崩坏之前，没人会管它。

“每周提示词”强制机制是轻量化版本：AI 值班轮换包括每周重新验证一个超过阈值的提示词。它不能取代管家，但可以防止队列完全无人问津。

领导者不常提及的成本框架

工程负责人会询问维护预算的成本并拒绝它们。他们几乎从不询问 不 维护的成本，因为没有人会按月开出这笔账单。幻灯片上应该列出以下三个条目：

隐性质量回归的复利效应。 本季度评估套件下降 3% 并不像火烧眉毛。再经过两次模型升级和一次重排序器 (reranker) 更换后，你的水平比一年前下降了 8%，而且没有人能指出是哪个提交导致的，因为没有任何一个提交单独造成了这种局面。

Token 消耗量呈上升趋势。 模型对指令的处理能力变强，但默认变得更加啰嗦；分词器 (tokenizers) 会发生变动；团队在每次事故后都会在系统提示词中添加几行防御性内容，且从未删除。在用户群持平的情况下，你每个任务的 token 支出每年增长 10-20%，而在总流量增长的背景下，这个条目是隐形的。

可移植性税收每季度都在复利增长。 提示词 (prompt) 每停留在一个特定供应商的怪癖（如 JSON 模式的特性、拒绝回答的风格假设、停止序列的处理）上一个季度，更换供应商的成本就会增加。当更便宜的模型出现时，那些没有为了可移植性进行维护的团队会发现，迁移是一个季度的工作量，而不是一个配置更改。

这种纪律性在第一次将为期六周的迁移缩短为一周时就体现了价值。第二次体现价值是在它比客户先发现隐性回归时。难点在于，在这些事情以令人难忘的方式发生之前，就为其提供资金。

组织失效模式

大多数在这方面出错的团队并不是在技术上出错，而是在组织上出错。平台团队拥有提示词注册表。产品团队拥有提示词。没有团队负责 维护，因为维护是一个动词，而注册表是一个名词。结果是得到了一个完美的版本控制系统，但其内容自功能上线以来就从未被触碰过。

在实践中奏效的模式通常是：平台团队负责 基础设施（注册表、评估运行器、标记过期提示词的调度器），产品团队负责 内容（实际的提示词及其评估），而一名指定的管家负责 节奏（催促负责人、升级逾期项目、批准下线决策）。三个角色，全部定人。一旦其中任何一个变成“团队的责任”而不是个人的责任，这种节奏就会在两个季度内消失。

另一种失效模式是孤儿提示词问题。工程师离职。功能优先级降低。提示词仍在生产环境中运行，因为没有人有理由删除它，而且删除它也不在任何人的季度计划中。下线路径——明确退役那些功能优先级已降低或负责人已离职且无继任者的提示词——也是这种纪律的一部分。一个无人负责的提示词不是资产；它是一项负债，其所有权默认归属于它出故障时正在值班的人。

这一认知的真正含义

我希望工程领导者内化的框架是：提示词是对 编写时 世界状态的一种依赖。模型行为、分词器、产品规则、上游工具、用户分布——在编写提示词的那天，所有这些都是一种特定的配置。世界已经向前发展了。如果提示词没有根据现在的世界进行重新验证，你就不知道它是否仍然有效；你只知道它在已经过去的一天里 曾经 有效。

这句话的形式与我们已经接受的关于代码依赖、安全补丁和证书到期的论述完全一致。团队之所以没有将其扩展到提示词，并不是因为这个类比不恰当，而是因为提示词是配置文件中的文本，看起来保留它们的成本为零，而且它们会以一种不会触发报警器的方式默默降级。这些都不是反对这种纪律的理由，而是为这种沉默构建监控仪器的理由。

在未来十年的 AI 产品工作中占据主导地位的团队，不是那些拥有最聪明提示词的团队，而是那些拥有枯燥时间表的团队，时间表上写着：每个季度，每个提示词，每个负责人，每个评估增量。枯燥正是关键。枯燥是你在实际预算中考虑到折旧时的样子，而不是将其视为一份无人报告增长率的隐性技术债务资产负债表。