07-CLAUDE.md 和 rules
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 在需要的时候能快速找到准确的信息,不会被无关内容干扰,工作效率自然更高。
