# 影片筆記：【知らなきゃ損】CodexやClaude Codeの力を最大限引き出すAIのフォルダ設計を教えます


<!-- VIDEONOTE_PUBLICATION_WARNINGS_BEGIN -->
## ⚠️ 全文快速校讀發現待確認修正

本筆記已完成可閱讀的逐字稿與時間跳轉；下列為待處理問題，建議播放原片確認。

- 待修正：⚠️ 全文快速校讀發現未解決異常（segment=0 待確認：複数の名詞が連続しており、区切りが不明確。ASRによる単語連結の可能性が高い。；暫定：ヒアリング契約書案書納品物；segment=1 待確認：文脈的に専門用語として成立している可能性が高いが、ASR特有の表記揺れである可能性も残る。；暫定：非公開ワークスペース）
- 待修正：逐字稿可先使用，但有待校正清單（segment=18 unnatural_sentence_boundary: 標點出現在句首或停在逗號位置，斷句可能不符合文法/口語；segment=34 unnatural_sentence_boundary: 標點出現在句首或停在逗號位置，斷句可能不符合文法/口語）

<!-- VIDEONOTE_PUBLICATION_WARNINGS_END -->

## 一句話總結
影片指出，AI 程式設計助手（如 Codex 或 Claude Code）的表現差異不僅來自模型或提示詞，更取決於「資料夾結構設計」。講師今（Ima）提出將目錄視為 AI 的工作環境（Harness），透過五種不同的目錄結構範例（如指示分割型、LLM Wiki 型、Human Layer 型等），教導使用者如何明確區分資訊入口、判斷基準、作業區與完成品，以解決指示過長、資料混亂或 AI 跳過規劃等痛點。

## 核心重點
*   **目錄即工作環境**：資料夾設計不僅是檔案整理，更是 AI 代理（Agent）的工作場所。AI 看到的目錄結構、檔案命名及成果物位置，直接影響其工作表現。
*   **五種基本角色**：良好的目錄結構應明確區分以下五個部分：
    1.  **入口**：AI 開始工作的地方。
    2.  **判斷基準**：AI 決策的依據與規則。
    3.  **作業中**：中間過程、筆記與判斷的存放處。
    4.  **完成品**：最終成果交付的位置。
    5.  **記憶與保管**：長期記憶、歷史記錄與歸檔。
*   **按需選擇結構**：沒有單一正解，應根據自身痛點選擇對應的目錄設計範例：
    *   指示過長 -> 範例 1（指示分割型）。
    *   資料多但無法整理 -> 範例 2（LLM Wiki 型）。
    *   AI 直接跳過規劃 -> 範例 3（Human Layer 開發運用型）。
    *   規則混雜 -> 範例 4（OpenCR 型）。
    *   交付不明確 -> 範例 5（Codex 秘書型）。
*   **最小構成建議**：若無特定需求，至少建立「入口、判斷基準、作業中、完成品」四個角色，並透過檔案移動反映工作狀態。

## 詳細大綱

### I. 核心觀念：目錄即工作環境
*   **常見誤區**：認為 AI 表現差異僅源於模型、提示詞（Prompt）或技巧。
*   **關鍵事實**：差異源於「AI 看到的目錄結構」、「檔案命名」及「成果物歸還位置」。
*   **比喻**：
    *   混亂的倉庫：AI 無法分辨參考資料、最新狀態、判斷基準及完成品位置。
    *   明確的工作區：明確區分資料接收、判斷基準、作業區與完成區，AI 才能順暢工作。
*   **結論**：目錄是檔案的整理櫃，也是交給 AI 的工作場所。設計目的在於讓 AI 能探索、判斷、作業並順利交接。

### II. 五種目錄結構設計範例解析

#### 範例 1：指示分割型（基於 Boris Češnjik 氏方針）
*   **適用情境**：希望將龐大指示書（Instructions）拆分，避免每次載入過多資訊。
*   **結構特點**：
    *   **三層結構**：專案層級、領域層級、技能層級。
    *   **`.cloud.md` (或類似指示檔)**：
        *   專案頂層：僅包含全局通用規則（專案目的、禁止觸碰區域、成果保存位置）。
        *   領域資料夾內：僅包含該領域專屬規則（如：內容創作領域的受眾定義、術語解釋規則）。
    *   **`skills` 資料夾**：僅在執行特定任務時才讀取的詳細步驟（如：YouTube 腳本製作步驟、審查項目）。
*   **核心邏輯**：不刪除指示，而是**區分讀取時機**。每次僅讀取「薄層」的全局規則，特定任務時才讀取對應領域規則，極簡任務時僅讀取技能步驟。

#### 範例 2：LLM Wiki 型（基於 Andrej Pesic 氏方針）
*   **適用情境**：解決「資料增加但無法轉化為可用知識」的問題。
*   **結構特點**：
    *   **`Raw` 資料夾**：存放原始資料（文章、論文、數據、圖片），作為證據，不允許 AI 修改。
    *   **`Wiki` 資料夾**：存放整理後的知識。
        *   `index.md`：目錄入口。
        *   `log.md`：更新歷史記錄。
        *   各頁面：概念整理、比較分析等。
    *   **`agent.md`**：定義 AI 處理 Wiki 的規則（如：原始資料不修改、Wiki 格式、如何更新 index 與 log）。
*   **核心邏輯**：區分「原始證據」與「整理後的知識」。透過 `index` 快速定位，避免每次閱讀所有原始資料。知識化流程：Raw 輸入 -> 檢查 Wiki 相關頁面 -> 新建或更新 Wiki 頁面 -> 更新 index 與 log。

#### 範例 3：Human Layer 開發運用型
*   **適用情境**：解決 AI 未充分理解前提就直接生成完成品，導致大量返工的問題。
*   **結構特點**：
    *   **`Sources` 資料夾**：
        *   個人領域：包含 Ticket（工單/任務）與 Notes。
        *   `Shared` 資料夾：團隊共享區。
            *   `Research`：調查結果（Markdown 格式，含日期/案件名）。
            *   `Plans`：執行前計劃（變更點、順序、確認點、完成標準）。
            *   `PRs` (Pull Requests/確認區)：實際變更內容或需人類確認事項。
*   **核心邏輯**：強制區分「調查」與「計劃」。
    *   流程：Sources 調查 -> Plans 計劃 -> **人類確認** -> 實際作業/完成品。
    *   強調：調查結果與計劃本身也是成果物，透過早期人類介入防止錯誤擴大。

#### 範例 4：OpenCR 型（Open Cursor 風格）
*   **適用情境**：解決業務規則、工具使用、長期記憶混雜在同一個檔案中的問題。
*   **結構特點**：
    *   基於不同角色的 Markdown 檔案分工：
        *   `Soul.md`：AI 的行為姿態/語氣。
        *   `Identity.md`：AI 的名稱與角色。
        *   `User.md`：合作對象（人類）的資訊與偏好。
        *   `Agent.md`：接受委託後的工作流程。
        *   `Tools.md`：使用的工具與注意事項。
        *   `Memory.md`：長期應保留的事實與決定。
        *   `Habit.md`：定期確認事項。
        *   `Memory/`：按日期記錄的日常作業細節。
*   **核心邏輯**：將記憶與資訊分類存放，避免重要資訊被埋沒。若語氣錯誤查 `Soul`，流程錯誤查 `Agent`，資訊過時查 `Memory`。明確區分「人格」、「對象」、「流程」、「工具」、「長期記憶」與「日常記錄」。

#### 範例 5：Codex 秘書型（講師今氏自創）
*   **適用情境**：作為 AI 秘書使用，明確區分委託接收與成果交付。
*   **結構特點**：
    *   頂層：`agent.md`（業務規則：接收順序、作業流程、成果返還位置）與 `soul.md`（姿態/語氣）。
    *   **四大資料夾**：
        *   `Inbox`：接收委託與原始素材。
        *   `Notebook`：作業中的筆記、判斷、下次學習點。
        *   `Outbox`：AI 返回的完成品。
        *   `Archive`：處理完畢的委託與歷史成果。
*   **核心邏輯**：透過檔案移動反映工作狀態。
    *   Inbox (待處理) -> Notebook (作業中) -> Outbox (待人類確認) -> Archive (已完成)。
    *   將一次性對話轉化為可持續的業務流程。

### III. 五種範例的共通點與實踐建議
*   **共通的五個角色**：
    1.  **資訊入口**：資料進入點（Raw, Ticket, Inbox）。
    2.  **判斷基準**：指導 AI 決策的依據（.md 指示檔, 已確認的調查/計劃）。
    3.  **作業中放置處**：中間過程（Wiki 頁面, Research/Plans, Notebook）。
    4.  **完成品去向**：最終交付地（Wiki, Source/Deliverables, Outbox）。
    5.  **記憶與保管**：長期記憶與歸檔（Memory, Archive）。
*   **資訊分離原則**：區分「每次必讀的簡短規則」與「僅在需要時讀取的詳細資料/重資料」。
*   **實踐建議**：
    *   不需一次性建立所有資料夾。
    *   根據痛點選擇對應範例：
        *   指示過長 -> 範例 1（分割型）。
        *   資料多但無法整理 -> 範例 2（Wiki 型）。
        *   AI 直接跳過規劃 -> 範例 3（Human Layer 型）。
        *   規則混雜 -> 範例 4（OpenCR 型）。
        *   交付不明確 -> 範例 5（Codex 秘書型）。
    *   **最小構成建議**：若無特定範例需求，至少建立「入口、判斷基準、作業中、完成品」四個角色。
    *   **核心心法**：目錄不需華麗，重點在於明確「AI 從何開始、依據何判斷、中途留何痕跡、成果交何處、下次繼承何物」。

## 工具 / 模型 / 名詞整理
*   **Claude Code**：影片提及的 AI 程式設計助手。
*   **Codex**：影片提及的 AI 程式設計助手。
*   **OpenCR**：講者提及的特定工作空間風格或專案名稱，與 Open Cursor 概念相關。
*   **LLM Wiki**：講者提及的知識管理方法論。
*   **YouTube**：影片發布平台。
*   **LINE**：講者提及用於發送技能文件（Skills file）的通訊工具。
*   **Pull Request (PR/プルリク)**：講者提及用於確認變更的機制。
*   **Deliverables (デリバラブルズ)**：講者提及的「成果物」資料夾名稱。
*   **Raw / Wiki**：講者使用片假名區分的原始資料與知識庫概念。
*   **Cloud.md / .cloud.md**：講者提及的指示檔命名，疑為特定專案中的規則檔案。
*   **Skills.md / SK.md**：講者提及的技能檔案。
*   **2026y0903.md**：講者舉例的日期檔案格式，年份寫為 2026。

## 操作流程整理
1.  **診斷痛點**：使用者首先需確認自身在使用 AI 程式設計助手時遇到的問題（如：指示過長、資料混亂、AI 跳過規劃、規則混雜、交付不明確）。
2.  **選擇結構範例**：根據痛點選擇對應的目錄結構範例（範例 1 至 5）。
3.  **建立目錄結構**：
    *   若選擇範例 1：建立專案層、領域層、技能層，並設定 `.cloud.md` 與 `skills` 資料夾。
    *   若選擇範例 2：建立 `Raw` 與 `Wiki` 資料夾，設定 `index.md`、`log.md` 與 `agent.md`。
    *   若選擇範例 3：建立 `Sources` 資料夾，區分個人與團隊共享區，設定 `Research`、`Plans` 與 `PRs`。
    *   若選擇範例 4：建立多個角色 Markdown 檔案（`Soul.md`, `Identity.md` 等）及 `Memory` 資料夾。
    *   若選擇範例 5：建立 `agent.md`、`soul.md` 及 `Inbox`、`Notebook`、`Outbox`、`Archive` 四大資料夾。
4.  **執行工作流**：
    *   將任務/資料放入對應的「入口」資料夾。
    *   AI 依據「判斷基準」進行決策與作業，將中間過程記錄於「作業中」區域。
    *   人類介入確認（如範例 3 的 PR 確認）。
    *   完成品移至「完成品」區域。
    *   歷史記錄歸檔至「記憶與保管」區域。
5.  **迭代優化**：根據實際使用情況，調整資料夾結構或增加新的指示檔。

## 值得注意的限制或風險
*   **結構複雜度**：建立多個資料夾與 Markdown 檔案可能增加初始設定成本。
*   **維護負擔**：需定期更新 `index.md`、`log.md` 或 `Memory` 等檔案，否則知識庫可能過時。
*   **AI 理解能力**：若目錄結構設計過於複雜或命名不清晰，AI 可能無法正確理解檔案間的關聯與讀取順序。
*   **人類介入需求**：部分結構（如範例 3）需要人類在特定階段（如計劃確認）進行介入，否則可能導致錯誤擴大。
*   **工具相容性**：不同 AI 助手（如 Codex 與 Claude Code）對目錄結構與指示檔的支援程度可能不同，需確認工具是否支援讀取多層級或特定命名的指示檔。

## 逐字稿辨識疑點
*   **今に (Ima)**：講者自稱名字，聽起來較不尋常，疑為「今井」或其他名字的聽寫錯誤，或為特定暱稱。
*   **ハーネス (Harness)**：講者解釋為「AI 周圍的環境」，對應工程術語 "Harnessing" 或 "Environment Setup"，但用詞較特殊。
*   **ボリスチェルニー氏 (Boris Češnjik?)**：講者提及的開發者名字，聽寫可能為 "Boris Češnjik" 或類似拼寫，需查證具體人名。
*   **アンドレペシ氏 (Andrej Pesic?)**：講者提及的 LLM Wiki 公開者名字，聽寫可能為 "Andrej Pesic" 或類似拼寫，需查證。
*   **DEX 方士 C たちヒューマンレイヤー**：講者提及的第三個範例來源，聽寫極度混亂，疑為 "Human Layer" 相關團隊或專案名稱，具體名稱需查證。
*   **OpenCR**：講者描述為「一時期非常著名的工作空間」，並提到 "Open Cursor" 相關概念，但名稱記錄為 OpenCR，需確認是否為特定工具名稱或口誤。
*   **cloud.MD / .cloud.md**：講者多次提及此檔案名，疑為特定專案中的指示檔命名（如 `.cursorrules` 或 `.claude` 的變體），或為聽寫錯誤（如 `CLAUDE.md`）。
*   **SK.MD / skill.MD**：講者提及技能檔案，聽寫不一致，疑為 `skills.md` 或類似名稱。
*   **ロウ (Raw) / ウキ (Wiki)**：講者使用片假名區分原始資料與知識庫，對應英文 `Raw` 與 `Wiki`。
*   **プルリク (Pull Request)**：講者將 `PR` 解釋為「プルリク」，即 GitHub 等平台的 Pull Request 縮寫，用於確認變更。
*   **デリバラブルズ (Deliverables)**：講者提及的「成果物」資料夾名稱。
*   **2026y0903.MD**：講者舉例的日期檔案格式，年份寫為 2026，可能為口誤或未來範例。

## 可延伸追問
*   如何具體設定 AI 助手（如 Claude Code 或 Codex）以讀取多層級的指示檔？
*   在實際專案中，如何平衡「詳細指示」與「AI 上下文窗口限制」？
*   對於小型專案，是否真的需要建立如此複雜的目錄結構？
*   如何自動化更新 `index.md` 或 `log.md` 等維護性檔案？
*   不同 AI 助手（如 Codex 與 Claude Code）在處理目錄結構時是否有顯著差異？