你的备用路径是生产环境中唯一未经测试的代码

每个成熟的 AI 系统都会配备回退方案（fallback）。当主模型被限流时，路由到更廉价的模型。当服务商返回 5xx 错误时，提供缓存的答案。当置信度低于阈值时，回退到手写的启发式规则（heuristic）。架构图中有一个清晰的小分支，标注为“降级模式”（degraded mode），每个人都因此感到更安全。

令人不安的部分在于：那个分支是系统中几乎从未运行过的唯一代码。主路径每天执行数百万次，并经过大量流量的调试、性能分析和实战测试。回退路径几乎从不执行——直到某天，它在负载下、在事故期间、在三名工程师看着仪表盘变红时，突然为所有人同时执行。

一个你不练习的回退方案并不是冗余。它是一个不受监控的第二系统，其“首秀”在统计学上注定会发生在最糟糕的时刻。

只在灾难期间运行的代码，就像从未运行过的代码一样在腐烂

软件腐烂并不是因为它在变化，而是因为它在原地踏步，而周围的一切都在改变。你的主 Prompt 每周都会被编辑——有人收紧了系统指令，添加了 Few-shot 示例，更换了模型版本。你的输出 Schema 增加了一个字段。你的下游解析器学会了期待那个字段。

回退路径注视着这一切发生，却并未参与其中。它的 Prompt 是六个月前主 Prompt 样子的“化石”。它的输出 Schema 上次针对解析器进行验证还是在两个过时的重构版本之前。它路由到的廉价模型早就在供应商的发布说明中被弃用了，而你团队中没人读过那些说明。

这些问题都不会浮现，因为回退路径没有运行。CI 捕获不到，因为 CI 运行的是测试覆盖的路径，而没人会为他们假设永远不会触发的分支编写测试。代码审查捕捉不到，因为破坏回退路径的 Diff 是对“主”路径的修改——回退路径成了附带损害，无声且处于监控视野之外。

这与几十年来一直困扰灾难恢复（DR）的失败模式如出一辙。最常见的备份失败并非备份本身无声停止工作，而是备份的“恢复”过程从未运行过，导致团队在真正的事故中才第一次发现漏洞。调查一致发现，只有大约一半的组织每年测试其灾难恢复计划。俗话说，未经测试的备份只是一个假设，而不是安全网。你的回退路径正是那个假设——更糟糕的是，它比没有回退方案具有更坏的特性：它制造了虚假的安全感。架构图显示你已经得到了保护，因此在生产环境停止协作之前，没有人会去真正承载并测试这个假设的承受能力。

停机终将到来——问题在于回退方案是否准备就绪

这不是一个你可以推迟的虚构风险。在 2025 年，每家主要的 LLM 供应商都至少经历过一次重大中断。公开的事故追踪器记录了各大 API 的数百次停机。一家供应商的状态数据显示，一年内发生了近 300 起事故；另一家在短短 90 天内记录了超过 100 起事故，其中数十起是重大事故。一家供应商因路由节点达到内存限制、未通过就绪检查，导致级联成容量不足，最终无法为任何人提供服务，经历了长达数小时的停机。

如果你依赖模型 API，你的回退路径“一定”会被调用。唯一悬而未决的问题是，届时它是否能正常工作。

这里的“正常工作”比团队设想的门槛更高。回退路径的触发并不等同于回退成功。思考一下在降级路径启动的那一刻，实际上必须满足哪些条件：

• 廉价模型或备份模型仍然存在并接受请求。
• 回退 Prompt 生成的输出仍符合解析器预期的 Schema。
• 你提供的缓存响应没有陈旧到错误的程度。
• 断路器（circuit breaker）确实触发了，并且是在几秒钟内而非几分钟内针对正确的信号触发的。
• 回退路径的延迟和 Token 成本本身不会级联成第二次故障。

其中的每一项都是一个活生生的假设。每一项都会发生漂移。而你第一次发现哪些环节断裂的时候，正是事故发生的时刻——除非你在此之前有意识地练习这条路径。

加载中…