教程｜一本書怎麼變成 AI 可調用的 Skill：Obsidian 深度閲讀流水線拆解

好多人讀書嘅問題，唔係冇讀，而係讀完用唔到。

書摘一大堆，劃線一大堆，讀書筆記一大堆。但係真係遇到一個決策、一個項目、一個寫作題目嗰陣，啲筆記就好似擺喺倉庫嘅零件咁，揾唔到、叫唔出、用唔到。

一個淨係寫唔讀嘅知識庫，唔係知識庫，似垃圾桶多啲。

所以讀書呢件事真正要升級嘅，唔係「點樣摘更多金句」，而係點樣將一本書變成一個可以被 AI 叫嚟用嘅 Skill。

呢套諗法可以叫做「編譯式閲讀」。唔係每次問 AI 嗰陣先叫佢檢索 PDF，而係先將本書嘅框架、模型、術語、反模式抽曬出嚟，變成一 set 結構化嘅 Skill。以後遇到真實問題嗰陣，AI 唔係臨時揭書，而係叫用已經編譯好嘅方法。

第一步，先搭一個可以長期存活嘅知識底座。

工具可以有好多，但 Obsidian 好適合做呢件事。原因好現實。

第一，佢係純 Markdown、本地儲存。10 年後某個工具唔更新，你啲檔案都仲喺度，任何文字編輯器都開到。

第二，佢有雙向連結同圖譜視圖。一本書嘅筆記仲 ok，二十本書之後，你需要見到概念之間點樣互相連接。

第三，佢有插件生態。Claudian、Obsidian Git、Dataview、Templater、Graph Analysis 呢啲工具，可以將 Obsidian 由筆記軟件變成一個知識操作系統。

一個實用嘅 Vault 結構可以咁樣設計：Inbox 放曬所有新諗法；Skills 放編譯好嘅書籍 Skill；Notes 放永久筆記；MOC 放內容地圖；Projects 放進行中嘅項目；Archives 放歸檔；Daily 放每日記錄。

呢套結構嘅重點唔係好睇，而係令輸入、加工、叫用、歸檔各有位置。

第二步，將本書由「文字」編譯成 Skill。

傳統 AI 讀書工具嘅邏輯係：你問問題，AI 檢索原文，然後回答。呢個叫檢索，唔係叫編譯。

編譯嘅邏輯係：本書先經過預處理，抽取出核心框架、命名術語、可執行命令、反模式、速查表，再生成 SKILL.md。以後 Claude 或者其他 AI 需要用呢本書嗰陣，載入嘅係方法結構，唔係成篇原文。

一個合格嘅書籍 Skill 至少應該包含：

作者核心論點，唔超過 100 字；命名框架，每個框架要有定義、使用場景同例子；可執行命令，用「喺咩情況下用咩動作」嘅格式寫；術語表，每條盡量短；反模式，明確講唔好做咩；速查表，列出最重要嘅 5 個決策點。

呢度有個質量判斷：如果生成出嚟全部都係原文抄錄，即係失敗咗。好嘅 Skill 應該係實踐者口吻，唔係讀書摘錄。

例如《The Mom Test》俾人編譯之後，核心唔應該係「呢本書講用家訪問好重要」，而係：

唔好問將來，要問過去；唔好問「你會唔會用」，要問「你上次幾時遇到呢個問題」；有效數據包括已俾錢行為、已承諾行為、具體事實；冇效問題包括「你鍾意呢個功能嗎」「你會為佢俾幾多錢嗎」。

咁就由知識變咗做工具。

第三步，唔係全部書都適合編譯。

最適合編譯嘅書有三個特徵：有命名框架，有可執行方法，有明確術語。例如決策框架、卡片筆記法、深度工作、系統設計、產品訪問呢類書。

有啲書可以編譯，但需要人手補充場景，例如人物訪問、商業傳記、思想隨筆。佢哋有見解，但框架唔夠硬。

有啲書唔適合編譯，譬如純敍事、散文、小說、情感閲讀。夾硬編譯會拆爛閲讀嘅樂趣。

所以唔好將 Book-to-Skill 當成萬能機器。佢適合將方法書變成可叫用嘅能力，唔適合將所有書都變成工具。

第四步，將 AI 放入 Obsidian，而唔係來回複製。

好多人讀書嗰陣用 AI 嘅方式好斷裂：喺 Obsidian 睇筆記，諗到問題，轉去瀏覽器，開 AI，複製一段內容，得到回答，再複製返嚟，格式亂曬，再整理。

呢種切換會打斷思維。

更好嘅方式係將 AI 代理放入 Obsidian。你喺筆記入面揀選一段文字，㩒快捷鍵，叫 AI 用金字塔原理重構；或者喺筆記入面輸入命令，叫佢叫用某本書嘅 Skill；或者用 @ 引用多個檔案，叫佢根據當前項目同書籍框架生成大綱。

例如你喺日記度寫：「今日遇到一個架構決策，唔知應該用微服務定係單體。」

你可以叫用原則類 Skill，叫 AI 先判斷問題類型、可逆性、影響範圍，再按目標、問題、診斷、方案、執行清單拆開。佢仲可以建議你參考系統設計相關 Skill，檢查分區、擴展性同組織複雜度。

嗰陣書唔再係書架上嘅知識，而係參與真實決策嘅工具。

第五步，等知識圖譜自動生長，但唔好完全放縱。

Claudian 呢類工具偏向即時對話，Claude-Obsidian 呢類後台服務偏向自動維護。兩者要分清。

即時對話係你觸發，AI 回應；後台維護係每日掃描新增筆記，發現關聯，插入雙向連結，更新 MOC，生成每日發現。

例如第一階段你編譯咗 3 本書，知識圖譜可能仲係幾個孤島。第二階段編譯 5 本書，AI 開始發現關聯。第三階段編譯 8 本書之後，可能會出現樞紐節點：系統思維、複利、反思循環、原子性、槓桿。

呢啲樞紐唔係你硬諗出嚟嘅，而係唔同書同工作日誌之間自然生曬出嚟。

但自動關聯一定有噪音。AI 可能因為關鍵詞一樣就連錯，都可能將表面關聯當成深層關係。每日用 5 分鐘檢查 daily discoveries，刪咗冇用嘅連結，為真正有價值嘅連結加註解，呢步唔可以慳。

知識圖譜嘅價值唔係全自動，而係令你每日多見到幾個自己原本睇唔到嘅連接。

第六步，行一個 7 日最小閉環。

可以拎一本有框架嘅薄書做測試。

Day 1，準備 EPUB 或者 PDF，紙書就用掃描加 OCR。

Day 2，執行 Book-to-Skill 或者手動用 Claude 抽取出 SKILL.md。

Day 3，審查輸出：框架係咪完整，術語係咪準確，命令係咪清晰，反模式係咪有齊。

Day 4，將 Skill 放返入 Obsidian 嘅 Skills 資料夾。

Day 5，用 Claudian 同呢本書對話，生成幾個場景化命令。

Day 6，用真實問題測試，例如攞用家訪問記錄叫 Mom Test Skill 做審計。

Day 7，用呢本書嘅 Skill 結合你嘅真實案例，寫一篇文章大綱或者做一個決策。

呢個閉環行得通之後，你先算真正「讀完一本書」。

第七步，注意五個陷阱。

第一個陷阱，將 Obsidian 用成 Notion。太依賴資料夾分類，筆記會越來越難揾。更好嘅方式係標籤、雙向連結同 MOC。

第二個陷阱，生成嘅 SKILL.md 全部都係原文抄錄。嗰陣要改提示，強調實踐者口吻、命令形式、反模式、速查表。

第三個陷阱，對話上下文丟失。每次對話前用 @ 引用相關檔案，等 AI 重新建立背景。

第四個陷阱，自動關聯噪音太多。每日審查 5 分鐘，唔好俾錯誤連結污染圖譜。

第五個陷阱，想一次過將所有工具 set 好先開始。更好嘅路線係先用 Obsidian + 一個 AI + 手動 SKILL.md 行通第一本書，再慢慢加插件。

工具鏈睇落複雜，但邏輯只有一句話：

將書變成你可以隨時叫用嘅技能，而唔係讀完就忘嘅文字。

今日就做到嘅動作都好簡單：揀一本薄嘅、有框架嘅書，抽取出 1 個核心論點、3 個命名框架、5 個可執行命令、5 個反模式。先唔好追求完美，先叫佢喺一個真實問題入面行得鬱。

讀完唔算數，行得通先算。

很多人讀書的問題，不是沒讀，而是讀完用不上。

書摘一堆，劃線一堆，讀書筆記一堆。真正遇到一個決策、一個項目、一個寫作題目時，那些筆記就像躺在倉庫裏的零件，找不到、調不出、用不上。

一個只寫不讀的知識庫，不是知識庫，更像垃圾桶。

所以讀書這件事真正該升級的，不是“如何摘更多金句”，而是如何把一本書變成一個能被 AI 調用的 Skill。

這套思路可以叫“編譯式閲讀”。不是每次問 AI 時再讓它檢索 PDF，而是先把書裏的框架、模型、術語、反模式提取出來，變成一份結構化 Skill。以後遇到真實問題時，AI 不是臨時翻書，而是調用已經編譯好的方法。

第一步，先搭一個能長期存活的知識底座。

工具可以有很多，但 Obsidian 很適合做這件事。原因很現實。

第一，它是純 Markdown、本地存儲。10 年後某個工具不更新了，你的文件還在，任何文本編輯器都能打開。

第二，它有雙向連結和圖譜視圖。一本書的筆記還好，二十本書以後，你需要看到概念之間怎麼互相連接。

第三，它有插件生態。Claudian、Obsidian Git、Dataview、Templater、Graph Analysis 這類工具，可以把 Obsidian 從筆記軟件變成一個知識操作系統。

一個實用的 Vault 結構可以這樣設計：Inbox 放所有新想法；Skills 放編譯出的書籍 Skill；Notes 放永久筆記；MOC 放內容地圖；Projects 放進行中的項目；Archives 放歸檔；Daily 放每日記錄。

這套結構的重點不是好看，而是讓輸入、加工、調用、歸檔各有位置。

第二步，把書從“文本”編譯成 Skill。

傳統 AI 讀書工具的邏輯是：你問問題，AI 檢索原文，然後回答。這叫檢索，不叫編譯。

編譯的邏輯是：書先經過預處理，提取核心框架、命名術語、可執行命令、反模式、速查表，再生成 SKILL.md。以後 Claude 或其他 AI 需要用這本書時，加載的是方法結構，不是整本原文。

一個合格的書籍 Skill 至少應該包含：

作者核心論點，不超過 100 字；命名框架，每個框架要有定義、使用場景和示例；可執行命令，用“在什麼情況下使用什麼動作”的格式寫；術語表，每條儘量短；反模式，明確不要做什麼；速查表，列出最重要的 5 個決策點。

這裏有一個質量判斷：如果生成出來全是原文摘抄，說明失敗了。好 Skill 應該是實踐者口吻，不是讀書摘錄。

比如《The Mom Test》被編譯後，核心不該是“這本書講用戶訪談很重要”，而是：

不要問未來，要問過去；不要問“你會用嗎”，要問“你上次什麼時候遇到這個問題”；有效數據包括已付款行為、已承諾行為、具體事實；無效問題包括“你喜歡這個功能嗎”“你會為它付多少錢嗎”。

這就從知識變成了工具。

第三步，不是所有書都適合編譯。

最適合編譯的書有三個特徵：有命名框架，有可執行方法，有明確術語。比如決策框架、卡片筆記法、深度工作、系統設計、產品訪談這類書。

有些書可以編譯，但需要人工補場景，比如人物訪談、商業傳記、思想隨筆。它們有洞見，但框架不夠硬。

有些書不適合編譯，比如純敍事、散文、小說、情感閲讀。強行編譯會把閲讀樂趣拆壞。

所以不要把 Book-to-Skill 當成萬能機器。它適合把方法書變成可調用能力，不適合把所有書都變成工具。

第四步，把 AI 放進 Obsidian，而不是來回複製。

很多人讀書時用 AI 的方式非常割裂：在 Obsidian 看筆記，想到問題，切到瀏覽器，打開 AI，複製一段內容，得到回答，再複製回來，格式亂了，再整理。

這種切換會打斷思維。

更好的方式是把 AI 代理放進 Obsidian。你在筆記裏選中一段文字，按快捷鍵，讓 AI 用金字塔原理重構；或者在筆記裏輸入命令，讓它調用某本書的 Skill；或者用 @ 引用多個文件，讓它基於當前項目和書籍框架生成大綱。

比如你在日記裏寫：“今天遇到一個架構決策，不知道該用微服務還是單體。”

你可以調用原則類 Skill，讓 AI 先判斷問題類型、可逆性、影響範圍，再按目標、問題、診斷、方案、執行清單拆開。它還可以建議你參考系統設計相關 Skill，檢查分區、擴展性和組織複雜度。

這時書不再是書架上的知識，而是參與真實決策的工具。

第五步，讓知識圖譜自動生長，但不要完全放任。

Claudian 這類工具偏即時對話，Claude-Obsidian 這類後台服務偏自動維護。兩者要分清。

即時對話是你觸發，AI 響應；後台維護是每天掃描新增筆記，發現關聯，插入雙向連結，更新 MOC，生成每日發現。

比如第一階段你編譯了 3 本書，知識圖譜可能還是幾個孤島。第二階段編譯 5 本書，AI 開始發現關聯。第三階段編譯 8 本書後，可能出現樞紐節點：系統思維、複利、反思循環、原子性、槓桿。

這些樞紐不是你硬想出來的，而是不同書和工作日誌之間自然長出來的。

但自動關聯一定會有噪音。AI 可能因為關鍵詞相同就連錯，也可能把淺層關聯當深層關係。每天花 5 分鐘審查 daily discoveries，刪掉無效連結，給真正有價值的連結加批註，這一步不能省。

知識圖譜的價值不是全自動，而是讓你每天多看到幾個自己原來沒看到的連接。

第六步，跑一個 7 天最小閉環。

可以拿一本有框架的薄書做測試。

Day 1，準備 EPUB 或 PDF，紙書就用掃描加 OCR。

Day 2，運行 Book-to-Skill 或手動用 Claude 提取 SKILL.md。

Day 3，審查輸出：框架是否完整，術語是否準確，命令是否清晰，反模式是否包含。

Day 4，把 Skill 放進 Obsidian 的 Skills 文件夾。

Day 5，用 Claudian 和這本書對話，生成幾個場景化命令。

Day 6，用真實問題測試，比如拿用戶訪談記錄讓 Mom Test Skill 審計。

Day 7，用這本書的 Skill 結合你的真實案例，寫一篇文章大綱或做一個決策。

這個閉環跑通以後，你才算真正“讀完一本書”。

第七步，注意五個坑。

第一個坑，把 Obsidian 用成 Notion。過度依賴文件夾分類，筆記會越來越難找。更好的方式是標籤、雙向連結和 MOC。

第二個坑，生成的 SKILL.md 全是原文摘抄。這時要改提示，強調實踐者口吻、命令形式、反模式、速查表。

第三個坑，對話上下文丟失。每次對話前用 @ 引用相關文件，讓 AI 重新建立背景。

第四個坑，自動關聯噪音太多。每天審查 5 分鐘，不要讓錯誤連結污染圖譜。

第五個坑，想一次性把所有工具配好再開始。更好的路線是先用 Obsidian + 一個 AI + 手動 SKILL.md 跑通第一本書，再慢慢加插件。

工具鏈看起來複雜，但邏輯只有一句話：

把書變成你能隨時調用的技能，而不是讀完就忘的文本。

今天就能做的動作也很簡單：選一本薄的、有框架的書，提取 1 個核心論點、3 個命名框架、5 個可執行命令、5 個反模式。先不要追求完美，先讓它在一個真實問題裏跑起來。

讀完不算，跑通才算。