Claude 部分故障

原文 ↗ Hacker News 讨论 ↗

Anthropic 的 Claude 服务——包括 claude.ai、Claude Code、Claude Cowork 和 API——发生了部分故障，引发了对频繁宕机、状态报告不可靠，以及如今高度依赖单一 AI 供应商的工作流脆弱性的抱怨。评论者将 Claude 新模型的强大能力与其被认为较差的可靠性进行对比，讨论了多模型冗余等策略（例如将 Claude 与 OpenAI 结合），并指出大型 AI 故障会如何扰乱个人生产力和新兴的基于代理的自动化。这起事件也引发了人们对过度依赖中心化 AI 基础设施的更广泛担忧，以及当关键的“智能服务”失效时会发生什么。

故障描述与范围

  • 报告称 Claude.ai（网页、桌面端、移动端）、Claude Code、Claude Cowork，以及部分 API 请求出现了错误率升高和性能下降。
  • 问题包括请求失败、登录循环、项目/容器消失，以及自动模式分类器损坏。
  • 状态页从“正在调查”较快地切换到了“运行正常”；一些人认为在问题仍然持续时这过于草率。
  • 一些用户随后报告称服务似乎又恢复可用了。

用户影响与可靠性担忧

  • 处理时间敏感工作的用户，尤其是让代理处理大型 PR 的人，受到了干扰；在大 diff 上把工作从代理交接给人类被描述为很痛苦。
  • 多位评论者表示 Claude 每周都会出现“多次”故障，认为这对一款高端产品来说不可接受。
  • 可用性被视为采纳的主要限制因素，尤其是在企业深度依赖单一提供商构建工作流时。

状态页、监控与运维

  • 有几个人指出，在状态页仍显示绿色时，5xx 错误却持续了很长时间。
  • 有人呼吁更好的端到端监控；第三方故障追踪器被认为比官方状态页更准确。
  • 一些人把责任归咎于管理层推翻了良好的运维实践（变更控制、回滚、限流等），而不是技术上做不到。

对原因与业务背景的猜测

  • 猜测包括：IPO 新闻后注册量激增、过于激进的促销/折扣活动，或者认证系统承受了压力。
  • 少数人开玩笑或带着阴暗意味地猜测这是被刻意安排的故障，用来凸显依赖性；也有人认为这种看法太愤世嫉俗。

模型质量与使用模式

  • 多位用户称赞 Opus 5.5 相比早期模型以及 Fable 5.1 是一次重大跃升，并表示使用量高得多。
  • 一些人觉得更便宜/更快的档位现在已明显被顶级模型压制。

对 AI 的依赖与韧性策略

  • 讨论指出，故障暴露了对 AI 助手的过度依赖，举例有人把任务拖到“Claude 恢复再说”。
  • 建议包括：
    • 同时使用多个供应商/模型以实现冗余和交叉审查。
    • 保留本地/开源模型以提供基础能力。
    • 设计工作流（例如提交结构）以便工具之间更容易切换。

更广泛的反思

  • 与停电和断网作比较；人们担心日益加剧的中心化和单点故障。
  • 也有人展开哲学讨论：重度使用 AI 是否会侵蚀人类推理能力，还是只是改变了哪些技能会被练习。