给 Claude 定规则：让它写出的代码像我们团队的人写的
摘要 ：本文详细介绍了如何通过
CLAUDE.md规则文件为 Claude Code 制定精确的编码规范，确保生成的代码符合团队风格。内容包括：Claude Code 安装与 Vibe Coding 生态、CLAUDE.md基本用法、Plan Mode 使用场景、实战规则配置示例、分层规则管理技巧，以及避免规则过于笼统的实践经验。核心思路是将团队编码规范转化为机器可读的精确指令，实现 AI 生成代码与团队风格的一致性。
承接上一篇
上一篇《主流编程智能体工具对比》里，我推荐了 Claude Code 作为综合能力最强的选择。
但光有工具还不够。Claude 的编程能力确实强，但如果你不给它定规矩，它写出来的代码风格可能跟你项目里现有的完全不搭------变量命名忽驼峰忽下划线，异常处理有的写有的不写，注释格式随心所欲。
这篇聊聊怎么给 Claude 定规则，让它写出的代码像你们团队的人写的。
先装好 Claude Code
如果你还没装 Claude Code，简单过一下。
安装
Claude Code 是 CLI 工具，npm 一行搞定：
bash
npm install -g @anthropic-ai/claude-code装完在项目目录下跑：
bash
claude它会自动读取项目目录结构，然后你就可以用自然语言跟它对话了。
Vibe Coding 生态：那些 10w+ 星标的工作流模板
除了 Claude Code 本身，日常开发中用得最多的其实是那些社区里流行的工作流模板------你可以理解为"AI 编程助手的自定义技能/工作流排行榜"。GitHub 上有一批仓库，汇总了从构思到部署的全流程模板，教 AI 怎么按工程纪律干活。
我截了几个最火的：
bash
┌──────────────────────────────────────────────────────────────┐
│ Vibe Coding 自定义工作流排行榜 │
│ │
│ 排名 名称 ★ Stars 工作流步骤 │
│ ── ──── ─────── ──────── │
│ 1 Superpowers 175k 头脑风暴→分支→计划 │
│ →TDD→审查→完成 │
│ │
│ 2 Everything CC 171k /plan→/tdd→/review │
│ →/security→/e2e→merge │
│ │
│ 3 Spec Kit 92k 宪法→澄清→规格 │
│ →计划→拆解→实现 │
│ │
│ 4 gstack 88k 办公时间→CEO评审 │
│ →工程师评审→设计→实现 │
│ │
│ 5 Get Shit Done 59k 新建→讨论→规划 │
│ →执行→验证→发布 │
│ │
│ 6 BMAD-METHOD 46k 简报→PRD→架构 │
│ →拆分→开发→审查→回顾 │
└──────────────────────────────────────────────────────────────┘几个有意思的观察：
TDD（测试驱动开发）几乎成了标配。 Superpowers、Everything Claude Code、Matt Pocock Skills 这几个高星项目都把 /tdd 作为核心环节。这说明大家已经意识到，光让 AI 写代码不够，还得让它先写测试。
分层 Review 文化在 AI 时代反而更重了。 gstack 甚至模拟了大公司的多层级审批------CEO 评审计划、工程师评审计划、设计评审、代码审查、QA 测试。听起来夸张，但对于需要多人协作的项目，这种"人工监督点"确实能避免 AI 跑偏。
子代理模式（Subagent-driven）是趋势。 Superpowers 里提到让 AI 主代理调度多个专业子代理并行工作------一个专门写测试，一个专门做安全扫描，一个专门写文档。这种模式在处理复杂任务时效率很高。
命令化是主流交互方式。 大多数工作流都采用 /command-name 格式，这是 Claude Code / Cursor 等工具的自定义指令语法。输入简短命令就能触发复杂的多步工作流，比每次手动打一大段提示词高效得多。
对我来说，最实用的是 Superpowers （个人开发者）和 Spec Kit（需求复杂的项目）。前者轻量级但覆盖全流程，后者强调"先定义规格再实现"，适合 API 设计或系统架构这类需要先把事情想清楚再动手的场景。
Claude 指令的基本用法
Claude 的指令系统有几个核心概念，先搞清楚后面才好讲规则。
CLAUDE.md 项目规则文件
在项目根目录放一个 CLAUDE.md 文件，Claude 每次启动时会自动读取。这就是你给 Claude 定的"家规"。
一个最简单的 CLAUDE.md 长这样：
markdown
# 项目规则
- 使用 TypeScript，严格模式
- 变量用 camelCase，类名用 PascalCase
- 异常必须抛出具体 Error 对象，不能 throw string
- 注释用 JSDoc 格式Claude 会在每次对话中遵循这些规则。
参考： Claude Code 最佳实践社区 github.com/suyili/clau... 和 Anthropic 官方文档 anthropic.com/engineering... 都建议把 CLAUDE.md 控制在 200 行以内，保持精简。
/init 命令
第一次进入项目时，可以用 /init 让 Claude 先理解项目：
bash
/init它会读取项目结构、依赖文件、已有代码风格，然后给你一个项目概览。这个步骤很重要，特别是接手别人的项目或者隔了一段时间回来接着做的时候。
日常对话
之后就是正常的自然语言对话：
把 UserService 里的 createUser 方法加上参数验证
给这个项目加一个健康检查接口Claude 会直接修改文件，你 review 后再决定是否接受。
Plan Mode：不确定需求时先用
这里插一个很多人忽略但非常重要的点：什么时候该用 Plan Mode，什么时候直接让 Claude 写代码。
直接写代码的场景
需求很明确，你清楚知道要什么：
- "把这个函数改成异步的"
- "加一个日志输出"
- "修复这个空指针异常"
这种场景直接说需求就行，不用进 Plan Mode。
用 Plan Mode 的场景
需求不明确，或者任务比较大，你不清楚最佳实现方案：
- "给项目加一套权限系统"------用什么方案？RBAC？ABAC？放哪些表？
- "重构这个模块"------怎么拆？依赖关系怎么处理？
- "设计一个新的 API"------RESTful 还是 GraphQL？分页怎么搞？
这些场景，先用 Plan Mode：
bash
/plan然后告诉 Claude 你的需求，它会：
- 先分析现有代码，搞清楚当前架构
- 列出几种可行的实现方案，分析利弊
- 给出推荐方案，并拆成具体的执行步骤
- 等你确认后再开始写代码
我的经验是： 超过 3 个文件需要修改的任务，先用 Plan Mode。不然 Claude 直接上手改，改到一半发现方向不对，整个上下文就废了，只能重新开始。
实战：用 CLAUDE.md 给智能体定规则
下面拿一个真实项目举例，看怎么把规则写清楚。
场景
我有一个 Spring Boot 项目，团队有明确的编码规范。之前让 Claude 帮忙改代码，它经常不按规范来------比如该用 @Slf4j 的地方它用 LoggerFactory.getLogger()，该抛 BusinessException 的地方它直接 throw new RuntimeException()。
每次改完我还要手动修，等于白干。
后来我写了一个详细的 CLAUDE.md，效果立竿见影。
规则文件示例
markdown
# CLAUDE.md - 项目规则
## 技术栈
- Java 17, Spring Boot 3.2.x
- MyBatis-Plus 3.5.7, Sa-Token 1.38.x
- Hutool 5.8.x, Lombok 1.18.30
## 代码规范
- 类名 PascalCase, 方法/变量 camelCase, 常量 UPPER_SNAKE
- 使用 @Slf4j 记录日志, 禁止 LoggerFactory.getLogger()
- 业务异常抛 BusinessException(code, message)
- Controller 返回 ResponseEntity, 统一用 BaseResponse 包装
- 所有 public 方法必须有 Javadoc
- 使用 BeanUtil.copyProperties 做对象拷贝
## 目录结构
src/main/java/com/example/
├── controller/ # REST 控制器
├── service/ # 业务逻辑 (interface + impl)
├── mapper/ # MyBatis-Plus Mapper
├── entity/ # 数据库实体
├── dto/ # 请求/响应对象
└── exception/ # 异常定义
## 禁止
- 禁止硬编码敏感信息
- 禁止空 catch 块
- 禁止字符串拼接 SQL效果对比
没定规则之前，Claude 生成的代码：
java
// Claude 自己写的
Logger logger = LoggerFactory.getLogger(UserService.class);
throw new RuntimeException("用户不存在");
String sql = "SELECT * FROM users WHERE name = '" + name + "'";定了规则之后：
java
// 按 CLAUDE.md 生成的
@Slf4j
public class UserServiceImpl implements UserService {
public User getUserById(Long id) {
User user = userMapper.selectById(id);
if (user == null) {
throw new BusinessException(404, "用户不存在");
}
return user;
}
}差距很明显。核心就一条：你不说清楚，Claude 就按它的训练数据来，而它的训练数据是全网代码的平均值，不是你团队的规范。
踩坑：规则写得太粗，等于没写
最开始我的 CLAUDE.md 只写了三行：
markdown
- 用 Java 17
- 用 Spring Boot
- 注意异常处理结果 Claude 还是该怎样怎样。"注意异常处理"这句话太模糊了------它理解的"注意"可能就是加个 try-catch 打印一下堆栈，而我想要的是抛出具体的 BusinessException 带上错误码。
后来我把每条规则都写到可执行 的粒度：不是"注意异常处理"，而是"业务异常抛 BusinessException(code, message)，不允许 RuntimeException"。Claude 对这种精确到类名和方法签名的规则，遵守度极高。
这里有个社区总结的经验很到位：别把强制行为写在 CLAUDE.md，用 settings.json 强制执行。 比如"禁止生成 Co-Authored-By"这种，与其在 CLAUDE.md 里写"NEVER add Co-Authored-By"，不如在 settings.json 里配置 attribution.commit: ""，直接从源头关掉。
进阶：CLAUDE.md + .claude/rules/ 分层管理
当项目变大、规则变多的时候，把所有东西塞进一个 CLAUDE.md 就不合适了。
社区的最佳实践是：CLAUDE.md 放核心规则（控制在 200 行以内），具体领域的规则拆到 .claude/rules/ 目录下：
bash
项目根目录/
├── CLAUDE.md # 核心规则（技术栈、命名规范、基础约定）
├── .claude/
│ ├── rules/
│ │ ├── java.md # Java 领域特定规则
│ │ ├── test.md # 测试规范
│ │ └── security.md # 安全规则
│ └── settings.json # 权限、模型、沙箱配置CLAUDE.md 里用 @ 引用规则文件：
markdown
# CLAUDE.md
## 技术栈
- Java 17, Spring Boot 3.2.x
## 代码规范
@rules/java.md
@rules/test.md
@rules/security.md这样分层的好处是：
- CLAUDE.md 保持精简，Claude 不会因为文件太长而忽略后面的内容
- 不同领域的规则独立维护，改 Java 规则不用动测试规范
- 团队成员可以按需加载特定规则
规则生效的工作流程
定好规则后，完整的开发流程是这样的：
bash
┌──────────────┐
│ CLAUDE.md │ ← 项目规则文件（每次启动自动读取）
│ (项目根目录) │ @rules/*.md 按需加载领域规则
└──────┬───────┘
│
▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ /init 初始化 │ ──→ │ 需求明确？ │ ──→ │ 直接对话 │
│ 读取项目结构 │ │ 是 → 直接写 │ │ Claude 改代码│
└──────────────┘ │ 否 → /plan │ │ 遵循规则 │
└──────┬───────┘ └──────┬───────┘
│ │
▼ ▼
┌──────────────┐ ┌──────────────┐
│ Plan Mode │ │ 你 Review │
│ 规划方案 │ │ 接受/拒绝 │
│ 拆分步骤 │ └──────────────┘
└──────────────┘这个闭环跑顺了之后，日常开发效率确实高了不少。Claude 生成的代码风格跟团队里老手写的几乎一样，review 的时候基本不需要改风格问题。
几个实用的小技巧
1. 规则文件分层写
把 CLAUDE.md 分成几块：技术栈、代码规范、目录结构、禁止事项。这样 Claude 读取时条理更清晰，你后续维护也方便。
2. 把规范写成正面指令
与其写"不要用 RuntimeException"，不如写"业务异常必须抛 BusinessException"。正面指令 Claude 遵守度更高，负面禁止有时候反而让它困惑。
3. 定期更新规则
项目规范会变，CLAUDE.md 也要跟着更新。我们团队每次 code review 发现新共识，就会同步更新到这个文件里。
4. 用 settings.json 做硬性约束
权限控制、模型选择、沙箱隔离这些，不要写在 CLAUDE.md 里，放到 .claude/settings.json 里配置。CLAUDE.md 管"怎么写代码"，settings.json 管"能做什么操作"。
5. 复杂任务先用 Plan Mode
超过 3 个文件需要修改的任务，先用 /plan 让 Claude 规划方案，确认方向再动手。这能避免改到一半发现方向不对，整个上下文废掉的情况。
总结
给 Claude 定规则的核心思路就一条：把你们团队的编码规范，写成机器可读的精确指令。
写得越细，效果越好。写到"用 @Slf4j，禁止 LoggerFactory.getLogger()"这个粒度，Claude 基本就不会再出错了。
下一篇聊聊另一个实用场景：怎么把 Claude 里配好的技能和规则，迁移到其他平台（Cursor、CodeBuddy、Qoder）上，避免每次换工具都要重新折腾一遍。
tangyuewei，从后端出发，用 AI 拓展到全栈的工程师。