| 2026年5月9日07:57—08:22 UTC(北京时间15:57—16:22) | Claude Opus 4.1 错误率升高 | claude.ai、Claude Console、Claude API、Claude Code | Pingoru 将其列为持续25分钟的事件,并显示“已识别问题、正在实施修复”,随后标记解决 。IsDown 也记录了同一 Opus 4.1 错误率升高事件,时长为24分钟 。 |
| 2026年5月9日23:33(第三方记录原文时间) | Claude Code 网页端部分中断 | Claude Code | DrDroid 记录“Claude Code on the Web Partial Outage”始于5月9日23:33,后续已解决 。Claude 状态页也显示5月9日 Claude Code 网页端部分中断已解决 。 |
关键区别在于:5月8日那条记录更像是 Claude Code 在 Windows 上的 IDE 扩展加载问题;5月9日 Opus 4.1 错误率升高,才是公开记录中同时波及 Web、Console、API 和 Claude Code 的事件 。把它们简单合并成一次“全 Claude 宕机”,容易夸大或混淆。
就5月9日 Opus 4.1 的错误率升高事件而言,目前可见公开记录没有提供详细根因复盘。Pingoru 的时间线只写到问题已识别、正在实施修复、事件已解决,并未说明底层原因 。
5月8日 Windows IDE 扩展问题相对更具体:Claude 状态页把它描述为 Claude Code 2.1.136 版本中的问题,导致 IDE 扩展无法加载 。这和全站级别的 Claude 服务不可用不是一回事。
用户的担心不完全来自这一次短暂波动,而是来自前后几个月的“反复出问题”感。ServiceAlert 的90天趋势表显示,2026年5月在其追踪的11天里有5天出现问题,2026年4月30天里有20天出现问题 。Maxim 的 Bifrost 状态页统计90天内有50起事件 ;IsDown 则称自2025年10月以来已追踪到211起 Claude 故障 。
这些统计来自第三方监测平台,不等同于 Anthropic 官方服务等级协议(SLA),而且不同平台可能把同一次波动拆分或合并得不一样。即便如此,它们说明了用户情绪的背景:短短一次错误率升高,落在一串“部分中断”“错误率升高”“服务不稳定”的记录之后,感受就不再是偶发小插曲。
2026年早些时候的报道也强化了这种印象。TechCrunch 报道,3月2日 Claude 出现广泛中断,影响 Claude.ai 和 Claude Code;Anthropic 当时称 API 按预期运行 。Business Insider 报道,4月7日 Claude 和 Claude Code 对许多用户不可用,Anthropic 仪表盘一度列出“major outage”,随后修复 。TechRadar 又报道,4月15日 Claude.ai、API 和 Claude Code 出现错误率升高,Downdetector 报告峰值超过5,100条 。
Claude 现在不只是一个聊天网页。5月9日 Opus 4.1 事件列出的受影响面包括 Web 应用 claude.ai、开发者 Console、API 和 Claude Code 。此前报道也提到,Claude 故障会暴露开发者对 AI 编程工具的依赖:工具不响应时,写代码、调试和交付节奏都会被迫改变 。
这就是实际的可靠性问题:如果 AI 助手已经嵌进代码生成、客服支持、资料检索或内部自动化,哪怕中断只有几十分钟,也可能造成排队、重试、人工接管和上下游流程延迟。对个人用户来说,Claude.ai 暂时打不开是麻烦;对团队来说,API 或 Claude Code 波动可能就是生产链路上的依赖失效。
5月8—9日的公开记录并不能证明 Claude 发生了一次单一、灾难性的整体崩溃。它们更准确地指向一组已解决事件:Windows 上 Claude Code IDE 扩展无法加载、一次短暂的 Opus 4.1 错误率升高,以及稍后的 Claude Code 网页端部分中断 。
但用户的可靠性焦虑并非小题大做。问题在于,同一批关键入口——网页、Console、API、Claude Code——反复出现在故障记录里,而公开事故说明又往往较短,未必包含根因细节 。对依赖 Claude 的团队来说,比较现实的做法是:
换句话说,5月8—9日事件本身不算长;真正值得追问的是,当 AI 工具越来越像工作基础设施时,团队是否已经为它“不在线”的时刻做好准备。