Claude Code 环境配置四件套：CLAUDE.md、Rules、Memory、Hooks 一次讲清

Thu, 23 Apr 2026 10:35:00 +0800

如果你用 Claude Code 一段时间，就会很快发现一件事：模型本身当然重要，但给它什么环境、什么边界、什么规则，同样重要。

很多人刚开始会把注意力放在“我这次 prompt 怎么写”，但真正把 Claude Code 用成熟之后，你会更关心另一件事：

它知不知道你是谁
它知不知道你怎么工作
它知不知道哪些规则不能违反
它知不知道什么事情必须先确认
它能不能长期记住这些边界

Claude Code 之所以能变成一个成熟工具，不只是因为模型强，而是因为它有一整套机制，帮你把这些工作方式沉淀下来。核心上可以拆成四层：

CLAUDE.md
Rules
Memory
Hooks

这篇文章就把这四个部分一次讲清楚。

为什么环境配置比单次提示词更重要

你可以把 Claude Code 想成你请来的一个助理。

第一天上岗时，你不会只跟他说一句“帮我做事”，而是会给他一份说明书，告诉他：

你的身份是什么
你的沟通语气偏好是什么
哪些操作必须先确认
哪些错误之前犯过，未来不能再犯
这个项目最重要的文档放在哪里

这就是为什么，长期来看，环境配置往往比单次 prompt 更重要。

因为 prompt 解决的是“这一次要做什么”，而环境配置解决的是“以后每次都要怎么做”。

第一层：`CLAUDE.md`

先从最基础的开始，CLAUDE.md 本质上就是一个文字文件。

你可以在里面写给 Claude 的说明，例如：

你是谁
你在做什么
你的沟通偏好
需要遵守的规则
当前项目的特殊背景
重要文档或目录的位置

每次 Claude Code 启动时，这份文档都会被自动送进上下文里，所以模型一定会读到。

我通常把它叫做“默契档”，因为它本质上就是你和模型之间长期协作的默契。

`CLAUDE.md` 适合写什么

最适合写进 CLAUDE.md 的，大致有这几类：

身份与工作背景
沟通语气和输出偏好
全局性的行为规则
经常会用到的重要项目背景
常见错误与避免方式

比如：

你所在的时区
你是否接受模型直接发送邮件或消息
哪些操作属于不可逆行为
处理文档和文件时的习惯
安全规范和敏感信息边界

一个很重要的原则：尽量精简

CLAUDE.md 有一个很重要的原则，就是一定要尽量精简。

原因很简单：它每次都会被强制注入上下文。

如果你写得太长，就会占掉大量上下文空间，导致真正重要的信息被稀释。模型不是不读，而是注意力会分散，最后更容易漏掉你最在意的规则。

官方建议通常是最好不要超过 400 行。

我自己的习惯会更保守一些，尽量控制在 200 行以内。

`CLAUDE.md` 的常见作用范围

CLAUDE.md 实际上有不同的放置层级，对应不同的作用范围。最常用的是两个：

1. User Level

这是全局层级。

它放在你电脑环境里，对你本机操作的所有项目都有效。

这个位置适合放：

你的身份信息
通用的沟通偏好
你跨项目都适用的做事习惯
全局性的安全规则

比如，如果你的时区不是默认常见值，而是曼谷时间，那这类信息就很适合放在 user level，这样模型以后帮你安排时间时就不容易出错。

2. Project Level

这是项目层级。

它放在具体项目目录下面，只对那个项目有效。

这个位置适合放：

项目专属背景
只在这个项目里成立的规则
项目的目录结构说明
这个项目的重要文档入口

举个例子，如果一个项目处理财务，另一个项目处理人事，那两边的背景和约束显然不同，就不应该混在同一个全局说明里。

怎么判断该放哪一层

判断方式其实很简单：

你写进去的东西，如果换到另一个项目里还成立，那就放 user level。

如果一换项目就不成立，那就放 project level。

怎么开始写第一版

最常见的起手方式有两种：

1. 用 `/init`

你可以直接在终端里运行斜线命令 /init，让 Claude 扫描当前项目，自动帮你生成一份基础版 CLAUDE.md。

2. 让 Claude 帮你整理

你也可以直接让 Claude 去搜索别人是怎么写 CLAUDE.md 的，再结合你的情况问你问题，最后帮你整理成适合你自己的版本。

很多时候，这比自己从零开始写更轻松。

一个很实用的习惯

在你和 Claude 长期协作的过程中，只要你发现某件事情属于“未来一定要记住、不要再犯”的内容，就可以直接让它写进 CLAUDE.md。

不过写之前还是要判断一下：

这是全局规则
还是当前项目规则

别把所有东西都塞进一个文件里。

第二层：`Rules`

接下来是 Rules。

它和 CLAUDE.md 最大的差别，不是文件形式，而是加载方式。

CLAUDE.md 是无论你做什么，模型都会读到。

而 Rules 的优势在于：可以条件加载。

也就是说，只有在某些路径、某些文件、某些工具或某些场景下，这条规则才会被读到。

为什么条件加载很重要

因为上下文空间永远是稀缺资源。

如果所有规则都无差别地塞进上下文里，就会发生两件事：

模型负担变重
真正关键的规则反而被淹没

按需加载的价值就在这里：让模型在刚好的时候读到刚好的信息。

什么时候该把规则从 `CLAUDE.md` 挪到 `Rules`

通常有两种情况：

1. `CLAUDE.md` 太长了

如果你的 CLAUDE.md 开始超过 200 行，规则越来越多，重要内容被稀释，那就该考虑把一部分规则拆出去。

2. 某些规则只和特定路径相关

如果你已经明显知道某些规则只在某类文件里才有意义，比如：

只对 Python 脚本有效
只对某个 hooks 目录有效
只对某个子项目有效

那这些规则就更适合移到 Rules。

`Rules` 最适合的场景

最典型的就是“特定情境、特定路径、特定文件类型”。

比如：

只在处理 hooks 文件时触发的规范
只在某类脚本中要遵守的编码规则
只在某个目录下适用的工作方式

这些内容如果继续塞在 CLAUDE.md 里，其实是不划算的。

第三层：`Memory`

第三个层面是 Memory。

它和 CLAUDE.md、Rules 一样，也会进入模型上下文，但它最核心的区别是：

CLAUDE.md 是你主动设定的。

Memory 则更像是 Claude 在协作过程中，写给自己的笔记。

`Memory` 记的是什么

当 Claude 判断某件事值得记住，或者需要短期保留，它就会把这些内容写进 Memory。

常见内容包括：

你纠正过它的某个做法
你最近新增的偏好
当前项目的临时状态
你今天没做完、明天还要继续的事
你最近在跟哪些人合作
某些最近才提到的个人信息或上下文

换句话说，Memory 更像动态知识，而不是长期制度。

`Memory` 和前两者的区别

一个简单的区分方式是：

CLAUDE.md / Rules：偏长期、偏制度、偏明确规则
Memory：偏临时、偏动态、偏工作过程中的新理解

如果某件事只是最近几天有效，或者项目状态在持续变化，那它通常更适合放进 Memory，而不是写成长期规则。

`Memory` 也可以手动写

虽然 Memory 有自动整理能力，但你也可以主动告诉 Claude：

请记下来我明天要做什么
请记下来我要追踪谁的状态
请记下来这个月某个项目的关键节点

它也可以帮你写进 Memory。

你还可以通过斜线命令 /memory 查看当前有哪些记忆，并手动编辑或删除。

不过很多时候，我自己不会频繁手动维护，因为 Claude 本身也会定期整理这些记忆，把已经过时的部分清掉。

第四层：`Hooks`

最后也是最重要、最进阶的一层，就是 Hooks。

前面讲到的 CLAUDE.md、Rules、Memory，本质上都还是自然语言说明。

你写了规则，模型通常会遵守，但它仍然是在“理解之后执行”。

只要还是自然语言，就会存在几个问题：

模型偶尔会漏掉
规则太多时，注意力会分散
某些情境下它会自行判断这条规则不重要

这不是你写得不够认真，而是自然语言规则本来就很难做到 100% 强制。

`Hooks` 的本质是什么

Hooks 不再是自然语言说明，而是一段脚本。

它是事件触发的、程序级别的强制逻辑。

只要某个事件发生，这段逻辑就一定会执行，不会被模型“自己判断后略过”。

这就是 Hooks 最关键的价值：

把“建议遵守”变成“必须执行”。

什么时候该上 `Hooks`

当你发现某条规则已经写进了 CLAUDE.md 或 Rules，但 Claude 偶尔还是不执行，而且这件事一旦漏掉，风险就比较大，那就应该考虑改成 Hooks。

简单说：

低风险的，写规则
高风险的，写 Hooks

最典型的 `Hooks` 场景

最典型的，就是那些你绝对不希望出错的动作，比如：

发邮件前必须确认
发 Slack、Outlook、Gmail 消息前必须确认
删除危险文件前必须拦截
检测到要外发密码或 API Key 时必须阻止

如果这些要求只是写成一句自然语言规则，模型有可能哪天忙中出错，真的就发出去了。

但如果写成 Hooks，只要事件发生，就会被强制拦截。

这才是程序层面的硬防线。

`Hooks` 常见的触发时机

Hooks 可以设置在很多不同阶段，例如：

对话刚开始时注入提醒
某个工具执行前进行检查
某个工具执行后做结果校验

你不一定需要自己知道专业术语。

很多时候，只要你能清楚描述需求，让 Claude 帮你判断“这条规则适不适合改成 hook”，它就能帮你一起设计。

你也可以通过斜线命令 /hook 去查看系统当前已经设置了哪些 hooks。

一套更实用的上手顺序

如果你想把这四层串起来，我自己更推荐下面这条路径：

第一步：先用 `/init` 生成基础版 `CLAUDE.md`

不要一开始就手写一份特别完整的规则文档。

先让 Claude 帮你扫描项目，生成一个起点版本，再慢慢迭代。

第二步：边用边补

在协作过程中，只要你发现：

这件事以后一定要记得
这个错误以后不能再犯
这个偏好以后每次都适用

就让 Claude 帮你写进 CLAUDE.md。

第三步：当 `CLAUDE.md` 变长时，拆到 `Rules`

一旦你发现 CLAUDE.md 越来越长，模型开始不一定遵守每一条规则，就该考虑拆分：

哪些是全局规则
哪些只和某些路径相关

把后者移到 Rules，改成条件加载。

第四步：再把高风险规则升级成 `Hooks`

如果某些规则即使写了，模型还是偶尔会漏，而且漏掉代价很高，那就不要再停留在自然语言层面，直接升级成 Hooks。

也就是把“提醒”变成“强制”。

第五步：把临时状态交给 `Memory`

对于那些会过期、会变化、不是长期制度的内容，不要一股脑写进 CLAUDE.md。

更合适的做法是交给 Memory：

当前项目进度
最近合作对象
最近新增偏好
近期计划和待办

这样上下文会更清爽，模型也更容易保持稳定表现。

这四层分别该记什么

如果你想快速记住，可以直接用下面这个区分：

CLAUDE.md：长期默契、全局说明、项目基础背景
Rules：按路径或场景加载的专项规则
Memory：动态知识、临时状态、最近学到的东西
Hooks：高风险操作的程序级强制拦截

结语

很多人把 Claude Code 当成“会写代码的聊天界面”，但真正用深之后，你会发现它更像一个长期协作的智能工作台。

关键不只是你每次怎么下指令，而是你有没有给它一套稳定、清晰、可长期积累的环境。

一旦你把这四层搭起来：

CLAUDE.md
Rules
Memory
Hooks

你和模型之间的协作质量，通常会有非常明显的提升。

因为你终于不是每次都从零开始解释自己是谁、怎么工作、什么事不能做，而是把这些真正沉淀成了环境。

这才是把一个强模型，真正用成成熟工具的关键一步。

Memory on KnightLi的博客

Claude Code 环境配置四件套：CLAUDE.md、Rules、Memory、Hooks 一次讲清

为什么环境配置比单次提示词更重要

第一层：CLAUDE.md

CLAUDE.md 适合写什么

一个很重要的原则：尽量精简

CLAUDE.md 的常见作用范围

1. User Level

2. Project Level

怎么判断该放哪一层

怎么开始写第一版

1. 用 /init

2. 让 Claude 帮你整理

一个很实用的习惯

第二层：Rules

为什么条件加载很重要

什么时候该把规则从 CLAUDE.md 挪到 Rules

1. CLAUDE.md 太长了

2. 某些规则只和特定路径相关

Rules 最适合的场景

第三层：Memory

Memory 记的是什么

Memory 和前两者的区别

Memory 也可以手动写

第四层：Hooks

Hooks 的本质是什么

什么时候该上 Hooks

最典型的 Hooks 场景

Hooks 常见的触发时机