Claude.ai 不可用：比网页宕机更麻烦的是工作流被卡住

2026 年 4 月 28 日 17:41 UTC，Anthropic 状态页开始调查 Claude.ai 无法访问的问题。10 分钟后，17:51 UTC，事件被标记为 Identified。

真正刺眼的地方不在“网页打不开”。同一条状态更新里，Anthropic API 出现 elevated errors，Claude Code 登录路径也受影响。

这说明 Claude 已经不是一个聊天框。它正在变成开发、办公和企业流程里的一个节点。节点一抖，工作流就跟着抖。

状态页只说到这里，别替它脑补

这次能确认的信息并不复杂，压缩成一张表就够了。

受影响对象包括：claude.ai、Claude Console（platform.claude.com）、Claude API（api.anthropic.com）、Claude Code、Claude Cowork、Claude for Government。

边界也要说清楚。

状态页没有给出故障原因。没有影响范围数字。没有恢复时间。没有根因分析。

Claude for Government 被列为受影响服务，不等于政府系统出现安全事件。API elevated errors，也不等于所有 API 请求全部失败。

该克制就克制。状态页不是惊悚小说素材。

真受影响的是两类人：开发者和企业技术负责人

个人用户打不开 Claude.ai，会烦。开发者遇到 API elevated errors，麻烦就具体多了。

如果你的产品把 Claude API 接进客服、知识库、代码生成、文档处理或内部审批，错误率升高可能带来三件事：接口失败、调用重试、业务超时。用户看到的未必是“Claude 挂了”，而是你自己的产品变慢、报错、不可用。

依赖 Claude Code 的开发者也一样。登录路径出问题时，影响不一定是代码全部停摆，但会卡住一部分高度依赖云端工具链的人。越把 AI 编码助手当日常入口，入口故障时越难受。

企业技术负责人现在该做的不是恐慌换供应商，而是补三张清单：

• 哪些业务允许 AI 调用失败后降级；
• 哪些业务必须切到备用模型或传统流程；
• 哪些岗位不能把 Claude Code、Console 或单一 API 当唯一入口。

采购也会变谨慎。不是不买 Claude，而是合同里要问 SLA、故障通报、状态页更新频率、日志可见性、备援方案。模型能力可以打动演示现场，可靠性才会影响上线审批。

我不太买账的是一种轻飘飘的说法：AI 只是助手，挂了也没什么。

很多公司嘴上说它是助手，流程里已经把它当主干。差别就在这里。

AI 越像基础设施，分水岭越不在演示视频里

过去讨论大模型，大家喜欢比上下文窗口、推理能力、代码能力、价格。这些都重要。但 AI 进了 IDE、客服系统、内部知识库和政府服务之后，问题变了。

模型看着更强，产品反而可能更脆。

电力就是老例子。平时没人夸插座伟大，断电十分钟，整栋楼才知道依赖有多深。云计算也一样，单次故障不一定说明厂商不行，但会照出客户有没有多区部署、降级预案和供应商冗余。

AI 平台正在走同一条路。不同的是，AI 还更容易被包装成“智能生产力”，让人忘了它本质上也是远端服务、账号系统、API 网关、控制台和权限链路的组合。

“天下熙熙，皆为利来。”厂商愿意把 AI 塞进更多场景，因为调用量、黏性、企业合同都在里面。用户要看另一半账：集成越深，故障成本越高。

这次还看不清的问题，反而更关键：

• 故障持续多久；
• 恢复后是否会给出根因；
• API elevated errors 的影响范围有多大；
• Claude Code 登录路径是否存在可绕开的备用方式；
• 企业客户能否拿到比公开状态页更细的通报。

这些问题比“Claude 是否还强”更现实。

一次事故不能推出 Anthropic 能力衰退，更不能直接说成商业危机。大规模在线服务都会出问题，云厂商也出过。

但行业该少讲一点神话，多讲一点断链时怎么活。

这次状态页打开了一个小窗口。窗口里能看到的，不是某个网页的尴尬，而是 AI 基础设施化后的新账本：能力是收益，依赖是成本，冗余是保险。

底盘不稳，再聪明的助手也会把人晾在半路。