校準
「校準」（calibration）是 LLM Wiki 這種知識庫模式的第二種維護機制，跟 Lint 並列、互不隸屬，2026-08-15 於 規則品質與判準「二十」定義。這頁記的是這個概念本身——通用於任何 AI 維護的個人 wiki，不限 DragonsHoard 這個實例；DragonsHoard 自己套用這個概念的決策脈絡仍歸建設歷程頁，不重複記在這裡。
跟 Lint 的差異：兩種不同的失效類型
wiki 可以想成使用者心智與外部世界在某個時間點的快取（cache）。Lint 查的是快取內部一致性——矛盾說法、被新來源推翻的舊主張，本質是「另一段文字跟這段文字對不上」，AI 靠比對語料庫本身就查得到。校準查的是另一種完全不同的失效：文本內部沒有任何矛盾訊號，內容自己讀起來通順自洽，但因時間流逝或使用者想法／外部世界已經改變，不再服務使用者現狀。判斷依據不在語料庫裡，只存在使用者當下腦中或外部現實——AI 讀十遍語料庫也讀不出來，注定只有快取的主人自己對照活的來源才校準得回來。這個前提預設「當初記的沒記錯」，不重新檢查記錄品質（那是 ingest 當下該顧好的事），純粹檢查「當初對、現在還對不對」的時間軸漂移。
兩個子類
- 內容認同漂移：內容還真不真、使用者還認不認同——例如某個想法種子已經不熱了、某頁對現況的描述已經跟使用者現在的認知脫節。
- 結構適配漂移：內容依然有效、使用者也還認同，但呈現／組織方式現在不再好用——例如已經整理好的內容，換了個角度看會想用不同的編排方式呈現。
（一度考慮過第三子類「優先順序漂移」——內容還真，但在使用者生活裡的份量變了——討論後判斷不需要獨立，併入上述兩類即可。這兩個子類不排除以後還有更多，之後遇到不屬於這兩類的案例再擴充，不用現在窮舉。）
明確排除的情況
同主題待整理筆記在捕捉區（例如 DragonsHoard 的 chaos/白板.md）持續堆積，不算校準要處理的失效——那是還沒走過 Ingest 管線的原料，談不上「已記錄內容失效」，不需要「當初記的沒錯」這個前提，屬於既有 Ingest 工作流程本身的積壓，是另一個問題。
目前的執行方式（尚未真正跑過）
校準這個機制剛被定義出來，還沒有實際執行過一次，所以這裡只能記初步構想，不是成熟流程：讀過現行的規則文件（DragonsHoard 是 CLAUDE.md）、粗看各頁面是否仍符合各自的範圍分類（不深看）、整理捕捉區找出已經處理過或不再需要的內容決定歸檔或刪除、評估時間軸紀錄（DragonsHoard 是 log.md）是否需要歸檔。
AI 可以輔助掃過提供建議，但角色只能是輔助——提供中性的結構性資訊、幫忙掃視——不能取代使用者的判斷。這裡有個容易誤踩的邏輯陷阱：校準這整個類別存在的前提就是「AI 沒有能力判斷什麼可能失效」，如果讓 AI 先用 proxy 訊號（自我標記不確定的條目、多久沒更新等）篩出候選清單，篩選本身已經是那個 AI 做不到的判斷，等於繞了一圈又踩回同一個坑。
細節分工留待實際跑過幾次校準、有真實經驗後再收斂，這次不預先設計成熟流程。
頻率
無固定週期，使用者自行決定，完全看心情觸發——不像 Lint 綁在 commit 動作上有固定觸發點。
相關頁面
- 規則品質與判準「二十」— 這個概念的原始定義過程與完整討論
- 知識庫建設哲學 — 「用可回溯性換取寬鬆約束」等相關的底層信念
- LLM Wiki 與 RAG 的差異 — 同主題資料夾的第一篇，LLM Wiki 模式本身的技術定位
- AI 輔助開發驗證流程 — 概念相鄰但不同：校準查的是「wiki 內容有沒有跟現實脫節」，那頁講的是「AI 寫的程式碼有沒有被驗證過」
- iThome 第二十三篇——CLAUDE.md／skills 大改回顧 — 結構適配漂移的具體案例：規則品質已磨利，但規則間的分工關係（誰讀什麼、放哪一層）才是真正失效的地方