6月2号早上，我打开电脑准备跑一个数据处理脚本，后台调用的是Claude API。结果请求全部超时，返回500错误。
一开始以为是自己代码的问题，排查了半小时。后来去查了Claude Status页面，发现不是我的问题。Claude全线宕机了，包括Web端、API、Console和Claude Code。
这不是第一次。根据status.claude.com的记录，6月第一周就出了5次故障，分别在6月2号、3号、5号、7号和8号。最严重的是6月5号那次，从UTC时间15:08开始，整整宕了将近2个小时。
一个让人后怕的事实
我之前没认真想过一个问题：我的产品里有多少地方强依赖了单一AI API？
跑了一遍代码之后发现，内容生成、用户意图分析、自动摘要，三个核心模块全走Claude。也就是说，Claude一挂，我的产品基本就废了。
ThoughtWorks有篇博客说得挺到位的：2026年Claude已经多次宕机，但6月这次感觉不一样，因为现在太多生产系统依赖它了。AI从玩具变成了基础设施，但基础设施的可靠性并没有跟上。
我做了什么
花了两天时间重构了API调用层。思路很简单：不要把鸡蛋放一个篮子里。
**第一件事：加了个路由层。** 主用Claude，如果连续3次请求失败或延迟超过30秒，自动切到备用模型。我选的是GPT-4o-mini做降级，便宜够用，处理日常任务没问题。关键业务路径上用Claude，因为质量确实好，但加了超时和重试逻辑。
**第二件事：本地缓存常见请求。** 用户高频问的那些问题，结果直接缓存到Redis里，TTL设了24小时。API挂了的时候，至少老用户还能拿到缓存的回答。不完美，但比白屏强。
**第三件事：异步队列+死信队列。** 之前所有API调用都是同步的，用户等着拿结果。现在改成异步，写进队列由worker消费。失败了进死信队列，等API恢复了重试。对用户体验的影响是：某些场景下响应变慢了几秒，但不会直接报错。
算了一笔账
加这层容错花了大概2天开发时间，每月多支出15美元左右的Redis和队列服务费。
但反过来想，6月2号那次宕机如果发生在有付费用户的高峰期，按照我目前的用户量估算，损失可能在200到500美元之间。投入产出比很划算。
Stanford 2026 AI Index报告里提到一个数据：开发者对单一AI供应商的平均依赖度从2024年的73%下降到了2026年的51%。趋势是对的，但还有一半的人没做冗余。
一些踩过的坑
OpenRouter这类聚合API看起来是完美方案，一个key调所有模型。但实际用下来，它自身也是个单点。我遇到过OpenRouter自己宕机的情况。所以我的建议是：聚合服务可以做备选，但主链路尽量直连。
另一个坑是模型之间的格式兼容。Claude的system prompt格式和OpenAI不一样，Function Calling的schema也有差异。做降级的时候，prompt和参数都要做适配。我写了个转换层来处理这个，不复杂但要测。
还有个容易忽略的点：成本监控。开了备用模型之后，如果主模型反复失败，备用模型会被疯狂调用。我设了日消费上限，超过就告警。有次Claude连续抖动半小时，GPT-4o-mini帮我跑了几千次调用，花了几美元。不多，但没有监控就是隐患。
我的判断
AI API的可靠性会越来越好，但不会做到100%。云服务AWS、GCP也偶尔宕机，AI API不会例外。
作为独立开发者，我们能做的是接受这个现实，然后在架构上预留容错空间。不是说每个项目都要上多区域多活这种大厂方案，但至少做到：主备切换、缓存兜底、异步解耦。
这三板斧搞下来，大部分API抖动对用户来说就是响应变慢了几秒，而不是直接看到报错页面。
如果你也在做依赖AI API的产品，建议现在就花半天时间检查一下：你的API调用有没有超时设置？有没有重试逻辑？主模型挂了有没有备选方案？
别等下一次宕机才想起来这事儿。
