知識庫怎麼建：個人筆記、團隊 wiki、AI 知識庫的四個共同問題
個人筆記、團隊 wiki、給 AI 用的知識庫，差在讀者是誰：未來的自己、同事、模型。三種都要回答收什麼、怎麼整理、怎麼找到、誰來維護。個人收藏的研究發現，「找」多半是找回自己看過的東西；企業 wiki 的研究則看到，負責整理或代寫的人一離開，內容就開始變亂、過時。
#wiki
6 篇文章寫給同事看：how-to 模板、決策紀錄，與寫少一點
團隊文件要長得差不多、看得懂，靠的是兩份模板和一條原則。原則是寧可少而新鮮：Google 的文件指南說，少量但新鮮正確的文件，勝過大量年久失修的文件，別處有的就連過去。how-to 模板照「先決條件、步驟、怎麼確認成功、出問題找誰」排；一項研究裡，照模板改寫的安裝說明在讀者評分的十個面向中有八個較好。決策紀錄（ADR）記下當時為什麼這樣決定，推翻時不刪、標成「已被取代」並連到新決定。研究也看到 ADR 常常試了沒繼續、「考慮過的選項」那段問題最多，常常沒寫或寫錯地方，所以模板要短，那一段要留著。
資訊架構：團隊 wiki 要按部門分還是按任務分，以及怎麼驗證
團隊 wiki 常見的爭論是按部門分還是按任務分。研究的答案比想像中保守：熟悉組織圖的員工用按部門分的內網反而比較快，標籤取得好不好的影響也比分類方式大得多。比較穩的做法是：主結構選一個每頁都找得到負責人的分法，再加幾頁按任務整理的入口頁、只放連結；頁面標題寫讀者會搜的字。動手分之前用卡片分類找出讀者怎麼想，分完用樹狀測試驗證找不找得到。
維護責任：誰負責、多久確認一次、什麼時候刪
文件過時是常態，而且不會報錯。GitHub 最熱門的專案裡，八成曾在文件裡留下指向已刪除程式碼的引用。維護有四種做法：每頁掛一個負責的角色、設驗證到期、改流程時同一個變更裡改文件、在被用到的時候順手改。每一種都有失靈的方式：負責人離職、到期通知被當垃圾信、規定在但沒人照做、沒人用的文章永遠沒人檢查。刪除的原則是先刪確定錯的，正確但少用的封存。讀完你能替團隊訂一張維護規則表：文件類型、負責角色、確認週期、刪除條件。
找得到：用搜尋紀錄找出缺口，以及開始讀團隊文件的 AI
同事搜不到，多半不是沒寫：一間大學圖書館的 50 筆零結果查詢只有一成是真的沒有。用三到六個月的搜尋紀錄把缺口分成找不到、不存在、用詞不同，先改標題、設同義詞；給 AI 看的 AGENTS.md 也一樣要精簡、要維護、要先評估，一項評估發現它們整體沒提高成功率，成本卻增加約兩成。
團隊知識庫為什麼會爛掉，以及要寫哪幾種文件
團隊 wiki 會爛掉，研究看到的主要是三件事：缺漏和過時比寫錯更常被抱怨、寫的人沒時間或離職了、主管和實際寫的人要的東西不一樣。不是所有 wiki 都會爛：寫的人自己也是讀的人，或文件解決的是一個明確的問題時，比較撐得住。文件可以照 Diátaxis 分成四種：教學、操作指南、參考資料、說明，用兩個問題判斷一份文件該是哪一種，就能看出團隊缺哪一類。