# 影片筆記：Obsidian AI 知识库第 1 步：从 0 搭建最小可用系统，跑通 2 个真实场景｜PARA｜Claudian

## 一句話總結

本影片示範如何搭建 Obsidian AI 知識庫的「最小可用版」，透過類似 PARA 的目錄結構與 CLI Agent 插件接入，跑通「資料輸入、AI 處理、知識沉澱、產生輸出」的核心路徑，並演示了「積累型」與「項目型」兩個真實場景的操作流程。

## 核心重點

1.  **最小可用版理念**：不追求一步到位的全自動化，避免初期系統過於複雜導致維護困難與 AI 幻覺。優先確保跑通關鍵路徑：資料進入 -> AI 處理 -> 知識沉澱 -> 產生輸出。
2.  **架構設計（類 PARA）**：
    *   資訊進入後，優先考慮「服務什麼」而非「屬於什麼主題」。
    *   目錄結構包含：收件箱（Inbox）、項目（Projects）、領域（Areas）、資源（Resources）、歸檔（Archive）、模板（Templates）、附件（Attachments）。
    *   資料流向：收件箱 -> 資源/項目 -> 歸檔。
3.  **技術接入流程**：
    *   使用 Obsidian 插件（如 Cloudian/Codex）結合 CLI Agent（如 Codecli）。
    *   透過本地終端測試對話後，在 Obsidian 內啟用 AI 服務。
4.  **實戰場景演示**：
    *   **積累型場景**：透過 Web Clipper 將網頁轉為 Markdown 存入收件箱，利用 AI 總結並建立雙鏈，將關鍵觀點沉澱至「領域」。
    *   **項目型場景**：從每日筆記產生想法，建立項目索引文件，利用 AI 拆解背景、分析、輸出及常見問題，最終生成文章與可視化圖表，並回傳至項目文件。
5.  **核心價值**：透過雙鏈串聯原始資料、分析內容與長期知識，實現知識從輸入到輸出的閉環。

## 詳細大綱

### 一、 觀念與架構設計

1.  **最小可用版理念**
    *   避免一開始追求全自動化導致難維護與 AI 幻覺。
    *   優先跑通關鍵路徑：資料進入 -> AI 處理 -> 知識沉澱 -> 產生輸出。
    *   複雜系統（如自生長、全自動化）可後續迭代。
2.  **Obsidian 本地知識庫結構**
    *   核心邏輯：資訊進來後，先問「服務什麼」而非「屬於什麼主題」。
    *   目錄結構參考：
        *   **收件箱 (Inbox)**：臨時入口，降低輸入門檻。
        *   **項目 (Projects)**：正在推進的具體項目。
        *   **領域 (Areas)**：長期維護的能力與判斷。
        *   **資源 (Resources)**：長期參考資料。
        *   **歸檔 (Archive)**：結束或暫不使用的內容。
        *   **模板 (Templates)**：常用模板。
        *   **附件 (Attachments)**：圖片、PDF 等素材。
    *   資料流向：收件箱 -> (整理後) -> 資源/項目 -> (完成後) -> 歸檔。

### 二、 AI 能力接入流程

1.  **架構組成**
    *   知識庫：Obsidian 本地倉庫（Markdown 文件與目錄）。
    *   連接器：Obsidian 插件（文中提及 Cloudian/Codex）。
    *   執行者：CLI Agent（命令行代理）。
2.  **五步實作流程**
    *   **步驟 1**：選擇 CLI Agent（如 Cloud Code, Codecli, OpenCode）。
    *   **步驟 2**：完成登錄或使用第三方模型轉接（如 CC-Switch）。
    *   **步驟 3**：在終端測試 Agent 是否正常對話。
    *   **步驟 4**：在 Obsidian 中啟用對應插件（如 Codex 標籤）。
    *   **步驟 5**：讓 AI 讀取當前筆記並進行總結，驗證最小驗證流程。

### 三、 真實場景演示

1.  **場景一：積累型（資料轉知識）**
    *   **輸入**：使用 Obsidian Web Clipper 將網頁轉為 Markdown 存入「收件箱」。
    *   **處理**：
        *   將筆記從收件箱轉移至「資源」。
        *   在筆記中新增「內容總結」標題。
        *   指令 AI 總結文章並更新至此標題下。
    *   **輸出/沉澱**：
        *   檢視 AI 總結，提取有價值的觀點。
        *   在「領域」建立長期筆記（如 Obsidian 學習）。
        *   將關鍵觀點整理進去，並保留原始資料的雙鏈。
2.  **場景二：項目型（知識服務目標）**
    *   **輸入**：從每日筆記記錄想法，建立項目索引文件（Index）。
    *   **結構規劃**：建立背景、分析、輸出、常見問題四個一級標題。
    *   **處理**：
        *   指令 AI 根據問題提供研究方向。
        *   指令 AI 在「常見問題」區域新建 Q&A 筆記並添加雙鏈。
        *   收集資料進入收件箱後，指令 AI 將資料遷移至「資源」並鏈接至「背景」。
        *   指令 AI 基於背景資料總結關鍵要點至「分析」。
        *   指令 AI 基於要點生成短文章至「輸出」。
        *   指令 AI 利用 Skill 生成關係圖，並鏈接至「輸出」。
    *   **輸出**：文章與可視化結果統一管理於項目 Index 文件中。

### 四、 總結與未來展望

1.  **系統價值**
    *   積累型：解決資料從臨時收集變為長期可複用知識。
    *   項目型：解決知識服務具體目標並推動成果形成。
    *   結構價值：資料、領域、項目各有位置，透過雙鏈串聯原始資料、分析與長期知識。
2.  **流程本質**
    *   輸入：資料、想法、需求。
    *   處理：AI 總結、提列、關聯。
    *   輸出：產生價值、推進項目、生成內容或決策。
3.  **未來升級方向**
    *   輸入端：介入更多資料類型（網頁、PDF、視頻、音頻、Lotion 筆記、Word 等）。
    *   處理端：參考卡巴基（Kagi/卡巴西？）知識庫思想，讓 AI 自動分類整理，人類負責判斷決策。
    *   輸出端：轉化為文章、圖文、PPT、視頻、播客等成果。

## 工具 / 模型 / 名詞整理

*   **Obsidian**：本地知識庫軟體。
*   **Markdown**：筆記文件格式。
*   **AI Wiki / AI Viki**：文中提及的概念或系統名稱。
*   **Agent 系統**：代理系統。
*   **卡巴西知識庫**：文中提及的知識庫思想來源。
*   **Codex**：文中提及的 AI 模型或服務名稱（多次出現，如 Codex CLI, Codex 服務商）。
*   **Hermes Agent**：文中提及的 Agent 工具。
*   **OpenCloud**：文中提及的 Agent 工具。
*   **Cloudian / Cloudium**：文中提及的 Obsidian 插件名稱。
*   **CLI Agent**：命令行代理。
*   **Cloud Code**：文中提及的 CLI Agent 選項之一。
*   **Codecli**：文中演示選擇的 CLI Agent。
*   **OpenCode**：文中提及的 CLI Agent 選項之一。
*   **CC-Switch**：用於轉接第三方模型的工具。
*   **Codex CLI**：命令行接口工具。
*   **DBT5.5**：文中提及的模型版本或名稱。
*   **Obsidian Web Clipper**：網頁剪藏插件。
*   **Clippings**：文中提及的資料保存路徑或文件夾名稱。
*   **卡巴基**：文中提及的知識庫思想來源。
*   **Lotion**：文中提及的筆記類型。

## 操作流程整理

### 通用 AI 接入流程
1.  選擇 CLI Agent（如 Cloud Code, Codecli, OpenCode）。
2.  完成登錄或使用第三方模型轉接（如 CC-Switch）。
3.  在終端測試 Agent 是否正常對話。
4.  在 Obsidian 中啟用對應插件（如 Codex 標籤）。
5.  讓 AI 讀取當前筆記並進行總結，驗證最小驗證流程。

### 場景一：積累型操作流程
1.  **輸入**：使用 Obsidian Web Clipper 將網頁轉為 Markdown 存入「收件箱」。
2.  **轉移**：將筆記從收件箱轉移至「資源」。
3.  **標記**：在筆記中新增「內容總結」標題。
4.  **AI 處理**：指令 AI 總結文章並更新至此標題下。
5.  **沉澱**：
    *   檢視 AI 總結，提取有價值的觀點。
    *   在「領域」建立長期筆記（如 Obsidian 學習）。
    *   將關鍵觀點整理進去，並保留原始資料的雙鏈。

### 場景二：項目型操作流程
1.  **輸入**：從每日筆記記錄想法，建立項目索引文件（Index）。
2.  **結構規劃**：建立背景、分析、輸出、常見問題四個一級標題。
3.  **AI 輔助規劃**：
    *   指令 AI 根據問題提供研究方向。
    *   指令 AI 在「常見問題」區域新建 Q&A 筆記並添加雙鏈。
4.  **資料處理與沉澱**：
    *   收集資料進入收件箱後，指令 AI 將資料遷移至「資源」並鏈接至「背景」。
    *   指令 AI 基於背景資料總結關鍵要點至「分析」。
5.  **產出生成**：
    *   指令 AI 基於要點生成短文章至「輸出」。
    *   指令 AI 利用 Skill 生成關係圖，並鏈接至「輸出」。
6.  **最終管理**：文章與可視化結果統一管理於項目 Index 文件中。

## 值得注意的限制或風險

1.  **AI 幻覺風險**：影片強調避免初期追求全自動化，因為複雜系統容易導致 AI 幻覺，建議先跑通最小驗證流程。
2.  **維護成本**：全自動化系統若設計不當，可能導致維護困難。
3.  **工具鏈混亂**：逐字稿中對於 CLI Agent 的選擇（Cloud Code, Codecli, OpenCode）以及登錄方式（Codex CLI）的描述較為混亂，實際操作時需確認工具鏈的正確名稱與邏輯。
4.  **辨識錯誤風險**：部分工具名稱、模型名稱及術語在逐字稿中存在疑似聽寫錯誤（如 Cloudian/Codex 混用、卡巴西/卡巴基、Lotion 筆記等），實際搭建時需查證正確名稱。

## 逐字稿辨識疑點

*   **卡巴西知識庫**：逐字稿出現「卡巴西知識庫」，後續又出現「卡巴基的知識庫思想」。需查證是否為特定知識管理方法論（如 PARA 的誤聽或特定作者名稱）。
*   **AI Viki**：逐字稿出現「AI Viki 自身長知識庫」，需查證是否為特定產品或模型名稱。
*   **OpenCloud**：逐字稿提及「OpenCloud 這類 Agent 的工具」，需查證是否存在此名稱的 Agent 工具。
*   **Cloudian / Cloudium**：逐字稿中插件名稱在「Cloudian」、「Codex」、「Cloudium」之間混用。通常 Obsidian 中對接 Codex 的插件名為 "Codex" 或 "Obsidian-Codex"。需查證正確插件名稱。
*   **DBT5.5**：逐字稿提及「模型切換到當前可用模型 DBT5.5」，需查證是否為特定模型版本或聽寫錯誤。
*   **Lotion 筆記**：逐字稿提及「Lotion 筆記」，需查證是否為特定筆記軟體名稱（如 Logseq 的誤聽）。
*   **Codex 與 Codecli**：逐字稿中對於 CLI Agent 的選擇（Cloud Code, Codecli, OpenCode）以及登錄方式（Codex CLI）的描述較為混亂，需查證具體工具鏈的正確名稱與操作邏輯。
*   **Obsign**：逐字稿最後提及「Obsign 這條結構」，應為 Obsidian 的聽寫錯誤。
*   **常眾問題**：逐字稿提及「選擇常眾問題這個區域」，應為「常見問題」的聽寫錯誤。
*   **克勞利亞**：逐字稿提及「克勞利亞日常調用 AI 的時候」，應為插件名稱（如 Codex 或 Cloudian）的聽寫錯誤。
*   **調查器**：逐字稿提及「調查器操作更加複雜」，需查證是否為特定工具名稱或聽寫錯誤。
*   **要剪辑要精力要罗列**：逐字稿中 AI 指令或反饋出現「要剪辑要精力要罗列」，語意不明，需查證是否為聽寫錯誤（如「要精簡、要精煉、要羅列」）。

## 可延伸追問

1.  如何具體配置 CC-Switch 來轉接第三方模型？
2.  在「積累型場景」中，如何設定自動化規則以減少手動轉移筆記至「資源」的步驟？
3.  「卡巴基」或「卡巴西」知識庫思想具體指什麼？是否有相關文獻或工具推薦？
4.  針對「項目型場景」，若資料量龐大，如何優化 AI 生成關係圖（Skill）的準確性與效率？
5.  未來升級輸入端時，處理視頻、音頻等多媒體資料的具體技術方案為何？