如何打造一套結合 Opus 5 與 Obsidian 的研究系統，每週省下數小時的手動閱讀時間

大多數研究工作並非真正的思考，而是閱讀、擷取與交叉比對，以手動方式逐一來源進行，耗費了本應用於真正思考的時間。

Opus 5 正是因為其設計目的而改變了這個局面。Anthropic 以與 Opus 4.8 相同的價格推出它，每百萬 token 輸入 5 美元、輸出 25 美元，但在 Frontier-Bench v0.1 上的分數比 Opus 4.8 提升了一倍以上。它明確並非定位為 Anthropic 最聰明的模型——那仍然是 Fable 5——而是定位為專為日常使用打造的模型，其效率在數千次呼叫中積累，這是單一基準測試標題永遠無法捕捉的。法律 AI 公司 Harvey 獨立報告指出，在匹配 Opus 4.8 最大推理輸出品質的同時，平均 token 使用量減少了 26%。

這種效率特性正是研究管線所需。你並非執行一次深度、昂貴的查詢，而是每週在不斷增長的來源庫中執行數十次擷取與綜合處理，而且如果沒有使用專為大量處理設計的模型，每次處理的成本會迅速累積。

這是一個完整的系統：Obsidian 作為永久儲存庫，Opus 5 作為處理引擎，以及一條特定的管線，自動將原始閱讀材料轉化為可連結、可查詢的知識，讓你過去手動擷取與交叉比對所花費的時間重新回到你手中。

為什麼 Opus 5 特別適合這項工作

在開始建構之前，值得先釐清為什麼這個系統使用 Opus 5 而非 Fable 5，因為為這項特定工作選錯模型是人們在這種系統上超支最常見的原因。

一個每週攝入來源的研究管線會執行大量個別模型呼叫：對每個新來源進行擷取、與現有筆記進行交叉比對、定期綜合處理、摘要生成。這是大量處理工作，而非單次深度工作。Opus 5 的整個定位正是圍繞這種特性建立：在相同價格下，Frontier-Bench 分數是 Opus 4.8 的兩倍以上，並且 Harvey 獨立驗證了其在重複、相似任務上的 token 效率提升。

Fable 5 仍然是處理真正最困難的單一研究問題的更好選擇——那些細微、高風險的綜合分析，弄錯一個細微點會產生實際後果，而且其更高的 SWE-Bench 相關推理深度值得付出大約兩倍的 token 價格。對於建構和維護研究系統的常規重複工作——每週攝入、持續擷取、摘要生成——Opus 5 的效率優先設計是正確的預設選擇，而 Fable 5 則保留給系統偶爾提出的值得深入探究的深度問題。

基礎：Obsidian 作為永久儲存

系統需要一個能永久保存知識、完全屬於你、且永遠不依賴任何單一模型或供應商的地方。Obsidian 庫中的純 Markdown 檔案正好做到這一點。如果明年出現更好的模型，你只需將其指向同一個資料夾，其他一切都不需改變。

針對研究系統的有效結構，基於一般的 raw 與 wiki 模式：

• raw 資料夾：存放原始素材，完全如攝入時的樣子——PDF、文章文字、影片逐字稿、未處理的內容。
• wiki 資料夾：存放處理過、已連結、永久版本的知識，按主題而非來源組織。
• questions 資料夾：專為研究系統設計，存放你閱讀過程中浮現但尚未解決的開放問題，確保在處理過程中不會遺漏任何真正重要的內容。
• digests 資料夾：存放 Opus 5 生成的每週摘要，加上時間戳，讓你可以回顧任何一週的重點，而無需重新閱讀所有內容。
• 根目錄下的單一 CLAUDE.md 檔案：明確定義這個系統應如何運作，下一節將詳細說明。

控制整個系統的 CLAUDE.md

這是整個設定中槓桿率最高的單一檔案，因為 Opus 5 會在每次會話開始時自動讀取它，這意味著你只需要編寫一次指令，而不必每次使用時都重新解釋系統。

1研究系統協議
2
3這個庫是一個研究系統。結構：
4
5/raw - 原始素材，完全如攝入時的樣子，永不編輯
6/wiki - 處理過、已連結的知識，按主題組織
7/questions - 尚未解決的開放問題
8/digests - 每週摘要，加上時間戳
9
10當新來源被放入 /raw 時：
11
121. 擷取具體、真正的新主張與發現，而非整個文件的摘要。
132. 檢查 /wiki 中是否存在相同主題的現有筆記。如果主題已有筆記，則擴展現有筆記，而非建立重複。
143. 使用 [[wikilinks]] 將每個新主張連結到相關的現有筆記。
154. 如果某個主張與 /wiki 中已有的內容矛盾，不要默默地覆蓋它。在兩個筆記中明確標記矛盾。
165. 如果某個來源提出一個你無法從庫中其他材料解決的真正開放問題，將其加入 /questions，而不是猜測答案。
17
18當被要求進行綜合或生成摘要時：
19
20從 /wiki 提取，而不是直接從 /raw 提取。wiki 是經過處理、可信賴的層。原始來源可能包含後來被發現錯誤或被取代的主張，這就是為什麼上述第 4 步存在。
21
22在報告任何擷取完成之前，確認你確實檢查了 /wiki 中是否存在相關的現有筆記，而不是假設這完全是新材料。

這個單一檔案就是讓一個資料夾中的零散筆記與一個實際系統產生區別的關鍵。其中的每一條指令都是為了防止一個特定的、真實的失敗模式——重複筆記、默默覆蓋的矛盾、未解決的問題被悄悄遺漏——這些問題在數月使用中會不知不覺地累積。

攝入管線

有了結構化的庫和編寫好的協議，以下是實際的每週工作流程。

• 在閱讀過程中，將任何來源放入 /raw：你讀到的文章、研究論文、播客逐字稿、影片逐字稿、競爭對手的部落格文章。這應該只需要幾秒鐘，而不是幾分鐘——整個重點是消除捕捉的障礙，讓你確實持續執行。
• 處理 /raw 中尚未處理的新檔案。對於每個檔案，擷取真正的新主張，檢查 /wiki 中相關的現有筆記，適當地擴展或建立筆記，並標記與已記錄內容的任何矛盾。將未解決的問題加入 /questions，而不是猜測。
• 根據你實際的閱讀模式，以適合的頻率執行此操作：如果你持續閱讀，每天一次；如果你的輸入較為零散，每隔幾天一次。重點是處理應在你捕捉到來源後不久進行，因為一次將十個來源批次分解為個別的擷取和交叉比對處理，正是 Opus 5 效率特性所針對的那種重複、相似形狀的工作。

每週摘要，自動化

這是時間節省最明顯的地方，而且值得將其設定為排程任務，而不是你記得手動執行的事情，因為整個系統的重點是將你從機械性部分中抽離。

1生成本週的研究摘要。從 /wiki 提取，特別專注於過去 7 天內新增或更新的內容，而非整個庫的歷史。
2
3結構：
4
51. 本週最重要的 3 到 5 項新發現，附上 /wiki 中完整筆記的連結。
62. 本週標記的新材料與現有筆記之間的任何矛盾，因為這些值得你直接關注。
73. 本週加入 /questions 但仍未解決的開放問題。
84. 一行說明本週哪個主題活動異常頻繁，因為一個快速累積許多相關筆記的主題通常值得深入、有意識的關注，而非被動累積。
9
10將結果儲存到 /digests，並附上本週日期。整個摘要保持在 500 字以內。這是指向完整筆記的指引，並非取代閱讀它們。

將此設定為每週自動執行，這樣在你親自打開任何筆記之前，一份簡短、結構化的摘要已經在等著你，涵蓋所有重要事項。這是系統取代數小時手動閱讀的直接機制：你不再需要重新閱讀一整週的原始材料來記住學到了什麼，而是閱讀一份 500 字的指引，只需要兩分鐘，而不是等價手動回顧所需的兩小時。

查詢所有內容，而不只是你記得的

另一個主要的時間節省，與摘要分開，是能夠針對你整個累積的知識庫提出真正的問題，而不是試圖記住哪個特定筆記有答案。

1根據 /wiki 中的所有內容，我對 [特定主題] 學到了什麼？引用每個主張來自的具體筆記。如果庫中的來源在這個主題上彼此不一致，請明確說明，而不是選擇一個並將其呈現為共識。

這是系統運行時間越長、回報越大的部分。第一個月，你的 wiki 很薄，這種查詢只會返回少量筆記。第六個月，在處理了數十個來源並進行交叉連結後，相同的查詢會浮現出你永遠無法手動建立的真正連結——第二週閱讀的一篇論文中的想法，直接連結到第二十週完全不同的來源中的某個東西，因為兩者都被歸檔到相同的主題下並進行了相應的連結。

誠實處理矛盾

這個系統相對於單純從記憶中重新閱讀自己的筆記，一個特定且被低估的價值在於，它會主動在你對某事的理解隨時間改變時浮現出來，而不是讓一個過時的信念未經挑戰地存在，僅僅因為你忘記了自己曾經持有它。

當攝入協議標記出矛盾——新來源的某個主張與現有筆記的某個主張衝突時——請抵制讓系統只選擇看似更新或更權威的來源並默默解決它的衝動。浮現矛盾的價值在於，它迫使你做出實際決定：早期的來源是錯的嗎？底層現實真的改變了嗎？還是這是一個根據上下文兩者都正確的情況，需要加入筆記中？自動化這個判斷會破壞建立一個讓你的思維隨時間變得更嚴謹的系統的目的。

一個月的實際範例

為了讓累積效應更具體，以下是這在真實使用一個月中的大致情況。

• 第一週，你放入六篇與你正在研究的一個專案相關的文章。攝入處理在 /wiki 中建立了八個新筆記，因為有些文章觸及多個不同主題，並且在存在真正關係的地方相互連結。摘要很短，因為還沒有太多先前的材料可供交叉比對。
• 第二週，你新增了四個來源。其中兩個擴展了第一週的現有筆記，而不是建立新筆記，因為攝入協議正確識別了主題重疊。一個標記了矛盾：第二週來源中的一個主張直接反駁了第一週來源自信陳述的某事。摘要突出顯示了這個矛盾，而你在審查後發現第一週的來源使用的是過時數據。你直接更新了那條筆記，註明了更正和原因。
• 第三週和第四週繼續這個模式。到月底時，對整個主題的查詢會返回一個追溯你理解實際演變過程的綜合分析，包括更正，而不僅僅是一個靜態快照，好像你從第一天就知道正確答案。

這就是具體陳述的實際價值主張。不是系統替你思考，而是它移除了那些機械性的負擔——擷取、交叉比對、記住你已經知道的東西——這些負擔過去每週都與你的實際思考時間競爭。

破壞這個系統的常見錯誤

有幾個特定的錯誤在人們設定這個系統時反覆出現，值得事先了解。

• 跳過 CLAUDE.md 協議，只是將檔案丟進 raw 並希望 Opus 5 能自行找出正確行為。 如果沒有明確的指令，特別是「檢查後再建立重複」的規則和「標記矛盾，不要默默覆蓋」的規則，系統會退化為它本來要避免的那種無結構的 AI 生成筆記堆。
• 對整個庫而不是特定一週的活動運行摘要。 這會產生一個每週越來越長、越來越沒用的摘要，因為它不斷重新總結你已經閱讀和處理過多次的材料，而不是只浮現真正新的內容。
• 將 Opus 5 的綜合分析視為自動正確，而非起點。 模型在這裡進行了真正的認知工作——在一個不斷增長的知識庫中進行擷取和交叉比對——像任何認知工作一樣，它受益於你自己的審查，特別是對它標記的矛盾，這些正是你自身判斷能增加最大價值的時刻。
• 出於習慣使用 Fable 5 進行常規的每週處理，假設較貴的模型總是更安全的選擇。 對於這個系統每週產生的大量重複、相似形狀的擷取和綜合工作，Opus 5 的效率特性是更合適的選擇，而成本差異在數月持續使用中會顯著累積。將 Fable 5 保留給系統本身提出的罕見、真正困難的綜合問題，這些問題值得額外審查，而不是用於常規的攝入管線。

直接連接庫，而不是複製貼上

以上所有內容在您手動打開 Claude 並貼上檔案內容時都能運作，但這個系統的真正無摩擦版本會將 Opus 5 直接連接到您的 Obsidian 庫，因此攝入和查詢無需任何複製貼上。

實務上，這需要使用 Obsidian 的 Local REST API 外掛程式，在 Obsidian 的社群外掛程式設定中啟用，它會透過一個帶有驗證金鑰的本地 API 端點公開您的庫。然後，Claude Code 或 Claude Desktop 的 MCP 連線可以直接讀取和寫入您庫中的檔案，這意味著本文前面提到的攝入提示將針對您的實際庫執行，建立和編輯真實的筆記，而不是您手動在聊天視窗和筆記之間複製內容。

只需設定一次。在 Obsidian 中，安裝並啟用 Local REST API 外掛程式，複製它產生的 API 金鑰。在 Claude Code 中，使用該金鑰配置一個指向您庫的 MCP 連線。透過要求 Claude 列出您 /raw 資料夾中的檔案來測試，如果它返回準確的清單，則連線已生效。

一旦這個功能正常運作，前面提到的整個攝入和摘要管線就會變成您可以用一條訊息觸發的事情，而不是手動複製貼上的過程，而且這也使得排程真正自動化，因為排程任務可以在您不在場的情況下呼叫相同的 MCP 連線。

擴展到多個研究主題

以上所有內容假設一個庫中只有一個研究主題。大多數認真運行這個系統的人最終會同時追蹤幾個不同的領域：一個特定的專案、一個您大致關注的行業、一個與前兩者無關的長期興趣。將這些混合到一個未經區分的 wiki 中，會產生系統本來要防止的那種雜訊。

解決方案與 Claude Projects 的一般範圍界定規則相同。為每個真正不同的研究主題提供自己的子資料夾結構，或者如果主題很大且彼此無關，以至於交叉污染會積極混淆綜合分析（例如，一個行業的主張被錯誤地與一個不相關的專案交叉引用，僅僅因為兩者都位於同一個未經區分的 /wiki 資料夾中），則使用完全獨立的庫。

1多主題範圍
2
3這個庫涵蓋多個研究領域，每個領域在 /wiki 下有自己的頂層資料夾：/wiki/topic-a、/wiki/topic-b 等。
4
5在攝入新來源時，首先確定它屬於哪個主題。如果它確實跨越兩個主題，請明確記錄跨主題的關聯，而不是在沒有解釋的情況下模糊地將其歸檔到一個資料夾中。
6
7摘要應按主題生成，而不是作為一個合併的摘要，除非明確要求進行跨主題綜合。

這種結構讓每個主題獨立累積——自己的 wiki、自己的一套連貫的交叉引用——同時仍然允許您在兩個領域之間存在真正值得浮現的關聯時，明確要求進行跨主題綜合，而不是讓每條筆記在一個單一的、未經區分的堆中，隱含地與不相關的材料競爭相關性。

實際的規則：何時拆分為完全獨立的庫，何時使用一個庫內的子資料夾？如果您真的不希望對一個主題的查詢意外地浮現來自另一個主題的不相關材料，那麼獨立的庫值得花費切換它們的微小開銷。如果主題之間的一些交叉授粉實際上是有價值的——例如，一個總體行業趨勢為一個特定專案提供資訊——那麼一個庫內的子資料夾可以保留這種連結組織，同時上述明確的主題範圍界定指令可以防止日常攝入中的實際混淆。

衡量這個系統是否真的為您節省時間

一個像這樣的系統可能感覺很有生產力，但如果沒有針對它要取代的東西進行實際衡量，它可能會產生錯覺。值得定期誠實地檢查，而不是僅僅因為系統存在並按時運行就假設時間節省是真實的。

在設定後的兩到三週內，追蹤您過去的週一審查在舊的手動流程下大概需要多長時間：重新閱讀您保存的所有內容、試圖記住什麼與什麼相關、搜尋您知道在某處讀過的特定事實。誠實地將其與現在閱讀生成的摘要並跟進其中標記為需要您注意的事項所需的時間進行比較。

真正重要的比較不是摘要本身節省的原始時間（一份 500 字的摘要顯然比一週的原始來源讀得快）。而是摘要是否真的浮現了重要的事項，意味著您不會在幾天後才單獨發現某個重要事項被埋沒在原始材料中，從未進入筆記或摘要。如果這種情況經常發生，那麼攝入協議的擷取步驟需要加強，而不一定是需要重新加入更多的手動閱讀時間作為變通方法。

另一個值得追蹤的誠實指標是，前面提到的查詢功能是否真的被使用。一個能生成乾淨的每週摘要，但您從未用它來查詢交叉引用答案的系統，只提供了其預期價值的一半——被動摘要的一半——而沒有主動的「我從所有餵給它的來源中到底學到了什麼」的一半，而這正是隨著時間推移展現真正累積價值的地方。如果您發現自己不怎麼查詢它，這通常表示 wiki 尚未累積足夠的交叉連結材料，讓查詢感覺值得——這在前一兩個月是正常的——或者表示您只是養成了不問的習慣，這值得有意識地改正，因為系統實際價值的很大一部分就在這裡。

本週設定這個系統

不要試圖一口氣建立完整的管線。按照讓每個部分在加入下一個部分之前證明自己的順序來建立。

• 第一週：只需建立庫結構和 CLAUDE.md 檔案，然後手動對您正在閱讀的任何內容執行攝入提示。在自動化任何東西之前，先熟悉擷取品質。
• 第二週：加入每週摘要生成，先手動運行而不是按排程，這樣您可以驗證它是否確實從正確的週活動中提取並保持適當簡潔。
• 第三週：一旦兩個部分都可靠運作，將攝入和摘要設定為自動運行，這樣系統就能真正在您不需要記得觸發的情況下運行。
• 到第四或第五週：您應該會注意到這個系統旨在產生的實際轉變。過去週一早上從試圖記住前一週讀過和學過什麼開始，現在變成了從一份兩分鐘的摘要開始，這份摘要已經為您完成了記憶工作，而那些過去用於手動重新閱讀和交叉引用自己研究的時間，現在可以用於研究中最需要人類的部分：決定什麼重要以及為什麼重要。

追蹤 @cyrilXBT 以取得本文中所有內容背後的確切 CLAUDE.md 模板和 Obsidian 庫設定。