Ingest
這頁記的是「Ingest」這個行為本身的通用定義，適用於任何 AI 維護的個人 wiki，不限 DragonsHoard 這個實例。理論化整理誕生於 2026-08-23 一次深度討論——起因是 iThome 鐵人賽 2026 第八篇要把 Ingest 從主角規格重新處理，發現過去對這個行為的理解只停留在操作步驟（讀資料→寫頁面→補連結→更新 index/log），沒有想清楚它的本質跟內部結構。DragonsHoard／iThome 系列自己套用這套理解時的寫作與決策脈絡，歸各自的專案決策歷程頁，不重複記在這裡。
一、Ingest 不是唯一的輸入管道
一個 AI 維護的 wiki，內容進來的管道通常不只一種：
- Ingest（正典管道）：外部素材 → AI 讀取／討論 → 寫進 wiki → 交叉引用 → 更新 index/log。
- Query 產出的新頁面：查詢過程中若某次分析本身有價值，存回去變成新頁面——但通常會用獨立的紀錄類型（例如
query）跟 Ingest 區分，不是同一類事件的紀錄。 - Promote（捕捉區晉升）：內容原本放在不受 wiki 規則約束的隨手捕捉區，之後被判定值得收，正式寫進 wiki——收尾動作（更新 index/log）通常「比照」Ingest，但起點沒有經過「外部素材進 raw/」這一步。步驟定義見 CLAUDE.md「混亂層」一節。
- 使用者直接編輯 wiki：使用者自己動手寫、動手改，不透過 AI。
前三者共享同一組不變的核心動作（見下「三段內部結構」），起點不同不代表行為不同——素材原本放在哪個資料夾，不是判斷「這算不算 Ingest」的依據。
二、真正的分界線：有沒有「消化」
第 4 種（使用者直接編輯）才是唯一真正的例外，而且分界線不在「素材放在哪」，在「誰做了結構化的決定」：使用者直接編輯時，內容進 wiki 已經是成形的，AI 沒有消化的動作可做，頂多事後用 Lint 補交叉引用——被動掃描，不是主動消化。這條線把 Ingest 家族（含 2、3）跟直接編輯明確分開。
三、Ingest 的核心生產線：兩段，不是三段
2026-08-23 修正：原本把消化、結構化、觸發評估並列成「三段」，說法不夠精確。消化的產出會餵給結構化——同一條生產線，依序加工，順序不能反。觸發評估不在這條線上：它的產出（如果真的有產出）不是這個 wiki 頁面的 tags、index.md 條目或連結——完全不影響這些——而是落在生產線之外，另外新增或修改一條規則（見下方「三之二」）。更精確的講法是：Ingest 的核心生產線只有消化→結構化兩段；觸發評估是這個生產線運作時「順便做」的一次獨立風險檢查，跟結構化的實際產出無關。
Ingest 是把「未成形素材」轉換成「服務無痛檢索的結構化知識」的行為，核心生產線分兩段，服務不同目的，且順序不能反：
1. 消化
判斷這則未成形素材對使用者而言「是什麼意思」與「值不值得記下」，判斷依據是使用者自己的脈絡與需求，沒有素材本身以外的客觀標準可對照。 這段的失敗風險是「做錯」，不是「沒做」——消化錯了不只是產出平庸內容，是會污染下一步（結構化的正確性完全依賴消化的判斷）。這段是人機協作：AI 要讀，但「重點是什麼、值不值得記」的判斷權在使用者。
消化本質上不明確，這是判斷權留在使用者手上的原因，不是缺陷：消化正不正確沒有可機械驗證的產出——「這個理解對不對」最終只能歸結到「符不符合使用者自己的意思」，除了使用者自己，沒有第三方（包括 AI）能獨立核對。倒過來看，正因為消化沒辦法被化簡成一套可驗證的產出，才需要留在使用者手上，不能整段交給 AI——如果消化能被機械驗證，它早就該跟結構化一樣變成 AI 的苦工。
消化的正確性在 Ingest 當下無法驗證，只能延後靠 校準（「內容認同漂移」子類）事後核對——校準本身也明講這個前提：「當初記的沒記錯，不重新檢查記錄品質（那是 ingest 當下該顧好的事），純粹檢查當初對、現在還對不對」。消化跟校準因此互補：消化決定「當下記對了沒」（無法即時驗證，只能盡力），校準決定「記錄的東西現在還對不對」（會隨時間漂移，需要使用者定期核對）。
2. 結構化
把消化得到的理解轉換成可被檢索到的具體產出——放進正確位置、接上連結、更新索引。判斷依據是既有的 wiki 結構規則（範圍宣告、命名慣例、交叉引用要求），是客觀、可核對的標準，跟消化剛好相反。 這段直接服務無痛檢索——檢索本身就是一種結構性質，不是內容品質。主要是 AI 的苦工。內容如果有明確的未來使用場景，這段也負責把提醒放進使用者實際會去讀的頁面（例如專案決策歷程裡留一句 pointer）——這仍然是結構化的範圍，不需要另外的機制（見「三之二」）。
只消化不結構化：內容存在，但在無痛檢索的意義上等於不存在，跟丟一份未處理的原始檔案沒有本質差別（找不到，乘以零）。
只結構化不消化：分類、連結這些決定本來就依賴對內容的正確理解，理解錯了，結構化產出的是錯誤的路標——讀者照連結點過去卻文不對題。這比完全沒結構化更糟：沒結構化是「找不到」，結構化錯誤是「製造假的找得到」，會侵蝕使用者對整套檢索機制的信任。
三之二、曾經考慮的第三段：規則觸發（範圍錯誤，已否決）
2026-08-23 再修正：這節原本主張 Ingest 該包含「觸發評估」——講得出未來場景就去 CLAUDE.md／.claude/rules/／skill 新增一條規則。這個結論後來被推翻，是範圍錯誤，不是措辭問題。
幾乎任何一則內容都講得出某個具體的未來使用場景——一份食譜、一段反思，只要肯想都能編出「以後會用到」的理由。如果「講得出場景」等於「該新增規則」，規則數量會隨 Ingest 次數線性成長，CLAUDE.md／.claude/rules/ 遲早膨脹到不可維護。這混淆了兩個不同的系統：內容該不該被記得，是結構化的工作（屬於知識庫）；AI 該怎麼操作，是規則層的事（不屬於知識庫），不該讓前者驅動後者。
回頭核對真實案例：這個系統裡實際被建出來的觸發機制（hoard-query 改手動觸發、hoard-commit 綁 commit 事件），沒有一個源自「ingest 了某則內容」，全部源自系統自己的運作流程出錯。最初用來論證這節的 PDF 案例，從頭到尾只是一個假設情境，從未真的因它新增過任何規則。
修正後的分工：
- 一般內容「未來會不會被想起來」，答案在結構化本身——交叉引用、把提醒放進使用者實際會去讀的頁面（例如專案決策歷程裡留一句 pointer），不動規則層。
- 系統自己該怎麼運作的洞察（不是內容，是流程/結構本身要不要改），走既有的獨立管道——DragonsHoard建設歷程，有自己的判斷門檻，Ingest 不需要重複處理。
原始論證留著當對照：AI 沒有跨對話的連續記憶是真問題——每次對話都是從被載入的規則文件重新拼湊出「現在知道什麼」，人類靠聯想記憶、習慣性翻資料夾這類模糊機制運作，AI 完全沒有對應物。但「因此 Ingest 該長出規則觸發」是從真問題推出的錯誤解法；正確解法是把重要內容放進結構上會被讀到的地方，不是把它變成一條新規則。真實案例（AI 提議把觸發點放在錯誤的子目錄規則檔，因為誤判了真實寫作流程的風險視窗）仍然成立，見 觸發機制演變「十七」——只是它證明的是「當時系統流程真的有問題」，不是「Ingest 該多一段」。
CLAUDE.md 對應的規則已同步刪除，過程中連帶收斂出一套通用的「規則有效性判準」（觸發要綁在可機械判斷的事件上、不依賴 AI 語意判斷；執行後要有具體可驗證的產出）跟「精簡性判準」，寫進 CLAUDE.md「CLAUDE.md 寫作準則」一節，用來檢查所有規則，不限這一條。推導過程見 規則品質與判準「二十五」、觸發機制演變「二十六」。
四、離開 AI，Ingest 會怎樣
Ingest 這個行為本身不會消失——這本來就是人類做了幾十年的事（傳統筆記法、Zettelkasten，本質上都是手動版的 Ingest）。離開 AI，改變的是結構化那一段的苦工會整個彈回使用者身上：讀、消化這件事人類本來就會做，真正壓垮傳統 PKM 的是持續維護結構（整理、交叉引用、歸檔）的成本，而且這個成本會隨內容量增長而不成比例地上升。
五、採集（Capture）：進 Ingest 之前的四個特性
素材要能真正被 Ingest 處理到，前提是使用者願意先把它留下來。採集——讓念頭、素材進到系統裡的第一步（對應 DragonsHoard 的 raw/／chaos/／materials/）——本身有四個核心特性：
- 低摩擦：好的採集入口要夠快。想到一件事，如果要開電腦、開資料庫、選分類、填好幾個欄位，這套採集系統很快就會被放棄。手機分享、語音、快速筆記、瀏覽器擴充套件、AI 助手，都是在降低這個成本。
- 有選擇：不是「看到有用的就存」——網路上幾乎任何東西都可能有用，這個標準太寬。更合理的篩選是「它跟我現在關心的問題有沒有關係？」。
- 保留脈絡：只存一句話（例如「Knowledge is information in context」），半年後可能完全不記得當時為什麼存。連同來源、日期、當時在研究什麼一起留下，之後才有可用性——採集留下的其實不只是「內容」，還包括內容的 context。
- 允許先粗糙：採集階段不需要處理得漂亮。「這東西值得留下」和「已經整理成完整知識」是兩回事，混為一談會讓採集這一步變重，反而破壞低摩擦。
這四個特性描述的是素材進入系統的門檻，跟「三、核心生產線」描述的消化→結構化是接續但不同的階段：採集決定「留不留」，Ingest 決定「留下來的東西怎麼變成可檢索的知識」。