給Obsidian 裝完自動運轉引擎（codex+skills+wiki）：知識碎片開始自己連成網

今日介紹嚇一套可以自動運轉嘅 Obsidian 知識庫系統。

可以當係俾 Obsidian 裝咗部引擎。

呢部引擎由三類嘢組成：

一類係 Skills，令 AI 真正理解 Obsidian 嘅格式。

一類係 Codex，令 AI 可以好似執行者咁讀取、修改、整理本地文件。

一類係 Wiki / 自動維護機制，令碎片筆記不斷被編譯、連接、審查、晉升。

呢篇文章唔係一篇「插件清單」，我更想寫嘅係一次覆盤：

點解我個知識庫以前係死嘅？

點解我覺得普通嘅雙鏈同標籤唔夠？

Skills、Codex、Wiki 呢三樣嘢分別解決啲咩問題？

同埋，一個普通人如果想令自己嘅 Obsidian 由「存資料」變成「長知識」，今日應該先改邊一步。

一、死咗嘅知識庫，通常唔係死喺輸入，而係死喺維護

好多人啱啱開始用 Obsidian 嘅時候，最容易上頭。

因為佢太適合「裝曬所有嘢」喇。

網頁剪藏可以放進去。

讀書筆記可以放進去。

項目覆盤可以放進去。

日記、靈感、選題、課程、客戶問題，都放得進去。

Markdown 文件天然開放，雙鏈睇落又好有「知識網絡」嘅感覺。

但我而家睇返，最危險嘅地方就喺呢度。

Obsidian 令輸入變得咁易，但佢冇自動幫你解決維護問題。

輸入速度一旦大過處理速度，Inbox 就會變成一個黑洞。

你以為自己係喺度建立第二大腦，實際上可能只係喺度建立第二個下載文件夾。

呢件事最反直覺嘅地方在於：

知識庫真正嘅瓶頸，唔係「有冇記錄」，而係「記錄咗之後有冇被重新組織」。

一條筆記如果冇被放到正確嘅位置，冇同其他筆記建立關係，冇被項目調用過，亦冇進入任何覆盤或決策流程，佢就只係一個文件。

文件再多，都唔會自動變成認知。

以前我嘅處理方法都好樸素：

見到好內容，先放 Inbox。

得閒嘅時候，再打標籤。

覺得重要嘅，就手動加幾個雙鏈。

讀完一本書，再抽啲原子筆記。

做項目嘅時候，諗起就去搜嚇舊資料。

呢套方法喺筆記數量好少嘅時候係行得通嘅。

但只要內容密度上嚟，佢就會冧。

唔係因為方法錯，而係因為佢太依賴人持續自律。

人會忙。

人會唔記得。

人會喺週末打開 Inbox，然後睇住幾十篇未處理筆記直接熄咗佢。

仲麻煩嘅係，手動維護仲有一個隱性問題：你會傾向於整理「睇落重要」嘅內容，而唔係整理「將來可能俾人用」嘅關係。

比如你會俾一篇文章打上 #AI、#工具、#知識管理。

但真正有價值嘅連結可能係：

呢篇文章裏面嘅「自動晉升機制」，可以連接到你之前做項目覆盤嗰陣遇到嘅「知識無法複用」問題。

呢篇文章裏面嘅「Agent 維護 Vault」，可以連接到你正在做嘅內容生產流程。

呢篇文章裏面嘅「定期健康報告」，可以連接到你之前搭過嘅個人 OKR 或項目看板。

呢啲關係唔係關鍵詞關係，而係使用關係。

靠人一篇篇手動諗，好難長期堅持。

所以我後嚟判斷，一個知識庫要生猛啲，唔可以只靠「識記錄」，必須有一套持續維護機制。

即係話，你唔可以只問：

我點記？

你仲要問：

邊個嚟整理？

邊個嚟檢查？

邊個嚟發現孤立筆記？

邊個將舊知識同新項目重新連起來？

邊個提醒我，呢條知識已經值得由原子筆記晉升做框架？

以前呢啲問題都默認由人做。

而家我更願意俾 AI 做其中大部分機械工作。

二、我想要嘅唔係「更識傾偈嘅 AI」，而係「識維護檔案系統嘅 AI」

好多人用 AI 管知識庫，第一反應就係將資料掟俾一個聊天窗口。

問佢：幫我總結嚇。

再問佢：幫我提煉幾個觀點。

最後複製返去 Obsidian。

咁當然有用，但我覺得仲未夠。

因為咁樣仍然將知識困喺一次性嘅對話入面。

你獲得咗一個回答，但你個 Vault 冇因為咁變好。

你啲舊筆記冇被更新。

你啲雙鏈冇增加。

你個 Inbox 冇清空。

你個項目看板冇變化。

你個知識圖譜亦冇因為咁更準確。

呢個就係我今次最想解決嘅問題：

AI 唔應該只喺聊天窗口裏面回答問題。

AI 應該進入知識庫嘅維護現場。

佢要識睇你嘅 Markdown 文件。

佢要知 Obsidian 嘅 wikilink 應該點寫。

佢要知 frontmatter 唔可以亂生成。

佢要知 Canvas 文件係 JSON，唔係普通文章。

佢要識搜尋、移動、補屬性、檢查孤立筆記。

佢要識定期行任務，而唔係每次都等我諗起先叫佢。

呢個亦係我點解將呢套系統拆成三層。

第一層係理解層。

解決嘅問題係：AI 到底識唔識 Obsidian 嘅格式？

第二層係操作層。

解決嘅問題係：AI 到底可唔可以直接操作 Vault？

第三層係維護層。

解決嘅問題係：AI 到底可唔可以長期、重複、低幹預咁做啲人唔想做嘅整理工作？

呢三層缺一不可。

得理解層，AI 寫得規範，但唔可以真正管理文件。

得操作層，AI 改得文件，但可能將格式寫亂。

得維護層，系統定時行得到，但如果前兩層冇打好，自動化只會自動製造混亂。

所以我後嚟俾自己定咗一個標準：

任何進入知識庫嘅 AI 工作流，都必須同時回答三個問題：

佢知唔知 Obsidian 嘅規則？

佢安唔安全咁操作文件？

佢留低嘅結果以後仲可唔可以俾我重用？

答唔到呢三個問題，就只算一次性輔助，唔算知識庫引擎。

三、第一層：Skills 令 AI 先學識 Obsidian 嘅語法

好多人會低估呢一步。

因為睇落，Obsidian 咪即係 Markdown？

但真正用起嚟就會發現，Obsidian 唔係普通 Markdown。

佢有 wikilink。

佢有 embeds。

佢有 callouts。

佢有 properties / frontmatter。

佢有 Bases。

佢有 Canvas。

佢仲有一大堆同插件生態相關嘅檔案格式。

如果 AI 唔理解呢啲規則，佢就好容易寫出「睇落係 Markdown，但喺 Obsidian 裏面唔好用」嘅內容。

例如，AI 可能會將內部連結寫成：

[某篇筆記](某篇筆記.md)

但喺 Obsidian 裏面，我真正想要嘅係：

[[某篇筆記]]

前者喺網頁好正常，後者先會入到 Obsidian 嘅雙鏈同反向連結體系。

再例如，AI 可能會將 Canvas 當成普通文本嚟寫。

但 Canvas 文件本質上係 JSON，節點、邊、位置、尺寸都有結構要求。

一個換行寫錯，文件就可能開唔到。

所以 Skills 嘅價值唔係「多一個提示詞」。

佢更加似係俾 AI 裝上某個領域嘅工作規程。

喺呢套 Obsidian 工作流裏面，我最睇重幾類 Skills。

第一類係 obsidian-markdown。

佢解決嘅係最基礎嘅 Markdown 規範問題。

寫筆記嘅時候，內部連結應該用 wikilink。

引用整篇筆記或某個章節嗰陣，應該用 Obsidian 嘅 embed 語法。

標註區塊應該用 callout。

frontmatter 要完整，但唔可以亂塞字段。

標籤要有層級，但唔可以無限擴張。

呢類規則睇落細，但佢決定咗知識庫以後可唔可以被檢索、被連結、被圖譜識別。

第二類係 obsidian-bases。

佢解決嘅係將 Vault 變成輕量數據庫嘅問題。

以前我哋睇筆記，通常係按文件夾睇。

但當筆記數量變多之後，文件夾唔夠用。

我更需要嘅係動態視圖。

例如所有 type: atom 嘅知識原子。

所有 status: active 嘅項目覆盤。

所有 confidence: high 但仲未晉升成框架嘅筆記。

所有最近 30 日被引用過嘅舊觀點。

呢啲唔應該靠人手動維護列表，而應該交俾 Bases 呢類數據庫視圖自動更新。

第三類係 json-canvas。

佢解決嘅係可視化圖譜嘅問題。

我以前都鍾意睇 Obsidian 嘅全局圖譜，但後嚟發現佢太容易變成一團煙花。

節點好多，線好多，睇落好震撼，但對決策冇乜幫助。

真正有用嘅圖譜，唔係所有筆記自動連成一團，而係圍繞一個問題、一個項目、一個框架，將關鍵節點同關係畫清楚。

Canvas 更適合做呢件事。

但前提係 AI 必須知道 Canvas 文件點樣寫。

第四類係 defuddle。

佢解決嘅係網頁入庫嘅問題。

好多網頁內容直接複製入知識庫，會帶入大量導航、廣告、推薦、雜亂格式。

呢啲嘢唔單止污染筆記，亦浪費後續 AI 處理嗰陣嘅上下文。

所以網頁進入 Vault 之前，最好先清洗成乾淨 Markdown，再加 source、date、topics 呢啲必要屬性。

呢一步做好之後，網頁剪藏先唔係「收藏夾搬家」，而係進入可處理嘅知識流水線。

我而家越來越覺得，Skills 嘅真正價值唔係令 AI 變聰明，而係令 AI 少犯低級格式錯誤。

一個知識庫長期運行，最怕嘅唔係某一次回答唔夠驚艷，而係每日喺裏面寫少少唔規範嘅嘢。

壞格式會慢慢積累。

連結會斷。

屬性會亂。

標籤會發散。

圖譜會失真。

最後你唔敢俾 AI 繼續維護佢。

所以，先俾 AI 立規矩，再俾佢動手。

呢個係第一層。

四、第二層：Codex 令 AI 真正有「手」

理解格式仲唔夠。

AI 仲要識得做嘢。

如果佢淨係俾我一段建議，叫我複製、貼上、建文件、改屬性、補連結，咁維護成本仲係我度。

所以第二層係操作層。

我需要一個 Agent 可以直接入到 Vault 嘅檔案系統。

讀取文件。

搜尋關鍵詞。

檢查屬性。

創建新筆記。

移動筆記。

補充雙鏈。

生成報告。

必要嘅時候仲可以提交版本紀錄。

呢個就係 Codex 喺呢套系統裏面嘅位置。

佢唔係用嚟炫技嘅。

佢更似一個冇介面嘅知識庫維護工。

我真正想俾佢做嘅嘢，通常都好樸素：

掃描 Inbox，揾出超過 24 個鐘未處理嘅筆記。

檢查呢啲筆記有冇 type、date、tags、source。

根據內容判斷佢應該入書籍、原子、項目，定係輸出目錄。

如果冇任何 wikilink，就標記為孤立筆記。

再搜尋 Vault 入面可能相關嘅舊筆記，俾出連結建議。

如果要修改，先列出清單，再執行。

執行完之後，留低變更紀錄。

呢啲事一啲都唔玄。

但佢哋好重要。

因為知識庫唔係靠一次大整理變好，而係靠每日還少少債。

以前我靠自己整理，最容易出現兩種極端：

一種係長期唔理，最後 Inbox 爆炸。

另一種係突然上頭，花成晚重構目錄，第二日繼續荒廢。

呢兩種都唔可持續。

Codex 適合做嘅唔係「俾我一個宏大嘅知識體系」，而係每日幫我將維護動作行一次。

我會將任務寫到好具體。

例如每日 Inbox 清理，唔係簡單一句「整理嚇我個知識庫」。

而係清楚話明：

邊啲文件要掃描。

咩條件算未處理。

按咩規則歸類。

欠邊啲屬性要補。

咩情況只標記唔移動。

咩情況一定要等我確認。

完成之後生成咩報告。

呢個其實係一個好重要嘅轉變。

我哋唔可以指望 AI 代替我哋「理解一切」。

我要將自己嘅維護原則寫成任務規則，俾 AI 按規則行。

AI 最適合做嘅係高頻、重複、邊界清楚嘅維護動作。

人應該保留嘅係判斷權：

呢條知識值唔值得晉升？

呢個連結係咪真係有意義？

呢個框架係咪已經俾真實項目驗證過？

呢條舊筆記係咪已經過時？

我而家嘅分工好明確：

Codex 做機械整理。

我做關鍵判斷。

呢個比「全部自動化」更可靠。

五、第三層：Wiki 同自動維護機制，令知識開始循環

如果得 Skills 同 Codex，其實仲係得「識寫、識改」。

真正令知識庫生猛嘅，係第三層：持續維護機制。

呢層我當佢係 Wiki 化。

唔係將所有內容做成百科，而係令原材料經過編譯、連接、審查，逐步變成可查詢、可重用、可追蹤嘅知識系統。

呢度有一個關鍵判斷：

唔係所有筆記都平等。

好多人做知識庫，容易將所有內容都當成「筆記」。

讀書摘錄係筆記。

網頁剪藏係筆記。

項目覆盤係筆記。

一句靈感都係筆記。

最後所有嘢溝埋一齊。

但如果你真係想知識庫撐得起決策，就必須有層次。

我而家更鍾意用四級嚟理解：

第 0 級，係 Inbox。

佢只係原始輸入，未經處理。

呢度嘅內容唔可以直接信，亦唔可以直接重用。

第 1 級，係已歸類嘅書籍筆記、網頁剪藏、知識原子。

佢哋已經有基本屬性，有來源，有主題，有初步連結。

但佢哋仲係材料。

第 2 級，係框架卡。

一條知識原子如果俾多個案例驗證，俾多個項目引用，而且有清楚嘅適用條件同失效條件，先夠資格晉升成框架。

第 3 級，係原則。

呢個係我真係會用嚟影響判斷嘅嘢。

而係我喺多個真實場景用過、驗證過、願意繼續承擔後果嘅判斷。佢唔係人哋講過嘅一句話，

呢套分級好重要。

因為如果冇晉升機制，知識庫就會一直停留喺「我收集咗好多嘢」。

而唔係「我沉澱咗自己嘅判斷」。

自動維護機制要做嘅，就係不斷推動內容喺呢幾個層級之間流動。

每日處理 Inbox。

每週檢查新增筆記同舊筆記嘅關係。

每月生成健康報告，睇嚇邊啲知識被引用，邊啲一直孤立，邊啲可以晉升，邊啲需要歸檔。

咁樣，知識庫先會由靜態儲存變成動態系統。

佢會不斷問你：

呢條筆記有冇俾人用過？

呢個標籤係咪重複？

呢個原子有冇足夠案例支撐？

呢條連結係咪只係關鍵詞相同，定係真係解決同一個問題？

呢個項目覆盤裏面有冇可以抽成框架嘅部分？

呢啲問題如果全靠人主動諗，好難。

但如果變成定期任務，佢哋就會反覆出現。

知識庫亦就開始有咗「自我修復」嘅能力。

六、呢套引擎行起咗之後，我最明顯嘅感受係咩

我最明顯嘅感受，唔係「整理速度快咗」。

而係我對知識庫嘅期望變咗。

以前我打開 Obsidian，多數係揾嘢。

而家我希望佢可以提醒我：你以前存過嘅某個判斷，同你而家做嘅呢個問題有關。

呢個變化好關鍵。

一個真正有價值嘅知識庫，唔應該淨係可以搜尋。

搜尋係你知道自己要揾咩。

但好多時候，你唔知舊知識裏面有啲咩可以幫到而家。

你需要嘅係「俾人提醒」。

例如我今日做一個商業診斷，入面出現咗「用戶點解唔願意持續使用」呢個問題。

如果知識庫裏面曾經有一條讀書筆記講「行為改變嘅摩擦成本」，有一條項目覆盤講「工具上手門檻」，仲有一條內容筆記講「用戶唔係唔想學，而係唔想被迫改變流程」，咁佢哋之間就應該被連接起來。

呢種連接唔係關鍵詞層面嘅「都有用戶兩個字」。

而係問題層面嘅「都在解釋同一種阻力」。

呢個先係知識網絡嘅價值。

以前靠我手動加連結，好難做得到。

因為我唔可能每日記得三個月前寫過咩。

但 Agent 可以定期掃描、搜尋、建議。

佢唔一定一次判斷正確，但佢可以將候選關係擺喺我面前。

我只需要做最後判斷：

呢個連結成立，定係唔成立。

呢度仲有一個好實際嘅收益：

好多內容創作者、諮詢顧問、獨立開發者，其實最缺嘅唔係靈感，而係重用自己嘅舊材料。

你以前睇過嘅書，做過嘅項目，踩過嘅坑，如果唔可以被重新調用，就會變成沉沒成本。

而一套自動維護嘅知識庫，會將呢啲舊材料重新推返去工作流。

你寫文章嘅時候，佢可以揾到舊案例。

你做項目嘅時候，佢可以揾到舊框架。

你做產品判斷嘅時候，佢可以揾到過去失敗嘅原因。

你準備課程或諮詢嗰陣，佢可以將零散材料整理成模塊。

呢個就係我講嘅：碎片開始自己連成網。

唔係筆記數量變多，而係舊筆記重新有咗出場機會。

七、但我不建議一上來就全自動

呢度一定要講一個邊界。

俾 AI 維護知識庫，唔等於俾 AI 亂改知識庫。

我反而覺得，愈想長期行，愈要剋制。

最容易出事嘅地方有四個。

第一個，係自動連結過度。

如果規則唔清楚，AI 好容易將所有睇落相關嘅嘢都連埋一齊。

咁樣會令圖譜變熱鬧，但關係質量下降。

我而家判斷一個連結值唔值得保留，會睇佢可唔可以答一句話：

呢兩份筆記點解應該互相見到對方？

如果答案只係「都提到 AI」「都屬於知識管理」，咁就唔夠。

如果答案係「佢哋都在解釋同一個項目失敗原因」「一個係方法，一個係案例」「一個係原則，一個係反例」，呢個連結先更有價值。

第二個，係標籤發散。

AI 好擅長俾內容打標籤，亦好容易打太多標籤。

標籤一多，睇落精細，但實際上會降低檢索價值。

我更傾向於限制標籤層級同數量。

標籤係入口，唔係正文。

真正嘅關係應該由 wikilink、屬性、Bases 視圖同項目引用嚟承載。

第三個，係將未驗證嘅觀點過早晉升。

AI 總結能力強，好容易將一段材料總結成「原則」。

但原則唔係總結出嚟嘅，係用出嚟嘅。

一條觀點如果冇經過多個場景驗證，冇失敗條件，冇反例，就只可以停留喺原子或候選框架。

唔可以因為佢寫得靚，就入原則庫。

第四個，係冇版本記錄。

只要俾 Agent 批量改文件，就一定要有回滾機制。

否則一次錯誤嘅自動整理，可能會令你好難定位問題。

所以我會盡量令每次維護都有記錄。

改咗邊啲文件？

點解改？

邊啲只係建議，邊啲已經執行？

出現問題點撤回？

聽落似工程習慣，但知識庫到咗一定規模之後，本質上就係一個個人知識工程。

冇版本意識，就唔應該隨便自動化。

所以我而家對呢件事嘅態度唔係「全部交俾 AI」。

而是：

低風險、高重複嘅維護工作，交俾 AI。

高價值、會影響判斷嘅知識晉升，保留人工審查。

呢個先係比較穩嘅分工。

八、如果你都想做，唔好一開始就搞大系統

好多人見到 Skills、Codex、Wiki、Bases、Canvas，第一反應就覺得複雜。

但我不建議一開波就搭完整系統。

真正行得動嘅系統，通常由一個好細嘅閉環開始。

你可以先做一個 30 分鐘版本。

第一步，只處理一個目錄：Inbox。

唔好搞整個 Vault。

先問自己：

Inbox 裏面嘅內容通常嚟自邊度？

網頁？

讀書？

項目？

臨時諗法？

唔同來源入到知識庫之後，應該變成咩類型？

第二步，定一個最小 frontmatter 模板。

唔好一開始就設計十幾個字段。

先留低幾個真正有用嘅：

type。

date。

source。

topics。

status。

第三步，寫一條非常具體嘅維護規則。

比如：

掃描 Inbox 裏面超過 24 個鐘嘅筆記。

如果有 source 而且內容嚟自網頁，標記為 clipping。

如果內容包含項目覆盤，標記為 project-note。

如果冇 type，就加 needs-review，唔好自動移動。

如果冇任何 wikilink，就俾出 3 個候選連結，但唔直接寫入。

第四步，手動行三次。

唔好急住定時。

先睇 AI 嘅建議質量。

佢係咪亂分類？

佢係咪亂打標籤？

佢係咪為咗連結而連結？

佢係咪可以講到連結理由？

第五步，再將其中最穩定嘅部分自動化。

例如只自動補 date 同 source。

只自動生成孤立筆記報告。

只自動列出候選連結。

等你信任呢個流程之後，再逐步俾佢移動文件、補連結、生成周報。

呢一步好重要。

好多自動化失敗，唔係因為技術唔得，而係一開始就俾咗系統太大權限。

我嘅建議係：

先俾 AI 做助理。

再俾 AI 做執行者。

最後先俾 AI 做維護者。

順序唔可以掉轉。

九、我最終留低嘅判斷

今次搞掂之後，我對 Obsidian 嘅看法變咗。

以前我當佢係筆記軟件。

後來我當佢係知識倉庫。

而家我更願意當佢係一個本地知識操作系統。

分別在於：

筆記軟件關注嘅係記錄。

知識倉庫關注嘅係存放。

知識操作系統關注嘅係流動。

內容點樣入嚟？

入嚟之後點樣清洗？

點樣變成原子？

點樣被連結？

點樣入到項目？

點樣被重用？

點樣被審查？

點樣晉升成框架？

點樣喺未來某個場景重新出現？

呢啲問題，先決定咗一個知識庫到底有冇生命力。

好多人以為第二大腦嘅關鍵係「記得夠多」。

我而家更願意話，第二大腦嘅關鍵係「可以重新調用」。

如果一條知識入到系統之後，再冇俾人見過，佢只係存檔。

如果一條知識可以喺未來嘅項目、文章、判斷、覆盤不斷出現，佢先開始變成你嘅資產。

Skills、Codex、Wiki 呢套嘢，對我最大嘅價值就喺呢度：

佢哋唔係令我少寫幾篇筆記。

佢哋係令我以前寫過嘅嘢，重新參與而家嘅工作。

呢件事好重要。

因為普通人做 AI，真正拉開差距嘅地方，通常唔係識唔識問一條靚問題。

而係可唔可以將自己嘅經驗、資料、判斷、項目覆盤，沉澱成一個會持續複利嘅系統。

聊天窗口入面嘅回答再好，都會過去。

但一個結構良好、可以自動維護、可以持續連接嘅本地知識庫，會越來越似你嘅長期資產。

所以我而家俾自己嘅建議好簡單：

唔好再將 Obsidian 當成「放資料嘅地方」。

亦唔好指望自己靠自律永遠維護佢。

俾佢一套規則。

俾佢一個 Agent。

俾佢一個定期維護機制。

由人負責判斷，由 AI 負責整理，由檔案系統負責沉澱。

當你有一日發現，三個月前讀書時留下嘅一條原子，突然出現喺今日嘅項目判斷裏面；

當你發現，一篇舊筆記唔再匿埋喺角落，而係俾自動連接到新嘅問題；

當你發現，知識庫開始主動將舊材料推返你嘅工作流；

嗰個時候，Obsidian 先唔只係一個筆記軟件。

佢開始似一個真係會生長嘅系統。

而一個會自己生長嘅知識庫，先配叫第二大腦。

今天介紹一下一套可以自動運轉的Obsidian知識庫系統。

可以把它理解成給 Obsidian 裝了一台引擎。

這台引擎由三類東西組成：

一類是 Skills，讓 AI 真正理解 Obsidian 的格式。

一類是 Codex，讓 AI 能像執行者一樣讀取、修改、整理本地文件。

一類是 Wiki / 自動維護機制，讓碎片筆記不斷被編譯、連接、審查、晉升。

這篇文章不是一篇“插件清單”，我更想寫的是一次覆盤：

為什麼我的知識庫以前是死的？

我為什麼覺得普通的雙鏈和標籤不夠？

Skills、Codex、Wiki 這三個東西分別解決什麼問題？

以及，一個普通人如果想讓自己的 Obsidian 從“存資料”變成“長知識”，今天應該先改哪一步。

一、死掉的知識庫，通常不是死在輸入，而是死在維護

很多人剛開始用 Obsidian 的時候，最容易上頭。

因為它太適合“裝下所有東西”了。

網頁剪藏可以放進去。

讀書筆記可以放進去。

項目覆盤可以放進去。

日記、靈感、選題、課程、客戶問題，也都可以放進去。

Markdown 文件天然開放，雙鏈看起來又很有“知識網絡”的感覺。

但我現在看，最危險的地方也在這裏。

Obsidian 讓輸入變得太容易了，但它沒有自動幫你解決維護問題。

輸入速度一旦大於處理速度，Inbox 就會變成一個黑洞。

你以為自己是在建立第二大腦，實際上可能只是在建立第二個下載文件夾。

這件事最反常識的地方在於：

知識庫真正的瓶頸，不是“有沒有記錄”，而是“記錄以後有沒有被重新組織”。

一條筆記如果沒有被放到正確的位置，沒有和其他筆記建立關係，沒有被項目調用過，也沒有進入任何覆盤或決策流程，它就只是一個文件。

文件再多，也不會自動變成認知。

以前我的處理方式也很樸素：

看到好內容，先放 Inbox。

有空的時候，再打標籤。

覺得重要的，就手動加幾個雙鏈。

讀完一本書，再抽一些原子筆記。

做項目的時候，想起來就去搜一搜舊資料。

這套方法在筆記數量很少的時候是能跑的。

但只要內容密度上來，它就會崩。

不是因為方法錯，而是因為它太依賴人的持續自律。

人會忙。

人會忘。

人會在週末打開 Inbox，然後看着幾十篇待處理筆記直接關掉。

更麻煩的是，手動維護還有一個隱性問題：你會傾向於整理“看起來重要”的內容，而不是整理“未來可能被用到”的關係。

比如你會給一篇文章打上 #AI、#工具、#知識管理。

但真正有價值的連結可能是：

這篇文章裏的“自動晉升機制”，可以連接到你之前做項目覆盤時遇到的“知識無法複用”問題。

這篇文章裏的“Agent 維護 Vault”，可以連接到你正在做的內容生產流程。

這篇文章裏的“定期健康報告”，可以連接到你之前搭過的個人 OKR 或項目看板。

這些關係不是關鍵詞關係，而是使用關係。

靠人一篇篇手動想，很難長期堅持。

所以我後來判斷，一個知識庫要活起來，不能只靠“會記錄”，必須有一套持續維護機制。

也就是說，你不能只問：

我該怎麼記？

你還要問：

誰來整理？

誰來檢查？

誰來發現孤立筆記？

誰來把舊知識和新項目重新連起來？

誰來提醒我，這條知識已經值得從原子筆記晉升成框架？

以前這些問題都默認由人來做。

現在我更願意讓 AI 來承擔其中大部分機械工作。

二、我想要的不是“更會聊天的 AI”，而是“能維護文件系統的 AI”

很多人用 AI 管知識庫，第一反應是把資料丟給一個聊天窗口。

問它：幫我總結一下。

再問它：幫我提煉幾個觀點。

最後複製回 Obsidian。

這當然有用，但我覺得還不夠。

因為這仍然把知識困在一次性的對話裏。

你獲得了一個回答，但你的 Vault 沒有因此變得更好。

你的舊筆記沒有被更新。

你的雙鏈沒有增加。

你的 Inbox 沒有清空。

你的項目看板沒有變化。

你的知識圖譜也沒有因此更準確。

這就是我這次最想解決的問題：

AI 不應該只在聊天窗口裏回答問題。

AI 應該進入知識庫的維護現場。

它要能讀你的 Markdown 文件。

它要知道 Obsidian 的 wikilink 應該怎麼寫。

它要知道 frontmatter 不能亂生成。

它要知道 Canvas 文件是 JSON，不是普通文章。

它要能搜索、移動、補屬性、檢查孤立筆記。

它要能定期跑任務，而不是每次都等我想起來再叫它。

這也是我為什麼把這套系統拆成三層。

第一層是理解層。

解決的問題是：AI 到底懂不懂 Obsidian 的格式？

第二層是操作層。

解決的問題是：AI 到底能不能直接操作 Vault？

第三層是維護層。

解決的問題是：AI 到底能不能長期、重複、低干預地做那些人不想做的整理工作？

這三層缺一不可。

只有理解層，AI 寫得規範，但不能真正管理文件。

只有操作層，AI 能改文件，但可能把格式寫亂。

只有維護層，系統能定時跑，但如果前兩層沒打好，自動化只會自動製造混亂。

所以我後來給自己定了一個標準：

任何進入知識庫的 AI 工作流，都必須同時回答三個問題：

它知道 Obsidian 的規則嗎？

它能安全地操作文件嗎？

它留下的結果以後還能被我複用嗎？

回答不了這三個問題，就只能算一次性輔助，不能算知識庫引擎。

三、第一層：Skills 讓 AI 先學會 Obsidian 的語法

很多人會低估這一步。

因為看起來，Obsidian 不就是 Markdown 嗎？

但真正用起來就會發現，Obsidian 不是普通 Markdown。

它有 wikilink。

它有 embeds。

它有 callouts。

它有 properties / frontmatter。

它有 Bases。

它有 Canvas。

它還有一堆和插件生態相關的文件格式。

如果 AI 不理解這些規則，它就很容易寫出“看起來是 Markdown，但在 Obsidian 裏不好用”的內容。

比如，AI 可能會把內部連結寫成：

[某篇筆記](某篇筆記.md)

但在 Obsidian 裏，我真正想要的是：

[[某篇筆記]]

前者在網頁裏很正常，後者才會進入 Obsidian 的雙鏈和反向連結體系。

再比如，AI 可能會把 Canvas 當成普通文本來寫。

但 Canvas 文件本質上是 JSON，節點、邊、位置、尺寸都有結構要求。

一個換行寫錯，文件就可能無法正常打開。

所以 Skills 的價值不是“多一個提示詞”。

它更像是給 AI 裝上某個領域的工作規程。

在這套 Obsidian 工作流裏，我最看重幾類 Skills。

第一類是 obsidian-markdown。

它解決的是最基礎的 Markdown 規範問題。

寫筆記時，內部連結應該用 wikilink。

引用整篇筆記或某個章節時，應該用 Obsidian 的 embed 語法。

標註塊應該用 callout。

frontmatter 要完整，但不能亂塞字段。

標籤要有層級，但不能無限擴張。

這類規則看起來小，但它決定了知識庫以後能不能被檢索、被連結、被圖譜識別。

第二類是 obsidian-bases。

它解決的是把 Vault 變成輕量數據庫的問題。

過去我們看筆記，往往是按文件夾看。

但當筆記數量變多以後，文件夾不夠用了。

我更需要的是動態視圖。

比如所有 type: atom 的知識原子。

所有 status: active 的項目覆盤。

所有 confidence: high 但還沒有晉升成框架的筆記。

所有最近 30 天被引用過的舊觀點。

這些不應該靠人手動維護列表，而應該交給 Bases 這種數據庫視圖自動更新。

第三類是 json-canvas。

它解決的是可視化圖譜的問題。

我以前也喜歡看 Obsidian 的全局圖譜，但後來發現它太容易變成一團煙花。

節點很多，線很多，看起來很震撼，但對決策沒什麼幫助。

真正有用的圖譜，不是所有筆記自動連成一團，而是圍繞一個問題、一個項目、一個框架，把關鍵節點和關係畫清楚。

Canvas 更適合做這件事。

但前提是 AI 必須知道 Canvas 文件怎麼寫。

第四類是 defuddle。

它解決的是網頁入庫的問題。

很多網頁內容直接複製進知識庫，會帶進大量導航、廣告、推薦、雜亂格式。

這些東西不僅污染筆記，也浪費後續 AI 處理時的上下文。

所以網頁進入 Vault 之前，最好先清洗成乾淨 Markdown，再加 source、date、topics 這些必要屬性。

這一步做好以後，網頁剪藏才不是“收藏夾搬家”，而是進入可處理的知識流水線。

我現在越來越覺得，Skills 的真正價值不是讓 AI 變聰明，而是讓 AI 少犯低級格式錯誤。

一個知識庫長期運行，最怕的不是某一次回答不夠驚豔，而是每天往裏面寫一點點不規範的東西。

壞格式會慢慢積累。

連結會斷。

屬性會亂。

標籤會發散。

圖譜會失真。

最後你就不敢讓 AI 繼續維護它。

所以，先給 AI 立規矩，再讓它動手。

這是第一層。

四、第二層：Codex 讓 AI 真正有“手”

理解格式還不夠。

AI 還需要能做事。

如果它只能給我一段建議，讓我自己複製、粘貼、建文件、改屬性、補連結，那維護成本還是在我身上。

所以第二層是操作層。

我需要一個 Agent 能直接進入 Vault 的文件系統。

讀取文件。

搜索關鍵詞。

檢查屬性。

創建新筆記。

移動筆記。

補充雙鏈。

生成報告。

必要時還能提交版本記錄。

這就是 Codex 在這套系統裏的位置。

它不是拿來炫技的。

它更像一個沒有界面的知識庫維護工。

我真正想讓它做的事情，往往都很樸素：

掃描 Inbox，找出超過 24 小時沒有處理的筆記。

檢查這些筆記有沒有 type、date、tags、source。

根據內容判斷它應該進入書籍、原子、項目，還是輸出目錄。

如果沒有任何 wikilink，就標記為孤立筆記。

再搜索 Vault 裏可能相關的舊筆記，給出連結建議。

如果要修改，先列出清單，再執行。

執行完以後，留下變更記錄。

這些事一點都不玄。

但它們非常重要。

因為知識庫不是靠一次大整理變好的，而是靠每天少積一點債。

以前我靠自己整理，最容易出現兩種極端：

一種是長期不管，最後 Inbox 爆炸。

另一種是突然上頭，花一整晚重構目錄，第二天繼續荒廢。

這兩種都不可持續。

Codex 適合做的不是“給我一個宏大的知識體系”，而是每天幫我把維護動作跑一遍。

我會把任務寫得非常具體。

比如每日 Inbox 清理，不是簡單一句“整理一下我的知識庫”。

而是明確：

哪些文件要掃描。

什麼條件算待處理。

按什麼規則歸類。

缺少哪些屬性要補。

什麼情況只標記不移動。

什麼情況必須等我確認。

完成以後生成什麼報告。

這其實是一個很重要的轉變。

我們不能指望 AI 替我們“理解一切”。

我們要把自己的維護原則寫成任務規則，讓 AI 按規則跑。

AI 最適合做的是高頻、重複、邊界清楚的維護動作。

人應該保留的是判斷權：

這條知識是否值得晉升？

這個連結是否真的有意義？

這個框架是否已經被真實項目驗證過？

這條舊筆記是否已經過時？

我現在的分工很明確：

Codex 做機械整理。

我做關鍵判斷。

這比“全部自動化”更可靠。

五、第三層：Wiki 和自動維護機制，讓知識開始循環

如果只有 Skills 和 Codex，其實還只是“會寫、會改”。

真正讓知識庫活起來的，是第三層：持續維護機制。

這層我把它理解成 Wiki 化。

不是把所有內容做成百科，而是讓原始材料經過編譯、連接、審查，逐步變成可查詢、可複用、可追蹤的知識系統。

這裏有一個關鍵判斷：

不是所有筆記都平等。

很多人做知識庫，容易把所有內容都當成“筆記”。

讀書摘錄是筆記。

網頁剪藏是筆記。

項目覆盤是筆記。

一句靈感也是筆記。

最後所有東西都混在一起。

但如果你真的希望知識庫能支撐決策，就必須有層級。

我現在更願意用四級來理解：

第 0 級，是 Inbox。

它只是原始輸入，未經處理。

這裏面的內容不能直接信，也不能直接複用。

第 1 級，是已歸類的書籍筆記、網頁剪藏、知識原子。

它們已經有基本屬性，有來源，有主題，有初步連結。

但它們還只是材料。

第 2 級，是框架卡。

一條知識原子如果被多個案例驗證，被多個項目引用，並且有清楚的適用條件和失效條件，才有資格晉升成框架。

第 3 級，是原則。

這是我真正會拿來影響判斷的東西。

它不是別人說過的一句話，而是我在多個真實場景裏用過、驗證過、願意繼續承擔後果的判斷。

這套分級很重要。

因為如果沒有晉升機制，知識庫就會一直停留在“我收集了很多東西”。

而不是“我沉澱了自己的判斷”。

自動維護機制要做的，就是不斷推動內容在這幾個層級之間流動。

每天處理 Inbox。

每週檢查新增筆記和舊筆記的關係。

每月生成健康報告，看看哪些知識被引用了，哪些一直孤立，哪些可以晉升，哪些需要歸檔。

這時，知識庫才會從靜態存儲變成動態系統。

它會不斷問你：

這條筆記有沒有被使用？

這個標籤是不是重複？

這個原子有沒有足夠案例支撐？

這條連結是不是隻是關鍵詞相同，還是確實解決同一個問題？

這個項目覆盤裏有沒有可抽象成框架的部分？

這些問題如果全靠人主動想，很難。

但如果變成定期任務，它們就會反覆出現。

知識庫也就開始有了“自我修復”的能力。

六、這套引擎跑起來以後，我最明顯的感受是什麼

我最明顯的感受，不是“整理速度變快了”。

而是我對知識庫的期待變了。

以前我打開 Obsidian，更多是在找東西。

現在我希望它能提醒我：你以前存過的某個判斷，和你現在做的這個問題有關。

這個變化很關鍵。

一個真正有價值的知識庫，不應該只是能搜索。

搜索是你知道自己要找什麼。

但很多時候，你並不知道舊知識裏有什麼可以幫助現在。

你需要的是“被提醒”。

比如我今天做一個商業診斷，裏面出現了“用戶為什麼不願意持續使用”這個問題。

如果知識庫裏曾經有一條讀書筆記講“行為改變的摩擦成本”，有一條項目覆盤講“工具上手門檻”，還有一條內容筆記講“用戶不是不想學，而是不想被迫改變流程”，那它們之間就應該被連接起來。

這種連接不是關鍵詞層面的“都有用戶兩個字”。

而是問題層面的“都在解釋同一種阻力”。

這才是知識網絡的價值。

以前靠我手動加連結，很難做到。

因為我不可能每天記得三個月前寫過什麼。

但 Agent 可以定期掃描、搜索、建議。

它不一定一次判斷正確，但它能把候選關係擺到我面前。

我只需要做最後判斷：

這個連結成立，還是不成立。

這裏還有一個很實際的收益：

很多內容創作者、諮詢顧問、獨立開發者，其實最缺的不是靈感，而是複用自己的舊材料。

你以前看過的書，做過的項目，踩過的坑，如果不能被重新調用，就會變成沉沒成本。

而一套自動維護的知識庫，會把這些舊材料重新推回工作流。

你寫文章的時候，它能找到舊案例。

你做項目的時候，它能找到舊框架。

你做產品判斷的時候，它能找到過去失敗的原因。

你準備課程或諮詢時，它能把零散材料整理成模塊。

這就是我說的：碎片開始自己連成網。

不是筆記數量變多，而是舊筆記重新有了出場機會。

七、但我不建議一上來就全自動

這裏必須講一個邊界。

讓 AI 維護知識庫，不等於讓 AI 隨便改知識庫。

我反而覺得，越是想長期跑，越要剋制。

最容易翻車的地方有四個。

第一個，是自動連結過度。

如果規則不清楚，AI 很容易把所有看起來相關的東西都連起來。

這樣會讓圖譜變熱鬧，但關係質量下降。

我現在判斷一個連結值不值得保留，會看它能不能回答一句話：

這兩個筆記為什麼應該互相看見？

如果答案只是“都提到了 AI”“都屬於知識管理”，那就不夠。

如果答案是“它們都在解釋同一個項目失敗原因”“一個是方法，一個是案例”“一個是原則，一個是反例”，這個連結才更有價值。

第二個，是標籤發散。

AI 很擅長給內容打標籤，也很容易打太多標籤。

標籤一多，看起來精細，實際上會降低檢索價值。

我更傾向於限制標籤層級和數量。

標籤是入口，不是正文。

真正的關係應該由 wikilink、屬性、Bases 視圖和項目引用來承載。

第三個，是把未驗證的觀點過早晉升。

AI 總結能力強，很容易把一段材料總結成“原則”。

但原則不是總結出來的，是用出來的。

一條觀點如果沒有經過多個場景驗證，沒有失敗條件，沒有反例，就只能停留在原子或候選框架。

不能因為它寫得漂亮，就進入原則庫。

第四個，是沒有版本記錄。

只要讓 Agent 批量改文件，就必須有回滾機制。

否則一次錯誤的自動整理，可能會讓你很難定位問題。

所以我會盡量讓每次維護都有記錄。

改了哪些文件？

為什麼改？

哪些只是建議，哪些已經執行？

出現問題怎麼撤回？

這聽起來像工程習慣，但知識庫到一定規模以後，本質上就是一個個人知識工程。

沒有版本意識，就不應該輕易自動化。

所以我現在對這件事的態度不是“全部交給 AI”。

而是：

低風險、高重複的維護工作，交給 AI。

高價值、會影響判斷的知識晉升，保留人工審查。

這才是比較穩的分工。

八、如果你也想做，不要從大系統開始

很多人看到 Skills、Codex、Wiki、Bases、Canvas，會第一反應覺得複雜。

但我不建議一上來就搭完整系統。

真正能跑起來的系統，往往從一個很小的閉環開始。

你可以先做一個 30 分鐘版本。

第一步，只處理一個目錄：Inbox。

不要動整個 Vault。

先問自己：

Inbox 裏的內容通常來自哪裏？

網頁？

讀書？

項目？

臨時想法？

不同來源進入知識庫以後，應該變成什麼類型？

第二步，定一個最小 frontmatter 模板。

不用一開始就設計十幾個字段。

先保留幾個真正有用的：

type。

date。

source。

topics。

status。

第三步，寫一條非常具體的維護規則。

比如：

掃描 Inbox 裏超過 24 小時的筆記。

如果有 source 且內容來自網頁，標記為 clipping。

如果內容包含項目覆盤，標記為 project-note。

如果沒有 type，就加 needs-review，不要自動移動。

如果沒有任何 wikilink，就給出 3 個候選連結，但不直接寫入。

第四步，手動跑三次。

不要急着定時。

先看 AI 的建議質量。

它是不是亂分類？

它是不是亂打標籤？

它是不是為了連結而連結？

它是不是能說明連結理由？

第五步，再把其中最穩定的部分自動化。

比如只自動補 date 和 source。

只自動生成孤立筆記報告。

只自動列出候選連結。

等你信任這個流程以後，再逐步讓它移動文件、補連結、生成周報。

這一步非常重要。

很多自動化失敗，不是因為技術不行，而是因為一開始就給了系統太大的權限。

我的建議是：

先讓 AI 當助理。

再讓 AI 當執行者。

最後才讓 AI 當維護者。

順序不能反。

九、我最後留下的判斷

這次搭完以後，我對 Obsidian 的看法變了。

以前我把它當筆記軟件。

後來我把它當知識倉庫。

現在我更願意把它當成一個本地知識操作系統。

區別在於：

筆記軟件關注的是記錄。

知識倉庫關注的是存放。

知識操作系統關注的是流動。

內容怎麼進來？

進來以後怎麼清洗？

怎麼變成原子？

怎麼被連結？

怎麼進入項目？

怎麼被複用？

怎麼被審查？

怎麼晉升成框架？

怎麼在未來某個場景裏重新出現？

這些問題，才決定了一個知識庫到底有沒有生命力。

很多人以為第二大腦的關鍵是“記得多”。

我現在更願意說，第二大腦的關鍵是“能重新調用”。

如果一條知識進入系統以後，再也沒有被看見，它只是存檔。

如果一條知識能在未來的項目、文章、判斷、覆盤裏不斷出現，它才開始變成你的資產。

Skills、Codex、Wiki 這一套東西，對我最大的價值就在這裏：

它們不是讓我少寫幾篇筆記。

它們是讓我以前寫過的東西，重新參與現在的工作。

這件事很重要。

因為普通人做 AI，真正拉開差距的地方，往往不是會不會問一個漂亮的問題。

而是能不能把自己的經驗、資料、判斷、項目覆盤，沉澱成一個會持續複利的系統。

聊天窗口裏的回答再好，也會過去。

但一個結構良好、能自動維護、能持續連接的本地知識庫，會越來越像你的長期資產。

所以我現在給自己的建議很簡單：

不要再把 Obsidian 當成“放資料的地方”。

也不要指望自己靠自律永遠維護它。

給它一套規則。

給它一個 Agent。

給它一個定期維護機制。

讓人負責判斷，讓 AI 負責整理，讓文件系統負責沉澱。

當你某一天發現，三個月前讀書時留下的一條原子，突然出現在今天的項目判斷裏；

當你發現，一篇舊筆記不再躺在角落，而是被自動連接到新的問題；

當你發現，知識庫開始主動把舊材料推回你的工作流；

那個時候，Obsidian 才不只是一個筆記軟件。

它開始像一個真的會生長的系統。

而一個會自己生長的知識庫，才配叫第二大腦。