从这篇开始进入日常使用篇。如果说上手篇是「知道 Claude Code 能干什么」，日常使用篇要解决的是「怎么让它干得更好」。
第一个要讲的就是 CLAUDE.md。
你有没有遇到过这种情况：
每次打开 Claude Code，都要先花几分钟解释一遍——「这个项目用的是 Next.js」「数据库是 SQLite」「部署在腾讯云」「请用中文回复」「不要用 ORM」……
更烦的是，有些规则你忘了说，Claude Code 就自作主张——用了你不想要的代码风格、选了你没用过的库、用英文回复了你的中文项目。
CLAUDE.md 就是用来解决这个问题的。
CLAUDE.md 是一个 Markdown 文件，Claude Code 每次启动时会自动读取。你在里面写的内容会被当作「始终生效的指令」——相当于给 AI 搭档写了一份入职文档，告诉它这个项目的规则、偏好、禁忌。
一次写好，每次对话都自动生效。 不用再重复解释。
CLAUDE.md 有两个层级：
| 文件位置 | 作用范围 | 用途 |
|---|
项目根目录的 CLAUDE.md | 当前项目 | 这个项目特有的规则 |
~/.claude/CLAUDE.md | 所有项目 | 你个人的通用偏好 |
两个都会生效，项目级的优先。
大多数情况下，你只需要在项目根目录放一个就够了。如果你有跨项目通用的偏好（比如「始终用中文回复」），就写在全局的那个里。
Claude Code 还支持
CLAUDE.local.md（不提交 git 的个人偏好）和.claude/rules/目录（模块化规则文件），后续进阶篇会详细介绍。入门阶段用好上面两个层级就足够了。
CLAUDE.md 没有固定格式，就是普通的 Markdown。但从实际使用经验来看，下面这些内容最有价值。
让 Claude Code 知道它在跟什么项目打交道：
# 我的项目
这是一个面向大众的 AI 教学平台，提供在线课程和博客文章。
## 技术栈
- 框架：Next.js 16 + React 19 + TypeScript
- 样式：Tailwind CSS 4
- 数据库：SQLite（better-sqlite3）
- 部署：PM2 + Nginx
这段信息看起来简单，但作用很大。有了它，Claude Code 写代码时会自动用 Tailwind 而不是写 CSS 文件，用 better-sqlite3 而不是建议你装 Prisma。
把你踩过坑的、反复纠正 Claude Code 的规则写下来：
## 代码规范
- 使用中文回复
- 数据库用 better-sqlite3 同步 API，不要用 ORM
- UI 组件用 shadcn/ui，不要自己造轮子
- Toast 提示用 sonner，不要用其他库
规则越具体越好。「代码要写好」没有用，「函数不超过 50 行，超过就拆分」才有用。
有些事情你绝对不想让 Claude Code 做：
## 禁止事项
- 不要手动 scp 文件到服务器
- 不要在服务器上直接改代码
- 不要跳过 deploy.sh 手动构建
- 不要向 git 提交 .env 文件或 API 密钥
写「禁止」比写「建议」更重要。Claude Code 很擅长遵循具体的禁令。
不需要列出每个文件，但让它知道关键目录在哪里：
## 项目结构
- `src/app/` — 页面路由
- `src/components/` — React 组件
- `src/lib/` — 工具函数和核心逻辑
- `src/db/migrations/` — 数据库迁移文件
- `content/` — Markdown 博客和文档
- `data/yidian.db` — SQLite 数据库（不提交 git）
把你日常跑的命令列出来，它在需要的时候会直接用：
## 常用命令
- `npm run dev` — 启动开发服务器
- `npm run build` — 构建生产版本
- `npm run migrate` — 执行数据库迁移
- `npm run test` — 运行测试
如果你的项目有特定的部署方式，写清楚：
## 部署
本地提交代码后，通过 ssh 到服务器执行部署脚本。
部署脚本会自动完成：拉代码 → 装依赖 → 构建 → 重启服务。
不要手动操作服务器上的文件。
把上面的内容组合起来，一个真实项目的 CLAUDE.md 大概长这样：
# 我的博客项目
个人技术博客，基于 Next.js 静态生成。中文内容为主。
## 技术栈
- Next.js 16 + TypeScript
- Tailwind CSS 4 + shadcn/ui
- MDX 博客文章
- SQLite 数据库
## 规则
- 中文回复
- 不使用 ORM，直接写 SQL
- 新增 UI 组件优先用 shadcn/ui
- 提交信息用英文，格式：feat/fix/docs: 描述
## 禁止
- 不要修改 deploy.sh
- 不要提交 .env 文件
- 不要在 API 路由中暴露内部错误详情
## 结构
- `src/app/` — 页面
- `src/components/` — 组件
- `src/lib/` — 核心逻辑
- `content/` — MDX 文章
## 命令
- `npm run dev` — 开发
- `npm run build` — 构建
- `npm run test` — 测试
不长，大概 50 行。但这几十行内容会让 Claude Code 在你的项目里表现得像一个已经了解项目背景的团队成员，而不是一个什么都要从头问的新人。
两种方式：
手动创建： 在项目根目录新建 CLAUDE.md，按上面的格式写好内容。
让 Claude Code 帮你生成： 在对话中输入 /init，Claude Code 会分析你的项目结构，自动生成一份初始的 CLAUDE.md。生成后你再根据自己的需要调整。
我们推荐先用 /init 生成，再手动补充规则和禁忌。自动生成的版本能覆盖技术栈和项目结构，但你的个人偏好和踩过的坑只有你自己知道。
除了项目级的，你还可以在 ~/.claude/CLAUDE.md 放一份全局指令。适合写跨项目通用的偏好：
# 全局偏好
请使用中文回复。
从原始需求出发思考，如果目标不清晰，先和我讨论再动手。
不要过度工程化，保持方案简单。
这些偏好会在你打开任何项目的 Claude Code 时自动生效。
CLAUDE.md 不是写完就不管了。几个实用的维护习惯：
踩坑就记录。 每次 Claude Code 做了你不想要的事（用了错误的库、忽略了某个约定），修完之后顺手把规则加到 CLAUDE.md 里。这样同一个坑不会踩两次。
定期清理。 项目在演进，三个月前的规则可能已经不适用了。偶尔花五分钟看一遍，删掉过时的条目。
提交到 git。 CLAUDE.md 应该和项目代码一起版本管理。这样团队里其他人用 Claude Code 也能自动获得这些规则。
不要写太长。 CLAUDE.md 的内容会占用上下文窗口。50-100 行的精华比 300 行的流水账效果更好。只写 Claude Code 会犯错的地方，不用写它本来就能做对的事。
Q：写了 CLAUDE.md 但 Claude Code 好像没读？
确认文件放在了项目根目录（不是 src/ 下面），文件名是 CLAUDE.md（大写）。启动 Claude Code 时，它会在终端显示加载了哪些配置文件，检查一下列表里有没有你的 CLAUDE.md。
Q：写了规则但 Claude Code 没遵守？
规则写得越具体、越明确，遵守率越高。「写好的代码」是模糊指令，「不要使用 any 类型」是明确指令。另外，如果对话已经很长了，早期读取的 CLAUDE.md 可能被压缩掉——这时候用 /compact 清理一下。
Q：CLAUDE.md 和对话中说的指令哪个优先？
对话中的指令优先。CLAUDE.md 是默认规则，你在对话中说的话可以覆盖它。比如 CLAUDE.md 里写了「用中文回复」，但你在对话中说「这段注释用英文写」，它会听后者。
写好 CLAUDE.md 是让 Claude Code 从「能用」到「好用」的第一步。下一篇我们讲日常用得最多的斜杠命令和快捷操作——掌握这些，你的操作效率会明显提升。
本篇要点：
- CLAUDE.md 放在项目根目录，每次启动自动加载
- 写清楚：技术栈、规则、禁忌、结构、命令
- 用
/init自动生成初始版本，再手动补充- 提交到 git，让团队共享
- 保持精简，50-100 行为宜