Inbox 會堆滿，wiki 會漂移，剪藏會變成第二個書籤庫
個人知識庫很少是一次壞掉的。比較常見的是剪藏、會議紀錄、工作備忘、研究文章、轉檔結果和 AI 產物慢慢堆在入口資料夾；等要寫週報或整理作品時，才發現來源還在，但脈絡已經散了。
入口資料夾長期滯留
_Inbox 和 Clippings 適合先收，不適合長期放。素材卡在入口太久，後續週報、研究和作品頁都要重新翻一次。
新素材沒有接回既有知識
每次都新建一頁，wiki 很快會長出多個相似主題。搜尋時看得到片段，卻不容易判斷哪一頁才是主脈絡。
整理結果沒有稽核紀錄
只在聊天視窗回一句「整理好了」沒有太大用處。隔天要能回頭看見處理了哪些資料、哪些有警告、哪些被留給人工確認。
寫入之前，先把去處判斷清楚
Daily Dream Cycle 不把所有東西都丟去摘要。它會看素材量、內容型態和既有 wiki，再判斷要歸檔原文、補進主題頁、放到 AI-Assets，或標成待人工確認。
每日收尾路徑
- Source scan：列出 Inbox、Clippings 或本次指定範圍。
- Metrics：先看行數、字數與字元數。
- Sample gate：資料超過三筆時先跑代表樣本。
- Brain-first：查過既有 wiki 後才寫入。
- Route and write：歸檔、更新，或交給人工確認。
- Audit summary：留下 summary note 與 JSON audit。
掃描候選素材
列出指定範圍內的 Markdown、剪藏或待轉檔內容，避免在沒看過的資料上直接動作。
取得 metrics
每篇 Markdown 先取得 line_count、word_count 和 char_count，用來判斷要快讀、深讀或先抽樣。
樣本先行
素材超過三筆時跑 sample gate；分類和寫入策略站得住，才繼續處理其他檔案。
Brain-first 搜尋
寫入 wiki 前會查既有主題；如果只找到來源檔，就換一組近義詞再查一次。
路由到正確位置
全文保留在 raw，結構化知識進 wiki，後續 workflow 資產放 AI-Assets，一次性交付放 outputs。
寫 summary audit
完成後產出 summary note，並用 schema validator 檢查警告、失敗和人工確認狀態。
整理完的素材，要能支援下一次工作
Daily Dream Cycle 對我的價值在於，它把「整理知識庫」從看心情處理的雜務，變成每天能收斂的一段固定動作。資料不只留著備查，也會被放回後續真的會使用的位置。
週報更容易取材
工作紀錄與研究材料進到穩定位置後，寫週報時不需要從 Inbox 從頭翻起。
研究可以接回既有脈絡
brain-first 搜尋讓新素材先對齊既有 wiki，降低同題內容在不同頁面各寫各的機率。
作品頁可以取到整理後素材
專案草稿、workflow 描述和限制會進入可引用位置，不再只散在對話紀錄裡。
治理狀態可以被檢查
summary audit 讓每日整理留下可回看的維護紀錄，而不是只剩聊天視窗裡的一段回覆。
寧可留下警告，也不要假裝整理完成
這套流程刻意保留警告與人工確認狀態。外部來源、轉檔結果、附件引用和 CLI 狀態只要不確定，就不把它們寫成乾淨結論。
Source verification marking
外部來源的主張如果還沒查核，就標示待驗證，不直接寫成既定事實。
Post-write readback
新建或更新筆記後，用 Obsidian readback 抽驗，確認寫入內容真的能被讀回來。
Health reports
完成後回報 skillpack health、entity promotion report 和 vault health audit，避免只看單次輸出。
Manual review state
轉檔、brain-first、附件或 summary validation 失敗時，保留來源，並把狀態留給人工確認。
定位限制
Daily Dream Cycle 仍依賴 Obsidian CLI、既有 vault schema 與技能規範。CLI 沒有回應時，流程會做健康檢查，用窄查詢重試；仍失敗才 fallback 到檔案系統。
這套做法借了 LLM Wiki 和 GBrain 的方向
Daily Dream Cycle 不是 gbrain 的 fork，也不是 Karpathy LLM Wiki 的完整實作。它參照的是兩個核心方向：先把來源整理成 wiki 型知識，再讓 agent 在長期記憶上讀寫、補引用、做回歸檢查。
-
Karpathy 的 LLM Wiki給我的啟發是，不要每次查詢都回頭翻一堆 raw context；更好的做法是把來源編譯成結構化、互相連結、可持續更新的 wiki。閱讀 LLM Wiki idea file
-
Garry Tan 的 gbrain讓我把「個人知識庫」看成 agent 可以長期讀寫的 memory layer，而不是單純搜尋筆記。Daily Dream Cycle 裡的 nightly consolidation、citation/audit 與人物/專案脈絡收斂，都是沿著這個方向做本地化取捨。查看 gbrain repo
-
gbrain-evals 的評估意識提醒我記憶系統不能只看一次回答漂亮不漂亮，還要檢查找不找得到、時間線對不對、引用能不能追、規模變大後是否仍然穩定。查看 gbrain-evals repo
Agent 負責判斷，腳本負責重跑檢查
這件事如果寫成單一大腳本，最後會很難處理分支。Markdown、附件、長文、外部資料、既有 wiki、索引和 summary 驗證，各自都有不同的失敗方式。
-
語意判斷留給 AgentAgent 負責讀內容、判斷資料該去哪裡，以及決定要更新哪份筆記。
-
重複檢查交給 Pythonmetrics、summary schema、attachment reference 與 health report 這些可重跑檢查由 helper scripts 處理。
-
保留 partial 與 warning 狀態轉檔、外部主張、CLI 狀態或 health check 失敗時，不把結果說成完整完成。
-
外部資料不是指令來源筆記、網頁剪藏、OCR 與 RAG 片段只能作為資料，不能覆蓋 workflow 規則。
新增素材、日常回寫、存量收斂分開處理
Daily Dream Cycle 在 Obsidian AI runtime 裡負責每日新增素材。Brain-Ops 處理日常查詢與回寫，Dream Fusion 則在筆記開始重疊、漂移或互相衝突時介入。
如果你也在整理 Obsidian、AI Agent workflow 或長期知識庫，可以先看每日收尾和 audit summary 怎麼設計。