引言：為什麼要動手實踐

上週读了 Karpathy 寫的一篇 gist。原文在這。

他討論的方向很有意思：在原始文件和使用者之間，加一層 LLM 自動維護的 Wiki。

核心概念一言以蔽之——知識不該是一次性的檢索產物。每次有新文件讀進去，LLM 會自己寫摘要、更新既有頁面、發現新舊說法之間的矛盾、維護頁面之間的連結。知識是持續累積的，不是查完就走的消耗品。

Karpathy 的 RAG vs Wiki 對比

原文裡把 RAG 和 Wiki 兩種方式做了清楚的對比：

RAG（檢索增強生成）：每次查詢都去原始文件裡撈片段、拼答案。查完就走，什麼都不留下。新文件來了，就多加個索引，之前查過的內容它完全不管。

Wiki 方式：讓知識持續存在。新內容進來後會反過來更新已有的頁面，知識會自己生長、演進。

Karpathy 的架構分為三層：

• 原始源（Source of Truth）：只讀，原始文件不經修改
• Wiki 層：LLM 自己讀寫，持續維護的知識中介
• Schema：定義這個 Wiki 該怎麼管、怎麼維護

還有一個關鍵操作叫 Lint（自我檢視）：定期檢查 Wiki 有沒有矛盾、有沒有過時的頁面、有沒有互相連不上的孤立頁。他說 LLM 不覺得維護麻煩——它一次能改十幾個檔案，不會忘記更新連結。

讀完之後我就在想：這套模式能不能在我自己的開發工作裡落地。

我自己的日常筆記一直用 Obsidian，但 Obsidian 的問題是——得自己手動整理、手動建連結。Karpathy 的方案正好補上了這一塊缺口：Obsidian 負責呈現和瀏覽，LLM 負責生成和維護。兩者結合起來，就是我要的答案。

目錄結構

動手之前，先把目錄結構定好。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

my-wiki/
├── 0_原始文件/              ← 丟進去的資料，唯讀，不碰
├── 1_會話碎片/              ← 從會話中擷取的原始紀錄，按日期分子目錄
│   └── 2026-04-19/
│       └── ses_xxx_主題.md
├── 2_知識圖譜/              ← 提煉後的持久知識，按分類子目錄
│   ├── 01_知識管理/
│   │   └── 0001_LLM-Wiki知識庫架構.md
│   ├── 02_工作流程/
│   │   └── 0010_專案計畫審查流程.md
│   ├── 03_架構與開發/
│   │   └── 0022_依賴注入規範與常見問題.md
│   └── 04_維運與環境/
│       └── 0041_部落格SFTP部署方案.md
├── index.md                  ← 入口索引，按分類列出所有頁面
├── log.md                    ← 每次工作流程的紀錄，只增不改
└── AGENTS.md               ← 規則檔案，人和 LLM 一起演進

每個目錄的職責很清楚：

0_原始文件 是唯讀層。不管是專案文件、技術文章還是參考資料，丟進去之後 LLM 只負責讀，不修改。這保障了原始資料的完整性，也避免了 LLM 在「幫你還是不幫你」之間的模糊地帶——它只負責讀，不負責優化你的原始文件。

1_會話碎片 是原始紀錄的歸檔層。每次和 LLM 的會話中，只要是有價值保留的技術討論、踩雷經驗、架構決策，就擷取出來存一份。按日期分子目錄，避免一個目錄下堆太多檔案。命名規則是 session_id + 會話主題，方便日後按會話 ID 追溯。

2_知識圖譜 是核心層。碎片是原始資料，知識圖譜是提煉後的精華。每個頁面有編號、有摘要、有詳細內容、有 Wikilink 互相連結。知識圖譜按主題分四個分類子目錄——01_知識管理（Wiki 架構、系統配置）、02_工作流程（計畫審查、執行框架）、03_架構與開發（微服務、開發規範、工具鏈）、04_維運與環境（部署、環境配置）。Wikilink 引用時必須帶完整路徑，比如 [[2_知識圖譜/03_架構與開發/0022_依賴注入規範與常見問題]]。

index.md 是入口。不用向量檢索，就用一個 Markdown 表格，按分類列出所有知識頁面，每個頁面一句話摘要加標籤。查東西的時候先掃一眼索引，再點進具體頁面。中等規模（幾十到幾百頁）效果很好。

log.md 是只增不改的操作日誌。每次工作流程跑完都記一筆：影響了哪些頁面、新增了什麼、有什麼發現。

AGENTS.md 是規則。告訴 LLM My-Wiki 怎麼運作、檔案格式要求、增量更新策略。這個檔案不是定好就不變的——實踐中發現規則不夠用的地方，我就改，改完在 log 裡記一筆。

三個工作流程

目錄結構定好之後，我寫了三個 Skill 來完成完整的工作流程。

my-wiki-src（擷取原始文件）：從 0_原始文件/ 裡讀取使用者丟進去的資料，提煉知識到 2_知識圖譜/。一篇文件讀進去，可能會影響十多個既有的知識頁面——更新、補充、建立新的維基連結。

my-wiki-talk（從會話提煉知識）：這是我最常用的。用 session API 讀取歷史會話，將有價值的對話內容提煉為知識碎片，整合到知識庫裡。具體流程是：讀取會話 → 生成碎片檔案 → 提煉知識頁面 → 建立 Wikilink 雙向連結 → 更新索引 → 追加日誌。

my-wiki-think（自我檢視）：定期執行。掃描所有知識頁面，尋找矛盾說法、孤立頁面、遺漏的連結，修復未按 AGENTS.md 標準執行的內容。還會發現那些「被多次提到但沒獨立成頁」的概念，建議建立新頁面。

這三個工作流程對應了 Karpathy 說的三個核心操作：Ingest（擷取）、Query（查詢，這裡用 talk 替代）、Lint（體檢）。

第一次執行

Skill 寫完後，第一次觸發了 /my-wiki-talk。它把我從今年 1 月到 4 月的歷史會話全掃了一遍。

讀取 15 個會話，生成 15 個碎片檔案，提煉出 8 個初始知識頁面。

這 8 個頁面涵蓋了當時的核心主題：LLM-Wiki 架構本身、系統配置規範、企業級知識庫建置經驗、計畫審查流程、E2E 測試概念、思考語言配置、維運工具選型。

之後又陸續執行了幾次，從不同專題的會話裡繼續擷取。不同專案的遷移策略、服務搬遷的踩雷經驗、CI/CD 建置問題修復、依賴注入的類型匹配規則、微服務的分層架構設計——全部有條不紊地沉澱到了知識圖譜裡。

每次執行完我都會檢查輸出。碎片檔案的 YAML front matter 資訊對不對、知識頁面的摘要是否準確、Wikilink 有沒有指向不存在的頁面——這些都是要確認的。不是完全放養，還是得有人看一眼。

知識頁面從最初的 8 個漲到了 43 個。

實踐方法論

整個實踐下來，我總結出幾條方法論。不是什麼新理論，是我自己走過一遍之後覺得值得記住的東西。

知識不是採集出來的，是累積的

這一點是最本質的轉變。以前我的習慣是碰到問題查資料、解決了就忘。下次遇到同樣的問題，又重新查一遍。

現在不一樣了。每次踩雷經驗一旦確認有複用價值，就提煉成知識頁面存下來。重點是不怕重複——同一個概念可能在不同專案的會話裡出現好多次，每次出現都是新的角度、新的上下文。會話碎片保留原始紀錄，知識圖譜提煉共性。

舉個例子，某個技術點的處理方式，在好幾個專案的會話裡都出現過。第一次紀錄的是基礎配置規則，第二次是某種特殊情境下遇到的坑，第三次是類型不匹配的錯誤修復。這三條碎片分別歸檔，知識圖譜裡則整合成一篇完整的使用規範，標註來源。下次再遇到類似問題，不用翻幾百筆會話紀錄，直接查對應頁面就行了。

分層隔離，減少連鎖反應

0_原始文件 不碰，1_會話碎片 按日期歸檔不改，2_知識圖譜 可以隨意增改。這個分層在實踐中很有用：

• 原始文件 是唯讀層。不管丟什麼資料進去，LLM 只讀不改。這保障了原始資料的完整性。
• 會話碎片 是歸檔層。按日期分子目錄，每個檔案用 session_id 加主題命名。session_id 唯一，不會衝突。日級目錄的好處是一個目錄下不會堆幾百個檔案，Obsidian 開啟的時候也不會卡頓。這些碎片檔案就像 git 的 commit log，是原始紀錄，不輕易改動。
• 知識圖譜 是可讀寫層。LLM 在這裡增刪改查。批次更新某個概念的描述，只需要改知識圖譜裡的頁面，不需要翻碎片檔案。索引和知識圖譜的編號一一對應，改了檔案名稱的話只需要同步更新 index.md。
• 規則檔案（AGENTS.md） 也是獨立維護的。實踐中發現某個流程少了一步、或者格式約定不夠清楚，直接改 AGENTS.md。規則變了，下次跑工作流程時 LLM 就會按新規則來。改完在 log.md 裡記一筆，日後有問題可以追溯是什麼時候改的、為什麼改。

自我檢視是必選項，不是選配

一開始我以為知識圖譜建好了就能一直用下去，不需要維護。事實不是這樣。

知識頁面越長越多，連結關係會越來越複雜。有些頁面可能只在索引裡出現過，但從來沒被其他知識頁面引用到——這就是孤立頁面。有些概念可能在好幾個頁面裡被反覆提到，但一直沒給它獨立建頁。有些 Wikilink 指向的檔案名稱變了，連結就斷了。

所以我每次批次添加新知識之後，都會跑一次 /my-wiki-think。它掃一遍所有頁面，告訴我哪些地方有問題。確認問題之後，我來決定怎麼處理——合併重複內容、補建遺漏頁面、修復斷鏈。

這有點像程式碼審查。你寫程式碼的時候覺得沒問題，跑了一遍 linter 之後才發現變數名拼錯了、某個 import 用不到、兩個函數的邏輯互相覆蓋。知識圖譜也一樣，不檢查的話問題會一直累積。

人的角色是架構師，不是編輯

LLM 能做的事：讀取、生成、連結、修復、編號、更新索引。

LLM 不能做的事：判斷哪些知識值得沉澱、哪些重複內容該合併、哪些新概念該獨立成頁、遇到衝突時該保留哪個。

它執行，我決定。

這一點和 Karpathy 說的分工完全一致。人在整個系統裡的角色不是變輕了，而是從「寫文件的人」變成了「管文件的人」——篩選來源、引導分析、提出好問題、思考這些知識意味著什麼。剩下那些機械性工作，交給 LLM 去處理。

Obsidian 的定位

我原本就用 Obsidian 做本地筆記。My-Wiki 建好之後，Obsidian 的角色變成了瀏覽器和編輯畫面。

知識圖譜裡的頁面是純 Markdown 檔案，Obsidian 可以直接開啟。Wikilink 用的是 [[頁面標題]] 格式，Obsidian 也能正常識別和跳轉。開啟 Obsidian 的圖譜檢視模式，能看到所有知識頁面之間的連結關係，哪個頁面是核心、哪些在邊緣，一目了然。

Obsidian 負責呈現、搜尋、手動編輯——LLM 負責生成和維護。 兩套工具不是替代關係，而是互補關係。

資料同步

知識圖譜全部是純 Markdown 檔案，天然適合版本管理和同步。我用 ZeroTier 組網，透過 Syncthing 在不同設備之間即時同步整個 my-wiki 目錄。不管是在公司電腦、家裡的 Mac，還是筆電上，都能讀到最新的知識頁面，不用擔心資料只存在某一台機器上。

現在的狀態

知識圖譜按模組分組編號——知識庫與系統、計畫和工作流程、微服務和架構、開發和工具鏈、維運和環境。每個頁面都有摘要、有標籤、有來源追溯。

開啟 Obsidian 讀取整個 my-wiki 目錄，就能看到完整的關聯圖譜。哪個頁面引用了哪個、哪個概念被哪些專案用到、從哪個會話碎片提煉的，一目瞭然。