NotebookLM 立省 80% Token：让老师答知识、让助手干活

上个月作者把 Claude 从 Pro 升到 Max，$200 一个月，心想这下总该用够用了吧——第五天：本周额度已耗尽。

这课是 @MinLiBuilds 的完整实测：真正省 Claude token 的办法不是开 cache，是让重数据一开始就不进 Claude。具体做法：让 NotebookLM 存储语料和检索，Claude 只做推理和编排。跟着这篇配置一遍，$20 的账号能干出 $200 的活。

分工比喻：NotebookLM 是老师——你采集的论文、财报、笔记形成它的知识库，你问它，它答经验，答案带引用，边界在源内，不乱外推；Claude 是助手——写代码、跑脚本、整理结果、编排工具，不懂就去问老师；你是课题负责人——只在关键决策点介入。

以下来自 @MinLiBuilds 的翻账经历。一次调研 47 篇论文的下午会话，单次就吃掉一周 10% 的额度——这种会话一周跑两三次，额度自然撑不住。

问题在他一直让 Claude 干它不擅长的事——当全文检索引擎。一坨 50k 字符的日志塞进对话，问一个问题，日志全文就要被算一次 input token；再问一次，就算命中了 prompt cache（单价只剩 1/10），主会话也会随轮次缓慢累加。更糟的是 cache 有 1 小时 TTL，间隔久了就得重写一次全价。

以下来自 @MinLiBuilds 的原理拆解，三条：

一、RAG vs 塞 context 是两种不同的成本模型。把 50k 字符日志塞进 Claude 对话，这坨数据就被算进 input token，每问一次就要被"看"一次——成本随语料大小线性涨。走 RAG 则是 NotebookLM 内部用向量检索命中相关片段，Claude 只看到几百字的蒸馏答案——成本近乎常数。

二、prompt cache 有 1 小时 TTL，研究场景命中率很低。很多人以为开了 cache 就万事大吉。实际 Anthropic 的 prompt cache 默认只存 1 小时，超时自动失效；你思考几分钟、切去做别的、开新 session，下一次就得按全价把语料重写一次 cache_creation。研究性会话恰好是"问一下、想一会、再问一下"的节奏，命中率常常惨不忍睹——这是账单暴涨的真正原因。

三、基于事实输出更有效。NotebookLM 的答案被约束在你上传的源里，每句话带 [1][2] 引用，点回原文，不会胡编。Claude 拿这种答案做决策，不用反复让它"再确认一下"——省下的是更难量化的时间成本。

以下来自 @MinLiBuilds 一周的试用经验。朋友写论文的 reading list 有 60 多篇，以前在 PDF 阅读器挨个 Ctrl-F，现在全丢进一个 notebook，问"谁支持 X 观点、谁反对、分歧集中在哪几个变量"——答案带 [1][2][3] 引用直接甩过来，点一下跳回原文对应段落，一周省十几个小时。

NotebookLM 的优点：

• 支持免费档 50 个源 / Pro 档 300 个；
• 处理能力不要钱：上传、索引、生成、对话全走 Google 的算力；
• 除了问答，能把整个 notebook 自动生成音频播客（通勤听最舒服）、思维导图、PPT、闪卡；播客尤其惊艳——你自己的资料被两个陌生 AI 用你没想过的角度讲一遍，常能听出新东西；
• 格式从来不是问题：PDF、网页 URL、YouTube 字幕、Google Docs、纯文本粘贴、图片 OCR、音频转写都能当源。

如果你的需求就是"坐下来问几个问题"，NotebookLM 网页版到这里就够了。但作者发现它卡在两个地方：一，心流被切 tab 切烂——调研一下午切 200 次 tab（问→复制答案→切 Claude→做实验→缺资料→切 Google→下载→加源→继续问……）；二，跟本地工具是两个世界——网页不能跑本地命令，每次"网页看完→手动敲一遍→切回网页"。NotebookLM 网页把自己定位成终点；他要让它成为流水线上的一环——被调度、被批处理、输出流到下一步。这就是 Claude 登场的地方。

以下来自 @MinLiBuilds。把 NotebookLM 变成 Claude 的一个工具，一件事就够：Claude 需要领域知识时，自己去问老师。

老师是只读的咨询台：你一次性把 47 篇论文灌进去就不用再管了，它在那儿等你问。不用回灌、不用喂新笔记——论文本身的观点足够撑起所有查询。

下面这个 prompt 把六步流程、工作纪律、notebook ID 全编码进去了，贴进 Claude Code 就能跑（注意替换 id）：

复制# 角色
  你是我的研究助手。我的课题老师是一个固定的 NotebookLM notebook
  (id: 6634ad4d-0594-4700-bddf-4a400ad46fa2)，里面装着 47 篇相关论文。
  你通过已安装的 notebooklm skill（/notecraft chat 等命令）跟老师对话。

  # 铁律
  1. 任何涉及论文观点、公式、方法、已知坑的问题，先 /notecraft chat 问老师，
     不要凭记忆回答，也不要让我把论文原文贴进对话。
  2. 老师是只读咨询台：不要把笔记、代码、实验结果回灌进 notebook。
     知识库就 47 篇论文，静止不变。
  3. 老师的答案带 [1][2] 引用。把引用原样保留在你给我的输出里。
  4. 中间要不要再问一次老师，你自己判断——不用每一步都确认。
  5. 老师答不上或引用弱的问题，明确说"老师无解"，不要外推硬编。

  # 工作流程
  ① 我给你一个课题 / 子问题。
  ② 识别里面哪些点需要领域知识（论文观点、前人方法、公式推导、已知失败模式）。
  ③ 对这些点逐条 /notecraft chat，拿到带引用的答案。
  ④ 用答案驱动执行：写代码、跑脚本、grep 本地文件、整理结果。
  ⑤ 执行中冒出新疑问就回到 ③ 再问老师，直到没有新疑问。
  ⑥ 最终输出给我：
     - 结论（带老师答案的 [引用]）
     - 你的代码 / 实验结果
     - 老师没覆盖的 open question 单独列一节

  # 输出格式
  每次交付用这个骨架：

  ## 老师说
  （/notecraft chat 拿到的要点，每条保留 [引用]）

  ## 我做了什么
  （你写的代码 / 跑的命令 / 观察到的结果）

  ## 结论
  （对我原始课题的回答）

  ## 老师没覆盖的
  （老师答不上或引用弱的点，留给我人工跟进）

  # 开始
  我的第一个课题是：<在这里写你的问题>

安装 NotebookLM Client & skill（Google 官方没提供 client，用第三方 @icebear0828 的开源实现，10 分钟动手）：

复制# 装客户端
npm i notebooklm-client

# 导出登录 session（会开浏览器登 Google）
npx notebooklm export-session

# 与笔记本对话
# npx notebooklm chat <notebook-id> --transport auto --question "帮我总结一下"

# 安装后在 agent 中使用 /notecraft 即可自动化 NotebookLM 操作
npx notebooklm skill install

仓库：https://github.com/icebear0828/notebooklm-client。装完在对话里说"查一下那个 notebook 里 X 的部分"，Claude 会自动调，不用每次解释语法。

以下来自 @MinLiBuilds。这组数不是模拟的，是真实一轮研究会话，从 Claude Code 的 session log 扒出来的。NotebookLM 侧的 token（上传/检索/生成）Google 全部免费，不进账单，下面只算 Opus 这边。

测试设置：语料 47 篇图像 + LiDAR SLAM 论文，一次性灌进同一个 notebook；模型 Claude Opus 4.7；5 轮深度问答（从"最适合做 SLAM 重建的方法"一路问到"3DGS vs NeRF 接 SLAM 后端的坑"）；Claude Code 里正常对话，每轮助手自己调 /notecraft chat 问老师。

实测结果（本文做法）：真正决定账单的是 token input + cache_creation（往缓存写新内容）+ output。便宜档（cache_read + input）单价不到它们的 1/10，忽略，只算贵档——5 轮贵档合计 $0.55，平均每轮约 $0.11。

关键数字：cache_creation 只有 17,379——5 轮里写进缓存的只有每轮老师答案（约 3–6k token）+ 少量系统增量。47 篇论文的原文一个字都没进 Claude 的 cache_creation——这就是省钱的全部秘密。

对比：47 篇论文直接塞 prompt——47 篇实测 38.4 万 words ≈ 50 万 token。最公平的对比是"单 session 多轮对话"（首轮建 cache、后续复用，传统做法最优情况）：即使这样，5 轮贵档差出 17 倍（$9.59 vs $0.55）；跨 session 场景 86 倍。

为什么 cache 帮不了传统做法？prompt cache 默认只有 1 小时（付费档），超时自动失效；每次 claude -p 新起 session、思考停顿、切换窗口，都会把上一轮 cache 挤出窗口。本文做法里论文压根不进 Claude，cache 命不命中都无所谓。语料翻倍（100 篇、200 篇）差距继续线性拉开：传统做法 cache_creation 随论文数线性涨，本文做法基本不变。

以下来自 @MinLiBuilds。三个工作流的共同点：反复查、跨文档、私有边界——占任何一条，建库 15 秒的成本一周内摊平。

以下来自 @MinLiBuilds。这套东西的核心就一句话——分工：NotebookLM 当老师（答领域知识，带引用，不乱外推）；Claude 当助手（编排工具、写代码、整理结果，不懂就问老师）；你当课题负责人（只在关键决策点介入）。

他用了一个月，省下的钱够吃好几顿大餐。但更重要的是：调研十几篇论文不再让他心疼额度了——这种"不用算账"的爽，比省钱本身还上瘾。