LLM Wiki 是把個人筆記交給大型語言模型讀過、重寫成 wiki 文章的做法，源自 Andrej Karpathy（前 Tesla AI 總監、OpenAI 創始成員）公開的 llm-wiki gist。劉亮據此建立的實例就是這座知識庫本身：0406/ 放原始筆記且只讀，wiki/ 放由模型寫出、可反覆重寫的文章。他在 2026 年 8 月把這套實作整理成講座與工作坊的開課大綱，見 LLM Wiki 開課計劃。
出現之前的筆記狀態
在 LLM Wiki 之前，劉亮的筆記長期停在 Apple 內建備忘錄，他的說法是「找不到真正合適的軟體」。中間經過一段 Obsidian 與相關 AI 工具的摸索期，觸發他接觸 Obsidian 的是幾組筆記與知識管理概念：結構洞（社會網絡理論中人與人之間的連結空缺）、關聯圖（Obsidian 的雙向連結視覺化）、卡片筆記法（Zettelkasten）、第二大腦（Tiago Forte 的個人知識管理方法，見 十億美元創作者）。這段摸索在講座大綱裡是要展示心得感想與實際產出的一節，意即該階段已有可展示的成果，只是尚未收斂成系統。
那段摸索期留下的具體痕跡是 MOC，而且規模不小：0406/ 底下有 127 份筆記的 frontmatter 指向 MOC 頁面，其中 123 份集中在 USEFUL/👀 視覺化溝通/，日期從 2024-12 到 2025-11，全部早於這座 wiki 的建立。當時他用的是 LYT框架那一套按主題地圖組織筆記的做法。
但那些 MOC 頁面本身幾乎都是空的——實際存在的五個檔案裡有四個是 0 bytes，唯一有內容的一個只放了一段 Dataview 查詢。指路的那一半建好了，地圖那一半沒有寫。這比「工具沒選對」更能說明那個階段為什麼沒有收斂：結構的形式在，判斷沒有放進去。
這條前史也解釋了 AI工具長期停留在工具清單的狀態：工具追蹤有了，把工具接進日常產出的那一步要等 LLM Wiki 才發生。
血統與設計哲學
系統由兩份公開文件拼成，分工明確。基底是 llm-wiki gist，它提供主張與架構：知識要編譯成一個持久且會複利的產物，而不是每次查詢重新檢索；三層架構分成不可變的原始來源、模型完全擁有的 wiki、人與模型共同演化的 schema；人類放棄 wiki 是因為維護負擔成長得比價值快，而 LLM 讓維護成本趨近於零。劉亮額外加入的 personal_wiki_skill（farzaa 發布的 Claude Code skill）提供作業規範：作家心態（模型的角色是作家而非歸檔員）、Wikipedia 語氣標準、各類型文章的長度目標與結構規範。這三項是這座 wiki 之所以讀起來是文章而不是筆記堆的原因，也對應到 wiki/references/writing.md 的內容。
上游文件對此是預期的。Karpathy 的 gist 開頭與結尾都聲明自己刻意抽象，只負責傳達模式，目錄結構與慣例應由 agent 與使用者協作長出來；farzaa 的目錄清單同樣寫明類型要從資料裡長出來、不要預先建立。分歧不是偏離。
與上游的七處分歧
| 項目 | 上游 | 這座 wiki |
|---|---|---|
ingest 指令 | farzaa 用 Python 腳本把 Day One、Notion、iMessage 等格式轉成 raw entries | 沒有這個指令。0406/ 本身就是 Obsidian vault 的 .md |
lint 指令 | 只有 Karpathy 提到，farzaa 的六個指令裡沒有 | 保留，並加上 callout 掃描與 log.md 格式檢查 |
| 查詢結果回存 | Karpathy 標為關鍵洞見：好答案應回存成新頁面，讓探索也複利 | query 明確禁止修改任何檔案 |
| 目錄分類 | farzaa 列出約 40 個類型 | 六類。synthesis/ 不在上游清單上，是本地新增 |
| 拆分判準 | 行數，超過 120 行臃腫、超過 150 行考慮拆 | 改為結構，需要三層以上章節才組織得起來時才拆，行數降為輔助訊號 |
| Callout | 兩份文件都沒有 | 新增四種標記（note／warning／question／todo），並讓 lint 掃描它們 |
| 多版本 | farzaa 用 --dir 切換平行宇宙，各版本互不參照 | 兩座各自獨立的 wiki，生活工作版與學術研究版 |
七項裡最值得記的是查詢結果回存。Karpathy 的理由是探索出來的比較表或分析不該消散在對話紀錄裡，這座 wiki 反其道而行，把 query 鎖成唯讀，改用 absorb 把對話產出當成來源材料吸收，_absorb_log.json 裡有多筆 session 的來源標為「對話記錄，非筆記檔案」。結果一樣是回存，路徑不同：它由人下令，不是查詢的副作用。
同期的另一種架構
同樣是 Obsidian 加 Claude Code、同樣要讓一座 vault 被模型讀得動，LYT框架 給的是另一個答案。LYT 保留原子筆記不改寫，在上面加一層 MOC（Maps of Content）——一則按人的思路排列連結的主題地圖，讓模型打開一張就掌握整個主題的 context。llm-wiki 的做法是把來源編譯成重寫過的文章，原始筆記維持只讀。兩者的分工因此相反：LYT 的知識庫由人寫、AI 協助歸檔與連結，這座 wiki 的知識庫由 AI 寫，人只提供來源與規範。
這條線索是 2026-08-05 從 Clippings/ 的一篇 LYT 教學文章吸收進來的，不是劉亮自己的實作紀錄。他為什麼收藏、是否打算取用其中的做法，目前沒有任何筆記寫到。
產出紀錄
四條實際用途、產出鏈本身的遞迴形狀、四個月沒有中斷的三項原因，以及一份質疑這類系統有沒有用的反對意見，見 LLM Wiki 產出紀錄。
系統維護
劉亮把 wiki 當成需要定期保養的系統，而不是一次設定就不動的工具，維護動作跟著 AI 動態走。2026 年的一次維護分兩步：先讓 AI 依〈The new rules of context engineering for Claude 5 generation models〉整理出的要點對既有文章做檢核，接著針對 log.md 累積的混亂紀錄做重新整理。他對結果的評價是滿意。
維護的必要性來自一項他原本沒有察覺的性質：系統會在正常使用期間悄悄劣化，而且不會報錯。 劣化不等於停止輸入，而是各部分之間出現不一致。已留下紀錄的三個實例——overview.md 曾在 2026-07-06 至 07-25 停在 43 篇不動，當時新文章仍在增加，索引還在但說的話是錯的；_index.md 與 overview.md 的篇數一度採兩種計法，兩處都把概覽算進六類而多算一篇；log.md 曾有一條把 1,469 字整段塞進標題行。共同點是三者都發生在他正常使用的期間，沒有任何錯誤訊息，而且不會有人每天打開 overview.md 檢查它有沒有說謊。空的索引使用者知道要繞開，錯的索引使用者會相信。
這組紀錄補上了 llm-wiki gist 沒有處理的一半。Karpathy 的論證是 LLM 讓維護成本趨近於零，所以 wiki 維持得住；劉亮這邊的實測顯示成本降到近零不等於維護會自動發生。三個實例都不是模型做不到，是沒有人下令做，而劣化本身不會發出要人下令的訊號。
工具面的補充是 kepano 發布的 Claude Obsidian Skill（obsidian-skills），列為工作坊要教的技巧。圖片如何納入 wiki 也列為工作坊題目，做法已寫進 wiki/wiki-handbook.md。
兩座 wiki 的拆分
學術研究用途另建一座 wiki，與個人生活筆記這座分開。劉亮 2026-08-13 給出兩個理由，一個是刻意設計，一個是風險管控。
實驗組與對照組。 這座生活工作版加了 personal_wiki_skill，學術版則維持純 llm-wiki gist，兩座並行是為了觀察兩者的差異。所謂「學術版不適用 personal_wiki_skill」因此不是相容性問題，是他刻意留白：farzaa 那份補的是寫作規範（作家心態、Wikipedia 語氣、長度與結構），拿掉之後才看得出它到底貢獻了什麼。本頁「與上游的七處分歧」記的是這座 wiki 偏離上游多遠，而學術版是另一端的參照點。
避免材料互相污染。 論文有大量文獻、訪談逐字稿與分析，他擔心在分析與撰寫過程中兩邊內容彼此混淆，造成管理維護上的困難。這個判斷下在建立之初，屬於保險而非事後補救——當時還沒有發生混淆，是預判。論文端的實際使用方式見 學術研究。
實驗目前沒有結論。兩座各自累積，但沒有任何筆記記下比較結果，也沒有訂出何時該回頭比對。
對外發布
計劃中列了三種延伸產出：某個主題的專屬網頁（他舉的例子是演唱會製作）、個人網站、方便更新的文章部落格。共同前提是 wiki 的內容已經是成篇的文章而非筆記，可直接對外發布。到 2026 年 8 月中，個人網站這項成立——滾寒宮建站歷程 用 Quartz 5＋GitHub＋Cloudflare 把 wiki 文章發布成 Digital Garden，目前 26 篇帶 publish: true。另一件成品 LLM Wiki 入門指南網頁（2026-08-04 上線）不算在內，它是為教學另寫的一頁。專屬主題網頁仍未做。
兩次上線對隱私給了不同答案，而隱私才是這個方向真正的成本。入門指南只用五張截圖，就有四張越過示範邊界，露出人名、文章標題與財務項目名稱，劉亮評估後維持原樣上線；滾寒宮要處理的是整批文章，改用架構解決——預設不公開、frontmatter 白名單擋掉列著私人檔名的 sources: 與 related:、[!todo] 與 [!question] 自動剝除。逐項審查換成了逐篇 opt-in：成本沒有消失，但變成可以一次付一點。