把 Claude Code 装好，和把 Claude Code 配置成能真正干活的样子，是两件完全不同的事。很多人装完之后跑起来，发现它只会给建议、不会主动读代码、更不懂你项目的结构，于是得出“这东西不过如此”的结论。其实不是它不行，而是你还没把它当成一个团队成员来配置，它拿到的信息只有“你问了什么”，没有“我们在做什么、怎么做、边界在哪”。
这篇指南围绕的就是这件事：怎么把一个刚装好的 Claude Code，配置成一个真正能融入工程流程的 AI 团队。会涉及环境准备、安装路径、认证方式、记忆文件设计、权限管控、Skills / 子 Agent / Hooks / MCP 的进阶玩法，以及我在实际配置中踩过的坑。适合刚接触 Claude Code 的人，也适合已经跑通但觉得“不够顺手”的人。按这套思路配置完，你会明显感觉到它从“会聊天的助手”变成了“会干活的同事”。
1. 别急着装：先想清楚你要的是工具还是“团队成员”
1.1 配置的实质：从单机工具到团队协作者
Claude Code 本质上是一个跑在终端里的 AI 编程代理（AI Agent），它能读你仓库里的文件、执行命令、修改代码、运行测试。但它不是魔法，它的所有行为都基于两样东西：上下文和规则。上下文是它能看到什么，规则是它被允许做什么。配置 Claude Code 的过程，本质上就是在给这两样东西做设定。
你如果什么都不配置，它就像一个第一天入职、没看过文档、没被介绍过团队的实习生：态度很好，但不敢动代码，也不知道仓库结构，只能靠你一句一句喂。而配置到位之后，它知道自己负责什么模块、代码风格是什么、测试命令是什么、哪些目录不能碰、遇到问题时该找谁（哪个子 Agent）帮忙。
这个差异，比你想象中大得多。我见过不少团队把 Claude Code 接入项目后发现“它总在乱改代码”“它不理解项目结构”，最后又退回纯手动写代码。问题基本都出在配置阶段——他们把它当搜索框用了，而不是当团队成员来培养。
1.2 三种使用场景对应的三种配置深度
配置不是越深越好，得先想清楚你的使用场景：
| 场景 | 典型用户 | 配置重点 | 配置成本 |
|---|---|---|---|
| 日常问答与代码解释 | 初学者、管理者 | 基本安装 + 模型选择 | 极低，10 分钟 |
| 个人项目的实际编码助手 | 独立开发者、爱好者 | 项目级 CLAUDE.md + 权限规则 | 中等，半小时 |
| 团队协作的 AI 工程成员 | 研发团队、长期维护的开源项目 | 记忆文件分层 + Skills + Hooks + MCP + 子 Agent | 较高，需要持续迭代 |
我见过最典型的误区是：团队需要的是第三种，却只做了第一种的配置。文件没建、权限没管、工具链没接，然后希望它能像资深工程师一样工作，这不可能。
所以，你先给自己定个位：你只是玩玩，还是想让这个 AI 真正承担一部分研发工作？如果是后者，后面的内容值得全部看完。如果只是前者，看完第二节装好它就够了。
2. 装到能跑：环境准备与安装路径里最容易翻车的环节
2.1 Node.js 版本管理的正确姿势
Claude Code 是一个 npm 全局包，所以环境准备的第一步永远是 Node.js。这里我强烈建议你用 nvm（Node Version Manager）而不是直接去官网下载安装包。为什么？因为 Claude Code 迭代速度很快，经常要求较新的 Node 版本，nvm 能让你在多个版本之间随意切换，而不是为了一个工具去升级全局环境，结果把别的老项目搞崩了。
# macOS / Linux 安装 nvm curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash # Windows 用户不要用上面这个脚本，去搜 nvm-windows，用法略有不同装完 nvm 后，按当前推荐的版本要求装 Node。我写这篇文章时用的命令是：
nvm install 20 nvm use 20 node -v # 确认版本Windows 用户注意：Claude Code 在 Windows 上跑，推荐配合 Git Bash 或 Windows Terminal + WSL 使用，纯 CMD 下偶尔会有样式和交互问题。这不是 Claude Code 本身的问题，而是终端工具链的兼容性差异。如果你已经在用 WSL，直接在 WSL 里装 Node 和 Claude Code 是最省心的路径。
2.2 Git 配置：全局身份、默认编辑器与换行符
Claude Code 会经常调用 Git 来做提交、查看 diff、回滚等操作，所以 Git 配置是它能否顺利工作的前置条件。很多人在 Git 没配好的机器上跑 Claude Code，会遇到“明明让它提交代码，它却报错”的情况，原因不是 Claude Code 出问题了，而是 Git 本身缺少全局身份信息。
git config --global user.name "Your Name" git config --global user.email "you@example.com" git config --global core.editor "code --wait"Windows 上建议再确认一下换行符配置，否则 Claude Code 生成的代码文件可能出现 CRLF/LF 混用：
git config --global core.autocrlf input一个容易被忽略的点：Claude Code 执行 Git 命令时，如果你的仓库所在目录没有初始化 Git，或者当前在子目录里，它可能会困惑于该对哪个仓库操作。建议你平时就保持“项目根目录 = Git 仓库根目录”的习惯，这既利于 Git 管理，也利于 Claude Code 理解项目边界。
2.3 安装方式选型：npm 全局包、原生脚本、VS Code 插件
Claude Code 的安装方式主要有三种，我分别说下适用场景：
| 安装方式 | 命令 | 适用场景 |
|---|---|---|
| npm 全局包 | npm install -g @anthropic-ai/claude-code | 最通用，适合大多数用户，升级用 npm |
| 原生脚本 | curl -fsSL https://claude.ai/install.sh | bash | 官方推荐，支持claude update自动更新 |
| VS Code 插件 | 扩展市场搜索 “Claude Code” 安装 | 如果你主要在 VS Code 里开发，插件体验最顺 |
我个人的选择是：主用 VS Code，那就直接在扩展市场里装 Claude Code 插件，它会顺带把 CLI 装好；如果是在远程服务器、容器或者只能 SSH 的环境里，用原生脚本或 npm 包更合适。
三条路不冲突，同一台机器上可以同时有插件和 CLI，它们共享同一套认证和配置文件。但要注意别装出两套不同版本互相干扰，尤其是 npm 装了一份、原生脚本又装了一份的情况。验证当前版本：
claude --version2.4 安装后的自检清单
装完后别急着跑，按这个清单过一遍，能省掉后面很多莫名其妙的报错：
- 运行
claude命令，确认能进入交互界面。 - 输入
/status，确认登录状态。首次使用需要完成 OAuth 登录，浏览器会弹出来让你授权。 - 输入
/model，确认你想要的模型（Opus / Sonnet 等）可用。不同账号对模型的可访问性有差异，订阅档位不同能选的范围也不同。 - 随便问一句“请读一下当前目录的 README 并总结”来测试它的文件读取能力，如果这一步都做不了，优先排查路径权限问题。
这个列表看起来简单，但它是最快的“体检”。我见过有人折腾了半天，最后发现是根本没登录，API 请求全部失败。
3. 把“身份”交给 Claude Code：认证配置与账号体系
3.1 登录方式对比：OAuth 登录、API Key、订阅方案
Claude Code 的登录认证有三种常见路径，我分别说下适合谁：
| 认证方式 | 配置方式 | 计费方式 | 适合场景 |
|---|---|---|---|
| Claude 账号 OAuth | 首次运行claude自动弹出浏览器授权 | 消耗账号本身权限（Pro / Max 等） | 个人开发者，已订阅 Claude 账号 |
| Anthropic API Key | 设置环境变量ANTHROPIC_API_KEY | 按 API 调用量计费 | 团队统一管理、自动化脚本、后端接入 |
| 企业 / 团队账号 | 组织内配置好的 SSO 或账号体系 | 按组织订阅 | 研发团队统一采购和管理 |
我个人建议，如果是个人日常使用，OAuth 登录最简单。如果你要把 Claude Code 接入脚本或 CI 流程，那就得用 API Key，并且通过环境变量注入，而不是把 Key 写死在配置文件里。
export ANTHROPIC_API_KEY="sk-ant-xxxxx"注意：API Key 的保密等级等同于生产环境密码，别提交进 Git 仓库。我见过不止一次有人在项目里把.env文件一并提交，结果 API Key 泄漏，被刷爆账单的惨案。
3.2 配置项里最容易被忽略的模型与输出控制
登录只是第一步，真正决定体验的是模型选择和输出参数。你可以在/config面板里操作，也可以用命令行直接修改配置文件。
两个最容易忽略的配置项：
- 模型选择（model）：Opus 适合复杂架构决策、跨文件重构，Sonnet 适合日常编码、快速迭代。如果你不指定，默认模型可能不是最优解。我习惯在项目里显式指定，避免每次会话都要手动切。
- 输出 token 上限（max_turns / max_output_tokens）：这个很少有人改，但它在处理大型重构时很关键。默认值偏保守，长任务容易中途断掉。适当调高可以让 Claude Code 在一次任务里完成更多步骤，减少“我做到一半，你让我继续”的割裂感。
环境变量控制方式：
export ANTHROPIC_MODEL="claude-sonnet-4-20250514" export CLAUDE_CODE_MAX_OUTPUT_TOKENS="16384"这里解释下为什么这些变量重要：Claude Code 的长任务本质上是一个多轮循环——读文件、改代码、跑测试、再读文件。每轮循环的可用 token 决定了它“一口气能干多少活”。调大一点，长任务的连续性和稳定性会好很多。当然，也不是越大越好，过大的单轮输出反而容易失控，得根据你项目的复杂度试出一个适合自己的值。
3.3 配置文件的层级关系
Claude Code 的配置分布在几个不同的位置，搞清楚它们的优先级能避免很多困惑：
| 配置文件路径 | 作用范围 | 说明 |
|---|---|---|
~/.claude/settings.json | 全局 | 所有项目的默认配置 |
项目.claude/settings.json | 当前项目 | 覆盖全局配置 |
| 环境变量 | 当前会话 | 优先级最高，临时生效 |
实际操作中，我会把“通用偏好”（比如主题、默认模型）放在全局设置里，把“项目专属规则”（比如构建命令、测试命令、禁止修改的目录）放在项目设置里。这样换项目时，全局偏好保留，项目规则跟着仓库走，团队成员也能共享同一套配置。
4. 让 AI 记住团队规则：CLAUDE.md 的分层设计与维护节奏
4.1 全局记忆、项目记忆、子目录记忆的优先级
CLAUDE.md 是 Claude Code 的“长期记忆”文件，它会自动加载并在每次对话中作为背景知识存在。这个文件是配置的核心中的核心，比任何参数调整都重要。
它的层级关系是：
- 全局记忆：
~/.claude/CLAUDE.md，存你的通用偏好、通用编码习惯、所有项目的通用规则。 - 项目记忆：项目根目录的
CLAUDE.md，存当前项目的架构说明、技术栈、构建与测试命令、代码风格约定。 - 子目录记忆：子目录下的
CLAUDE.md，存该模块的专属说明，优先级高于项目根目录记忆。
子目录的 CLAUDE.md 是个容易被忽略但我实测很有用的功能。项目大了以后，根目录的记忆文件会越来越长，而 Claude Code 每次加载全部记忆会稀释重点。更好的做法是：根目录只放全局架构信息，把某个模块的专属逻辑下沉到对应子目录的 CLAUDE.md。这样它在处理某个模块时才会加载到最相关的上下文。
4.2 一份高质量 CLAUDE.md 应该写什么、不写什么
我见过很多人的 CLAUDE.md 写得像公司官网首页的“关于我们”：一堆你好、很高兴为你服务、我支持什么功能……这些全是废话。Claude Code 不需要被问候，不需要被夸奖，它需要的是能被直接执行的信息。
一份好用的 CLAUDE.md 应该包含以下几类内容：
- 项目的一句话定位：这个项目做什么的？让 AI 在遇到模糊任务时能自己判断什么方向是对的。
- 技术栈与关键依赖：后端用什么框架、前端用什么构建工具、数据库用什么。这能帮它少问很多问题。
- 常用命令：测试怎么跑、lint 怎么跑、构建怎么跑、部署怎么做。
- 目录结构总览：哪些是核心代码、哪些是生成代码、哪些是配置文件。
- 硬性边界：哪些目录绝对不能改（比如
dist/、node_modules/、generated/），哪些文件可以改但要谨慎。 - 架构约定：比如“新增功能必须带单元测试”“数据库迁移文件需要手写回滚脚本”“错误处理统一走自定义异常”。
我在实际项目里加过一句很简单的规则，“不要修改 docs/ 目录下的文件，那是设计团队维护的”，从那以后 Claude Code 就不再乱动那些文件了。你给它划清楚边界，它就不会越界；你没划，它就按它自己的默认逻辑来，而默认逻辑往往不匹配你们的实际流程。
不写什么也很重要：不要写模糊的形容词（比如“保持高质量代码”）、不要写太长的历史背景、不要写会经常变的信息（比如某个接口文档的完整参数列表，这更适合让 MCP 去查）。记忆文件一旦变得太长太旧，反而会变成干扰源。
4.3 用 /memory 和“迭代式校准”保持文档不过期
配置 CLAUDE.md 不是一次性工作，而是持续校准的过程。
我的做法是：在使用过程中，凡是发现 Claude Code 做了一件“因为不知道规则而做错”的事，我就会把规则补进 CLAUDE.md。比如有一次它把 ES Module 的代码改成 CommonJS 写法，我就在 CLAUDE.md 里明确写了“本项目统一使用 ESM，禁止引入 require”。新加一条规则之后，这个问题就再也没出现过。
Claude Code 提供了一个方便的入口：在对话里直接输入/memory，就能打开对应层级的 CLAUDE.md 进行编辑。日常维护节奏可以这样安排：
- 每次完成一个较大的功能，花两分钟检查有没有需要沉淀的规则。
- 每次升级了依赖或改了目录结构，同步更新记忆文件。
- 每周花一次时间，把不再适用的旧规则删掉。
这套节奏坚持下来，你的 CLAUDE.md 会成为团队里一份真实的“活文档”，而且它直接服务于 AI，和给人看的设计文档可以互补。
5. 从编辑器到团队工作台：VS Code 与桌面端的联动配置
5.1 VS Code 插件配置与集成调试
很多人习惯在终端里用 Claude Code，但如果你主要用 VS Code，我强烈建议装官方插件。插件的价值在于它能直接读取你当前打开的文件、选区、编辑器状态，这让 Claude Code 的上下文感知能力上一个台阶——它不再需要靠猜“你在说哪个文件”，而是可以直接看到你光标所在的位置。
在 VS Code 扩展市场搜索“Claude Code”，安装后，左侧会出现专属图标面板。首次使用时仍然需要走登录授权流程，但只需一次，CLI 和插件共享认证状态。打开命令面板（Ctrl+Shift+P），输入 “Claude” 能看到所有可用命令，比如开始新会话、选择模型、查看历史等。
一个常见的困惑是：插件的会话和命令行里claude的会话是不是同一个？严格来说它们是不同的界面入口，但底层共享配置和认证。所以你在命令行里设置好的 CLAUDE.md、skills、模型偏好，插件里同样生效。
5.2 桌面端的价值和与 CLI 的差异
标题和热词里都提到了“桌面版”和“桌面端”，这里说下我的理解。Claude Code 本身是一个命令行工具，但官方推荐的使用方式是在一个独立的终端窗口里跑它，而不是在 VS Code 的内嵌终端里和你的日常终端混在一起。这样做的理由很实际：Claude Code 会话很长，输出很多，和你的编译日志、Git 命令挤在一个终端里，很容易误操作或者被大量输出刷屏。
如果你是在 Linux 或 macOS 上，我建议给 Claude Code 单独开一个终端标签页，全屏跑，它会在里面展示文件 diff、交互菜单、任务进度，体验会比挤在某个编辑器终端里好很多。Windows 上用 Windows Terminal 新建一个专属标签页也能达到同样效果。这不算什么高深配置，但对实际使用舒适度的提升非常明显。
5.3 非交互模式：把 Claude Code 接进脚本和 CI
除了交互式对话，Claude Code 支持非交互模式（headless mode），这是它作为“团队成员”的时候最有价值的能力之一——它可以被脚本调用、接入 CI、在提交代码时自动跑起来干活。
# 一次性执行任务 claude -p "运行所有测试并总结失败原因" --allowedTools "Bash(npm test)" # 继续上一次会话 claude --continue -p "继续你刚才的任务" # JSON 输出，方便其他程序解析 claude -p "分析这个仓库的结构" --output-format json我实际用过的场景是：在 Git hooks 里嵌入一个 Claude Code 调用，提交代码时自动让它跑一遍测试，发现失败就帮忙定位原因，并把分析结果以注释形式追加到提交信息中。这样团队里每个人提交代码时，都会自动得到一次 AI 的“预审意见”。
这里必须提醒一个权限上的坑：非交互模式下如果配置了--dangerously-skip-permissions，等于把所有权限全部放开，Claude Code 会不加确认地执行任意命令。这在本地手动跑还好，但如果放到 CI 里、放到一个不安全的输入环境里，风险极高。正确做法是用--allowedTools精确列出它在这个任务里能执行的命令白名单。
6. 还能更强：Skills、自定义 Agent、Hooks 与 MCP 的进阶配置
6.1 Skills：让 Claude Code 具备“专项能力证书”
如果说 CLAUDE.md 是告诉 Claude Code“你们团队有哪些规则”，那么 Skills 就是告诉它“我们团队有哪些专用技能”。一个 Skill 由一组指令、参考代码和资源组成，放在特定目录下，Claude Code 会在相关场景下自动加载。
Skills 的目录结构长这样：
~/.claude/skills/ └── vue-component-generator/ ├── SKILL.md └── templates/SKILL.md是这个技能的核心说明，包含 YAML frontmatter 和正文指令。它的作用相当于“完整的操作手册”：Claude Code 会在遇到匹配场景时读取它，然后按照里面的步骤来执行。
--- name: vue-component-generator description: 当用户要求创建 Vue 组件时使用此技能，它会按团队规范生成组件模板和测试文件。 --- 创建 Vue 组件时，请遵循以下步骤： 1. 使用 Composition API 的 `<script setup>` 语法 2. 模板文件放在 src/components/ 下，按照 PascalCase 命名 3. 每个组件必须附带同名 .spec.ts 测试文件 4. 样式统一使用 scoped CSS，类名走 BEM 命名规范 ...我目前在个人项目里配置了好几个 Skills：一个负责生成项目里固定的模块文件结构，一个负责写规范的 Git 提交信息，还有一个是代码审查专用技能。这比每次在提示词里反复交代规则要高效得多——你只要在 prompt 里说“写一个新组件”，它就会自动匹配到对应技能并执行整套流程。
查看和调试 Skills：
claude --skills # 列出所有可用 Skills claude --debug # 调试模式，能看匹配过程6.2 自定义子 Agent：给团队添加专项角色
Claude Code 本身有一个主 Agent 负责统筹任务，但它还支持你自定义子 Agent（Subagent）——相当于给团队添加了几个专项角色：有人专职写测试、有人专职做代码审查、有人专职处理数据库迁移，主 Agent 会根据任务类型把它派给对应的人。
自定义子 Agent 放在~/.claude/agents/下，每个 Agent 是一个 Markdown 文件：
--- name: test-writer description: 专门负责编写单元测试和集成测试。当用户要求为新功能补充测试时使用。 tools: Read, Grep, Write, Edit, Bash model: opus --- 你是一个测试工程师，专门负责编写高质量的单元测试。在动手之前： 1. 先阅读被测代码，理解它的输入输出和边界条件。 2. 使用项目已有的测试框架和命名规范。 3. 测试用例要覆盖正常路径、异常路径和边界路径。 4. 写完后运行测试，确保全部通过。配置子 Agent 的关键点在于tools字段——你可以限制这个 Agent 能使用的工具范围。测试工程师不需要修改生产代码，那你就可以只给它 Read / Grep / Write / Bash 这几个工具，技术上限制它“越权操作”。这比在提示词里说一万句“你不要乱改代码”都管用。
6.3 Hooks：在关键事件上插入自动化校验
Hooks 是 Claude Code 的一套事件响应机制，可以在特定事件发生时执行外部命令。这相当于给 AI 成员加了一道道自动检测闸门。我配置过的最有用的两个 Hook：
一是PreToolUse：在 Claude Code 执行敏感命令之前，先跑一层检查。比如它要执行git push之前，先检查当前分支、检查是否有未提交的变更，如果状态不对就拒绝执行。
二是PostToolUse：在它执行完某个操作之后，自动跑一次校验。比如它改完代码之后，自动跑一遍 lint 和测试：
{ "hooks": { "PostToolUse": [ { "matcher": "Write|Edit", "hooks": [ { "type": "command", "command": "npm run lint -- --quiet" } ] } ] } }Hooks 的配置放在settings.json里，同样是分全局和项目两级的。项目级 Hooks 对团队最有价值，因为每个成员本地跑 Claude Code 时，都会自动带上这套校验逻辑。
6.4 MCP：接入外部工具链
MCP（Model Context Protocol）是 Claude Code 和外部工具之间的标准通信协议。你可以通过它让 Claude Code 访问 GitHub、数据库、网页搜索、文件系统以及其他内部服务。这相当于把这个 AI 成员接到你们团队真正的工具链上，而不只是操作本地代码。
# 示例：给 Claude Code 接入 GitHub MCP 服务器 claude mcp add github --env GITHUB_TOKEN=your_token -- npx @modelcontextprotocol/server-github # 查看已配置的 MCP 服务器 claude mcp listMCP 的配置可以放在项目级（.mcp.json），提交到仓库后全团队共享。新增一个 MCP 服务器之前，建议先想清楚：这个工具提供的信息是不是 Claude Code 当前无法通过读文件、跑命令获得的？只有答案是“是”，接入 MCP 才有价值。MCP 不是用来堆数量的，每接一个工具都意味着多一个安全面和维护成本。
7. 配置的“运维学”：卸载、升级、权限管控与团队推广
7.1 干净卸载与残留清理
卸载这件事，看起来简单，但残留配置经常会污染下次安装。如果你装的是 npm 包，卸载命令是：
npm uninstall -g @anthropic-ai/claude-code原生脚本安装的版本，在 Linux 上用同一套安装器加 uninstall 参数，或者直接删掉对应的可执行文件。删完之后还要清理配置目录，不然后面重装的时候会读到一堆旧配置：
rm -rf ~/.claude rm -f ~/.claude.jsonVS Code 插件则在扩展面板里直接卸载即可。我建议，如果你从旧版本升级后遇到奇怪行为（比如配置失效、Skills 不加载），先查一下是不是残留配置在捣乱。多数情况下，全新安装反而比在旧配置上修修补补更省时间。
7.2 版本升级策略与行为漂移
Claude Code 的迭代速度非常快，几乎每周都有新版本。升级本身很简单：
- npm/插件安装的：
npm update -g @anthropic-ai/claude-code或直接在 VS Code 扩展面板更新。 - 原生脚本安装的：
claude update。
但升级带来的问题在于“行为漂移”——同一个配置，在新版本里可能表现不一样。因为底层模型的默认行为、工具调用逻辑、权限策略都在变。我的经验是：不要在项目最关键的一周升级，升级前先看一下 changelog；如果发现升级后行为异常，优先检查配置项是否有兼容性变化，其次才是环境问题。
另外，如果你在团队里做推广，建议统一某个子版本一段时间，等新版本稳定后再统一升级。这能大大减少“为什么我这边正常，他那边就不行”的排查成本。
7.3 权限模型的最佳实践：既能干活又不失控
最后聊权限，这是最容易谈崩的话题。很多人的两个极端：一是全程用--dangerously-skip-permissions，图省事，结果它把不该动的目录改了；二是所有操作都弹窗确认，结果几分钟就烦了，最后干脆不用了。
正确的姿势是在配置里维护一套合理的权限规则：
| 配置项 | 推荐值 | 说明 |
|---|---|---|
permissions.defaultMode | acceptEdits | 文件编辑默认接受，减少频繁打断 |
permissions.allowDangerousTasks | false | 危险任务默认拒绝，需要你确认 |
permissions.allowedTools | 按项目需求列出白名单 | 只放必要工具，宁少勿多 |
permissions.denyTools | 明确禁用高危操作 | 比如禁止删除文件、禁止 push 到主干分支 |
我自己的习惯是：先在交互模式下跑几天，观察 Claude Code 日常会用到哪些工具，然后把这些工具加进白名单；凡是没加进白名单的能力，每次使用时它都会问你一次，你再决定要不要放开。经过一两周的“试用期”，权限配置基本就能稳定下来，它既能干活，又不会失控。
7.4 团队推广：让配置成为团队资产，而不是个人技巧
如果你觉得这套配置好用，想让团队一起用，最关键的一件事是：把配置变成仓库的一部分，而不是存在你个人的~/.claude/目录里。
项目级的.claude/目录是可以提交进 Git 仓库的，里面放团队共享的CLAUDE.md、settings.json、agents/、skills/，甚至.mcp.json。新成员拉下代码的那一刻，就已经继承了整套 AI 团队配置，不需要任何额外步骤。
这是我的一个真实体会：当团队里每个人都各自维护一套自己的提示词和配置时，AI 对每个人说的话可能都不一样，这会造成很大内耗。但当你把配置当成代码来管理——提交、评审、迭代，AI 就会像一支训练有素的团队一样，按同样的标准在每个人面前工作。
8. 一次让你少走弯路的配置自查清单
文章最后，我把这套配置的核心检查点整理成一份清单。不管你是刚接触还是已经用了一段时间，按着它过一遍，基本能确认自己的 Claude Code 是否处于健康状态：
- Node.js 版本达标，Git 全局身份已配置。
- 认证状态正常：
/status显示已登录，模型可选。 - 全局 CLAUDE.md 里有你的通用编码偏好。
- 项目 CLAUDE.md 里有架构说明、常用命令、禁止修改的目录。
- 权限模式不是“全部跳过”，allowedTools 和 denyTools 有明确配置。
- 项目级的
.claude/目录已纳入版本控制，团队成员可共享。 - 至少配了一个与项目相关的 Skill 或子 Agent，实测能正常工作。
- 升级流程和更新命令已知，且不会在项目关键期盲目升级。
这套清单是我从实际项目中一点点整理出来的。每次配置一台新机器、接一个新项目，我都按这个顺序走一遍，基本上能在半小时内把 Claude Code 从“能跑”调到“好用”。最后再分享一个我在操作中的体会：配置 Claude Code 的收益不是一次性的，而是滚雪球式的。你每多写一条规则、多沉淀一个 Skill、多校准一次权限配置，它之后的每一次任务都会更贴合你的项目，这种累积效应时间越久越明显。
