知識庫怎麼建：個人筆記、團隊 wiki、AI 知識庫的四個共同問題
個人筆記、團隊 wiki、給 AI 用的知識庫，差在讀者是誰：未來的自己、同事、模型。三種都要回答收什麼、怎麼整理、怎麼找到、誰來維護。個人收藏的研究發現，「找」多半是找回自己看過的東西；企業 wiki 的研究則看到，負責整理或代寫的人一離開，內容就開始變亂、過時。
#knowledge-management
14 篇文章選筆記工具：Obsidian、Notion，與換工具時資料帶不帶得走
選筆記工具前先問五件事：檔案能不能用別的程式打開、連結改名會不會斷、搜尋、多裝置同步、離線能不能用。Obsidian 的筆記就是本機一個資料夾裡的 Markdown 檔，但區塊連結這類語法離開 Obsidian 就點不開，iPhone 上官方建議的同步方式也只有兩種。Notion 的資料庫好用，但匯出時只能帶走一個檢視、callout 會變成 HTML，匯出的東西也不能直接上傳回去還原。換工具之前，先匯出一次、用別的程式打開看看。
放哪裡：PARA、Johnny.Decimal，與到底要不要分資料夾
自己建的檔案，研究一再發現人主要靠點資料夾找回，搜尋工具變好也沒改變；標籤用的人很少，用了也多半只貼一個。所以筆記值得分類，但每則有一個主要的家就好，結構別太深、資料夾別太滿。PARA 依「離手上的事多近」分四類，Johnny.Decimal 每層最多十個、用編號固定位置；兩者的數字都是作者的經驗，不是實驗結果。
寫給同事看：how-to 模板、決策紀錄，與寫少一點
團隊文件要長得差不多、看得懂，靠的是兩份模板和一條原則。原則是寧可少而新鮮：Google 的文件指南說，少量但新鮮正確的文件，勝過大量年久失修的文件，別處有的就連過去。how-to 模板照「先決條件、步驟、怎麼確認成功、出問題找誰」排；一項研究裡，照模板改寫的安裝說明在讀者評分的十個面向中有八個較好。決策紀錄（ADR）記下當時為什麼這樣決定，推翻時不刪、標成「已被取代」並連到新決定。研究也看到 ADR 常常試了沒繼續、「考慮過的選項」那段問題最多，常常沒寫或寫錯地方，所以模板要短，那一段要留著。
資訊架構：團隊 wiki 要按部門分還是按任務分，以及怎麼驗證
團隊 wiki 常見的爭論是按部門分還是按任務分。研究的答案比想像中保守：熟悉組織圖的員工用按部門分的內網反而比較快，標籤取得好不好的影響也比分類方式大得多。比較穩的做法是：主結構選一個每頁都找得到負責人的分法，再加幾頁按任務整理的入口頁、只放連結；頁面標題寫讀者會搜的字。動手分之前用卡片分類找出讀者怎麼想，分完用樹狀測試驗證找不找得到。
維護責任：誰負責、多久確認一次、什麼時候刪
文件過時是常態，而且不會報錯。GitHub 最熱門的專案裡，八成曾在文件裡留下指向已刪除程式碼的引用。維護有四種做法：每頁掛一個負責的角色、設驗證到期、改流程時同一個變更裡改文件、在被用到的時候順手改。每一種都有失靈的方式：負責人離職、到期通知被當垃圾信、規定在但沒人照做、沒人用的文章永遠沒人檢查。刪除的原則是先刪確定錯的，正確但少用的封存。讀完你能替團隊訂一張維護規則表：文件類型、負責角色、確認週期、刪除條件。
找得到：用搜尋紀錄找出缺口，以及開始讀團隊文件的 AI
同事搜不到，多半不是沒寫：一間大學圖書館的 50 筆零結果查詢只有一成是真的沒有。用三到六個月的搜尋紀錄把缺口分成找不到、不存在、用詞不同，先改標題、設同義詞；給 AI 看的 AGENTS.md 也一樣要精簡、要維護、要先評估，一項評估發現它們整體沒提高成功率，成本卻增加約兩成。
團隊知識庫為什麼會爛掉，以及要寫哪幾種文件
團隊 wiki 會爛掉，研究看到的主要是三件事：缺漏和過時比寫錯更常被抱怨、寫的人沒時間或離職了、主管和實際寫的人要的東西不一樣。不是所有 wiki 都會爛：寫的人自己也是讀的人，或文件解決的是一個明確的問題時，比較撐得住。文件可以照 Diátaxis 分成四種：教學、操作指南、參考資料、說明，用兩個問題判斷一份文件該是哪一種，就能看出團隊缺哪一類。
維護：筆記怎麼不在三個月後荒廢，以及哪些事交給 LLM
排一個 30 分鐘的每週回顧：清收件匣、處理結束的專案、從一張 MOC 挑一個問題往下想。摘要不必排時間，碰到才加一層。LLM 可以幫你找重複、建議可能相關的筆記、把你先寫好的重點擴寫成句子；那一句自己的話、判斷什麼重要、刪不刪，留給自己。一項 30 人的研究比較三種 AI 協助，AI 直接給完整筆記的那組學得最少，也最少修改。
收什麼：收集不等於知識庫
決定一則資訊收不收，按順序問三句：說得出具體用途嗎、之後搜得回來嗎、寫得出一句自己的話嗎。說不出用途就不留；搜得回來的原文只留連結，搜不回來的存副本；寫得出那句話才進知識庫，寫不出就放進待讀清單。收件匣每週清空。背後的原因是：收不收有兩種錯，多收會把重要的東西淹沒，漏收之後要重找，只把門檻調鬆或調緊，只是把一種錯換成另一種。
怎麼連：Zettelkasten、Evergreen notes 與 MOC
讀完這篇，你能把一篇讀書摘要改寫成兩三則可以互相連結的筆記，並在筆記多起來時建一張地圖筆記（MOC）。做法歸成四個原則：一則筆記只講一個概念、依概念不依書寫、用自己的話寫、每條連結寫出為什麼連。這套做法源自 Luhmann 的卡片盒；研究支持「自己產生比只讀記得牢」，但我找不到可信的對照實驗測過 Zettelkasten 本身。
用 LLM 做知識管理：從 Karpathy 的 llm-wiki 到開源生態全覽
Karpathy 在 2026 年提出 llm-wiki 模式，讓 LLM 主動維護 markdown wiki 而非每次從頭 RAG；目前已有 100+ 開源實作，從本機 CLI 到 serverless Telegram bot 各有差異。
knowledge-pipeline：六層管線幫你的 RAG 做品質管控
一個六層確定性管線，從 URL 擷取到向量嵌入全自動處理，透過八維度評分系統在資料進 RAG 之前就篩掉垃圾。
LLM 知識庫的三種模式：知識庫、經驗庫、部落格
Andrej Karpathy 提出用 LLM 編譯個人知識 wiki 的框架——收集原始資料、LLM 編譯成 .md wiki、對 wiki 做 Q&A、輸出歸檔回 wiki。本文比較三種實踐路線：Karpathy 的知識庫模式、社群的經驗庫模式、以及 quidproquo 的部落格模式。