07-CLAUDE.md 和 rules
CLAUDE.md 是什么
CLAUDE.md 是 Claude Code 的项目记忆文件。你可以把它理解为 Claude Code 关于你项目的"长期记忆"——它会在每次对话开始时自动加载，告诉 Claude 你的项目背景、技术栈、编码规范和约定。
你可以手动创建 CLAUDE.md，也可以在 Claude Code 的终端中输入/init让它自动生成。随着项目的演进，CLAUDE.md 会像你的记忆一样不断迭代和丰富。
CLAUDE.md 应该放什么
好的 CLAUDE.md 应该包含以下内容：
- 项目概述：项目是做什么的，目标用户是谁
- 技术栈：使用的框架、库、构建工具和版本
- 编码规范：命名约定、代码风格、文件组织方式
- 目录结构：关键目录的用途说明
- 常用命令：构建、测试、部署等常用命令
- 团队约定：分支策略、提交信息格式、PR 流程
CLAUDE.md 的大小控制
CLAUDE.md 不是越大越好。因为所有大模型的上下文容量都有限，一个过于冗长的 CLAUDE.md 会占用宝贵的上下文空间，反而降低 Claude 的执行效率。
建议将 CLAUDE.md 控制在200 行以下。只记录长期稳定、反复有用的内容。那些一次性的、临时的指令不应该放在这里。
CLAUDE.md 的放置位置
CLAUDE.md 可以放在多个位置，优先级从高到低为：
| 位置 | 作用域 | 是否加入版本控制 |
|---|---|---|
| 子目录/CLAUDE.md | 仅该目录 | 可选择加入 |
| 项目根目录/CLAUDE.md | 当前项目 | 建议加入，与团队共享 |
| 项目根目录/CLAUDE.local.md | 当前项目 | 不加入，放入 .gitignore |
| ~/.claude/CLAUDE.md | 所有项目 | 不加入 |
重要规则：如果多个位置的 CLAUDE.md 存在冲突，优先级高的会覆盖优先级低的。例如项目根目录的 CLAUDE.md 会覆盖用户目录的同名设置。
rules 规则文件
对于较大的项目，单一的 CLAUDE.md 可能不足以组织所有的项目规则。这时你可以使用.claude/rules/目录将指令组织到多个文件中。
rules 的文件组织
每个文件应涵盖一个主题，并使用描述性文件名。例如：
your-project/ ├── .claude/ │ ├── CLAUDE.md # 主项目指令 │ └── rules/ │ ├── code-style.md # 代码样式指南 │ ├── testing.md # 测试约定 │ └── security.md # 安全要求所有.md文件都会被递归发现，因此你可以将规则组织到子目录中，如frontend/、backend/、database/等。
rules 的加载机制
Claude Code 会根据规则配置和当前上下文有选择地加载rules 文件。这意味着：
- 当你处理前端代码时，主要加载
frontend/下的规则 - 当你处理 API 开发时，自动加载
api-design.md - 规则文件只有在相关时才占用上下文
这种按需加载的机制，比把所有内容都塞进 CLAUDE.md 要高效得多。
最佳实践总结
根据万少的经验，推荐以下分层管理策略：
第一层：CLAUDE.md（记忆层）
存放长期稳定的项目信息：
- 项目名称和一句话描述
- 核心技术栈
- 最常用的构建和测试命令
- 团队协作约定（分支策略、PR 规范）
第二层：.claude/rules/（规则层）
存放分类管理的项目规则：
- 代码风格规则
- 测试规则
- 安全规则
- 数据库设计规范
- API 设计规范
第三层：CLAUDE.local.md（个人层）
存放个人专属的偏好设置：
- 个人常用的编辑器设置
- 个人工作流偏好
- 注意：此文件应加入 .gitignore
核心原则
- 只记录长期有用的信息：一次性的指令不要写进记忆文件
- 按主题拆分：不同领域的内容放到不同的规则文件
- 控制文件大小：CLAUDE.md 不超过 200 行，规则文件不超过 100 行
- 定期维护：随着项目演进，定期清理过时的内容
- 团队共享：项目级别的 CLAUDE.md 和 rules 应提交到版本控制
这样组织的好处是：Claude 在需要的时候能快速找到准确的信息，不会被无关内容干扰，工作效率自然更高。
