过去一个月，海量 Claude Code 用户反馈模型质量“断崖式下跌”——有人觉得它变笨了，有人抱怨它开始健忘，还有人发现写代码的水平大不如前。Anthropic 最终发布了一篇极为坦诚的事后复盘中，详细拆解了这场风波背后的真相。
这篇复盘信息密度极高，我们来深入分析一下。
三个独立问题，叠出一场“退化”风暴
首先要明确一个核心事实：模型本身的基底没有变。 API 层和推理层毫无损伤。问题出在 Claude Code 这款产品的应用层上。具体来说，是三个不同时间点上线的变更，各自打击了不同用户群，最终叠加起来，让大家普遍感觉“模型在持续退化”。
这三个问题分别是什么？
第一个： 3 月 4 日，团队将默认的推理强度从 high 下调至 medium。起因是部分用户在 high 模式下遭遇了夸张的等待时间，界面如同卡死一般。团队认为降低默认强度能优化体验，内部测试也显示，medium 在多数任务上仅稍弱一点，却大幅降低了延迟。
问题在于，用户对“快但笨”的容忍度远低于团队的预期。用户宁可等着，也要更聪明的输出。这揭示了一个很关键的产品洞察：对编程这类高认知密度的工作，用户对智能水平的敏感度远高于对延迟的敏感度。 你让模型反应变快却变蠢了，用户的第一感知是“它变差了”，而且这种感知极其强烈。
4 月 7 日，这项变更被回滚。如今 Opus 4.7 默认采用 xhigh，其他模型默认采用 high。
第二个问题最为隐蔽，也最有技术含量。3 月 26 日，团队上线了一项缓存优化。设计初衷很直接：若一个会话闲置超过一小时，恢复时便清除旧的思考记录，借此降低延迟与成本。 因为闲置超时后缓存本就会失效，不如顺势把那些已无必要的历史推理也清掉，少发送一些 token。
然而，实现上出了大纰漏。清除操作本应只执行一次，结果却变成了在那之后的每一轮对话中都执行。一旦某个会话触发过一次闲置阈值，之后每一次请求便只保留最近一轮的推理，先前的思考过程被全部丢弃。
这意味着什么？Claude 在攻克复杂任务时，它看得见自己刚做了什么，却完全忘了为什么要这么做。它丧失了对整个任务链路的理解。 用户的感受就是重复、健忘、工具调用莫名其妙。更糟的是，因为思考块被持续抛弃，每次请求都沦为缓存未命中，额度消耗比正常情况快得多。
这个 Bug 花了两周才被定位。一方面因为它仅在特定条件下触发（会话须先闲置超一小时），另一方面，两个毫不相关的内部实验恰好“障眼法”般干扰了它的复现路径。它竟安然通过了人工代码审查、自动化测试、端到端测试与内部试用（dogfooding），全程未被发现。直到 4 月 10 日才得以修复。
第三个问题爆发于 4 月 16 日。为抑制 Opus 4.7 天生的啰嗦倾向，团队在系统提示中添了一句指令：工具调用之间的文本不能超过 25 个词，最终回复不能超过 100 个词，除非任务需更多细节。
内部测试了好几周，跑了一整套评估未发现性能回退。然而，上线后用更全面的评估套件一测，编码质量竟下降了 3%。4 月 20 日，此指令被回滚。
为何这些 Bug 如此难以发现？
复盘中最值得深思的部分，并非 Bug 本身，而是对“为何它们能逃过所有防线”的反思。
三个变更全部通过了完整的审查流程：代码审查、单元测试、端到端测试、自动化验证、内部试用，一个不落。但它们还是成了“漏网之鱼”。
原因有好几层。
第一层，内部员工使用的版本与公开版本存有差异。 这是个经典的陷阱：你以为在进行充分的内部“吃自己的狗粮”（dogfooding），可实际上，你测试的环境与用户所处的真实环境存在微妙的差距，而 Bug 恰好潜藏其中。
第二层，评估套件的覆盖面不够广。 内部执行的那套评估未能捕捉到系统提示变更对编码质量的影响，直到事后用更全面的测试集才暴露出那 3% 的衰减。这无疑表明，评估本身也需持续迭代和拓展边界。
第三层，早期的用户反馈极难与正常波动区分开。 模型生成本身带有随机性，用户的主观感受也受多重因素左右。问题初露端倪时，团队很难立刻断定是真实的退化，还是正常的噪音。
这三层缘由叠加，便构筑了一个致命的盲区：每道防线单独审视都合情合理，但组合起来，其防御力就是不够。
一个有趣细节：用 AI 来审查 AI 的代码
复盘中提到一个颇具启发性的实验。团队用 Opus 4.7 对存在问题的 Pull Request (PR) 进行了回溯式的代码审查。结果，Opus 4.7 能揪出那个缓存 Bug，而 Opus 4.6 却做不到。
这证明了两件事。其一，模型能力的提升是实质性的，新一代模型在理解复杂系统交互方面有了长足进步。其二，用 AI 审查 AI 产品的代码，正从一个概念迈向真实的工程实践。Anthropic 目前已在内部推行此方法，并计划将改进后的代码审查（Code Review）工具开放给用户。
这不禁让人联想到一个更宏大的图景：随着 AI 系统日趋复杂，人类审查者越来越难以覆盖所有边界场景。借用更强的模型去审查由较弱模型参与构建的系统，或将成为一种标准实践。 如果你想了解更前沿的开发者动态，像 云栈社区 这样的技术论坛上，对这些议题的探讨正在升温。
后续改进措施与思考
Anthropic 列出的一系列改进方向很具体：确保更多内部员工使用与用户毫无差别的公开版本；对每次系统提示的变更，都进行全面的、按模型细分的评估；新赠“浸泡期”和灰度发布机制，为问题暴露留出足够时间；同时，增强 Code Review 工具的上下文能力，允许引入更广的代码仓库作为审查背景。
他们还开设了名为 @ClaudeDevs 的 X 账号，专用于解释产品决策背后的逻辑。这一举动本身也值得关注：当你的产品是一个 AI 模型，用户对“它为何表现不一”的焦虑是持续存在的。主动且透明地沟通，远比被动回应要好得多。作为补偿，所有订阅用户的用量额度被重置。
这件事给所有 AI 工具使用者提了个醒。当我们日益依赖 AI 处理关键任务时，AI 产品自身的质量波动，会直接影响我们的产出与判断。 你可能花了一整天，用一个“退化”了的工具干活，产出质量因而下降，自己却未必能及时察觉，甚至可能怀疑是自己 prompt 写得不好，或任务本身太难。因此，建立“质量基线感知”就变得非常关键——你大概要知道这个工具正常时能做到什么水平，一旦它偏离该基线，便能快速调整，比如切换模型、调整参数，或是先等等看平台方面是否有问题。
另一个关键在于：产品层的决策对 AI 工具的真实表现有着举足轻重的影响。 模型没变，但你感受到的智能水平，会因一个默认参数的调整、一个缓存策略的 Bug、一句系统提示的增删而剧烈震荡。这在 人工智能 领域的工程实践中尤为突出。评价一个 AI 产品，模型能力只是其中的一个维度，产品工程的质量同样重要，甚至在日常体验中更为重要。
Anthropic 这次复盘的坦诚程度，在业内是稀有的。多数公司面对类似问题，要么沉默，要么含糊其辞。把三个 Bug 的技术细节、清晰时间线、发现过程以及修复方案全部公开，这本身就是对用户信任的深度投资。在 AI 工具竞争白热化的今天，这种透明度很可能会演变为一种差异化的优势。
发表于 昨天 20:30
|
查看: 4|
回复: 0
