同樣在 LizzieYzy Next 也有支持該功能。不過需了解，形勢判斷引擎並不需要是主分析引擎本身，而是另外啟動一個用於盤面歸屬、領地估算與粗略點目的輔助引擎的設置。它可以使用 KataGo，也可以使用 ZenGTP。由於這個功能的設置方式與一般 KataGo 分析引擎不完全相同，因此實際設置時需要注意的幾個重點。

第一次尚未設置形勢判斷命令時，所出現的窗格就會讓使用者填入加載的指令。它支持使用另外一個引擎 Zen7 執行形勢判斷，但需要擁有 Zen7 的可執行 DLL（Zen.dll），以及可以執行 ZenGTP 運行的指令（好像是舊版 LizzieYzy 專案內有？我也忘了！）。

另外就是透過 Katago 引擎執行加載命令，但建議使用權重低些，例如 20B 版本，並且不要設置分析秒數、計算量等參數，盡量讓其系統資源耗用較低，能快速執行並顯示形勢判斷結果即可，並不需要過度精確要求。

我個人是仍然沿用同一個 KataGo 分析引擎（b28c512nbt），但需要把原來的 config 設定檔複製一份，並更名為如：gtp_estimate_b28.cfg，然後最主要需調整以下參數（完整參數內容可以參考我的 KataGo Gist 範本）：

# ---------------------------------------------------------------------------
# 一、日誌設定
# 形勢判斷會頻繁呼叫，不建議開啟完整 GTP 與搜尋日誌。
# ---------------------------------------------------------------------------
logAllGTPCommunication = false
logSearchInfo = false
logSearchInfoForChosenMove = false
logToStderr = false
# ---------------------------------------------------------------------------
# 二、分析輸出設定
# 形勢判斷主要使用 kata-raw-nn 0，不需要長 PV 或額外探索噪聲。
# ---------------------------------------------------------------------------
analysisPVLen = 8
reportAnalysisWinratesAs = SIDETOMOVE
analysisWideRootNoise = 0.0
analysisIgnorePreRootHistory = true
# ---------------------------------------------------------------------------
# 三、規則與貼目設定
# 以韓國規則、黑貼 6.5 目為基準。
# 注意：LizzieYzy Next 形勢判斷流程可能會送出
# kata-set-rules chinese 或 kata-set-rules japanese 覆蓋 rules。
# ---------------------------------------------------------------------------
rules = korean
komi = 6.5
# 若只分析固定貼目的棋譜，才考慮啟用。
# 一般不建議，避免與 SGF / GUI 的貼目設定衝突。
# ignoreGTPAndForceKomi = 6.5
# ---------------------------------------------------------------------------
# 四、投降設定
# 形勢判斷引擎不需要投降，但相關欄位仍建議保留，避免啟動缺 key。
# ---------------------------------------------------------------------------
allowResignation = false
resignThreshold = -0.90
resignConsecTurns = 3
# ---------------------------------------------------------------------------
# 五、搜尋與思考設定
# 形勢判斷不需要高強度搜尋，避免搶主分析引擎資源。
# ---------------------------------------------------------------------------
numSearchThreads = 2
ponderingEnabled = false
# 形勢判斷不建議固定搜尋限制。
# maxVisits = 500
# maxPlayouts = 500
# maxTime = 10.0

然後加載命令行與啟動 KataGo 引擎命令是一樣的，只是 config 檔改為上述已修改的配置檔。例如填入以下：

H:\Game\Go\GoAI\Katago\engines\v1.16.5-cuda12.8-trt10.9\katago.exe gtp -model H:\Game\Go\GoAI\Katago\models\kata1-zhizi-b28c512nbt-muonfd2.bin.gz -config H:\Game\Go\GoAI\Katago\configs\gtp_estimate_b28.cfg

LizzieYzy Next 的形勢判斷引擎，主要用途是快速提供盤面局勢的約略判斷，而不是取代 KataGo 主分析引擎的精確計算。它比較接近野狐圍棋對弈時可以點選的「局勢判斷」功能：可以快速看出黑白雙方大致的地盤分布、盤面歸屬與領先方向，但不應把它視為嚴格點目或最終勝負判定。

因此，形勢判斷引擎的設置重點不是追求長時間搜尋或高 visits，而是讓它能穩定、快速地回傳盤面估算結果。真正需要深入檢討一手棋的得失、勝率變化、目差變化與後續變化圖，仍應回到 KataGo 主分析引擎來判斷。

簡單來說：形勢判斷適合用來快速掌握盤勢輪廓；精確復盤與關鍵手分析，仍應以主分析引擎為準。

〈關於 LizzieYzy Next 的形勢判斷引擎設置〉這篇文章最早發佈於《Kenmingの鮮思維》。

去年我曾寫過一篇〈KataGo (2025) 開源圍棋 AI 安裝與設置〉，主要整理 KataGo 這套開源圍棋 AI 引擎在 Windows 環境下的安裝與設定方式。當時我使用的 GUI 分析與復盤界面，是較為通用的 Java-based 覆盤軟體 LizzieYzy。

LizzieYzy 本身曾經是相當好用的 KataGo 圖形化分析工具，不過該專案已經有一段時間沒有持續維護，因此一些既有問題也沒有再被修復。對我來說，最明顯的不便之一，就是它無法連線至各圍棋對弈平台，例如 野狐圍棋 已無法直接下載或擷取棋譜。若要分析線上對局或職業棋手棋譜，就必須另外手動處理 SGF 檔案，整體流程並不順手。

不過就在前幾個月，我注意到 LizzieYzy 出現了一個新的延續版本：LizzieYzy Next。

需要先說明的是，LizzieYzy Next 並不是原作者重新回來維護舊專案，而是由另一位作者接手延續 LizzieYzy 的使用脈絡，並重新整理成目前仍在積極維護的新版專案。這一點其實相當難得，因為它不是單純包裝既有程式，而是針對安裝包、平台支援、引擎配置、線上棋譜擷取、分析功能與文件說明，都做了相當完整的整理。

更值得一提的是，作者的維護頻率非常高，幾乎可以說是幾日一更。專案也提供多種版本選擇，從一般使用者可以直接下載使用的整合包，到適合進階使用者自行配置 KataGo 引擎的客製化版本都有涵蓋；平台支援也不只限於 Windows x64，還包含 Linux 與 macOS。除此之外，作者也整理了相當詳細的 README.md 文件，甚至貼心提供 PDF 與多國語言版本供使用者下載參考。

以一個開源圍棋工具來說，能看到這樣積極、細緻且長期投入的維護，確實不常見。這背後若不是對圍棋與圍棋 AI 分析有很高的熱情，大概也很難持續投入這種無償的整理與開發工作。

LizzieYzy Next 是什麼？

簡單來說，LizzieYzy Next 是一套以 KataGo 為核心引擎的圍棋 AI 圖形化分析與復盤工具。

如果 KataGo 本身是負責判斷局面、搜尋變化與給出勝率／目差評估的 AI 引擎，那麼 LizzieYzy Next 就是把這些分析結果轉換成棋手可以直接操作、觀察與理解的前端介面。

它延續了 LizzieYzy 原本熟悉的使用方式，但在新版中重新整理了安裝包、引擎配置、線上棋譜擷取、全盤分析、勝率概覽與棋盤同步等功能。對一般棋友來說，可以較低門檻建立一套可用的 AI 復盤環境；對已經自行配置 KataGo、CUDA 與 TensorRT 的使用者來說，也可以選擇不含引擎的版本，接入自己原本調校好的 KataGo 環境。

不過本文的重點不是重新說明 KataGo 如何安裝與調校。KataGo、CUDA、TensorRT、權重檔與 config 設定方式，我已經在先前文章中整理過。這篇會聚焦在 LizzieYzy Next 本身：它解決了哪些 GUI 覆盤流程問題、該如何選擇安裝包，以及實際使用時哪些功能最值得注意。

KataGo 的安裝與設置可參考：

LizzieYzy Next 的價值

LizzieYzy Next 的價值，不只是讓舊版 LizzieYzy 可以繼續使用，而是把原本已經中斷維護的 KataGo 圖形化復盤流程重新整理與補強起來。

對一般棋友來說，它降低了建立 AI 復盤環境的門檻；對已經熟悉 KataGo 的使用者來說，它則提供了一個更完整、更方便接入既有引擎設定的 GUI 分析介面。尤其是線上棋譜擷取、快速全盤分析、勝率概覽與棋盤同步等功能，讓它不只是單純的 SGF 閱讀器，而是更接近一套完整的圍棋 AI 復盤工作環境。

這次維護版最值得肯定的地方，在於作者並不是只做一次性的打包整理，而是持續修正、補強與釋出新版。從更新頻率、版本分類、跨平台支援，到 README.md 與多語文件的整理，都可以看出作者投入了相當多心力。對一個開源圍棋工具來說，這種持續維護本身就很珍貴。

從官方 README 與 Releases 內容可以看出，LizzieYzy Next 明確將自己定位為目前仍在維護的 LizzieYzy / KataGo GUI，並且針對幾個實務痛點重新打磨：

• Windows 免安裝包優先，下載後解壓即可使用。
• 依照 OpenCL、NVIDIA、RTX 50、無引擎等情境區分不同發布包。
• 一般使用者可選擇內建 KataGo 的整合版本。
• 進階使用者可選擇無引擎版本，接入自己既有的 KataGo 環境。
• 野狐棋譜可以直接輸入暱稱抓取，不再要求使用者先查數字帳號。
• Windows 發布包整合棋盤同步工具，降低使用者另外尋找 readboard 工具的成本。
• 支援 Windows、macOS、Linux 等平台。

LizzieYzy Next 的主要功能特徵

整理 README.md 與實際安裝使用後，幾個 LizzieYzy Next 的功能包括：

• 延續 LizzieYzy 的使用方式
  保留原本 LizzieYzy 熟悉的 KataGo 圖形化分析與復盤介面。
• 提供多種安裝版本
  依不同使用情境提供 OpenCL、NVIDIA、without engine 等版本，方便一般使用者與進階使用者選擇。
• 支援快速全盤分析
  可針對整盤棋快速進行 AI 分析，方便復盤時觀察勝率、目差與關鍵轉折。
• 提供勝率概覽
  可從整體變化中快速查看局勢起伏，對找出失誤點與勝負關鍵相當有幫助。
• 支援野狐圍棋棋譜擷取
  可透過野狐暱稱取得棋譜，減少手動下載或轉檔的不便。
• 支援棋盤同步工具整合
  可支援奕客直播平台棋譜同步播放，適合用於線上觀戰、直播棋譜與即時復盤觀察。

安裝與版本選擇

該專案的 README 文檔已經寫得非常詳細，這裡只針對 Windows 用戶（畢竟這佔絕大數）給一些要點的說明：

• 一般 Windows 使用者：優先使用 OpenCL 免安裝版。
• NVIDIA RTX 20 / 30 / 40 系列顯卡：可使用 nvidia.portable.zip。
• RTX 50 系列顯卡：可使用 nvidia50.cuda.portable.zip。
• OpenCL 不穩定：可改用內建 KataGo 的相容版本。
• 已熟悉 KataGo、想自行配置引擎與權重：可使用 without.engine.portable.zip。

對多數棋友來說，個人比較建議先依照官方推薦使用免安裝版。portable.zip 的好處是設定、日誌、保存棋譜、下載權重與相關快取會保留在解壓縮後的目錄內，日後升級、搬移或清理都比較直覺。而更為想省事的用戶，直接就下載帶有 with-katago 的整合包，它可以達成一鍵優化設置並且馬上就可以分析覆盤使用。

我的安裝方式

我個人算是較為進階的使用者，使用的顯卡是 NVIDIA RTX 3080 12GB，並且先前已經完成 CUDA 12.8 與 TensorRT 10.9 的安裝與設定。因此這次我沒有直接使用內建引擎的版本，而是選擇自行配置的無引擎版本，也就是 windows64.without.engine.portable 壓縮包。

這個版本適合已經明確知道自己要使用哪個 KataGo 引擎、哪個權重檔，以及哪份設定檔的使用者。它的優點是環境乾淨，不會與內建 KataGo 引擎混淆；缺點是需要自行完成引擎、權重與設定檔的配置。

相關的 KataGo、CUDA 與 TensorRT 安裝流程，可以參考我去年整理的那篇文章。後續我也會再另外分享一篇搭配 Human-like 權重的配置說明，包含棋力設定與使用情境。這類配置更適合應用在與 AI 對弈上，尤其可以搭配較適合作為對弈練習的開源軟體，例如 KaTrain。

補充下，關於 KataGo 的 Config 檔，我根據最新版本（v1.16.x）更新了相關參數設置的繁體中文註解說明，如果要自行調校 KataGo 引擎的效能與優化，可以參考：KataGo v1.16.5 GTP Config 範本。

實際使用情境：從棋譜擷取到 AI 復盤分析

最後補充幾個我初步使用 LizzieYzy Next 時的應用情境。由於該專案本身已經提供相當完整的安裝文檔，本文就不再展開詳細的安裝與設定流程。事實上，這套覆盤軟體的功能相當多，初次使用時不一定能很快掌握全貌；因此以下僅透過幾張截圖，說明它在實際覆盤與棋譜分析時可以扮演的角色。

以下展示的棋局分析，除了奕客圍棋直播同步播放的畫面之外，主要是利用 LizzieYzy Next 連線至野狐圍棋，下載 LG 盃半決賽「王星昊對陣申真諝」的棋譜後，再進行 AI 分析與復盤。

同步直播棋譜並即時觀察局勢

LizzieYzy Next 支援奕客直播平台的棋譜同步播放。對於想要觀看職業對局、直播棋譜，或即時跟進棋局變化的使用者來說，這會比手動下載 SGF 再匯入分析方便許多。

在同步棋譜後，可以直接透過 LizzieYzy Next 的主畫面觀察棋局進行，同時搭配 KataGo 分析候選點、勝率、目差與局勢變化。

快速全盤分析，找出關鍵轉折點

對已經完成的棋譜，可以使用自動分析功能，讓 KataGo 逐手分析整盤棋。分析完成後，就能從勝率曲線、目差變化與候選點分布中，快速找出局勢轉折的位置。

這對復盤相當實用。因為多數情況下，一盤棋真正需要深入檢討的並不是每一手，而是那些勝率或目差突然大幅變化的節點。透過全盤分析，可以更快定位問題手與關鍵局面。

在完整棋局中查看候選點與變化圖

當棋局進入中後盤，局面通常已經非常複雜。這時 LizzieYzy Next 可以在棋盤上直接標示 KataGo 推薦的候選點，並在右側列出各候選點的勝率、計算量、佔比與目差。

這種呈現方式，比單純看文字數據更直觀。使用者可以直接在棋盤上看到 AI 認為重要的落點，並對照實戰下法，判斷當時的局部選擇是否合理。

使用棋力評估輔助理解對局品質

除了單純看勝率與目差，LizzieYzy Next 也提供棋力評估功能，可以從 AI 選點吻合度、好手率、失誤率等角度，輔助觀察一盤棋的整體品質。

這類資訊不適合作為絕對結論，但對復盤很有參考價值。尤其在檢視自己或他人的對局時，可以協助判斷哪一方在選點穩定性上較好，或哪一段開始出現明顯偏差。

參考連結

• LizzieYzy Next GitHub：https://github.com/wimi321/lizzieyzy-next
• LizzieYzy Next Releases：https://github.com/wimi321/lizzieyzy-next/releases
• KataGo GitHub：https://github.com/lightvector/KataGo
• KataGo Release：https://github.com/lightvector/KataGo/releases
• KataGo 官方權重：https://katagotraining.org/
• 我的 KataGo 安裝與設置文章：https://kenming.idv.tw/katago-2025-install-and-setup/
• 2026 KataGo config 範本 Gist：https://gist.github.com/kenming/8a473b2c35b9fca4bd7e7ad35fe0312d

〈從 KataGo 到 LizzieYzy Next：打造更好用的圍棋 AI 復盤環境〉這篇文章最早發佈於《Kenmingの鮮思維》。

他的影片標題常帶有很強的行動感，例如：

「在一天內重新校準你的人生」、「用寫作重新設計你的工作與人生」、「建立一個不再依賴公司的自己」。這類內容之所以值得整理，不只是因為標題吸引人，而是背後其實反覆圍繞著一人公司、數位寫作、專注力與創作者經濟等主題。

Obsidian 有提供一個 Web Clipper 插件，它確實可以有效擷取網頁文章以及 Youtube 的影片逐字稿（transcript），不過它卻無法批次擷取多則影片。所以我自己寫了一個 Python script，利用 yt-dlp 抓取 Dan Koe 的 YouTube 頻道影片清單。截至 2026/05/05，該頻道共有 157 則影片；我將每則影片的逐字稿批次擷取下來，並將每支影片各自輸出成一個 `.md`（Markdown）文檔，同時加上 YAML frontmatter 與 Metadata 資訊，方便作為影片摘要與檢索資訊。

接著，這些 Markdown 文檔會被儲存到先前我所建置的 llm-wiki 知識庫內。再透過 Codex / Claude Code 進行萃取提煉（Ingest）後，整理成可查詢、可交叉關聯、可長期維護的 wiki 內容。

這次的 Dan Koe 影片整理，重點並不只是批次下載逐字稿，而是把這些內容轉換成後續可以被 LLM 持續分析與維護的知識素材。

而且這次我將這個 llm-wiki Vault 專門用來整理 Dan Koe 的相關論述。後續他所發表的文章、影片等內容，除了可以透過我寫的 script 批次處理，也可以使用 Obsidian Web Clipper 擷取單篇文章或單支影片，再納入這個 llm-wiki 知識庫中。

透過 LLM 分析，我就可以更快速地提煉 Dan Koe 長期內容中的核心觀點，例如：

- Dan Koe 如何定義 one-person business

- 他對 digital writing 的定義

- 不同影片中反覆出現的概念

- 他的內容是否存在主題演進

- 哪些觀點適合進一步整理成概念頁或方法論頁

〈把 Dan Koe 的 157 則 YouTube 影片整理成 llm-wiki 知識庫〉這篇文章最早發佈於《Kenmingの鮮思維》。

近日為了方便管理多個 AI Agent（Claude/Codex）的 Skills 共用機制，原本是想乾脆自己來開發一個，但秉持著盡量不要重新造輪子，所以先從 GitHub 上查找（關鍵字：Skill Manager），還真找到許多同類型的專案。

然後又再關聯到先前我也下載過對岸一個 Claude Code 多帳號／多供應商切換的開源工具專案 - cc-switch，我發現這些專案執行後的管理設置界面並非是採透過瀏覽器開啟的 Web 頁面，也不是傳統原生桌面應用程式。而是看起來綜合了兩者的特性，卻又可以跨平台的 "類桌面應用的 Web 界面"，還挺有意思的。

再進而查看他們程式碼所使用的應用框架，都不約而同使用了 tauri 2.0 框架，我直覺以為這應該算是前端框架吧？，但卻又不是；那麼該歸屬為後端框架吧？但又不盡然。透過 AI 調研，結果給我一堆技術行話，卻仍是定位不清。

乾脆自己也來動手寫一個相關練手用的專案吧，就近了解近期這些相關的應用技術吧（React/Typescript + Tauri + Rust Core）。我想就以跨平台的桌面寵物來作為應用案例，順便把我的小狗堡貝放進 Windows 桌面上，時不時讓牠走動、餵食、安撫等，也是挺有趣的。

我在使用任何程式語言、任何技術框架開發專案前，首先要決定的就是分層架構的設計議題。Ract/TypeScript 是前端，這沒有問題，Rust Core 是後端這也沒問題，就是 Tauri 應該定位在哪一層呢？查看相關文件以及透過 AI 討論，還真的都說不出所以然！

與 AI 對話討論，可以看成它是一位技術實作能力超群的「技術宅」，但較為抽象的概念層次，往往會夾雜著底層的實作機制來說明。所以我就禁止讓它從技術的角度（例如它會用 IPC, command handler 來解釋 tauri）解釋，而是只從巨觀的角度來說明。總算比較明確定位了 tauri 的分層關係。最基本的巨觀分層概念：

Frontend <-> Bridge <-> Backend

Frontend 可以是 React / TypeScript，負責使用者看見與操作的介面；

Backend 則是 Rust Core，負責核心邏輯、資料處理與本機作業系統能力整合。

至於 Tauri 2 ，它其實就是中間那層 Bridge，它不是傳統 Web 架構裡的 API Controller 或 Gateway 角色，而是 WebView Frontend 與 Rust Backend 之間的本機連接與能力邊界。

把 Tauri 2 的概念分層簡化為：

• 前端：使用者看見與操作
• 橋接層：通訊、邊界與控制
• 後端：邏輯、系統存取與資料處理

一句話來說：

• What：Tauri 2 是一個以 WebView 承載前端介面、以 Rust Core 整合本機能力，並透過 Bridge 連接兩者的跨平台桌面應用框架。
• Why：Tauri 2 讓 Web 前端能以輕量、安全、受控的方式，橋接至本機桌面能力。

可參考官網文件： https://v2.tauri.app/start/

確實釐清並界定好了分層框架後，程式碼的組織相對就會井然有序且簡潔很多了。若以概念目錄樹來表達，大致可以看成：

tauri-app/
├─ frontend/ # Frontend：WebView 介面層
│ └─ React / TypeScript
│
├─ bridge/ # Bridge：Tauri 2 橋接層
│ └─ IPC / Commands / Events / Capabilities
│
└─ backend/ # Backend：Rust Core 後端層
│ └─ Logic / System Access / Data

除了桌寵這個小案例，後續這樣的架構也可以延伸應用在如跨平台系統管理介面、AI 工具控制台，甚至 Trading Dashboard 這類需要整合本機能力的桌面應用。也就是說，Tauri 2 真正值得理解的，不只是它能把 Web UI 包成桌面程式，而是它提供了一個清楚的 Bridge，讓前端介面與本機系統能力之間維持可控、可測試、可擴充的分層邊界。

〈Tauri 2 的分層架構定位：讓 Web 前端成為本機桌面應用〉這篇文章最早發佈於《Kenmingの鮮思維》。

前言

在上一篇文章〈Karpathy LLM Wiki 知識系統實踐：解析核心理念〉中，我整理了 Karpathy 所提出的 LLM Wiki 方法論，其核心並不在於使用某個特定工具，而是建立一套可以持續演化的知識處理流程：

• 原始資料放在 raw/
• LLM 將資料整理為 wiki/
• 透過 AGENTS.md 或 CLAUDE.md 定義操作規範
• 每次新增資料時，不只是產生摘要，而是整合進既有知識結構

這篇接續上一篇，聚焦在「基礎建置」：如何用最少工具，先建立一個可運作的 Karpathy LLM Wiki。

這裡的目標不是一次就打造完整系統，也不是導入複雜 RAG、向量資料庫或自動化 pipeline，而是先建立一個最小可行流程（Minimum Viable Workflow）：

能收集資料、能讓 LLM ingest、能產出 wiki、能持續查詢與維護。

準備工具

基礎設置只需要三類工具。

1. Obsidian

Obsidian 是本地 Markdown 筆記工具，在這套方法中扮演 Wiki 的載體。

Karpathy 對它有一個很直覺的比喻：

• Obsidian 是 IDE
• LLM 是 programmer
• Wiki 是 codebase

也就是說，我們不是把 Obsidian 當成一般筆記軟體，而是把整個 Vault 視為一個由 LLM 維護的知識工程專案。

Obsidian 的好處在於：

• 所有內容都是本地 Markdown 檔案
• 支援 [[wikilinks]] 雙向鍊結樣式
• 可以用 Graph View 檢視知識圖譜
• 不需要先導入資料庫或雲端服務

2. LLM Agent

第二個工具是能操作本地檔案的 LLM Agent，例如：

• OpenAI Codex
• Claude Code
• Gemini
• 使用如 Ollama 建置本地的 LLM
• 其他可讀寫本地 Markdown 檔案的 agent

重點不是模型品牌，而是它必須能做到幾件事：

• 讀取 raw/ 裡的來源
• 在 wiki/ 建立與更新 Markdown
• 維護 index.md 與 log.md
• 依照規格檔執行 ingest、query、lint

如果使用 Codex，該行為規範檔名命名為 AGENTS.md；而如果使用 Claude Code，則命名為 CLAUDE.md。

兩者在概念上扮演同一個角色：告訴 LLM 這個知識庫應如何被維護。

3. Obsidian Web Clipper

第三個工具是 Obsidian Web Clipper。

它不是必要條件，但很實用。因為多數研究素材來自網頁文章、Youtube、技術文件、Blog、教學文章等。Web Clipper 可以直接把網頁轉成 Markdown，保存到 Obsidian Vault（可以指定任一 Vault） 中。

在這套流程裡，建議將 Web Clipper 的輸出位置設定為：/raw

如果文章中有圖片，也建議讓附件下載到：raw/assets/

這樣原始資料與附件就會一起保存在本地，避免日後網頁圖片失效，LLM 也可以在需要時檢視圖片內容。

創建 LLM Wiki Vaullt 目錄結構

安裝 Obsidian 後，先建立一個新的 Vault，本例命名為：llm-wiki-demo。

啟動 Obsidian 並開啟該 Vault，接著需要執行對應的 LLM Agents。Obsidian 可透過安裝 obsidian-terminal 插件，在應用程式內直接呼叫 Agent CLI。然而，在 Windows 11 上的使用體驗並不理想，因此本例改採在 Vault 目錄下另開 PowerShell 執行 Codex CLI，並將兩個應用程式並排顯示於同一螢幕，以便同步檢視與操作。

接著無需手動逐一建立目錄與檔案結構。我的作法是只先建立 \raw 目錄，並透過 Codex CLI 將 Karpathy 發表於 Gist 的 LLM Wiki 下載至該目錄。同時，也要求 Agent 一併擷取所有留言討論，整理並儲存為單一 Markdown 文件。

然後我在 Agent CLI 聊天框內輸入以下訊息：

根據 raw/karpathy-llm-wiki-gist.md 的主文內容（僅採用其三層目錄架構，不納入留言討論中的建議），建立本 llm-wiki-demo 的知識庫目錄結構。既有 raw/ 內的原始文檔則維持不變。

建議啟用 /plan 模式，讓 Agent 在實際建立目錄前，先確認所採用的結構符合主文所建議的設計。以下為最小必要的目錄結構：

llm-wiki-demo/        # Obsidian vault 根目錄
├─ AGENTS.md          # LLM Wiki schema 與操作規範
├─ raw/               # 原始來源層，作為 source of truth
├─ templates/         # wiki 頁面與紀錄模板
└─ wiki/              # 由 LLM 維護的知識頁主體

最後，Agent 會依據 Karpathy 的 LLM Wiki 主文建立目錄結構，並生成必要的規範檔（AGENTS.md 或 CLAUDE.md）、索引（index）與日誌（log）等完整模板，最終呈現在 Obsidian 的檔案目錄窗格中。

透過 Web Clipper 設定與擷取網頁內容

Obsidian 官方推出的 Web Clipper 插件功能相當強大！它的主要功能特徵有：

• 一鍵擷取網頁內容並儲存為 Obsidian 筆記；支援擷取 YouTube 影片並將逐字稿一併保存
• 支援頁面文字高亮（Highlight）並一併保存
• 可選擇擷取完整頁面或特定區塊（如文章主體）
• 自動轉換為 Markdown，保留基本結構與格式
• 支援自訂模板與指定儲存位置（Vault／資料夾）

安裝 Obsidian Web Clipper 後，建議設定：

• Vault：選擇你的 LLM Wiki Vault
• Save location：raw/
• Attachment folder：raw/assets/

這樣每次剪藏網頁時，就會直接進入 raw source 層。

一個基本流程會是：

1. 在瀏覽器看到值得研究的文章或影片
2. 用 Obsidian Web Clipper 存到 raw/
3. 若文章有圖片，下載到 raw/assets/
4. 回到 LLM Agent，要求 ingest 該來源

這裡要注意一點：不要把 Web Clipper 剪下來的文章直接當成整理後的知識。

它只是 raw source。

真正的整理工作，應由 LLM 在 wiki/ 中完成。

第一次 Ingest

當目錄與規格建立完成後，就可以進行第一次 ingest（擷取）。

當 \raw 目錄內有多筆尚未被 ingest 處理過的原始文檔，就可以對 Agent 下達如下的指令：

請 ingest raw/ 內所有尚未 ingest 的來源。

理想情況下，LLM 不應只產生一篇摘要，而是會建立多個頁面，例如：

wiki/
├─ sources/
│  └─ karpathy-llm-wiki-gist.md
├─ concepts/
│  ├─ llm-wiki.md
│  ├─ rag.md
│  ├─ persistent-wiki.md
│  ├─ raw-sources.md
│  ├─ wiki-layer.md
│  └─ schema-layer.md
├─ operations/
│  ├─ ingest.md
│  ├─ query.md
│  └─ lint.md
├─ architecture/
│  └─ raw-wiki-schema.md
├─ index.md
└─ log.md

這才是 LLM Wiki 的精神：把來源整合進一個可持續維護的知識結構。

查詢與回寫

完成第一次 ingest 後，就可以開始用 wiki 提問。

例如：

請根據 wiki，說明 LLM Wiki 與傳統 RAG 的差異。

或：

請比較 raw/wiki/schema 三層架構各自的責任。

在回答時，LLM 應該先讀：

wiki/index.md

再依照索引讀相關頁面。

如果回答產生了有長期價值的整理，例如：

• 一份比較表
• 一個設計取捨分析
• 一個跨來源綜合結論
• 一份未來改進建議

就應該要求 LLM 將它回寫到：

wiki/syntheses/

這就是 query file-back。

它能讓每一次查詢不只是得到答案，也能讓知識庫本身變得更完整。

知識圖譜

當 LLM Agent 完成多次 Ingest 並在 wiki/ 目錄下生成多個具備雙向連結（[[wikilinks]]）的 Markdown 文件後，知識庫便從平面的文檔堆疊轉化為具備拓樸結構的知識網路。

透過 Obsidian 的知識圖譜（Graph View），我們可以對系統進行以下實務觀察：

• 語義網路的實體化：圖譜中的節點代表概念（Concepts）或來源（Sources），連線則是 LLM 根據 AGENTS.md 規範所識別出的邏輯關聯。這將原本隱含在內文中的知識脈絡，轉化為直觀的架構圖。
• 知識成熟度評估：密集的節點集群（Clusters）代表該領域已有足夠的交叉參照與資訊深度；相對地，孤立節點（Orphan Nodes）則揭示了知識庫中的斷層，作為後續執行 lint 或補充 raw 資料的標靶。
• 驗證 Codebase 結構：誠如 Karpathy 所述，Wiki 是 Codebase，而圖譜即是該 Codebase 的架構藍圖。透過視覺化，維護者能確認 index.md 是否正確發揮樞紐節點（Hub）的作用，確保 LLM 在執行查詢時能循序存取相關路徑。

這種展現方式不僅是為了美觀，更是確保知識系統在演化過程中，始終保持結構化的完整性與可導航性。

定期 Lint Wiki

當 wiki 開始累積頁面後，需要定期檢查健康狀態。

可以直接要求：

請 lint 這個 wiki，檢查是否有矛盾、過期資訊、孤立頁、缺少 backlinks、重要概念缺頁，並提出修正建議。

Lint 應檢查：

• 是否有頁面互相矛盾
• 是否有舊結論被新來源推翻
• 是否有孤立頁
• 是否有概念被多次提到但沒有獨立頁
• index.md 是否漏列頁面
• log.md 是否記錄最近操作

這個步驟很重要。

因為知識庫真正困難的不是新增資料，而是長期維護。

知識庫的持續維護與整理，對於知識工作者是很煩心的工作，而這反而是 LLM 最為專長所在。

基礎設置完成後的目錄樣貌

一個完成基礎 ingest 後的 Vault，大致會像這樣：

llm-wiki-demo/           # Obsidian Vault 根目錄
├─ raw/                  # 原始來源層；來源真相，不應由 LLM 修改
│  └─ assets/            # raw 來源引用的圖片、附件與本地資產
├─ templates/            # Wiki 頁面模板；供後續 ingest/query/lint 建頁使用
│  ├─ architecture.md    # 架構頁模板
│  ├─ concept.md         # 概念頁模板
│  ├─ operation.md       # 操作流程頁模板
│  ├─ source.md          # 來源摘要頁模板
│  └─ synthesis.md       # 綜合分析頁模板
├─ wiki/                 # LLM 生成與維護的知識庫主體
│  ├─ applications/      # 應用場景頁；如 personal、research、business/team
│  ├─ architecture/      # 架構與資料流頁；如 raw → wiki → schema
│  ├─ concepts/          # 核心概念頁；如 RAG、persistent wiki、schema
│  ├─ operations/        # 操作流程頁；如 ingest、query、lint
│  ├─ sources/           # raw 來源的摘要與 metadata 頁
│  ├─ syntheses/         # 跨來源綜合分析與 query file-back 頁
│  ├─ tools/             # 工具與整合方式；如 Obsidian、qmd、MCP
│  ├─ index.md           # Wiki 內容索引；回答問題前優先讀取
│  ├─ log.md             # 時序操作日誌；記錄 ingest/query/lint/update
│  └─ overview.md        # 知識庫總覽；目前對 LLM Wiki pattern 的整體理解
├─ AGENTS.md             # Schema layer；定義 Codex/LLM 如何維護此 Vault
├─ README.md             # README文件，介紹三層架構與基本工作流

這個結構已經足以支撐基礎使用：

• 新資料進 raw/
• LLM 維護 wiki/
• AGENTS.md 定義行為
• index.md 導覽內容
• log.md 追蹤演化

此時還不需要導入向量資料庫、MCP 或複雜搜尋工具。

先讓流程跑起來，比一開始就把架構做大更重要。

一些實務建議

1. 一次 ingest 一份來源

初期建議一次只 ingest 一份來源。

這樣比較容易檢查 LLM 的整理結果，也比較容易調整 AGENTS.md 的規則。

等流程穩定後，再考慮批次 ingest。

2. 不要讓 LLM 修改 raw

這點要反覆強調。

raw/ 是原始證據，不是工作區。

如果 LLM 整理錯了，可以修 wiki；但如果 raw 被改掉，就失去追溯依據。

3. index.md 要保持簡潔

index.md 不是全文目錄，也不是所有內容的複製。

它應該是一份導覽：

• 頁面名稱
• 一句話摘要
• 分類
• 必要 metadata

它的用途是讓人與 LLM 都能快速找到入口。

4. log.md 要持續追加

log.md 不需要寫得很長，但一定要記錄操作。

最重要的是：

• 何時 ingest
• ingest 了什麼
• 建立或更新了哪些頁
• 是否有 query 被回寫
• 是否做過 lint

5. 先用 Markdown，再談工具升級

當 wiki 還在早期階段時，不需要急著加搜尋引擎、資料庫或自動化。

等到你真的遇到問題，例如：

• 頁面太多，index 不夠用
• 查詢需要全文搜尋
• 多人或多 agent 同時維護
• 需要更嚴格的 metadata 查詢

再考慮導入 qmd、MCP、Obsidian Bases、Dataview 或 SQLite 等工具。

結語

Karpathy LLM Wiki 的基礎設置其實不複雜。

真正重要的是建立正確分工：

• raw/ 保存原始資料
• wiki/ 保存整理後的知識
• AGENTS.md 或 CLAUDE.md 定義 LLM 的操作規範
• index.md 幫助定位
• log.md 保存演化紀錄

這套方法的價值，不在於一次產生漂亮的筆記，而在於讓知識可以持續累積與維護。

當新資料加入時，LLM 不是重新開始，而是把新資料整合進既有結構。

當你提出問題時，答案也不只是聊天回覆，而可以回寫成新的知識頁。

這就是 LLM Wiki 和傳統文件整理或一次性 RAG 最大的差別。

下一步，等基礎流程穩定後，就可以進一步討論如何導入 skill、搜尋工具與自動化流程，讓這套知識系統更適合長期維運。

〈Karpathy LLM Wiki 知識系統實踐：基礎安裝與建置篇〉這篇文章最早發佈於《Kenmingの鮮思維》。

關於如何有效整理屬於自己的知識庫（Knowledge Base），我可是嘗試了許多種方法與工具。從早期講究以文件資料夾如何分類、到使用 PARA 方法論只簡化為四個主目錄（Project, Area, Resource, Archive），但在實務應用上仍覺得不太順手。

其實原因在哪裡？我覺得先釐清所要整理的素材有相當的關係。我發現自己真正花時間整理的，並不是日常筆記，也不是既有的工作文件，而是在研究某個主題時，所收集的大量素材——包含文章、影片、PDF 等。接著再進行閱讀、分析、彙整、摘要，甚至進一步實作或撰寫成文章。

如果是一次性的短期研究素材倒也還好，消化完即丟棄。這類情境下使用如 NotebookLM 或 ChatGPT Project 或 Gemini Gems 等，將資料集中後交由 AI 進行分析與整理，其實已經相當足夠。

但當研究主題變得長期且持續擴展時，情況就完全不同：

• 研究範圍廣泛
• 參考資料數量龐大
• 新資料會不斷加入
• 舊結論需要反覆修正

在這種情境下，建立「屬於自己的本地知識庫」就變得必要。而真正的挑戰，不再只是分類，而是：

如何有效整合知識，以及如何快速定位可用的資訊。

恰好在這個月初（4/3），AI 大佬 Karpathy 在他的 X 社群上貼了這篇：「LLM Knowledge Bases」，分享他如何使用 LLM 建立各種研究主題的個人知識庫（Personal Knowledge Bases）。這套方法論一經發表，便如往常般引發廣泛關注；除了大量轉傳分享外，也有許多知識工作者（包括我）已開始著手實踐。

這套方法有幾個關鍵特點：

• 不依賴複雜的 RAG 架構
• 使用極簡工具（如 Obsidian）
• 搭配 LLM（Claude Code、Codex、Gemini 等）
• 將原始素材「編譯」為具備摘要與雙向連結的 Wiki
• 並以 LLM 作為查詢與推理界面

Karpathy 這套方法透過簡單的工具組合，將原本複雜的知識庫建構流程轉化為個人與小型團隊可行的實踐方式，這也正是我所需要的。

Karpathy LLM Wiki 方法論總覽

Karpathy 隨後在其 Gist〈LLM Wiki〉中，補充了一份較為完整的架構設計筆記。

其核心觀點在於：將原始資料（文章、PDF、影片等）與最終使用之間，加入一層由 LLM 維護的 Wiki。
知識不再每次查詢時從原始資料重新拼接，而是先被整理、整合，並持續累積在 Wiki 中。

整體而言，這套方法可視為一種知識處理流程的轉換：

• 原始資料（Raw sources）作為輸入來源
• Wiki 作為主要知識介面
• LLM 負責整理、更新與維護內容

在此基礎上，Karpathy 進一步將其做法拆分為結構與流程兩個層面，使系統得以持續演化，而非一次性整理完成。

這裡就依其內容，分為三個面向進行解析與說明。

一、核心構想：從文件檢索轉向持續累積的 Wiki

在傳統做法中，原始資料通常直接作為查詢來源；但在這套方法中，這些資料被視為輸入，而非最終知識。

透過 LLM 處理後，內容會被整理為具備結構的 Wiki 頁面，包含主題、摘要與關聯連結。
查詢時，優先基於這些已整理的頁面，而非直接回到原始資料進行檢索。

當新的資料加入時，LLM 並不是單純產出摘要，而是會：

• 更新既有主題頁面
• 補充相關概念
• 修正或調整原有內容

知識因此不再是分散的文件集合，而是逐步累積與演化的整體。

二、系統設計：三層架構與三種操作流程

為了讓知識系統具備穩定結構，Karpathy 將其設計拆分為三個層次：

三層架構

• Raw sources
  - 原始資料來源（文章、PDF、影片等）
  - 保持不變，作為事實依據
• Wiki
  - 由 LLM 維護的知識頁面
  - 包含摘要、主題與交叉連結
• Schema
  - 定義操作規範與行為方式
  - 指導 LLM 如何進行處理

三種操作流程

• Ingest
  - 將新資料整合進既有 Wiki
  - 可能同時更新多個相關頁面
• Query
  - 從 Wiki 查詢並生成回答
  - 查詢結果可再回寫為新知識
• Lint
  - 定期檢查內容品質
  - 包含矛盾、過時資訊與缺漏補強

透過這三種操作，Wiki 不斷被更新與修正，形成可持續演化的知識結構。

三、維運關鍵：索引、記錄與持續整理

在實際運作上，Karpathy 特別強調幾個維持系統穩定的關鍵要素。

首先是索引與記錄：

• `index.md` 作為知識導覽入口，用於快速定位主題與頁面
• `log.md` 記錄 ingest、query、lint 等操作，追蹤系統演化過程

其次是維持低複雜度設計：

• 在資料規模尚小時，不依賴複雜的 RAG 或 embedding 系統
• 以簡單結構優先，避免過早引入額外工具

最後是工具的彈性使用：

• 可搭配 Obsidian、Web Clipper、CLI 工具等
• 但這些皆為輔助，而非必要條件

整體而言，這套方法並不強調工具本身，而是透過明確的結構與流程，使知識整理能持續進行，而非一次性完成。

後續實踐

理解 Karpathy 所提出的 LLM Wiki 方法論後，下一步即是落實為可運作的知識系統。

我將分為兩個階段，逐步說明實際建置與優化的方式：

一、基礎建置：以最少工具快速建立可運作流程

在基礎建置階段，重點不在於工具堆疊，而在於先建立一套可運作的最小流程（Minimum Viable Workflow）。

此階段將採用：

• Obsidian 作為 Wiki 知識載體
• Obsidian Web Clipper（Browser extension）作為資料收集工具
• LLM（Codex 或 Claude Code）負責內容整理與結構化

並透過行為規範檔（如 `AGENTS.md` 或 `CLAUDE.md`），明確定義：

• 如何 ingest 原始資料
• 如何更新 Wiki 結構
• 如何維持內容一致性

目標是在最少工具的前提下，快速建立從「資料收集 → 知識萃取 → 結構化輸出」的基本流程。

二、進階優化：導入 Skill 與工具鏈強化系統能力

當知識庫規模逐步擴大後，單純依賴手動規範與基本流程，將逐漸面臨效率與一致性的挑戰。

在進階階段，將導入既有的工具與設計，以提升整體系統的可維運性與效能。

主要包含：

• 採用現有的 Obsidian Wiki專案（目前我看到把 llm-wiki 核心理論具體化為 skill 的最完善的專案）
• 並搭配其所建議的延伸工具，例如：
  - obsidian-skills（定義可重用的提示與操作流程，強化 LLM 在 Obsidian 內的行為一致性）
  - qmd（提供本地 Markdown 知識庫的快速搜尋與索引能力，作為查詢輔助工具）

透過這些工具的導入，可達成：

• 更有效的文件組織與知識連結
• 自動化程度的提升
• 查詢與處理效率的優化
• 面對大量資料時的系統穩定性

整體而言，這兩個階段分別對應：

• 基礎建置：建立可運作的知識流程
• 進階優化：強化系統能力與擴展性

後續將依序針對這兩個部分，進行實作層面的詳細說明。

〈Karpathy LLM Wiki 知識系統實踐：解析核心理念〉這篇文章最早發佈於《Kenmingの鮮思維》。

不過，在 Windows 上建構 AI Agent 自動化工作流時，環境配置的自動化程度與權限控制是核心考量。傳統 Windows 軟體的安裝方式（如 .msi 或 .exe）通常涉及系統登錄檔修改與系統管理員權限（UAC）的要求，這對需要自主執行的 AI Agent 而言，會造成流程中斷或權限提升的技術門檻。

如何有效避開系統管理權限，卻又不能賦予 AI Agent 完整權限（否則一旦誤刪系統相關檔案，可能導致系統崩潰）？這看起來相當兩難！

也是在詢問 AI Agent 後才知道，原來 GitHub 上有一個相當知名的套件管理工具 —— Scoop。它的主要設計初衷在於採用 User-Level 的權限架構，所有安裝的指令（如 7zip、node.js、python、php、pandoc 等）均統一儲存在使用者帳號目錄內 ~/scoop。它如同 Mac 上的 Homebrew，一行指令即可完成應用程式的下載、安裝、移除與更新，整個過程完全不需要動用系統管理員權限。

基於這樣的特性，Scoop 成為 AI Agent 能夠在無需人工介入處理權限彈窗的情況下，自主管理 CLI 工具鏈的關鍵工具。這不僅簡化了 Agent 對系統環境的操控邏輯，也確保了工具執行環境的一致性與安全性。

以下是對 Scoop 的基本介紹與應用情境、安裝等說明。

What and Why Scoop？

Scoop 是一個專為 Windows 設計的命令列套件管理器 (Command-line Installer)。它透過 PowerShell 執行，並使用簡單的命令（如 scoop install python）來自動化下載、解壓縮與配置軟體的過程。

其技術架構包含以下特性：

• 基於 JSON 清單 (Manifests)： 軟體的安裝資訊與下載路徑定義在簡單的 JSON 檔案中。
• 軟體庫 (Buckets) 機制： 軟體清單儲存在 Git 倉庫中。除了預設的 main 庫，使用者可以自由添加 extras、versions 或 java 等擴充庫。

在 Windows 11 環境下，Scoop 解決了傳統安裝方式的三大痛點：

1. User-Level 權限執行（無需 UAC）

這是對 AI Agent 最友好的特性。大多數 Scoop 軟體安裝在使用者資料夾內，不會跳出 UAC 警告，亦無需管理員權限。這使得 Agent 在自動化腳本中安裝或更新工具時，不會因為權限請求而掛起。

2. 避免環境變數 (PATH) 污染

傳統安裝軟體會將路徑直接寫入系統 PATH，導致環境變數混亂。Scoop 將所有軟體安裝在統一目錄（預設為 ~\scoop），並透過 ~\scoop\shims 目錄下的代理執行檔（Shim）進行管理。AI Agent 只需定位此單一路徑即可呼叫所有工具。

3. 綠色、可移植且易於清理

Scoop 偏好可攜式（Portable）軟體，不修改系統登錄檔。透過 資料持久化 (Persist) 機制，在更新軟體版本時會保留設定檔與數據，實現無痛升級，這對需要長期穩定運行的 Agent 環境至關重要。

實務使用情境 (Use Cases)

針對 AI Agent 作為 Windows「家管」的生活化應用，以下是典型場景：

• 文件檔案的整理與分類：
  當 AI Agent 定期掃描本機 Documents / Downloads 目錄時，可自動辨識檔案內容（如發票、技術文件、圖片等），進行分類、重新命名與搬移，並建立結構化目錄（如 Finance / Projects / Media），同時可搭配瀏覽器開啟雲端硬碟介面（如 Google Drive）同步整理遠端檔案，維持本地與雲端一致性。
• Gmail、行事曆與雲端硬碟整合管理：
  AI Agent 可透過瀏覽器自動登入 Gmail、Google Calendar 與雲端硬碟，定期整理信件（分類標籤、封存、標記重要）、彙整近期行程與提醒事項，並同步檢查雲端檔案狀態（如未整理文件或重複檔案），將分散資訊集中為每日摘要，降低人工切換與遺漏風險。
• 內容創作與多平台自動發佈：
  當使用者完成文章撰寫後，AI Agent 可自動調用瀏覽器登入 Blog 平台與社群（如 Facebook），依據預設格式填寫標題、內容與標籤，完成發佈流程；同時可進一步處理 SEO 欄位、摘要生成與多平台同步發佈，形成一套從內容完成到發布的全自動流程。

安裝與常用操作指令

安裝 Scoop

安裝非常簡單，只需在 PowerShell 終端機執行以下命令即可：

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Invoke-RestMethod -Uri https://get.scoop.sh | Invoke-Expression

常用操作命令

可以參考官網的 QuickStart（首頁本身即為優秀的快速指南）

• 搜尋工具： scoop search <app>
• 安裝工具： scoop install <app>
• 更新軟體庫： scoop update
• 更新所有已安裝軟體： scoop update *
• 移除軟體： scoop uninstall <app>

更進階的應用可參考它的 README 文件。

小結心得

我會將透過 Scoop 安裝的所有指令列表，定期整理為一份文件 available-commands.md，並讓 AI Agent 的規範檔（如 AGENTS.md 或 CLAUDE.md）在每次啟動時先讀取該文件內容，以了解其可操作的指令集合，且全程無需系統管理員權限。這使得在系統整體安全性與操作便利性之間，取得良好的平衡。

對於追求環境配置自動化、系統路徑整潔，以及極簡化工具鏈管理的 AI Agent 而言，Scoop 提供了低摩擦且高效率的執行基礎，是在 Windows 11 上進行 CLI 命令自動化操作的理想選擇。

〈AI Agent 的 Windows 11 最佳助手：Scoop 套件管理工具與權限自動化〉這篇文章最早發佈於《Kenmingの鮮思維》。

這個專案主要在處理一個常見問題：LLM 在長對話或長期互動中，容易遺失上下文（context）。

MemPalace 採取的方式，和一般常見的「摘要記憶」不同，它偏向保留原始對話內容，再透過語意檢索把相關片段找回來使用。

這樣的設計，其實對應到一個古老、源自希臘的記憶方法——「記憶宮殿（method of loci）」：

透過把資訊放在不同的空間位置（例如房間、走廊），在需要時沿著路徑取回記憶。

在這個專案中，則是用類似 wing / room 的結構來組織資料，再搭配向量檢索，讓 AI 可以在需要時找回相關內容。

它的核心其實很簡單——不是去「摘要記憶」，而是乾脆「保留全部原文」。這個選擇本身就很有意思，因為現在大多數 AI workflow 都是在想怎麼壓縮 context，但它是反過來：我不壓，我存，等需要時再找。

如果用工程的角度來看，這其實就是把問題從「compression」轉成「retrieval」。也就是說，瓶頸不在記憶，而在你能不能有效把正確片段「撈」回來。

不過這個專案最為吸睛的，反而並非獨創的關鍵技術，而是作者之一竟然是 Milla Jovovich——也就是《惡靈古堡》系列中「愛麗絲」的飾演者，同時也是《第五元素》等作品的知名影星。

根據專案相關說明，她在長期使用 ChatGPT、Claude 等工具時，發現 AI 無法延續過去對話的脈絡；而現有記憶工具又傾向替使用者篩選內容，可能丟失關鍵思考過程。這也促使她與開發者合作，嘗試建立一種能完整保留並可回溯的記憶系統。

目前這個專案已累積高達 30K stars，熱度仍在持續。不過因為它的 benchmark 看起來相當亮眼（甚至接近 100%），也引發部分社群的質疑與拆解，指出測試方式可能使結果偏向樂觀，且部分結果實際上依賴外部 API，與「完全本機」的說法並不完全一致。

不過值得一提的是，作者持續修正 README，將限制說明得更清楚，也讓數據呈現更為保守，讓整體專案逐步回到「可驗證」的軌道。

該專案基於 SQLite 與 ChromaDB，主要可在本地執行，不需額外 API Key（除非調用模型本身），因此在隱私與資料控制上具有一定優勢。

再觀察幾天，等更多評測與回饋出來後，再來決定是否實際安裝。（README 已說明支援多種 CLI 環境，並以 Claude Code 為主要整合對象。）

〈從《惡靈古堡》的愛麗絲到 LLM 記憶宮殿 — MemPalace〉這篇文章最早發佈於《Kenmingの鮮思維》。