换了模型，你的提示词资产会不会作废

一套用了半年的提示词，换模型之后遇到的第一件事，通常不是效果变差。

是请求直接报错。

Anthropic 官方的模型弃用文档里有一张参数弃用表，写着 `temperature`、`top_p`、`top_k` 三个采样参数在 Claude Opus 4.7 及之后的模型上的状态：Returns a 400 error when set to a non-default value——只要你把它们设成非默认值，请求返回 400。不是效果打折，是不跑。

这件事值得先说清楚，因为它决定了「提示词资产会不会作废」这个问题该怎么问。它不是一个玄学问题，它有三种具体的作废方式，其中两种在官方文档里白纸黑字写着，第三种写在迁移指南里，而第三种最贵。

下面三种逐个拆，再给一份最小回归用例清单和一套版本管理的最小配置。依据全部来自各家公开文档，逐条给出页面与日期。

一、三种作废：两种当场报错，一种悄悄发生

第一种，参数作废。 就是开头那条。

同一份文档里还有第二条同类的：`thinking: {type: "enabled", budget_tokens: N}` 这种写法在 Claude Opus 5 上不被支持，同样返回 400。而在此之前的一代模型上，它是可用的。

这类作废的好处是它诚实——它当场就告诉你。坏处是如果这段调用埋在凌晨跑的批处理里，你会在第二天上午才知道。

第二种，模型名作废。 你的提示词绑在一个模型 ID 上，那个 ID 会消失。

这不是推测，是有排期表的。据 Anthropic 的模型弃用页面，`claude-sonnet-4-20250514` 与 `claude-opus-4-20250514` 于 2026 年 4 月 14 日发出通知、2026 年 6 月 15 日退役；`claude-3-7-sonnet-20250219` 于 2026 年 2 月 19 日退役；`claude-opus-4-1-20250805` 已于 2026 年 6 月 5 日发出通知，公告的退役日期是 2026 年 8 月 5 日（2026 年 8 月 18 日复核补记：该型号已按期退役，官方弃用页现在把它标为 Retired，定价页注明「在 Bedrock 与 Google Cloud 上除外」——它从一条排期变成了一个已完成的样本）。同一页写着一条政策：对公开发布的模型，Anthropic 承诺至少提前 60 天通知退役（原文 at least 60 days' notice before model retirement for publicly released models）。

另外两家也一样。据 OpenAI 的弃用页面，2026 年 6 月 11 日的公告把 `gpt-5-2025-08-07`、`gpt-5-pro-2025-10-06`、`o3-2025-04-16`、`o3-pro-2025-06-10` 几个旧快照排进了 2026 年 12 月 11 日关停；2026 年 4 月 22 日的公告则把一批更老的模型（含 `gpt-3.5-turbo-0125`、`gpt-4-0613`、`o1`、`o3-mini`、`o4-mini`）排进了 2026 年 10 月 23 日关停，推荐替换为 GPT-5.6 的三个档位。

据月之暗面的模型文档，`kimi-k2` 系列自 2026 年 5 月 25 日起下线且不再维护（原文 have been offline since May 25, 2026 and are no longer maintained），文档给的迁移方向是 kimi-k3；`kimi-latest` 于 2026 年 1 月 28 日下线，`kimi-thinking-preview` 于 2025 年 11 月 11 日下线；同一页还写着 `kimi-k2.5` 与 Moonshot V1 系列在 K3 发布后不再对新用户开放，全平台下线时间公告为 8 月 31 日。

三家、三份官方文档、一件事：模型 ID 是有保质期的，而保质期普遍短于你那套提示词的使用寿命。

第三种，提示词里的话本身作废。 这一种不报错。

Anthropic 从 Claude Opus 4.8 迁移到 Claude Opus 5 的官方迁移指南里，有两条建议是直接冲着提示词正文去的：

请把这两条读第二遍。「把你之前写进提示词的那几句删掉」——这是模型提供方自己给出的迁移动作。 那几句当年是被当成最佳实践写进去的：让它检查一遍、让它列出理由、让它自我复核。它们不会报错，它们只是从「提高质量」变成了「增加成本、拖长响应、让答案更啰嗦」。

同一份指南还写了一条会直接改变你账单的行为差异：在 Claude Opus 4.8 上，不带 `thinking` 字段的请求不带思考运行；在 Claude Opus 5 上，同样的请求会以自适应思考运行。指南因此明确提示：`max_tokens` 是输出总量的硬上限，思考和正文一起算，所以那些原本不带思考跑的任务，要回头重看 `max_tokens`。

一句话总结这一节：报错的那两种会自己找上你，不报错的那一种只会体现为「怎么这一版答得又长又慢又贵」，而没有基线你根本说不清是不是它。

二、还有一种作废发生在账单上：同一段文字，token 数多了约三成

这一条单独拿出来说，因为它最容易被漏掉——它既不报错，也不改变答案质量，只改变你付多少钱。

Anthropic 模型总览页在 Claude Fable 5 的上下文窗口一栏有一条注释：Claude Fable 5 使用 Claude Opus 4.7 引入的那套分词器；与 Claude Opus 4.7 之前的模型相比，同一段文本会产生大约多 30% 的 token（原文 compared to models before Claude Opus 4.7, the same text produces roughly 30% more tokens，并注明具体幅度取决于内容）。

同一份迁移指南也补了另一半：从 Claude Opus 4.8 迁到 Claude Opus 5，两者用的是同一套分词器，所以 token 数大致不变，不需要再做一次重新计量。

两句合起来是一个很清楚的边界：跨过 4.7 这一代，你的提示词一个字没改，计费的字数多了约三成；在这一代之内换型号，不涉及这件事。

这个三成落到钱上是多少，取决于你的调用结构。下面这笔账你可以自己填，其中的调用量是本文给的假设值，不是任何调研结论：

假设你有一段 2000 token 的系统提示词，每次调用都要带上，每天调用 2000 次，一个月按 30 天算。

• →每月光系统提示词就是 2000 × 2000 × 30 = 1.2 亿 token；
• →多三成，就是每月多出约 3600 万 token；
• →按 Claude Opus 5 官方定价页的输入价 5 美元每百万 token 计，每月多出 36 × 5 = 180 美元；
• →三年是 6480 美元。

这三步乘除都是本文自己算的，口径要写清三点：第一，2000 token、2000 次/天 是假设值，你把它换成自己的实际值，结论会变；第二，只算了系统提示词这一段，没算用户输入和输出；第三，30% 是官方给的近似值，官方同时写明具体幅度取决于内容。

但这笔账真正的用处不是这个数，而是它指出的那件事：

所以从第一天起，提示词就该有版本、有责任人、有一份能在半天内跑完的回归用例。下面两节先讲回归用例，因为它是另一件的前提。

三、最小回归用例清单：七步，一个不许超的上限

这七步有顺序，别跳。全套跑一遍的目标是半天之内出结论，超过半天说明用例集太大了。

第 1 步。先跑「报错清单」，只看状态码，不看效果。

把你所有在跑的调用翻出来，只查三件事：有没有设 `temperature`／`top_p`／`top_k`；有没有用 `thinking` 的旧写法带 `budget_tokens`；有没有硬编码某个具体的模型 ID。三件事各出一份清单，这一步的产出就是三个数字。这一步做不完，后面六步都是空谈。

第 2 步。选 20 条真实历史输入当回归集。20 条是上限，不许超。

超过 20 条，这套就会从「每次换模型都跑一遍」退化成「攒了三个月也没人跑」。选法固定：10 条最常见的、5 条最长的、5 条历史上出过错的。 必须是真实发生过的输入，不许自己编——编出来的输入会绕开你真实数据里那些奇怪的地方，而那些地方正是会出事的地方。

第 3 步。给每条用例写一句判定语句，只允许三种形式。

三种形式是：必须包含某个字符串；必须不包含某个字符串；必须能被下游那段程序解析成功。「看着还行」不是判定语句。 写不出这三种之一的用例，说明这件事的验收标准还没定，先把标准定了再回来。

这一步最费时间，也是唯一一次性投入：判定语句写完之后，以后每次换模型都是复用。

第 4 步。先用你正在用的那个模型跑一遍，把 20 条的输出原样存下来。

这是基线。注意这份基线不是业务指标的基线，是字面输出的基线——它回答的是「同一句输入，新模型给出的东西还满不满足那句判定」，不回答「效果好不好」。两件事别混在一张表上。

第 5 步。换新模型跑同一份，逐条对。允许失败的上限是 2 条。

20 条里挂 1 到 2 条，属于提示词层面能修的，改提示词、重跑。挂 3 条及以上，就不是改提示词的问题了。 那说明你的流程依赖了这一代模型的某个具体行为，要改的是流程或者是下游那段解析代码。我的建议是遇到这种情况先停下来，别把时间花在反复调那几句提示词上——那是这套清单最常见的失败方式。

第 6 步。把删掉的旧指令单独存一份。

第一节那两条官方建议要你删掉自检指令和冗长度期待。删掉不等于扔掉。 单独存一个文件，标明是从哪个版本删的、为什么删。理由很实际：回滚的时候要用；以及下次换到另一家的模型时，那几句可能又要加回来。

第 7 步。新旧两套并行跑满两周，再切全量。

两周不是拍的，是为了盖住一个完整的业务周期——月初月末、周一周五、有促销和没促销。这两周里旧的那套继续承接真实流量，新的那套只跑影子请求，两边的输出每天抽 10 条人工对一次。跑满两周没出新问题，再切。

四、版本与责任人：三个字段，和一条别把资产存在别人家的规矩

回归用例解决的是「换的时候怎么验」，这一节解决的是「换之前你知不知道自己有哪些东西要验」。

每一条正在生产里跑的提示词，至少要有三个字段：版本号、责任人、它绑定的那个模型 ID。

第三个字段最容易被漏，而它恰恰是必需的。Anthropic 的模型总览页写着一条：每个 Claude 模型 ID 都是一个钉死的快照；从 4.6 这一代开始，模型 ID 用的是不带日期的写法，但它同样是钉死的快照，不是一个会自动指向最新版的指针（原文 a pinned snapshot, not an evergreen pointer）。

这句话对你的意义是：你不可能靠「一直用最新的」来回避这件事。 你的提示词永远是绑在某一个具体版本上的，区别只是你自己知不知道绑的是哪一个。三个字段里的第三个，就是让你知道。

责任人那一格也有一条硬规矩：一条提示词只能有一个责任人，不许写部门名。 写部门名等于没有责任人，60 天的通知邮件发到公司邮箱之后，会停在一个没人认领的位置上。

还有一条容易被当成技术细节、其实是资产归属问题的：别把提示词资产存在供应商的平台功能里。

据 OpenAI 的弃用页面，2026 年 6 月 3 日的一批公告里有三条：Reusable Prompts API 于 2026 年 11 月 30 日关停，官方给的迁移方向是迁回你自己的应用代码；Evals Platform 同日关停，迁移方向是第三方工具；Agent Builder 同日关停，迁移方向是 SDK 或工作区。

这三条放在一起读，结论很直白：你存在别人平台上的提示词和评测集，会跟着那个平台功能一起下线。 模型下线至少还有 60 天通知和一张明确的对照表，平台功能下线给你的是一句「迁回你自己的代码里」。

所以最小配置是三件东西，都在你自己这边：一个存提示词全文的文件、一张记着版本／责任人／模型 ID 的表、一份 20 条的回归集。三样都不需要买任何工具，一个共享文档夹就能装下。先把这三样凑齐，再谈要不要上提示词管理系统。

五、什么时候不该这么做

第一，你总共只有三五条提示词、每天调用几十次。 那么这套清单的建设成本大于它能省下的钱。这种规模下正确的做法只有第 1 步：把三件报错清单查一遍，其余六步先别做。等到调用量上去了，或者第一次换模型把你坑过一次，再回来建。

第二，回归集会腐坏，而腐坏的回归集比没有更糟。 业务改了，那 20 条用例里有几条已经不代表真实输入了，但它们还在挡着——新版本明明更好，却因为挂在几条过期用例上而被拦下来。我的建议是每个季度清一次，清的时候只做一件事：把不再出现于真实流量里的用例删掉，补上新出现的。 清完还是 20 条，不许趁机涨到 30 条。

第三，并行跑两周意味着这两周的模型调用费大约翻倍。 这笔钱要提前报，不能等账单出来再解释。如果两周翻倍的钱你批不下来，那就把并行期缩到一周，但别缩到零——直接切全量的代价不是钱，是你会在切完之后才发现问题，而那时候旧的那套已经停了。

第四，如果你的提示词是外部供应商在维护的，这套清单对你不成立。 你要的不是回归集，是合同里的两句话：模型变更需要提前多少天书面通知；变更后的验收标准是什么，由谁跑、跑什么。这是采购问题，不是技术问题，用技术手段解决会很贵而且解决不了。

最后回到最开头那个问题：换了模型，提示词资产会不会作废。

会作废一部分，而且比例没有人能提前告诉你。 但这句话真正的重点不在「作废」上，在「一部分」上——你之所以怕换模型，是因为你说不清那一部分有多大。而那 20 条用例、那三个字段、那两周并行，全部只做一件事：把「不知道会坏多少」变成「知道坏了哪两条」。

从不知道到知道，中间隔的不是技术，是半天。

这套回归用例与兜底规则的完整模板，在《数字员工搭建实战》第 5 课。