Appearance
CLAUDE.md怎么写:从零打造AI编程搭档说明书完整指南
想象一下:你每天早上到公司,都要花10分钟给新来的同事解释一遍项目用的是Spring Boot还是Spring Cloud、Maven怎么配置、代码分层规范是什么。你一定觉得荒谬——写个文档不就行了?CLAUDE.md就是你写给Claude Code的那份文档。写好这一个文件,相当于给你的AI搭档做了一次全面的入职培训。
一、CLAUDE.md到底是什么
CLAUDE.md是一个Markdown格式的文本文件,Claude Code在每次会话开始时会自动读取它的内容,作为上下文的一部分注入到对话中。你不需要手动引用它,不需要在对话中提到它——它就像一个永远在线的项目说明书。
一句话定位:CLAUDE.md是Claude Code认识你项目的第一份材料,也是唯一一份每次对话都会自动加载的文件。
它和其他配置的关系
| 配置 | 定位 | 放什么 |
|---|---|---|
| CLAUDE.md | 普遍适用的指令 | 项目规范、技术栈 |
| Skills | 特定场景的知识 | 可复用工作流 |
| Hooks | 必须执行的动作 | 自动化触发 |
| Settings | 工具权限控制 | 权限白名单 |
文件放在哪里
| 位置 | 作用域 | 是否提交Git | 适用场景 |
|---|---|---|---|
| ~/.claude/CLAUDE.md | 所有项目 | 否 | 个人全局偏好 |
| ./CLAUDE.md | 当前项目 | 是(推荐) | 团队共享项目规范 |
| ./CLAUDE.local.md | 当前项目 | 否(加入.gitignore) | 个人本地配置 |
| ./子目录/CLAUDE.md | 子目录 | 是 | 模块级别特殊规范 |
| 父目录的CLAUDE.md | 父级项目 | 视情况 | 多模块项目场景 |
Claude Code会自动合并这些层级的内容。在多模块Maven项目中,你可以在根目录放通用规范,在各子模块目录放模块特有的说明。
二、应该写什么:WHAT-WHY-HOW框架
一份好的CLAUDE.md需要回答三个问题:项目是什么(WHAT)、为什么这么做(WHY)、怎么在项目中工作(HOW)。
2.1 WHAT — 告诉Claude项目的技术地图
markdown
# 项目概述
这是一个基于 Spring Boot 3.2 + Java 21 的电商订单管理系统。
# 技术栈
- 框架: Spring Boot 3.2
- 语言: Java 21
- 构建工具: Maven 3.9
- 数据库: MySQL 8.0 + MyBatis-Plus
- 缓存: Redis (Lettuce)
- 消息队列: RocketMQ
- 测试: JUnit 5 + Mockito
# 项目结构 (标准分层架构)
- src/main/java/com/acme/order/
- controller/ - REST 接口层
- service/ - 业务逻辑层
- service/impl/ - 业务逻辑实现
- mapper/ - MyBatis 数据访问层
- model/
- entity/ - 数据库实体
- dto/ - 数据传输对象
- vo/ - 视图对象
- config/ - 配置类
- common/ - 公共工具和常量2.2 WHY — 解释关键的设计决策
这部分解释那些"不看说明就会踩坑"的设计决策。Claude最需要的不是"该怎么做",而是"为什么这么做"。
markdown
# 设计决策
- 使用 MyBatis-Plus 而非 JPA/Hibernate
原因:团队更熟悉 SQL 优化,MyBatis-Plus 提供灵活的 SQL 控制能力
- 所有接口返回统一响应体 Result<T>,不直接返回实体
原因:前后端约定统一的数据格式,便于全局异常处理
- 分布式 ID 使用雪花算法 (Snowflake),不使用数据库自增
原因:分库分表场景下保证 ID 全局唯一且有序2.3 HOW — 告诉Claude怎么干活
markdown
# 常用命令
- 编译打包: `mvn clean package -DskipTests`
- 运行全部测试: `mvn test`
- 运行单个测试类: `mvn test -Dtest=OrderServiceTest`
- 本地启动: `mvn spring-boot:run -Dspring-boot.run.profiles=dev`
- 代码格式化: `mvn spotless:apply`
# 代码规范
- Controller 层只做参数校验和结果封装,不写业务逻辑
- Service 接口和实现分离
- 所有数据库实体继承 BaseEntity
- 方法命名: findXxx / saveXxx / updateXxx / removeXxx
- 提交信息遵循 Conventional Commits 规范
# Git 工作流
- 分支命名: feature/xxx, fix/xxx, chore/xxx
- 提交前必须通过编译和 checkstyle 检查三、怎么写才好:六条黄金法则
法则一:保持精简,控制在200行以内
CLAUDE.md的每一行都会被注入到对话上下文中,占用宝贵的token预算。研究表明,前沿LLM能可靠遵循的独立指令数量大约在150-200条。
判断标准:对于每一行内容,问自己——"如果删掉这行,Claude会犯错吗?"如果答案是否,果断删掉。
法则二:用引用拆分文档,而非塞进一个文件
CLAUDE.md支持通过@语法引用其他文件,实现"渐进式披露":
markdown
# 项目指南
@README.md
@docs/architecture.md
@docs/database-design.md
@docs/api-conventions.mdClaude会在需要时主动去读取这些文件,而不是每次对话都加载全部内容。
法则三:用工具约束格式,而非用指令
不推荐:在CLAUDE.md里写大量代码风格规则。
推荐:交给Checkstyle、Spotless等工具来强制执行,CLAUDE.md里只需要写一句:
markdown
# 代码风格
代码提交前会自动运行 `mvn spotless:apply`,无需手动关注格式问题。法则四:对关键规则使用强调语法
当某条规则特别重要时,使用大写或强调标记提高遵循率:
markdown
IMPORTANT: 所有数据库操作必须通过 MyBatis-Plus 的 Mapper 接口,禁止在 Service 层拼接 SQL 字符串。
IMPORTANT: 不要修改 generated/ 目录下的任何文件,这些是自动生成的代码。Anthropic官方建议使用"IMPORTANT"、"YOU MUST"、"NEVER"等强调词。但不要滥用——如果每条规则都标注为"重要",那就等于没有重要的规则。
法则五:记录"坑"和"怪癖"
项目中总有一些违反直觉的设计或已知的陷阱,这些才是CLAUDE.md最有价值的内容:
markdown
# 注意事项
- 权限校验通过自定义注解 @RequirePermission 在 AOP 中统一处理
如果要新增需要权限的接口,只需在 Controller 方法上加注解即可
- 测试环境使用 H2 内存数据库,运行测试前不需要启动外部数据库
- legacy/ 包下的代码正在迁移中,新功能不要引用这个包法则六:像维护代码一样维护CLAUDE.md
| 发现 | 动作 |
|---|---|
| Claude反复犯同一个错误 | 加一条规则 |
| Claude忽略了某条规则 | 检查文件是否太长导致规则"被淹没" |
| 项目技术栈变更 | 及时更新 |
好的实践:每当你在对话中反复解释某件事,就把它加入CLAUDE.md。
四、完整实战示例(约60行)
markdown
# 项目概述
这是 Acme 公司的内部订单管理系统,基于 Spring Boot 3.2 + Java 21。
# 技术栈
- Spring Boot 3.2, Java 21, Maven 3.9
- 数据库: MySQL 8.0 + MyBatis-Plus 3.5
- 缓存: Redis (Spring Data Redis + Lettuce)
- 消息: RocketMQ 5.x
- 测试: JUnit 5 + Mockito + H2
# 常用命令
- 编译: `mvn clean compile`
- 打包: `mvn clean package -DskipTests`
- 全部测试: `mvn test`
- 本地运行: `mvn spring-boot:run -Dspring-boot.run.profiles=dev`
- 格式化: `mvn spotless:apply`
# 项目结构 (com.acme.order)
- controller/ - REST 接口,只做参数校验和结果封装
- service/ - 业务接口定义
- service/impl/ - 业务逻辑实现
- mapper/ - MyBatis 数据访问层
- model/entity/ - 数据库实体 (继承 BaseEntity)
- model/dto/ - 请求/响应数据传输对象
- model/vo/ - 视图对象
# 代码规范
- Controller 不写业务逻辑,Service 接口与实现分离
- 所有接口返回 Result<T> 统一响应体
- 方法命名: findXxx / saveXxx / updateXxx / removeXxx
- 提交信息遵循 Conventional Commits
# 详细文档
@docs/architecture.md
@docs/database-design.md
@docs/deployment.md
# Git 工作流
- 分支: feature/xxx, fix/xxx, chore/xxx
- PR 必须通过 CI 检查后才能合并
# 注意事项
IMPORTANT: 数据库操作通过 MyBatis-Plus Mapper,禁止拼接 SQL 字符串
IMPORTANT: generated/ 包是自动生成的,不要手动修改
- legacy/ 包下的代码正在迁移,新功能不要依赖
- 分布式 ID 使用雪花算法,不要用数据库自增 ID五、从/init开始,但不要止步于此
如果你的项目还没有CLAUDE.md,最快的起步方式是在项目目录下运行/init命令。Claude会自动分析你的项目结构、读取pom.xml等配置文件,生成一份初始的CLAUDE.md。
但要注意:/init生成的只是一个起点。它能捕捉到明显的模式,但可能遗漏你的团队特有的工作流程和约定。真正有价值的CLAUDE.md是在日常使用中逐步打磨出来的。
总结
写好CLAUDE.md的核心思路可以归纳为三句话:
| 维度 | 核心思路 |
|---|---|
| 写对的内容 | 用WHAT-WHY-HOW框架覆盖项目的技术地图、设计决策和操作手册 |
| 用对的格式 | 精简200行、@引用拆分、工具约束格式、强调关键规则 |
| 持续维护 | 像维护代码一样维护CLAUDE.md,日常使用中逐步打磨 |
一句话:CLAUDE.md是你给AI搭档的入职手册——写好它,Claude从"新人"变"老手"。
