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 在正确项目里做正确的事。