知識庫建設哲學
建設歷程主頁記的是「什麼時候、為了什麼理由，做了哪個決定」的逐年紀事；這頁記的是把那些決定攤開來看之後，浮現的共同模式——毓文對「為什麼要建一個知識庫、它該長什麼樣子」的底層信念。2026-08-12 由 AI 綜合 CLAUDE.md 全文、架構設計、既有對話記憶整理而成，屬於分析／歸納內容，不是逐字紀錄。
一、外部化是為了解除焦慮，不是為了立刻產出結論
整套 raw → chaos → wiki 的分層，根源是毓文自己的認知模式：「浮上水面的想法不具象化就會沉沒消失」。這個信念過去讓他把「記下來」跟「當場討論完」綁死在一起，導致頻繁跳題。chaos/ 這一層（白板、想法.md）存在的意義，就是把這兩件事拆開——寫一行就能解除沉沒感，不需要當下處理完。混亂層不只是一個資料夾設計，是把他自身的認知模式直接翻譯成架構（見建設歷程「八」）。
二、自己的心得跟外部文章，地位完全對等
CLAUDE.md 明講「使用者自己的創作、理解、心得同樣是原始素材，跟外部文章走同一套 ingest 管線」。這代表 DragonsHoard 不是「讀書筆記庫加一個私人日記」的組合，而是把自我反思、生活狀態變化跟他讀的書、研究的主題，當成同一個知識體系裡地位相同的節點。知識庫記的不是「關於世界的事」，是「關於他跟世界的事」。這條原則本身經歷過一次修正——見建設歷程「三」，AI 一度把自己的創作當例外對待，被毓文直接指出並推翻。
三、「會不會被引用」是價值的唯一判準
不管是建設歷程要不要記、想法要不要整理進 wiki，反覆出現的判斷句都是同一句：「這件事以後會不會被引用/套用，還是做完就沒了」。這是個務實的過濾器——不是在追求記錄的完整性，是在追求記錄的複用率。單次操作、單篇文章進度不值得留痕，因為 git history 已經夠用；只有「以後會重複套用的模式」才值得升格成常青內容（見建設歷程「七」的門檻定義）。
四、系統本身也是知識的一部分（反身性）
「DragonsHoard 建設歷程」被獨立設成一個常青主題、不掛在任何專案下、不會隨專案歸檔——這是不尋常的設計選擇。多數人的知識庫只記內容，毓文連「我怎麼組織知識」這件事本身都在持續記錄、版本化、定案。他在用經營一個活系統的方式在經營這個系統，而不是把它當一次性搭好就不管的工具。這份「知識庫建設哲學」頁本身，正是這個反身性原則的又一層——連「這套系統的底層信念是什麼」都值得沉澱成一頁。
五、用可回溯性換取寬鬆的約束，而不是事前完美防呆
raw 唯讀從技術強制（Windows 唯讀屬性）改成文件約定 + commit 前 git diff 事後偵測，原因寫得很清楚：技術防呆有漏洞（擋得住編輯、擋不住 rm）、還要手動維護，事後偵測配合 git 歷史可回復，反而更可靠（見建設歷程「十二」）。wiki 開放直接編輯、不用唯讀保護也是同一種邏輯。這反映一貫的傾向：不追求「不會出錯」，追求「出錯了看得到、回得去」。
六、交叉引用是「是不是 wiki」的判準，但連結的苦工外包給 AI
CLAUDE.md 明講：頁面互相連結，決定這套東西「還算不算 wiki」，而不只是分類整齊的檔案堆——這是硬性要求，index.md／log.md 則是軟性的、可以寬鬆補的。但這件苦工本身明確劃給 AI（「你負責所有的整理、交叉引用、歸檔等苦工」）。毓文重視的是知識之間的關聯結構，但他認為產生關聯是可以機械化外包的維護工作，自己的稀缺資源要留給讀、想、問、創作。
七、對結構擴張很節制，偏好證明需求後才長出新結構
「結構/系統擴充要節制」、想法先寫一行不主動另開檔案、不主動建議新 skill 除非有具體痛點——這些都指向同一種紀律：先讓真實使用壓力把需求「擠出來」，再回應著長結構，而不是預先設計好一套精緻分類再往裡面塞內容。chaos/想法.md 從「索引＋獨立衛星檔」的兩層結構退回「單一檔案、預設一行摘要」，正是這個原則的實例（見建設歷程「十一」）。
一句話總結
這不是一個「收集資訊」的知識庫，是一個把「捕捉」「消化」「定案」三個認知階段刻意分離、且把系統自身的演化也當作可累積知識的個人認知基礎設施。核心不是內容量，而是有沒有被複用、看不看得到自己怎麼變的軌跡、以及該鬆的地方鬆、該緊的地方緊。
相關頁面
- DragonsHoard 建設歷程 — 本頁分析所本的逐年決策紀事
- 毓文 — 個人檔案，AI 協作規則與決策模式，跟本頁「反身性」「複用判準」等觀察互相印證
- LLM Wiki 與 RAG 的差異 — LLM Wiki 這個模式本身相對於 RAG 的技術定位，跟本頁的個人信念角度互補
- 校準 — 「用可回溯性換取寬鬆約束」的延伸：wiki 內部一致性靠 Lint，wiki 跟活的來源之間的落差靠校準，兩種維護機制互補