核心概念與做法不是我原創
這個作品的核心概念與做法，完全來自 Andrej Karpathy 的 LLM Wiki 與 Garry Tan 的 G-Brain。說白一點，我就是沿著兩位大神公開的方法抄作業；但 Daily Dream Cycle 不是 fork，也沒有沿用他們的程式碼。Skill、腳本、流程關卡與 Obsidian 落地，都是我和 AI 依自己的情境一起做出來的客製化版本。
真實的知識治理案例
2026-06-30 的公開 audit 是目前可核對的代表案例。這不是最新版效能數據；它記錄每筆素材最後去了哪裡，也保留當時尚未排除的警告。
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，警告保留給後續維運
這次執行真正留下什麼
三組素材各自接回原有主題：決策記憶合併進決策帳本，子代理素材補進 Agent 協作頁，Vibe Coding 成本與 SDD 痛點回到原有的成本主題。沒有為了看起來產出很多而另開三份相似 Wiki。
Audit 同時保留外部主張待查核、附件與 promotion drift 的既有警告。17 筆只是這次公開紀錄，不拿來推算節省工時或採用率。
未經整理的剪藏終究會變成第二個雜物間
個人知識庫通常不是突然壞掉。剪藏、會議紀錄、研究文章和 Agent 對話產物慢慢堆在入口資料夾；素材一多，脈絡難找，過大的批次還會造成混讀、漏寫或歸錯位置。
真正麻煩的是整理成本一路往後轉嫁。入口資料夾裡的東西沒有消失，只是每次寫週報、做研究、整理作品時又得重翻。若每篇剪藏都另開 Wiki，搜尋結果會越來越多，主脈絡反而更難找；若把長文與不同主題硬塞同一批，還可能漏寫或歸錯位置。
自動化流程必須拆開草稿寫入與來源搬移
同一天收進來的素材，不一定屬於同一主題。Preflight 只盤點候選的 metrics、metadata 與內容指紋；Agent 再依主題、風險和預期知識頁分群。每組通過 checkpoint 後，流程才會往下走。
這不是一條跑到底的 pipeline。盤點與分群只決定這輪讀什麼；寫入檢查負責判斷草稿能不能進 Wiki；來源搬移還要再過另一道 gate。三件事拆開，才不會因為某支腳本成功，就把整輪誤寫成完成。
01 先看清楚今天進來的是什麼唯讀盤點候選、內容指紋與可能的來源異常。
Obsidian CLI 狀態、檔案類型、篇幅、metadata、內容雜湊、完全重複群組，以及疑似夾帶第二篇文章的尾段。
每筆候選都有可核對的路徑、metrics 與內容指紋。掃描只建立 sidecar，不回寫來源。
來源留在原位。文章邊界不清時交給人工確認，不自動截斷或忽略尾段。
02 同題、同風險的素材才放在一批主題、風險與預期 Wiki 不相容的素材不塞在一起。
一般 cohort 是 2 至 5 篇、最多 25,000 字元；長文獨立成 Source Pack。
計畫超過 3 組、15 篇或 75,000 字元時，改成有界 slice。v2.10 可提出 Target proposal，讓使用者一次核准處理契約。
目標頁或風險說不清，就停在 proposal 或 manual queue，不靠擴大批次硬湊答案。
03 第一批得走完這條路大量處理前，用 sample gate 證明搜尋、寫入與歸檔決策走得通。
第一個 cohort 的來源邊界、brain-first 結果、知識去向與 archive-only 理由。
至少有一筆素材能說清楚要更新哪頁、為何只留來源，或為何需要人工確認。
不會拿「原始檔有保留」當作已吸收知識。分群或寫入決策需要修正，後續批次暫停。
04 新素材先回頭找既有主脈絡Brain-first 搜尋避免同一主題長出多份平行 Wiki。
每篇素材先查既有 Wiki；若只命中來源檔，改用近義 query 搜尋知識區。
更新既有頁、建立新的 canonical 頁，或標成 source-only 進入可搜尋來源目錄。
長文先做 heading map 與 evidence pointers。已命中主頁時，只更新原頁，不另造同題入口。
05 草稿得證明沒有改壞舊知識Memory Transition Gate 把遺漏、覆蓋與誤讀分開檢查。
Coverage 找遺漏，preservation 檢查舊脈絡有沒有被蓋掉，faithfulness 對照來源。
初次失敗會留下問題位置與修法，在 tmp 產生修正版，只自動重試一次。
標記 manual review，保留來源與修復建議。其他安全 cohort 可以繼續，不讓單篇卡住整輪。
06 Wiki 寫入與來源搬移各自放行正式寫入與受控歸檔是兩次不同的驗證。
通過檢查的草稿逐 bytes 寫入 Wiki，再用 Obsidian readback 與 SHA-256 核對。
Archive gate 檢查來源 checksum、目的地碰撞與 transition 證據；prepare ready 才能搬。
還要執行 verify。目的地內容對不上時，不在 summary 宣稱歸檔完成。
07 最後留下人看得懂、機器也能重算的紀錄來源目錄、v1.15 audit 與 health checks 各自回答不同問題。
重建 DreamCycle source catalog，讓 source-only 素材仍可由主題找到 raw 來源。
Audit 分開記 execution、vault governance 與 backlog；正常延後不算失敗，全庫舊警告也不冒充本輪錯誤。
Summary schema、附件引用、索引與 health checks 通過後才收尾。有警告就保留 completed-with-warnings。
自動化腳本無法替內容正確性背書
Python helper 負責重跑 metadata、hash、readback、archive 與 audit schema；內容是否漏掉重點、蓋掉舊脈絡或誤解來源，仍由 Agent 判斷。外部主張沒查核就保留警告，附件或來源路徑對不上就不搬檔。
v2.10 的邊界
Target Mode 可以在同一個活躍任務裡依 checkpoint 接著處理，但仍由主 Agent 串行執行；worker delegation 固定停用，跨任務可信 resume 也尚未啟用。流程不確定時，素材留在原位，audit 記下停在哪一道檢查。
前面的來源聲明不是客套話。Daily Dream Cycle 把 LLM Wiki 的持續編譯觀念與 G-Brain 的長期記憶治理方向，收斂成我自己的本地 workflow；程式與流程實作沒有沿用兩者的程式碼。
下一次工作應該從整理好的位置開始
每輪結束後，素材只會落在三個地方：既有或新增的 Wiki、可搜尋的 raw 來源、人工確認佇列。週報、研究與作品頁可以沿著 audit 找回整理後的脈絡，不必依賴聊天紀錄回想當時做了什麼。
可以先從批次邊界、寫入檢查與來源目錄這三件事聊起。
Obsidian 知識治理三階段
晨間情報調度、每日有界入庫與存量知識重整，三個 Agent Skill 各自負責不同週期的工作與驗證機制。