🎯 什麼情境該想到我
當你「的知識庫長大了，開始出現前後矛盾、孤兒頁、過時說法，或者跨好幾次工作階段後忘了上次做到哪」的時候。
⚙️ 怎麼用（步驟 / 公式）
核心想法：wiki 一長大就會自然腐化。定期讓 LLM 當檢查員掃一遍，就像程式碼的 lint。
健檢清單（原文列的六項）：
| 檢查項 | 怎麼查 | 怎麼修 |
|---|---|---|
| 頁面間的矛盾 | 同一概念在不同頁的定義、數字不同 | 回原始來源核對，改掉錯的那頁，或註明兩種說法 |
| 被新來源推翻的過時說法 | 較新的來源與舊頁結論衝突 | 更新舊頁，標註查證日期 |
| 孤兒頁（沒有任何連入） | 掃描所有 wikilink，找出沒被任何頁引用的頁 | 從相關頁或索引連入，或判斷該刪 |
| 被提到卻沒有自己頁面的重要概念 | 同一個詞在多頁出現，但沒有對應頁 | 建頁 |
| 缺漏的交叉連結 | 兩頁講相關的事卻沒互連 | 補連結（只連真正相關的） |
| 可以補的資料缺口 | 頁面寫「待查」或內容太薄 | 上網查證後補上 |
LLM 在健檢時也很適合提議新問題與新來源，順便決定下一步要讀什麼。
能自動化的先腳本化：斷連結、孤兒頁、frontmatter 欄位缺漏、trigger 重複，用幾行腳本就查得出來，每次健檢固定跑。矛盾、過時、缺口這類需要判斷的，才交給 LLM 逐頁看。
配一個只追加的操作日誌 log.md：
## [2026-04-02] ingest | Article Title
## [2026-04-05] query | 某某比較
## [2026-04-10] lint | 修 3 個斷連結、2 處矛盾
每筆用固定開頭，就能用 grep "^## \[" log.md | tail -5 看最近 5 筆。它讓你和 LLM 知道 wiki 怎麼演化到現在，跨工作階段接手時不必重新摸索。
🧪 我實際套用的紀錄
- 2026-09：本庫十階段深度健檢。每階段固定跑斷連結、trigger 撞車、來源↔工具雙向連結檢查，並把進度記在
_meta/深度健檢.md（相當於分主題的日誌）。
⚠️ 注意 / 什麼時候不適用
- LLM 健檢也會誤報：例如表格裡的
\|、canvas 嵌入被誤判成斷連結。腳本的輸出要人看一眼再修。 - 修矛盾要回原始來源：不要讓 LLM 在兩頁之間「挑一個看起來合理的」，要回原文核對。
- 補連結寧缺勿濫：為了消滅孤兒頁而硬連，只會讓連結失去意義。
- 小型知識庫（幾十頁）人工瀏覽就夠了，不必排定期健檢。
🔗 相關工具
- 工具-讓LLM維護的個人Wiki —— 整套模式，這張是其中的 Lint 步驟
- 工具-把好答案存回知識庫 —— 存回的推論頁最容易跟新來源矛盾，健檢時要優先看