Claude Code - 9 Rules 实战指南：让 AI 编程助手「长记性」的模块化配置方案

Claude Code Rules 实战指南：让 AI 编程助手「长记性」的模块化配置方案

你是不是也遇到过这种情况：CLAUDE.md 写着写着就 500 行了，AI 该遵守的规范一条没少，但每次对话都像塞了一本字典进上下文，真正关键的指令反而被稀释了。本文从「为什么要拆」到「怎么拆」再到「拆完效果如何」，用真实项目案例带你走一遍 rules 的完整实战。

一、为什么需要 rules？

1.1 CLAUDE.md 的「膨胀困境」

Claude Code 的记忆系统里，CLAUDE.md 是最核心的配置------每次会话启动，它都会被完整加载到上下文窗口。这意味着：

所有内容都在上下文里占位，不管这次会话用不用得上
越长 ≠ 越好 ，官方建议控制在 200 行以内，超过后指令遵从度会下降来源：Anthropic 官方文档
信息权重被稀释------当你的 CLAUDE.md 里塞了注释规范、命名规范、技术栈规范、安全规范、Lint 禁止项......真正需要 AI 每次都记住的核心约定，反而被淹没了

打个比方：CLAUDE.md 就像你给新同事的一份「入职手册」，你应该把「每天都要遵守的规则」写在最显眼的位置，而不是把「只在写测试时才需要看的测试规范」也塞进同一页纸里。

1.2 rules 解决了什么问题？

.claude/rules/ 目录的本质是一个按主题拆分 + 按需加载的指令系统。它解决的核心矛盾是：

痛点	CLAUDE.md 一把梭	rules 拆分方案
上下文浪费	500 行规范全部加载，哪怕这次只改个 CSS	无 `paths` 的全局加载，有 `paths` 的按需加载
信息权重稀释	核心约定和领域规范混在一起	核心约定留在 CLAUDE.md，领域规范独立文件
团队维护困难	所有人改同一个文件，冲突频发	按主题分文件，各管各的
规范粒度失控	什么都往里塞，越写越长	每个 rule 一个主题，职责清晰

一句话总结：CLAUDE.md 负责告诉 AI「你是谁、这个项目是什么」，rules 负责告诉 AI「遇到这类文件时该怎么做」。

二、rules 的加载机制

理解加载机制是正确使用 rules 的前提。这是很多人搞错的地方。

2.1 两种加载模式

rules 的加载模式由 YAML frontmatter 中的 paths 字段决定：

模式一：全局加载（无 paths 字段）

markdown 复制代码

---
name: forbidden
description: 项目中禁止出现的高风险行为
---

## 架构禁止
- 禁止使用 React Class 组件写法
- 禁止删除现有导入

会话启动时立即加载，行为和写在 CLAUDE.md 里一样
适合：安全规范、禁止项等每次都要遵守的规则

模式二：条件加载（有 paths 字段）

markdown 复制代码

---
paths:
  - "src/**/*.test.ts"
  - "tests/**/*.ts"
---

# 测试规范
- 单元测试: `*.test.ts`
- 集成测试: `*.integration.test.ts`
- 使用 Arrange-Act-Assert 模式

会话启动时不加载
只有当 Claude 读取或编辑匹配 paths 模式的文件时，才注入上下文
适合：测试规范、API 规范、特定领域规范等只在特定场景下需要的规则

2.2 加载时序图

一个完整的会话生命周期中，rules 的加载过程如下：

lua 复制代码

会话启动
  → 加载 CLAUDE.md（含向上遍历的所有层级）
  → 加载 CLAUDE.local.md
  → 加载 .claude/rules/ 下所有【无 paths】的 rule 文件
  → 【有 paths】的 rule 文件暂不加载
      │
      ├─ 用户：改一下 src/utils/format.ts
      │   → Claude 读取 format.ts
      │   → 检查 paths 匹配 → 不命中任何 paths rule → 不加载
      │
      ├─ 用户：给 format.ts 写个测试
      │   → Claude 创建 src/utils/format.test.ts
      │   → 检查 paths 匹配 → 命中 testing.md 的 paths → 加载 ✓
      │
      └─ 用户：再改一下 CSS
          → Claude 读取 styles.css
          → testing.md 已在上下文中 → 仍在上下文中（不会卸载）

关键细节：paths 控制的是「何时加载」，不是「何时生效」。一旦加载就不会卸载。 这意味着如果你在会话中先编辑了一个测试文件触发了 testing.md 的加载，后续即使去改 CSS，testing.md 也仍然在上下文里。

2.3 paths 的 glob 匹配模式

模式	匹配范围
`*/.ts`	任意目录下的所有 .ts 文件
`src/*/`	src 目录下的所有文件
`*.md`	项目根目录的 Markdown 文件
`src/components/*.tsx`	特定目录下的 React 组件

可以在一个 rule 中指定多个 patterns，也支持花括号扩展：

yaml 复制代码

paths:
  - "src/**/*.{ts,tsx}"
  - "lib/**/*.ts"
  - "tests/**/*.test.ts"

2.4 文件命名与编号

rules 文件支持递归发现，你可以用子目录组织：

bash 复制代码

.claude/rules/
├── 000-forbidden.md        # 最高优先级
├── 100-tech-stack.md       # 技术栈
├── 150-commenting-standard.md
├── 200-checklist.md
├── 300-naming.md
├── frontend/               # 子目录也支持
│   └── component-style.md
└── backend/
    └── api-design.md

推荐用三位数编号前缀控制加载顺序，数字越小优先级越高。这对「禁止项必须最先被读到」这类场景尤其重要。

2.5 YAML frontmatter 可选字段

rules 文件支持以下 frontmatter 字段：

字段	作用	必填
`name`	rule 的标识名称，方便在 `/memory` 中查看	否（建议填）
`description`	一句话描述 rule 的内容	否（建议填）
`paths`	触发条件加载的 glob 模式列表	否（无则全局加载）

三、如何提取 rules？------ 实战方法论

3.1 提取判断标准

不是所有内容都该拆到 rules 里。核心判断逻辑：

objectivec 复制代码

CLAUDE.md 当前的内容
    │
    ├─ 这是「每次会话都需要」的核心约定吗？
    │   ├─ 是 → 留在 CLAUDE.md
    │   └─ 否 → 拆到 rules
    │
    ├─ 这是「只在特定文件类型下才需要」的领域规范吗？
    │   ├─ 是 → 拆到 rules + 加 paths
    │   └─ 否 → 拆到 rules + 不加 paths
    │
    └─ 这是「多步骤流程」或「复杂模板」吗？
        ├─ 是 → 考虑用 Skill 而不是 rule
        └─ 否 → 用 rule

按 CLAUDE.md 长度决策：

CLAUDE.md 行数	建议
< 200 行	不用拆，一把梭就好
200--500 行	有领域规范就拆，没有就先不拆
> 500 行	必须拆，否则核心指令权重被严重稀释

3.2 提取四步法

第一步：盘点现有内容

通读 CLAUDE.md，把每段内容标记分类：

分类	含义	去向
🔴 硬性约束	绝对禁止做的事，违反即事故	`000-forbidden.md`，全局加载
🟡 技术栈规范	框架/库的使用约束	`100-tech-stack.md`，全局或按 paths
🟢 领域规范	只在特定场景生效	对应 rule + paths
🔵 交付检查	代码完成后的自检清单	`200-checklist.md`，全局加载
⚪ 核心约定	项目本质信息	留在 CLAUDE.md

第二步：检测内容重叠

不同段落间是否有重复或矛盾的规则？比如：

「禁止使用 class 组件」在技术栈规范里写了，在禁止项里又写了一遍 → 去重，保留在优先级更高的位置
「SCSS 用 px」和「JS 动态样式用 px2Vw」分散在不同段落 → 合并到同一个 rule

第三步：决定 paths 策略

问自己一个问题：这条规范，改一个不相关的文件时也需要遵守吗？

「禁止删除现有导入」→ 不论改什么文件都该遵守 → 无 paths，全局加载
「API 路由文件放 server/routes/」→ 只在改后端文件时相关 → 加 paths 限定

第四步：精简 CLAUDE.md

拆完之后，CLAUDE.md 只保留三类内容：

项目概述：一句话说清这是什么项目
常用命令：dev、test、lint、deploy
rules 索引：一张表告诉团队成员（和 AI）规则在哪里

3.3 让 AI 帮你提取：提示词模板

上面四步法是手动拆分的思路。但实际操作中，你完全可以把「扫描 + 提取 + 生成 rule 文件」这件事交给 Claude Code 自己来做。下面是我实际使用的提示词，你可以直接复用或根据项目调整。

第一步提示词：扫描 + 抽离 + 给方案

markdown 复制代码

.claude通用配置抽离到rules文件夹。

背景：
目前发现claude下的很多配置都存在全局通用性的规则。

需求功能：
- 深度扫描claude配置后，抽离通用配置存放到rules文件中。

完成质量：
- 前端和后端的配置不要去重合并，一定要记住这条规则。
- 通用的抽离，不通用的不抽离。

先进入执行模式，给我方案和理由，让我审查，我确认后再执行

这个提示词的设计要点：

设计点	为什么这样写
`深度扫描`	让 AI 主动遍历 .claude/ 目录和 CLAUDE.md，而不是只看当前上下文
`前端和后端的配置不要去重合并`	防止 AI 自作主张把前后端同类规则合并成一个 rule------前后端虽然都叫「命名规范」，但内容完全不同
`通用的抽离，不通用的不抽离`	划清边界，避免 AI 把所有内容都拆出去（CLAUDE.md 变空壳）或什么都不拆（等于没做）
`给我方案和理由，让我审查`	关键！拆分配置是不可逆操作，必须先看方案再执行，不能让 AI 直接改文件

第二步提示词：同步更新 CLAUDE.md

markdown 复制代码

CLAUDE.md 因为.claude配置变更了，claude.md也需要更新

抽离完 rules 后，CLAUDE.md 必须同步更新------删掉已迁移的内容，补上 rules 索引表。这句提示词就是提醒 AI 完成这一步。

完整的工作流：

objectivec 复制代码

提示词 1：扫描 + 抽离
    → AI 输出拆分方案（列出哪些内容拆到哪个 rule 文件）
    → 你审查方案，确认/调整
    → AI 执行：创建 rule 文件 + 从 CLAUDE.md 中移除对应内容

提示词 2：更新 CLAUDE.md
    → AI 精简 CLAUDE.md，只保留核心约定 + rules 索引表
    → 你确认最终版本

💡 实战建议：第一次拆分建议用「先给方案再执行」的模式；后续增量维护（加一条新规则、调整某个 rule）可以直接让 AI 执行，因为文件结构已经稳定了。

四、真实场景应用：从 500+ 行 CLAUDE.md 到模块化 rules

下面用我的真实项目------一个 React 18 + MobX 的移动端 H5 项目，演示完整的 rules 拆分过程。

4.1 拆分前：CLAUDE.md 的膨胀现状

项目最初把所有规范都塞进了 CLAUDE.md，膨胀到了 500+ 行。内容大致分为：

架构禁止项（不许用 class 组件、不许删导入、不许全局 lint）
Lint 禁止项（不许全局 eslint --fix）
样式禁止项（不许手写 vw、不许缩放设计稿数值）
React 技术栈规范（函数组件、Hooks、JSX）
MobX 状态管理规范（页面级用 useObserver、组件级禁用）
750 适配方案（px → vw 转换、路径别名）
注释规范（文件头、组件、Store、常量、函数、SCSS......占了一大半篇幅）
命名规范（PascalCase、camelCase）
检查清单（交付前的自检项）

问题很明显：注释规范就占了近 200 行，但如果你这次只是改个样式，这些注释规范完全用不上，却在白白消耗上下文。

4.2 拆分方案

按照上面的四步法，最终拆分结果：

bash 复制代码

.claude/rules/
├── 000-forbidden.md           # 🔴 最高优先级禁止项
├── 100-tech-stack.md          # 🟡 技术栈规范
├── 150-commenting-standard.md # 🟢 注释规范（篇幅最大）
├── 200-checklist.md           # 🔵 交付检查清单
└── 300-naming.md              # 🟢 命名与代码风格

精简后的 CLAUDE.md 只剩核心约定 + rules 索引表：

markdown 复制代码

# 项目概述
React 18 移动端 H5 项目，函数组件 + Hooks + MobX，750 设计稿适配。

# 命令
- `npm run dev` --- 启动开发服务器
- `npm run build` --- 生产构建

# Rules 通用规范（自动加载）

| 文件 | 位置 | 说明 |
|------|------|------|
| 绝对禁止事项 | `.claude/rules/000-forbidden.md` | 最高优先级禁止项 |
| 技术栈规范 | `.claude/rules/100-tech-stack.md` | React/MobX/样式/路径别名规范 |
| 注释规范 | `.claude/rules/150-commenting-standard.md` | 文件头、组件、状态字段、函数、SCSS 注释规范 |
| 通用检查清单 | `.claude/rules/200-checklist.md` | 代码完成后通用检查清单 |
| 命名与代码风格 | `.claude/rules/300-naming.md` | 命名规范、缩进、注释规范 |

4.3 逐个 rule 实战拆解

🔴 000-forbidden.md ------ 最高优先级禁止项

设计思路 ：禁止项必须最先被 AI 读到，所以用 000 前缀确保加载顺序最靠前。不加 paths------因为不管改什么文件，这些红线都不能碰。

markdown 复制代码

---
name: forbidden
description: 项目中禁止出现的架构、Lint、样式等高风险行为
---

## 🔴 架构禁止（最高优先级）

1. ❌ 禁止使用 React Class 组件写法，全部使用函数组件 + Hooks
2. ❌ 禁止使用 antd-mobile 5.x 版本，统一使用 antd-mobile-v2
3. ❌ 禁止业务组件使用任何 MobX 功能（useObserver、observer、inject 等）
4. ❌ 禁止删除现有导入，即使看起来没用到
5. ❌ 禁止随意引入不必要的第三方依赖，优先使用项目已有依赖
6. ❌ 禁止随意修改项目构建配置

---

## 🔴 Lint 禁止

1. ❌ 禁止执行全局 lint 扫描，只针对变更文件执行增量检查
2. ❌ 禁止执行 npm run eslint-fix-GLOBAL-DANGEROUS
3. ❌ 禁止执行 npm run stylelint-fix-GLOBAL-DANGEROUS
4. ❌ 禁止执行 npx eslint --fix src/
5. ❌ 禁止执行 npx eslint --fix 不带文件名（在当前目录全局执行）

---

## 🔴 样式禁止

1. ❌ 禁止手动计算和书写 vw 单位，SCSS 中全部使用 px
2. ❌ 禁止人为缩放设计稿尺寸，严格按照 750 设计稿数值编写

为什么这么设计？

分三大类（架构/Lint/样式），每条用 ❌ 标记，AI 对视觉标记更敏感
Lint 禁止项列出了具体的危险命令，而不是笼统地说「不要全局 lint」------越具体，AI 越不容易踩坑
「禁止删除现有导入，即使看起来没用到」------这条是从真实踩坑中总结出来的，项目有动态导入的场景，AI 可能会误删

🟡 100-tech-stack.md ------ 技术栈规范

设计思路：技术栈规范是每次开发都需要的基础信息，全局加载。但按领域分了小节，AI 可以快速定位。

markdown 复制代码

---
name: tech-stack
description: React、MobX、样式、路径别名等基础技术栈规范
---

## 📦 React 规范
- ✅ 全部使用函数组件 + Hooks，禁止 class 写法
- ✅ 使用 React 18.2.0 版本特性
- ✅ 项目仅支持 JS/JSX，不引入 TypeScript，不执行 TS 类型检查

## 📦 MobX 状态管理规范

### 页面级别（允许使用 MobX）
- ✅ 页面必须使用 useObserver Hook
- ✅ 禁止使用 observer HOC 方式
- ✅ 禁止使用 import { observable, action } from "mobx"
- ✅ 必须使用 useLocalStore Hook 方式
- ✅ useLocalStore 外层必须由 createShareStore 包裹，禁止单独使用
- ✅ useLocalStore 内部禁止使用 @observable 装饰器

### 业务组件（完全禁止 MobX）
- ❌ 业务组件不得使用任何 MobX 功能

## 📦 样式规范（750 设计稿适配）
- ✅ SCSS 中全部使用 px，PostCSS 自动转换为 vw
- ✅ JS 动态样式必须使用 @Tool/pureBasic/vw 的 px2Vw 方法
- ✅ 所有类名统一使用驼峰命名

## 📦 路径别名规范
- @Stores --- 全局状态存储
- @Service --- API 接口服务
- @PureBusiness --- 纯业务逻辑
- @Hooks --- 公共 Hooks
- @Tool --- 工具函数
- @CComponents --- 公共组件
- @BComponents --- 业务组件
- @Static --- 静态资源

为什么这么设计？

MobX 规范分「页面级」和「组件级」两个互斥场景，比混在一起写更清晰
路径别名列出完整映射表------AI 需要这个来正确生成 import 语句
「项目仅支持 JS/JSX，不引入 TypeScript」------明确告知 AI 不要自作主张加类型注解

🟢 150-commenting-standard.md ------ 注释规范

设计思路：这是篇幅最大的 rule（近 200 行），也是拆分价值最高的。注释规范只在写代码时才需要，但内容太多不适合放在 CLAUDE.md 里。全局加载是因为项目中几乎每次会话都会涉及代码编写。

由于篇幅较长，这里展示其核心结构设计：

markdown 复制代码

---
name: commenting-standard
description: 项目文件头、组件、函数、Store、常量、SCSS 等注释要求
---

## 🔴 强制要求（所有生成代码必须严格遵守）
> ⚠️ 重要提示：代码注释与代码功能同等重要。
> 即使发现项目现有代码注释质量不高，也不要降低标准。

## 📝 注释总原则
| 原则 | 说明 |
|------|------|
| 全面性 | 所有必须注释的场景不能遗漏 |
| 准确性 | 注释必须准确描述代码功能，不误导 |
| 可读性 | 注释语言清晰，易于理解 |
| 一致性 | 所有注释格式保持统一 |

## 1️⃣ 文件头部注释规范 → 2️⃣ 组件注释规范 → 3️⃣ 状态字段注释规范
→ 4️⃣ 常量注释规范 → 5️⃣ 函数/方法注释规范 → 6️⃣ 函数内部变量注释规范
→ 7️⃣ 行内注释规范 → 8️⃣ Hooks 注释规范 → 9️⃣ SCSS 注释规范

## 🚨 代码完成后注释检查清单
（9 项逐条自检）

关键设计点：

开头就是强制声明：「即使发现项目现有代码注释质量不高，也不要降低标准」------这句是专门写给 AI 的，因为 AI 有时会「看到项目里注释不完善，就降低自己的注释标准」，必须明确告知不要这样
函数内部变量注释是容易遗漏的点，单独成节。比如 DOM 测量变量、单位换算变量、金额计算变量------这些是 AI 最容易不写注释的地方
SCSS 注释禁止用 // ：SCSS 编译器对单行注释的处理不一致，必须用 /* */

🔵 200-checklist.md ------ 交付检查清单

设计思路：checklist 是代码完成后的兜底检查，全局加载。设计成 checkbox 格式，AI 可以逐项确认。

markdown 复制代码

---
name: checklist
description: 代码交付前的通用自检项
---

## ✅ 代码完成后通用检查清单

### 组件规范
- [ ] 组件命名为大驼峰（PascalCase）
- [ ] 全部使用函数组件 + Hooks，无 class 组件
- [ ] 组件注释包含 @createDate

### 注释规范
- [ ] 函数内部关键局部变量已添加注释
- [ ] DOM 测量变量、单位换算变量已添加注释
- [ ] style / className / CSS 变量派生逻辑已添加注释
- [ ] useEffect 副作用目的与清理逻辑已添加注释

### 样式规范
- [ ] SCSS 中全部使用 px，无手动书写的 vw 单位
- [ ] SCSS 选择器嵌套层级必须与 JSX DOM class 层级一致
- [ ] 禁止将 JSX 中父子 DOM class 在 SCSS 中拍平成同级选择器

### 代码风格
- [ ] 使用 4 空格缩进
- [ ] 使用正确的路径别名
- [ ] 未删除现有导入
- [ ] 未引入不必要的第三方依赖

为什么 checklist 独立成 rule？

放在 CLAUDE.md 里会太长，且 checklist 只在代码写完后才有用
独立出来后，每次会话加载的额外开销很小，但兜底效果很强
checkbox 格式让 AI 可以逐项打勾确认，比一大段文字更好执行

🟢 300-naming.md ------ 命名与代码风格

设计思路：命名规范内容精简，全局加载即可。

markdown 复制代码

---
name: naming
description: 文件、组件、CSS 类名、缩进和基础注释风格规范
---

## 📝 命名规范

### 文件命名
- 组件目录：大驼峰（PascalCase）
- 组件文件：index.jsx

### 组件命名
- 组件名：大驼峰（PascalCase）
- 组件根 CSS 类名：{组件名}Container

### CSS 类名
- 全部使用小驼峰（camelCase）
- 不使用下划线、中划线

## 📝 缩进规范
- JS/JSX 文件：4 空格缩进
- SCSS 文件：4 空格缩进

4.4 拆分效果对比

维度	拆分前	拆分后
CLAUDE.md 行数	500+ 行	~20 行 + 索引表
规范完整度	全部在 CLAUDE.md	一条不少，分散在 5 个 rule
上下文占用	每次全部加载	无 paths 的全部加载（~250 行），有 paths 的按需加载
维护方式	所有人改一个文件	按主题分文件，互不冲突
优先级控制	靠书写顺序	靠文件编号前缀

五、进阶技巧

5.1 前端后端规则不要合并

如果你的项目是前后端同仓（Monorepo），前端和后端的规则一定要分文件。原因：

前端规则加 paths: ["src/frontend/**"]，后端规则加 paths: ["src/backend/**"]，互不干扰
前端改 CSS 时不会加载后端的数据库规范，反之亦然
团队协作时，前端和后端各自维护自己的 rule 文件

5.2 用户级 rules：跨项目复用

如果你的个人编码习惯在所有项目中一致（比如「4 空格缩进」「commit message 用 conventional commits」），可以放到用户级 rules 目录：

bash 复制代码

~/.claude/rules/
├── preferences.md    # 个人编码偏好
└── workflows.md      # 个人工作流偏好

用户级 rules 在所有项目中生效，但项目级 rules 优先级更高，可以覆盖用户级设定。

5.3 用符号链接共享 rules

多个项目共用同一套规范时，用符号链接避免重复维护：

bash 复制代码

# 链接整个共享目录
ln -s ~/shared-claude-rules .claude/rules/shared

# 链接单个文件
ln -s ~/company-standards/security.md .claude/rules/security.md

5.4 rule vs skill vs command 的选择

场景	用什么	理由
每次会话都要遵守的规则	rule（无 paths）	自动加载，无需手动触发
只在特定文件类型下生效的规范	rule（有 paths）	按需加载，节省上下文
多步骤可复用的工作流程	skill	支持模板、辅助文件、工具限制
快捷指令	command	单文件、轻量、即时执行

5.5 验证 rules 是否生效

用 /memory 命令可以查看当前会话加载了哪些 CLAUDE.md 和 rules 文件。如果某个 rule 没出现在列表中，说明它没被加载------检查文件位置、paths 配置是否正确。

六、踩坑记录

6.1 「禁止项」放 CLAUDE.md 还是 rules？

都可以，但推荐放 rules 并用 000 前缀。原因：

CLAUDE.md 会被 /compact 后重新加载，但内容太长时关键禁止项可能被「淹没」
rules 中 000-forbidden.md 始终在加载顺序的最前面，AI 最先读到

6.2 paths 的 glob 不是正则

paths 使用的是 glob 模式，不是正则表达式。常见错误：

yaml 复制代码

# ❌ 错误：这不是 glob 语法
paths:
  - "src/.*\.test\.(ts|tsx)$"

# ✅ 正确
paths:
  - "src/**/*.test.{ts,tsx}"

6.3 已加载的 rule 不会卸载

前面说过：paths 控制的是「何时加载」不是「何时生效」。所以不要把超大文件的 paths 设得太宽泛------比如 **/* 会让 rule 等同于全局加载，失去了按需加载的意义。

6.4 frontmatter 的 `---` 不能省

YAML frontmatter 必须用 --- 包裹，且 --- 必须独占一行。少了这个，整个文件会被当成普通 Markdown 全局加载，paths 配置不生效。

七、总结

rules 不是「把 CLAUDE.md 拆成多个文件」这么简单，它的核心价值在于按需加载 ------通过 paths 让 AI 只在需要的场景下看到对应的规范，既节省上下文空间，又提高了指令遵从度。

实战建议：

禁止项用 000 前缀，确保最先被读到
能加 paths 就加 paths，除非这条规范确实每次都需要
CLAUDE.md 控制在 200 行以内，只放核心约定 + rules 索引
前后端规则分文件，避免相互污染
定期用 /memory 检查，确认 rules 加载状态符合预期

配置体系不是一次性搭建完就结束的------它需要随着项目的演进持续迭代。每次发现 AI 犯了同样的错误，就是往 rules 里加一条新规则的信号。这就是 rules 的终极价值：把踩过的坑变成永久的防线。

Claude Code - 9 Rules 实战指南：让 AI 编程助手「长记性」的模块化配置方案

Claude Code Rules 实战指南：让 AI 编程助手「长记性」的模块化配置方案

一、为什么需要 rules？

1.1 CLAUDE.md 的「膨胀困境」

1.2 rules 解决了什么问题？

二、rules 的加载机制

2.1 两种加载模式

2.2 加载时序图

2.3 paths 的 glob 匹配模式

2.4 文件命名与编号

2.5 YAML frontmatter 可选字段

三、如何提取 rules？------ 实战方法论

3.1 提取判断标准

3.2 提取四步法

3.3 让 AI 帮你提取：提示词模板

四、真实场景应用：从 500+ 行 CLAUDE.md 到模块化 rules

4.1 拆分前：CLAUDE.md 的膨胀现状

4.2 拆分方案

4.3 逐个 rule 实战拆解

🔴 000-forbidden.md ------ 最高优先级禁止项

🟡 100-tech-stack.md ------ 技术栈规范

🟢 150-commenting-standard.md ------ 注释规范

🔵 200-checklist.md ------ 交付检查清单

🟢 300-naming.md ------ 命名与代码风格

4.4 拆分效果对比

五、进阶技巧

5.1 前端后端规则不要合并

5.2 用户级 rules：跨项目复用

5.3 用符号链接共享 rules

5.4 rule vs skill vs command 的选择

5.5 验证 rules 是否生效

六、踩坑记录

6.1 「禁止项」放 CLAUDE.md 还是 rules？

6.2 paths 的 glob 不是正则

6.3 已加载的 rule 不会卸载

6.4 frontmatter 的 --- 不能省

七、总结

6.4 frontmatter 的 `---` 不能省