事故与变更：十四次模型升级、三次回归失败与一次四小时故障

客户不关心你换了哪个模型，他们关心的是：换的时候，有没有人拦一下。

一、四小时二十一分钟，回复全挂

2026 年 10 月的一个周二，主供应商返回大量 5xx。早上九点开始，到下午一点二十一分恢复，持续 4.2 小时；这段时间里，商家的 AI 草稿全部失败，客服只能手打。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

周闻当时在开会，手机静音。第一个发现的是客户，第二个是状态页的监控。等他打开电脑，已经有 7 家商家在群里问「是不是崩了」。

故障不可怕，可怕的是客户比你先知道。 这次之后，他把「谁先知道」写进了值班规则，而不是只加一条监控。

二、十四次升级：变更要能被叫出名字

一年里，主供应商发布了 14 次影响输出的模型变更。他把每次变更都记成一条。

14 次 × 4.4 小时 = 61.6 小时/年。4.4 小时里，跑一次评测约 1 小时，人工抽查约 1.5 小时，写记录与通知约 1 小时，剩余是排期与沟通。

变更记录的第一个用途是定位。 客户说「上周还好好的」，你能翻到上周有没有变更；没有记录，就只能靠记忆，而记忆通常不准。

第二个用途是谈判。供应商变更导致质量下降时，一份带日期的回归结果，比一句「感觉变差了」有力得多。

版本要固定，不能默认跟随最新。他的做法是在配置里写死模型版本，供应商发布新版本时先灰度 5% 流量，跑完回归再全量；这一步多花两小时，能省掉一次事故。

固定版本也有代价：你会错过改进。所以固定不是永久，而是「有意识地升」；每次升级都要有一条记录，而不是被动接受。

变更通知要订阅三个地方：供应商邮件、状态页、开发者公告。只靠邮件，你会漏掉在控制台里直接生效的变更；只靠状态页，你会漏掉提前两周的预告。

错过通知不是小概率事件。他的做法是每月初花 15 分钟翻一遍供应商的变更日志，和上月记录对照；15 分钟能发现的问题，事后要花一天。

三、回归门禁：三次失败拦下了什么

14 次变更里，3 次回归失败，占 21.4%。三次都不是「模型变笨了」，而是具体的能力回退。

门禁规则只有一条：政策类与拒答类不允许任何一条回退。 事实类允许 2 条内波动，语气类允许人工判断。

这条规则看起来严，但它对应的是钱。政策错一条可能赔一次款，拒答错一条可能编出一条不存在的条款；语气差一点，最多是体验问题。

三次失败里，第 1 次最值得记。供应商说「只是小版本」，但评测显示政策类掉了 4 条；如果没有门禁，这次升级会直接上线。

第 2 次暴露了另一个问题：失败不是二元的。加了提示约束后重跑通过，说明模型能力还在，只是默认行为变了；这种情况不该直接拒升级，而该改提示。

第 3 次是「接受失败」。语气变生硬不影响正确性，改提示词补偿即可；门禁不是「全部通过才能上线」，而是「每一类失败都要有处置」。

门禁的价值在于「有权限说不」。 如果每次失败都被解释成「问题不大」，门禁就退化成了通知。

门禁要能在一天内跑完。120 条用例跑一遍约 1 小时，人工抽查 1.5 小时；如果排不进当天，就延后升级，而不是「先上线再补测」。

延后也有成本：供应商可能在一周后强制下线旧版本。他的缓冲是提前两周收到预告，用第一周跑回归，第二周灰度；两周是能安排开的最短窗口。

四、降级与三个通知渠道

供应商故障时，产品要能降级，而不是整体不可用。

他平时的流量是 A 80%、B 20%，B 不是备用而是常备；这样切换时 B 已经在跑真实流量，不是「从没上过场」的备份。

降级要有质量差异的预期。B 的事实类通过率比 A 低 3 条，切换后评测报告会变；这个差异要提前写进文档，否则客户会以为「降级后变笨了」是新问题。

通知走三个渠道：状态页、邮件、站内横幅。状态页给所有人看，邮件给付费客户，站内横幅给正在用的人；三个渠道各 10 分钟，故障当天就要发第一条。

第一条通知不需要原因，只需要三件事：什么功能受影响、现在是什么状态、下一次更新什么时候。原因可以等复盘，状态不能等。

4.2 小时的故障里，第一条通知在 9 点 40 分发出，距开始 40 分钟。这个速度不算快，但比「等修好再说」好得多；客户知道你在处理，就不会另找方案。

复算：
变更：14 次/年 × 4.4 h = 61.6 h/年
失败：3 ÷ 14 = 21.4%；政策 1 + 拒答 1 + 语气 1
门禁：政策与拒答零回退；事实 ≤2 条；语气人工判
故障：1 次 × 4.2 h（09:00–13:21）
通知：3 个渠道（状态页 / 邮件 / 站内），首条 40 分钟内
降级：A 80% / B 20%，切换阈值错误率 5% × 5 分钟

61.6 小时是变更成本，不含故障处理。故障的 4.2 小时只是「不可用时长」，真正的成本是之后的复盘、客户解释与补偿，通常是它的两到三倍。

五、行动清单与复算验收

• 在配置里固定模型版本，不默认跟随最新。
• 每次变更记编号、时间、内容、回归结果与处置。
• 设一条门禁：政策与拒答零回退。
• 新版本先灰度 5%，跑完回归再全量。
• 保持第二供应商常备流量，而不是冷备。
• 定义降级阈值与回退路径。
• 准备三个通知渠道，写好第一条通知模板。
• 每次故障后 7 天内出一页复盘。

验收标准：任取一次模型变更或故障，都能说出时间、影响范围、处置与结果。

前四条是「让变更可见」，后四条是「让故障可控」。如果只有一小时，先做第三条：没有门禁的变更，等于把质量交给供应商的发布节奏。

使用边界与实操验收

本文不评价供应商。 变更频率、故障率是各家的运营特征；这里只讲一人产品怎么接住它们。

固定版本不等于永远不升。 长期不升会积累技术债，也会错过安全修复；固定是为了「有控制地升」。

降级不是免费的。 第二供应商的质量、价格与延迟都不同；切换前要算清差异，不能假设「备用的和主的一样」。

通知要诚实。 不知道原因就说不知道，不要写「正在优化」；客户能接受故障，不能接受模糊。

事故分级要提前定。 什么算 P1、谁来决定通知、多久更新一次，故障当时再讨论就晚了。

本文的数字是教学假设。 14 次、3 次、4.2 小时都是演示口径，换成自己的产品要按实际重算。

变更与事故要写在同一个清单里。 分开记，你会忘记「这次故障是不是上次变更引起的」；同一条时间线，才看得出因果。

关键参考与核验范围

• NIST AI 风险管理框架 ：用于核对变更管理、监测与事件响应的通用流程。
• NIST 生成式 AI 风险画像 ：用于核对供应链依赖与模型变更相关的风险条目。
• OWASP LLM Top 10 ：用于核对供应链与模型依赖的风险分类。

以上链接于 2026-10-27 实测可公开访问；未核验版本、条款更新与适用范围。核验日期：2026-10-27。

范围上只讨论一人产品如何管理模型变更与供应商故障，不评价任何供应商的服务水平，也不提供法律意见。

系列导航

• 上一篇：内容与版权：一次相似投诉、四十八小时下架与七个数据来源
• 下一篇：AI 合规验收：十二项检查、四维评分与一次客户审查演练
• 回到目录：一个人的 AI 合规：六个功能、二十二项供应商条款与一次客户审查
• 相关阅读：一个人的运维：可用性、告警、事故与值班