MemoryLake
返回全部文章
Tutorial2026 年 7 月 31 日·7 分钟阅读

如何停止向 Claude 重复上传 PDF (2026)

这个月你已经把同一份 180 页的合同附件上传到了五个不同的 Claude 对话中。每一次,你都要重新解释哪些条款重要,重新说明第 14.3 条已取代先前的草案,并重新提出你已经解答过一次的问题。文档本身并没有改变,改变的只是 Claude 对它的记忆被重置了。

直接的答案是:附件属于对话,而不属于你。当对话结束时,该文档在对话中的存在也随之结束——你对它得出的所有结论也同样烟消云散。Claude 并没有“拥有”你的 PDF 库;它只是在这一刻、在这个线程中,阅读你递给它的东西。

关于这种“阅读”有多昂贵,有一个最新且极具启发性的数据。2026 年 7 月 30 日,MarkTechPost 发布了 Token Saver,这是一个适用于 Claude Desktop 的 MIT 许可 MCP 扩展,它可以在你的 PDF 上运行本地混合搜索——BM25 关键词检索加上本地 `all-MiniLM-L6-v2` 嵌入模型——并且只向 Claude 发送与你的问题相匹配的段落,同时附带准确的页码,且文件永远不会离开你的机器。据报道,在处理大型文档时,它可以减少 92–99% 的 token 消耗

这个数字值得我们深思,因为它量化了默认情况下的代价:在没有检索的情况下,你正在为了回答一个问题而付费重新阅读整份文档。但更便宜的阅读并不等于记住。Token Saver 让每个问题的成本大幅降低;但它无法让明天的对话知晓今天得出的结论。本指南旨在弥合这第二个差距。

为什么你一直在重复上传相同的文档

附件的作用域仅限于对话

上传的文件是对话上下文的一部分,而对话是一个有边界的对象。开启一个新对话,文件就不在了,提取的条款不在了,你针对它进行的推理也不在了。这与为什么 Claude 会遗忘你上传的文件中所记录的壁垒是一样的——并没有什么东西坏掉,只是作用域比你的工作流要窄。

全文阅读是昂贵的默认设置

Token Saver 的数据是对这一情况最清晰的公开说明。如果仅检索相关段落就能减少 92–99% 的 token 使用量,那么基线情况——即为了让模型回答关于第 112 页的一个问题而将整个文档推入上下文——就是几乎所有成本的来源。乘以你重新上传同一文件的次数,这种浪费就绝非小数目了。

Project 知识库有所帮助,直到它被挤出上下文

将参考文档放入 Claude Project 中是一个真正的改进:它们可以用于该项目中的每个对话,而不是仅限于一个。但瓶颈会出现在长时间的工作会话中,随着对话的增长,知识文件可能会被挤出有效上下文——其机制在为什么 Claude 会遗忘你的项目知识文件中有所提及。Project 是一个更好的容器。但它仍然只是一个容器,而且它保存的是文件,而不是结论。

你想要保留的通常不是文件本身

注意你每次实际上重新确立的是什么:不是 PDF 的字节,而是结论。哪个条款起支配作用。附录中重申了哪些数据。你的法律审查标记了哪三个段落。这些是从庞大、静态的文档中提取出来的微小、持久的事实——而这恰恰是任何附件机制都无法存储的。

各种替代方案的客观评估

每次都重新上传

有效,但成本最高,且体验会悄然下降:在第三次上传后,你就会停止重新解释那些细微差别,而答案也会在没人注意到的情况下变得更加肤浅。

本地检索扩展

Token Saver 及类似工具是解决真实问题的真正方案。每个问题的成本下降了一个数量级,敏感文档保留在你的磁盘上,页级引用使结论可被核对——这比粘贴你无法再追踪来源的文本具有真正的优势。但它们无法做到的是持久化:检索只是对文档进行索引,它不会承载你已经做出的决定,而且它只存在于你安装它的机器上。如果你的同事下周问同样的问题,他们必须从零开始。这种区别正是为什么 RAG 不是记忆的全部主题。

将摘要粘贴到每个新对话中

这是一种务实折中的方法,但也是一种会逐渐失效的方法。摘要会偏离源文档,没有人对其进行版本控制,一旦文档被修改,你就会在流传中得到两个相互矛盾的事实。

构建你自己的流水线

分块、嵌入、排序、刷新、访问控制。如果文档智能是你的产品,这很合理。如果你只是想让 Claude 停止询问它已经知道的事情,这就太昂贵了。

解决方案:赋予 Claude 跨越对话的文档记忆

终结这一循环的方法是将文档及其提取的结论保存在一个你的工具可以读取的统一地方,而不是保存在单个对话中。这就是 MemoryLake 所扮演的角色:上传一次,即可通过 MCP 或 API 在任何助手或智能体中进行检索。

步骤 1:创建 API 密钥

生成密钥并在大约 30 秒内发出你的第一次请求。

创建 MemoryLake API 密钥
创建 MemoryLake API 密钥

步骤 2:上传你的第一批记忆

放入你经常重复添加的文档、图像和文件:合同、规范、研究论文、董事会简报、政策手册。同时添加相应的结论——起支配作用的条款、已更正的数据、你的团队已经审查过的部分。

上传你的第一批记忆到 MemoryLake
上传你的第一批记忆到 MemoryLake

步骤 3:连接你的 AI 和智能体

让 Claude、Codex、OpenClaw 以及你的其他智能体通过 MCP 或 API 访问该记忆。新对话开启时,模型就已经知晓该文档,而同事的对话也会从相同的源头开始,而不是使用他们自己的副本。有关特定客户端的演练,请参阅如何为 Claude Code 添加记忆

通过 MCP 连接你的 AI 和智能体
通过 MCP 连接你的 AI 和智能体

这在实践中改变了什么

以一份大约 90,000 个 token 的 180 页合同为例。一个月内将其添加到五个对话中,在提出任何后续问题之前,就需要重新阅读大约 450,000 个 token。检索式工具可以将每个问题的这部分消耗减少 Token Saver 所报告的 92–99%;而持久化记忆则免去了账单的另一半,即你因为之前的推导被丢弃而不得不重新推导相同结论的那部分。

时间是更敏感的成本。每个对话需要 5 到 10 分钟的重新熟悉时间,每周进行几次对话,涉及接触该文档的每个人——而且存在第四次重新解释时遗漏第一次所包含的限制条件的风险。跨工具的一致性也源于同样的解决方案:当 ChatGPT 和 Claude 读取同一个记忆时,它们就不会再对同一个 PDF 给出不同的答案,而这正是 ChatGPT 遗忘你上传的文件背后的问题。

文档记忆的最佳实践

存储结论及其引用来源

“终止合同需要提前 60 天通知——第 14.3 条,第 41 页”值得永久保留。完整的条款文本则不需要,它已经在文档中了。存储结论及其定位信息,能让你以极小的体积获得可检索性和可验证性。

保持单一事实来源,并进行版本控制

当文档被修改时,替换已存储的事实,而不是在旧事实旁边添加新事实。同一个条款有两个活跃版本比没有更糟糕,因为模型会非常自信地选择其中一个。

将参考语料库与决策分离开来

文档是输入;决策是你的团队产生的结果。两者都要保留,但不要让不断堆积的 PDF 淹没真正指导行为的那十二句话。

结论

向 Claude 重复上传 PDF 并不是一个你需要克制自己的坏习惯——它是将文档存储在对话内部的必然结果。2026 年 7 月 30 日发布的 Token Saver 扩展等本地检索工具证明了这种默认行为的成本有多高,并以坦诚且私密的方式解决了每个问题那一半的开销。

另一半是持久性:你得出的结论,可用于下一个对话、下一个工具和下一个人。将文档及其结论放入你的智能体可以读取的记忆层中,第五次上传就永远不会发生,因为没有什么需要重新确立的了。

常见问题

为什么 Claude 不记得我昨天上传的 PDF?

因为上传的文件属于该对话。Claude 在对话的上下文中读取附件;当对话结束时,该文档的可用性以及针对它得出的所有结论也随之结束。持久性必须来自对话之外的东西。

Token Saver 扩展是否能赋予 Claude 长期记忆?

不能,它也没有这样声称。它于 2026 年 7 月 30 日作为 Claude Desktop 的开源 MCP 扩展发布,执行本地混合搜索(BM25 加上本地嵌入模型),并且仅发送匹配的段落,据报道可节省 92–99% 的 token,并提供页级引用。这是检索效率和隐私保护——而不是跨对话的记忆,也无法与你的团队成员共享。

Claude Projects 对于参考文档来说足够了吗?

它们是一个真正的改进,因为文件可以在项目内的各个对话中共享。其局限性在于,在长时间的会话中,知识文件可能会被挤出有效上下文,而且项目保存的是文档,而不是你从中得出的结论。

我应该将整个 PDF 存储在记忆中,还是只存储结论?

两者都需要,它们扮演不同的角色。保持文档可检索,并将一小部分持久的结论(带有页面引用)作为一等记忆进行存储。否则,这些结论就会被重新推导。

同一个文档记忆可以服务于 Claude 和其他工具吗?

可以,当记忆存在于任何单一客户端之外,并通过 MCP 或 API 进行访问时。这就是防止两个助手对同一份合同产生不同解读的方法。