Claude Codesettingsrules

Claude Code 的两大控制支柱：settings.json 与 rules/*.md

2026-05-28

前文聊了 CLAUDE.md和 memory.md。Claude Code 的两大记忆支柱：静态显式记忆 vs 动态隐式记忆。

今天继续介绍剩下两个关键成员：settings.json 和 rules/*.md。它们一个负责控制 Claude 这个工具本身的行为，另一个负责让 Claude 在复杂项目中“按需翻阅”专业规范，避免被巨无霸文件烧光 Token。

一、settings.json：Claude 的“控制面板”

如果说 CLAUDE.md 是你教 Claude 怎么写代码，那么 settings.json 就是你用来配置 Claude 这个工具本身的开关与参数。

存储位置（全局生效）
- macOS / Linux：~/.claude/settings.json
- Windows：C:\Users\你的用户名\.claude\settings.json
核心作用：控制底层软件行为，例如：
- 默认使用哪个大模型（Opus / Sonnet）
- 是否开启深度思考（thinking mode）
- 是否启用自动记忆
- 终端主题风格
- Token 消耗上限（防止预算超支）

📌 简单理解：settings.json 像是公司行政部发的《办公设备使用规定》——它不关心你写什么业务代码，只规定你用什么电脑、能花多少电费、几点锁门。

二、rules/*.md：按需加载的“领域专家手册”

随着项目膨胀，你可能会把所有规范（组件规范、API 规范、状态管理规范、Git 规范、测试规范……）一股脑塞进 CLAUDE.md。最终这个文件动辄上千行——Claude 每次对话都要从头读一遍，不仅 Token 烧得心痛，还会让 AI “注意力涣散”，抓不住重点。

为了解决这个问题，rules/*.md 应运而生。它通常存放在项目根目录的 .claude/rules/ 下（也支持 .github/ 等路径），核心逻辑只有八个字：按主题解耦，按需加载。

它是如何工作的？

你把不同领域的规则拆成独立的 .md 文件。当 Claude 需要修改一个网络请求文件时，它会智能识别当前任务上下文，只主动读取 rules/api-handling.md，而自动忽略样式、Git 等其他规则文件。

🧠 一些实现细节：Claude 并不会神秘地“猜”出你要用哪个规则。通常你需要在 CLAUDE.md 的“规则索引”部分明确声明：“当涉及 API 调用时，请遵循 rules/api-client.md”，或者依赖工具自身的约定（例如文件名与任务关键词匹配）。但无论哪种方式，最终效果都是按需加载，避免全量灌输。

项目目录示例

├── .claude/  
│ └── rules/  
│ ├── vue-components.md # 组件开发规范：props 写法、setup 语法  
│ ├── tailwind-style.md # 样式规范：必须用原子类，禁止原生 CSS  
│ ├── api-client.md # 网络请求规范：Axios 拦截器、Token 刷新  
│ └── git-commit.md # Git 提交规范：feat:/fix: 前缀  
├── CLAUDE.md # 总纲：技术栈 + 规则索引  
└── ...

示例：`rules/api-client.md` 的内容

# 接口请求与数据处理规范

## 核心原则
- 所有 API 请求必须使用 `src/api/request.ts` 导出的封装客户端。
- 严禁在组件内直接使用 `fetch` 或原生 `axios`。

## 错误处理
- 异步请求必须包裹 `try...catch`。
- 业务错误码（如 401）必须调用全局状态（Pinia）的 `userStore.logout()` 处理。

当你对 Claude 说：“帮我对接一个获取用户资产列表的接口” —— 它发现自己要触碰 API 相关代码，就会主动加载 api-client.md，严格按照里面的规范写请求、做错误处理，绝不乱来。

三、四大记忆支柱 —— 一张图总结

文件	类比	作用
`settings.json`	公司的行政制度	控制 Claude 工具本身的行为（模型、预算、主题）
`CLAUDE.md`	团队的总工程师	规定项目技术栈、整体架构、核心约定
`rules/*.md`	各领域的专家	平时不说话，碰到特定模块时提供专业军规
`memory.md`	自己的错题本	Claude 自动记录的踩坑教训，防止重蹈覆辙