Claude Code 的第二大腦：如何在一小時內建立結構

Ailoot 參考文件：ailoot.ai/docs/。

Claude Code 為什麼需要第二大腦？哪些內容不可或缺？#

星期二，你開啟 Claude Code。你向它說明：這是專案、這是受眾、不要做這件事。你們一起工作。到了星期四，聊天視窗換了，你又得重新解釋一遍。

如果你有 CLAUDE.md，第一層挫折就已經解決。基本規則和專案說明都放在同一個檔案中，並且會在每個工作階段載入。我在CLAUDE.md 指南中說明過這個檔案的運作方式；你可以先讀它，把基礎準備好。

但 CLAUDE.md 是給新進員工看的操作手冊：怎麼穿著、如何用什麼語氣與客戶交談、發布時要用哪些指令。這些內容還不足以讓人對專案做出好決策。做決策需要知識：產品是什麼、受眾是誰、經濟模式如何運作、你試過什麼，以及哪些做法行不通。

本文所述的作者經驗中，這些知識過去散落在四個地方：作者的腦中、Telegram 聊天、Google 文件，以及員工的腦中。做出決策一個月後，沒有人記得當初為什麼這麼做。新同事得花一小時詢問團隊，才能掌握狀況。Claude 完全不在這些背景資訊之中。

根據作者描述的經驗，在建立第二大腦之前，每個工作階段都得重新說明客戶是誰、方案如何設計，以及由哪家供應商處理付款。現在有了 business/，我只要開啟聊天並說：「依照新定價方案更新提案」，Claude 就會自行前往 business/company/legal.md 閱讀要求，再前往 business/products/pricing.md 查看新定價方案，然後一次提出編輯建議。不必再暖機；背景資訊會自動載入。

Anthropic 在工程部落格中將這個問題稱為「上下文腐化」：

換句話說，塞進視窗的內容越多，代理程式就越不擅長處理細節。解決方法是建立一套外部檔案結構，讓 Claude 能依據特定要求自行查閱。這就是第二大腦。

什麼是第二大腦？它如何應用於 Claude？#

典型的第二大腦使用者會建立 Obsidian vault，加入書籍摘錄、通話筆記和專案構想。

作者將這個概念應用於 Claude Code 工作時，它就不再是生產力問題，而成了代理程式架構問題。

在傳統做法中，第二大腦屬於你，由你手動存取。使用 Claude Code 時，第二大腦變成雙向的：你和代理程式都能存取。這改變了它的格式需求。

既然代理程式會自行存取，檔案就必須採用它不需額外整合便能理解的格式。Markdown 是理想選擇：文字、標題階層，以及檔案間的連結。Notion 和 Google Docs 不適合。你可以透過 MCP 連接它們，但這會多出一層、每次要求多耗一個 token，還多一個故障點。

檔案和專案放在同一個檔案系統中，因此 Claude Code 自然就能存取。不需要設定。只要在專案資料夾中啟動代理程式，它就能看見裡面的所有檔案。免費，而且開箱即用。

Claude Code 開箱即用的記憶階層有哪些？#

在加入自己的內容之前，先看看 Claude 在沒有你協助時能記住什麼。Anthropic 在官方文件中說明了兩種機制：CLAUDE.md（由你撰寫的規則）和自動記憶（Claude 自行寫下的心得）。兩者都會在每個工作階段開始時載入。

CLAUDE.md 會同時在四個位置搜尋：

四個檔案都會載入 context。層級越具體，優先順序越高。本機檔案最後讀取，因此其中的規則會覆蓋其他規則。

CLAUDE.md 也可以放在專案內的任何資料夾中。Claude 從子資料夾讀取檔案時，會按需載入該子資料夾的 CLAUDE.md。這對 monorepo 很有用：前端規則放在 frontend/CLAUDE.md，後端規則放在 backend/CLAUDE.md，代理程式處理相關部分時才會載入。

自動記憶是在 Claude Code 2.1.59 中推出的。這些是 Claude 寫下的關於你的檔案：

~/.claude/projects/<project-name>/memory/
├── MEMORY.md          # 索引，每個工作階段都會載入（200 行或 25KB）
├── debugging.md       # 詳細筆記（按需載入）
├── api-conventions.md
└── ...

Anthropic 在官方文件中如此描述：

自動記憶可透過 ~/.claude/settings.json 中的 autoMemoryEnabled 旗標啟用。要寫入什麼由 Claude 決定。你可以讀取 MEMORY.md 並手動編輯——它就是一般的 Markdown。

CLAUDE.md 或第二大腦——界線該怎麼劃分？#

我在演講中常用這個比喻：想像你雇了一位新員工。第一天，你會交給他什麼？

一份操作手冊：怎麼穿著、何時到班、如何用什麼語氣與客戶交談，以及透過哪個系統發布。它是一份簡短文件，不會解釋你做什麼或為什麼，只會說明如何行事。

另外，你會讓他存取公司維基。維基會說明產品是什麼、適合誰、受眾是誰、價格是多少及原因、競爭者有哪些，以及你犯過哪些錯誤。這是一個大型檔案庫。沒有人會把它全部讀完——有具體問題時才會去查。

CLAUDE.md = 操作手冊。第二大腦 = 維基。兩者都需要。

區分方式很簡單。把所有每項任務都相關的內容放在 CLAUDE.md：

• 代理程式在這個專案中的角色（幫手、負責人、助理）
• 回答時使用的語言
• 工具堆疊
• 發布指令
• 禁止事項（不要使用 em dash、不要執行 git push --force）
• 導覽規則：商業背景和原則要去哪裡查

把所有按需才需要的內容放進第二大腦：

• 產品、受眾、經濟模式和目標
• 競爭者和市場
• 過往決策及其原因
• 客戶案例和評論
• 原則和方法論

Anthropic 在文件中也做了相同的區分：

Skills 是儲存階段性知識的一種方式。在專案旁放一個 business/ 資料夾則是另一種方式。我兩種都用，下面會再詳細說明。

專案大腦由什麼組成：5 個部分加上一台時光機#

作者描述的經驗所採用的架構範例：

方法上的關鍵點是將 ai-clone/ 和 business/ 分開。

business/ 回答「我們做什麼？」產品、受眾、價格、競爭者。它關乎專案。如果你明天把專案交給合作夥伴，這個資料夾也會一起交出去。

ai-clone/ 回答「我如何做決策？」我的原則、語氣、專業做法和禁用詞。它關乎我。如果我明天開始新專案，這個資料夾會跟著我一起走。

兩者結合，就形成我所說的「一人公司」：一個人、結構化背景資訊，以及會讀取這些資訊的 AI。

business/ 應該放什麼？哪些內容不該放？#

作者描述的專案中，business/ 頂層結構如下：

business/
├── INDEX.md              ← 資料夾導覽圖，先讀
├── company/              ← 使命、法人、價值觀、法律政策
├── products/             ← 產品、方案、價格
├── audience/             ← 客戶輪廓、區隔、異議
├── goals/                ← 年度、季度、每月目標與指標
├── economics/            ← 單位經濟、收入、支出、預測
├── marketing/             ← 通路、漏斗、素材、競爭者
├── execution/            ← 每週規劃、待辦事項
└── assets/               ← 設計系統、評論、文案庫

這是作者描述的專案範例，不是教條。我會依需求建立資料夾。起初我只建立三個（products/、audience/、goals/）；2-3 個月後，因為不確定新內容該放在哪裡，才加上其他資料夾。

資料夾的主要檔案是 INDEX.md，也就是導覽圖。它會包含「問題 → 檔案」對照表，讓 Claude 知道要去哪裡。若沒有這個檔案，代理程式就得依序讀取每個檔案，浪費 token。

INDEX.md 範例摘錄：

### Where to find things

| What you need | Where to look |
|---|---|
| Who our client is and their pain points | `business/audience/avatar.md` |
| Products, plans, and prices | `business/products/` |
| Goals and metrics | `business/goals/` |
| Economics (income, expenses, unit economics) | `business/economics/` |
| Promotion channels and materials | `business/marketing/` |

接著只要在 CLAUDE.md 加一行：「關於商業的問題，請讀取 business/INDEX.md 並依照導覽圖查找。」代理程式不會把整個資料夾載入 context，而是讀取導覽圖、挑出正確檔案，再只讀取那個檔案。

不要放進 business/ 的內容清單：

• 未經整理的原始聊天紀錄。如果有洞見，就提煉並記下來；如果沒有，就不要放。
• 程式碼中已有的重複資訊。不必寫「付款透過 CloudPayments 處理」，代理程式看得到程式碼。
• 螢幕截圖和圖片。它們會增加資料夾大小，而且文字模型若沒有額外步驟就無法解析。
• 動態數字。「今天這個產品有 423 筆付款」一週後就過時了。使用 LIVE 標記並連結資料庫查詢。
• 敏感或有疑慮的資訊。假設明天有人把儲存庫放到 YouTube 上，讓 10 萬名陌生人看到，只保留你願意公開的內容。員工、代理程式，有時還有外部承包商都會讀取這個資料夾。

為什麼要分開建立 ai-clone 資料夾？為什麼不該和 business 混在一起？#

概念很簡單：business 知道我們做什麼；clone 知道我如何做決策。

作者描述的專案中，ai-clone/ 結構如下：

ai-clone/
├── INDEX.md           ← 資料夾導覽圖
├── role.md            ← 我是誰、背景、重視什麼
├── identity/          ← 價值觀、願景、使命
├── thinking/          ← 演講中的心智模型
├── voice/             ← 語氣、詞彙、風格
├── principles/        ← 對產品、程式碼、商業的信念
├── feedback/          ← 從錯誤中學到的規則 ← 主要資料夾
├── style/             ← 禁用詞、Telegram 格式
└── reference/         ← 工具、環境

最有用的資料夾是 feedback/，其中保存我透過代理程式犯錯而學到的具體規則。每條規則都放在獨立檔案中，格式如下：

---
name: short-name
description: one line - what’s in the file and when to apply it
type: feedback
---

用一句話寫下一條簡短規則。

**Why:** 為什麼有這條規則。背景、事件、觀察。

**How to apply:** 套用這條規則時的具體觸發條件。

沒有「Why」，規則就沒有生命力——代理程式無法將它套用到類似情境。沒有「How to apply」，也不清楚何時該使用這條規則。

我資料夾中的一個例子是「用連字號，不用 em dash」。這條規則源自 em dash — 是生成文字的重要視覺標記。它適用於所有公開文案。檔案位於 ai-clone/feedback/no-em-dashes.md。

我做法稍有不同：我把規則寫在 ai-clone/feedback/，而不是 CLAUDE.md。CLAUDE.md 是專案檔案，但關於語氣和風格的規則屬於個人。它們會跟著我到下一個專案。CLAUDE.md 則留在原專案中。

什麼是 Live Metrics？為什麼不該在檔案中寫死數字？#

開始建立第二大腦時，主要陷阱之一就是填入過時數字。你寫下「我們有 320 位客戶」，兩週後已經變成 410。你寫下「月營收是 470 萬」，一個月後，這個數字的背景就消失了：它是目標、實際數字，還是預測？

在作者的範例中，做法如下。在 business/products/practicum.md 檔案中，使用標記取代數字：

## Cohorts

> **LIVE** - run the queries in `live-metrics.md`, section “Sales”
> to see current payments by cohort.

| Cohort | Dates | Paying |
|-------|------|------------|
| 1 | March 10-12, 2026 | LIVE |
| 2 | March 24-26, 2026 | LIVE |

另一個 live-metrics.md 檔案則包含可直接執行的 SQL 查詢，以及查詢結果的說明：

## Sales (payments by cohort)

```sql
SELECT c.name, COUNT(p.id) AS paid, SUM(p.amount) AS revenue
FROM purchases p
JOIN cohorts c ON c.id = p.cohort_id
WHERE p.status = 'paid'
GROUP BY c.name
ORDER BY c.starts_at DESC;
```

當我問代理程式「第二期有多少筆付款？」時，它會：

1. 讀取 business/products/practicum.md
2. 看到數字旁的 LIVE 標記
3. 開啟 live-metrics.md
4. 找到「Sales」章節
5. 對正式環境資料庫執行查詢
6. 使用最新資料回答

這同時解決兩個問題：數字不會過時；決策依據的是目前狀況，而不是去年的資料。

AI 如何針對單一要求瀏覽第二大腦？#

具體要求範例：「替新一期的參與者撰寫一封電子郵件。」

1. Claude 從空的視窗開始，載入 CLAUDE.md（規則、技術堆疊、導覽路徑）。
2. 它從 CLAUDE.md 的導覽中看到：「ai-clone/INDEX.md——每個工作階段開始時都要讀取。」它開啟檔案，了解我是誰、我的語氣，以及我使用哪些禁用詞。
3. 它從導覽中看到：「電子郵件範本——src/lib/email/layout.ts。」它開啟檔案並了解格式。
4. 它看到：「產品背景——business/products/practicum.md。」它開啟檔案並讀取產品資訊。
5. 它看到檔案中的 LIVE 標記和 live-metrics.md 參照。它開啟檔案並找到可直接執行的 SQL。如果需要目前數字，就執行查詢；如果不需要，就標記「寄送時取得這個數字」。
6. 它查看 ai-clone/style/telegram-format.md 中的語氣規則、ai-clone/feedback/no-em-dashes.md 中禁止使用 em dash 的規則，以及 business/marketing/funnel.md 中的漏斗轉換率。

它會用我的語氣撰寫郵件，使用最新數字，並避開 em dash 和 AI 標記。

Anthropic 在工程部落格中將這種做法稱為即時情境載入：

換句話說，Claude 隨身帶著資料的指標，而非資料本身。只有相關資訊會進入 context，因此更節省 token，也更加準確。context window 能保持清爽，供推理使用。

第二大腦的 5 個反模式：哪些做法應該避免？#

反模式 1。CLAUDE.md 過度膨脹。寫下 500 行指示，想著「把所有內容都放在同一處」。Anthropic 對此說得很直接：

目標長度是 80-120 行。其他內容放到獨立檔案，再透過導覽連結過去。

反模式 2。萬用資料夾。你把所有東西都丟進第二大腦：未處理的聊天紀錄、沒用的螢幕截圖、沒人會讀的報告。一個月後，資料夾已經膨脹，代理程式浪費 token 閱讀垃圾內容，而你也想不起任何東西放在哪裡。規則是：第二大腦中的每個檔案都應回答一個明確問題。如果半年內沒人開啟，就刪除或移到封存區。

反模式 3。重複內容。「付款透過 CloudPayments 處理，位於 src/lib/payment/cloudpayments.ts；供應商在 .env 中設定。」代理程式從程式碼就能看見這些內容。不要在 business/ 重複記錄。重複內容會過時：程式碼改了，business/ 卻沒更新，代理程式就會依照舊資訊工作。

反模式 4。把數字寫死。「我們有 1,247 位客戶，轉換率為 6.3%」——想像這是某家抽象金融科技新創公司的數字。這類數字一週後都會過時。使用 LIVE 標記和 live-metrics.md。相關章節在上方。

反模式 5。背景資料缺少可存取路徑。 第二大腦在別處，而代理沒有權限或指引時，只從程式資料夾啟動並不足夠。不敏感、可共用筆記放在儲存庫 business/ 與 ai-clone/ 很方便；私有背景則應獨立管控，明確設定允許存取與導覽。資料夾方便性不能凌駕保密需求。

如何在一小時內建立第二大腦：逐步做法#

1. 建立兩個根目錄資料夾

   在專案根目錄中，與 src/ 並列：

   mkdir -p business/{products,audience,goals,economics,marketing}
   mkdir -p ai-clone/{identity,voice,principles,feedback,style}
   

2. 製作 INDEX.md 作為資料夾導覽圖

   business/INDEX.md 是一張「問題 → 檔案」對照表。先建立至少 5 列，再逐步增加。ai-clone/INDEX.md 也照著做。

3. 加入簡短的產品和客戶說明

   business/products/main.md 說明產品是什麼、適合誰、價格是多少，以及有什麼不同。30-50 行。business/audience/avatar.md 說明客戶是誰、他們的痛點，以及他們會買什麼。30-50 行。不要描述理想客戶，而要描述真實客戶。如果有不知道的地方，就標記「待確認」並繼續。

4. 在 ai-clone/role.md 描述自己

   寫下你是誰、你做什麼，以及什麼對你重要。20-30 行就足以開始。當你發現代理程式寫出的風格不像你時，再加入語氣、原則和禁用詞。

5. 在 CLAUDE.md 加入導覽路徑

   開啟 CLAUDE.md 並加入一個章節：

   ## Project map
   
   - Business context → `business/INDEX.md`
   - Context about me → `ai-clone/INDEX.md`
   - Technical plans → `plans/YYYY-MM-DD-*.md`
   - Reflections on past sessions → `retrospectives/`
   
   Always read `ai-clone/INDEX.md` and `business/INDEX.md` at the start of a session.
   

6. 啟動 Claude Code 並檢查

   開啟代理程式並詢問：「告訴我產品和受眾的資訊。」如果它根據資料夾背景資訊回答，就表示運作正常。如果它捏造內容，請檢查資料夾是否和專案放在一起、檔名是否正確，以及 CLAUDE.md 中的導覽是否寫得明確。

接下來，第二大腦會依據兩項原則逐漸成長。

第一：代理程式每次犯錯，就新增一條規則。3-4 週後，ai-clone/feedback/ 會有 15-20 個規則檔案，代理程式就不再犯大多數常見錯誤。

第二：每次做出商業決策，就記錄在 business/。如果你調高價格，就在 business/products/pricing.md 加入日期和原因。如果你改變定位，就在 business/company/about.md 記下來。六個月後，你就會有一份記得「為什麼」的檔案庫。

這週我們一起完成了不少工作。

分析這週所有程式碼變更和我們建立的所有提交。
其中有哪些有價值的資訊應該放進 business/？請寫入適當的檔案，
並加上連往相鄰檔案的 wiki 連結，避免背景資訊流失。

如果程式碼中有尚未說明的決策，請詢問我原因，
並將原因連同日期記錄在適當的檔案中。

不要重複程式碼已明確顯示的內容。只納入沒有 business/ 時，代理程式在下一個工作階段
無法知道的資訊。

接下來呢？Skills、Subagents 和 context engineering#

第二大腦建立好之後，還有 Anthropic 所描述的三種不同層級的 context 最佳化工具。

Skills 是程序知識。如果你有反覆執行的工作流程（撰寫學習指南、製作 Telegram 貼文、稽核網站），可以將它編寫成附有任務說明的 SKILL.md 檔案。每個工作階段開始時，Claude 會掃描技能名稱和說明，只載入符合目前任務的技能。這樣能節省 token，並讓焦點維持集中。

Subagents 是擁有各自 context window 的隔離 Claude 執行個體。把繁重任務（讀取 30 個檔案並整理摘要）交給 subagent，它會在自己的視窗中工作，並只回傳結果。你的主要視窗會保持清爽。Anthropic 寫道：

Context engineering 是管理哪些內容會進入視窗。Anthropic 在 2025 年稱它是與代理程式合作的基礎技能，層級高於 prompt engineering。Prompt engineering 是選擇措辭；context engineering 是選擇檔案、路徑、技能和 subagent。

第二大腦是 context engineering 的第一個構成要素。沒有第二大腦，Skills 讀取的是空白，Subagents 無處可去，代理程式的視窗則會被隨機資訊填滿。有了第二大腦，這三種工具才能開始發揮作用。

下一步。在專案旁建立兩個資料夾：business/ 和 ai-clone/。各自加入一個 INDEX.md，寫下 5 行導覽內容。在 CLAUDE.md 加入四行導覽路徑。一小時內，你就會有一套可運作的第二大腦架構。接著遵循「代理程式每次犯錯，就在 ai-clone/feedback/ 加一行」這條規則逐步擴充。我在如何正確設定 CLAUDE.md指南中，說明用來導向第二大腦的完整 CLAUDE.md 範本。

繼續在 Ailoot 探索。