影片筆記：【知らなきゃ損】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 四大資料夾。

1. 執行工作流：

• 將任務/資料放入對應的「入口」資料夾。
• AI 依據「判斷基準」進行決策與作業，將中間過程記錄於「作業中」區域。
• 人類介入確認（如範例 3 的 PR 確認）。
• 完成品移至「完成品」區域。
• 歷史記錄歸檔至「記憶與保管」區域。

1. 迭代優化：根據實際使用情況，調整資料夾結構或增加新的指示檔。

值得注意的限制或風險

• 結構複雜度：建立多個資料夾與 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）在處理目錄結構時是否有顯著差異？