滾寒宮是劉亮把 LLM Wiki 的部分文章對外公開的網站，2026 年 8 月上線於 garden.liuliang.work。站名取他的專業別名「滾亮」，同時是廣寒宮的諧音（劉亮 2026-08-13 確認）。定位寫在首頁第一行：
這裡是滾亮的「知識花園」，不是部落格，所以沒有最新文章。
技術組合是 Quartz 5＋GitHub＋Cloudflare Pages。它與 LLM Wiki 入門指南網頁 是兩件不同的東西：入門指南是為教學另外寫的一頁，滾寒宮發布的是 wiki 既有的文章本身。
構思
wiki 建在 Obsidian 裡只有自己看得到，他一直想把部分內容公開成個人網站或部落格形式。已知 Obsidian 官方的 Publish 服務可用但要付費，因此先確認有沒有替代方案。
方案評選交給 AI，列出可行選項並加上價格比較與排名：
| 方案 | 年費 | Obsidian 相容 | 維護負擔 | 排名 |
|---|---|---|---|---|
| Quartz 5＋Cloudflare | US$0 | ★★★★★ | 低～中 | 1 |
| Obsidian Publish | US$57.60（教育價） | ★★★★★ | 極低 | 2 |
| Astro＋Cloudflare | US$0 | ★★★☆☆ | 中～高 | 3 |
| Webpage HTML Export＋Cloudflare | US$0 | ★★★★☆ | 中 | 4 |
| Hugo＋Cloudflare | US$0 | ★★★☆☆ | 中 | 5 |
Obsidian Publish 在設定與維護上都最輕，輸在年費與網站自由度（三顆星）。Quartz 5 拿下第一是因為零年費、相容性滿分、日常發布簡單，維護負擔仍在可接受範圍。
發展
訪談法的第二次使用
選定方案後他沒有立刻開工，而是先進入 未知四象限 的「已知的未知」模式，用訪談法確認還有哪些需求與問題沒被想到。他寫給 ChatGPT 的 prompt 幾乎是 2026-08-02 那場開課計劃十題訪談的翻版：一次一題、優先問會改變架構與長期維護的問題、對模糊或矛盾的回答直接追問、資訊足夠前不提方案、最後整理成計劃並另列未決事項與隱性假設。差別只在主題從開課換成建站。
這是 wiki 裡第一次記錄到方法本身被移轉。一套原本用在課程設計上的訪談流程，被他改寫成自己的工具，拿去解一個完全不同領域的問題。
ChatGPT 問了 54 題，歷時一個多小時，中間他忍不住反問還剩多少題。他挑出的三個代表性問題是：
- 自動發布要依賴 Mac 本機，還是盡量放在雲端、Mac 關機也不影響——這決定同步腳本與 GitHub／Cloudflare 的責任分工，也決定日後維護的是本機工具鏈還是雲端 CI/CD
- 一篇已公開的筆記取消公開標記時，網站頁面是否要自動刪除並清掉附件與連結——這決定發布腳本要不要做「新增／更新／撤下」三種狀態管理，而不只是單向複製
- 公開筆記的網址在改檔名、改標題、移資料夾之後是否要保持不變——這決定不能單靠路徑生成 URL，需要為公開筆記建立固定的 slug
三題都不是「怎麼建」，而是「建完之後怎麼活下去」。劉亮的評語是，這些問題對非專業的人來說，不問根本不會想到。這正是四象限主張的那種未知：不在技術能力裡，在你不知道自己該問什麼。
十項 MVP 標準
訪談判定關鍵決策足夠之後，AI 才產出架構、計劃與步驟，並訂出十項驗收標準：Obsidian vault 完全不搬家、私人筆記不進 GitHub、publish: true 才能公開、一個 Obsidian 指令完成全站同步、wikilinks 正常、圖片正常、Search／Backlinks／Graph 正常、取消 publish 可以撤下、git 可以 rollback、Cloudflare 能自動 deploy。
他拿著計劃回到 Claude Code 按步驟實施，逐階段確認驗收，一天完成，形容為幾乎無痛無坑（見 Vibe Coding）。
結果
發布路徑
筆記加上 publish: true → Obsidian 執行 Publish 指令 → ~/Developer/garden 的發布引擎掃描 vault、只取 publish: true、改寫連結、處理圖片、寫入 content/、驗證 Quartz build、commit 並 push → GitHub 私有 repo → Cloudflare Pages 約一分鐘完成建置。程式碼不在 vault 裡，從 Obsidian 看不到它。
隱私由架構解決，不是由審查解決
wiki 在 2026-08-04 記過一項判斷：把 wiki 內容對外發布，真正的成本不在技術而在隱私。滾寒宮給出的答案是把逐項審查換成預設值：
- 預設不公開。 私人筆記不會被寫進
content/，因此不進 git 也不進 GitHub，從未離開 vault - frontmatter 白名單。
sources:與related:列的是私人筆記的檔名與路徑，發布時被擋掉；新增欄位預設一律擋，不需維護黑名單 [!todo]與[!question]自動剝除，所以這兩種 callout 可以放心寫在 vault 裡- 圖片的 GPS 與相機資訊在轉檔時一併丟棄
成本沒有消失，是被改成逐篇 opt-in。每公開一篇仍要自己讀過正文，找出寫給自己的考證註記，以及提到未公開筆記的具體數字——這兩種機器分不出來，因為它們是合法的正文。截至 2026-08-13 有 27 篇帶 publish: true，本篇是其中之一。
撤下同樣是架構的一部分：把 publish: true 拿掉再發布，內容從網站消失、退出 Graph 與搜尋，但網址保留並顯示已撤下，避免別人的連結與搜尋引擎突然 404。
現況
首頁挑了四篇當入口：動手之前先想清楚、LLM Wiki、先確認身份再判斷、走自己的路。讀者留言透過 Giscus 寫進另一個公開 repo 的 Discussions，需要 GitHub 帳號，只出現在文章頁。數據用 Cloudflare Web Analytics，無 cookie，刻意不用 Google Analytics。網域於 2026-08-12 從 Cloudflare 的預設子網域換到 garden.liuliang.work。
日常操作 SOP、踩過的坑與各項設定寫在 vault 根目錄的〈Digital Garden 維運手冊〉，那份文件本身沒有 publish: true。手冊的用途是操作指南，§13 記的公開篇數不隨每次發布更新（劉亮 2026-08-13 確認不需維護），要查實際篇數以各篇 frontmatter 的 publish: 為準。
已知風險與未決
- Quartz 升級流程還沒實際跑過。 專案動過 Quartz 核心檔案（為 canonical 連結改了
Head.tsx），上游更新可能覆蓋或衝突 - 發布流程綁定 macOS。 vault 裡有 20 個 HEIC，而處理圖片的函式庫讀得到標頭卻無法解碼，得靠 macOS 內建工具先轉中繼檔
- 已有留言的筆記不能再換資料夾。 Giscus 用當前網址對應留言，不跟著 301 走，留言會變成孤兒（留言本身仍在 GitHub 上）
- Logo、favicon、首頁文案、字體與 CSS 尚未定案