用好 NotebookLM 立省 80% token
用好 NotebookLM 立省 80% token
上個月我把 Claude 從 Pro 升到 Max，$200 一個月，心想這下總該用夠用了吧。
第五天：本週額度已耗盡。
翻使用日誌我才看清楚錢花在哪。一次調研 47 篇論文的下午會話，單次就吃掉一週 10% 的額度。這種會話一週跑兩三次，額度自然撐不住。
·問題在我一直讓 Claude 幹它不擅長的事——當全文檢索引擎。
一坨 50k 字元的日誌塞進對話，問一個問題，日誌全文就要被算一次 input token；再問個，就算命中了 prompt cache（單價只剩 1/10），主會話也會隨輪次緩慢累加。更糟的是 cache 有 1h TTL，間隔久了就得重寫一次全價。這就好比每次問律師問題，都讓他把你 50 頁的合約先朗讀一遍再開口。
Claude Code 擅長推理、編排、寫程式碼。讀原始語料這件事該讓別的工具幹，Claude 只看結論。順著這個思路找下去，我想到了 NotebookLM。
跟著這篇配置一遍，你 $20 的帳號能幹出 $200 的活。
導讀
長文，按興趣挑著看：
一：NotebookLM 是什麼 + 能幹什麼
二：為什麼要再套一層 Claude
三：裝 skill，10 分鐘動手
四：實測 token 帳 + 原理拆解
五：學者 / 學生工作流
六：打新股 / 讀招股書 工作流
七：個人知識庫工作流
總結
想先看工作流，直接跳到第五部分——找到你那一類看就行。
一句話論點
真正省 Claude token 的辦法不是開 cache，是讓重資料一開始就不進 Claude。
具體做法：讓 NotebookLM 儲存語料和檢索，Claude 只做推理和編排。兩者分工清晰，用一個比喻概括——
NotebookLM 是老師：你親自採集進去的論文、財報、筆記形成它的知識庫。你問它，它答經驗，答案帶引用，邊界在源內，不亂外推。Claude 是助手：負責寫程式碼、跑腳本、整理結果、編排工具。不懂就去問老師，拿到答案繼續幹活。你是課題負責人：只在關鍵決策點介入。
關鍵原理，為什麼這樣分工省錢
一、RAG vs 塞 context 是兩種不同的成本模型。
把 50k 字元日誌塞進 Claude 對話，這坨資料就被算進 input token。每問一次就要被「看」一次，成本隨語料大小線性漲。走 RAG 則是 NotebookLM 內部用向量檢索命中相關片段，Claude 只看到幾百字的蒸餾答案，成本近乎常數。
二、prompt cache 有 1h TTL，研究場景命中率很低。
很多人以為開了 cache 就萬事大吉。實際 Anthropic 的 prompt cache 預設只存 1 小時，超時就自動失效；你思考幾分鐘、切去做別的、或者開新 session，下一次呼叫就得按全價把語料重寫一次 cache_creation。研究性會話恰好是「問一下、想一會、再問一下」的節奏，命中率常常慘不忍睹。這是帳單暴漲的真正原因。
三、基於事實輸出會更有效
NotebookLM 的答案被約束在你上傳的源裡，每句話帶 [1][2] 引用，點回原文。不會胡編。Claude 拿這種答案做決策，不用反覆讓它「再確認一下」，省下的是更難量化的那部分時間成本。
誰不用看下面了
語料 < 5k tokens、只查一兩次——直接問 Claude，別折騰
需求是純 Q&A、不嵌工作流——打開 notebooklm 網頁用就夠了
在乎響應速度超過帳單——慢 3 倍受不了
要理解程式碼結構 / 跳定義——NotebookLM 更加適合文字 RAG
誰繼續往下讀
想要具體的安裝步驟和避坑
想看幾個場景怎麼落地到指令層
在用 Claude Code 想把 NotebookLM 變成一個 skill
第一部分：先認識 NotebookLM
第一次打開 NotebookLM 是因為一位朋友安利。她寫論文的 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 已經是一個非常強的獨立工具。如果你的需求就是「坐下來問幾個問題」，這篇文章到這裡就夠了，下面的都不用看。
但我用著用著發現它卡在 2 個地方：
一、心流被切 tab 切爛
調研一個課題：問一個問題 → 得到答案 → 點引用跳原文 → 讀完一段 → 回 notebook 複製答案 → 切到 Claude Code 消費 → 做完實驗 → 發現少一篇資料 → 切到 Google 搜尋 → 切到下載 → 切回 notebook 加源 → 繼續問……一下午切 200 次 tab。
二、跟本地工具是兩個世界
我排查線上事故時把日誌灌進 notebook 後能查。但我還要同時在終端 grep 本地配置、看 k8s events、起 pod 復現——網頁不能幫我跑任何本地命令，每次都是「在網頁看完 → 手動敲一遍 → 再切回網頁」。
NotebookLM 網頁把自己定位成終點——你問它，它答你，結束。但我想讓它成為流水線上的一環——被排程、被批次處理、輸出能流到下一步。
這是 Claude 登場的地方。
第二部分：再把 Claude 套上去
把 NotebookLM 變成 Claude 的一個工具。一件事就夠了——Claude 需要領域知識時，自己去問老師。
流程的形狀
老師（NotebookLM）是唯讀的諮詢台：你一次性把 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 拿到的要點，每條保留 [引用]）
## 我做了什麼
（你寫的程式碼 / 跑的命令 / 觀察到的結果）
## 結論
（對我原始課題的回答）
## 老師沒覆蓋的
（老師答不上或引用弱的點，留給我人工跟進）
# 開始
我的第一個課題是：<在這裡寫你的問題>
幾條線索
47 篇論文原文一次都沒進 Claude 對話——主會話 token 只花在推理和程式碼
老師只被諮詢、不參與執行——它的長處是帶引用的領域檢索
你只在 ① 介入——中間要不要再問一次老師，Claude 自己判斷
老師知識庫靜止不變——47 篇論文就是 47 篇，夠用了
這是「串起來」比「單獨用」強的根本原因：省掉的 tab 切換、省下的 token，都是附贈福利。下面講福利有多大。
第三部分：安裝 NotebookLM Client & skill，讓 Claude 認識這個老師
Google 官方沒有提供 NotebookLM client，不過 @icebear0828 已經寫了第三方 client 可以連接 NotebookLM，安裝後，Agent 可以透過命令列或者自然語言存取 NotebookLM。
https://github.com/icebear0828/notebooklm-client 。
基礎安裝：
# 裝客戶端
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
裝完之後在對話裡說「查一下那個 notebook 裡 X 的部分」，Claude 會自動調——不用每次解釋語法。
第四部分：實測——到底省多少錢（Opus 4.7）
下面這組數不是模擬的，是真實一輪研究會話，從 Claude Code 的 session log 裡扒出來的。
NotebookLM 側那部分 token 上傳、檢索、生成——Google 全部免費，不進你的帳單。下面所有數字只算 Opus 這邊。
測試設定
語料：47 篇圖像 + LiDAR SLAM 相關論文，一次性灌進同一個 NotebookLM 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
cache_creation 是每次「往快取寫新內容」的 token，貴檔裡最容易爆的一檔。這次 5 輪裡寫進快取的只有每輪老師答案（~3-6k token）+ 少量系統增量——合計 1.7 萬。
47 篇論文的原文一個字都沒進 Claude 的 cache_creation——這就是省錢的全部秘密。
對比：如果把 47 篇論文直接塞 prompt
47 篇論文實測 38.4 萬 words ≈ 50 萬 token（從 NotebookLM 官方統計字數算出來）。塞 prompt 的傳統做法分兩種場景：
最公平的對比是和「單 session 多輪對話」第二行，——同一研究會話裡首輪建 cache、後續複用，是傳統做法的最優情況。即使這樣，5 輪問答貴檔差出 17 倍（$9.59 vs $0.55）。跨 session 場景只會更慘（86 倍）。
為什麼 cache 幫不了傳統做法？很多人以為「開了 cache 就萬事大吉」。實際 Anthropic 的 prompt cache 預設只有付費檔 1 小時），超時就自動失效；加上每次 claude -p 新起 session、思考停頓、切換別的視窗，都會把上一輪 cache 擠出視窗。
本文做法裡論文壓根不進 Claude，cache 命不命中都無所謂。
語料再翻倍（100 篇、200 篇）差距繼續線性拉開——傳統做法 cache_creation 隨論文數線性漲，本文做法基本不變（只隨老師答案長度微漲）。
用 Opus 跑研究的人：200 次研究會話一年就是小兩千刀的差距——光「論文不進 Claude」這一個動作，一年省下的夠再升一次 Max。
代價：慢 3 倍
操作 實測中位耗時 建 notebook + 加一個源 10-15 秒 NotebookLM chat 一次 16-48 秒（中位約 45 秒） Claude Opus 單問（不過 NotebookLM） 20-35 秒
如果你在乎每秒響應不是每月帳單，這套不適合你。
接下來的幾個部分，作為拋磚引玉，寫了三個適合 NotbookLM 的工作流
五：學者 / 學生工作流
六：打新股 / 讀招股書 工作流
七：個人知識庫工作流
第五部分：研究者 / 學生工作流
reading list 是天然的知識邊界。
痛點：一學期幾十篇論文，同一批 PDF 要反覆查幾十次。以前 Ctrl-F 翻到眼花，問 ChatGPT 又怕它瞎編不帶引用。
語料配方（灌一次用一學期）：
20-50 篇課題相關論文 PDF
課程大綱、講座字幕
導師郵件、自己的章節草稿、讀書筆記
老師能回答的殺手問題：
「哪兩篇結論互相衝突，衝突在哪一層假設？」
「X 方法在這個語料裡出現過幾次，各自怎麼用的？」
「A 論文的公式 3 和 B 論文的公式 7 實際等價嗎？」
Claude 在鏈路裡幹嘛：按課題推進——問老師拿概念/公式 → 寫程式碼復現 → 跑實驗 → 整理筆記。論文原文一次都不進 Claude 會話。
第六部分：打新股 / 讀招股書工作流
一本招股書 300-600 頁，打新視窗就三天。靠人讀完再決策根本來不及。
痛點：港股/A 股打新節奏快，新股上市前只有聆訊後資料集（港股）或招股意向書（A 股）能看，文件動輒 500 頁+，裡面有公司介紹、歷史沿革、業務模式、財務資料、募資用途、風險因素、基石投資者等 20+ 章節。靠人讀：
一家看完至少 4 小時
一週 5-8 家新股，根本來不及
決策視窗就 72 小時，錯過就只能下期再打
而且招股書最有資訊量的不是「公司怎麼誇自己」，是藏在風險因素、關聯交易、歷次融資估值裡的那些紅旗。這部分人眼最容易漏。
語料配方（一家公司一個 notebook）：
招股書全本（聆訊後資料集 / 招股意向書）——必灌，最核心
基石投資者披露表——看誰背書、鎖定期多久
同行可比公司最新財報——估值對標的錨
保薦人/承銷商研報（能搞到的話）——官方定價邏輯
管理層過往訪談、公司過去融資輪估值表——看估值跳漲節奏
行業監管政策文件（如醫藥的 NMPA、科技的相關新規）——決定行業天花板的外部變數
老師能回答的殺手問題：
判斷要不要打，通常就問這 8 個——每個都是 200 頁招股書裡找半天的那種：
「核心產品/業務是什麼？近 3 年收入結構變化如何？客戶集中度？」
「這家和同行（A、B、C）在毛利率、營收增速、研發佔比上的差異在哪？」
「基石投資者是誰、認購金額、鎖定期？基石裡有沒有知名產業資本？」
「此次募資用途按比例拆，哪部分最大？募資完成後控股股東持股稀釋到多少？」
「風險因素裡，哪些是行業共性（可以對照同行打折看），哪些是公司特有（必須警惕）？」
「過往融資估值：上一輪估值 / IPO 估值的跳漲倍數？上輪投資人鎖定期多久？」
「歷史財務有沒有一次性收益把利潤做高的痕跡？過去 3 年經營現金流和淨利潤是否匹配？」
「關聯交易佔營收比多少？前五大客戶裡有沒有關聯方？」
每個問題都帶 [頁碼] 引用——老師會直接把招股書裡對應的那段甩給你，不用再翻 PDF。
Claude 在鏈路裡幹嘛：
批次處理就是這個工作流的靈魂:
一週打新池 = [新股A, 新股B, 新股C, ...]
最後 Claude 把 8 家的一頁彙總成一張 markdown 決策表 → 你 15 分鐘掃完下單。
一週打新池 5-8 家 = 40-64 次查詢，全程論文（這裡是招股書）不進 Claude 對話——單本招股書 150-250k token，5 家就是 100 萬 token 的語料量，傳統做法光這一項一週就能燒掉 $50+。走本文做法 $2 以內。
真實打新場景的增量價值：
壓縮決策時長：4 小時/家 → 20 分鐘/家
紅旗不會漏：8 個問題裡第 5、7、8 項（風險、財務調整、關聯交易）是散戶最常忽略的，老師會逐條摳
跨家對比：港股同一週常有 3 家同行業公司同時招股，用同一套模板跑完直接能排序
第七部分：個人知識庫工作流
給自己建「第二大腦」。
痛點：Obsidian 搜尋只認關鍵字，答不出「我對 X 的看法這三年變過沒」。所有筆記都是自己寫的，合規上沒顧慮，但體量散、格式雜，本地沒工具能跨檔案做語義檢索。
語料配方（一股腦全灌，之後增量補）：
Obsidian / Notion 全量匯出
Kindle 高亮、Readwise 剪藏
工作日記、會議紀要、復盤文件
老師能回答的殺手問題：
「我這三年對『專注力』寫過什麼？觀點變了嗎？」
「《原則》和《思考快與慢》對認知偏差的說法，哪裡重疊哪裡衝突？」
「過去一個月所有會議紀要裡，X 專案各人的態度分別是什麼？」
Claude 在鏈路裡幹嘛：主題演進類問題本來就需要對話式 AI + 全量語料。Claude 負責把老師的多輪答案合成結構化總結（時間軸、觀點對比表、待跟進清單）。
三個工作流的共同點：反覆查、跨文件、私有邊界——佔任何一條，建庫 15 秒成本一週內攤平。
最後
有一些值得注意的：
storage_state.json 裡面是你 Google 的活 session。注意保管。
notebooklm-client 是逆向 NotebookLM 內部協議做出來的。Google 不認帳，隨時可能改後端讓你的命令突然報錯。
這套東西的核心就一句話——分工：
NotebookLM 當老師：答領域知識，帶引用，不亂外推
Claude 當助手：編排工具、寫程式碼、整理結果，不懂就問老師
你當課題負責人：只在關鍵決策點介入
我用了一個月，省下來的錢夠再吃好幾頓大餐。但更重要的是，調研十幾篇論文不再讓我心疼額度了——這種「不用算帳」的爽，比省錢本身還上癮。
大家如果覺得喜歡這篇貼文，給我點個關注 @MinLiBuilds
最後推薦我的 cache 系列第一篇，深入淺出講清楚快取機制，讀完也是立省 token：