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