提示词缓存降本：前缀稳定是关键

同一个模型，为什么有人用起来便宜，有人账单却高得多？作者把主要原因归到提示词缓存（prompt cache）：反复发送的固定内容，如果命中缓存，就能按更低的输入价格计费。

这篇最有用的地方，是把省钱问题落到了提示词的排列方式上。不过，文中的价格、命中率和会话建议都有适用前提，不能直接当成所有模型、所有团队都成立的结论。

缓存省的是重复输入，关键在前缀

按原文描述，模型输入存在标准输入和缓存读取两档价格。作者列出的每百万 token 价格是：Claude Sonnet 5.5 标准输入 $2、缓存读取 $0.10；Claude Fable 5.1 标准输入 $10、缓存读取 $0.25。

这些是原文给出的型号和报价，文章没有附上可核对的定价内容，本文也未独立核验，不宜直接拿来做采购预算。

缓存匹配的是前缀，也就是请求开头连续相同的内容。系统提示词、工具定义、少样本示例（few-shot examples）如果每次都保持一致，就有机会复用。某处内容发生变化，后面的部分即使文字相同，也可能无法沿用之前的前缀缓存。

缓存优化首先是组织重复内容，而不是一味缩短提示词。

作者称，从他们的网关观察，Claude Code、AI Chat 这类每轮携带系统提示词和历史消息的工具，在正常会话中通常能达到 60% 以上的命中率。但文章没交代样本量、统计周期，也没明确这个比例按请求数还是 token 数计算。

三个写法调整，围绕同一个原则

第一，把固定内容放前面，把变化内容放后面。系统提示词、工具定义和固定示例排在前部，用户输入、检索结果放在后部。这样每轮请求即使追加新内容，也能尽量保留前面一致的部分。

第二，把时间戳、随机 ID 等动态字段移出前缀。作者举的反例，是在系统提示词中嵌入时间戳，导致缓存命中归零，成本增加数倍。

问题不在于请求中不能出现日期，而在于它出现得太早。业务需要当前时间时，原文建议把它放进末尾的用户消息。随机 ID 也应避免混入原本可以重复使用的固定内容。

第三，连续任务尽量延续会话，让系统提示词和已有历史形成可复用的前缀。作者认为，每轮重新开启会话会损失这些复用机会。

这条需要保留一点判断：文章把「重开会话」与「缓存失效」直接关联，却没有说明服务商如何识别缓存。按照它自己强调的前缀匹配逻辑，如果新请求仍保留相同前缀，仅凭会话是否重开，还不足以判断能否命中。

我的判断

我赞同先整理提示词，再看账单。对已经有较长系统指令、工具定义和多轮历史的 AI 应用，这是一项很具体的优化：内容可以继续保留，只需避免无意义的动态字段提前打断前缀。

但文章的结论比证据走得更远。作者称，同模型用户之间的费用差异「十有八九」来自缓存，又用「命中率翻倍」描述三种技巧，却没有提供对应的统计依据或改造前后数据。这些应当视为经验判断。

60% 以上的命中率也不能直接理解成账单节省 60%。原文要求关注的用量明细包括标准输入、缓存写入和缓存读取，但没有交代缓存写入的价格，也没有把输出费用纳入比较。只看读取折扣，算不出完整成本。

与直接删减上下文相比，调整顺序更适合固定内容占比较高的请求；如果每次任务差异很大、重复前缀很短，它的收益就未必明显。文章也没有提供这两种做法的对照数据。

能拿来做什么

• 检查 Node 服务组装模型请求的代码，把系统指令、工具定义和固定示例集中放在前部，再追加用户问题与检索结果。
• 排查系统提示词里的时间戳、随机 ID 和当前日期，把业务必需的动态信息移到靠后的消息中。
• 在 Claude Code 等多轮编程场景里，围绕同一任务连续交互，并观察缓存读取用量；不要仅凭会话长度判断是否省钱。
• 调整后连续运行几轮，在控制台比较标准输入、缓存写入和缓存读取 token，同时核对总费用。缓存读取占比上升，是优化生效的线索，最终仍要看账单。