初级
.claude/ 文件夹结构解析
.claude/ 文件夹结构解析
.claude/ 文件夹结构解析#
一份关于 CLAUDE.md、自定义命令、技能、代理和权限的完整指南,以及如何正确设置它们。
大多数 Claude Code 用户将 .claude 文件夹视为一个黑盒。他们知道它存在,也见过它出现在项目根目录中。但他们从未打开过它,更不用说理解里面每个文件的作用了。
这错失了一个良机。
.claude 文件夹是 Claude 在您项目中行为的控制中心。它保存着您的指令、自定义命令、权限规则,甚至 Claude 在不同会话间的记忆。一旦您理解了每个文件的作用和原因,您就可以将 Claude Code 配置成完全符合您团队需求的样子。
本指南将带您全面了解该文件夹的结构,从您每天都会用到的文件到那些设置一次就无需再管的文件。
两个文件夹,而非一个#
在深入探讨之前,有一件事值得提前了解:实际上有两个 .claude 目录,而不是一个。
第一个位于您的项目内部,第二个位于您的主目录中:

项目级文件夹保存团队配置。您将其提交到 git。团队中的每个人都会获得相同的规则、相同的自定义命令、相同的权限策略。
全局的 ~/.claude/ 文件夹保存您的个人偏好和机器本地状态,例如会话历史和自动记忆。
CLAUDE.md:Claude 的指令手册#
这是整个系统中最重要的文件。当您启动 Claude Code 会话时,它读取的第一件事就是 CLAUDE.md。它会直接将其加载到系统提示中,并在整个对话过程中牢记。
简单来说:您在 CLAUDE.md 中写的任何内容,Claude 都会遵循。
如果您告诉 Claude 在实现之前总是先写测试,它会照做。如果您说“永远不要使用 console.log 处理错误,总是使用自定义日志记录器模块”,它每次都会遵守。
在项目根目录放置 CLAUDE.md 是最常见的设置。但您也可以在 ~/.claude/CLAUDE.md 中放置一个,用于适用于所有项目的全局偏好设置,甚至可以在子目录中放置一个,用于特定文件夹的规则。Claude 会读取所有这些文件并合并它们。
CLAUDE.md 中应该写什么
大多数人要么写得太多,要么写得太少。以下是行之有效的内容。
应该写:#
- 构建、测试和代码检查命令(npm run test, make build 等)
- 关键的架构决策(“我们使用带有 Turborepo 的单体仓库”)
- 不明显的注意事项(“TypeScript 严格模式已开启,未使用的变量会报错”)
- 导入约定、命名模式、错误处理风格
- 主要模块的文件和文件夹结构
不要写:#
- 任何属于代码检查器或格式化程序配置的内容
- 您已经可以链接到的完整文档
- 解释理论的长篇大论
将 CLAUDE.md 保持在 200 行以内。超过这个长度的文件会开始占用太多上下文,Claude 对指令的遵循程度实际上会下降。
以下是一个简洁但有效的示例:
# 项目:Acme API
## 命令
npm run dev # 启动开发服务器
npm run test # 运行测试(Jest)
npm run lint # ESLint + Prettier 检查
npm run build # 生产构建
## 架构
- Express REST API,Node 20
- 通过 Prisma ORM 使用 PostgreSQL
- 所有处理器位于 src/handlers/
- 共享类型位于 src/types/
## 约定
- 在每个处理器中使用 zod 进行请求验证
- 返回格式始终为 { data, error }
- 永远不要向客户端暴露堆栈跟踪
- 使用日志记录器模块,而不是 console.log
## 注意事项
- 测试使用真实的本地数据库,而非模拟数据。首先运行 `npm run db:test:reset`
- 严格的 TypeScript:永远不要有未使用的导入大约 20 行。它给了 Claude 在这个代码库中高效工作所需的一切,而无需不断澄清。
CLAUDE.local.md 用于个人覆盖#
有时您有一个偏好是您个人特有的,而不是整个团队的。也许您更喜欢使用不同的测试运行器,或者您希望 Claude 总是使用特定模式打开文件。
在您的项目根目录创建 CLAUDE.local.md。Claude 会将其与主 CLAUDE.md 一起读取,并且它会自动被 git 忽略,因此您的个人调整永远不会进入仓库。

rules/ 文件夹:可扩展的模块化指令#
CLAUDE.md 对于单个项目效果很好。但是一旦您的团队壮大,您最终会得到一个 300 行的 CLAUDE.md,没人维护,大家也都不理会。
rules/ 文件夹解决了这个问题。
.claude/rules/ 内的每个 Markdown 文件都会自动与您的 CLAUDE.md 一起加载。您可以将指令按关注点拆分,而不是一个巨大的文件:
.claude/rules/
├── code-style.md
├── testing.md
├── api-conventions.md
└── security.md每个文件保持专注且易于更新。负责 API 约定的团队成员编辑 api-conventions.md。负责测试标准的人员编辑 testing.md。没有人会互相干扰。
真正的威力来自于路径作用域规则。在规则文件中添加一个 YAML 前言块,它只在 Claude 处理匹配的文件时激活:
---
paths:
- "src/api/**/*.ts"
- "src/handlers/**/*.ts"
---
# API 设计规则
- 所有处理器返回 { data, error } 格式
- 使用 zod 进行请求体验证
- 永远不要向客户端暴露内部错误详情当 Claude 编辑 React 组件时,它不会加载这个文件。只有当它在 src/api/ 或 src/handlers/ 内部工作时才会加载。没有 paths 字段的规则会无条件加载,每次会话都如此。
当您的 CLAUDE.md 开始显得拥挤时,这是正确的模式。
commands/ 文件夹:您的自定义斜杠命令#
开箱即用,Claude Code 有内置的斜杠命令,如 /help 和 /compact。commands/ 文件夹允许您添加自己的命令。
您放入 .claude/commands/ 的每个 Markdown 文件都会变成一个斜杠命令。
名为 review.md 的文件创建 /project:review。名为 fix-issue.md 的文件创建 /project:fix-issue。文件名就是命令名。

这是一个简单的例子。创建 .claude/commands/review.md:
## description: 在合并前审查当前分支的差异以发现问题
## 待审查的更改
!`git diff --name-only main...HEAD`
## 详细差异
!`git diff main...HEAD`
审查上述更改,关注:
1. 代码质量问题
2. 安全漏洞
3. 缺失的测试覆盖
4. 性能问题
按文件给出具体、可操作的反馈。现在在 Claude Code 中运行 /project:review,它会自动将真实的 git diff 注入到提示中,然后才让 Claude 看到。! 反引号语法运行 shell 命令并嵌入输出。这使得这些命令真正有用,而不仅仅是保存的文本。
向命令传递参数#
使用 $ARGUMENTS 来传递命令名之后的文本:
---
description: 调查并修复一个 GitHub issue
argument-hint: [issue-number]
---
查看此仓库中的 issue #$ARGUMENTS。
!`gh issue view $ARGUMENTS`
理解这个 bug,追踪其根本原因,修复它,并编写一个能捕获它的测试。运行 /project:fix-issue 234 会将 issue 234 的内容直接输入到提示中。
个人命令与项目命令#
.claude/commands/ 中的项目命令会被提交并与您的团队共享。对于您希望在任何项目中都能使用的命令,请将它们放在 ~/.claude/commands/ 中。这些命令会显示为 /user:command-name 而不是 /project:command-name。
一个有用的个人命令:每日站会助手、一个按照您的约定生成提交信息的命令,或者一个快速的安全扫描。
skills/ 文件夹:按需可重用的工作流#
您现在知道命令是如何工作的了。技能在表面上看起来类似,但触发方式根本不同。在我们继续之前,先了解一下区别:

技能是 Claude 可以自行调用的工作流,无需您输入斜杠命令,当任务与技能描述匹配时即可触发。命令等待您输入。技能则监视对话并在合适的时机行动。
每个技能都位于其自己的子目录中,并包含一个 SKILL.md 文件:
.claude/skills/
├── security-review/
│ ├── SKILL.md
│ └── DETAILED_GUIDE.md
└── deploy/
├── SKILL.md
└── templates/
└── release-notes.mdSKILL.md 使用 YAML 前言来描述何时使用它:
---
name: security-review
description: 全面的安全审计。在审查代码漏洞、部署前或用户提及安全时使用。
allowed-tools: Read, Grep, Glob
---
分析代码库中的安全漏洞:
1. SQL 注入和 XSS 风险
2. 暴露的凭据或密钥
3. 不安全的配置
4. 认证和授权漏洞
报告发现的问题,附带严重性评级和具体的修复步骤。
参考 @DETAILED_GUIDE.md 了解我们的安全标准。当您说“审查这个 PR 的安全问题”时,Claude 会读取描述,识别出匹配项,并自动调用该技能。您也可以使用 /security-review 显式调用它。
与命令的关键区别:技能可以捆绑支持文件。上面提到的 @DETAILED_GUIDE.md 引用会拉取一个与 SKILL.md 位于同一位置的详细文档。命令是单个文件。技能是包。
个人技能放在 ~/.claude/skills/ 中,可在您所有项目中使用。
agents/ 文件夹:专门的子代理角色#
当任务足够复杂,需要专门的专家时,您可以在 .claude/agents/ 中定义一个子代理角色。每个代理都是一个 Markdown 文件,拥有自己的系统提示、工具访问权限和模型偏好:
.claude/agents/
├── code-reviewer.md
└── security-auditor.md以下是 code-reviewer.md 的样子:
---
name: code-reviewer
description: 专家代码审查员。在审查 PR、检查 bug 或在合并前验证实现时主动使用。
model: sonnet
tools: Read, Grep, Glob
---
您是一位专注于正确性和可维护性的高级代码审查员。
审查代码时:
- 标记 bug,而不仅仅是风格问题
- 建议具体的修复,而不是模糊的改进
- 检查边界情况和错误处理漏洞
- 仅在规模重要时才注意性能问题当 Claude 需要进行代码审查时,它会在自己独立的上下文窗口中生成此代理。代理完成其工作,压缩发现结果,然后报告回来。您的主会话不会因数千个标记的中间探索而变得混乱。
tools 字段限制了代理可以执行的操作。安全审计员只需要 Read、Grep 和 Glob。它没有理由写入文件。这种限制是刻意的,值得明确说明。
model 字段允许您为专注的任务使用更便宜、更快的模型。Haiku 可以很好地处理大多数只读探索。将 Sonnet 和 Opus 留给真正需要它们的工作。
个人代理放在 ~/.claude/agents/ 中,可在所有项目中使用。

settings.json:权限和项目配置#
.claude/ 内的 settings.json 文件控制着 Claude 可以做什么和不可以做什么。您在这里定义 Claude 可以运行哪些工具、可以读取哪些文件,以及在运行某些命令之前是否需要询问。
完整的文件如下所示:
{
"$schema": "https://json.schemastore.org/claude-code-settings.json",
"permissions": {
"allow": [
"Bash(npm run *)",
"Bash(git status)",
"Bash(git diff *)",
"Read",
"Write",
"Edit"
],
"deny": [
"Bash(rm -rf *)",
"Bash(curl *)",
"Read(./.env)",
"Read(./.env.*)"
]
}
}以下是每个部分的作用。#
$schema 行在 VS Code 或 Cursor 中启用自动完成和内联验证。请始终包含它。
allow 列表包含无需 Claude 询问确认即可运行的命令。对于大多数项目,一个好的 allow 列表应涵盖:
- Bash(npm run *) 或 Bash(make *),以便 Claude 可以自由运行您的脚本
- Bash(git *) 用于只读 git 命令
- Read、Write、Edit、Glob、Grep 用于文件操作
deny 列表包含完全被阻止的命令,无论如何都不允许。一个合理的 deny 列表应阻止:
- 破坏性的 shell 命令,如 rm -rf
- 直接的网络命令,如 curl
- 敏感文件,如 .env 和 secrets/ 中的任何内容
如果某个命令不在任何一个列表中,Claude 会在继续之前询问。这种中间地带是刻意的。它为您提供了一个安全网,而无需预先预测每个可能的命令。
settings.local.json 用于个人覆盖#
与 CLAUDE.local.md 的理念相同。创建 .claude/settings.local.json 用于您不想提交的权限更改。它会自动被 git 忽略。
全局的 ~/.claude/ 文件夹#
您不经常与此文件夹交互,但了解其中的内容很有用。
~/.claude/CLAUDE.md 会加载到每个 Claude Code 会话中,跨越您所有的项目。这是放置您个人编码原则、偏好风格或任何您希望 Claude 记住的内容(无论您在哪个仓库中)的好地方。
~/.claude/projects/ 按项目存储会话记录和自动记忆。Claude Code 会自动保存其工作过程中的笔记:它发现的命令、观察到的模式、架构见解。这些内容在会话之间持续存在。您可以使用 /memory 浏览和编辑它们。
~/.claude/commands/ 和 ~/.claude/skills/ 保存可在所有项目中使用的个人命令和技能。
您通常不需要手动管理这些。但当 Claude 似乎“记住”了您从未告诉过它的内容,或者当您想清除项目的自动记忆并重新开始时,了解它们的存在会很方便。
全貌#
以下是所有内容如何组合在一起的:
your-project/
├── CLAUDE.md # 团队指令(已提交)
├── CLAUDE.local.md # 您的个人覆盖(被 git 忽略)
│
└── .claude/
├── settings.json # 权限 + 配置(已提交)
├── settings.local.json # 个人权限覆盖(被 git 忽略)
│
├── commands/ # 自定义斜杠命令
│ ├── review.md # → /project:review
│ ├── fix-issue.md # → /project:fix-issue
│ └── deploy.md # → /project:deploy
│
├── rules/ # 模块化指令文件
│ ├── code-style.md
│ ├── testing.md
│ └── api-conventions.md
│
├── skills/ # 自动调用的工作流
│ ├── security-review/
│ │ └── SKILL.md
│ └── deploy/
│ └── SKILL.md
│
└── agents/ # 专门的子代理角色
├── code-reviewer.md
└── security-auditor.md
~/.claude/
├── CLAUDE.md # 您的全局指令
├── settings.json # 您的全局设置
├── commands/ # 您的个人命令(所有项目)
├── skills/ # 您的个人技能(所有项目)
├── agents/ # 您的个人代理(所有项目)
└── projects/ # 会话历史 + 自动记忆一个实用的入门设置#
如果您是从头开始,以下是一个行之有效的渐进步骤。
步骤 1. 在 Claude Code 中运行 /init。它会通过读取您的项目生成一个初始的 CLAUDE.md。将其编辑到只剩要点。
步骤 2. 添加 .claude/settings.json,其中包含适合您技术栈的 allow/deny 规则。至少,允许您的运行命令并拒绝读取 .env。
步骤 3. 为您最常执行的工作流创建一个或两个命令。代码审查和问题修复是很好的起点。
步骤 4. 随着项目增长和 CLAUDE.md 变得拥挤,开始将指令拆分到 .claude/rules/ 文件中。在合适的地方按路径限定它们的作用域。
步骤 5. 添加一个包含您个人偏好的 ~/.claude/CLAUDE.md。这可能是类似“总是在实现之前先写类型”或“偏好函数式模式而非基于类”的内容。
对于 95% 的项目来说,这确实是您所需要的全部。技能和代理在您有值得打包的重复复杂工作流时才会用到。
关键见解#
.claude 文件夹实际上是一个协议,用于告诉 Claude 您是谁、您的项目做什么以及它应该遵循哪些规则。您定义得越清晰,您花在纠正 Claude 上的时间就越少,它花在做有用工作上的时间就越多。
CLAUDE.md 是您杠杆率最高的文件。首先把它弄对。其他一切都是优化。
从小处着手,逐步完善,并将其视为项目中任何其他基础设施:一旦设置得当,它每天都会带来回报。
到此结束!
如果您喜欢阅读本文。
找到我 → @akshay_pachaar ✔️
每天,我都会分享关于 AI、机器学习和氛围编码最佳实践的教程和见解。