简单说，CLAUDE.md 就是你项目的"记忆芯片"。
每次你启动 Claude Code，它会自动读取项目根目录下的CLAUDE.md文件，把里面的内容加载到上下文中。这意味着，你可以在这个文件里写下：
• 项目的技术栈和架构 • 常用的命令和脚本 • 代码风格和规范 • 重要的文件位置 • 任何你希望 Claude 记住的东西
这样，Claude 每次启动都能"记住"这些信息，不用你重复解释。
小白入门：解决重复问题
先说清楚CLAUDE.md是啥：它是Claude Code的"项目记忆文件"，每次对话开始时会自动加载到上下文。简单理解就是——你提前写好项目信息，Claude每次都能看到，不用反复说明。
1 手动创建第一个配置文件
CLAUDE.md支持两个位置：
•用户级: ~/.claude/CLAUDE.md（所有项目通用）•项目级: 项目根目录/CLAUDE.md（当前项目专用）
新手建议从项目级开始。在项目根目录创建文件：
cd/path/to/your/project
touchCLAUDE.md然后写入最基础的3行：
# 项目信息
## 技术栈
-语言: TypeScript
-格式化: Prettier
-构建命令: npm run build就这么简单。
2 自动生成CLAUDE.md文件
更快速与通用的方法是使用 "/init" 命令，让 Claude Code 自动为你生成CLAUDE.md文件。
3 快速添加和直接编辑
• 快速添加：在对话中，想让 Claude 记住任何事，只要在输入内容前加上 # 号，比如：# 所有项目文档都使用中文。然后选择存入 CLAUDE.md 就行了。 • 直接编辑：任何时候，你都可以输入 /memory 命令，它会直接在编辑器里打开 CLAUDE.md 文件，让你进行更详细的编辑和整理。
下次启动Claude Code，它会自动看到这个文件。你再也不用重复说"用TypeScript"了——Claude已经知道了。
我自己第一次配置后的感觉是：从每次对话都要花5分钟说明项目背景，到Claude直接就懂。确实不错。
搞定了基础，但问题来了——多个项目怎么办？
如果你只有一个项目，上面的方法够用了。但如果你像我一样维护10个项目，每个CLAUDE.md都写一遍个人偏好（比如"我喜欢用单引号"），维护成本就上来了。
这时候就要用到CLAUDE.md的4级层级系统。
进阶理解：4级层级系统全解密
Claude Code的配置文件采用的是cascaded system（层叠系统）的机制，优先级从高到低，如下所示：
1.企业级: 企业策略配置（企业账号专用）2.项目级: 项目根目录/CLAUDE.md3.用户级: ~/.claude/CLAUDE.md4.子目录级: 项目子目录/CLAUDE.md
优先级规则很简单：子覆盖父，近的覆盖远的。
举个例子：
• 用户级配置了"用单引号" • 项目级配置了"用双引号" • 结果：Claude在这个项目里用双引号（项目级覆盖用户级）
什么该放哪一级？
这里分享我的决策树：
用户级(~/.claude/CLAUDE.md)：
• 个人编码风格（缩进、引号） • 常用快捷指令 • 个人工作习惯
示例配置：
# 我的偏好
## 代码风格
-使用单引号
-缩进：2空格
-行尾分号：必须
## 常用操作
-提交前运行: npm test && npm run lint项目级(项目根目录/CLAUDE.md)：
• 项目技术栈 • 项目构建命令 • 团队代码规范 • 项目架构说明
示例配置：
# MyProject
## 技术栈
-前端: React 18 + TypeScript
-状态管理: Zustand
-样式: Tailwind CSS
## 项目结构
-/src/components - UI组件
-/src/hooks - 自定义Hooks
-/src/api - API调用层
## 开发规范
-组件命名: PascalCase
-文件命名: kebab-case
-提交规范: Conventional Commits子目录级(某个子目录/CLAUDE.md)：
• 模块特殊规则 • 特定组件的注意事项
比如在/src/legacy/CLAUDE.md中：
# Legacy模块特别说明
这个目录的代码比较老，维护时注意：
-不要重构，只修bug
-保持var和function写法（别改成const/arrow）
-改动前务必跑回归测试用了分层配置后，就可以从"维护10份完整配置"变成"维护1份通用配置+10份差异配置"。维护成本下降还是十分明显的。
高手是怎么配置的
下面一起看高手是如何在真实项目中进行配置的。
Claude Code的作者Boris，前阵子在Twitter分享了他们Anthropic内部团队的真实配置方式：
单一共享CLAUDE.md，签入git
他们的做法很直接——整个团队维护一个共享的CLAUDE.md文件，直接提交到代码仓库。所有人都能看到，所有人都能贡献。
# 团队项目结构
/project-root
├── CLAUDE.md ← 团队共享配置
├── src/
└── tests/全员每周贡献多次
这不是"写一次就不管"的文档。他们的CLAUDE.md是活的——每周团队成员都会补充新发现的最佳实践、新的约定、踩坑经验。
配合hooks使用
他们还会在CLAUDE.md里指定hooks（Claude Code的钩子机制），让某些操作自动触发特定逻辑。比如提交前自动跑lint、生成代码后自动运行类型检查。
效果如何？
Anthropic官方公布的数据：使用Claude Code后，人均每日合并PR数量增加约67%。
67%——这可不是一点半点的提升。我滴个乖乖，这个数字直接说明了配置做对了，效率提升确实香。
说了这么多好处，也得聊聊坑
用了CLAUDE.md 也有挺长时间了，也是从小白进化成熟手，中间过程也踩了不少坑，分享给你，希望你不要再踩一次：
坑1：配置优先级搞混，导致规则冲突
场景：你在用户级配置了"缩进用4空格"，项目级配置了"缩进用2空格"，结果Claude有时候用2有时候用4，代码风格乱了。
原因：没理解优先级规则。项目级应该覆盖用户级，但如果配置写得模糊，Claude可能理解混乱。
解决方案：
• 搞清楚哪些是个人偏好（放用户级）、哪些是项目规范（放项目级） • 项目规范必须明确，别含糊其辞 • 冲突时，项目级优先
坑2：文件过大，浪费上下文
有人把所有东西都往CLAUDE.md里塞——API文档、完整代码示例、历史决策记录...结果文件>10k字，每次对话都要消耗大量token。
建议：
• CLAUDE.md只放必要的上下文 • 详细文档放在 docs/目录，CLAUDE.md里只写路径引用• 用emoji标记关键信息（🔥表示重要规则，✓表示已完成事项）
坑3：团队配置不统一
多人协作时，有人习惯在本地CLAUDE.md写自己的偏好，有人直接改项目级配置，最后大家看到的Claude行为不一致。
解决方案：
• 团队统一用项目级CLAUDE.md，签入git • 个人偏好只写在用户级 ~/.claude/CLAUDE.md• Code Review时检查CLAUDE.md的变更
高级技巧：让Claude更快找到关键信息
如果你的CLAUDE.md比较大，可以用这些技巧帮Claude快速定位重点：
用emoji标记优先级
# 项目规范
## 🔥 核心规则（必须遵守）
-绝对不允许使用any类型
-所有API调用必须有错误处理
## 推荐做法
-优先使用函数式组件
-使用TypeScript严格模式用"READ THIS FIRST"引导
# READ THIS FIRST
这个项目有个特殊要求：所有数据库操作必须走ORM，禁止原生SQL。
详细规范见下方...Claude会优先注意到这种明确的指引。用下来的感受是，关键信息的命中率明显提升了。
从现在开始：行动建议
根据你的情况，选对应的起步方式：
单人开发者
1. 在 ~/.claude/CLAUDE.md记录个人偏好（代码风格、常用命令）2. 在当前项目创建项目级配置（技术栈、构建命令） 3. 用两周，感受下"不用重复说明"的舒适感
多项目维护者
1. 先建用户级配置（通用偏好） 2. 每个项目建项目级配置（项目特定规则） 3. 特殊模块加子目录级配置（特殊处理逻辑） 4. 定期优化配置，删掉不必要的内容
团队leader
1. 制定团队CLAUDE.md规范（哪些必须写、哪些禁止写） 2. 在主仓库创建标准模板 3. 签入git，要求团队成员共同维护 4. Code Review时检查CLAUDE.md的变更
避坑检查清单
• 理解了4级层级的优先级规则 • 知道哪些放用户级、哪些放项目级 • 文件大小控制在合理范围（<5k字为宜） • 用emoji或明确标记突出重点 • 团队项目的CLAUDE.md已签入git