Claude Code 长上下文缓存 Bug 深度复盘：1M 上下文多轮编码质量为何崩盘

把这个问题想清楚，很多枝节自然会简化。

这三个看似各自针对延迟、成本和输出长度的优化，在不同用户群和时段逐步叠加，制造出“煮青蛙”式的质量不稳体验。有些会话主要受 reasoning effort 影响，有些则被缓存 bug 主导，而 verbosity 限制进一步压缩了复杂代码所需的推理空间。类似过去大厂 silent change 引发的用户反弹，这次也提醒行业，产品层调整若缺乏足够透明的渐进 rollout，容易积累成可见问题。

深层来看，这次缓存bug的核心在于3月26日的优化改动本意是为idle超过1小时的会话仅清除一次较旧thinking历史，以降低恢复latency并控制token开销。可实际执行中，清除操作却变成了每turn一次，导致cache miss频发，历史推理链条被反复丢弃。Claude仍在继续工具调用和编码任务，却逐渐失去对先前决策的记忆。这直接削弱了其在大型代码库多文件重构中的核心优势——一次性把握跨文件依赖并维持长会话一致性理解。

开发者社区在 Hacker News 和 Reddit 上的反馈高度一致：代码重复生成、突然遗忘先前上下文、响应长度骤减成为常见吐槽点。不少人提到原本能一气呵成的复杂重构，现在需要多次迭代才能勉强完成；主流媒体也迅速跟进，焦点多集中在使用体验的不便上。然而，这种讨论存在明显盲区——大家更多关注“用着不顺手”的表象，却较少深挖质量下滑期间 AI 生成代码的内在缺陷率是否在同步上升。这一点目前行业内仍有不同声音，但数据趋势值得警惕。

4月7日这一变更被回滚，多数模型默认恢复high，Opus 4.7甚至设为xhigh。单独来看，它主要影响响应深度，尚未引发全面质量崩盘。

安全公司 Veracode 的长期测试数据提供清晰对比：在80个编码任务中，Claude Opus 4.7 引入漏洞的比例达到52%，高于 OpenAI 模型约30%的水平。一位安全专家自建工具测得质量下滑期 Claude Code 缺陷率较初期高出47.3%以上。

Anthropic 在 postmortem 中承诺的“未来不同做法”最值得关注。他们计划让更大比例内部员工直接使用与公版一致的 Claude Code 配置，而非特供版；同时改进 Code Review 工具并外发使用。对系统 prompt 变更，则要求进行 per-model evals、ablations 测试，并增加 soak period 和 gradual rollout。

Claude的1M上下文窗口原本为生产级代码重构提供了独特价值，能让模型在单一会话中构建相对完整的代码库视图，避免开发者反复手动拆分上下文。但本次bug让这一优势转为双刃剑：长idle后全量重算不仅造成token爆炸，有效的高质量一致性上下文也远低于宣称水平。历史类似上下文管理问题反复提醒我们，即使模型参数强大，工程层面的状态维护稍有疏忽，长会话编码质量就会快速崩盘。

月4日，Anthropic针对Claude Code进行了默认推理努力的调整，将其从high切换到medium。这一变化主要影响了Opus 4.6和Sonnet 4.6模型，核心目的是缓解高努力模式下偶尔出现的极长思考尾部，导致UI呈现冻结状态，同时降低token消耗。Anthropic内部基于evals和dogfooding数据，认为medium能在多数日常编码任务中实现略低智能但显著更优的延迟表现。

表面上看，用户社区的反应相当直接而情绪化。大量帖子描述 Claude Code “一夜之间就不行了”，部分开发者甚至猜测是为了控制成本而故意降低智能表现。讨论焦点多停留在底层模型或 Anthropic 的响应速度上，很少有人第一时间将问题归因于产品层面的细微配置调整。

深挖三个变更的时间线，能清晰看到它们如何形成连锁反应，间接加速了限额消耗。3月4日默认reasoning effort从high降至medium，本意缓解UI偶发卡顿，却削弱了复杂逻辑的深度分析能力；3月26日的缓存优化本想清理闲置会话的旧思考历史，却因bug导致每轮都清空上下文，造成重复输出和额外token浪费；4月16日系统prompt新增verbosity限制（工具间≤25词、最终响应≤100词），短期内让编码质量评估下降约3%。

未来这个差距会继续扩大，还是逐步收敛，值得持续观察。