在上一篇文章中，我们像拆解精密仪器一样，宏观地审视了 Claude Code 的技术架构与核心组件。但说实话，光有架构还不够，就像给了一台超级计算机却不装操作系统，它依然跑不起来。今天我们要聊的是一个geng接地气、gengNeng直接提升你开发幸福感的话题——Claude Code 的记忆系统，以及那个至关重要的配置文件：CLAUDE.md。

让我们先直面一个让人甚至有点抓狂的场景，这几乎是每个初次接触 AI 编程助手的开发者必经的“至暗时刻”。

第一次对话：
你：帮我写一个用户登录接口
Claude：没问题，这是基于 Express 和 JavaScript 的基础实现...
你：等等，我们项目技术栈用的是 Egg.js 框架，而且必须用 TypeScript。
Claude：好的，明白了。让我重新为您生成...
第二次对话：
你：帮我写一个登录的前端页面。
Claude：好的，这是使用传统 CSS 的登录页面...
你：哎呀，忘了说我们项目强制使用 Tailwind CSS。
Claude：收到，正在为您重写...

刚开始的时候，你可Neng觉得多说两句也没什么大不了的。但随着项目像滚雪球一样变得越来越复杂，代码量激增，业务逻辑盘根错节，Ru果每次开启新对话，Claude dou像得了“失忆症”一样，把你之前强调过无数遍的技术栈、代码风格、团队规范忘得一干二净，那种无力感真的会让人心态崩了。它就像一个永远记不住你喜好的实习生，每次dou要你手把手教一遍。

这时候，CLAUDE.md 就是那剂专治“失忆”的特效药。它不仅仅是一个文件，geng像是你为这位 AI 实习生准备的一份详尽的“入职手册”。

什么是 CLAUDE.md？

简单来说CLAUDE.md 是一份存放在项目根目录下的说明书。每当 Claude Code 启动一个新的对话会话时它Zuo的第一件事不是听你发号施令，而是先默默地把这份手册读一遍。通过这份文件，Claude Neng够迅速建立起对项目的背景认知，明确自己在干活时必须遵循的底层逻辑和规则。

这就像是一个经验丰富的老员工入职前先阅读公司文档一样，有了这份文档，它才Neng迅速进入角色，而不是像个无头苍蝇一样乱撞。

记忆系统的初始化流程：一场精密的加载仪式

当你兴致勃勃地在项目目录下敲下命令启动 Claude Code 时后台其实发生了一场井然有序的“加载仪式”。这个过程并非杂乱无章，而是遵循着严格的优先级顺序，确保了规则的层层递进与覆盖。

启动 Claude Code
       │
       ▼
加载企业策略  /etc/claude-code/CLAUDE.md
       │
       ▼
加载用户级    ~/.claude/CLAUDE.md
       │
       ▼
加载项目级    ./CLAUDE.md 或 ./claude/CLAUDE.md
       │
       ▼
加载项目规则  .claude/rules/*.md
       │
       ▼
加载本地级    ./CLAUDE.local.md
       │
       ▼
进入对话，所有规则正式生效

kan到这个流程，是不是有点眼熟？没错，这和我们熟知的计算机缓存分层设计有着异曲同工之妙。Claude Code 的记忆系统正是采用了这种分层记忆的架构。高层级的配置就像是“宪法”，提供了基础的约束；而低层级的配置则像是“地方法规”，针对具体场景进行补充和微调。

五层记忆架构详解

为了让你geng直观地理解这个层级结构，我们Ke以把它想象成一个金字塔。下面我们逐层剖析，kankan每一层到底该放些什么。

┌─────────────────────────────────┐  优先级Zui高
│  企业策略  /etc/claude-code/     │
├─────────────────────────────────┤
│  用户级    ~/.claude/            │
├─────────────────────────────────┤
│  项目级    ./CLAUDE.md           │
├─────────────────────────────────┤
│  项目规则  .claude/rules/        │
├─────────────────────────────────┤
│  本地级    ./CLAUDE.local.md     │  优先级Zui低
└─────────────────────────────────┘

第一层：企业策略

存放路径/etc/claude-code/CLAUDE.md

核心定位公司的“宪法”，不可逾越的红线。

这一层通常由公司的 IT 部门或平台工程团队统一维护。它的存在是为了在组织层面强制执行某些不可妥协的规范。比如严禁在代码中硬编码密钥、必须通过特定的代码审查流程、符合特定的安全合规标准等。

Zui棒的是无论你在公司里的哪个项目组工作，只要启动了 Claude Code，这些配置就会自动加载。作为开发者，你甚至不需要手动去配置它，它就像空气一样自然存在默默守护着企业的安全底线。

第二层：用户级

存放路径~/.claude/CLAUDE.md

核心定位你的个人编码“癖好”。

这一层完全属于你个人。无论你跳槽到哪个项目，这份配置dou会如影随形。这里适合存放那些你个人非常坚持的通用偏好。比如你特别喜欢用某种特定的注释风格，或者你习惯用 4 个空格而不是 2 个空格缩进，又或者你总是希望 Claude 在生成代码时附带详细的解释文档。把这些写在这里无论走到哪里Claude douNeng按你的习惯办事。

第三层：项目级

存放路径./CLAUDE.md 或 ./claude/CLAUDE.md

核心定位团队的“圣经”，共享的上下文。

这是Zui常用、也是Zui重要的一层。通常情况下这个文件会被提交到 Git 仓库中，随代码一起分发。它的作用是让整个团队共享同一份“项目说明书”。无论是谁拉取了代码，只要启动 Claude Code，它就Neng立刻明白这个项目是Zuo什么的，用了什么技术栈，有哪些特殊的约定。

典型内容包括：项目的技术栈选型、目录结构的约定、API 设计的规范等等。这是团队协作的基石，Neng极大地减少沟通成本。

第四层：项目规则

存放路径.claude/rules/*.md

核心定位模块化的细粒度控制。

随着项目的发展，CLAUDE.md 可Neng会变得臃肿不堪，像一篇长篇大论，导致加载效率下降，甚至让 Claude 抓不住重点。这时候，就需要引入“项目规则”层，将规则拆分到独立的文件中。

.claude/
└── rules/
    ├── typescript.md      # TypeScript 专属规范
    ├── testing.md         # 测试用例编写规范
    ├── api-design.md      # 接口设计原则
    └── security.md        # 安全漏洞防范指南

这一层Zui迷人的特性在于条件作用域。你Ke以通过 paths 字段声明，某个规则文件只有在编辑特定文件时才会被加载。这简直是节省上下文 Token 的神器！

举个例子，假设你有一个 .claude/rules/testing.md 文件：

---
paths:
  - "**/*.test.ts"
  - "tests/**/*.ts"
---
请确保所有测试用例遵循 AAA 模式...

在这个配置下只有当你正在修改测试文件时关于测试的规范才会被注入到上下文中。Ru果你在写业务逻辑，这些规则就不会占用宝贵的上下文窗口。这种按需加载的机制，既精准又高效。

第五层：本地级

存放路径./CLAUDE.local.md

核心定位你的“秘密花园”，绝对不要提交。

这一层适合存放那些只与你本地开发环境相关，且绝对不Neng泄露给别人的内容。比如你本地调试用的数据库地址、只有你Neng访问的测试服务器的 API Key、或者是一些临时的调试开关。

切记，一定要把这个文件加入到 .gitignore 中，否则你的私密配置可Neng就会随着代码提交“裸奔”到远程仓库了。

如何写出一份高质量的 CLAUDE.md？

理解了层级结构只是第一步，怎么写才是关键。请记住CLAUDE.md 中的每一行字，dou会在每一次对话开始时被自动注入到上下文中。这意味着，精简和精准是两个必须遵守的铁律。

拒绝正确的废话

先来kan一个反面教材，这种写法在现实中非常普遍，但说实话，几乎没有任何实际效果。

# 项目规范
## 代码质量
请写出高质量的代码。代码应该是可读的。使用有意义的变量名。保持代码整洁。遵循Zui佳实践。不要写重复的代码。

这些话错了吗？没错，全是真理。但问题是Claude 模型本身在训练时就Yi经学习了无数遍这些原则了。你写这些，就像是对一个米其林大厨说“Zuo饭要熟，要好吃”一样，属于绝对正确的废话。它们太抽象了无法指导具体的行动。

相比之下明确告诉 Claude 你希望它具体Zuo什么效果会好上一万倍。

# 项目规范
## TypeScript
- 定义对象结构时优先使用 `interface`，仅在联合类型时使用 `type`。
- 严禁使用 `any`，若类型不确定，请使用 `unknown` 配合类型守卫。
- 当函数参数超过 3 个时请重构为对象参数。
## 错误处理

typescript
// 业务错误抛出
throw new BusinessError;
// 验证错误
const data = orderSchema.parse;
// 注意：在 controller 层不要手动 try-catch
// 所有错误应由全局错误中间件统一捕获和处理

kan到区别了吗？后者直接规定了语法细节、库的使用方式以及架构层面的处理流程。这才是 Claude 需要的“行动指南”。

黄金法则：WHY / WHAT / HOW

在编写规范时试着通过三个关键问题来构建你的指令：为什么是什么怎么Zuo。

1. WHY

这一部分的作用，不是让 Claude 死记硬背一个库的名字，而是让它理解你Zuo出某个技术决策的深层原因。当 Claude 明白了“为什么”，它在面对相似但又不完全相同的场景时才geng有可NengZuo出符合你预期的判断，而不是生搬硬套。

2. WHAT

这一部分的重点在于划定边界。什么是允许的，什么是绝对禁止的，决策应该发生在哪一层？对于 Claude 来说清晰的边界比模糊的“Zui佳实践”重要得多。比如“禁止在 Service 层直接访问 HTTP 请求对象”就是一个清晰的边界。

3. HOW

明确路径，步骤清晰。让 Claude Neng够稳定地复用同一套工作流，而不是每次dou自由发挥，搞出一些奇形怪状的代码。

CLAUDE.md 的本质：显性化知识

Zui后我想强调的一点是：CLAUDE.md 定义的是默认决策，而不是用来承载全部知识的百科全书。

对于一些非核心的、可Neng只是偶尔被用到的知识，正确的Zuo法是引用，而不是复制粘贴。你Ke以使用 @import 指令引用其他文件，或者简单地告诉 Claude “参考官方文档链接”。

这样Zuo有两个巨大的好处：一是保持了 CLAUDE.md 的精简，节省了宝贵的上下文 Token；二是确保了知识的准确性，避免了文档过时的问题。

总而言之，CLAUDE.md 的本质是将那些隐性的、只存在于老员工脑子里的项目知识，显性化为一份可读、可执行的文档。你越早为项目建立这份手册，Claude Code 就越Neng像一位真正熟悉项目、甚至和你并肩作战多年的老队友一样工作并决策。

它不再是一个只会听令的机器人，而是一个懂业务、懂规范、懂你的智Neng伙伴。从今天开始，不妨花点时间整理一下你的 CLAUDE.md，相信我，这笔投入绝对是物超所值的。

---