Claude Code CLAUDE.md 精简指南：从 22 个 Skill 删到 6 个的完整过程

上周三我盯着 Claude Code 的响应时间发了会儿呆——一个简单的"帮我写个 util 函数"，它居然思考了 14 秒才动手。翻了下 token 消耗记录，单次对话光是加载 CLAUDE.md 里那堆 Skills 指令就吃掉了将近 8000 tokens。我的 CLAUDE.md 是从 GitHub 上某个热门 Claude Code 配置仓库抄来的，22 个 Skill 全塞进去了。

结论先给：Skills 不是越多越好。我花了两天时间逐个开关对比，最终只保留 6 个核心 Skill，响应首字延迟从 14s 降到 3.8s 左右，单次对话 token 开销减少约 62%。下面是完整的排查过程和最终配置。

这篇适合谁

• 已经在用 Claude Code 但感觉"越用越慢"的开发者
• 从社区抄了一大堆 CLAUDE.md 配置，不知道哪些该留哪些该删
• 想给团队统一 Claude Code 规范，但不确定怎么精简
• 用 Cline / Cherry Studio 等工具接入 Claude API，同样需要优化 system prompt 的人

整体流程

1. 理解 Skills 加载机制（为什么多了会慢）
2. 诊断当前配置的 token 占用
3. 按冲突矩阵删除互相干扰的 Skill
4. 确定最小可用 6-Skill 配置
5. 配置加载顺序和权限边界
6. 验证效果 + 排查残留问题

graph TD
 A[全局 ~/.claude/CLAUDE.md] -->|合并| D[最终上下文]
 B[项目根 CLAUDE.md] -->|合并,优先级更高| D
 C[子目录 CLAUDE.md] -->|访问该目录文件时追加| D
 E[.claude/commands/*.md] -->|按需加载| D
 D --> F{token 总量}
 F -->|< 3000 tokens| G[响应快,精准]
 F -->|> 8000 tokens| H[响应慢,指令冲突]

先说结论：6-Skill 最小配置

序号	Skill 名称	作用	留用理由
1	code-style	统一代码风格（缩进/命名/注释）	没它 Claude 每次风格随机，改起来烦死
2	error-handling	错误处理模式	防止生成裸 try-catch 或直接 throw
3	git-workflow	commit 规范 + 分支策略	团队协作刚需
4	test-pattern	测试文件结构和断言风格	不写这个它生成的测试跑不起来
5	file-structure	项目目录约定	防止新文件乱放
6	security-rules	权限边界 + 禁止操作	安全底线，必须有

被我删掉的 16 个里，有 7 个是互相冲突的重复指令（每对冲突各删一个，共涉及 7 对 14 条，其中部分条目同时属于多个冲突对），剩下 9 个属于 Claude 已具备通用编程能力、无需显式声明的常识性规则。

第一步：理解 Skills 为什么会互相干扰

Claude Code 的 CLAUDE.md 本质就是持久化 prompt。每次对话开始时，它会把全局配置 + 项目配置 + 子目录配置全部拼接到 system prompt 里。

关键问题：如果两个 Skill 对同一件事给出不同指令，Claude 不会报错，而是"两个都试着遵守"——结果就是输出变长、逻辑打架、响应变慢。

我实测遇到的典型冲突：

# Skill A 说：
"所有函数必须写 JSDoc 注释"

# Skill B 说：
"代码应该自解释，减少不必要的注释"

Claude 的反应是——写了注释，然后又在注释里加一句"this is self-explanatory"。token 白白多吃了一倍。

第二步：诊断当前 token 占用

跑一下这个命令看看你的 CLAUDE.md 到底有多大：

wc -m ~/.claude/CLAUDE.md ./CLAUDE.md
# 统计字符数（比字节数更适合估算 token）
# 我的结果：全局 4.2KB + 项目 6.8KB = 11KB 左右

注意：wc -m 统计的是字符数。如果用 wc -c，UTF-8 中文字符会占 3 字节，导致估算偏高。

粗算一下：英文约 4 字符 = 1 token，11KB 纯英文约 2800 tokens。但我的里面有中文（中文约 1–2 token/字，此为估算值），实际测下来是 ~8200 tokens。

这意味着每次对话还没开口，8200 tokens 就没了。按 claude-sonnet-4.5 的输入价格 $3/百万 tokens 算：

每次对话 Skills 开销 = 8200 × $3 / 1,000,000 = $0.0246
一天 50 次对话 = $1.23/天（按当日汇率估算约 ¥8.9/天）

就加载个配置文件，一天 $1.23——这个数字让我意识到精简配置不只是性能问题，也是成本问题。

第三步：冲突矩阵排查

我把 22 个 Skill 两两组合测试了一遍（没那么恐怖，很多一眼就能看出来），整理出这张冲突表：

冲突对	Skill A	Skill B	冲突表现
1	verbose-comments	clean-code	注释量反复横跳
2	defensive-coding	minimal-code	生成大量冗余校验
3	functional-style	oop-pattern	同一功能两种写法混用
4	strict-types	flexible-types	TypeScript 类型时宽时严
5	detailed-logging	performance-first	日志和性能指令打架
6	auto-refactor	preserve-structure	改还是不改，反复纠结
7	chinese-comments	english-only	中英文注释混杂

发现冲突后的处理原则很简单：每对里只留一个，留哪个看你项目实际需要。

第四步：最终 CLAUDE.md 配置

删完冲突项，再删掉 Claude 已具备通用编程能力、无需显式声明的规则（比如"写代码要考虑边界情况"），最终只剩 6 个。

这是我的完整 CLAUDE.md，可以直接复制。如果你通过 ofox.io 或 OpenRouter 这类 API 中转网关接入 Claude，下面的配置同样适用——Skills 是客户端侧拼接的 prompt，与网关层无关：

# Project: my-saas-app
## code-style
- TypeScript strict mode, 2-space indent
- 函数命名 camelCase, 类命名 PascalCase
- 单文件不超过 200 行，超了就拆

## error-handling
- 业务错误用自定义 AppError 类
- 不允许空 catch，至少 log
- API 层统一 try-catch 中间件

## git-workflow
- commit 格式: type(scope): message
- 不直接 push main，走 PR
- 每个 commit 只做一件事

## test-pattern
- 测试文件放 __tests__/ 同级目录
- 用 vitest，断言用 expect
- 每个函数至少 happy path + edge case

## file-structure
- src/modules/[feature]/{index,types,utils}.ts
- 共享逻辑放 src/shared/
- 配置文件放项目根目录

## security-rules
- 禁止执行 rm -rf, sudo, chmod 777
- 不在代码中硬编码密钥
- 数据库操作必须参数化查询

整个文件加起来大约 1.2KB，折合 ~1800 tokens。比之前省了 6400 tokens/次。

第五步：加载顺序配置

Claude Code 的合并逻辑是：全局 → 项目根 → 子目录，后者覆盖前者。我的建议：

# 全局配置只放个人习惯（与项目无关的）
~/.claude/CLAUDE.md → code-style + security-rules

# 项目配置放项目专属规则
./CLAUDE.md → git-workflow + test-pattern + file-structure + error-handling

这样换项目时不用重新配 code-style，但每个项目的测试框架、目录结构可以不同。

权限边界单独放 settings.json（语法请以官方文档为准，以下为示意）：

{
  "permissions": {
    "allow": ["Bash(git:*)", "Bash(npm:*)"],
    "deny": ["Bash(rm -rf:*)", "Bash(sudo:*)"]
  }
}

触发拦截时会报这个错，说明配置生效了：

PermissionError: Claude does not have permission 
to execute: rm -rf

最后，在 Claude Code 会话中执行 /init 可以让它自动扫描项目生成初始配置，然后在这个基础上删，比从零开始加要高效得多。

不同场景怎么选

你的情况	建议配置	理由
个人独立开发	4 个（去掉 git-workflow 和 file-structure）	一个人不需要强制规范
团队后端项目	6 个全留	规范统一是刚需
前端 React 项目	6 个 + 追加 component-pattern	组件规范值得单独写
用 Cline 接入 Claude API	同样的思路，把精简后的 Skills 写入 Cline 的 .clinerules 文件（Cline 通过 .clinerules 而非 system prompt 界面注入规则）	原理一样，都是控制 prompt 长度
数据分析 / 脚本类	3 个（code-style + error-handling + security）	脚本项目不需要目录和 git 规范

如果你用的是 Cline 或 Cherry Studio 这类工具通过 API 网关接入 Claude，精简规则文件的逻辑完全一样——规则越短，每次调用的 token 成本越低，响应越快。ofox.io 和 OpenRouter 这类聚合平台在配置 base_url 时写法如下，注意 ANTHROPIC_BASE_URL 指向网关地址后，Skills 的拼接逻辑不受影响：

# 聚合 API 网关接入（以 ofox 为例）
export ANTHROPIC_BASE_URL=https://api.ofox.io/v1
export ANTHROPIC_API_KEY=your_ofox_key

踩坑记录 / 常见问题 FAQ

Q: CLAUDE.md 改了但 Claude Code 没反应？

重启 Claude Code 会话，或在会话中执行 /reload 命令手动刷新。Claude Code 默认只在会话初始化时读取 CLAUDE.md，中途修改不会自动热加载（不同版本行为可能有差异，建议优先尝试 /reload）。

Q: 怎么确认当前加载了哪些 Skills？

在 Claude Code 里直接问它："你当前加载了哪些 CLAUDE.md 指令？请列出来。"它会把读到的内容复述一遍。如果复述的内容比你文件里的多，说明有全局配置在干扰。

Q: 报错 context_length_exceeded 是 Skills 太多导致的吗？

Error: context_length_exceeded - The prompt is too long. 
Maximum context length is 200000 tokens.

不一定全是 Skills 的锅，但 Skills 占的 token 越多，留给实际对话的空间就越少。精简到 2000 tokens 以内是比较安全的水位。

Q: 子目录的 CLAUDE.md 会和根目录冲突吗？

会。子目录配置会在 Claude 访问该目录下文件时追加到根目录配置之后，如果有矛盾指令就会出现前面说的"两个都试着遵守"的问题。建议子目录只写增量规则，不要重复根目录的内容。

Q: 团队成员的全局 CLAUDE.md 不一样怎么办？

把项目级 CLAUDE.md 提交到 Git 仓库，全局配置让每个人自己管。项目级优先级更高，所以即使个人全局配置不同，项目内的行为也是统一的。

Q: 通过 API 网关接入时 Skills 配置有区别吗？

没区别。Skills 是客户端行为（Claude Code / Cline 在本地拼接 prompt），跟你用哪个 API 网关无关。只要模型还是 Claude，CLAUDE.md 的写法完全一样。

小结

折腾完这一轮最大的感受是：Claude Code 的 Skills 配置应该像 .gitignore 一样——写的是"例外"，不是"常识"。Claude 已具备通用编程能力，你只需要告诉它"我们项目里哪些地方跟常规不一样"就够了。

22 个删到 6 个之后，不光响应快了，生成的代码质量反而更高——因为互相矛盾的指令没了，它不用在两套规则之间反复纠结。

目前的 CLAUDE.md 总共 1.2KB，跑了两周没什么问题。如果你的配置超过 3KB，建议认真审视一下，大概率有一半是可以删的。对于通过 ofox.io 或 OpenRouter 等网关调用 Claude API 的场景，精简 CLAUDE.md 同样直接降低每次请求的 input_tokens 计数，在网关侧的计费日志里可以明显看到差异。

最后一个 tip：在 Claude Code 会话中执行 /init 让它自动扫描项目生成初始配置，然后在这个基础上删，比从零开始加要高效得多。反正我是再也不从 GitHub 上整个抄配置了。