可以做到什麼
找出多篇相似、過期或互相衝突的筆記，先提出候選組、承接頁、合併理由與風險。確認後才重寫一篇主頁，並把舊頁封存。
00 / CONCEPT SNAPSHOT
先把 Dream Fusion 想成「知識庫的重編譯步驟」
它不是摘要器，也不是自動清檔工具。它處理的是已經累積在 wiki 裡、彼此重疊或版本不一致的舊頁，先讓人看見候選與風險，再把確認後的主題收斂成一個可追溯入口。
為什麼要這麼做
AI 很會產筆記，也很容易把同一個主題整理成多個平行答案。沒有收斂機制時，搜尋會命中很多舊頁，讀者還要自己判斷哪一篇才可信。
概念是什麼
新頁上半部放目前採信的理解，下半部保留來源、日期、衝突與封存去向。aliases 讓舊標題還能找到承接頁，history 不會被清掉。
一句話：摘要負責把新素材變成筆記；夢融合負責把太多筆記重新收斂成一個入口。
01 / PROBLEM
同一個主題累積出多篇舊頁，搜尋就開始失準
Obsidian 用久之後，麻煩通常不是缺資料，而是同一件事被記在太多地方。
一篇是早期摘要，一篇是研究筆記，一篇是後來的修正版本。搜尋時每篇都像能回答問題，但讀者還要自己判斷哪一篇才是目前版本。
AI 協作會放大這個問題。Agent 很會產出筆記，也很容易把同一份材料整理成多個角度；如果沒有收斂流程，知識庫會變成一堆看似完整的舊答案。
02 / WORKFLOW
夢融合只處理已存在的知識頁
它不清 Inbox，也不處理單篇新素材。它處理的是已經在 wiki 裡累積一段時間、開始重複或互相打架的頁面。
Candidate report
用 deterministic report 找出標題、aliases、wikilinks、tags 與來源軌跡相近的筆記群組。
Proposal first
列出候選筆記、推薦承接頁、合併理由與風險。沒有人工確認，就不進入寫入流程。
Compiled Truth + Timeline
確認後重寫目前採信的理解，舊來源、演進與衝突則放進 timeline / evidence trail。
Aliases and archive
新頁保留舊標題 aliases，舊頁只移到封存區。舊連結可以找到承接頁，舊脈絡也能追。
03 / CONCEPT LINEAGE
這個 skill 參照 LLM Wiki 與 gbrain，但落點放在 Obsidian 舊頁收斂
Dream Fusion 的知識管理脈絡來自兩個外部概念：Karpathy 的 LLM Wiki 提醒我先保留 raw evidence，再讓 LLM 維護 wiki；Garry Tan 的 gbrain 則把 brain layer、dream cycle、來源引用與 gap analysis 做成可運轉的 agent memory 系統。
Andrej Karpathy：LLM Wiki
LLM Wiki 的重點是三層分工：不可變 raw sources、由 LLM 維護的 Markdown wiki，以及約束 agent 行為的 schema / AGENTS。Dream Fusion 接在這個模式後段，處理 wiki 長期使用後出現的重複、過期與衝突。
Karpathy LLM Wiki gistGarry Tan：gbrain
gbrain 把 agent 記憶做成會讀、會引用、會指出未知處的 brain layer，並用 dream cycle 持續 ingest、enrich、consolidate。Dream Fusion 借的是這個運轉觀念，但實作保持在我的 Obsidian skillpack 裡。
garrytan/gbrain04 / QUALITY GATES
我刻意讓它停在 proposal，因為融合比摘要更容易改壞知識庫
摘要寫錯，通常只是多一篇爛稿；融合寫錯，可能會讓一組舊頁被錯誤承接。所以這個 skill 最重要的設計，是固定哪些地方不能自動放行。
人工確認
候選群組先變成 proposal。人確認後，才允許寫入承接頁與封存舊頁。
衝突保留
不同來源互相矛盾時，只標出 conflict，不讓 Agent 私自選一邊。
連結防呆
融合後的新頁保留舊標題 aliases，降低舊 wikilinks 失效的風險。
05 / TECHNICAL CREDIBILITY
它不是一段 prompt，而是一個有操作合約的 Agent Skill
夢融合的判斷由 Agent 做，但候選掃描、查詢驗證與健康檢查交給可重跑的腳本。
候選掃描由 build_fusion_candidate_report.py 產出。真正融合時，流程要求讀取來源全文、保留 aliases、建立 Source Notes；承接頁如果是核心主題，再用 run_query_eval.py 檢查舊標題或常見問法是否仍能命中新頁。
這樣拆，是為了讓失敗點可定位。候選太寬、融合判斷太急、query eval 沒過，會是不同類型的問題，不應混在同一段 prompt 裡。
06 / VERIFIED EXECUTION
第一次 execute 用在「知識蒸餾」主題，沒有停在設計稿
2026-06-28，我用這個流程收斂兩篇舊摘要頁。它先掃候選，再讀全文，最後才建立承接頁與封存舊頁。
436
掃描 wiki 筆記數，用 deterministic candidate report 先找可能重疊的頁面。
20 / 8
產出前 20 組候選，人工讀回 8 篇候選全文後才決定第一組。
1 + 2
建立 1 篇融合頁，並把 2 篇舊摘要頁移到封存區，不刪除舊脈絡。
22 / 22
新增 query eval case 後全數通過；新頁也通過 tag、No BOM 與 Obsidian readback 檢查。
實際承接頁：「知識蒸餾與AI能力轉移治理」把工程機制與產業治理兩篇摘要收斂成同一個 watchlist 主題。
保留未決問題：DeepSeek、xAI、AI Overwatch Act 相關主張沒有被寫成事實，而是留在 Open Questions / Conflicts。
流程驗證：候選掃描、人工確認、全文讀回、封存、索引更新與 query eval 都有明確檢查點。
07 / IMPACT
摘要會增加頁面，夢融合負責讓舊頁變少、脈絡變清楚
這件作品處理的是 AI 工作流後半段：資料已經進來了，筆記也已經生成了，接下來要避免它們變成一堆互相競爭的答案。
搜尋結果更穩：同一主題不再分散在多篇相似筆記裡，讀者可以先看承接頁。
歷史脈絡還在：舊筆記被封存，timeline 和 source notes 保留當時的觀察。
知識治理可接續：Dream Cycle 處理新素材，Brain-Ops 處理日常回寫，Dream Fusion 處理舊頁收斂。三者分工後，知識庫比較不會越整理越亂。
08 / NEXT READING
放在整個 Obsidian AI runtime 裡看
Dream Fusion 不是孤立工具。它接在每日素材整理、日常知識回寫與本機資料處理之後，負責處理已經累積出重複版本的舊頁。