Open-Notebook 讓 NotebookLM 變開源

Open-Notebook 把 NotebookLM 的玩法拆成可自架、可調參、可改碼的開源版本。

我用 NotebookLM 風格的工具一陣子了，越用越有火氣。Demo 都很漂亮，真的丟進工作裡就開始露餡：來源類型卡卡、模型不能選、檢索怎麼跑也看不到、輸出格式還要看廠商臉色。你想把它接進自己的知識庫、內網文件、研究流程，結果它像一個包得很漂亮的抽屜，能開，但你不能碰裡面的結構。

我會注意到 AIToolly 這篇整理，是因為它提到 open-notebook 這個 GitHub 專案，作者是 lfnovo。它不是單純說「又一個 clone 出來了」，而是在講一件更實際的事：NotebookLM 這種工具，終於有機會變成你能自己拆、自己改、自己養的東西。

NotebookLM 好用，但它不能讓你碰底層

“The open-notebook project seeks to break these barriers by offering an open-source implementation.”

翻譯一下就是：它想把 NotebookLM 的體驗做出來，但不要把控制權關在黑盒裡。這句話聽起來很平，但我覺得它戳到痛點了。因為這類工具真正麻煩的地方，從來不是介面漂不漂亮，而是底層到底怎麼運作。文件怎麼切塊、先撈哪段、回答怎麼組 prompt、引用怎麼來，這些才是你最後會卡住的地方。

我以前最常遇到的狀況是，工具在小測試裡都像神，真的拿來處理亂七八糟的文件就開始裝死。掃描 PDF、會議記錄、內部 wiki、產品規格書混在一起，答案不是漏掉重點，就是引用錯段。閉源工具的問題不是它不能用，是你一旦想修，基本上只能祈禱。開源至少讓我有機會看懂它怎麼死的。

實操上，我現在看這類產品不先看宣傳頁，我先看三件事：

• 我能不能追到答案來源
• 我能不能換模型或調檢索
• 我能不能把它放進自己的部署環境

如果這三個答案都很模糊，我就直接把它歸類成玩具，不管畫面多順。

靈活性不是加分項，是能不能上線的分界線

AIToolly 那篇文章把 flexibility 當成核心賣點，我覺得這才是對的說法。這種工具講靈活，不是文青式的好聽而已，而是你到底能不能把它塞進真實工作流。模型能不能換、檢索參數能不能調、資料來源能不能擴、輸出能不能接到別的系統，這些才決定它是產品，還是展示品。

我自己做內部研究助理時最有感。團隊常常不是只有一種資料：產品文件、incident note、會議逐字稿、供應商 PDF、法務備忘錄，全都想丟進去。閉源 notebook 類工具通常一開始還行，因為大家都在玩同一種資料格式；一旦進到真實場景，它就會開始替你做假設，而那些假設通常很不適合企業內部工作。

開源不會自動把問題解掉，但它至少讓我有辦法改。這差很多。因為真正有價值的不是「它現在支援什麼」，而是「它能不能長出我需要的東西」。如果架構夠乾淨，社群可以補功能；如果架構爛掉，連你自己都不想碰。

我會建議你先列一份必要控制項，不要等到導入後才發現少東少西：

• 模型選擇
• chunk size 和 retrieval depth
• 文件來源格式
• 匯出格式
• 自架或本地部署

少一個，我都會先打問號。

開源不是信仰，是你能不能審計資料流

“This move is significant because it allows for a level of transparency that is currently missing in the market.”

這句話我接受。因為透明不是空話，它直接關係到你敢不敢把資料丟進去。AI notebook 類工具最敏感的不是「答得準不準」，而是它到底把你的文件送去哪裡、存了什麼、留了多久、是不是偷偷走第三方 API。這些東西在閉源產品裡常常只能靠猜，猜到最後你也不會安心。

我看這類工具時，腦中其實不是產品經理，而是資安、法遵，還有我自己未來會不會被追殺。因為一旦工具碰到內部計畫、客戶資料、法務文件，你就不能只問「好不好用」，你要問「我能不能解釋它怎麼運作」。開源至少讓你有機會把資料流畫出來，知道哪裡會出界。

但我也不會天真到以為 open source 就等於安全。爛 code 也可以是開源的。差別在於，開源讓我有機會審、改、補，甚至叫同事一起看。這在處理敏感內容時很重要，因為信任不是靠感覺，是靠可驗證。

實操上，我會先問這三個問題：

• 文件實際存在哪裡
• prompt 和 embedding 是在哪裡處理
• 哪些部分能自架，哪些一定要外呼

這三題答不出來，就先不要談導入。

「更多功能」其實是在說，這東西還活著

文章裡提到開發者想加 “more functions”，這種說法很早期、很模糊，我反而不討厭。因為它代表這個專案還在被真實使用形狀拉著走，不是已經被產品簡報定死。早期開源專案本來就應該這樣，先活下來，再慢慢長出邊角。

在 NotebookLM 類工具裡，我會期待的功能通常很務實：更好的 PDF parsing、筆記整理、來源比較、多模態輸入、citation 管理、工作流整合。這些都不是 demo 會先秀的東西，因為 demo 只會給你乾淨文件和標準問題。真實世界沒那麼乖，文件常常髒到你懷疑人生。

我看過太多 AI 工具卡在第一版就不動了，因為它們只做了最窄的 use case，然後就開始自我感覺良好。開源專案至少有機會讓不同使用者補不同缺口，今天有人補 parsing，明天有人補 export，久了才有可能變成真正能用的系統。

我的實操判斷很簡單：不要問它現在是不是全能，先問它的架構能不能長出新功能而不炸掉。看三件事就夠了：

• 模組切得清不清楚
• 文件寫得像不像人寫的
• repo 是不是一坨單檔大雜燴

如果答案很糟，我寧願不要。

開發者在意的不是好看，是能不能接進系統

對一般使用者來說，NotebookLM 類工具是方便；對我這種會真的拿去接系統的人來說，它是 fit 不 fit。我要的是能不能自動 ingest 文件、能不能接現有權限系統、能不能把輸出送進知識庫、能不能跟背景任務和 automation 合作，而不是一個只能單獨活著的資訊小島。

這也是我覺得 open-notebook 值得看的原因。它不是只在跟某個產品打對台，它其實是在挑戰一個很常見的預設：研究助理一定要是集中式、封閉式、一次只能照廠商規則玩。不是，至少對開發者不是。只要架構夠乾淨，這種工具完全可以是 composable 的，可以自架，可以嵌進你現有 stack，甚至可以很無聊但很穩。

而且這也符合我現在看到的趨勢：越來越多團隊開始在意 local AI 和 data sovereignty。當大家開始在意資料到底去哪裡，黑盒工具就沒以前那麼好混。open-notebook 會被注意到，不是因為它名字像 NotebookLM，而是因為它站在這個轉向上。

如果你要真的拿來做，我會先看整合點：

• 能不能從既有儲存系統抓文件
• 登入權限能不能對接組織規則
• 能不能匯出成 markdown、JSON 或知識庫格式
• 能不能掛背景工作和自動化

這些沒有，就先別急著把它當正式工具。

能不能撐住髒資料，才是最後答案

每個 AI notebook 在乾淨 PDF 上都看起來很會。真正的工作是另一回事：文件半成品、會議記錄互相打架、掃描檔糊成一團、來源彼此矛盾。這時候我才會知道，工具到底是靈活，還是只是把「靈活」印在首頁而已。

open-notebook 有意思的地方在於，它把這個問題交回社群和使用者手上。這就是開源在這個類別裡真正值錢的地方，不是便宜而已，而是可以因為問題變了就跟著改。問題一定會變，這幾乎是鐵律。

如果是我現在要導入，我不會一次全上。我會先做小範圍試點：一套 corpus、一個用例、一個團隊。先看檢索品質、來源可追溯性、維護成本，再決定要不要擴大。這比聽一百句「很適合知識工作」有用多了。

實操上，我會用這份檢查表，而不是用熱情：

• 它有沒有從正確來源回答
• 失敗時我能不能說清楚原因
• 我能不能不重寫就改行為
• 我敢不敢把敏感筆記交給它

如果這四題有兩題卡住，那就先停。

可抄的模板

# Open-Notebook 導入檢查清單（給開發團隊用）

## 目標
打造一個可自架、可審計、可調整的 NotebookLM 風格工作區。

## 不可妥協項
- 原始碼必須可讀、可審計
- 文件 ingest 必須可設定
- 模型選擇必須可切換
- retrieval 參數必須可見、可調
- 必須能自架或本地執行

## 評估問題
1. 文件上傳後實際存到哪裡？
2. 哪個模型負責檢索與生成？
3. 能不能調 chunking、ranking、citation 行為？
4. 目前支援哪些檔案格式？
5. 哪些部分能擴充而不用整個 fork？
6. 能不能把筆記和回答匯出成可用格式？
7. repo 有沒有清楚的模組、測試、貢獻文件？

## 試點計畫
- 先選一組文件：產品文件、研究筆記或內部 wiki
- 載入 20 到 50 份代表性文件
- 問 10 個團隊真的會問的問題
- 記錄：
  - 回答品質
  - 引用品質
  - 檢索漏答
  - 延遲
  - 安裝與設定痛點
- 決定要保留、修改，還是直接放棄

## 先改的地方
- Model provider
- Embedding model
- Chunk size
- Retrieval depth
- Source ranking logic
- Export format
- Authentication and access control

## 待辦清單
- 更好的 PDF parsing
- 更好的掃描檔處理
- 多來源比較
- Markdown export
- Background ingestion jobs
- Team workspaces
- Audit logging

## 我的規則
如果我說不出這工具怎麼運作，我就不會把重要筆記交給它。

## 可直接貼上的評估 prompt
你現在要幫我評估一個開源 AI notebook 工具，對象是開發團隊。我要的是實用檢查表，不是行銷文。請聚焦在：透明度、自架、模型選擇、retrieval 調參、匯出能力、維護性。先問我文件類型、團隊人數、隱私限制、整合目標，再產出試點計畫和客製化待辦清單。

這段我故意寫得很無聊，因為無聊才是對的。這種工具放在文件和決策中間，最怕的就是漂亮但不穩。

原始來源是 AIToolly 的這篇整理：https://aitoolly.com/ai-news/article/2026-06-09-open-notebook-a-flexible-open-source-implementation-of-notebooklm-emerges-on-github。專案本體是 open-notebook，作者是 lfnovo；上面這篇拆解有一部分是我自己的工作流判斷，一部分是根據原文整理出來的可抄版本。