提示词缓存

缓存只认前缀：前缀逐字不变才打折，顺序一换整条作废。所以提示词的排列顺序是一件经济决策。

同一套提示词、同一个模型，两个团队的实际成本可以差一倍，区别往往只在一件事：缓存命中率。而命中与否不由内容决定，由顺序决定——前缀逐字不变才打折，顺序一换整条作废。

读完你能回答：

命中只认前缀，而且要逐字一致

厂商的做法是：把你这次请求的开头一段和之前某次请求比对，一致的那一段不用重新计算，所以按折扣价计费。折扣可以很大，这是成本优化里最直接的一个杠杆。anthropic-prompt-caching 两家厂商的文档把这套机制讲的是同一件事，差别只在怎么开启。openai-prompt-caching

两个词要拆开看。

「前缀」意味着只有开头那一段能吃到。缓存是从头开始连续匹配的，中间任何位置出现不一致，后面的部分就都吃不到。

「逐字一致」意味着差一个字符就断。不是「意思一样」就行，是字面上必须相同。

两条合起来推出一个反直觉的结论：命中与否不由「内容是否相同」决定，而由「前缀是否逐字相同」决定。同一批材料，这次 A 在前 B 在后，下次 B 在前 A 在后，两次都不命中——尽管你一个字都没改。

还有一条：它要么整段命中，要么完全不命中，不存在只命中一部分。从第一个对不上的位置往后，全部按原价结算。所以真正该问的不是「命中了多少」，而是「从哪里开始对不上」。这个位置比命中率本身更有用，因为它直接指出该改哪一行。

按这个顺序组织每次请求：

固定不变的放最前。系统提示、长期规则、固定知识——每次一样，构成稳定的缓存前缀。
会变的放最后。本轮的问题、临时指令、这次检索到的材料。
中间不要出现会变的东西。时间戳、随机数、用户标识，以及运行时拼出来的字符串，只要落在前缀范围内，每一次请求都会产生差异，缓存也就永远命不中。模型如果确实不需要这些字段，就不要把它们写进提示词。
变的内容也给它一个固定顺序。检索材料每次都不同，但排序规则可以固定，比如按相关度降序。结构稳定本身就有价值。

还有一条容易被忽略的动作：把频繁改动的长期规则从系统提示里拆出来。放在系统提示之后单独一段。这样你改规则时，前面那一段仍然命中。分层加载在这里有直接的经济意义——它不只是注意力管理，也是账单管理。

省下来多少，取决于两件事相乘：折扣的力度有多大，以及你的输入里有多大比例落在稳定前缀之内。厂商定的是前一个数，你能动的是后一个数。

一个合同审查助手可以说明这件事：它每次请求都带着同一份审查规则和输出格式模板，这一部分占掉了输入的大头，而每轮真正新增的只是待审的一段条款。规则不改，前面那一大块就一直按折扣价算；输入成本能压掉多少，取决于这部分的占比，而不是取决于折扣本身有多狠。

一句话：顺序不是排版问题，是计价问题。

把前缀钉住，意味着你放弃了随时改开头那部分的自由。这是一笔明确的取舍，不是白拿的好处。

前缀越长，折扣越多，但改它的代价越大。因为一改，整条前缀重新积累。所以正在每天调提示词的功能，缓存收益会被反复清零。

系统提示要频繁调整时，它会变成永远付原价的那一段。这时候别急着优化缓存，先把结构定下来。定型之后再固化，收益才稳定。

固定的是结构，不是内容。该随任务变的部分必须变；把本该变化的内容硬写成固定文本，是自欺欺人——它既没省到钱，还让提示词变差。

所以判断标准是：这段内容会不会经常改？经常改的，放后面；不常改的，放前面。这条标准比任何技巧都好用。

还有一条同样重要的边界：缓存不吃输出那一档。它打折的是输入，输出那一段多少钱都不打折。所以一个输出为主的链路，把前缀调得再稳，能省下的也只是账单一角。

多数厂商的计费明细里会分开显示缓存命中的用量。把它记进日志，算一个命中率：命中的输入量除以总输入量。

这条指标值得和成本一起按天看。它是少数几个既能解释账单、又能直接指导改动方向的指标。

推不出「所以缓存能救所有成本问题」。能打折的只有输入那一档；如果你的账单主要是输出，先把输出压下来，再回头看缓存，顺序不能反。

也推不出「换个便宜模型就一样省」。缓存是在同一个模型、同一个厂商内部积累的，换模型、换厂商都意味着重新开始积累。所以按任务分档配模型时，要考虑的不只是单价，还有切换本身的成本——一个便宜一点但吃不稳缓存的档位，算总账可能更贵。

命中率还是一个典型的「能归因才有得优化」的指标。它必须和模型、链路、调用次数一起记录，否则你只知道账单涨了，不知道是哪条链路涨的。成本要能归因到每一步讲的就是怎么把它拆开。