Claude Code 如何管理多個專案記憶：CLAUDE.md、Memory 和 Hooks 的團隊用法

很多團隊開始用 Claude Code 後，會很快遇到一個問題：專案越多，記憶越亂。一個倉庫要用 pnpm，另一個倉庫要用 Poetry；一個專案要求先寫測試，另一個專案要求先改文件；還有一些部署命令、分支規則、程式碼風格和禁區檔案，只要 Claude Code 記錯一次，就可能浪費半小時排查。

解決這個問題的關鍵不是把所有規則都塞進一個超長提示詞，而是把專案記憶分層：CLAUDE.md 寫倉庫內穩定規則，Memory 放跨專案偏好和長期事實，Hooks 負責把固定檢查自動化。這樣做以後，Claude Code 進入不同專案時能讀到不同上下文，團隊也能把 AI 協作規則沉澱成工程資產。

多專案記憶為什麼容易亂

Claude Code 的上下文能力很強，但工程團隊的真實環境通常很複雜：

不同倉庫使用不同技術棧、包管理器和測試命令。
同一個團隊可能有前端、後端、指令碼、運維和文件多個專案。
有些規則是團隊通用的，有些規則只適合某一個倉庫。
口頭約定如果沒有寫下來，每個成員和每次會話都會重複解釋。
AI 一旦把 A 專案的習慣帶到 B 專案，就會產生錯誤操作。

所以，多專案記憶管理的目標不是讓 Claude Code 記住更多，而是讓它在正確的位置記住正確的事。

三層記憶模型

可以把 Claude Code 的工程記憶拆成三層：

層級	適合放什麼	不適合放什麼
`CLAUDE.md`	當前倉庫的構建、測試、目錄、程式碼規範、禁區檔案	個人偏好、跨專案閒聊、臨時任務
Memory	團隊長期偏好、個人工作習慣、跨倉庫通用原則	某個倉庫獨有的命令和路徑
Hooks	提交前檢查、格式化、測試、敏感檔案保護	需要人判斷的產品決策

簡單說，CLAUDE.md 回答“這個專案怎麼做”，Memory 回答“這個人或團隊通常怎麼協作”，Hooks 回答“哪些動作必須自動檢查”。

CLAUDE.md：每個倉庫一份專案說明書

CLAUDE.md 最適合放在專案根目錄，內容應該具體、穩定、可執行。它不是專案 README 的替代品，而是給 AI 程式設計助手看的工作手冊。

一個團隊版 CLAUDE.md 可以這樣組織：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


# Project Guide

## Tech Stack

- Runtime: Node.js 22
- Package manager: pnpm
- Framework: Next.js
- Tests: Vitest and Playwright

## Common Commands

- Install dependencies: `pnpm install`
- Run dev server: `pnpm dev`
- Run unit tests: `pnpm test`
- Run lint: `pnpm lint`
- Run e2e tests: `pnpm test:e2e`

## Working Rules

- Before editing shared UI components, inspect existing usage first.
- Prefer existing helpers in `src/lib` before adding new utilities.
- Do not change database migrations unless the task explicitly asks for it.
- Keep unrelated refactors out of feature fixes.

## Verification

- For UI changes, run `pnpm lint` and the nearest relevant test.
- For API changes, add or update request-level tests.
- For database changes, include migration notes in the final summary.

這類檔案的重點是“讓 Claude Code 少猜”。如果專案裡有固定命令、特殊目錄、容易踩坑的歷史包袱，都應該寫進去。

不要把 CLAUDE.md 寫成垃圾桶

很多團隊失敗在一個地方：第一次覺得 CLAUDE.md 很有用，於是不斷往裡面追加規則，最後變成幾千行。Claude Code 當然能讀，但規則越多，衝突越多，真正關鍵的內容越容易被淹沒。

建議遵守幾個約束：

每條規則都要能影響實際操作。
已經過期的命令和架構說明及時刪除。
臨時任務不要寫進 CLAUDE.md，放在當前會話裡說清楚即可。
個人口吻和情緒化提醒不要寫進去。
同一個意思不要用三種說法重複強調。

如果一條規則只對某個目錄有效，最好放到對應目錄的區域性說明裡，或者在 CLAUDE.md 中明確範圍。

Memory：儲存跨專案偏好

Memory 更適合放跨專案、跨會話仍然成立的偏好。例如：

團隊預設使用中文提交資訊。
修改生產配置前必須先解釋風險。
不要自動重置使用者未提交的改動。
前端頁面需要先保證移動端不溢位。
程式碼審查時先列問題，再寫總結。

這些資訊不屬於某一個倉庫，但會影響所有專案的協作方式。把它們放進 Memory，比在每個 CLAUDE.md 裡重複一遍更合適。

但 Memory 也不能亂放。像 apps/admin 的啟動命令、某個資料庫表名、某個部署指令碼路徑，通常應該寫在專案內文件裡。否則換到另一個倉庫時，Claude Code 可能會把舊路徑當成當前事實。

Hooks：把固定動作交給自動化

CLAUDE.md 和 Memory 都是文字規則，Hooks 則適合處理“每次都要做”的動作。工程團隊可以用 Hooks 做這些事：

編輯後自動執行格式化。
提交前檢查敏感檔案。
修改指定目錄時提醒執行測試。
阻止把 .env、金鑰、生產配置加入提交。
在任務結束時彙總變更檔案和驗證結果。

例如團隊可以約定：只要改了 src/api，就必須跑 API 測試；只要改了 package.json，就必須說明依賴變化。這樣的規則靠人提醒很容易漏，交給 Hooks 更穩定。

Hooks 的原則是自動化明確動作，不替代人做判斷。像“這個需求要不要做”“這個架構是否合理”，仍然應該由團隊成員決定。

多專案協作的寫法示例

如果一個團隊同時維護前端、後端和部署指令碼，可以這樣分工。

前端專案的 CLAUDE.md 重點寫：

1
2
3
4
5
6


## Frontend Rules

- Use existing components in `src/components` before creating new ones.
- Keep layout stable on mobile and desktop.
- Use `pnpm lint` for quick validation.
- For visual changes, mention what viewport was checked.

後端專案的 CLAUDE.md 重點寫：

1
2
3
4
5
6


## Backend Rules

- API handlers live in `src/routes`.
- Database migrations must be reviewed manually.
- Do not change authentication middleware without explicit approval.
- Run `pytest tests/api` after endpoint changes.

運維專案的 CLAUDE.md 重點寫：

1
2
3
4
5
6


## Operations Rules

- Treat deployment scripts as production-sensitive.
- Do not print secrets or tokens in logs.
- Prefer dry-run mode before changing remote state.
- Summarize changed commands before final handoff.

這三個檔案不需要寫成同一種模板。它們的目標是讓 Claude Code 進入當前目錄後，馬上知道“這裡最重要的規則是什麼”。

什麼時候更新記憶

團隊可以把記憶更新當成一次小型覆盤。出現以下情況時，就值得更新：

Claude Code 連續兩次用錯命令。
成員反覆提醒同一條專案規則。
新增了固定驗證流程。
專案目錄結構發生變化。
某條舊規則已經不再適用。

不要把每一次對話都寫進長期記憶。真正值得沉澱的，是下個月、下個成員、下個專案仍然會用到的規則。

程式碼審查場景怎麼用

在程式碼審查裡，多專案記憶尤其有用。團隊可以讓 Claude Code 按固定順序工作：

先讀取當前倉庫的 CLAUDE.md。
再檢查本次改動涉及的目錄。
按專案規則執行最小必要驗證。
審查時優先找 bug、迴歸風險和缺失測試。
最後再給出簡短修改總結。

這樣做的好處是，Claude Code 不會每次都從通用程式碼審查模板開始，而是先理解當前專案的真實約束。

常見錯誤

第一種錯誤是把所有內容都放進 Memory。這樣跨專案汙染最嚴重，尤其是命令、路徑和部署規則。

第二種錯誤是把 CLAUDE.md 寫得像完整開發手冊。AI 需要的是高頻約束，不是所有歷史背景。

第三種錯誤是隻寫規則，不做自動化。能用 Hooks 檢查的事情，就不要只靠文字提醒。

第四種錯誤是沒人維護。專案變了，記憶沒變，Claude Code 就會認真執行過期規則。

一個可執行的落地流程

如果團隊剛開始整理 Claude Code 記憶，可以按這個順序做：

給每個活躍倉庫補一份簡短 CLAUDE.md。
只寫技術棧、常用命令、禁區檔案和驗證方式。
把跨專案偏好整理到 Memory。
把固定檢查做成 Hooks。
每兩週清理一次過期規則。

第一版不要追求完整，先讓 Claude Code 少犯最常見的錯誤。等團隊使用幾輪後，再把重複提醒沉澱進去。

小結

Claude Code 管理多個專案記憶，核心是分層：專案事實放 CLAUDE.md，長期偏好放 Memory，重複檢查交給 Hooks。團隊不需要一開始就設計複雜體系，只要先把命令、目錄、禁區和驗證規則寫清楚，就能明顯減少 AI 程式設計中的誤操作。

真正好的記憶系統不是越長越好，而是讓 Claude Code 在正確專案裡做正確的事。