提示词缓存省钱，先检查前缀和命中率

Prompt caching 能省 API 费用，但开了缓存，不代表账单就会降。原文的核心判断是：能否省钱，首先取决于提示词的组织方式。大段固定内容放在哪里、每次请求是否保持一致，比单纯开启缓存更关键。

这篇短文没有实测账单，也没有模型之间的对照。它提供的是三个排查方向：固定内容放前面、优先缓存大块重复上下文、检查实际命中情况。对维护 AI 应用的前端和全栈开发者，这些建议适合拿来检查请求构造逻辑。

为什么内容没变，缓存却可能用不上

原文讨论的是前缀匹配：系统从提示词开头寻找可以复用的相同内容，而不是在整段请求中随意寻找重复段落。

因此，system prompt、工具定义、大段固定参考资料，都应该排在每次请求变化的内容之前。用户问题等动态内容则放到后面。

缓存需要的是稳定的共同开头，而不只是请求中存在相同文本。

例如，同一份参考文档被反复发送，如果它前面先出现每次都不同的用户问题，文档本身再稳定，也不符合作者建议的组织方式。动态内容越早出现，后面的大段固定内容就越难作为共同前缀复用。

作者强调，缓存前缀需要逐字节一致，其中一个字符发生变化，就会破坏对应匹配。这里要保留一个边界：原文没有指定 API，也没有解释部分前缀复用或具体匹配规则，不能据此断言所有服务都会整段缓存失效。可以直接采用的原则是，尽量保持固定内容的文本和顺序稳定。

什么内容才值得花时间做缓存

作者列出的高价值对象包括参考文档、工具 schema，以及较长的 system prompt。它们有两个共同点：体积大，而且会跨请求重复出现。

如果 system prompt 本来只有很短一段，即使命中缓存，可节省的费用也有限。反过来，一大段固定资料反复随请求发送，才更有优化空间。

所以，判断优先级时不能只问「能不能缓存」，还要问「重复发送了多少内容」。

这也解释了为什么有些实现开启缓存后几乎没有收益：可能是提示词排列不合适，也可能只是被缓存的内容太少。原文没有提供长度门槛、折扣比例或成本公式，不能从中推导出具体省钱幅度。

怎样确认缓存真的在工作

作者建议直接查看 API 响应中的缓存命中信息，而不是根据配置判断缓存已经生效。

原文称，多数 API 响应会报告缓存命中情况，但没有给出具体字段名或响应示例。落到项目里，需要按所用服务的响应结构读取，不能凭这篇文章照搬某个字段。

检查时可以围绕同一组固定上下文发起多次请求，再改变末尾的用户问题，观察缓存信息。如果命中率接近零，就回头检查固定内容前面是否混入了动态文本，以及固定块是否在请求之间发生了细微变化。

缓存配置只说明你尝试启用了它，响应数据才能帮助判断它是否生效。

命中也不等于收益足够大。原文把命中率作为重要检查项，但没有进一步展示它与实际费用的关系。

我的判断

这篇文章最有用的地方，是把成本问题落到了请求构造上。相比一开始就更换模型，检查内容顺序和重复上下文，通常更容易形成具体、可审查的改动。

但它提供的是实践建议，没有披露作者或团队的实验过程，也没有命中率、账单或改造前后的对照数据。「能显著省钱」有明确前提，不能当成已经验证的普遍结论。

还要区分缓存与删减上下文。缓存适合重复发送且确实需要的固定资料；如果某段内容对任务没有帮助，先减少无效输入更直接。具体应选哪种做法，要看任务需要和实际计费，原文没有提供比较结果。

能拿来做什么

• 在 Node 服务端集中构造 AI 请求，把固定指令、工具定义和公共资料放在动态问题之前，并检查固定块是否被意外插入了变化内容。
• 对带参考文档或大量工具 schema 的应用，优先检查这些大块重复内容；只有短提示词的功能，可以先评估优化收益。
• 在现有请求日志中记录服务实际返回的缓存信息，调整提示词顺序后比较命中情况和费用，用数据决定是否继续优化。