Claude 急了！模型降智，官方长文用 bug 搪塞？开发者怒怼“太晚了”：承认不达标为何不退钱？

“看得出 Anthropic 是真急了，都开始澄清了。”有网友在看到发文解释 8 月至 9 月初陆续出现 bug 的推文后表示。

“产品质量这么差。我之前不明白为什么，现在明白了。”开发者 Tim McGuire 在帖子下表示。

“我也是。同以前相比，之前用起来感觉就像有个可以分派任务的初级工程师，事情能完成，代码至少还算过得去。但最近的体验，更像是在和一只猴子打交道。”开发者 Peermux 说道。

Anthropic 将 8 月至 9 月初期间的模型质量下降问题，归咎于三项基础设施漏洞的影响。8 月初，许多用户开始上报 Claude 响应降级问题。Anthropic 坦承当时未能发觉用户反馈与正常波动之间的差异。到 8 月底，同类报告的频率和持续性越来越高，为此其展开调查，并发现三项互不关联的基础设施 bug。

“首先澄清一点：我们绝不会因需求、时间或者服务器负载情况的变化而降低模型质量。用户上报的问题纯由基础设施 bug 所导致。”Anthropic 强调。

Anthropic 还表示，“我们深知用户希望 Claude 始终提供稳定的质量表现，为此我们设定了极高的执行标准，以确保基础设施变更不会影响模型输出。但从近期事件来看，我们未能真正落实这些标准。以下剖析报告将解释发生了什么、为何检测和解决问题的时间比我们预期更长，以及我们将做出哪些调整以防止未来再次发生类似事件。”

“我们一般不会分享关于基础设施的技术细节，但考虑到此番问题的范围和复杂性，这次特做出全面解释。”Anthropic 说道。

具体发生了什么

如何支撑 Claude 的规模化运行

根据介绍，Anthropic 通过第一方 API、Amazon Bedrock 以及 Google Cloud 的 Vertex AI，为数百万用户支撑起了 Claude 服务体系。Anthropic 还在多种硬件平台上部署 Claude，包括 AWS Trainium、英伟达 GPU 以及谷歌 TPU 等，通过这种方式为全球用户提供服务所需的容量与地理分布支持。

每种硬件平台有其自身特点，需要配合相应优化。Anthropic 表示，“尽管存在种种变数，我们仍为模型实现制定了严格的等效标准。我们的目标是无论在哪种平台上，用户请求都能得到同等质量的响应。但由此发生的复杂性，也意味着任何基础设施变更都需要在所有平台和配置之上进行审慎验证。”

Claude API 事件时间表图解。黄色为检测到问题，红色为性能降级加剧，绿色为已部署修复程序。

这些 bug 的相互交织，导致诊断工作变得异常困难。第一项 bug 于 8 月 5 日出现，影响到指向 Sonnet 4 全部请求中的约 0.8%。8 月 25 日和 26 日，另外两项 bug 依次出现。

Anthropic 称，尽管最初造成的影响并不大，但 8 月 29 日的负载均衡变化导致受影响流量比例上升，使得更多用户遇到问题。但也正因为仍有大部分用户可获得正常服务性能，因此上报情况变得令人困惑且相互矛盾。

三个问题彼此交织

下面 Anthropic 具体介绍了导致服务降级的三个 bug，它们何时发生以及其处理办法：

1. 上下文窗口路由错误

8 月 5 日，部分 Sonnet 4 请求被错误路由至专用服务器——这批服务器实际是为即将发布的 1M token 上下文窗口所配置。这项 bug 最初影响到全部请求中的 0.8%。8 月 29 日，一次例行负载均衡变更无意间增加了被路由至 1M 上下文服务器的短上下文请求数量。到 8 月 31 日影响最严重的阶段，Sonnet 4 全部请求中已经有 16%受到影响。

在此期间发出请求的全体 Claude Code 用户中，约有 30%至少遭遇一次被路由至错误服务器类型的问题，即响应降级。在 Amazon Bedrock 上，自 8 月 12 日以来路由错误影响的流量峰值已在全部 Sonnet 4 请求中占比 0.18%。从 8 月 27 日至 9 月 16 日期间，错误路由对 Google Cloud Vertex AI 上的请求影响比例则接近 0.0004%。

但确实有一部分用户受到的影响更为严重，这是因为 Anthropic 的路由机制具有“粘性”，即一旦当条请求被错误服务器处理，后续请求很可能也会被交予同一错误服务器。

解决方案：团队修复了路由逻辑，确保短上下文和长上下文请求被定向至正确的服务器池。Anthropic 在 9 月 4 日部署了修复程序，第一方平台及 Google Cloud Vertex AI 的修复于 9 月 16 日完成，AWS Bedrock 则于 9 月 18 日完成。

2. 输出异常

8 月 25 日，Anthropic 在 Claude API TPU 服务器上部署了一项错误配置，导致 token 生成过程出错。运行时性能优化也导致了问题，偶尔会为特定上下文中很少出现的 token 赋予高输出概率，例如在英语提示词下生成泰语或中文字符，或在代码中产生明显的语法错误。如一小部分用英语提问的用户，可能会在回答中看到“สวัสดี”。

此次异常影响到 8 月 25 日至 28 日期间指向 Opus 4.1 和 Opus 4 的请求，以及 8 月 25 日至 9 月 2 日指向 Sonnet 4 的请求。第三方平台未受此问题影响。

解决方案：Anthropic 已发现此问题，并于 9 月 2 日撤销配置，并在部署流程中添加了针对意外字符输出的检验测试。

3. 近似 top-k XLA:TPU 编译错误

8 月 25 日，Anthropic 部署了代码以改进 Claude 在文本生成过程中的 token 选择方式，但此次调整无意触发了 XLA:TPU 编译器中的一项潜在 bug，且已确认会对 Claude Hiaku 3.5 的响应结果造成影响。

Anthropic 猜测，这可能还影响到 Claude APi 上 Sonnet 4 和 Opus 3 的子集。第三方平台未受此问题影响。

解决方案：Anthropic 首先发现了影响 Haiku 3.5 的 bug，并于 9 月 4 日进行了圆滚。随后，其注意到用户上报的 Opus 3 问题似乎与此 bug 相关，并于 9 月 12 日进行了回滚。经过广泛调查，Anthropic 表示无法在 Sonnet 4 上重现此漏洞，但出于谨慎考虑同样对其进行了回滚。

同时，Anthropic 与 XLA:GPU 团队合作修复了编译器 bug，并发布一项修复程序以使用精确 top-k 算法以提高精度。

深入研究 XLA 编译器 bug

为了解释这些问题的复杂性，以下是 XLA 编译器 bug 的表现形式及其难以诊断的具体原因。

在 Claude 生成文本时，它会计算下一潜在单词的出现概率，并从概率分布中随机选择一个样本。Anthropic 使用“top-p 采样”方法来避免无意义输出——即只考虑累积概率达到阈值（通常为 0.99 或 0.999）的单词。在 TPU 上，Anthropic 的模型须跨多个芯片运行，概率计算也在不同位置上进行。为了对这些概率进行排序，需要协调芯片间的数据，因此过程相当复杂。

2024 年 12 月，Anthropic 发现当 temperature 温度参数设置为零时，TPU 偶尔会丢弃概率最高的 token。为此其部署了一种变通方法加以解决。

2024 年 12 月发布的补丁代码片段，用于解决 temperature 为 0 时意外丢弃高概率 token 的 bug。

造成问题的根本原因跟混合精度算法有关。Anthropic 的模型使用 bf16（16 位浮点）运算下一个 token 的概率。但向量处理器为 fp32 原生，因此 TPU 编译器（XLA）可通过相应运算转换为 fp32（32 位）以优化运行时。此优化过程由 xla_allow_excess_precision 标记保护，此标记默认为 true。

但这就造成了不匹配：本应就最高概率 token 达成一致的运算却在不同精度级别上运行。精度的不匹配，导致其无法就哪个 token 具有最高概率达成一致，最终导致最高概率 token 有时会被丢弃。

8 月 26 日，Anthropic 部署了采样代码重写以修复精度问题，并改进了在达到 top-p 阈值的极限概率时的处理方式。但在修复过程中，团队又发现了一个更加棘手的难题。

代码片段所示为一个最小化重现器，此片段属于 8 月 11 日变更的一部分，而该变更正是造成 2024 年 12 月 bug 问题的根本原因，且属于 xla_allow_excess_precision 标记的正常行为。

Anthropic 的修复程序删除了 12 月的解决方案，转而尝试直接处理根本原因。但这又在近似 top-k 运算中引发了另一个更深层次的 bug——所谓近似 top-k 是一种性能优化方法，能够快速找到概率最高的 token。但这种近似运算有时会返回完全错误的结果，且仅限于某些批次大小和模型配置。12 月的临时解决方案无意间掩盖了这个问题。

开发该算法的 XLA:TPU 工程师分享的底层近似 top-k bug 的重现器。代码在 CPU 上运行时，可以返回正确结果。

该 bug 会根据某些互不相关的因素而变化，例如在其之前或之后执行过的运算、是否启用调试工具等，最终引发严重不一致。同一条提示词可能在某条请求上完美运行，但在下条请求上却出现问题。

在调查期间，Anthropic 还发现精确 top-k 运算的性能损失也得到有效控制。在将 top-l 从近似切换为精确，并在 fp32 精度上进行额外运算的标准化调整后，模型质量的稳定性大为提升，因此团队决定接受这种用效率换稳定性的方案。

为何检测如此困难？

Anthropic 的验证流程一般包含基准测试、安全评估和性能指标。工程团队会先进行抽查，再将成果部署至小型“金丝雀”测试组。

这些问题让官方意识到，很多关键缺陷本应被提早发现。Anthropic 的原有评估无法捕捉到用户上报的性能下降根源，部分原因在于 Claude 往往能成功从孤立的错误中恢复正常。Anthropic 自身的隐私保护措施也给调查工作带来了挑战。内部隐私和安全控制措施，要求工程师无法随意访问用户与 Claude 交互的方式和时间，能够看到的就只有反馈报告形式的信息。这虽然保护了用户隐私，却导致工程师难以检测并发现能够重现 bug 的全部细节。

Anthropic 表示，各项 bug 在不同平台上引发的症状也有区别。这导致报告混乱，无法指向任何单一原因，团队观察到的结果就成了随机且缺乏一致性的性能降级。

“更重要的是，我们高度依赖模糊评估。虽然意识到上报频率有所增加，但却缺少明确的方法将这些报告与近期各项变更联系起来。在 8 月 29 日负责上报激增时，我们就没能立即将其与标准的负载均衡变更联系起来。”

改进方案

随着对基础设施的持续完善，Anthropic 表示也在评估和 bug 预防等方面做出探索，具体改进方案包括：

1. 建立更灵敏的评估方法：为了准确发现特定问题的根本原因，团队开发出能够准确区分正常运行及故障实现的评估方法，并将持续改进这些方法以密切跟进模型质量变化。

2. 扩大质量评估范围：除了定期在系统上运行评估之外，还会在实际生产系统上持续运行这些评估，以发现上下文窗口负载均衡 bug 之类的问题。

3. 提升调试工具速度：开发基础设施与工具，确保在不牺牲用户隐私的前提下更好地结合社区反馈进行调试。此外，如果后续发生类似事件，团队将使用内部定制工具以缩短修复时间。

“评估和监控非常重要。此番事件表明，在 Claude 响应性能未达到常规标准时，我们还需要参考来自用户的持续信号。结合具体变化报告、发生的意外行为示例以及不同用例模式，我们就能更准确地找出问题所在。”Anthropic 表示。

信任难拾

纵然看起来是一篇诚意满满的事故分析文章，但是很多用户已经不再买账。用户 Aleksandr Oleynik 在官方帖子下表示：

我已经使用 Anthropic 的模型一年了，特别是在编程工作中，我更喜欢它们。过去一年里虽然出现过各种质量下降的情况，但我一直忠于 Anthropic。然而现在发生的情况简直是一场噩梦，我都不想详细说了，Opus 和 Sonnet 的性能都严重退化。

 

你们说问题出现在八月和九月初——不，这些问题仍在继续，而且在我看来情况甚至更糟了。

 

Claude Code CLI 完全无视指令（无论是 Opus 还是 Sonnet），而且这是有意识、故意发生的，之后他们自己也承认了这一点。目前唯一能工作的方式是将所有必要的指令加入每一个请求中，即便如此，它们有时仍会忽略指令。

 

自七月以来，代码工作的质量明显下降。我订阅了 Max 200，如果到九月底情况仍然如此，我将不会续订。我试用了 Codex CLI GPT-5 Codex High，可以告诉你——它现在的表现甚至比 Claude Code CLI Opus 4.1 在最佳状态时还要好，而那是在你们出现这些问题之前。

 

请采取措施，否则你们将失去忠实订阅用户！

“如果你们承认在八月至九月之间并没有交付承诺的产品，那么就应该提供退款，或者至少赠送一个月的免费服务。这样才能体现诚意，并有助于维持用户对你们的信任。”Peermux 说道。

Anthropic 的工程师 Sholto Douglas 也转发帖子并表示：“我们很抱歉，我们会做得更好。我们正在努力确保今后不再出现此类退化问题，并重新赢得您的信任。”

“太迟了。Codex 的推出加上 Cursor 的价格调整，让我在同时付费给 Anthropic 和 Cursor 一年多之后，终于下决心放弃使用 Claude Code 和 Claude on Cursor。除非下个版本有着极其巨大的提升，否则我大概不会再碰 Claude 了。”软件工程师 Ali Ihsan Nergiz 在帖子下说道。

对此，Douglas 回复道，“下一个版本会更好。”

这个回答被部分网友认为是在暗示下个重大更新。但大家的反应已经不是期待，而是怀疑和不相信：“为了留住用户，他们会说任何话。我对此持怀疑态度。”“它会更擅长收钱，但不交付任何东西。”“当 Claude 不再对一切撒谎时，我才会再次用它。”

Claude 用户流失的情况已经持续了数月，但背后的原因很难完全归于到技术上。

4 个月前，开发者 seoulsrvr 分享了自己放弃 Claude 的经历：

我曾长期是 Claude 的坚定支持者，但我不会再续订之前购买的套餐了。

 

我曾为整个团队购买了 Claude Pro 订阅。一开始产品非常好——我们都很喜欢。

 

但后来 Anthropic 推出了 Max，结果我们的 Pro 服务突然降级，糟糕到我们不得不转用其他工具。使用额度几乎立刻就会被用完，文档大小限制让我们无法处理数据，回答开始变得含糊，或者回复内容远远超出最初请求的范围（比如只需要一个简单的数据表时，它却生成了完整的数据库架构），感觉就像系统在刻意尽快触发使用限制……问题简直数不胜数。

 

这不仅是我的感受，也是整个团队的共识。

 

在 ChatGPT、Gemini 等竞品的编码和其他方面变得越来越强大的时候，Anthropic 反而选择压榨付费用户。考虑到 Anthropic 在竞争激烈的市场中最需要的其实是更多忠诚开发者的拥护来帮助扩大市场份额，这样的做法简直是愚蠢至极。

 

短视的管理，糟糕的战略。

无疑，越来越严格的使用限制是用户非常反感的一项政策。

• 4 月 9 日，发布 Claude Max 计划，定位是为“重度用户/需要大量使用 Claude 的用户。Max 计划有两个层级：5× Pro 的额度（约 $100/月）和 20× Pro 的额度（约 $200/月）。

• 7 月 17 日，用户报告 Claude Code 使用限制变严格，但公司未立即公开所有变动细节，许多用户反馈之前能持续工作的能力受限变得更频繁，如消息数量、上下文长度或代码任务被中断等。

• 7 月 28 日，官方公布新的每周使用额度政策：除了已有的使用限制（每 5 小时重置一次）外，公司还将引入两项新的每周使用限制，每 7 天重置一次：一项是整体使用限额，另一项则专门针对 Claude Opus 4。Max 订阅用户可以在超出限额后，按标准 API 费率购买额外使用量。目的是控制极端高耗使用和滥用情形，如后台连续运行 24/7、账户共享或转售访问等。8 月 28 日开始生效。

• 8 月 28 日后，各层级订阅用户（Pro / Max）都开始同时受到“每 5 小时滚动限制” + “每周限额”的约束。

第二季度以来，无论是长期的 Pro 订阅用户，还是新加入的 Max 用户，Claude 用户都在抱怨服务问题——问题并非在于价格，而是即便付费之后，这些问题依旧存在。

虽然 Google 的 Gemini、OpenAI 的 GPT 等在编程上的表现越来越强，但这或许并不是 Claude 用户选择取消订阅、离开该服务的唯一原因。

5 月份时，一位 Reddit 用户提到，“我取消了 Pro 套餐，现在这种限制简直是个笑话。” 他补充说，像 Google Gemini Studio 这样的免费工具，在编码任务上表现甚至比 Claude 更好。作为曾经的月费用户，他最终决定退订。

另一位用户在取消订阅后表示，尽管他每月支付 20 美元，但 Claude 依然存在很多问题。“我会打开一个对话，想要在副项目上写代码。Gemini 2.5 Pro 或 ChatGPT 可以让我连续几个小时不断地做小迭代和复杂操作，而且不会遇到上下文窗口限制。”然而 Claude 的速率限制很快就触发了。用户经常看到“Token 已用尽”的提示，被迫开启新对话，并在每次新提问时重新添加上下文。最终，他觉得自己花在解释需求上的时间比真正写代码还多。

团队用户也遇到了麻烦。一位加入六人 Claude Team（预付了一年订阅）的 用户反映，即便是很小的文件也会导致会话崩溃。“MCP 读取一两个小文件后，我们就频繁收到‘Claude 达到对话最大长度’的提示。”“甚至连最基本的提示词，在来回几轮之后就被截断。现在几乎完全无法使用。”

但从当时至今， Claude 官方基本一直在推出新功能，对于用户具体的问题很少回复。

虽然现在有人表示依然支持 Claude，但类似上面的抱怨还在持续，Claude 起初凭借编程能力吸引的广大开发者们开始用脚投票。Anthropic 能否真正挽回用户信任，或许还需要更多“真诚”的措施。

参考链接：

https://www.anthropic.com/engineering/a-postmortem-of-three-recent-issues

https://analyticsindiamag.com/ai-features/why-claude-is-losing-users/