Claude Code的'降智'风波揭示了AI产品优化的隐形陷阱。Anthropic的三项'善意'优化——降低推理强度、错误缓存清理、过度约束提示语——如何叠加出45天的性能灾难？本文深度拆解技术细节与产品逻辑，揭示大模型时代'微调'与'崩溃'的临界点。

如果你是一名外科医生，手术进行到一半，突然发现手里的手术刀变钝了——不是一下子变钝，而是每天钝一点点，直到某天你划不开皮肤了。

你回头去问刀具供应商，对方告诉你：”哦，我们觉得刀太锋利会划伤医生的手，所以偷偷磨圆了一点。然后我们又觉得刀柄太重影响手感，就换了个轻的。最后我们发现刀身太长不好收纳，就截短了两厘米。每一步都是为你好。”

这就是过去45天里，Anthropic对Claude Code做的事。

“Claude变笨了”——这次不是错觉

过去一段时间，”Claude变笨了”这五个字几乎刷遍了所有开发者社区。

Hacker News上有人发帖吐槽，Reddit的编程板块天天有人骂，X上更是怨声载道。最开始大家还以为是自己的问题——是不是提示词写得不好？是不是工作流搞复杂了？甚至有人开始怀疑自己的编程水平退步了。

说实话，作为一个每天用Claude Code写代码的00后从业者，我自己也经历过这种自我怀疑。今年3月中旬开始，我明显感觉Claude Code的表现大不如前：以前一轮对话就能搞定的重构任务，现在要来回扯三四轮；以前写出来的代码干净利落，现在动不动就给你生成一堆废话注释；更离谱的是，有时候前面刚讨论过的上下文，下一轮它就完全忘了，像个得了健忘症的实习生。

我一度以为是自己的使用方式出了问题，还专门花了一个周末重新学习了Anthropic的提示词工程指南。

结果呢？4月23号，Anthropic的Claude Code研发团队终于打破沉默，发了一篇名为《An update on recent Claude Code quality reports》的事后分析报告。

翻译成大白话就是：用户反馈的”降智”不是错觉，是我们搞砸了。

具体来说，是三处看起来”为用户好”的产品优化，引发了连锁反应，让全球最强编程模型之一在长达45天的时间里持续性能劣化。三个独立的改动，分别从不同维度削弱了Claude的能力，最终叠加出了灾难性的效果。

接下来，我会把这三个优化一个个拆开，告诉你它们各自是怎么回事、为什么会出问题、以及这件事对我们做AI产品的人意味着什么。

第一刀：砍掉”思考时间”换速度——用户要的是快，但不是蠢

时间线：3月4日上线

先说第一个改动，也是最早的一个。

大模型有个特点：想得越久，答得越好。这不是玄学，而是推理类模型的基本原理。你给模型更多的”思考预算”（也就是允许它在内部进行更多轮的推理），它就能产出更高质量的结果。就像你考试的时候，给你3个小时和给你30分钟，答题质量肯定不一样。

Claude Code里有一个叫”推理强度”的参数，简单理解就是控制模型”想多久”的旋钮。这个旋钮有几个档位：低、中、高、极高。之前默认是”高”。

然后问题来了。不少用户吐槽说，Opus模型（Claude最强的版本）思考时间太长了，有时候UI都卡住不动。这个反馈确实是真的——我自己也遇到过，等模型思考的时候干看着屏幕转圈，确实烦人。

团队的应对方案是：把默认推理强度从”高”悄悄调到了”中”。

注意这个”悄悄”。他们没有在更新日志里专门说明这个改动，也没有弹窗告知用户。在内部评估中，”中”等强度的表现看起来还行——速度明显快了，智能损失”看起来不大”。

但实际使用中完全是另一回事。

这里要说一个我个人的深刻感受：大模型的”差一点点”和传统软件的”差一点点”，是两个完全不同的概念。

传统软件，比如一个按钮的响应时间从100毫秒变成150毫秒，用户可能压根感知不到。但大模型不一样。模型从”高”降到”中”，表面上可能只是某个基准测试得分掉了两三个百分点，但在真实的开发场景里，这两三个百分点可能就是”写出能用的代码”和”写出一坨需要你花20分钟手动修的垃圾”之间的差距。

打个不太恰当的比方：一个棋手的等级分从2800掉到2750，对普通人来说都是”超级厉害”，但对跟他对弈的其他顶级棋手来说，差距是肉眼可见的。Claude Code的用户恰恰就是这群”顶级棋手”——他们是专业开发者，对模型输出质量的感知极其敏感。

上线之后，用户的负面反馈开始涌入。团队也做了一些补救措施，比如在启动时弹提示让用户知道可以手动调高推理强度，增加了内联的强度选择器，甚至恢复了一个叫”ultrathink”的极高强度选项。

但问题是——大多数用户根本不会去改默认设置。

这是产品设计的基本常识，我们做移动互联网的人应该都懂：默认值就是产品经理替用户做的决策，80%以上的用户会直接接受默认值。你把默认值从”高”调到”中”，就等于替80%的用户做了一个”牺牲智能换速度”的决定，而他们根本不知道发生了什么。

直到4月7日，团队才把默认值改回”高”，并在新发布的Opus 4.7上默认开启”极高”模式。

这一刀，砍了34天。

第二刀：省成本的缓存清理变成了”记忆黑洞”——最隐蔽、伤害最大的一刀

时间线：3月26日上线

如果说第一刀是”让Claude变笨了一点”，第二刀就是”让Claude彻底失忆了”。

这个Bug的技术细节稍微复杂一些，但我尽量用大白话讲清楚。

当你用Claude Code写代码的时候，每一轮对话，模型不仅会给你输出结果，还会在后台进行大量的”内部推理”——比如”用户让我重构这个函数，我之前看到这个函数调用了A模块，A模块有个已知的兼容性问题，所以我重构的时候要注意处理这个边界情况”。

这些内部推理（也叫思维链）会被保留在对话历史里。这样，在后续的对话中，模型就能”记住”自己之前为什么做了某个决定。这是保持上下文连贯性的关键机制。

3月26日，团队上线了一个优化：当会话空闲超过一小时，自动清除旧的内部推理内容，以节省Token成本并加快响应速度。

设计初衷听起来很合理。你中午去吃了个饭，回来继续工作，之前积累的大量内部推理确实会占用上下文窗口，清理掉一些能让模型跑得更快更省钱。

但代码写出了一个致命Bug。

本来应该是”空闲超过一小时后，清理一次旧的推理内容”。结果实际上变成了”空闲超过一小时后，在后续的每一轮对话中都进行清理”。

你感受一下这个差别：

• 正确的行为：你离开了一小时，回来后，系统清理一次旧记录，然后正常工作。
• 实际的行为：你离开了一小时，回来后，系统在你说的每一句话之后都把之前的记忆删掉。

这意味着什么？意味着一旦触发了这个Bug，Claude Code就只能记住最近一轮对话的内容。它彻底忘了自己之前为什么要修改代码、之前看到了什么文件、之前做了什么决策。

在用户看来，Claude突然开始重复同样的话、给出前后矛盾的建议、反复问已经回答过的问题。就像一个每隔五分钟就失忆一次的同事，你每次都得从头跟他解释一遍项目背景。

更坑的是，这个Bug还有一个”隐藏伤害”：由于每轮都在清理缓存，导致大量的缓存未命中。正常情况下，相似的对话上下文可以复用之前的缓存，省时省钱。但现在每轮都是”全新”的，相当于每句话都要重新从头算起。

结果就是：用户的使用额度被疯狂消耗，明明没干什么特别的事，流量却像开了闸一样往外涌。

这个Bug为什么拖了这么久才发现？Anthropic在报告里给出了解释，读起来让人哭笑不得——

当时内部恰好有两个互不相关的实验在同时运行。一个是服务端的消息队列实验，另一个是思维链展示方式的改动。这两个实验的存在，恰好掩盖了这个缓存清理Bug的症状。就像一个病人同时吃了三种药，其中两种药的副作用恰好掩盖了第三种药的过敏反应，直到过敏严重到盖不住了，医生才发现问题。

最后，团队用了超过一周的时间才定位到根本原因，并在4月10日修复。

这里还有一个挺有意思的细节：在调查过程中，团队用最新的Opus 4.7模型去审查出问题的那段代码，Opus 4.7成功发现了Bug。而之前的Opus 4.6没能发现。某种意义上，Anthropic是”用新版Claude修好了旧版Claude搞出来的烂摊子”。

这一刀，砍了15天。

第三刀：治啰嗦治出了”呆”——一句提示语砍掉3%的智能

时间线：4月16日上线

第三个问题出在系统提示语上。

Opus 4.7这个版本比前代”话更多”——虽然在难题上表现更好，但输出内容明显更冗长。做过大模型产品的人应该都懂，啰嗦是大模型的通病，用户对此的容忍度很低。

为了治这个毛病，团队在系统提示语里加了一句约束：

“在工具调用之间的文本控制在25个词以内。最终回复控制在100个词以内，除非任务确实需要更多细节。”

这句话在内部测试了好几周，在Anthropic自己跑的评测集上没有发现性能下降，所以4月16日就跟着Opus 4.7一起上线了。

但后来团队做了更大规模的消融测试——简单说就是一行行删掉系统提示语，观察每删一行对模型表现的影响——发现这句约束导致了所有模型版本大约3%的性能下降。

3%听起来不多，对吧？

但结合前面已经存在的两个问题——推理强度降级导致的智能损失，加上缓存清理Bug导致的上下文丢失——这3%就成了压垮骆驼的最后一根稻草。三个问题叠加在一起，用户感受到的不是”3%+几个百分点”的算术加法，而是一种系统性的、全方位的”这玩意儿不行了”的体感。

4月20日，团队紧急撤销了这条提示语。

这一刀，砍了4天。

但要注意，这4天恰好是Opus 4.7刚发布、全球开发者蜂拥而至尝鲜的窗口期。新用户的第一印象就是”这个万众期待的最强模型，怎么这么拉胯？”

45天里发生了什么：三刀叠加的灾难时间线

把三个问题放在一起看，时间线是这样的：

3月4日到4月7日（34天），推理强度被偷偷降级，Claude全面变笨。

3月26日到4月10日（15天），缓存清理Bug让Claude失忆，同时疯狂消耗用户额度。

4月16日到4月20日（4天），过度约束的提示语进一步压缩了模型的表达和推理空间。

从3月4日到4月20日，这三把刀前后交叉，中间有12天（3月26日到4月7日）是两把刀同时生效，还有4天（4月16日到4月20日）是跟最后一把刀叠加。

整个过程中，没有任何一个改动是”恶意”的。每一个优化都有合理的出发点：加快速度、节省成本、减少啰嗦。

但最终的结果是：用户感受到了一个持续45天的、不可逆转的智能退化。

这让我想起一个老笑话：一个人去理发，跟理发师说”帮我修一下就好”。理发师先修了一下左边，觉得不对称；又修了一下右边，还是不对称；再修左边……最后理成了光头。

每一步都是”微调”，每一步都有道理，但最终的累积效果是毁灭性的。

用户不买账：迟到的真相比Bug更伤人

Anthropic在4月23日发布了这篇事后分析报告，同时宣布重置所有订阅用户的使用限额作为补偿。

按理说，主动承认问题、公开技术细节、给出补偿措施，这在行业里已经算是比较有诚意的做法了。但开发者社区的反应是——骂得更凶了。

为什么？因为有三个让人咽不下去的点：

第一，”重置限额”的补偿太敷衍。

有用户在X上贴出截图：自己每月付几百美元的高级订阅，过去几周因为缓存Bug导致额度被疯狂消耗，而Anthropic的补偿就是重置当期限额。更讽刺的是，有人发现重置时间总是卡在限额快到期前几小时，相当于你的月卡还剩最后一天的时候，人家大方地说”给你续一天”。

有人算了一笔账：过去一年为Anthropic付了大约2400美元的订阅费，结果因为官方自己的Bug导致体验崩塌，补偿就是一个不痛不痒的限额重置。这种”补偿”的诚意，说实话很难让人感受到。

第二，发布时间太”巧”了。

这篇事后分析报告发布的当天，恰好是OpenAI发布GPT-5.5的日子。在AI圈，这种”撞车”操作很难不引发联想。有人直接质疑：你们是在趁大家都关注GPT-5.5的时候偷偷放出坏消息，分散注意力吧？

当然，也有可能真的是巧合。但在信任已经摇摇欲坠的时候，任何”巧合”都会被解读为”算计”。

第三，事前的沟通姿态让人心寒。

在正式承认问题之前的这45天里，社区一直在反馈”Claude变笨了”。Anthropic的官方口径始终是”模型没有退化”。

你想想这种感受：你花大价钱买了一个工具，用着用着发现不好使了，去找厂商反馈，厂商说”你搞错了，我们没问题”。你怀疑了一个半月，最后厂商告诉你”哦，确实是我们的问题”。

有用户在X上的发言让我印象很深，大意是：你让我怀疑了自己整整两周，我以为是自己的提示词写得烂、工作流设计得差，甚至开始怀疑自己的能力。结果问题出在你们身上？然后一个限额重置就想打发我？

最扎心的是，已经有用户开始用脚投票了。有人表示切换到OpenAI的Codex之后体验非常好，正在考虑彻底更换工具链。要知道，让一个重度用户放弃已经深度集成的工具是非常难的，一旦他们真的走了，再拉回来的成本是初次获取的5到10倍。

为什么内部没人发现？——每个做AI产品的人都该反思的问题

这件事最让我震惊的不是Bug本身——哪个软件没Bug呢？让我震惊的是：这些Bug在内部居然都没被发现。

Anthropic在报告里给出了一些解释：

• 缓存Bug因为两个内部实验的干扰而难以复现
• 推理强度的降级在内部评测集上”看起来影响不大”
• 提示语约束在自家评测集上没有触发性能下降

但抽丝剥茧来看，根本原因只有一个：内部开发者用的不是公开发行版。

Anthropic的内部员工用的是带有各种实验特性的内部版本，而不是普通用户安装的公开版本。这意味着他们感受到的产品和用户感受到的产品，从一开始就不是同一个东西。

这个问题在软件行业有一个经典的名字，叫”dogfooding”——吃自己的狗粮。意思是你自己团队得用自己的产品，才能真正理解用户的痛点。

Anthropic在报告里也承认了这个问题，表示未来会推动更多内部员工使用公开发行版。但说实话，这种承诺在行业里听得太多了。

作为一个做了几年AI产品的人，我想分享一个自己的切身经验：我们团队之前做一个基于大模型的文档处理工具，内部Demo效果非常好，大家都觉得没问题。结果上线第一天就被用户骂惨了——因为我们测试的文档都是格式规范的PDF，而真实用户丢进来的是歪歪扭扭的手机拍照截图、扫描件、甚至还有人把PPT截图拼成了一个Word文档。

评测集和真实世界之间的鸿沟，永远比你想象的大。

Anthropic的改进方案：方向对了，但够不够？

在报告的最后，Anthropic列出了三项改进措施。我逐一说说我的看法：

改进一：强制内部员工使用公开发行版。

方向完全正确。但执行难度比说起来大得多。内部员工需要测试新功能，不可能百分百用公开版。关键是要在”内部测试版”和”公开版”之间建立一个制度化的轮换机制——比如每个月至少有一周必须只用公开版，而且要求写使用报告。

光有意愿不够，得有流程保障。

改进二：对系统提示语的每一行修改进行消融测试。

这是这次事件里最有价值的技术教训。消融测试就是逐行删除提示语，观察每删一行对模型输出的影响。听起来简单，但实际工作量巨大——一个复杂的系统提示可能有几十上百行，每一行都要跑一轮完整的评测。

但这个投入是值得的。因为这次事件证明了：对大模型来说，系统提示语里的每一个字都可能产生蝴蝶效应。你以为无关紧要的一句约束，可能在某些场景下引发严重的性能退化。

改进三：对任何可能牺牲智能的改动，增加”浸泡期”和渐进式上线。

也是对的方向。传统软件的灰度发布大家都熟——先放1%的用户，观察数据，没问题再逐步扩大。大模型产品更需要这种机制，因为评测集永远覆盖不了真实使用场景的复杂度。

但浸泡期多长合适？灰度比例怎么定？这些细节Anthropic没有在报告里说清楚，我觉得后续需要更具体的方案。

此外，Anthropic还在X上开了一个@ClaudeDevs的官方账号，用来跟开发者社区沟通产品决策。这一步走得不错，但能不能坚持做下去、做到什么程度，还需要时间验证。

对我们做AI产品的人意味着什么？——五条实操方法论

作为一个亲身经历了这场风波的从业者，我觉得这件事的教训远不止”Anthropic犯了错”这么简单。这里面有很多通用的方法论，适用于每一个做大模型产品的团队。

我总结了五条：

第一条：永远不要偷偷改默认值。

这是最基本、也是最容易被忽视的产品原则。用户选择你的产品，是基于他当前感知到的体验。你在后台偷偷把推理强度从”高”改成”中”，就相当于咖啡店偷偷把美式的浓缩从两份减到了一份半——你觉得差别不大，但天天喝的老客户一口就能喝出来。

如果你必须改默认值，至少做到两件事：一是在更新日志里明确说明，二是给用户提供一键恢复旧默认值的选项。

第二条：大模型产品的”性能-成本-体验”三角，不能用传统软件的思路来平衡。

传统软件的性能优化通常是帕累托改进——你优化了数据库查询速度，用户体验变好，服务器成本也降低，皆大欢喜。

但大模型不一样。在大模型里，速度、成本和智能之间往往是零和博弈。你想让模型更快，就得牺牲思考深度；你想省Token，就可能损失上下文连贯性；你想让输出更简洁，就可能压缩掉关键的推理过程。

所以，在做任何涉及这三个维度的优化时，必须回答一个灵魂拷问：如果这个优化只能让10%的用户高兴，却让50%的用户体验变差，你还做不做？

答案通常是不做——或者至少做成可选项，而不是改默认值。

第三条：评测集永远不够用，真实用户测试不可替代。

Anthropic的三个优化在内部评测集上都”看起来没问题”。但真实环境中，它们都出了问题。

这给我们的教训是：不要迷信评测集。再全面的评测集也只是真实使用场景的一个子集，而且是一个被精心策划过的子集。真实用户会做的事情远比你想象的多样、混乱和不可预测。

我的建议是：对于任何可能影响模型核心能力的改动，除了跑评测集，必须做”真实场景压力测试”——找10到20个重度用户，让他们在真实工作中使用改动后的版本至少一周，收集定性反馈。这比跑一万条评测用例都管用。

第四条：缓存和上下文管理是大模型产品的”命门”，改动需要最高等级的代码审查。

Claude Code的缓存清理Bug，本质上是一个”看起来简单、实际上极其复杂”的上下文管理问题。这类问题在所有大模型产品中都是高发区域。

我见过太多大模型产品在上下文管理上踩坑：对话历史莫名其妙被截断、长文档处理到一半”忘了”前半部分、多轮对话中前后矛盾……

如果你在做大模型产品，我的建议是把所有跟”上下文””记忆””缓存”相关的代码模块标记为”核心红区”——任何改动都需要至少两个高级工程师交叉审查，而且必须在各种边缘场景下测试（比如会话空闲1小时、5小时、24小时后恢复的情况）。

另外你也可以关注一下LangGraph和MemGPT这类专门做大模型记忆管理的开源框架，它们在上下文持久化和分层记忆方面已经有了不少成熟的解决方案，值得参考借鉴。

第五条：出了问题，第一时间跟用户坦诚沟通，不要等到”最佳时机”。

Anthropic这次最大的公关失误，不是Bug本身，而是在社区反馈了45天之后才公开承认问题。而且偏偏选在竞争对手发布新产品的当天发布报告，更是给自己的诚意打了折扣。

在AI行业，用户对模型的信任极其脆弱。这些用户不是普通消费者，他们是把你的模型深度集成到自己工作流里的开发者，他们的生产力和收入直接依赖你的产品稳定性。

当你知道产品出了问题时，最好的沟通时机永远是”现在”——哪怕你还没完全查清原因。你可以说”我们注意到了问题，正在调查，初步排查方向是什么什么，预计什么时候给更新”。这比沉默45天后突然扔出一份”完美报告”强一百倍。

写在最后：技术领先只是入场券

有一个问题我一直在想：如果Claude不是”全球最强编程模型之一”，这件事还会引发这么大的风波吗？

答案大概率是不会。

正是因为Claude Code代表了编程辅助工具的天花板，用户对它的期望也被拉到了最高。当这个天花板突然塌了一块下来，砸到的恰好是最忠诚、付费最多、依赖最深的核心用户——他们的反应当然最激烈。

这件事揭示了一个我觉得很多AI从业者还没有意识到的残酷现实：在大模型竞争进入白热化的今天，技术能力的领先周期越来越短。今天你是最强的，三个月后别人就可能追上来。

真正的护城河不是跑分第一，而是你能不能在产品出问题的时候不丢掉用户的信任。

OpenAI有过类似的教训（还记得GPT-4的”变懒”事件吗），Google的Gemini也踩过坑。行业里没有任何一家公司能保证模型永远稳定。

但用户能接受的是”你告诉我出了什么问题、怎么修的、以后怎么避免”。用户不能接受的是”你偷偷改了东西、否认有问题、然后在我快要放弃你的时候才承认”。

对于我们这些做AI产品的人来说，这件事给的最大教训其实只有一句话：

你可以犯技术的错，但不能犯沟通的错。Bug可以修，信任修不了。