知識庫怎麼建：個人筆記、團隊 wiki、AI 知識庫的四個共同問題
個人筆記、團隊 wiki、給 AI 用的知識庫，差在讀者是誰：未來的自己、同事、模型。三種都要回答收什麼、怎麼整理、怎麼找到、誰來維護。個人收藏的研究發現，「找」多半是找回自己看過的東西；企業 wiki 的研究則看到，負責整理或代寫的人一離開，內容就開始變亂、過時。
20 篇文章
知識庫怎麼建
同一套問題走三遍：給未來的自己（個人筆記）、給同事（團隊 wiki）、給模型（RAG 用的 AI 知識庫）。每段都回答收什麼、怎麼整理、怎麼找到、誰來維護，方法作者的主張和實證研究分開寫。
系列導讀
收什麼：收集不等於知識庫
決定一則資訊收不收，按順序問三句：說得出具體用途嗎、之後搜得回來嗎、寫得出一句自己的話嗎。說不出用途就不留；搜得回來的原文只留連結，搜不回來的存副本；寫得出那句話才進知識庫，寫不出就放進待讀清單。收件匣每週清空。背後的原因是：收不收有兩種錯，多收會把重要的東西淹沒，漏收之後要重找，只把門檻調鬆或調緊，只是把一種錯換成另一種。
放哪裡：PARA、Johnny.Decimal，與到底要不要分資料夾
自己建的檔案，研究一再發現人主要靠點資料夾找回，搜尋工具變好也沒改變；標籤用的人很少，用了也多半只貼一個。所以筆記值得分類，但每則有一個主要的家就好，結構別太深、資料夾別太滿。PARA 依「離手上的事多近」分四類，Johnny.Decimal 每層最多十個、用編號固定位置；兩者的數字都是作者的經驗，不是實驗結果。
怎麼連：Zettelkasten、Evergreen notes 與 MOC
讀完這篇，你能把一篇讀書摘要改寫成兩三則可以互相連結的筆記，並在筆記多起來時建一張地圖筆記（MOC）。做法歸成四個原則：一則筆記只講一個概念、依概念不依書寫、用自己的話寫、每條連結寫出為什麼連。這套做法源自 Luhmann 的卡片盒；研究支持「自己產生比只讀記得牢」，但我找不到可信的對照實驗測過 Zettelkasten 本身。
選筆記工具：Obsidian、Notion，與換工具時資料帶不帶得走
選筆記工具前先問五件事：檔案能不能用別的程式打開、連結改名會不會斷、搜尋、多裝置同步、離線能不能用。Obsidian 的筆記就是本機一個資料夾裡的 Markdown 檔，但區塊連結這類語法離開 Obsidian 就點不開，iPhone 上官方建議的同步方式也只有兩種。Notion 的資料庫好用，但匯出時只能帶走一個檢視、callout 會變成 HTML，匯出的東西也不能直接上傳回去還原。換工具之前，先匯出一次、用別的程式打開看看。
維護：筆記怎麼不在三個月後荒廢，以及哪些事交給 LLM
排一個 30 分鐘的每週回顧：清收件匣、處理結束的專案、從一張 MOC 挑一個問題往下想。摘要不必排時間，碰到才加一層。LLM 可以幫你找重複、建議可能相關的筆記、把你先寫好的重點擴寫成句子；那一句自己的話、判斷什麼重要、刪不刪，留給自己。一項 30 人的研究比較三種 AI 協助，AI 直接給完整筆記的那組學得最少，也最少修改。
團隊知識庫為什麼會爛掉，以及要寫哪幾種文件
團隊 wiki 會爛掉，研究看到的主要是三件事：缺漏和過時比寫錯更常被抱怨、寫的人沒時間或離職了、主管和實際寫的人要的東西不一樣。不是所有 wiki 都會爛：寫的人自己也是讀的人，或文件解決的是一個明確的問題時，比較撐得住。文件可以照 Diátaxis 分成四種：教學、操作指南、參考資料、說明，用兩個問題判斷一份文件該是哪一種，就能看出團隊缺哪一類。
資訊架構：團隊 wiki 要按部門分還是按任務分，以及怎麼驗證
團隊 wiki 常見的爭論是按部門分還是按任務分。研究的答案比想像中保守：熟悉組織圖的員工用按部門分的內網反而比較快，標籤取得好不好的影響也比分類方式大得多。比較穩的做法是：主結構選一個每頁都找得到負責人的分法，再加幾頁按任務整理的入口頁、只放連結；頁面標題寫讀者會搜的字。動手分之前用卡片分類找出讀者怎麼想，分完用樹狀測試驗證找不找得到。
寫給同事看：how-to 模板、決策紀錄，與寫少一點
團隊文件要長得差不多、看得懂，靠的是兩份模板和一條原則。原則是寧可少而新鮮：Google 的文件指南說，少量但新鮮正確的文件，勝過大量年久失修的文件，別處有的就連過去。how-to 模板照「先決條件、步驟、怎麼確認成功、出問題找誰」排；一項研究裡，照模板改寫的安裝說明在讀者評分的十個面向中有八個較好。決策紀錄（ADR）記下當時為什麼這樣決定，推翻時不刪、標成「已被取代」並連到新決定。研究也看到 ADR 常常試了沒繼續、「考慮過的選項」那段問題最多，常常沒寫或寫錯地方，所以模板要短，那一段要留著。
維護責任：誰負責、多久確認一次、什麼時候刪
文件過時是常態，而且不會報錯。GitHub 最熱門的專案裡，八成曾在文件裡留下指向已刪除程式碼的引用。維護有四種做法：每頁掛一個負責的角色、設驗證到期、改流程時同一個變更裡改文件、在被用到的時候順手改。每一種都有失靈的方式：負責人離職、到期通知被當垃圾信、規定在但沒人照做、沒人用的文章永遠沒人檢查。刪除的原則是先刪確定錯的，正確但少用的封存。讀完你能替團隊訂一張維護規則表：文件類型、負責角色、確認週期、刪除條件。
找得到：用搜尋紀錄找出缺口，以及開始讀團隊文件的 AI
同事搜不到，多半不是沒寫：一間大學圖書館的 50 筆零結果查詢只有一成是真的沒有。用三到六個月的搜尋紀錄把缺口分成找不到、不存在、用詞不同，先改標題、設同義詞；給 AI 看的 AGENTS.md 也一樣要精簡、要維護、要先評估，一項評估發現它們整體沒提高成功率，成本卻增加約兩成。
給 AI 讀的知識庫差在哪：動手前先寫測試題
人看得懂的 wiki，AI 還是可能答錯：它看到的是被切出來的幾段文字，看不到導覽、標題層級和前後文。所以動手建 RAG 之前，先寫一份測試題：每題附上答案和出處段落，並刻意放幾題文件答不了的。Azure 的 RAG 指南把這一步跟內容分析平行做；一項研究發現，只用 AI 生成的題目評估，會高估檢索表現 29 到 37 個百分點，所以要混入真實使用者的問題。知識庫小於約 500 頁時，也可以先不做 RAG，整份放進提示裡。
盤點來源：哪些文件該進 AI 知識庫，信哪個版本
共用硬碟整包匯進去，是 AI 知識庫最常見的開頭，也是最常見的錯。舊版和現行版一起被撈到時，模型會混在一起答：一項研究裡，現行資料明明有被撈到，旁邊只多一段過時資料，總分就降了兩成多。先做一張來源盤點表，記下每個來源的負責人、更新頻率、存取限制和處理方式；第一批只收一個工作流程、治理良好的來源；同一份文件只收現行版，舊版要收就標版本與失效日期。匯入之後核對檔案數，因為有的連接器權限不足時一個檔案都不匯，也不報錯。
解析與清洗：PDF、表格、掃描檔轉成文字時，哪些東西會悄悄壞掉
文件轉成文字時，壞掉的地方通常不會報錯：多欄的段落接錯順序、表格的合併儲存格被攤平、頁首頁尾混進內文、掃描檔的錯字、圖片和刪除線消失。OCR 的準確率高也不代表 RAG 答得好：一項研究裡，帶刪除線和顏色標記的文件 OCR 分數 82.9%，問答卻只答對 52.8%。比起換工具，怎麼切塊影響更大：同一份轉換結果，改成依標題階層切塊並附上標題路徑，表格題從 66.6% 升到 99.8%。所以解析完一定要抽檢，對照原檔看這幾種壞法。
安全：收進知識庫的文件，會不會洩漏個資或反過來指揮 AI
收進知識庫的文件可能夾著個資，也可能藏著寫給 AI 的指令；後者已在 Slack AI 和 Microsoft 365 Copilot 上被示範過。只在系統提示叫模型忽略效果很小，比較穩的是入庫時加個資與指令兩道關卡，再限制模型能做的動作。偵測工具都不保證找全，每一層都只是降低風險。
結構與 metadata：除了內文，每份文件還要記哪些欄位
metadata 有三種用途：回傳給人引用、參與搜尋、檢索前過濾；型號、年份、地區這種精確條件要放在欄位裡，一項研究把公司和年份寫在每段前面，前五名找到正確段落的比例從 33% 升到 55%。過濾用的欄位從來源系統取值、用固定選項、日期存成數字，不要讓 LLM 自由產生。
切塊與索引：要切多大、用什麼搜，以及怎麼知道選對了
建索引要做三個決定：切塊的單位、用關鍵字還是向量還是兩者都用、用哪個 embedding 模型。這三個都是半永久的選擇，改了就要整批重建。研究的建議偏保守：語意切塊沒有一致比較好，按句子或按文件結構切通常就夠；overlap 的效果很小、依設定而定。繁體中文的一項研究裡，正確段落排在第一名的比例，只用向量搜尋 57%，關鍵字搜尋 76%，兩者混合 81%。不要憑感覺選：用 order 11 的測試題比較兩種設定，一次只改一件事。
權限：怎麼確保 AI 不會把 A 部門的文件答給 B 部門
權限要在檢索時就過濾：每段文字帶著能看它的群組，查詢帶著使用者的群組，不符合的根本不進候選，而不是讓模型讀了再叫它別說。AI 不會新增權限，但會讓本來分享得太寬的文件變得一問就找得到，所以上線前要先整理過度分享。權限改了，索引不一定跟著改：有的連接器只在完整爬取時更新權限，最多延遲一天。過濾也有代價：條件很嚴時，某些向量資料庫會回傳不足的結果。上線前寫一題越權測試放進測試題。
更新與刪除：文件改了、刪了，AI 知識庫怎麼跟上
文件改了或刪了，索引不會自己跟上。比較穩的增量同步是：用內容雜湊判斷哪些文件變了，只重做變了的；刪除要清到每一個存放處，包括全文索引和向量庫。很多工具預設不處理刪除，刪除和更新也可能要過一段時間才生效。為什麼要刪乾淨：一篇預印本把一份過時文件放進上下文，兩個小模型原本答對的醫學題有三到四成被翻錯；要求模型「照文件回答」時，比例升到三分之二到四分之三。
評估與上線：怎麼知道 AI 知識庫好用，上線後怎麼持續變好
評估要分兩層：檢索有沒有找到出處段落，回答有沒有依據段落、答得對不對。只看回答會被騙：一項研究發現，給的資料不足以回答時，模型仍有三到六成答對，靠的是它自己的知識，換成只有你們公司答得出的問題就會壞。用 order 11 的測試題兩層都評，越權題和答不了的題也要評；LLM 當評審要跟人工抽樣校準。上線後，把轉人工、被抱怨的對話整理成失敗案例，交回文件負責人修，再加進測試題。