托管模型升级前，用固定用例把住验收关

模型 API 还能返回 HTTP 200，不代表业务仍然正确；模型名称变了，也不代表应用必须停用。作者提出了一套面向中小企业的模型变更验收方法：先辨认变化发生在哪一层，再用固定用例比较，最后只批准测试覆盖到的使用范围。

这篇的价值在于把关注点从回答好不好，拉回到整个应用是否还能安全运行。不过，标题里的 14 项检查是合成测试方案，没有调用真实模型，也没有生产测量结果。它适合拿来设计发布流程，不能拿来证明某家供应商可靠。

模型更新，究竟应该测哪一层

作者先拆开了几种容易混在一起的事件：模型退役涉及停用日期和替代方案，别名迁移涉及版本可复现性，请求与响应结构变化涉及接口兼容，行为变化才涉及任务质量。价格、配额、隐私设置和工具权限，又是另外几组问题。

例如，供应商宣布了替代日期，只能证明旧配置需要迁移，不能证明替代模型能保住当前质量。同样，一个熟悉的模型别名，也不能自动充当固定版本。

原文以 OpenAI 的 snapshot 和退役文档说明版本与生命周期记录的必要性；提到 Anthropic 的通知政策时，则强调其自营平台和合作平台可能不同。这里没有给出具体通知天数，也不应推导出全行业统一承诺。

真正要保存的测试对象，是整个工作流配置：provider、产品入口、请求模型字符串、endpoint、tenant、相关 region、日期、system instructions、工具定义、检索语料版本、parser 和后处理逻辑。凭据与密钥必须排除。

验收结论属于被测的工作流配置，不能直接归因给模型本身。

新模型配只读工具，旧模型配广泛写权限，即使结果不同，也只能比较这两个系统版本。供应商不返回底层版本时，应记录「not available」，不能从别名猜版本，更不能把回答变化直接认定为静默更新。

接口通了以后，还要守住哪些边界

接口验收需要同时覆盖成功与失败。作者要求至少准备一个有效的最小请求和一个故意无效的请求，检查必填字段、默认值、长度限制、结构化输出和工具声明，并使用生产中的 SDK 与 parser。

响应端则要区分正常回答、无内容、截断、类型异常、拒绝和格式损坏。错误对象不能被解析成正常回答，拒绝也不能在后处理时被剥掉。结构校验失败后，应进入人工复核、补充信息或预先定义的非 AI 路径；让模型自行修复必须有次数限制和独立校验。

质量评分也要落到可观察的条件。发票摘要要保留哪些字段，哪些判断需要来源，不确定时能否停止推断，都应在测试前写清。候选配置是否达到最低标准，和它是否比旧配置退步，是两个判断，不能用一个平均分代替。

涉及外部操作时，要求更严格。测试应使用不会影响客户或记录的替身接口，确认模型只能提出动作，执行权由应用层控制。审批界面需要展示收件人、金额或改动字段，权限必须由服务端执行。

超时重试还会带来重复操作：写入可能已经成功，只是响应没有回来。作者建议在业务操作边界实现幂等，重试前查操作记录；模型请求 ID 未必能阻止重复退款或重复发送。

14 个场景能决定发布，却证明不了可靠性

这套方案写于 2026-11-05，样本是 14 个合成场景，没有真实 endpoint、生产记录或模型输出。它能帮助检查系统如何处理超时、限流、服务端错误、部分响应和重试耗尽，但不能估计错误率、安全性或服务可用性分布。

原文标题称有 14 项检查，但提供的编号正文只到第 11 项，后面又称有 14 个场景。完整场景与编号检查如何对应，输入没有交代。

成本评估也不能只看 token 单价。作者主张计算每个验收合格任务的成本，把检索、工具、重试、人工审核、修正，以及被拒绝或升级处理的任务算进去。14 个合成场景不足以推算月账单，还需要实际流量或明确的工作量假设。

隐私证据则要落实到当前账号：保留期限、训练用途、region、日志和访问设置都应核实。供应商的通用介绍不能替代 tenant 证据，推理处理区域也不能直接等同于存储区域或支持人员访问范围。

结果分为 Pass、Fail、Unknown。Unknown 表示证据不足，并非通过。低影响功能可以在明确限制下接受某些未知项，但不能据此宣称相关条件已满足。

原文的 Python 示例只读取保存的 JSON，不发起 API 调用。下面这段定义了示例门槛和必需的用例编号：

import json
import sys
from pathlib import Path

THRESHOLD = 0.90
REQUIRED = {f"C{i:02d}" for i in range(1, 15)}

要看清 THRESHOLD = 0.90：这是示例政策值，不是行业标准；REQUIRED 要求的是 C01 到 C14。提供的源码在分数校验表达式中途截断，无法据此运行完整门禁，也不能确认后续实现是否兑现了「硬门槛失败就阻断发布」。

我的判断

我赞成它把权限、接口、数据控制和质量评分放在同一个发布流程里。对于能发消息、改记录的应用，一次越权执行不能被其他高分抵消。允许系统在证据不足时澄清或停止，也比一味奖励回答完整更符合业务需要。

它的局限同样明确：这是一套方法提案，没有新旧模型对照结果，没有证明 14 个场景足够，也没有验证 0.90 的门槛合理。Google 的部署测试指导能支持版本比较和显式阈值，不能替这份具体清单背书；社区里的静默回退讨论也只是个案。

和临时试几个提示词相比，固定用例加配置记录更便于重复执行；和持续评估、线上监控相比，它只是发布前的一道检查。作者也承认，小样本通过不能保证未来所有输入。

中小团队可以按影响范围缩减检查深度。内部草稿助手与退款流程不必承担相同成本，但缩减应有依据。回滚也要核实旧配置是否仍可访问：已退役的模型无法靠保留配置重新上线。

能拿来做什么

• 给现有 AI 功能建立配置清单，记录模型别名、endpoint、负责人、提示词和检索版本，并把供应商通知关联到受影响的工作流。
• 在 Node 调用边界加入请求与响应校验，用固定样本覆盖空响应、拒绝、格式损坏和限流，确认前端能展示相应状态。
• 给发送消息、更新记录等工具接入无副作用的测试替身，检查服务端权限、明确审批和超时后的重复执行处理。
• 在换模型前写好最低质量标准、硬性失败条件与预算上限；保留旧配置结果，并核实回退权限和停用日期。