Daily Dream Cycle 每日知識入庫 Agent Skill
這是一個放在 Obsidian vault 裡的每日收尾流程。它讀取 _Inbox、Clippings 與附件，先查既有 wiki，再決定素材要封存、合併、建立知識頁，或留下人工確認狀態。
一句話：Daily Dream Cycle 把每天收進來的零散素材，整理成後續週報、研究、作品頁和知識查詢能繼續使用的來源鏈。
Obsidian 的 Inbox、剪藏、轉檔結果、附件與指定素材範圍。
raw 封存、wiki 新增或更新、AI-Assets、summary note 與 audit log。
它不是單純摘要器；外部主張未查核時會保留警告，不直接寫成結論。
17 筆素材進來，最後變成 3 個可追蹤的知識變更
2026-06-30 的 Dream Cycle 讀取 _Inbox 與 Clippings，先跑 sample gate，再把素材分成新增 wiki、更新既有 wiki、封存 raw 與保留警告幾種結果。這段紀錄比「整理好了」更重要，因為隔天可以回頭檢查每筆素材去了哪裡。
2026-06-30 audit 摘要
- Scope
- _Inbox / Clippings
- 素材
- 17 筆，含 16 篇 Markdown 與 1 個附件
- 寫入
- 新增 1 篇 wiki，更新 2 篇既有 wiki
- 封存
- 16 篇 Markdown 移入
raw/DreamCycle/2026-06-30 - 狀態
- completed-with-warnings，警告保留給後續維運
新增決策帳本主題
兩篇 AI 決策記憶 ADR 被收斂成 AI 決策帳本與跨工具記憶治理，而不是留在 Inbox 各自漂流。
合併子代理素材
Agent teams、Subagent、session log 的素材被補進既有 AI Agent 構件與子代理協作，避免重複開新頁。
成本治理接回主脈絡
Vibe Coding 成本、SDD 規格痛點與 AI 防呆素材被併入 AI Coding 成本治理與規格驅動開發。
沒有把警告藏起來
外部主張保留待查核語氣；全庫 attachment 與 promotion drift 仍列為既有基線，不包裝成零風險完成。
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 怎麼設計。