如何通过 Prompt 缓存技术降低长文本对话的 Token 消耗

Claude 3.5 Sonnet 和 GPT-4o 这种长上下文模型最吃钱的地方，就是每次对话都要把之前的几万字历史记录重新传一遍。其实用好 Prompt Caching（提示词缓存），能直接把重复输入的 Token 成本砍掉 90%，响应速度还能快一截。

最核心的逻辑是：把那些固定不变的、体积巨大的部分（比如 API 文档、项目代码库、复杂的 System Prompt）放在缓存区，只要这部分内容没变，模型直接读取快照，不再重复计算。

在 Claude API 中，缓存不是自动的，必须在消息体中显式地给需要缓存的节点打标。一个实战技巧是：把最重的“知识库”放在最前面，然后在关键的转折点加上 cache_control。

具体请求结构参考：

{
  "model": "claude-3-5-sonnet-20240620",
  "max_tokens": 1024,
  "system": [
    {
      "type": "text",
      "text": "这里放入 20k 字的项目全局架构文档和编码规范...",
      "cache_control": { "type": "ephemeral" } 
    }
  ],
  "messages": [
    {
      "role": "user",
      "content": "基于上述文档，帮我写个登录页面的接口调用逻辑。"
    }
  ]
}

这里有个容易踩的坑：缓存是顺序敏感的。如果你在缓存节点中间插入了一个词，或者修改了开头的一句话，那么该节点之后的所有缓存全部失效。所以建议把动态变化的变量（比如当前时间、用户 ID）全部放在消息的最末尾，绝对不要插在缓存块中间。

针对 Cursor 等 AI 编辑器的用户，虽然底层封装了缓存，但你可以通过优化 .cursorrules 来间接提升效率。不要把所有琐碎的要求写在规则里，而是建立一个 docs/context.md 专门存放静态知识，在对话中用 @ 引用。这样 AI 客户端在处理上下文窗口时，更容易触发底层的缓存机制，而不是每次都全量刷新。

效率提升对比：
未开启缓存： 每次提问 → 重新计算 20k Tokens → 延迟 3-5 秒 → 支付全额费用。
开启缓存： 每次提问 → 命中 20k 缓存 → 延迟 < 1 秒 → 仅支付极低额度的缓存命中费用。

对于需要频繁喂入大规模代码库的开发者，这种配置能让对话体感从“思考很久”变成“秒回”。