重點
Claude Code 的第二大腦不是單一檔案，而是由五個資料夾加上 git 組成的結構。CLAUDE.md 設定規則與導覽路徑，`business/` 儲存專案知識，`ai-clone/` 儲存關於你這位決策者的資訊，`plans/` 放置技術計畫，`retrospectives/` 則收錄過往工作階段的心得。代理程式會先讀取 CLAUDE.md，再依據特定要求沿著連結前往正確的資料夾。本文介紹 Claude Code 官方文件中的記憶階層、五部分結構，以及如何在一小時內逐步建置。
Ailoot 參考文件：[ailoot.ai/docs/](https://ailoot.ai/docs/)。
## Claude Code 為什麼需要第二大腦？哪些內容不可或缺？
重點
一個 CLAUDE.md 檔案可以涵蓋基本規則，但無法處理商業記憶。一個月後，你忘了為什麼調高價格。三個月後，你忘了為什麼拒絕分期付款。知識同時散落在四個地方：你的腦中、Telegram 聊天、Google 文件，以及員工的腦中。第二大腦會將這些內容集中到專案旁的一個 Markdown 檔案資料夾中，Claude 可以自行前往查找。
星期二，你開啟 Claude Code。你向它說明：這是專案、這是受眾、不要做這件事。你們一起工作。到了星期四，聊天視窗換了，你又得重新解釋一遍。
如果你有 CLAUDE.md，第一層挫折就已經解決。基本規則和專案說明都放在同一個檔案中，並且會在每個工作階段載入。我在[CLAUDE.md 指南](https://ailoot.ai/blog/zh-hant-tw/claude-md-template/)中說明過這個檔案的運作方式；你可以先讀它，把基礎準備好。
但 CLAUDE.md 是給新進員工看的操作手冊：怎麼穿著、如何用什麼語氣與客戶交談、發布時要用哪些指令。這些內容還不足以讓人對專案做出好決策。做決策需要知識：產品是什麼、受眾是誰、經濟模式如何運作、你試過什麼，以及哪些做法行不通。
本文所述的作者經驗中，這些知識過去散落在四個地方：作者的腦中、Telegram 聊天、Google 文件，以及員工的腦中。做出決策一個月後，沒有人記得當初為什麼這麼做。新同事得花一小時詢問團隊，才能掌握狀況。Claude 完全不在這些背景資訊之中。
根據作者描述的經驗，在建立第二大腦之前，每個工作階段都得重新說明客戶是誰、方案如何設計，以及由哪家供應商處理付款。現在有了 `business/`，我只要開啟聊天並說：「依照新定價方案更新提案」，Claude 就會自行前往 `business/company/legal.md` 閱讀要求，再前往 `business/products/pricing.md` 查看新定價方案，然後一次提出編輯建議。不必再暖機；背景資訊會自動載入。
註記
這不是 Claude 的記憶問題，而是架構問題。代理程式的 context window 就是它的工作記憶。只有你明確指出的內容才會載入。其他一切都在視窗之外，並在需要時載入。第二大腦會以有組織的方式儲存那些「其他一切」，讓 Claude 找得到方向。
Anthropic 在工程部落格中將這個問題稱為「上下文腐化」：
重點
這個概念很簡單：大腦是用來思考，而不是用來儲存想法。對 Claude Code 而言，第二大腦從生產力方法轉變為代理程式架構：一個外部筆記資料夾，代理程式可透過檔案系統直接存取。
典型的第二大腦使用者會建立 Obsidian vault，加入書籍摘錄、通話筆記和專案構想。
作者將這個概念應用於 Claude Code 工作時，它就不再是生產力問題，而成了代理程式架構問題。
在傳統做法中，第二大腦屬於你，由你手動存取。使用 Claude Code 時，第二大腦變成**雙向**的：你和代理程式都能存取。這改變了它的格式需求。
既然代理程式會自行存取，檔案就必須採用它不需額外整合便能理解的格式。Markdown 是理想選擇：文字、標題階層，以及檔案間的連結。Notion 和 Google Docs 不適合。你可以透過 MCP 連接它們，但這會多出一層、每次要求多耗一個 token，還多一個故障點。
檔案和專案放在同一個檔案系統中，因此 Claude Code 自然就能存取。不需要設定。只要在專案資料夾中啟動代理程式，它就能看見裡面的所有檔案。免費，而且開箱即用。
提示
你可以把第二大腦放在 Obsidian 裡——我也會在那裡開啟它，方便檢視連結圖譜。但檔案本身放在程式碼旁的一般資料夾中。Obsidian 只是 Markdown 檔案的便利外殼。即使沒有 Obsidian，Claude 也看得到這些檔案。你可以使用任何編輯器；重要的是檔案要存在磁碟上，而不是放在使用自有格式的雲端服務中。
## Claude Code 開箱即用的記憶階層有哪些？
/memory/
├── MEMORY.md # 索引，每個工作階段都會載入（200 行或 25KB）
├── debugging.md # 詳細筆記（按需載入）
├── api-conventions.md
└── ...
```
Anthropic 在官方文件中如此描述：
Claude 不會在每個工作階段都儲存內容。它會根據資訊在未來對話中是否可能有用，判斷哪些內容值得記住。
— Anthropic，code.claude.com/docs/en/memory
自動記憶可透過 `~/.claude/settings.json` 中的 `autoMemoryEnabled` 旗標啟用。要寫入什麼由 Claude 決定。你可以讀取 MEMORY.md 並手動編輯——它就是一般的 Markdown。
警告
自動記憶很有用，但不能取代第二大腦。Claude 會在其中記下工具和程式碼模式方面的實用心得，例如「這個指令碼缺少旗標 X 就會出錯」、「這個資料庫資料表名稱是這個」。它不會記下商業策略。如果你希望代理程式記住受眾是誰，以及選擇某個價格的原因，就必須自行把資訊放進另一個背景資料夾。
## CLAUDE.md 或第二大腦——界線該怎麼劃分？
重點
CLAUDE.md 是給新進員工看的操作手冊：如何行事、使用哪些指令，以及哪些事不能做。第二大腦是公司維基：你做什麼、服務對象是誰、經濟模式如何運作，以及你試過什麼。一份行為規則檔案，加上一套外部知識結構。CLAUDE.md 是索引；第二大腦是檔案庫。沒有索引，代理程式不知道檔案庫存在。沒有檔案庫，它只知道規則，不知道商業背景。
我在演講中常用這個比喻：想像你雇了一位新員工。第一天，你會交給他什麼？
一份操作手冊：怎麼穿著、何時到班、如何用什麼語氣與客戶交談，以及透過哪個系統發布。它是一份簡短文件，不會解釋你做什麼或為什麼，只會說明如何行事。
另外，你會讓他存取公司維基。維基會說明產品是什麼、適合誰、受眾是誰、價格是多少及原因、競爭者有哪些，以及你犯過哪些錯誤。這是一個大型檔案庫。沒有人會把它全部讀完——有具體問題時才會去查。
CLAUDE.md = 操作手冊。第二大腦 = 維基。兩者都需要。
區分方式很簡單。把所有**每項任務都相關**的內容放在 CLAUDE.md：
- 代理程式在這個專案中的角色（幫手、負責人、助理）
- 回答時使用的語言
- 工具堆疊
- 發布指令
- 禁止事項（不要使用 em dash、不要執行 `git push --force`）
- 導覽規則：商業背景和原則要去哪裡查
把所有**按需才需要**的內容放進第二大腦：
- 產品、受眾、經濟模式和目標
- 競爭者和市場
- 過往決策及其原因
- 客戶案例和評論
- 原則和方法論
Anthropic 在文件中也做了相同的區分：
CLAUDE.md 會在每個工作階段載入，因此只放入普遍適用的內容。只有某些時候才需要的領域知識或工作流程，請使用 skills。Claude 會按需載入，不會讓每段對話都變得臃腫。
— Anthropic，code.claude.com/docs/en/best-practices
Skills 是儲存階段性知識的一種方式。在專案旁放一個 `business/` 資料夾則是另一種方式。我兩種都用，下面會再詳細說明。
## 專案大腦由什麼組成：5 個部分加上一台時光機
重點
專案大腦由五個資料夾加上 git 組成。CLAUDE.md 設定規則與導覽路徑。`ai-clone/` 儲存你的數位投影：原則、語氣，以及出錯後的回饋。`business/` 儲存專案知識。`plans/` 放置各階段的技術計畫。`retrospectives/` 收錄工作階段後的回顧。Git 讓所有內容成為一台時光機：一年後，你可以開啟任何檔案，查看做決策時檔案裡的內容。
作者描述的經驗所採用的架構範例：
| 資料夾 | 內容 | 用途 |
|----|----|----|
| **`CLAUDE.md`** | 專案規則、技術堆疊、檔案結構、資料夾導覽、溝通語言 | 這是代理程式的操作手冊。每個工作階段都會載入。少於 200 行，理想長度為 80-120 行。 |
| **`ai-clone/`** | 我是誰、我的原則、語氣、決策風格、出錯後的回饋 | 我作為決策者的數位投影。它知道我會立刻拒絕什麼、我會用什麼風格提出建議，以及我從錯誤中學到的規則。 |
| **`business/`** | 產品、受眾、目標、經濟模式、行銷、過往決策、案例 | 以 wiki 連結相連的 Markdown 檔案。每個檔案透過 `[[...]]` 連結到其他檔案。代理程式遇到具體問題時會前往查找。 |
| **`plans/`** | 每項功能一份計畫。`YYYY-MM-DD-feature.md` 檔案含有階段和核取方塊 | Plan Mode 只存在單一對話中，執行 `/clear` 後就會消失。`plans/` 資料夾位於儲存庫中，任何代理程式都能隨時接續計畫。 |
| **`retrospectives/`** | 每個工作階段後的回顧：完成了什麼、要記住什麼、有哪些可改善之處 | 系統自我學習。錯誤會轉化為 `ai-clone/feedback/` 中的規則。 |
| **`+ git`** | 所有檔案的版本歷史 | 一台時光機。開啟任一檔案並執行 `git log`，就能查看它何時、為何變更。 |
方法上的關鍵點是**將 `ai-clone/` 和 `business/` 分開**。
`business/` 回答「我們做什麼？」產品、受眾、價格、競爭者。它關乎專案。如果你明天把專案交給合作夥伴，這個資料夾也會一起交出去。
`ai-clone/` 回答「我如何做決策？」我的原則、語氣、專業做法和禁用詞。它關乎我。如果我明天開始新專案，這個資料夾會跟著我一起走。
兩者結合，就形成我所說的「一人公司」：一個人、結構化背景資訊，以及會讀取這些資訊的 AI。
## business/ 應該放什麼？哪些內容不該放？
重點
把每週變動不超過一次的專案事實放進 `business/`：定位、受眾、產品與價格、季度目標，以及重要決策。不要放聊天紀錄、未處理的原始資料、程式碼中已有的重複資訊、螢幕截圖和動態數字。用 LIVE 標記和 SQL 查詢連結取代數字——下方的專門章節會說明做法。
作者描述的專案中，`business/` 頂層結構如下：
```
business/
├── INDEX.md ← 資料夾導覽圖，先讀
├── company/ ← 使命、法人、價值觀、法律政策
├── products/ ← 產品、方案、價格
├── audience/ ← 客戶輪廓、區隔、異議
├── goals/ ← 年度、季度、每月目標與指標
├── economics/ ← 單位經濟、收入、支出、預測
├── marketing/ ← 通路、漏斗、素材、競爭者
├── execution/ ← 每週規劃、待辦事項
└── assets/ ← 設計系統、評論、文案庫
```
這是作者描述的專案範例，不是教條。我會依需求建立資料夾。起初我只建立三個（`products/`、`audience/`、`goals/`）；2-3 個月後，因為不確定新內容該放在哪裡，才加上其他資料夾。
資料夾的主要檔案是 `INDEX.md`，也就是導覽圖。它會包含「問題 → 檔案」對照表，讓 Claude 知道要去哪裡。若沒有這個檔案，代理程式就得依序讀取每個檔案，浪費 token。
`INDEX.md` 範例摘錄：
```markdown
### 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 萬名陌生人看到，只保留你願意公開的內容。員工、代理程式，有時還有外部承包商都會讀取這個資料夾。
警告
如果儲存庫是公開的，`business/` 資料夾也是公開的。我會把第二大腦當作明天可能公開來看待，即使它現在是私有的。沒有經過同意的客戶姓名、每月營收數字、密碼都不要放。這個習慣能減輕許多壓力。
## 為什麼要分開建立 ai-clone 資料夾？為什麼不該和 business 混在一起？
重點
`ai-clone/` 儲存你的數位投影：原則、語氣、禁用詞，以及出錯後的回饋。代理程式每次出錯都會依照「規則 → 原因 → 如何套用」的公式，轉化為 `ai-clone/feedback/` 中的一條規則。這個資料夾會跟著你從一個專案移到另一個專案。`business/` 則留在專案裡。兩者要分開：新專案的 `business/` 會是新的，但你的原則和風格不變。
概念很簡單：business 知道我們做什麼；clone 知道我如何做決策。
作者描述的專案中，`ai-clone/` 結構如下：
```
ai-clone/
├── INDEX.md ← 資料夾導覽圖
├── role.md ← 我是誰、背景、重視什麼
├── identity/ ← 價值觀、願景、使命
├── thinking/ ← 演講中的心智模型
├── voice/ ← 語氣、詞彙、風格
├── principles/ ← 對產品、程式碼、商業的信念
├── feedback/ ← 從錯誤中學到的規則 ← 主要資料夾
├── style/ ← 禁用詞、Telegram 格式
└── reference/ ← 工具、環境
```
最有用的資料夾是 `feedback/`，其中保存我透過代理程式犯錯而學到的具體規則。每條規則都放在獨立檔案中，格式如下：
```markdown
---
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` 則留在原專案中。
註記
衡量這套方法成熟度的一個方式是：你每週會因為同一件事對代理程式說幾次「不對，不是這樣」？在成熟的系統中，答案是零。每次錯誤都會變成 `feedback/` 中的一條規則，代理程式下次就不會重犯。
## 什麼是 Live Metrics？為什麼不該在檔案中寫死數字？
重點
第二大腦檔案中的數字幾天內就會過時。今天的「1,000 位客戶」明天就變成 1,050，一個月後則是 2,000。若把數字寫死，一個月後代理程式就會根據過時資料提出建議。解決方法是在檔案中放置 LIVE 標記，再另外建立 `live-metrics.md` 文件，放入可直接執行的 SQL 查詢。代理程式看到 LIVE 時，就會前往資料庫取得目前數字，並根據最新資料推理。
開始建立第二大腦時，主要陷阱之一就是填入過時數字。你寫下「我們有 320 位客戶」，兩週後已經變成 410。你寫下「月營收是 470 萬」，一個月後，這個數字的背景就消失了：它是目標、實際數字，還是預測？
在作者的範例中，做法如下。在 `business/products/practicum.md` 檔案中，使用標記取代數字：
```markdown
## 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 查詢，以及查詢結果的說明：
````markdown
## 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. 使用最新資料回答
這同時解決兩個問題：數字不會過時；決策依據的是目前狀況，而不是去年的資料。
警告
依照作者描述的做法，只有受信任的代理程式才能存取正式環境資料庫。它們只能透過會記錄查詢且不會暴露密碼的包裝程式取得權限。在 `live-metrics.md` 放入含有純文字密碼的直接 `psql` 指令並不是好做法。應建立一個從環境變數取得密碼，且不會將密碼顯示在輸出的包裝程式。這是另一個技術層，但沒有它，LIVE 就會變成安全漏洞。
## AI 如何針對單一要求瀏覽第二大腦？
重點
處理要求的路徑總是一樣：Claude 讀取 CLAUDE.md，看到導覽圖（`business/INDEX.md`、`ai-clone/INDEX.md`），前往相關的 INDEX，再依照索引找到特定檔案；必要時透過 LIVE 取得數字。這只需要 5-6 次讀取操作，而不是把整個資料夾塞進 context。context window 可以留給推理，token 不會浪費在無關檔案上。
具體要求範例：「替新一期的參與者撰寫一封電子郵件。」
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 在工程部落格中將這種做法稱為即時情境載入：
採用「即時」方式建構的代理程式會保留輕量識別資訊（檔案路徑、已儲存的查詢、連結等），並在執行時使用這些連結，動態將資料帶入 context。
— Anthropic，anthropic.com/engineering/effective-context-engineering-for-ai-agents
換句話說，Claude 隨身帶著資料的指標，而非資料本身。只有相關資訊會進入 context，因此更節省 token，也更加準確。context window 能保持清爽，供推理使用。
## 第二大腦的 5 個反模式：哪些做法應該避免？
重點
初學者使用第二大腦時常犯的主要錯誤：1）CLAUDE.md 膨脹到 500 多行，而不是保持簡短並負責導覽；2）萬用儲存資料夾淪為垃圾堆；3）重複記錄 Claude 已能從語言或程式碼得知的內容；4）把數字寫死，沒有使用 LIVE，導致數字過時；5）讓代理無權存取或找不到背景資料；不論資料位於同一儲存庫或獨立私有儲存，都可能發生。
反模式 1。CLAUDE.md 過度膨脹。 寫下 500 行指示，想著「把所有內容都放在同一處」。Anthropic 對此說得很直接：
保持簡短。逐行詢問：「刪掉這行後，Claude 會開始犯錯嗎？」如果不會，就刪掉。臃腫的 CLAUDE.md 檔案會讓 Claude 忽略你真正的指示！
— Anthropic，code.claude.com/docs/en/best-practices
目標長度是 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/` 很方便；私有背景則應獨立管控，明確設定允許存取與導覽。資料夾方便性不能凌駕保密需求。
提示
獨立分支（`context` 或 `business-context`）可組織工作，卻不是存取邊界；檔案仍是同一儲存庫的 Git 物件，可隨分支或歷史發布。私有商業背景應使用獨立私有儲存庫或外部儲存，明確設定存取與代理導覽。submodule 可指向私有儲存庫，但保密來自其權限，不是 submodule 本身。另一選項是刻意忽略、另有備份的本機資料夾；忽略路徑不會移除已追蹤檔案或已發布歷史。程式儲存庫只保留可分享背景。
## 如何在一小時內建立第二大腦：逐步做法
重點
你可以在一小時內建立最精簡的第二大腦：建立根目錄資料夾 `business/` 和 `ai-clone/`，分別製作 `INDEX.md` 導覽圖，在 `business/products/` 加入簡短產品說明，在 `audience/` 加入客戶說明，並在 `ai-clone/role.md` 說明你是誰。接著在 CLAUDE.md 加上通往這些資料夾的導覽路徑。之後在工作中逐步擴充：代理程式每次犯錯，就在 `ai-clone/feedback/` 加一條規則；每次做出決定，就在 `business/` 加一則筆記。
1. ### 建立兩個根目錄資料夾
在專案根目錄中，與 `src/` 並列：
```bash
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` 並加入一個章節：
```markdown
## 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
重點
第二大腦加上 CLAUDE.md 是基礎。在其上加入 Skills（依據任務說明按需載入的程序知識）、Subagents（擁有各自 context window、用於繁重任務的隔離 Claude 執行個體），以及 context engineering（管理哪些內容進入視窗）。這些是上層的三個樓層。沒有基礎，它們就無法運作——代理程式沒有可讀取的內容。
第二大腦建立好之後，還有 Anthropic 所描述的三種不同層級的 context 最佳化工具。
**Skills** 是程序知識。如果你有反覆執行的工作流程（撰寫學習指南、製作 Telegram 貼文、稽核網站），可以將它編寫成附有任務說明的 `SKILL.md` 檔案。每個工作階段開始時，Claude 會掃描技能名稱和說明，只載入符合目前任務的技能。這樣能節省 token，並讓焦點維持集中。
**Subagents** 是擁有各自 context window 的隔離 Claude 執行個體。把繁重任務（讀取 30 個檔案並整理摘要）交給 subagent，它會在自己的視窗中工作，並只回傳結果。你的主要視窗會保持清爽。Anthropic 寫道：
專門的 sub-agent 可以在乾淨的 context window 中解決聚焦的任務。[…] 每個 subagent 都可以廣泛探索，花費數萬個甚至更多 token，但最後只回傳經過壓縮和提煉的工作摘要（通常為 1,000-2,000 個 token）。
— Anthropic，anthropic.com/engineering/effective-context-engineering-for-ai-agents
**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](https://ailoot.ai/blog/zh-hant-tw/claude-md-template/)指南中，說明用來導向第二大腦的完整 CLAUDE.md 範本。
### 來源
- [Claude Code Memory 文件](https://code.claude.com/docs/en/memory) - Anthropic 官方 Claude Code 記憶階層說明
- [Claude Code 最佳實務](https://code.claude.com/docs/en/best-practices) - 使用 CLAUDE.md 的官方指引
- [有效的 AI 代理程式 context engineering](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) - Anthropic Engineering 對 context rot、注意力預算與即時情境載入的說明
- [Skills 說明](https://claude.com/blog/skills-explained) - Anthropic 部落格：Skills、Memory、Subagents 和 MCP 的差異
繼續在 [Ailoot](https://ailoot.ai/) 探索。
## 常見問題：Claude Code 的第二大腦：如何在一小時內建立結構
### 把商業資料放另一個 Git 分支，就能保密嗎？
不能。分支仍屬於同一儲存庫，檔案可隨 Git 物件與歷史分享。應用有獨立存取控制的私有儲存，或刻意忽略並另有備份的本機資料夾；忽略路徑不會抹除既有追蹤歷史。
### 代理如何找到程式儲存庫外的私有背景資料？
提供明確指引與任務必要存取權，用精簡索引導向相關文件，並驗證代理能讀取獲准檔案。只有私有位置、沒有導覽，不會自動提供上下文。
## Ailoot · 公司及其專案組合
Ailoot以累積的營運經驗、廣大的客戶群、穩定的服務及持續的KPI管理為基礎。
公司及其專案組合：數百萬客戶，每月銷售額達數十億。
Ailoot將這些營運經驗用於API存取，讓客戶的產品、代理、應用程式及自動化流程使用AI功能。