<!-- Source: https://hermesbible.com/flows/index-md-folder-structure-faster-hermes-agent -->

核心概念

AI 能做的事跟你的設定環境讓它做的事之間有落差——而那個落差通常是你的生產力死亡的地方。同一個能跨整個病毒家族做推理的 Agent，卻會樂意花兩分鐘在你的 vault 裡打開錯誤的檔案，只為了調出三個月前的一份簡報。

罪魁禍首很少是模型本身，而是 Agent 周圍看不見的基礎架構：

資料夾結構是你建造的一個籠子，它限制了 Agent 如何移動，但不限制 Agent 能做什麼。

這個流程是一份真正的 Obsidian vault 解剖報告——它因意外而變得混亂，一個資料夾接一個資料夾，直到 Agent 迷路。修復方法幾乎小得令人尷尬：一個索引檔案加上幾個資料夾名稱前的數字。但這就是一個迷路的 Agent 和一個能工作的 Agent 之間的差別。

Agent 看不到的結構

大多數人按照內容類型組織 vault：文章、研究、素材、策略文件，各放各的資料夾。這看起來很整潔，因為人類用分類來思考——你的大腦會自動做交叉參照，你永遠不用想該去哪裡找。

Agent 不會用分類來思考。當你要求 Hermes 規劃一個產品發布時，這個任務會拉取策略筆記、品牌指南和之前的發布經驗——上下文散落在不同的內容類型資料夾中。Agent 必須每次都到處搜尋，完全不知道哪個草稿是最新版、哪個已經封存，或者哪個筆記是這個月的、哪個是六個月前的。

你 Agent 周圍的結構所做的工作，比 Agent 自身的能力還多。

你為一個記得東西放在哪裡的人腦建造了 vault，然後把它交給一個每次任務都從零開始的搜尋者。搜尋者需要一張地圖——沒有地圖，它會把每個檔案都當成可能的答案。

診斷之後再重組

在觸碰任何資料夾之前，先測量。對你 Agent 最常處理的三個任務跑這項五分鐘測試：

1. 計時每個任務從頭到尾的時間。
2. 統計它打開了幾個檔案才找到正確的。
3. 記錄它多久選錯檔案或停下來問你該用哪個。

任何花超過三十秒、或打開三個以上錯誤檔案的任務，背後都有一個壞掉的資料夾。以下是原始內容類型 vault 中五個常見任務的表現：

*（粗略實驗——把確切數字當方向參考就好。）*每個任務都跨了多個資料夾，而且大多在找到正確版本之前先打開了封存版本。Agent 把它的能力消耗在導航上，而不是實際工作。

解方：最小且有效的籠子

每個主題一個資料夾、用編號排序、在根目錄放一個 INDEX.md 來映射一切。就是這整個修復方法，它由三個協同運作的規則組成。

規則 1——INDEX.md 作為地圖（也是軟性審核關卡）

在每個主要資料夾的根目錄放一個 INDEX.md。它列出所有子資料夾和標準檔案，以及 Agent 應該從哪裡開始。Agent 會首先讀取這個檔案，在碰任何東西之前就知道裡面有什麼——把它想像成一個軟性關卡，Agent 在知道自己要處理什麼之前，不被允許開始工作。

# Brand Index

This folder holds the current brand system.

## Folder Map

| Folder | Purpose | Updated |
|---|---|---:|
| `01.Brand System/`      | Visual identity, topic scope, voice | 2026-06-11 |
| `02.Editorial Strategy/`| Article direction, title rules, queue | 2026-06-11 |
| `03.Promotion/`         | Launch, distribution, tool strategy | 2026-06-11 |

## Canonical Files

| File | Purpose |
|---|---|
| `01.Brand System/01. Brand System.md`   | Visual identity, colors, typography |
| `02.Editorial Strategy/01. Articles.md` | Article queue, title rules |

## Where To Go

- Start with `01.Brand System/04. Direction.md` for mission
- Use `02.Editorial Strategy/01. Articles.md` for article selection

INDEX.md 經過三個版本才到這裡。第一版列出了每個檔案，長到四十行——很完整，但長度本身就是開銷。第二版只有約 15 行，太短了，Agent 還是會問問題。這第三版只列出子資料夾和標準檔案，加上一個簡短的「去哪裡」章節標出起始點。

規則 2——每個資料夾一個主題

按照主題組織，而不是內容類型。每個主題有自己的資料夾，品牌工作和品牌工作放在一起，策略和策略放在一起。Agent 不會跨越邊界去找不屬於那裡的東西。

05.Brand/
├── INDEX.md
├── 01.Brand System/
├── 02.Editorial Strategy/
├── 03.Promotion/
├── 04.Public Deliverables/
├── 05.Operating Plan/
└── 06.Archived/

封存的資料放在 06.Archived/，舊的簡報和退役的計畫在那裡等待。Agent 知道除非你特別要求歷史上下文，否則不要去那裡——你在 INDEX.md 中記下這條規則，讓它知道歷史資料放在哪裡。這種分離保持了使用中的資料夾乾淨，搜尋速度快。

規則 3——用編號標記資料夾和檔案的閱讀順序

編號讓閱讀順序明確，而不是依賴字母排序。01.Brand System 會在 02.Editorial Strategy 之前被讀取；Agent 不用猜測。資料夾內部的編號對檔案也是一樣的，所以 Agent 知道 01. Articles 是起始點，02. Previous Articles 在後面。額外的好處是：前導編號讓你也更容易記住結構。

成效

重組之後，同樣五個任務——模型沒有任何改變：

最慢的任務從兩分鐘降到二十六秒，最快的任務大約十秒。Agent 打開 INDEX.md、跟著它需要的起始點、然後直接開始工作，不會迷路。能力沒有改變——資料夾結構只是不再在任務開始前就浪費掉大部分的能力。

花時間的錯誤

• **在每個子資料夾都放 INDEX.md。**地圖太多意味著 Agent 讀索引而不是做事。只在有足夠子資料夾需要地圖的主要資料夾根目錄保留 INDEX.md。一個只有四、五個檔案的小子資料夾根本不需要地圖。
• **在 Agent 顯示困惑之前就建結構。**大多數人過度工程化自己的設定。只在 Agent 迷路時才加結構，而且只加足夠修復特定問題的程度——能完成工作的最小介面。
• **在結構內部再嵌套結構。**子資料夾裡面的子資料夾把兩層層級變成五層，迫使 Agent 為了一個檔案解析多個 INDEX 檔案和編號序列。把多餘的層級壓回平面子資料夾。深度是快速檔案查詢的敵人。
• **追求完美的編號。**在最後面追加新資料夾而不是重新編號所有東西是沒問題的——編號只需要有方向性。把完美順序當成目標，會把一個實用的修復變成美化專案。

仍有局限的地方

• 封存內容仍然會被作為上下文引用，所以 INDEX.md 必須告訴 Agent 歷史資料放在哪裡——否則它會假設封存內容不存在。
• Obsidian Sync 可能會提供過時的副本：在你的筆電上編輯檔案時，較舊的版本可能還在你的 VPS 上，而 Hermes 可能把 VPS 副本當作事實來源。這是同步問題，但它會在資料夾系統內部浮現，因為 Agent 只看到眼前的檔案。
• 編號在單一層級超過約 10–12 個項目時會失效，此時序列變得任意。把頂層類別保持在該門檻以下，需要時就往深處嵌套。
• **重新命名會破壞引用。**任何指向舊資料夾名稱的 INDEX.md 指標都會失效，直到你更新它，所以設定一次資料夾名稱就不要再動——一個稍微彆扭的名稱比一個壞掉的引用代價更低。
• 這個模式最適合內容密集和規劃密集的工作流程。純粹的程式碼或資料密集的設定可能需要完全不同的組織原則。

為什麼重要

這裡的一切都追溯到一個直覺：**掌握真正重要的那一層。**打造你的技術堆疊讓沒有公司能控制你的工具；打造你的 vault 讓沒有混亂能控制你的 Agent。從供應商到資料夾，都是同一個原則。

當周圍的基礎架構壞掉時，能力是很便宜的。建造好基礎架構，能力自然會跟上。一個索引檔案和幾個資料夾名稱前的編號，就是一個迷路的 Agent 和一個能工作的 Agent 之間的差別。