近日為了方便管理多個 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の鮮思維》。

不過從去年開始，因為有 AI 開發相關的系統設置等，我的桌機原來僅為 512GB 的系統碟已快爆倉！我知道這一年來記憶體與儲存裝置飆漲得相當離譜，但衡量許久，還是不得已從 Momo 購物 下單買了「美光 T500 2TB M.2 SSD」。買進價格為 NT$10,800。唉！回想兩年前（2024）這類等級的 SSD 才不到 5,000 元，現在漲幅足足超過一倍有餘。（結果購買後一週又再上漲 1,000 元！）

這條 T500 2TB 顆粒為 TLC 顆粒（這很重要，系統碟千萬不要買到 QLC），M.2 2280 PCIe 4.0 SSD（CT2000T500SSD5 讀 7400M/寫 7000M）。由於我的桌機當時購買的是 ASUS TUF GAMING B550M-PLUS M-ATX 規格，機殼空間很窄小（當初未充分考量，桌機還是不要買 M-ATX 規格，不好升級），導致要加裝 M.2 散熱片高度不能過高，甚至其中 PCIe Gen3 插槽還是被壓在顯卡底下，只能考慮使用超薄散熱片。

找了許久，在 蝦皮購物 購買了採用石墨烯材質加強導熱的散熱片。我是從兩家店舖個別購買，因其中有家可買大片的銅箔片回來自己切以備不時之需。

現在要折騰這些硬體升級對我真是吃力，整整花了老大半天！需要把顯卡先拔下來，又把貓頭鷹塔扇移除下來清灰，也順便重新對 CPU 塗抹散熱膏（早已乾枯了）。

壓在顯卡下方的是 PCIe Gen3 的插槽，需避免誤插影響效能，所以把原來 512 GB 汰換下來的 M.2 改插在這處，且前述已說明，只能加裝超薄散熱片插入，但裝好後重開機發現溫度竟超過 60度（臨界邊緣）！原因就是顯卡排熱就會直接影響到下方的散熱片。後來想到主機板有附一片長片的散熱片可以隔熱，不過又要拆下顯卡重新安裝，很是折騰～。加裝上後（但需要稍用力下壓才能鎖住）溫度就可以降到只有30餘度了，還好～。

完成安裝後兩片 M.2（一為 Gen3、另一為 Gen4）包覆著散熱片所在位置如下圖。

升級後主系統空間頓時大了很多（2TB），且這條 美光 T500 跑的是 Gen4，速度也快上不少，溫度基本也不會超過 40度（夏天應該就會超過，但應該都算是安全範圍）。雖然價錢小貴，但仍是對這次的升級挺滿意的。

尤其是後續我又多花了兩三天時間重新安裝與規劃系統，而且又加上了使用 ChatGPT Codex 輔助用來管理我的系統與資料空間，整體系統的組織架構相當順暢。這個就留待下篇文章來分享系統設置心得。

〈Crucial T500 2TB NVMe SSD 升級實錄：桌面主機系統碟效能優化〉這篇文章最早發佈於《Kenmingの鮮思維》。

以下整理學員提出的五個問題。
我會先以簡化標題呈現問題主題，再保留原始提問內容，並逐一說明我的看法與建議。

Q1 既有系統新增功能時，需求文件應更新原文件還是建立新文件再提交給 AI？

學員原始提問：

若系統已正式上線，使用者提出新增功能需求，且該功能可能影響既有作業流程時：
此類變更應持續維護於原有的《功能需求規格書－購物車模組.md》中進行版本更新，
或是僅將新增功能部分獨立整理為新的 .md 文件，再提供 AI 協助處理較為適當？

回覆：建議原則是：
「維持原規格的演進版本，而不是拆散成多份零散文件。」

原因有三：

1. 需求文件本質上是系統契約（System Contract） 若同一模組（例如購物車）持續新增功能，建議仍維護在同一份規格文件中（除非新增功能內容非常繁雜，那是可以另以附件關聯，但本質上仍視為同一份文件），以版本或章節方式演進，例如：

購物車模組功能規格.md
├─ v1 基本功能
├─ v1.1 新增批次加入商品
└─ v1.2 新增優惠券計算

2. 避免知識碎片化 若每次需求都獨立成新文件，長期會導致：

• AI 上下文難以理解整體邏輯
• 人類也很難掌握完整行為

3. AI 的最佳使用方式是「完整上下文（Context）」，而不是片段 AI 在分析需求時，需要看到：

• 原功能
• 新需求
• 既有限制 才能推論哪些地方需要修改。

因此較建議的做法是：

• 核心模組規格 → 維持單一文件版本演進
• 跨模組需求 → 建立新的功能提案文件

Q2 舊 WinForms 系統如何透過 AI 協作重構為 Web 架構？

學員原始提問：

若既有系統為 C# WinForms 架構且已上線運作，未來計畫全面改為 Web 架構（例如 React + FastAPI），
若希望透過 AI 協作進行重構或翻寫，建議應採取何種步驟或策略，較能確保品質與效率？

回覆：建議不要直接讓 AI「翻寫整個系統」，而是採取分階段重構策略：

Step 1：先抽出 Domain / Business Rules / 資料存取方式

先整理系統中真正重要的部分：

• 資料模型
• 業務規則
• 使用情境（Use Cases）

這些是系統真正的核心資產。

Step 2：建立新系統的架構骨架

例如：

Frontend
  React
Backend
  FastAPI
  Application Services
  Domain
  Infrastructure

這個骨架應由開發人員先行架構規劃設計，並採以 POC（Proof Of Concept）方式驗證可行性，而不是讓 AI 自由生成。

Step 3：逐步轉譯 Use Case

例如：

WinForms
AddProductToCart()

→ 轉為

API
POST /cart/items

此時 AI 很適合協助：

• 轉譯 UI 行為
• 產生 API contract
• 生成資料模型

Step 4：逐步功能模組遷移

不要一次遷移整個系統，而是：

Cart module
Order module
Inventory module

採逐步功能模組的替換策略。簡單說：

AI 適合協助「轉譯與實作」，
但架構設計與結構分解仍應由開發者主導。**

Q3 前後端規格文件應合併還是分開提供給 AI？

學員原始提問：

課程中前後端皆以不同 .md 文件進行功能規範與描述。
當有新的功能需求時，應整合為單一需求文件交由 AI 執行，
或仍建議以前後端分開的方式，分別提供給 AI 處理較佳？

回覆：「整體需求文件 + 前後端細分規格」

P.S. 這裡可能有一點理解上的落差，我稍微補充說明一下：

在課程中前面章節其實有先提供「情境需求描述」與「系統功能規格書」，
這是從需求分析的角度來看系統，因此在這個階段通常不會區分前端或後端。

學員所看到的前後端 .md 文件，其實已經是「系統開發規格」
的層次，主要是為了讓 AI 在實作程式碼時，能夠有更清楚的上下文與責任邊界。

feature-cart.md （整體需求）
frontend-cart.md （前端需求）
backend-cart.md （API / Service）

原因：

• 1. 整體文件提供上下文
• 2. 分文件方便各自實作

實務上 AI 也較容易理解：

• 前端只需載入 frontend spec
• 後端只需載入 backend spec

Q4 系統文件是否應與程式碼一起放入 Git？

學員原始提問：

系統相關文件是否建議與程式碼一併納入 Git 版本控制管理？

回覆：強烈建議放入 Git。

原因如下：

1. 文件本身就是系統資產

在 AI 協作開發中：

AGENTS.md
技術規格
架構說明

都是 AI 的重要上下文。（這也是課程中強調「將 AI 規範版本化」的原因。）

2. 文件需要版本歷史

可以追蹤：

• 需求如何演進
• 哪個版本改了什麼

3. 避免文件與程式碼脫節

同一 repo 能確保：

• 規格
• 程式碼
• 文件

同步演進。

Q5 大型舊專案缺乏文件時，如何導入授課所教授的方法（迭代與漸增）？

學員原始提問：

若為老舊大型專案且缺乏完整文件，應如何套用今日課程所介紹的方法進行重整與導入？

回覆：建議不要嘗試一次補齊所有文件，而是採取：

「逆向建立最小知識結構」

建議步驟如下：

Step 1：先建立一份 system-overview.md

內容只需包含：

• 系統目的
• 主要模組
• 技術架構

Step 2：建立 模組級文件

例如：

modules/
cart.md
order.md
product.md

描述：

• 功能
• 資料
• API

Step 3：利用 AI 進行「輔助整理」

例如：

• 解析 controller
• 推測 API
• 產生資料模型文件

但需要工程師審核。

Step 4：逐步導入規範文件

例如：

AGENTS.md
architecture.md
coding-guidelines.md

讓 AI 之後能在可控環境下協作。

最後補充一個觀念：

文件不是為了 AI 而寫。 文件是為了「讓系統知識可被管理」。

AI 只是讓這些知識能被更有效率地使用。

〈AI Agent 標準化開發基礎課程 Q&A：AI 協作開發的實務問題與建議〉這篇文章最早發佈於《Kenmingの鮮思維》。

目前 Claude Code 並未將 AGENTS.md 視為自動載入的標準檔案。這意味著即便 AGENTS.md 位於儲存庫（Repository）根目錄，Claude Code 也不會因其檔名而主動將其納入推理的上下文（Context）之中。

在 Claude Code 的生態系中，CLAUDE.md（或位於 .claude/CLAUDE.md）才是定義 Agent 行為與技術規範的標準入口。其核心價值在於提供「專案持久化記憶」（Project Memory）—— 這是一份專為 AI 撰寫的「專案說明書」。

一個問題的主要思考：如果這個專案可能會交叉應用 VS Code Copilot 以及 Claude Code 作為 AI 輔助開發的工具，那麼是否可以共用原來 Copilot 所定義好的 AGENTS.md + copilot-instructions.md 行為與技術規格？

 先給解決方案：使用 模組化映射（Modular Mapping）。

行為與技術規範的模組化映射

VS Code 所使用標準化的 AGENTS.md（以及 copilot-instructions.md），可以透過 Claude Code 的模組化映射（Modular Mapping）方式，以達成相同的效果：

• 行為中樞：CLAUDE.md  對應並載入 AGENTS.md（定義 Agent 如何行動）。
• 技術約束：.claude/rules/ 模組  對應並導入 copilot-instructions.md（定義專案技術規格與規則）。

一個基本 Claude Code 的專案規範的目錄結構：

your-project/
├── .claude/
│   ├── CLAUDE.md           # Main project instructions
│   └── rules/
│       ├── code-style.md   # Code style guidelines
│       ├── testing.md      # Testing conventions
│       └── security.md     # Security requirements

CLAUDE.md 與 .claude/rules/ 檔案設置

在 ./.claude/CLAUDE.md 中可以使用（@path）導入方式引用 AGENTS.md 檔案。

# Claude Code 專案記憶入口
## Agent 行為規範
@AGENTS.md

此外在 .claude/rules/ 目錄（該目錄所有 .md 檔案會自動載入）下可以有多個技術規範檔案以作為模組化映射。

這裡簡化為只有一個技術規格檔：tech-stack.md，並且讓其映射 copilot-instructions.md 所記載的技術堆疊。

# Tech Stack & Coding Conventions
> 本檔案定義專案的技術約束與開發慣例。
## 核心技術規範
為了維持與專案全域開發標準的一致性，請完整遵循：
- **技術棧與架構約束**：@.github/copilot-instructions.md

驗證 CLAUDE.md 與 rules 的規範設置

利用 VS Code 開啟終端機並執行 Claude Code（CLI）後，在對話欄內輸入：

- 本專案的核心技術規範紀錄在哪一個檔案內？

- 本專案在修改程式碼時需遵循的行為原則？

如果回覆內容確實對應並記載於 .claude/ 資料夾內的 CLAUDE.md 與 rules/tech-stack.md，即表示以上設置步驟正確，且規範已成功載入。

透過上述配置，我們能完美實現 Claude Code AGENTS.md 的檔案映射，讓專案管理更加自動化。

補充說明

為了方便進一步對照與理解，我已將本文提到的 AGENTS.md、copilot-instructions.md、CLAUDE.md 、tech-stack.md 等相關檔案，整理成一份 Gist，並附上四個實際範例檔案，說明它們在 VS Code Copilot 與 Claude Code 中的角色分工與關係。

〈AGENTS.md × CLAUDE.md：讓 Claude Code 與 VS Code 共用行為規範的實務做法〉這篇文章最早發佈於《Kenmingの鮮思維》。