我的 Obsidian Vault CLAUDE.md 原文¶
摘要¶
本頁是 vault 根目錄 CLAUDE.md 的公開版原文附錄，治理 AI 維護知識庫時的資料夾權限、Ingest／Query／Lint 與 MkDocs 發布條件。本文版本為 2026-05-28；公開部分保留可分享的維運規則，原文所界定的私人筆記與未公開內容則不屬於公開操作範圍。
制度設計與使用方式見用 CLAUDE.md 把 AI 變成你的 Obsidian 知識庫維護者；亦可取得原始文字下載版。
引用的公開原文（展開檢視）
下列文字逐字保留為公開版 CLAUDE.md 的引用證據；以 markdown 原始碼呈現，避免其內部結構干擾本頁層級。
# LLM Wiki — 操作說明（給 Claude 看的）
這是一個由 LLM 維護的知識庫，概念來自 Andrej Karpathy 的 LLM Wiki 設計。
你（Claude）是這個 wiki 的**唯一維護者**。每次操作都要遵守以下規則。
---
## 本檔定位與 coding guidelines 分流
本檔只管理 **D:\知識庫 Obsidian Vault** 的操作規則：資料夾權限、Wiki ingest/query/lint、知識整理、MkDocs/GitHub Pages 發布條件。
Andrej Karpathy / multica-ai 的 coding 行為準則已獨立保存於：
- `_system/spec/claude-coding-guidelines.md`
- 原始來源：`https://github.com/multica-ai/andrej-karpathy-skills/blob/main/CLAUDE.md`
使用規則：
- 維護本知識庫、整理筆記、發布 docs 時，**優先遵守本檔**。
- 進行 coding 任務、修改 scripts、或整理其他 coding repo 的 `CLAUDE.md` 時，**引用 `_system/spec/claude-coding-guidelines.md`**。
- 不要把 coding-first 規則直接混入本檔主體，避免與 vault-specific 權限規則混淆。
---
## 資料夾結構
```
D:\知識庫\
├── 📥 Sources/ ← 原始資料（文章、PDF、筆記），不要修改
├── 📚 Wiki/ ← 你維護的知識頁面（markdown）
├── 📝 Notes/ ← 使用者自己的筆記，你不要動
└── CLAUDE.md ← 本文件（你的操作手冊）
```
---
## Wiki 頁面類型
每個 Wiki 頁面屬於以下類型之一，用 frontmatter 標記：
```yaml
---
type: concept # 抽象概念、方法論、框架
type: entity # 具體事物：人、公司、工具、資料集
type: synthesis # 跨來源的綜合分析
type: timeline # 事件時序整理
---
```
頁面命名規則：使用**繁體中文**，簡短清楚。例：`注意力機制.md`、`Andrej Karpathy.md`。
---
## 操作 1：Ingest（消化新資料）
當使用者說「幫我消化這篇」或把檔案放進 `📥 Sources/` 時：
1. 閱讀來源文件
2. 找出其中的**實體、概念、主張、數據**
3. 對每個重要項目：
- 若 `📚 Wiki/` 已有對應頁面 → **更新**該頁面（加入新資訊，保留舊資訊）
- 若沒有 → **新建**頁面
4. 在每個更新/新建的頁面底部加上來源標記：
```
**來源**：[文件名稱]（消化於 YYYY-MM-DD）
```
5. 更新 `📚 Wiki/_Index.md` 的頁面清單
**黃金原則**：Wiki 是累積的。絕不刪除舊資訊，只增加與修正。
---
## 操作 2：Query（回答問題）
當使用者問問題時：
1. 讀取 `📚 Wiki/_Index.md` 確認有哪些頁面
2. 讀取相關頁面
3. 從 wiki 內容合成答案
4. 若分析過程中有新洞見，可主動新增一個 `type: synthesis` 頁面
---
## 操作 3：Lint（健康檢查）
當使用者說「幫我做 lint」時：
1. 列出所有 Wiki 頁面
2. 找出：
- 互相矛盾的主張
- 過時資訊（有明確日期可判斷）
- 孤兒頁面（沒有被其他頁面連結）
- 明顯的資訊缺口
3. 產出報告，逐條列出問題與建議修正方式
---
## 格式規範
- 內部連結用 Obsidian 語法：`[[頁面名稱]]`
- 每個頁面最上方必須有 frontmatter（type 欄位）
- 用 `## 小節標題` 組織內容，不要用超過三層標題
- 數字、來源、日期要精確，不要模糊帶過
---
## 禁止事項
- 不得修改 `📥 Sources/` 內的任何檔案
- 不得修改 `📝 Notes/` 內的任何檔案
- 不得在 wiki 頁面中捏造資訊——若不確定，寫「待確認」
- 不得刪除有來源標記的資訊，只能標注「已更新」或「待驗證」
---
## 新知識工作流：Obsidian → GitHub → MkDocs
本 Vault 的長期目標是：
```text
Claude / Codex / GPT
↓
Obsidian Vault（Single Source of Truth）
↓
GitHub Private Repo（版本控制 / 備份 / 專案管理）
↓
MkDocs（公開知識網站）
↓
GitHub Pages
```
### 目錄角色
- `Inbox/`：所有新知識、AI 研究結果、未整理內容的入口。
- `Knowledge/`：整理完成後的正式知識庫。
- `Projects/`：專案型文件與研究結果。
- `docs/`：MkDocs 公開網站來源，只放可公開、已整理完成的內容。
- `📥 Sources/`：原始資料，不得任意修改。
- `📚 Wiki/`：既有 LLM 維護 wiki，可逐步遷移或與 `Knowledge/` 並存。
- `📝 Notes/`：使用者私人筆記，不得修改。
### AI 產出規則
當使用者提出問題時：
1. 先回答問題。
2. 再產生可保存版本。
3. 轉換成 Obsidian Markdown 格式。
4. 新內容預設先放 `Inbox/`，整理完成後再移至 `Knowledge/`。
### 筆記標準格式
所有正式知識筆記建議包含：
```markdown
---
tags:
- Topic
created: YYYY-MM-DD
source: Claude/Codex/GPT/Hermes
status: draft|complete
publish: false
---
# 標題
## 摘要
## 問題背景
## 核心概念
## 實作範例
## 我的理解
## 延伸閱讀
```
### 發布至 MkDocs 的條件
只有符合以下條件才能移入 `docs/`：
- 已整理完成
- 有摘要
- 有案例或實作範例
- 有自己的理解
- 非草稿
- 不含私人資訊、敏感資料或不適合公開的內容
### 分類規則
正式知識分類在 `Knowledge/`：
- `AI/`
- `DataScience/`
- `MachineLearning/`
- `SQL/`
- `Python/`
- `Statistics/`
- `Trading/`
- `Career/`
- `Projects/`
- `Notes/`
MkDocs 公開網站分類在 `docs/`：
- `ai/`
- `trading/`
- `machine-learning/`
- `projects/`
### Git / GitHub 規則
- GitHub private repo 用於版本控制與備份。
- 不要把大型原始資料、private data、API keys、token、`.env`、資料庫檔放進 Git。
- GitHub Pages 只發布 `docs/` 經 MkDocs 產生的內容。
---
## 公開子集 vs 私人母集（避免重複漂移）
延續「`docs/` 是精選公開子集、Obsidian 為母集」的原則，補充重複管理規則（2026-06-13 立）：
- `docs/` 是 Obsidian 的**精選公開子集**。一篇研究升級進 `docs/` 後，**不要在 📚 Wiki 留同主題的舊複本**；`docs` 為該主題權威版，數字、結論以 `docs` 為準。
- 既有重複舊複本搬到 `📚 Wiki/_archive/`（不刪、可還原；Obsidian `[[wikilink]]` 依檔名解析，搬資料夾不斷連），避免「以為是私料、其實是公開舊版」的混淆。
- 真正只存在 Obsidian、未公開的知識（私人框架、工作筆記、未整理草稿等）才留在 Wiki 主體——這是 Wiki 相對 `docs` 的真正價值。