Anthropic的三次失误：当你每天依赖的AI工具在悄悄变差，而你毫不知情
2026年4月23日，Anthropic在其官方工程博客上发布了一篇在AI行业颇为罕见的文章。
不是发布公告，不是产品更新，而是一篇完整的工程事后分析（postmortem）——用工程师的语言，逐条解释了过去一个多月里Claude Code为什么变差了。
三项独立的工程决策，叠加在不同时间节点，产生了一个让数百万开发者感到困惑和愤怒的结果：他们每天依赖的AI编程工具，在没有任何通知的情况下，悄悄变差了。整个过程历时45天，横跨3月初到4月20日，中间经历了无数条GitHub issue、Reddit帖子和开发者社群的公开讨伐。
这篇事后分析，既是一份技术声明，也是一次公开的组织反思。它揭示的问题，远比”Claude变慢了”更深刻——它让我们看到了当AI工具成为核心基础设施之后，工程组织将面临怎样前所未有的责任标准，以及为什么即使是顶级AI实验室，也无法完全预见自己产品决策在真实用户场景中的连锁效应。
三个失误，一个月的混乱
让我们先把事情的技术层面说清楚。
第一个失误：推理努力的错误权衡（2026年3月4日）
当Anthropic在2月份发布Opus 4.6时，默认推理努力设置为”高”（high）。这意味着模型在回答每个问题之前会进行深度推理，结果更好，但延迟更高。部分用户反映界面会”冻结”——Claude在思考时间太长，UI显示空白，造成了不好的体验。
Anthropic工程师于是将默认推理努力从”高”降为”中”（medium），并通过产品内对话框解释了调整原因，希望以略微降低的智能换取更流畅的用户体验。他们的内部测试表明：中等推理努力在大多数任务上实现了略低的智能，但延迟显著降低，同时还能更充分地利用用户的使用配额。
问题在于：内部评估选取的任务样本，与真实工程场景存在差距。
“这是错误的权衡，”Anthropic在事后分析中写道。直到4月7日，在大量用户反馈”宁愿等一会儿，也要更聪明的结果”之后，他们才将默认设置改回高推理努力。最新版本中，Opus 4.7的默认值被进一步提升为”极高”（xhigh），而Claude Code v2.1.118版本中，Sonnet 4.6也默认使用xhigh。
这一变更影响了Sonnet 4.6和Opus 4.6的所有用户，持续时间超过一个月。
第二个失误：一个悄悄清空记忆的Bug（2026年3月26日）
这是三个失误中技术上最微妙，也最具破坏力的一个。
Claude Code在工作时会保留推理历史（thinking history）——每一步工具调用的背后，模型都能看到自己之前为什么做了那些决定。这是保证跨轮对话连贯性的关键机制：当你要求Claude修改某段代码时，它能记住自己为什么在上一轮选择了那种实现方式。
Anthropic的工程师决定做一个效率优化：如果一个会话空闲超过1小时，就清除旧的推理历史，以降低用户恢复会话时的延迟和成本。逻辑上没有问题——闲置1小时的上下文本来就会被缓存驱逐（cache eviction），清除推理历史只是减少无用的token传输。
技术实现上，他们使用了clear_thinking_20251015 API请求头配合keep:1参数。设计意图很清晰：跨越空闲阈值后，只保留最新一个推理块，其余清除。
但实现时出现了一个Bug：本应只在会话恢复时清除一次的操作，变成了”每一轮对话都清除”。
结果是：只要一个会话曾经空闲过超过1小时，Claude在此后的每一轮对话都会”失忆”——它看不到自己为什么做了之前的决策，于是变得健忘、重复，做出奇怪的工具选择。用户描述的现象极为准确：Claude会在同一对话里一遍又一遍地执行相同的操作，就好像它从来不记得自己刚才做了什么。
更糟糕的是，这个Bug还引发了连锁效应：推理历史被持续清除意味着大量缓存未命中（cache miss），因为那些本应命中缓存的请求现在变成了截断版本，无法匹配已缓存的内容。于是用户的token消耗量加速上涨——有用户报告自己的月度配额在几天内就耗尽了，而背后的原因是一个静默运行的Bug在每轮对话中浪费着宝贵的推理资源。
这个Bug从3月26日持续到4月10日，历时15天，横跨Sonnet 4.6和Opus 4.6的所有用户，才被完整定位和修复。
Anthropic在事后分析中解释了为什么内部难以复现：两个不相关的实验干扰了测试环境——一个是内部限定的服务端消息队列实验，另一个是改变了推理显示方式的变更，恰好在CLI会话中把这个Bug的视觉症状遮掩住了。工程师在内部测试时既无法在常规CI环境中复现，也需要”会话空闲超过1小时”这个特定触发条件，而典型的自动化测试很少模拟这种真实使用场景。
第三个失误：一行系统提示的副作用（2026年4月16日）
最后一个失误是最近的，也是持续时间最短的。
4月16日，Anthropic在Claude Code的系统提示中加入了一条”减少冗长输出”的指令，目的是让Claude的回复更简洁，避免不必要的废话——这种优化在很多场景下是用户明确要求的，也符合工程师的直觉。
在单独测试时，这条指令看起来没什么问题。但与系统提示中已有的其他指令组合之后，它显著损害了代码生成质量——Claude开始省略重要的注释和错误处理逻辑，甚至跳过必要的实现步骤，因为它在”简洁”和”完整”之间选错了平衡点。
4月20日，Anthropic撤回了这条指令。但在这4天内，Sonnet 4.6、Opus 4.6和Opus 4.7的用户都受到了波及。
用户看到了什么：一场没有解释的退化
这三个失误单独来看，每一个都不是灾难性的。但它们叠加在不同时间线上，产生了一个在用户侧极难解读的现象：Claude Code在没有任何公告的情况下，持续、不规律地变差。
这种不规律性才是真正让人抓狂的地方。推理努力降低影响的是输出的”深度”，缓存Bug影响的是跨轮对话的”记忆”，系统提示变更影响的是输出的”完整性”。三种症状交织在一起，用户无法区分哪种质量问题来自哪个原因，只能感受到一种混乱而弥漫的退化感。
AMD AI团队高级总监Stella Laurenzo在GitHub上发布了一份详细的技术分析，覆盖了6,852个Claude Code会话文件和超过234,000次工具调用。她的结论措辞直接：”Claude已经退步到无法信任其完成复杂工程任务的程度。”
她的发帖之所以引起如此大的反响，不只是因为数据详细。而是因为她的身份：这不是一个普通用户在抱怨体验，而是一位在顶级芯片公司领导AI团队的工程高管，用企业级的数据质量在评估一个她的团队深度依赖的工具。
Reddit上充斥着类似的投诉。有用户说Claude Code变得”懒惰”“无知”“退化而目光短浅”。更多的开发者开始质疑：Anthropic是不是在故意降级（”nerfing”）自己的模型，以管理算力压力和使用成本？
这种”nerfing”指控是AI工具行业近年来反复出现的阴谋论。用户的逻辑很直接：如果模型变差了，又没有任何通知，那就一定是故意为之。在AI服务中，悄悄降级的动机是真实存在的——更少的推理token意味着更低的服务成本，更低的默认推理努力意味着更多人能在配额限制内完成更多任务。
Anthropic一直到4月23日才公开承认：对。Claude Code确实变差了。但不是故意的。是我们的工程决策失误。
为什么这三个失误都没被提前发现？
这是整篇事后分析最值得深思的部分，也是最诚实的部分。
Anthropic描述了一个让大多数工程师都会感到熟悉的困境：在充分的测试覆盖之下，真实用户场景的某些角落依然不可见。
对于推理努力降级，内部评估在大多数标准任务上看到了”略低但可接受的质量”——但那些评估没有充分模拟开发者实际处理的复杂、多步骤工程任务，那类任务对推理深度的敏感性远高于常规问答。
对于缓存Bug，两个不相关的内部实验恰好遮掩了症状，让工程师在内部环境中无法复现；同时，”会话空闲超过1小时”这个触发条件在自动化测试中几乎从不出现，但在真实工作中随处可见。
对于系统提示变更，单独测试没有问题，组合之后产生了未预见的交互效应——而在一个复杂的提示工程系统中，所有提示的全组合测试在计算上几乎是不可行的。
“这些变更通过了多层人工和自动化代码审查、单元测试、端对端测试、自动验证和内部dogfooding，”Anthropic写道。
这句话如果只是普通公司的危机声明，可能会显得苍白。但Anthropic随后给出了技术细节，让这句话显得可信：他们描述了具体的测试盲点，而不是泛泛地宣称”我们已经尽了全力”。
这说明了什么？它说明，当AI工具成为复杂工程工作流的核心，传统的软件测试方法可能已经不够用了。一个代码变更在单元测试和端对端测试中表现正常，但在”会话空闲了一个多小时然后继续工作”这种真实场景里产生了灾难性的副作用——而这种场景对于任何长时间工作的开发者来说都是司空见惯的。
测试生产AI工具的困难不只是技术问题，更是认识论问题：你需要在产品发布前，想象出所有可能的真实使用场景并加以测试。而真实用户的使用方式，总是比你的想象更加多样。
AI工具的新问责标准
这场事件发生的背景值得注意。
Anthropic在2026年4月的二级市场估值已超过1万亿美元（据Business Insider报道）。Claude Code已经成为数以百万计的开发者日常工作流中不可替代的工具。当一个工具成为核心的工程基础设施，它的每一次悄悄退化都会在没有预兆的情况下传导到下游——进入代码库、集成到产品、甚至部署到生产环境。
在这个背景下，Anthropic选择发布一篇完整的工程事后分析，本身就是一个值得关注的决策。
这不是典型的科技公司危机公关做法。通常的剧本是：发布简短声明，承认”有些用户可能遇到了问题”，说明”已经修复”，然后低调过去。Anthropic做的是：解释每一个失误的技术原因、触发条件、持续时间、影响范围，以及他们将如何从系统层面避免再次发生。
他们承诺的改进包括：更好的可观测性工具（observability）、更接近真实用户场景的测试框架、以及更快将内部人员暴露于与外部用户相同使用条件下的能力。
他们还做了一个具体的补偿动作：截至2026年4月23日，所有Claude Code订阅者的使用量限额被重置。这是一个实质性的成本承担——用真实的资源，部分弥补用户在这段时间内因Bug产生的额外token消耗所造成的损失。
第三层洞察：当AI工具开始”吃自己的狗粮”
这里有一个大多数报道都没有注意到的细节，却可能是整篇事后分析最有意思的地方。
在Anthropic的事后分析中，他们提到了一个验证实验：将出问题的代码提交发给Opus 4.7的Code Review系统，提供完整代码仓库上下文之后，Opus 4.7能够识别出导致问题的代码变更。
Anthropic没有明说，但逻辑显然：如果在代码审查流程中早一点使用Claude，这些问题或许可以更早被发现。
这是AI工具行业一个正在悄然形成的趋势：用AI工具来审查AI工具本身的代码。不是把AI当成魔法，而是把它当成一个能处理海量代码上下文、不会因为疲劳或认知偏见而遗漏信息的代码审查助手。
但这里有一个需要被认真对待的悖论：如果Claude Code本身在那段时间处于退化状态，那么用退化的Claude来审查代码，可靠性是否有保障？
Anthropic使用的是Opus 4.7，而事后分析明确指出API层面未受影响——产品层的失误（系统提示、推理努力设置、缓存行为）和模型本身的能力是两个独立的维度。Opus 4.7的底层推理能力并没有因为Claude Code产品层的变更而受损。
这个区分非常重要，却在公众舆论中几乎被完全忽视。
用户感受到的”Claude变差了”，其实是产品工程层面的失误，而不是基础模型能力下降。但从用户视角看，这个区别根本不可见——他们只知道输出质量变差了。这触及了AI服务一个根本性的透明度问题：当产品层的工程决策影响了用户对模型能力的感知，用户几乎没有办法独立验证真正的原因是什么。
他们只能依赖服务提供商的诚实。
反向论点：透明度能够被工具化吗？
有一种声音值得被认真对待：Anthropic的这份事后分析，是否是一种精心设计的叙事操作？
论点如下：通过主动发布详细的技术原因分析，Anthropic把叙事从”Claude变差了，可能是故意的（nerfing）”转变为”我们犯了工程错误，但我们透明地承认了”。这种转变对Anthropic非常有利：它把一个可能被解读为商业策略问题（为节省算力成本而悄悄降级）的事件，重新框架为一个可以被原谅的技术失误。
这种批评并非完全没有道理。
但它忽略了一个关键事实：Anthropic在事后分析中披露的细节，远超危机公关所需的最低限度。他们具体描述了为什么内部测试未能发现问题——不只是”测试不够”，而是解释了哪两个不相关的实验干扰了复现，以及为什么自动化测试无法捕获这种场景依赖的Bug。他们承认了具体的影响持续时间和受影响版本，他们讨论了未来改进的具体方向，包括在Code Review流程中引入Claude的计划。
另一个值得注意的信号：行业同行和媒体对这篇事后分析的评价总体正面。The Register的标题是”Anthropic admits it dumbed down Claude when trying to make it smarter”——承认”试图让它更聪明时把它搞蠢了”。这不是一个危机公关希望看到的标题，但Anthropic接受了这个叙事而不是试图纠正它。
这种程度的工程透明度，在AI行业并不常见。更常见的是语焉不详的”服务通知”和几乎不包含任何信息的版本更新日志。
Anthropic的选择是不同的。这未必是纯粹出于道德，但它设立了一个行业参照——当AI工具造成了可测量的质量下降，用户有权了解发生了什么、为什么发生、以及如何不让它再次发生。
结语：你不知道你在依赖一个已经变差的工具
这件事的意义，超出了一家公司的一次工程事故。
它揭示的是一个更根本的信任结构问题：在传统软件时代，当一个工具”变差”了，表现通常是明确的——崩溃、报错、功能失效。用户能看到问题发生，能决定是否迁移。
但AI工具的退化是隐性的。Claude Code质量下降47%（TrustedSec的测量数据），但它不会崩溃，不会报错，仍然会生成看起来合理的代码。用户在不知情的情况下接受了退化的输出，把它集成进了代码库，推进了生产环境，某些情况下甚至信任了那些质量已经下滑的判断。
这才是最深远的风险——不是AI变差了，而是你在不知情的情况下依赖了一个已经变差的AI，并且把它的输出当成了可信的结果。在关键的工程决策时刻，你以为你有一个强大的协作者，实际上你有的是一个正在悄悄退化的工具。
这种不可见性对未来的AI监管提出了新要求：AI工具提供商是否有义务在产品层发生可能影响输出质量的重大变更时，主动通知用户？不是在事后分析里，而是在变更发生的时候？
Anthropic的这篇事后分析，是一次诚实的面对。但它是一次迟来了45天的诚实——对于那些在问题期间把质量退化的代码推进了生产环境的工程师来说，透明度本身不能撤销已经发生的错误。
下一次AI工具的隐性退化，不会在发生时通知你。在核心基础设施级别的AI工具里，建立问责机制，已经不是可选项了。
参考资料
- Anthropic官方工程博客（2026-04-23）: An update on recent Claude Code quality reports
- The Register（2026-04-23）: Anthropic admits it dumbed down Claude when trying to make it smarter
- VentureBeat（2026-04-23）: Mystery solved: Anthropic reveals changes to Claude’s harnesses likely caused degradation
- Business Insider（2026-04-23）: Anthropic acknowledges Claude Code issues, denies ‘nerfing’
- Forbes - The Wiretap（2026-04-22）: Anthropic’s Claude Is Pumping Out Vulnerable Code, Cyber Experts Warn