如果你的 AI 应用有一段很长的系统提示词、一份塞进上下文的文档、或者一批固定的少样本示例，而这些内容在每次请求里几乎原封不动地重发一遍——那你正在为同样的输入 token 反复付费。Prompt Caching（提示词缓存）就是来解决这件事的：把请求里稳定不变的前缀缓存住，命中后这部分 token 大幅降价、还更快。
这篇文章讲清缓存的原理、OpenAI 和 Claude 两家机制的关键差异、实际能省多少，以及最重要的——怎么组织你的提示词才能真正命中缓存。
缓存的前提是「前缀完全一致」：稳定的内容放前面，变化的内容放后面。
为什么会有重复付费
模型 API 按 token 计费，输入和输出分别计价。很多应用的请求结构长这样：
[系统提示词 2000 token] ← 每次都一样
[工具定义 1500 token] ← 每次都一样
[知识库/文档 5000 token] ← 每次都一样
[对话历史 …] ← 缓慢增长
[本轮用户提问 50 token] ← 每次不同前面近万 token 的前缀，每次请求都完整发送、完整计费，而真正变化的可能只有最后几十个 token。请求量一大，这部分重复输入就是账单的主要构成。Prompt Caching 让服务端把这段稳定前缀的计算结果缓存下来，下次命中时不必重算，价格随之大降。
两家机制的关键差异
缓存的计价和触发方式各家不同，用之前必须搞清楚——这直接决定你能不能省到钱。以下为机制层面的说明，具体折扣比例和有效期以厂商官方文档实时为准：
| 维度 | OpenAI 系 | Claude（Anthropic） |
|---|---|---|
| 触发方式 | 自动，前缀匹配即命中 | 手动，用 cache_control 显式标记断点 |
| 是否要改代码 | 基本不用 | 需要在请求里打缓存标记 |
| 写入是否额外收费 | 通常无额外写入费 | 写入缓存有一定溢价，命中才回本 |
| 命中读取价格 | 显著低于原价 | 显著低于原价 |
| 缓存有效期 | 较短、自动管理 | 有基础档，也可选更长有效期档位 |
| 最低缓存长度 | 有一个起始 token 门槛 | 有一个起始 token 门槛 |
核心区别是自动 vs 手动：OpenAI 你几乎什么都不用做，把稳定内容放前面就会自动命中；Claude 需要你主动用 cache_control 标出「缓存到这里」，灵活度更高（能精确控制缓存哪几段），但写入有溢价，意味着缓存内容必须被复用足够多次才划算——只用一两次反而更贵。
能省多少：先算一笔账
省多少完全取决于「稳定前缀占比」和「复用次数」。做个简单估算：假设前缀 8000 token、变化部分 200 token，前缀命中缓存后按原价的一小部分计费。
- 前缀占比越高、命中读价越低，省得越多——像客服机器人（长系统提示 + 固定知识）、代码助手（长文件上下文）、文档问答（同一份文档反复问）这类场景，输入成本往往能降到零头。
- Claude 的手动缓存要考虑写入溢价：第一次请求写缓存比不缓存还略贵，从第二次命中起才开始赚。所以复用次数少（比如一次性批处理里每条前缀都不同）时，手动缓存可能不划算。
结论：高前缀占比 + 高复用次数 = 缓存的甜点区。反过来，每次请求前缀都不一样的场景，缓存帮不上忙。
算清楚「前缀占多少、复用多少次」，再决定用不用手动缓存——不是所有场景都赚。
命中缓存的三条铁律
缓存基于前缀精确匹配，一个字节不同，从那里往后全部失效。所以提示词的组织方式直接决定命中率：
1. 稳定的放前面，变化的放后面
把系统提示词、工具定义、固定示例、知识库文档这些不变内容全部前置；把用户提问、当前时间、随机 ID 等易变内容放最后。顺序错了，缓存等于没开。
2. 别把变量插进稳定区
一个极其常见的错误：在系统提示词里插入 当前时间：2026-07-14 15:32:01。这一下让整个前缀每秒都在变，缓存永远命中不了。动态信息一律移到提示词末尾，或作为单独的用户消息。
3. 保持前缀字节级稳定
JSON 字段顺序、空格、换行的任何变动都会让缓存失效。序列化时固定字段顺序，别用会随机排序的结构。Claude 的手动缓存要把 cache_control 断点打在稳定区和变化区的边界上。
✅ 正确结构 ❌ 错误结构
[系统提示] ← 缓存 [系统提示 + 当前时间戳] ← 每次都变，永不命中
[工具定义] ← 缓存 [用户提问]
[文档] ← 缓存 [文档] ← 变化内容夹在中间，后面全失效
─缓存断点─ [工具定义]
[对话历史]
[用户提问] ← 不缓存和其他降本手段配合
Prompt Caching 只是降本工具箱里的一件。配合使用效果更好：
- 模型路由：简单任务走便宜模型，复杂任务走旗舰模型，见模型路由；
- 网关统一管理：在 AI 网关层统一开启和监控缓存命中率，比每个应用各自配置更可控；
- 控制上下文长度：缓存降低了长前缀的成本，但不等于可以无限堆上下文——长上下文本身有信息利用率问题，能精简还是要精简。
缓存命中率是可监控指标：把它接进网关或日志，才知道优化有没有生效。
适用人群与常见坑
适合有稳定长前缀、请求量较大的应用开发者：客服、代码助手、文档问答、RAG、批量处理都是典型受益场景。几个高频坑：
- 以为开了就一定省：Claude 手动缓存写入有溢价，低复用场景反而更贵，先算账；
- 动态内容污染前缀：时间戳、随机 ID 混进稳定区，命中率归零，这是最常见的失误；
- 缓存过期没预期：缓存有有效期，低频请求可能每次都过期重写，享受不到读价优惠——高频调用才是缓存的主场；
- 不监控命中率：以为在省，其实因为结构问题一直没命中。务必在响应的 usage 里查缓存命中 token，用数据确认。
常见问题
Q：缓存会泄露我的提示词给别人吗？ A：不会。主流厂商的缓存按账户/组织隔离，缓存的是你自己的前缀供你自己复用，不跨账户共享。但敏感数据的合规要求仍以厂商条款为准。
Q：缓存会影响模型输出质量吗？ A：不会。缓存只是复用前缀的中间计算结果，模型看到的完整输入和不缓存时一模一样，输出没有区别。
Q：对话历史越来越长，能缓存吗？ A：能，而且很划算。对话历史是「只增不改」的前缀——每轮新增内容追加在后面，之前的历史保持不变，正好符合缓存的前缀匹配特性。把动态的当前提问放最后即可。
小结
Prompt Caching 的收益公式很简单：稳定前缀越长、复用次数越多，省得越多。用好它只需记住三件事——稳定内容前置、动态内容后置、前缀字节级不变。OpenAI 自动命中省心，Claude 手动标记灵活但要算写入账。开启后别忘了监控命中率，用数据证明你真的省到了钱。