Claude 吃 PDF 一次烧掉 8 万 token?这个 MCP 扩展把账单砍掉九成,还不用上传整份文件

摘要

你丢一份 100 页的 PDF 给 Claude，让它帮你找几个关键条款。

它吭哧吭哧把整份 PDF 的 token 全塞进上下文，给出答案。挺好用。

但你打开账单一看，一次对话，烧掉 8 万 token。按 Sonnet 5 的定价，$0.24 没了。

你一天要处理 10 份这样的 PDF，每份问 3 个问题。

月底账单：$216。一年 $2,592。

更糟的是——你的合同、财报、病历，全都上传到了 Anthropic 的服务器。

有没有办法让 Claude 只吃该吃的那点 token，剩下的靠本地检索补？文件还不上传？

有，本周刚上线的一个开源工具，把这事做到了极致。

一句话定位

Token Saver 是 Marktechpost AI 团队 7 月 30 日发布的一个 Claude Desktop 扩展。

它干的事很简单：你在本地指定一个放 PDF 的文件夹，问 Claude 问题时，它先在本地把相关段落检索出来，只把那几段喂给模型——不是整份 PDF。

省多少？仓库公开的 eval 数据是 92-98%——但有条件。条件是什么，后面说。

GitHub 地址：https://github.com/Marktechpost/Token-Saver ，截至发文 41 star。

🗣️ 说人话：以前你问 Claude 关于 PDF 的问题，模型必须接收整份 PDF 的全部 token 才能回答；现在它只需要接收检索出的相关段落。极端高频大文件场景下，账单可能从 $216 量级降至 $8 量级。

它是怎么做到的

原理不复杂，但值得讲清楚——因为这决定了它什么时候好用、什么时候没用。

Token Saver 用了"混合检索"（hybrid RAG）：

1关键词匹配（BM25）：老派但快，找"终止条款""营收"这种精确词

2语义匹配（本地 embedding）：懂同义词，"operating earnings"和"营业利润"能匹配上

30.4 / 0.6 混合打分：关键词占 4 成，语义占 6 成

4弃权门控：得分太低就不答，宁可说"我不知道"也不瞎编

5Top-K 切片：只把最相关的几段（约 2,500 tokens）送给 Claude

整个过程跑在你本地。PDF 原文不整体上传——索引和检索都在本地完成，只有检索出的相关段落会通过 MCP 发送给 Claude 的云端模型。Embedding 模型第一次用会下载一次（2-5 分钟），之后就离线运行。

🗣️ 说人话：它先把 PDF 切成小块，给每块建索引。你问问题时，它先查索引找到最相关的几块，只把这几块给 Claude。模型看到的少了，账单就少了。

安装：5 步，真的不用 Python

我们最讨厌"安装只需 3 步"结果要装 7 个依赖的工具。Token Saver 这点比较诚实——真的不用 Python、不用终端、不用改配置文件。

1去 GitHub Releases^[1] 下载 token-saver-ccr.mcpb（一个文件）

2打开 Claude Desktop → Settings → Extensions → Install extension → 选那个文件

3会看到一个红色警告："not verified by Anthropic"。这是正常的，任何从文件安装的扩展都会有，点继续

4打开 Enabled 开关

5点 Configure，选一个小而专用的 PDF 文件夹。别选整个 Documents，选一个专门放你要问的 PDF 的文件夹

首次提问时 Claude 会问你"要不要用这个工具"，选 Always allow。首次运行会下载 RAG 引擎（2-5 分钟），之后就很快。

两个使用习惯（README 里强调的）：

1说"my"、"my lease agreement"、"my report"——让 Claude 知道你在说你的文件

2要求 cite the pages——真实引用只能来自你的文档，是触发器也是证明

仓库公开数据：92-99% 是真的，但有条件

我们看官方 eval 数据（2026-07-25 测量，30 个作者编写的问题，两份真实 PDF：213 页的 Dobbs v. Jackson 判决书 + 152 页的伯克希尔 2023 年报。注：样本量较小，不足以推断真实世界准确率）：

指标	数值	说明
Recall@5	0.90	30 个问题中 27 个，答案页在 top-5 检索结果里
False-abstain	0.00	没有把该回答的问题错误拒绝
纯关键词回退	0.90	不跑 embedding 模型也能达到 0.90

Token 节省官方数据（按文档规模，tiktoken 测的）：

文档规模	一次性粘贴 vs Token Saver	每轮重复粘贴 vs Token Saver
~20 页	省 14%	省 83%
~80 页	省 78%	省 96%
~300 页	省 94%	省 99%

看到关键了吗？

92-99% 对应的是 80-300 页的大文档 + 每轮重复粘贴的场景。

20 页的小文档，一次性粘贴只省 14%。15 页以下，切片可能比整份文件更贵——这时候别用。

🗣️ 说人话：大文档、反复问问题 → 省 90%+ 是真的。小文档、问一次就走 → 不值得折腾。

月度账单能省多少？

我们算一笔账——先声明，这是理论上限，不是真实用户收益。

假设你是重度用户：每天处理 10 份 100 页 PDF，每份问 3 个问题。并且假设你禁用一切缓存、每轮都全量重复粘贴整份 PDF（最差情况）。

1原生方式：每轮重复粘贴整份 PDF，每月 72M tokens，按 Sonnet 5 定价约 $216

2Token Saver：省 96%，每月 2.88M tokens，约 $8.64

3理论月度节省上限：~$207

这是最差情况下的上限。 实际上 Claude Desktop 有 file context 缓存，你大概率不会每轮都重新粘贴整份 PDF。实际节省通常低于这个数。

更现实的估算：如果你每月在 Claude 上处理 PDF 花 $50+，Token Saver 大概率能砍到 $5-10 的量级——具体取决于你的文档规模分布和使用频率。

🗣️ 说人话：账单越贵的人省得越多。每月花 $10 以下的用户，这工具对你意义不大。

它不适合什么场景

诚实讲几个限制（作者自己也披露了，这点值得赞赏）：

1小文档不值得用：15 页以下的 PDF，切片可能比整份文件更贵

2文件选择是弱项：16 份 PDF 的文件夹里，14 次请求只正确选对 12 次（注：测试样本量极小，不足以推断真实世界准确率）。如果你把一堆名字相似的文件放一起，它会选错

3通用名词会选错：两本 1000 页教科书放一起，"what does the textbook say about Pavlov" 会选错；改成"my psychology textbook"可修复

410% 的问题可能答错：recall@5 = 0.90 意味着在检索层面，10% 的问题其相关上下文可能未被送入模型，从而增加答错风险（注：测试样本量极小，30 道自编问题不足以推断真实世界准确率）。你必须检查引用页码，发现不对时重新提问

5页码引用不给章节出处：在有"多数意见 + 异议"的法律裁决书中，模型必须推断段落来自哪一方，可能出错

适用场景：

✅ 推荐使用： 1. 法律合同（50+ 页）、财报（100+ 页）、教科书、长文档查询 2. 对隐私敏感的人（PDF 不上传） 3. 账单焦虑的 Claude 订阅者

❌ 不推荐使用： 1. 会议纪要（5-10 页）、研究论文（10-30 页，边界）、需要全文通读的创意写作 2. 需要图表解读的 PDF、多文档交叉引用

为什么本地 RAG 可能是一个重要方向

最后聊一个更大的趋势。

Token Saver 不是第一个做本地 RAG 的工具，但在目前公开可查的 Claude Desktop 扩展中，它是较早提供图形化一键安装方案（.mcpb 单文件）的本地 RAG 工具之一。

这背后的逻辑是：

1Token 经济学：context 每轮都要重新计费，PDF 越大越亏。本地检索把"大 context"变成"小切片"，成本结构变了

2数据主权：企业不能把合同传到云端（合规），个人不想把病历上传（隐私）。虽然检索出的片段仍需发送给云端模型，但索引和检索本身在本地完成，显著减少了敏感数据离域的范围

3MCP 生态：Model Context Protocol 正在让本地工具变简单。对终端用户而言，以前需要自行编写或配置代码才能跑本地 RAG，现在只需安装一个打包好的 .mcpb 文件

我们上个月写过 Marker 2（PDF → Markdown 转换），那是在"格式转换"这一层做文章。Token Saver 是在"检索 + 计费"这一层做文章。两层加起来，PDF + AI 的工作流才算完整。

🗣️ 说人话：以前 AI 是"你把文件传上来，我帮你处理"。现在趋势是"索引和检索在你电脑上，只有必要的片段传给云端"。这是从"全量上传"到"本地驻在 + 最小传输"的转变。

数据来源：MarkTechPost 原文，https://github.com/Marktechpost/Token-Saver

关注「AI 效能派」，我们专注把 AI 工具讲成你能用的东西，不讲黑话、不画大饼。