多个模型出现较高错误率

故障症状和状态页

• 用户报告 Claude Code 和 claude.ai 出现广泛的 500、503 和 529（“过载”）错误；有些会话可用，而另一些会超时，说明基础设施影响并不均匀。
• 状态页显示许多红色/橙色事件（“圣诞装饰” / “full three pepper blend”），动态时间窗口还会根据视口宽度改变所报告的可用性。

可用性指标与感知到的影响

• 公布的可用性：claude.ai 约 99.1%，“Claude for Government” 约 99.3% 以上，Claude Code 更低。
• 有人认为对于核心工作工具来说，<99.9% 很差，尤其当故障集中在美国/欧洲工作时间；也有人说即使有宕机，生产力提升仍然值得。
• 有些人希望看到“我所在时区工作时间内的可用性”，而不是汇总后的 SLA。

对 AI 工具的依赖与基础技能

• 许多人承认在现实软件工作中高度依赖 AI/互联网；其他人坚持即使离线也能开发，只是更慢。
• 有人担心未来开发者在没有 LLM 的情况下会失去编写或维护大型文档/代码库的能力。
• 反方观点：工具宕机时，团队会“回到基础水平”，因此长期生产力总体仍是正收益。

替代方案、harness 和生态复杂性

• 有人建议尝试 pi、OpenCode、Codex、GLM‑5.2、DeepSeek、Zed、pool、oh-my-pi、openrouter 等。
• 体验褒贬不一：有些人觉得 pi 灵活且可扩展；另一些人则报告称，在同一模型上与其他 harness 相比，pi 的 token 消耗和延迟都很高。
• 许多人现在同时使用多个模型/harness 以及新兴标准（MCP、ACP），并指出复杂性不断增加，工具变化很快。

安全性与 curl | sh 安装器之争

• 长篇子讨论争论是否把网上的安装脚本直接管道给 shell。
• 批评者称这不负责任，并且存在供应链风险；支持者认为这无处不在、很方便，而且通常只是对包管理器的一层封装。
• 讨论涉及信任模型、包管理器与临时脚本，以及这种做法是否会“训练”用户形成不安全行为。

根因：基础设施 vs “AI 编写”的系统

• 有人将责任归咎于 Anthropic 大量内部使用 agentic loops 和 AI 编写代码，认为故障暴露了“Claude 导向编程”的局限。
• 也有人反对这种说法，认为这是“把一切都怪给 AI”的谬误，并指出大规模基础设施历来都很难，完全可能因为许多非 AI 原因而失败。
• 争论集中在这些事件到底体现了文化/工程问题，还是只是快速增长和基础设施不成熟；目前没有明确证据。

LLM 的本质与局限

• 一些开发者把 LLM 描述为“加强版概率随机表”：适合想法、调试帮助和 rubber-ducking；但作为自主编码者并不可靠。
• 举出的例子包括荒谬但自信的代码（用基于字符串的十六进制检查代替整数比较），进一步说明需要严格的人类审查和护栏。
• 有人认为非确定性和幻觉是内在属性；工作流必须使用窄提示、短视野和分层检查才能可靠。

定价、锁定与未来场景

• 有人猜测，一旦公司形成依赖，供应商就会提价，并担心企业会被锁定多年。
• 也有人指出竞争存在（OpenAI、开源模型、多个 harness），并预计理性的组织会采用多供应商策略，而不是依赖单一提供方。
• 还有人认为按席位计费的高额 AI 成本在许多任务上仍可能比人类开发者更便宜，但也怀疑当前工具能否完全替代工程师。

文化与幽默反应

• 很多人把这次故障当成被迫休息：去“touch grass”、过节、做规划，或者像“90 年代那样”写代码。
• 段子包括“Claude for Government”可用性更好、AI 数据中心让地球升温、内部“备用 Claude”其实是人类，以及 Anthropic 用 Gemini 或 DeepSeek 来修 Claude。
• 玩笑之下，是对越来越依赖脆弱云 AI 服务的焦虑。