Claude Code 空格攻击？当检测到非Claude模型时悄悄修改系统提示词导致缓存失效

Claude Code 的 Prompt Cache 机制

在现代 AI 编程工具中，Prompt Caching（提示词缓存） 是降低成本和延迟的重要技术。像 Claude Code 这样的 AI 编程助手，在每次请求时都会发送一段完整的提示词结构，其中通常包括：

• 工具定义（tools）
• 系统提示词（system prompt）
• 会话消息（messages）

缓存机制会对这些内容的前缀部分进行缓存，只要内容保持完全一致，就可以避免每次重新计算全部上下文。

在 Claude 的实现中，缓存通常包含以下顺序：tools → system prompt → messages。只要前缀完全一致，系统就会命中缓存，从而显著减少 token 消耗和响应时间。也正因为如此，Claude Code 的设计原则之一就是：系统提示词尽量保持固定，不要频繁修改，否则缓存会失效。

空格修改现象：为什么一个字符就能破坏缓存

最近在开发者社区中，有人发现一个有趣的现象：当 Claude Code 检测到当前运行的模型不是 Claude 系列模型 时，它似乎会在每次回复前，对系统提示词进行极其微小的修改，例如：

• 在某个位置增加或删除一个空格
• 修改不可见字符
• 改变格式化空白

乍看之下这些变化几乎无法察觉，但对于缓存系统来说却是致命的。

原因很简单：Prompt Cache 是基于字节级一致性（byte-identical）的。只要系统提示词中哪怕一个字符发生变化，缓存前缀就不再一致，于是系统必须重新处理整个上下文。

举个简单例子：

仅仅多了一个尾部空格，缓存就会失效。

为什么会出现这种设计？

关于这一现象，目前社区提出了几种可能解释。

1. 防止第三方模型复用 Claude Code 的优化

Claude Code 的许多优化策略，例如Prompt Cache、工具调用结构、系统提示词布局，都是围绕 Claude 模型设计的。

如果其他模型（例如开源模型或第三方 API）直接复用 Claude Code 的结构，可能会获得不公平的性能优势、绕过官方生态。因此，通过微小修改破坏缓存，可以让非 Claude 模型的运行成本显著增加。

2. 避免错误缓存

另一种解释更偏技术角度。Prompt Cache 的正确性依赖于：

• 模型行为一致
• Tokenization 一致

如果不同模型共享同一缓存，可能导致：

• 推理错误
• 结果不一致

因此系统可能故意让缓存只在 Claude 模型上生效。

3. 商业策略与生态控制

也有开发者认为，这是 AI 平台生态竞争的一部分。AI 编程工具正在成为新的开发入口：

• IDE
• Agent
• Coding CLI

如果 Claude Code 在非 Claude 模型上同样表现优秀，用户可能会直接换用更便宜的模型。因此通过限制缓存优化，可以提高 Claude 模型的性价比优势，强化平台绑定。

因此有网友调侃：这还真的挺 Anthropic 的~

对开发者意味着什么

如果这一行为属实，它会带来几个现实影响：

1. Token 成本上升

缓存失效意味着每次请求都需要重新处理系统提示词，上下文 token 数量暴涨。在大型代码仓库中，这个成本会非常明显。

2. 延迟变高

Prompt Cache 的核心价值之一就是减少推理延迟。当缓存无法命中时模型必须重新读取完整上下文，响应时间会明显变慢。

3. AI Coding 工具的锁定效应

这也提醒开发者一个事实：AI IDE 与模型之间正在形成强绑定关系。未来可能出现类似情况：

不同工具的底层优化，可能只在某些模型上才能发挥最大效果。

结语

Claude Code 修改一个空格破坏缓存的现象，看似只是一个微不足道的技术细节，却揭示了 AI 编程工具背后的深层逻辑：

• Prompt Caching 已成为 AI 工具性能关键
• 系统提示词结构越来越复杂
• AI 平台之间的生态竞争正在加剧

未来，随着 AI IDE 与模型进一步深度绑定，我们可能会看到更多类似的微优化策略。而对于开发者来说，理解这些底层机制，或许比单纯选择哪个模型更重要。