Lint
這頁記的是「Lint」這個維護機制本身該怎麼設計的通用判準，適用於任何 AI 維護的個人 wiki，不限 DragonsHoard 這個實例。2026-09-15 一次討論刻意不預設現行規格是對的答案，改成先從「什麼樣的 Lint 設計合理、有效」建立判準，再回頭檢驗現行設計找漏洞——這頁記的是推導出來的判準本身；DragonsHoard 自己套用這套判準的決策脈絡與具體結果歸建設歷程，不重複記在這裡。
一、本質定位：只處理機械可判斷的結構檢查
Lint 只處理「機械可判斷、不需要語意或脈絡理解」的結構檢查——這是它跟 Ingest／Query 的分工邊界，也是判斷任何一項該不該歸 Lint 管的第一道濾網。需要語意理解或脈絡判斷的失效類型不符合這條線，見第四節。
二、觸發時機的判準
四條：
- 要卡在「修正還便宜」跟「修正變貴」的分界點上——這是選任何觸發點的唯一正當理由。
- 觸發本身要可靠、不能靠自覺或記性——「定期」「有空就做」這類設計容易退化成「可以不做」。
- 不能太頻繁到打斷正常寫作／探索的節奏——中間狀態暫時違反不變條件是正常的，不該每次都被打斷。
- 不能太稀疏到讓違規累積到無法追溯。
保證方式是獨立於時機的另一個維度：就算觸發時機選對了，還要另外問「這個觸發真的會被執行嗎」。「AI 每次都會照做」是文字承諾，不是機制保證，任何繞過 AI 的操作路徑都不受它約束。純機械可判斷的檢查理論上都能寫成確定性腳本，掛進 host 層級真正的強制點，讓觸發不依賴 AI 的記性或誠實——這呼應同一個系統已經驗證過的原則「host 層級機制優先於 agent 層級文字承諾」，具體案例見 觸發機制演變「五十六」「五十七」。
三、檢查對象的判準
四條：
- 必須是純機械可判斷的，不需要語意或脈絡理解。
- 必須對應到某個明確被承諾過的保證，不是「感覺應該不錯」的內容品質期待。
- 必須是「單看一個頁面本身看不出來，需要跳出去看全局才會發現」的錯誤——否則寫作當下就能自己注意到，不需要 Lint。
- 檢查成本要跟知識庫規模相稱：規模小時全域重掃可以忽略成本；規模變大後，同一個檢查目標未必需要同一種做法——例如「這次異動有沒有製造孤兒頁面」不需要每次重建全庫連結圖，只需要看這次改動實際牽動到的範圍就夠。
四、為什麼矛盾／過時說法不歸 Lint 管
這兩類失效本質上需要語意理解，不符合第一節的判準。勉強要做的話只有三種可能設計：全庫兩兩比對（成本高、雜訊高）、縮小到同主題比對（本質上就是在做 Ingest／Query 的工作，不是 Lint）、依賴 Ingest／Query 本來就在做的事順手發現（例如收錄時的有限範圍矛盾比對、查詢時語意理解的偶然副作用）。不需要為這類失效另立獨立機制。
這個結論呼應一個更底層的立場：矛盾／過時與否本身就是需要人（或 AI 在場、被要求時）當下判斷的事，包裝成自動化保證，等於預設了一個不存在的「隨時可被機械驗證的正確答案」，這個預設本身就是錯的。這類失效真正對應的檢查機制是 校準，不是 Lint——兩者的分工邊界正是「文本內部有沒有可比對的訊號」：Lint 抓得到的失效，語料庫內部本身就有矛盾訊號；校準要抓的失效，文本自己讀起來通順自洽，判斷依據只存在使用者當下腦中或外部現實，AI 讀語料庫也讀不出來。