如果你用 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

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

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

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