这篇文章的核心内容是来自cluade 的分享总结，项目开发时配置.cluade项目文件，1、项目级文件夹包含团队配置。你将其提交到git。团队中的每个人都遵循相同的规则、相同的自定义命令和相同的权限策略。2、全局~/.claude/文件夹包含你的个人偏好和机器本地状态，如会话历史和自动记忆。
在项目根目录设置CLAUDE.md是最常见的配置。但你也可以在~/.claude/CLAUDE.md中为所有项目设置全局偏好，甚至在子目录中为特定文件夹设置规则。Claude会读取所有这些文件并合并它们。 CLAUDE.md中应该包含什么 大多数人要么写得太多，要么写得太少。以下内容效果最佳。
应该写入：
- 构建、测试和lint命令（npm run test, make build等）
- 关键架构决策（"我们使用带有Turborepo的单体仓库"）
- 不明显的注意事项（"TypeScript严格模式已开启，未使用的变量是错误"）
- 导入约定、命名模式、错误处理风格
- 主要模块的文件和文件夹结构
不应写入：
- 适合放在linter或formatter配置中的内容
- 你已经可以链接到的完整文档
- 解释理论的长段落
- 保持CLAUDE.md在200行以内。超过这个长度的文件会占用太多上下文，Claude对指令的遵循度实际上会下降。
基本入门设置
如果你从头开始，以下是一个有效的渐进步骤。
- 步骤1. 在Claude Code中运行/init。它通过读取你的项目生成一个初始CLAUDE.md。将其编辑为基本内容。
- 步骤2. 添加.claude/settings.json，包含适合你技术栈的allow/deny规则。至少，允许你的运行命令并拒绝.env读取。
- 步骤3. 为最常做的工作流创建一两个命令。代码审查和问题修复是良好的起点。
- 步骤4. 随着项目增长，CLAUDE.md变得拥挤，开始将指令拆分为.claude/rules/文件。在有意义的地方按路径范围划分。
- 步骤5. 添加~/.claude/CLAUDE.md，包含你的个人偏好。这可能是"始终在实现前编写类型"或"偏好函数式模式而非基于类的模式"。
这确实是95%项目所需的一切。当你有值得打包的重复复杂工作流时，技能和代理才会派上用场。
rules/文件夹：可扩展的模块化指令
CLAUDE.md适用于单个项目。但一旦团队成长，你最终会得到一个300行的CLAUDE.md，没人维护，人人忽视。 rules/文件夹解决了这个问题。 .claude/rules/中的每个markdown文件都会自动与你的CLAUDE.md一起加载。而不是一个巨大的文件，你可以按关注点拆分指令
hooks系统：对Claude行为的确定性控制
CLAUDE.md指令很好。但它们只是建议。Claude大多数时候会遵循它们，但不是所有时候。你不能依赖语言模型始终运行你的linter，从不执行危险命令，或始终在完成时通知你。 Hooks使这些行为变得确定。它们是在Claude工作流程中特定点自动触发的事件处理程序。你的shell脚本每次都运行，没有例外。 所有hook配置都位于settings.json中的hooks键下。Claude Code在会话开始时快照配置，当事件触发时通过stdin接收JSON有效负载，并使用退出代码决定下一步操作
skills/文件夹：即时可用的可重用工作流
技能是Claude可以根据上下文自行调用的工作流，当任务与技能描述匹配时。技能监控对话并在适当时机行动。 每个技能都位于自己的子目录中，包含一个SKILL.md文件：
agents/文件夹：专业化的子代理角色
当任务足够复杂，可以从专用专家中受益时，你可以在.claude/agents/中定义一个子代理角色。每个代理都是一个markdown文件，具有自己的系统提示、工具访问和模型偏好：
settings.json：权限和项目配置
.claude/中的settings.json文件控制Claude允许和不允许做什么。这也是你的hooks所在的位置，你在此定义Claude可以运行哪些工具，可以读取哪些文件，以及在运行某些命令前是否需要询问。