一套客服助手每次回答都要带上服务规则、产品说明和几十个示例，用户只问一句话，前面的长资料却会随请求重新发送。输入越长，这部分重复处理越显眼。提示词缓存就是为这种场景准备的，它让模型服务复用刚处理过的相同前缀，少算一遍输入，也常能缩短等待时间。
我把 Google Gemini 和 Anthropic Claude 的当前缓存文档对着看了一遍。两家实现细节不同，共同点很清楚。缓存依赖重复内容，前缀一变，命中就会下降。它也有长度和时间条件，开了一个选项并不等于每次请求都省钱。
固定内容要放在前面
Google 建议把大段共用内容放在提示开头，并在较短时间内发送相似前缀。Gemini 2.5 及更新模型默认提供隐式缓存，开发者不用另建缓存对象，命中多少可以从响应里的 usage.total_cached_tokens 查看。文档同时列出了最低输入门槛，Gemini 2.5 系列是 2048 token，几款更新的 Flash 模型是 4096 token。短到只有几百 token 的请求，通常够不到这道门槛。
Gemini 也保留显式缓存，让开发者自己创建和管理缓存对象。当前 Interactions API 只支持隐式缓存，确实要控制显式缓存时需改用 generateContent API。选哪一种，取决于业务是否需要自己管理缓存内容和存续时间。
Claude 的规则更适合看清前缀为何会失效。它按 tools、system、messages 的顺序计算缓存内容，一直算到标记了 cache_control 的区块。命中要求这段内容完全一致，文字和图片都算。把当前时间、用户编号或本次检索结果塞进前缀，哪怕只改一个小地方，后续请求也会得到另一份散列结果。
整理提示时，可以先放长期不变的系统规则，再放一批共用资料，最后才接用户问题和每次都会变的内容。这样做同时方便维护。产品说明换版时，缓存自然重建，普通提问则继续复用原来的固定部分。
先看命中记录再算账
缓存也有有效期。Claude 文档写明默认时长为 5 分钟，每次命中会刷新，也提供额外收费的 1 小时版本。一次响应若流式生成了 4 分钟，下一次请求留给默认缓存的时间就只剩大约 1 分钟。低频业务可能经常等到缓存过期，高频客服和批量文档问答更容易连续命中。
它省的是重复输入处理，输出仍由模型照常生成。回答很长时，输出 token 的时间和费用不会凭空消失。上线前最好记录三组数，原始输入 token、命中 token、整次请求耗时，再按业务高峰和低峰分别看。命中率稳定以后，才能把节省写进预算。
我会先挑一条长指令、十个真实问题做小测试。固定前缀保持不动，只改最后的用户问题，确认响应里出现缓存命中。随后故意改一处系统说明，观察命中怎样变化。这两轮跑明白，提示词缓存才算接对。