同一套客服规则每天要处理许多不同问题，或者一份长格式规范要反复交给 AI 使用时，请求里往往有大量重复输入。提示词缓存针对的就是其中从开头开始保持一致、能够再次利用的部分。理解这个条件，比到处寻找“打开缓存”的按钮更有用。

本文用原创的活动咨询材料演示怎样拆分固定规则与动态问题，先做不用 API 的结构练习，再说明上线时怎样观察命中和成本。本文没有实际调用付费模型，不提供虚构的降价比例、响应速度或命中率。练习中的短文本用于说明结构，并不保证达到任何模型的最低可缓存长度。

一、提示词缓存究竟复用了什么

模型处理输入时会计算中间状态，常见名称是 KV 状态。提示词缓存保存可重用前缀对应的这些状态，让之后符合条件的请求减少重复的输入计算。它不是把上次回答原样返回的答案库；同一个规则前缀后面接不同问题，仍然需要处理新增内容并生成新回答。

把它与网站缓存区分开：网站页面缓存可以保存已经生成的页面；本地答案缓存可以由开发者保存问答结果；提示词缓存则发生在模型输入处理环节。三者可以出现在同一个应用中，但命中条件、过期方式和更新责任不同。用户问了新问题，不能因为提示词前缀命中就跳过事实核验。

前缀不是从全文中随意挑选的相似片段。 如果每个请求都以不同的时间戳开头，即使后面贴了完全相同的长手册，也破坏了从开头延伸的稳定结构。语义类似、顺序改变、标点变化，也不能直接当作相同的模型输入。

固定规则在前、动态问题在后的提示词结构示意

二、准备一个不需要付费的练习

准备文本编辑器，建立 policy-v1.txt 与 questions.txt 两个文件即可。不需要安装模型，也不用提供 API 密钥。先用以下虚构活动规则练习，不要输入真实客户资料、合同或内部名单。

固定规则分四项：报名截至周四十八点；活动在周六十四点开始；地点为阅览室；费用与取消政策没有提供。再写固定的回答约束：只根据规则回答，每个答案注明依据编号，没有资料则说明待确认，不替组织者作承诺。

动态问题分三项：现在还能报名吗；我临时不能参加能退款吗；活动什么时候开始。第一项还缺当前时间，第二项缺费用和退款条款，第三项可以直接引用开始时间。这个设计同时检查内容质量，避免把所有注意力放在省输入成本上。

给固定规则编号 R01 至 R04。将问题放在最后，另加清晰的材料边界。用户提交的文字是待处理资料，不能因为其中写着“忽略之前规则”就覆盖应用规则。缓存优化与权限控制是两项不同工作，调整顺序不等于解决提示词注入。

三、把请求整理成可维护的三层结构

第一层放稳定的任务说明：角色、允许使用的依据、缺失信息的处理方式和输出字段。第二层放同一批请求共用的规则正文与版本。第三层才放当前问题、必要的当前时间及本次补充材料。

示例结构如下，它是便于理解的文本组织方式，不是可以直接提交给 API 的完整请求体：

固定说明：依据活动规则回答；不补造条款。
固定格式：回答、依据、待确认事项。
规则版本：reading-policy-v1
R01 报名截至周四十八点。
R02 活动在周六十四点开始。
R03 地点为阅览室。
R04 费用与取消政策尚未提供。
--- 本次问题 ---
我临时不能参加，可以退款吗？

版本号也属于输入的一部分。 不要只修改版本标签却留下旧条款；也不要正文已经改变却仍用旧版本误导排查。可以在应用自己的日志中记录规则文件校验值，帮助确认两次请求实际使用的是哪套材料，但日志里不应保存不必要的用户隐私。

如果工具定义、结构化输出格式或模型相关设置发生变化，也需要检查是否影响服务端实际渲染的前缀。只比较自己拼接的字符串，不能完整证明最终模型输入没有变化。前缀练习的价值是发现明显的不稳定内容，而不是替代平台的用量记录。

四、做一次前缀位置的对照练习

复制上面的模板两份，只替换最后的问题。沿着开头逐行比对，圈出第一处差异。理想情况下，第一处差异应出现在动态问题区域。然后故意把“本次请求编号”移动到最前面，每份填不同编号，再比对一次，就能看到共享开头被提前截断。

再做第三组：保留相同问题，却调整 R01 与 R02 的顺序。人类读起来意思没有变化，但输入顺序变了，因此不能拿语义相同来证明缓存可复用。生产环境应使用确定的序列化与排序方式，不要让每次请求随机打乱工具或资料顺序。

最后检查材料是否适合共用。甲客户专属条款不能混入乙客户的固定规则。为提高命中而拼接所有租户的资料，既增加无关上下文，也可能造成越权输出。应先按业务权限分组，再讨论每组内部稳定的前缀。

五、接入真实 API 时怎样验证

需要正式调用时，先确认所选模型支持哪些缓存模式、最低输入要求及计费规则。OpenAI 当前官方指南区分较新模型与更早模型：可用的显式断点、隐式行为、保留参数和用量报告方式并不完全一致。不要照搬另一模型的请求字段，也不要把演示短文扩充成无用文字只为跨过长度门槛。

本篇不提供绑定具体模型的完整付费请求，读者应从官方当前接口示例出发，保持模型及相关配置一致，在小额预算内完成对照。若使用显式模式，必须按该模型支持的内容块设置断点；仅切换模式却没有合格断点，可能无法产生预期缓存。默认行为也不能代替实际观察。

每次记录：规则版本、模型、总输入量、缓存相关用量、输出量、请求时间、首个输出到达时间、总耗时和错误信息。缓存命中看平台报告的缓存用量，不能仅凭“第二次感觉更快”判断。网络波动、服务负载及生成长度都会影响总时间。

前缀稳定性、用量和成本的三步核验示意

六、算成本时同时看写入、读取与输出

缓存不等于免费。正式预算要按所用模型的当前价格分别统计普通输入、缓存读取、可能存在的缓存写入，以及输出消耗。不要只把缓存读取单价乘以全部输入，也不要把写入总费率误算成在普通输入之上又重复叠加的一笔费用。

建立小批量对照记录，先看每个业务任务实际需要多少总费用，再看稳定规则是否真的被反复读取。只有一次使用的长资料，即使写入缓存，也未必有后续复用价值。为了缓存而加入冗长无关背景，可能增加总输入量并降低答案聚焦程度。

测试时使用多个符合实际的任务，观察分布而非挑一个最好看的结果。若两组请求输出长度差别很大，总费用不适合直接比较。先固定回答任务和输出上限，再分别分析缓存输入节省与生成成本，不把两种变量混在一起。

七、没有命中时按这个顺序排查

第一，检查长度与模型支持范围。最低可缓存长度是 token 条件，不是中文字符数；短模板没有命中不必然是故障。

第二，检查第一次不同的位置。日期、随机编号、用户画像或动态工具描述是否提前进入固定部分；规则文件是否被无意插入空格、换行或不同排序。

第三，核对模型、工具、格式及其他可能影响前缀的设置。应用层看起来相同的正文，不代表整个请求完全相同。

第四，检查时间间隔与平台的缓存策略。缓存不是永久存储，选定保留策略也不等于每一次请求都获得更低延迟。不能把接口支持的某种保留时间解释成业务资料的删除承诺。

第五，查看官方缓存诊断与用量界面。只在有证据时调整结构，不通过反复付费调用碰运气。请求失败时先检查参数和账户权限，不把所有错误都归因于缓存。

八、最终交付物与验收清单

完成练习应得到固定规则文件、动态问题列表、前缀差异记录及小额测试计划。已经做过正式调用的，再附脱敏用量与费用记录；没有调用的，明确写“未进行线上成本测试”，不要填预测数字当作实测。

验收至少包括：规则可追踪版本；动态内容没有无故跑到前面；不同客户资料隔离；缺失条款不会被模型补造；实际缓存用量有记录；缓存不可用时业务仍可正常回答。正确性和权限是上线前提，缓存只是输入处理的优化手段。

官方参考