写完一篇解释 DeepSeek 提示词缓存（prompt caching）的文章后，我以为问题已经说清楚了：
表达精准，是为了减少输入浪费和澄清轮次；前缀稳定，才更有利于缓存复用。
但一条评论让我发现，我还混淆了两种请求结构。
简化缓存理解基本成立
读者说，普通多轮聊天中，每一轮都会把历史记录和新问题一起提交。对话越长，前面通常能复用的内容越多。用词是否精准，和缓存命中没有直接关系。
这个理解放在追加式对话里基本成立。
DeepSeek 的多轮对话接口是无状态接口（stateless API）。服务端不会替用户保存对话上下文，调用方需要把历史消息重新提交。标准做法是保留前面的消息，把模型回答和新问题依次追加到末尾。
比如第一轮提交一段 316 不锈钢保温杯资料，让模型写标题；第二轮追加“再补充三条购买理由”。旧资料、旧任务和旧回答仍在前面，新要求只加在末尾。只要前面的实际输入没有变化，后续请求就可能复用已有缓存。
即使后来补一句“前面不是 316，而是 304”，追加式对话通常也不会改掉旧消息，而是在末尾加入纠正。原来的前缀仍然存在。
但这不是所有聊天产品的固定行为。工具也可能编辑旧消息、裁剪历史或压缩上下文。缓存真正匹配的是每次实际提交的输入，不是界面上看起来是否还在同一段对话。
文档工具更容易改动前缀
写文章、改代码或处理资料时，工具经常会重新组装请求。比如 A 是一篇文章草稿，B 是“修改标题”，C 是“检查逻辑”，D 是“润色结尾”。如果工具每次都发送 A+B、A+C、A+D，只要 A 保持不变，后续请求就有机会复用共同前缀。
但真实写作中，A 往往一直在变。你刚改了开头，又调整了小标题，再删掉一段背景。前部输入随之变化，原有缓存能复用的部分通常会减少。
具体能命中多少，还取决于系统此前保存了哪些缓存前缀单元。DeepSeek 的缓存采用尽力而为（best effort）机制，并不保证每次命中。因此，不能只根据文档修改位置精确计算缓存量。
所以，对用户来说，可以先把它理解成两种场景：普通聊天的前缀通常更稳定，文档工作流的前缀更容易变化。从技术上看，真正的区别仍然是工具怎样组织请求：
- 只在末尾追加，前缀通常更稳定；
- 重新组装内容，尤其改动靠前部分，前缀更容易变化。
真正值得做的优化
普通聊天不必为了缓存刻意改变说话方式。先把问题说清楚，减少无效来回。
如果能够控制文档工具的请求结构，可以把长期稳定、会反复使用的内容放在前面，比如系统提示词、工具定义、固定规则和参考资料；把本轮指令、临时意见和局部修改放在后面。关键不是意思大致相同，而是前面的实际输入保持不变。
缓存也不是模型记忆。系统只是复用了相同前缀的计算，主要影响计费和速度。模型看到的仍是本轮提交的完整输入。命中缓存，不代表模型多知道了什么；没有命中，也不代表模型少看了内容。
写到最后
折腾一圈，我反而觉得，大多数人不需要刻意优化缓存。
缓存命中后的输入单价可以低到未命中的五十分之一。但如果本来只花几分钱，再便宜五十倍，也改变不了什么。为了这点成本，反过来约束自己怎么提问、怎么写作，不值得。只有长文档被大量重复调用时，缓存才真正成为一个工程问题。
我研究它，不是因为人人都该懂，只是工作中碰到了，好奇它为什么这样，于是弄明白，再记录下来。
平时把问题说清楚就好。缓存能命中就命中，不能命中也没关系。