ClaudeCode有关记忆的全部知识点

1.Resume与Fork Session在会话管理上的不同作用

在 Claude Code 的底层架构中，File Checkpointing（文件检查点） 是一个非常精妙的设计。理解它的原理，能让你在进行复杂重构时游刃有余。

要搞清楚如何配合它实现文件级隔离，我们需要先拆解它的底层逻辑，然后给出具体的实操方案。

一、什么是 Claude Code 的 File Checkpointing？

在底层，Claude Code 在调用工具（如 Edit、Write）修改任何文件之前，会做以下几件事：

自动快照（Snapshot）：在修改文件前，系统会把该文件的当前内容（或通过 Git 差异、临时文件）保存为一个"检查点（Checkpoint）"。

与对话轮次绑定：这个检查点和你的对话历史（Chat Turn）是紧密关联在一起的。每一个大模型输出并执行修改的节点，都在底层对应着一个状态栈（Undo Stack）。

支持回滚（Rollback） ：当你想撤销时，系统不仅能恢复对话上下文，还能把磁盘上的文件原封不动地还原到那个检查点时的状态。

二、如果想做到"文件级别的隔离并尝试新方案"，该如何操作？

正如前面图片中所说：单纯的 /branch 隔离的是对话，而不是文件系统。如果你希望在尝试新方案（删掉15个文件，生成8个新文件）时，能随时完美切回原方案的 15 个文件状态，单靠 Claude 内部的隐式 Checkpoint 可能会因为文件被直接覆盖而显得不够直观。

在实际工程中，有两条路线可以完美配合实现文件级隔离：

路线 A：完全依赖 Claude Code 的内置 Checkpoint（适合轻量、快速尝试）

如果你已经用了 /branch 分叉出一个新 Session 去尝试新方案，结果发现 8 个新文件的方案行不通，想要回到原方案：

利用内置的撤销/回滚能力 ：在 Claude Code 中，你可以通过类似 /undo 或查看历史状态的指令，让系统触发底层的 Checkpoint 回滚。

底层原理：由于底层的 Checkpoint 记录了文件修改前的快照，当你回滚到分叉前的那个对话节点时，Claude Code 的底层状态机会自动把磁盘上的 8 个新文件清理掉，并将那 15 个旧文件恢复。

局限：如果新旧方案你想同时保留、随时横向对比，单靠内置 Checkpoint 会比较痛苦，因为它是"单线覆盖"的。

路线 B：底层硬核隔离 ------ "Git 分支/Worktree" + "Claude Code Session"（生产环境推荐）

如果你需要绝对安全、文件级别完全隔离、并且随时可以左右横跳对比，最标准的架构做法是让 Claude Code 的 Session 与 Git 强绑定：
第一步（保存当前 15 个文件的进度）：

在原分支上，先让 Git 帮你做一次硬核 Checkpoint：
复制代码
git add .
git commit -m "feat: 完了方案一的15个文件重构"
第二步（创建物理隔离的工作区）：

切一个新的 Git 分支（或者使用 Git Worktree 在另一个目录打开）：
复制代码
git checkout -b experiment-solution-b
第三步（开启新的 Claude Code Session）：

在新的 Git 分支下启动一个新的 Claude Code。此时：

磁盘上的文件是独立的一套。

你在这个新 Session 里随便删文件、生成新文件，完全不会影响 experiment-solution-a 分支上的 15 个文件。

第四步（自由切换）：

如果想看原来的 15 个文件：git checkout solution-a，原分支的 Claude 状态和文件全部在线。

如果想看新方案：git checkout experiment-solution-b。
总结

Claude Code 的内置 Checkpoint 解决了"后悔药"的问题（单线操作中随时撤销某一步的改动）。

Git 分支 / Worktree 解决了"平行宇宙 "的问题（多套方案同时存在、文件物理隔离）。在做重大重构时，"Git 分离工作区 + 对应 Claude Session" 是最稳妥的工程实践。

注意：

/branch、/resume、/undo这些命令可以直接在CLI终端中使用，但无法直接在VSCode插件中使用，但插件中提供了**图形按钮，**可以实现同样的功能。

Fork conversation from here（仅分叉对话）
Rewind code to here（仅回滚代码）
Fork conversation and rewind code（分叉对话 + 回滚代码）

注意：Claude Code 的 File Checkpointing（检查点）机制只记录 Claude 自身通过 Edit/Write 工具修改的代码 。如果你在这期间自己手敲代码改了文件，或者在终端运行了命令修改了文件，Claude 是没有为其录入快照的，因此回滚时不会撤销这些手动修改。

2.Session存储的底层原理

3.Resume与Fork对比表

2.Agent SDK默认将哪三类状态写入容器本地磁盘？这些状态在容器重启、缩容或跨节点迁移时是否会丢？

2.子进程模式

3.SessionStore是镜像不是代替

4.四种Session部署方式

5.多租户隔离的坑

python 复制代码

for await (const message of query({
  prompt,
  options: {
    cwd: tenantDir,
    settingSources: [],
    env: {
      ...process.env,
      CLAUDE_CONFIG_DIR: configDir,
      CLAUDE_CODE_DISABLE_AUTO_MEMORY: "1",
    },
  },
})) { ... }

6.资源规划

3.Auto Memory(MEMORY.md)在session启动时被加载到上下文，决定加载量的条件是啥？

1.决定加载量的两个约束条件

2.MEMORY.md的定位是"索引"而非"记忆库"

3.两个约束的触发方式

4.实际案例：超限导致的问题

5.与CLAUDE.md的加载约束对比

6.Topic Files：突破200行限制的正确方式

误区：很多人看到 MEMORY.md 规定最多只能写 200 行，以为 Claude Code 的记忆库总共只能存 200 条信息。

真相：200 行的限制仅针对主索引文件 (MEMORY.md)。真正的知识可以拆成无数个独立的专题文件（Topic Files），这些专题文件没有行数上限。

在项目的 ~/.claude/projects/<hash>/memory/ 目录下，文件被分成了两层：

主索引层 (MEMORY.md)：

必须严格控制在 $\\le 200$ 行。

它里面只写目录、摘要和跳转链接/指针 （例如：[Testing setup](testing.md)）。

专题详情层 (Topic Files)：

比如 testing.md、api-conventions.md、debugging.md 等。

它们不在每次会话启动时加载，而是作为"知识仓库"静静躺在磁盘上。

整个过程就像去图书馆查资料：

启动加载轻量化 ：每次 session start（会话刚启动）时，系统只把作为目录的 MEMORY.md 载入内存，启动成本极低。

按需索取 ：当 Claude 在工作中突然遇到和测试相关的问题，它会扫描 MEMORY.md 索引，发现里面有一句 [Testing setup](testing.md) 指针。

主动读取 ：Claude 会主动去读取 testing.md 这个文件的具体内容。

用完即走（不常驻） ：读取到的详细内容只会临时进入当前的 turn（当前轮次）的上下文里辅助干活，不会永久常驻在全局记忆里占用宝贵的 Token 空间。

7.25K上限的由来

以前系统只检查 "行数不能超过 200 行"。

Anthropic 的生产数据中发现了一个极端边缘案例：

有个项目的 MEMORY.md 只有 197 行（顺利通过了小于 200 行的行数检查）。

但使用者把这 197 行的每一行都写了近 1000 个字符 ，导致整个文件体积膨胀到了 197KB！

结果：这个 197KB 的文本在会话刚启动时直接注入，一下子啃掉了 6000 ~ 8000 个 Token，直接把 Agent 后续对话的可用内存挤爆了。

因此，Anthropic 规定：自动记忆（Auto Memory）的常驻索引，绝对不能占用超过 200K Context Window 的 3%~4%（即 25KB 左右）。

4.CLAUDE.md与MEMORUY.md的区别？

在 Claude Code 中，CLAUDE.md 文件与 MEMORY.md（Auto-Memory 自动记忆系统）代表了两套完全不同逻辑的"记忆机制"。如果打个比方：CLAUDE.md 是你写给 AI 的"项目说明书/宪法"，而 MEMORY.md 是 Claude 自己在干活时记的"工作笔记本/日记"。

两者的核心区别如下表所示：

维度	CLAUDE.md 文件	MEMORY.md（自动记忆系统）
谁来编写	开发者手动编写（或用 `/init` 生成后修改）	Claude 自己自动记录（根据你的纠正和对话自动生成）
内容性质	固定的规则、指令、编码标准、架构规范	学习到的模式、调试心得、个人偏好、长期经验
存储位置	项目根目录、`.claude/` 或用户根目录 `~/.claude/`	保存在 `~/.claude/projects/<project>/memory/` 目录中
加载方式	每次会话开始时完整加载进上下文	每次会话加载 `MEMORY.md` 前 200 行（作为索引），更详细的子文件按需加载
版本控制	通常会提交进 Git，供团队成员共享	属于个人私有，默认不提交进 Git
通俗比喻	宪法 / 公司的SOP 规范	AI 自己的工作笔记 / 随手记

2.两类记忆的设计哲学

3.生命周期拆解

4.两类记忆的内容边界

5.各Agent竞品对比

6.容量管理与溢出策略

5.CC的Memory机制（CLAUDE.md、session记忆、MEMARY.md）如何工作？

复制代码

新会话启动
  ↓
加载 CLAUDE.md 层级（global → project root → .claude/rules/ → local）
  ↓
加载 MEMORY.md 前 200 行（或前 25KB，取较小值）
  ↓
拼接为 user-context message 注入 system prompt 之后
  ↓
会话进行中，Claude 发现值得记住的信息 → 提议写入 MEMORY.md
  ↓
会话结束，记忆持久化在磁盘上

与通用Agent Memory对比

6.CLAUDE.md是提示词级别的软约束，而非代码/系统级别的硬约束

CLAUDE.md 里的内容只是给模型看的"参考背景/上下文"，而不是客户端会去硬性解析并拦截的"强制配置文件"。

什么叫 Enforced Configuration（强制配置）？

比如 .gitignore 或者我们前面学过的 Hooks 配置（如 PostToolUse / Stop）。这些是由系统/程序底层（JavaScript 代码）直接拦截并强制执行的规则。系统发现不符合就直接报错或拒绝，模型无法反抗。

什么叫 Context（上下文）？

CLAUDE.md 里的规约（例如"修改代码后跑 pytest"或"代码风格用 2 空格缩进"）。它只是一段自然语言文本，模型读取后会"尽量照做"，但没有任何底层的代码机制能 100% 保证模型始终听话。

CLAUDE.md 到底注入到了哪里？

注入身份 ：在 query.ts 的上下文组装中，CLAUDE.md 的文本会被包装成一条 user message （用户消息）注入到模型 Context Window 里，而不是底层不可篡改的 System Prompt。

注意力竞争：既然它是普通对话消息，就会和你后续发出的数十轮对话、工具返回的几千行报错混在一起，共同竞争模型的 Attention（注意力机制）。

退化效应 ：随着会话越来越长（Context 越堆越高），CLAUDE.md 在历史记录中的位置被挤得越来越靠前，它写的指令被模型"遗忘"或冲淡的概率就会越来越高。

知道了这个特性，你在设计 Agent 开发工作流时就必须遵循 "分层治理" 的原则，不能把安全性或关键门禁寄托在 CLAUDE.md 上：

校验类型 能否写在 CLAUDE.md 中？ 正确的技术方案 治理逻辑

代码风格/建议 可以（如：优先用 TypeScript 写高阶函数） CLAUDE.md 声明软约束，错了一两处不影响系统运行。

工作流范式 可以作为起点（如：重构流程推荐先跑一遍 review） Skills 链式封装 (Chained Skills) 把多步动作标准化为固定 Pipeline。

安全/质量硬门禁 绝对不行 （如：禁止修改 .env 文件、改完必须跑 Lint） Hooks 系统硬拦截 系统底层死把关，绕过大模型意志。

在 CLAUDE.md 里写规约是给模型看建议，在 Hooks 里写脚本才是给系统下死命令。

校验类型	能否写在 CLAUDE.md 中？	正确的技术方案	治理逻辑
代码风格/建议	可以（如：优先用 TypeScript 写高阶函数）	`CLAUDE.md` 声明	软约束，错了一两处不影响系统运行。
工作流范式	可以作为起点（如：重构流程推荐先跑一遍 review）	`Skills` 链式封装 (`Chained Skills`)	把多步动作标准化为固定 Pipeline。
安全/质量硬门禁	绝对不行（如：禁止修改 `.env` 文件、改完必须跑 Lint）	`Hooks` 系统硬拦截	系统底层死把关，绕过大模型意志。

在搭建安全的 Agent 开发工作流或自动化闭环（Unattended Run）时：

指导 AI 怎么写代码 → 用 CLAUDE.md；

阻止 AI 干坏事/危险操作 → 用 PreToolUse Hook；

定义整个团队的安全红线 → 用 Managed Settings。

这段 JSON 配置的作用是在 Claude Code 中注册一个 PreToolUse 前置防御钩子 ，用来硬性拦截并禁止执行高危命令（如 deploy-prod.sh）。
复制代码
{
  "hooks": {
    // 1. 触发时机：在工具（Tool）被真正下发执行之前的"临门一脚"
    "PreToolUse": [
      {
        // 2. 匹配目标：只针对模型尝试调用 "Bash" 终端工具时生效
        "matcher": "Bash",
        "hooks": [
          {
            // 3. 执行类型：通过调用本地命令行脚本（Shell）来把关
            "type": "command",
            // 4. 真正执行的安全检查脚本路径
            "command": ".claude/hooks/block-deploy.sh"
          }
        ]
      }
    ]
  }
}
当 Claude 在 Agent Loop 里生成了一条指令（比如：Bash(command="./deploy-prod.sh")）并准备下发给系统执行时：

强行拦截 ：系统检测到触发了 PreToolUse 的 Bash 匹配器，暂停下发该命令。

脚本校验 ：系统先在后台静默运行 .claude/hooks/block-deploy.sh，并把 Claude 准备执行的命令作为参数传给这个脚本。

安全裁决：

允许通过 ：如果脚本检查无害，返回退出码 0（Exit Code 0），系统放行，Claude 成功执行命令。

硬性拒执行 ：如果脚本在传入命令里发现了 deploy-prod.sh 关键字，脚本返回非零退出码。

阻断结果：系统直接拒绝执行该命令，并将阻断原因回抛给 Agent。

7.修改CLAUDE.md后不会在当前session立即生效

8.CLAUDE.md与MEMARY.md属于哪一层prompt cache？

1. 什么是前缀匹配（Prefix Matching）？

核心机制 ：Anthropic 的 Prompt Caching API 采用的是严格的前缀匹配 机制------系统会从第一个 Token 开始，连续匹配到哪，缓存就生效到哪。

"一损俱损"的连锁效应 ：这意味着，如果请求的中间某一层发生了改变，这层之后的所有缓存将全部失效，无论后面的内容有没有发生变化。

实际影响示例：假设一个会话（Session）跑了 50 轮对话，上下文积累到了 100K token。如果最前方的 System Prompt 层（如工具定义）发生了改变，那么这 100K token 的缓存将全部失效并需要重算。但如果是 Conversation 层仅追加了新消息，前面的缓存就能全部命中，只需处理新追加的内容。

2. 什么是分块缓存（Chunk-based Caching）？

直觉设想 ：很多人在设计系统时，第一直觉会产生一个疑问："为什么不按文件级别做分块缓存？比如修改了 CLAUDE.md，就只让 CLAUDE.md 对应的那个区块失效，其他区块保持不变？"这种将不同文件或模块独立切块、各自独立缓存的方案，就是分块缓存。

技术现实 ：图片中明确指出，Anthropic 的 prompt caching API 并不支持分块缓存，它只认从头到尾的连续前缀。

正是因为 API 仅支持前缀匹配而不支持分块缓存，Claude Code 在设计时进行了精妙的位次编排：把改动频率相对较低的 CLAUDE.md 放在了动态对话历史（Conversation）的前面。

这样做的优势：通过将相对稳定的配置前置，可以最大程度地保护后面一大堆历史消息的缓存不被轻易打断，从而确保整体系统的缓存命中率与性能。

Claude Code 的提示词缓存不是全局共享的，而是"按项目目录和运行环境严格隔离"的。

一、为什么缓存不能全局共享？（目录与环境隔离）

原因：Claude Code 在每次会话启动时，其 System Prompt 中会动态嵌入很多强环境绑定的信息（例如：当前工作目录绝对路径、操作系统版本、Shell 类型、Auto Memory 文件的路径等）。

结果：因为底层 API 采用的是严格的"前缀匹配"，只要两个会话的目录或环境变量有一点不同，生成的缓存前缀就完全不一致，缓存无法跨目录互相命中。

典型场景 ：哪怕是同一个 Git 仓库，如果你开两个不同的 worktree（工作树），由于它们的物理文件夹路径不同，系统也会各自独立建立两套缓存，无法复用。

二、什么情况下多个 Session 可以共享缓存？

同目录并行 ：只有在同一个目录（Directory）下并行启动的多个 session，才有机会共享同一份缓存。

前提条件 ：它们的启动时 Git 状态快照（Git Status Snapshot）必须保持一致。如果一个改了代码没提交、另一个是干净的工作区，由于 Git 状态变了，缓存也会发生断裂。

理解这个机制有助于我们在本地进行多任务并行开发时做到心中有数：

在同一个项目目录下频繁开多个窗口跑任务，可以高效利用缓存，节省大量 Token 和推理延迟。

但如果跨不同项目、不同目录，缓存是完全独立的，不会产生干扰。

Prompt Cache（提示词缓存） 是一种在大语言模型（LLM）API 中用于降低延迟、节省成本的底层技术机制。

简单来说，它的本质就像浏览器的本地缓存或 CPU 的一级缓存------避免对重复输入的文本进行重复的计算（Token 预处理与 KV 矩阵计算）。

1. 为什么需要 Prompt Cache？

在与 AI 进行长对话或使用 Agent（如 Claude Code）干活时，我们发送给模型的所有内容都会包含大量的固定背景信息，例如：

系统的 System Prompt（如 AI 的人设、工具定义、安全规则）；

项目中的 上下文配置 （如 CLAUDE.md 中的代码风格要求、自动记忆 MEMORY.md）；

累积的长 历史对话记录。

在传统的调用方式中，即使你的这部分背景信息一个字都没改，每次你发一条新消息，大模型 API 都需要从头到尾把这几万甚至几十万 Token 的背景内容重新计算一遍。这不仅极度浪费 Token 费用，还会带来明显的等待卡顿。

Prompt Cache 的出现，就是为了解决这个"重复计算"的痛点。

2. Prompt Cache 是怎么工作的？

当你第一次发送一段长的 Prompt 时：

写入缓存：大模型服务端会将该 Prompt 前半部分固定文本计算出的中间状态（KV Cache）存储在服务器内存中，并打上缓存标记。

命中缓存（Cache Hit）：在后续请求中（比如你接着提问第 2 轮、第 3 轮），只要前面的背景文本没有发生变化，服务端就会直接读取保存好的缓存状态。

效果收益：

大幅降本：对于命中的缓存 Token，通常可以享受 90% 以上的 API 费用折扣。

显著提速：模型无需重新计算长文本，响应首字延迟（TTFT）大幅缩短，体验极其流畅。

3. Prompt Cache 的核心规则与特点

在实际系统设计（如 Claude Code 架构）中，Prompt Cache 遵循以下几个关键技术特征：

前缀匹配（Prefix Matching） ：缓存是严格从第一个 Token 开始连续匹配的。如果中间某一段文本发生了改动，该段改动之后的所有内容缓存都会瞬间失效。这就是为什么 Claude Code 会把不常修改的配置放在前面、把频繁变动的对话放在后面的原因。

存在存活时间（TTL）：缓存不是永久保留的，服务器通常会设定一个 TTL（例如默认 5 分钟或开启长缓存后 1 小时）。如果在 TTL 内没有新请求，缓存就会被自动释放。

隔离粒度（Cache Scope）：缓存不是全局通用的。如果运行环境、项目路径（如不同目录或 Git 工作树）发生了变化，生成的缓存前缀也会不同，无法跨环境共享命中。

Prompt Cache 就是让 AI "记住你之前发过的长背景，下次提问时直接接着看增量，不再重新死记硬背" 的计算复用技术。

9.CLAUDE.md文件过大，有什么缓解上下文开销与提升指令遵循率的方法？

错觉（文件结构清晰） ：许多开发者为了不让 CLAUDE.md 显得太长，会在主文件中写上 @rules/git.md 或 @rules/style.md。表面上看 CLAUDE.md 变得只有几行，好像完成了"瘦身"。

现实（预处理器全量展开） ：在 CLI 启动做上下文初始化时，预处理器（Preprocessor）遇到 @path 语法会自动去读取对应的目标文件，把目标文件的全文无缝展开并直接拼接到内存的 Context Window 中。

工程结论：

import (@path) 只是为了人类开发者在代码仓库中好维护文件（类似于代码里的文件拆分/模块导入）。

它完全无法降低 Token 占用。如果被引用的子文件加起来有 300 行，模型在启动时依然会接收到 300 行的全局 Token 压力。

如何区分 Rules 与 Skills？两种方案怎么选？

很多人容易把 .claude/rules/ 和 .claude/skills/ 混淆，两者的根本区别在于加载触发机制（Trigger Mechanism）与适用哲学（Purpose）。

维度 Rules (.claude/rules/) 图片.jpg Skills (.claude/skills/) 图片.png+ 1

定位 "约束与准则"（How to behave） "工具与程序"（How to execute）

加载机制 Path-scoped（路径/作用域触发） Invocation-scoped（显式/意图调用触发）

触发条件 当 Agent 触碰/编辑特定路径的文件 时自动加载（如改 Button.vue 时才加载组件规范）当用户输入 /skill-name 或模型判断需要执行特定复杂工作流时才动态加载

生命周期 在相关文件操作期间常驻上下文按需拉取，完成特定步骤/校验后可释放

典型示例 src/api/ 下的文件必须遵守 RESTful 规范自动跑 Lint + Build + Test 这一整套多步重构链条 (/verify)

2. 选型决策指南（怎么选？）

遵循 "按需加载（Lazy Loading）" 的核心原则，你可以根据以下场景进行选择：
复制代码
                    ┌─────────────────────────┐
                    │ 你的配置/指令属于哪种？  │
                    └────────────┬────────────┘
                                 │
         ┌───────────────────────┴───────────────────────┐
         ▼                                               ▼
【声明性规范 / 约束】                             【过程性步骤 / 工具流】
"改此类文件时必须遵守的铁律"                      "需要特定触发的组合动作"
         │                                               │
         ▼                                               ▼
放到 .claude/rules/                              放到 .claude/skills/
例如：                                           例如：
- Vue 组件的命名规范                             - 一键生成单元测试框架 (/gen-test)[cite: 15]
- 数据库 Migration 编写禁忌                       - 发布前的安全与性能审查链条 (/verify)[cite: 15]
（仅当改到对应目录/文件时才自动加载）          （显式输入斜杠命令或意图匹配时加载）

维度	Rules (.claude/rules/) 图片.jpg	Skills (.claude/skills/) 图片.png+ 1
定位	"约束与准则"（How to behave）	"工具与程序"（How to execute）
加载机制	Path-scoped（路径/作用域触发）	Invocation-scoped（显式/意图调用触发）
触发条件	当 Agent 触碰/编辑特定路径的文件时自动加载（如改 `Button.vue` 时才加载组件规范）	当用户输入 `/skill-name` 或模型判断需要执行特定复杂工作流时才动态加载
生命周期	在相关文件操作期间常驻上下文	按需拉取，完成特定步骤/校验后可释放
典型示例	`src/api/` 下的文件必须遵守 RESTful 规范	自动跑 Lint + Build + Test 这一整套多步重构链条 (`/verify`)

**无 paths 声明的规则文件在效果上与直接写在 CLAUDE.md 中是一样的，**它们都会在每次会话时加载，只是让文件的组织结构更加清晰。

由于它会"每次会话都加载，跟写在 CLAUDE.md 里一样"，它会占用会话的上下文长度。 它无法像带有 paths 声明的规则那样通过路径匹配来实现"不匹配则跳过、不消耗 token"的资源优化。唯一的好处就是文件组织更清晰了。

10.哪些写作特征会降低CLAUDE.md的指令遵循率？

避开"模糊动词"，使用强指令与明确断言

反面教材：使用"尽量避免"、"考虑使用"、"适当处理"等模棱两可的词汇，模型无法准确判断何时执行。

正面规范 ：使用确定、绝对的指令表达，例如 IMPORTANT: 永远不要在 controller 层直接写 SQL，所有查询必须走 repository 层。

简化逻辑，拒绝"多重嵌套条件"

反面教材："如果是在生产环境下，并且用户量超过一定阈值，同时没有开启缓存的情况下，应该..."这类套娃复杂的逻辑判定，模型很难稳定解析。

正面规范：拆分为清晰的单条逻辑或规则。

明确 Scope（作用域），防止规则混淆

反面教材 ：把只适用于 frontend/ 的前端规则写在根目录 CLAUDE.md 里与后端规则混在一起，导致模型搞不清哪条该用。

正面规范 ：全局 CLAUDE.md 只保留通识；特定模块的规则采用带 paths 匹配的路径级规则（.claude/rules/）进行隔离。

标注 Priority（优先级），区分红线与建议

反面教材：所有指令平铺直叙，没有区分"绝对不能违反"和"最好这样"。

正面规范 ：显式使用 IMPORTANT: 或 YOU MUST 等前缀标记核心规约。

控制文件体积，严防"文件膨胀"

原理：系统提示已占用了约 50 条指令位，当总指令数超过 150-200 条时，模型的遵守率会明显下降。

正面规范 ：严格将 CLAUDE.md 行数控制在 200 行以内（建议 100 行左右），并将最高优先级的铁律放在文件靠前的位置（如前 20 行）。