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

只有持续学习，才能跟上这个节奏。

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

Anthropic 4月23日发布的 postmortem 报告直指 Claude Code 近期质量感知下滑的根源：默认推理努力从 high 降至 medium 以缓解延迟、缓存优化引入的 bug 导致会话中反复清除推理历史，以及为控制冗长而添加的系统提示词长度限制。

值得持续跟踪的是，如果更多厂商效仿 Anthropic 公开类似 postmortem，行业透明度会否显著提升，否则开发者仍会频繁遭遇“莫名其妙变差”的黑箱体验。AI 编码工具的成熟，终究考验的不是单一模型，而是整个系统工程栈的稳健性。

质量下降时的 Claude Code，颇像一个经验尚浅的实习生在赶工状态下更容易犯低级错误。推理深度压缩导致复杂逻辑推演不够充分，提示词限制则挤压了详细的安全考量空间，结果便是输出中更易出现缺少输入验证、潜在 SQL 注入风险，或不符合 OWASP 最佳实践的不安全数据处理路径。

月16日，第三个变更进一步叠加：在系统提示中新增长度限制，要求工具调用间文本不超过25词，最终响应不超过100词（除非任务需要更多细节）。这一调整原本为减少冗长输出，却直接导致编码质量评估下降约3%。三个变更影响了Claude Code、Claude Agent SDK和Claude Cowork，但API始终稳定。不同变更作用在不同流量切片上，叠加后问题显得随机且难以复现，这也是早期内部调查未立刻对上的原因。

月26日的变更原本旨在优化闲置会话：仅在超过1小时不活跃后，使用clear_thinking header保留最近一个thinking block，配合prompt caching减少后续输入token。实际执行中，bug让这一清除逻辑在会话内所有后续轮次都生效，甚至在中途工具调用时也会丢弃当前推理路径。这直接破坏了Claude作为编码助手的短期记忆链，让模型无法连贯记住“为什么选择这个工具”或“上一步决策的逻辑依据”。

月23日，Anthropic发布了一篇详细的postmortem，明确指出模型权重并未发生变化，底层API也未受影响。问题集中在Claude Code、Agent SDK以及Cowork所依赖的harness层，三处具体变更叠加后引发了系统性体验下降。4月20日，这些变更已全部回滚，并为订阅用户重置了使用限额。

但postmortem点出了这些观点的盲区：问题不在核心模型权重，而集中在Claude Code的harness、SDK和Cowork组件的工具层集成，API端并未受波及。

安全公司 Veracode 的测试数据给出了更具说服力的佐证。在过去一年针对 80 个编码任务的评估中，Claude Opus 4.7 引入漏洞的比例达到 52%，而 OpenAI 模型对应比例约为 30%。TrustedSec CEO Dave Kennedy 通过自建工具进一步观察到，质量下滑期间 Claude Code 的缺陷率比初期高出 47.3% 以上。

类似拉扯在过去AI产品迭代中反复出现，核心在于用户真正想要的是“默认聪明，必要时选快”，而非反过来先给一个快的默认再让大家找回深度。

这个关系链条值得每个决策者反复权衡。