Claude 失控！官方用漏洞搪塞，开发者怒斥“太晚了”，为何不退款？

整理 | 褚杏娟、核子可乐

“看得出来，Anthropic 这次真的是急了，连忙出来解释了。”一位网友在看到关于八月到九月初出现bug的推文后这样评论。

“这产品质量真让人失望。我之前不太理解，现在终于明白了。”开发者 Tim McGuire 在评论区这样表达。

“我也是这么觉得。和以前相比，现在的使用体验就像在和一个水平不高的初级工程师打交道，虽然事情能完成，但代码质量却不尽如人意。而最近的感觉，更像是在和一只猴子沟通。”开发者 Peermux 也表示。

Anthropic 把八月到九月初模型质量下降的问题，归咎于三项基础设施的漏洞。八月初，许多用户开始反馈 Claude 的响应质量变差。Anthropic 承认当时未能察觉用户反馈和正常波动之间的区别。到八月底，类似的报告频率和持续性不断上升，因此他们展开了调查，发现了三项互不相关的基础设施问题。

“首先要澄清的是：我们绝不会因为需求、时间或服务器负载的变化而降低模型的质量。用户反馈的问题完全是由基础设施 bug 导致的。”Anthropic 强调道。

他们还表示：“我们非常清楚用户对 Claude 提供稳定质量表现的期望，因此我们设定了很高的执行标准，以确保基础设施的变更不会影响模型的输出。但从最近的事件来看，我们未能真正落实这些标准。接下来的分析报告将会解释发生了什么，为什么检测和解决问题的时间比我们预期的要久，以及我们将采取哪些措施来防止类似事件的再次发生。”

“我们通常不会分享基础设施的技术细节，但考虑到这次问题的范围和复杂性，我们决定进行全面解释。”Anthropic 说道。

具体发生了什么呢？

如何支撑 Claude 的规模化运行

根据介绍，Anthropic 通过第一方 API、Amazon Bedrock 和 Google Cloud 的 Vertex AI，为数百万用户提供 Claude 服务。它们在多种硬件平台上部署 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日进行了配置撤销，同时在部署流程中增加了针对意外字符输出的检查测试，以避免以后再发生类似情况。

接下来，谈谈近似top-k XLA:TPU的编译错误。

在8月25日，Anthropic引入了一段新代码，目的是改善Claude在文本生成时对于token的选择。不幸的是，这次改动无意中触发了XLA:TPU编译器中的一个潜在bug，并且确认会影响Claude Haiku 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有时会被忽略。

在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的工程师分享了在开发算法时遇到的一个较复杂的bug，这个叫“近似top-k”的性能优化手段原本是为了快速找到概率最高的token。然而，这种方法有时会给出完全错误的结果，并且只在特定的批次大小和模型配置下出现。去年12月的临时解决方案无意中掩盖了这个问题。

这个bug的变化很奇怪，受多种因素影响，比如之前或之后的运算、调试工具是否开启等等，导致结果的不一致。你可能会发现同样的提示词在一条请求中可以完美运行，但在另一条请求中却出问题。

在调查过程中，Anthropic还发现，精确的top-k运算性能损失得到了有效控制。当他们将近似的top-l切换为精确模式，并在fp32精度下进行额外调整时，模型的稳定性大幅提升。于是，团队决定为了稳定性而牺牲一些效率。

那么，为什么检测这些问题如此困难呢？

Anthropic通常的验证流程包括基准测试、安全评估和性能指标。工程师会先进行抽查，然后再将成果部署到一个小规模的“金丝雀”测试组中。

这些问题让公司意识到，很多关键缺陷本该提前发现。然而，他们现有的评估方法没能捕捉到用户反馈中提到的性能下降的原因。部分原因是Claude能够从孤立的错误中恢复正常。此外，公司的隐私保护措施也给调查带来了挑战。由于内部隐私和安全控制，工程师无法随意访问用户与Claude的交互记录，只能看到反馈报告的形式信息。这虽然维护了用户隐私，但也让问题的调查变得更加复杂。

Anthropic还表示，不同平台上bug所引发的问题症状各异，导致报告的混乱，无法指向一个明确的原因。团队观察到的结果呈现出一种随机且缺乏一致性的性能下降。

“更重要的是，我们极度依赖模糊评估。尽管意识到上报的频率在增加，但我们缺乏将这些报告与近期变更相结合的明确方法。比如在8月29日上报激增时，我们没能立刻将其与标准负载均衡的变更联系起来。”

为了改善现状，Anthropic表示在基础设施不断完善的同时，也在探索bug的预防措施，具体改进方案如下：

1. 建立更灵敏的评估方法：团队开发了能够准确识别正常运行与故障的评估方法，并会不断优化以密切关注模型质量的变化。

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

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的困境：从青涩到失落的用户体验

我曾经为整个团队购买了Claude Pro的订阅，起初的时候，大家都觉得这个工具非常棒，真的是喜欢得不得了。

可是后来，Anthropic推出了Max计划，结果我们的Pro服务突然就降级了，体验变得糟糕透了，以至于我们不得不寻找其他工具来使用。使用额度一下子就被耗尽，文档的大小限制让我们无法处理必要的数据，回答开始变得模糊不清，甚至有时候请求简单的数据表时，它却给我们生成了一个完整的数据库架构，感觉就像是系统故意在加速触发使用限制，问题一堆一堆的。

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

当ChatGPT、Gemini等竞争对手在编程和其他领域越来越强大的时候，Anthropic却选择了增加对付费用户的压榨。说实话，考虑到在竞争激烈的市场里，Anthropic其实最需要的是更多忠诚的开发者来支持他们，扩大市场份额，这样的做法简直是愚蠢透顶。

真的是短视的管理和糟糕的战略。

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

• 4月9日，Claude Max计划发布，专为“重度用户”设计，分为两个层级：5倍的Pro额度（大约$100/月）和20倍的Pro额度（大约$200/月）。

• 7月17日，用户反馈Claude Code的使用限制变得更加严格，但公司并没有立即公开所有变动的细节，很多用户表示之前能够顺利工作的能力变得不稳定，像消息数量、上下文长度等都受到影响。

• 7月28日，官方公布了新的每周使用限制政策：除了已有的每5小时重置一次的限制外，还引入了每7天重置一次的整体使用限额和专门针对Claude Opus 4的限制。Max订阅用户在超出限额后需要按标准API费率购买额外的使用量，目的是为了控制极端高耗和滥用现象，比如后台连续运行或账户共享等。该政策从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/

声明：本文为InfoQ整理，不代表平台观点，未经许可禁止转载。

今日好文推荐

直播预告

模型触手可得，落地却举步维艰？真正的竞争在于AI应用的“落地效率”。关于AI中间件的“基建之战”正在展开。「点击预约按钮即可预约直播」