我如何配置 Claude Code 作为日常开发伙伴

Claude Code 是我每天花时间最多的工具 —— 一小时写 Rust，下一小时跳到 Python，再下一小时进 TypeScript 项目。一天几百条消息，横跨四五个仓库。折腾了几个月，围绕它的这套配置已经远不止是代码补全：它会执行规约、跨会话记住上下文，还能代我驱动真实的基础设施。这篇文章从头把它讲一遍。如果你从没打开过 Claude Code，前半部分就是写给你的；如果已经在用了，直接跳到后面的配置章节。

Claude Code 到底是什么

Claude Code 是 Anthropic 的官方 CLI。在终端敲 claude 就会打开一个交互式 Agent，能读写文件、执行 shell、搜网页、调用 MCP server↗︎、把任务分派给专门的子代理 —— 而且始终以你启动时所在的目录为根。

底层还是和 API 一样的 Claude 模型，让它区别于聊天窗口的是模型之外的那一圈东西：工具、权限、Hooks、记忆、插件。模型本身是固定的，你能调的是外面那层壳。

我脑子里的模型是这样的：Claude Code 是一个套在 Agent 外面的壳。 Agent 很聪明，壳是你要配的东西。

配置放在哪里

四层作用域，遇到冲突时下面覆盖上面：

后面讲到的每一样东西都落在这个阶梯的某一层。规则对所有项目成立 → 用户层；约定只对这个仓库成立 → 项目层；和你本机相关的差异（某个工具的本地路径、私人 API key）→ 本地层。受管策略是组织层面推下来、个人覆盖不掉的那一档。

这种分层看似琐碎，但真的重要。用户层规则是你"不用再重复自己"的地方；项目层规则是你告诉 Claude "这个仓库里有哪些非显式约定"的地方，而不用把它塞进每个会话的系统提示里。

全局目录结构

我的用户作用域长这样：

~/.claude/
├── CLAUDE.md              # 全局指令，每次会话自动加载
├── settings.json          # 权限、Hooks、插件、状态栏
├── rules/                 # 按主题拆分的指令文件
├── skills/                # 用 /命令 触发的自定义工作流
├── projects/              # 按项目的自动记忆（Claude 自己维护）
│   └── <project>/memory/
│       ├── MEMORY.md
│       └── ...
├── statusline-command.sh  # 状态栏脚本
├── update-pricing.sh      # 每日拉 Anthropic 定价
└── cache/
    └── model-pricing.env

后面几节按实际搭建顺序依次展开。

CLAUDE.md —— 系统指令

这是 Claude 每次会话开头都会读的文件，相当于常驻 briefing：你是谁、在做什么、要遵守哪些约定。

可以在 ~/.claude/CLAUDE.md（到处生效）放一份，在每个仓库的 ./CLAUDE.md 或 ./.claude/CLAUDE.md（只在本仓库生效）再放一份，还可以在项目里放一份不进 git 的 ./CLAUDE.local.md。所有找到的文件会直接拼接进上下文，不会互相覆盖。新项目第一次用时，可以用 /init 让 Claude 扫描代码、生成一份起点。

我的全局版本写得很短，是索引而不是手册：

• 身份 —— 全栈开发，Rust / C# / .NET / Python / TypeScript。
• 环境 —— macOS 宿主机 + Parallels 里的 Windows 虚拟机，用来跑 .NET Framework 4.8 项目。
• 行为 —— 先读代码再改、不确定就问、匹配现有风格、永远不对 main 做 force-push。
• 规则索引 —— 每个领域指向 rules/ 下对应的文件。

之所以写短，是因为一大坨文字的系统提示容易被忽略 —— 对模型是这样，对未来想来编辑的自己也是这样。官方文档自己的建议是每份 CLAUDE.md 控制在 200 行以内。索引告诉 Claude 去哪找，实际内容就地贴近被使用的地方。

还可以用 @路径 导入其它文件 —— 引用 README、package.json、或者从家目录里引用一份共享规则文件都很好使。导入是递归的，所以一份项目 CLAUDE.md 可以引用你个人的偏好文件而不用重复写。

项目级 CLAUDE.md 装的是仓库特有的约定 —— 包管理器、内容模型、导入别名、测试命令。我个人网站那份大致是：

• 用 pnpm（不用 npm）。
• 博客是 content/blog/ 下的 MDX 文件。
• 导入用 @/i18n/navigation（不用 next/link）。
• API 响应遵循全局 RFC 9457 规则。

cd 进另一个仓库时，项目级 CLAUDE.md 自动加载，叠在全局那份上面。不用每次重新交代。

规则文件 —— 作用域化的可重载标准

Claude Code 专门给模块化指令留了一个目录：项目层的 .claude/rules/ 和用户层的 ~/.claude/rules/。目录里的每个 .md 文件都会被递归发现，和 CLAUDE.md 一起加载。这是内建功能，不是你要自己拼的。

比"直接往 CLAUDE.md 里加内容"强的一点在这里：规则可以通过 frontmatter 绑定到特定文件。一条 paths: ["src/api/**/*.ts"] 的规则，只在 Claude 真的动 API 文件时才进入上下文，其它时候不占位置。

我用户层的规则集是十个文件，每个管一件事：

这样做换来两个好处：

1. 规则扛得住压缩。 Claude 在会话过程中学到的东西，被压缩时可能丢；项目根的 CLAUDE.md 和 .claude/rules/ 文件会在压缩后从磁盘重新注入。
2. 它们可以 diff。 改一个标准只改一个文件，不用翻四条散落在 shell 历史里的提示。

效果日常就能看到。Claude 会在 Rust 提交前自己跑 cargo clippy，Python 项目默认用 uv，API 错误格式严格走 RFC 9457 —— 我一句不用说。规则写一次，就不用再重复自己。

settings.json —— 权限 / Hooks / 插件 / 状态栏

settings.json 是全局配置的另一半。它决定 Claude 能做什么，以及它做事前后周围发生什么。下面每一节都够单独展开。

权限 —— 纵深防御

权限分成允许列表（自动批准，不弹窗）和拒绝列表（硬性封堵，不可覆盖）。

允许（自动批准）：

• 文件操作：Read、Edit、Write、Glob、Grep
• Shell：Bash，由拒绝列表兜底
• 网络：WebFetch、WebSearch
• Playwright 和 Context7 的所有工具

拒绝（绝对不能跑，哪怕模型觉得该跑）：

• 破坏性：rm -rf /、git push --force、git reset --hard、git clean -f
• 危险：dd、mkfs、shutdown、reboot、chmod 777
• 供应链：npm publish、cargo publish、curl | bash
• 密钥：cat ~/.ssh/*、cat *id_rsa*

拒绝列表是配置里投入产出比最高的一项。模型偶尔会产生幻觉想跑危险命令，这没关系 —— 只要真的跑不起来就行。这东西应该在出事之前就配好，而不是出事之后再补。

想更细的话，权限接受参数形状模式 —— 比如 Bash(gh pr *) 而不是整条 Bash 都放开给 gh。我在"想用某个 CLI 但不完全信任它任意子命令"的场景会用这种写法。

Hooks —— 自动护栏

Hooks 在 Claude 使用工具的前后执行 shell 命令。官方文档列了二十多个事件 —— PreToolUse、PostToolUse、UserPromptSubmit、SessionStart、Stop、PreCompact、PostCompact、SubagentStart、FileChanged 等等。每个事件会通过 stdin 收到一段 JSON，返回结构化输出可以拦截、修改或者只是观察这次调用。

我用了三个。

PreToolUse —— 任何 Bash 调用前提醒一下：

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "echo '⚠️  Confirm branch and remote before pushing'"
      }]
    }]
  }
}

matcher 是工具名、| 分隔的列表，或者正则。PreToolUse 也可以用 {"hookSpecificOutput": {"permissionDecision": "deny"}} 直接拦下一次调用 —— 组织级策略超出静态拒绝列表的部分就靠这个。

PostToolUse —— 每次编辑文件后，按扩展名提醒跑对应的 linter。参数走 stdin，用 jq 取文件路径：

FILE=$(jq -r '.tool_input.file_path // empty')
case "$FILE" in
  *.rs) echo "Reminder: run cargo clippy" ;;
  *.cs) echo "Reminder: run dotnet build" ;;
  *.py) echo "Reminder: run ruff check && ruff format" ;;
esac

两个都不阻塞调用，就是拍一下肩膀。但它们能拦住不少问题，因为每次都会触发，不依赖 Claude 自己记得问。

SessionStart hook 给我一次机会，在会话第一条消息里塞进自定义上下文 —— git 状态、分支陈旧程度、某个在进行中的实验提醒。

插件和 marketplace

插件把 skill、agent、hook、MCP server、slash 命令打包成一个可安装的整体。Claude Code 自带官方 marketplace（claude-plugins-official），第三方 marketplace 可以从 GitHub 仓库、Git URL 或本地路径加进来。

装一个插件就一行：

/plugin install github@claude-plugins-official
/plugin install supabase@claude-plugins-official
/plugin install vercel@claude-plugins-official

插件的 skill 会按插件名加命名空间（/github:create-pr），所以两个插件可以有同名 skill 而不冲突。

我装了十来个。官方的：

• commit-commands —— /commit、/commit-push-pr
• github —— issue、PR、release，基于 GitHub MCP
• vercel —— 部署、可观测性、Next.js 和 AI SDK 指导
• supabase —— 项目检视和 SQL
• code-review —— 按置信度过滤的 PR 审查
• rust-analyzer-lsp、typescript-lsp —— 基于 LSP 的实时诊断

第三方：

• context7↗︎ —— 拉实时库文档，填训练数据过时的坑
• interface-design↗︎ —— 设计系统审计
• ecc↗︎ —— 一个很大的社区合集
• playwright —— 浏览器自动化

加第三方 marketplace 通常通过 /plugin marketplace add，也可以写到 settings.json 里 —— 这样队友信任这个仓库后会被提示安装：

{
  "extraKnownMarketplaces": {
    "interface-design": {
      "source": {
        "source": "github",
        "repo": "Dammyjay93/interface-design"
      }
    }
  }
}

我在 rules/agents.md 里放了一张插件—任务映射表，让 Claude 不用问就能选对：

平台 CLI

刚才插件列表里有几个（github、vercel、supabase、context7、playwright）本质上就是包了一层的 MCP server，去 API 拿结构化的数据回来，用来读状态很合适。但真要动手做事 —— 发部署、跑迁移、出 release —— 我更习惯让 Claude 直接通过 Bash 调平台自己的 CLI。

常用的几个：

• gh —— 建 PR、轮询 CI、合并。/ship 说白了就是一串 gh 命令串起来。
• Supabase CLI —— db diff、migration、edge function 部署。Supabase MCP 查状态，CLI 负责改动。
• Vercel CLI —— vercel deploy、env pull、日志 tail。插件告诉 Claude 现在什么情况，CLI 让它能动手。
• AWS CLI —— 列桶、tail 日志、看 EC2。IAM 继续兜底，能做什么由它管。
• gcloud / kubectl / docker —— 进各自的世界都一样。

不用再套一层，反正走的是 Bash，前面"权限"一节的拒绝列表已经拦住 --force 这类危险参数，PostToolUse hook 也会在改动前提醒一下。想更细一点，就用 Bash(gh pr *) 这种方式放开特定子命令，不把 gh 整个开出去。

慢慢磨出来的分工：MCP 读、CLI 写、插件负责两样都要用到的流程。这条写进规则之后，Claude 就不再纠结用哪个工具了。

状态栏 —— 实时仪表盘

我最喜欢的自定义。终端底部一行，该看的都在：

[Opus 4.6] misoto22-site | main | 45k 12k | 32% (57k/200k) | $0.45 | 12m30s | 3f +42 -8

从左到右：模型、项目目录、Git 分支、输入 / 输出 token、上下文使用率（带颜色：50% 以下绿、50–75% 黄、75% 以上红）、会话费用、会话时长、Git diff 统计。

费用来自本地缓存的 Anthropic 定价，一个小脚本每天抓一次公开定价页，把每个模型的单价写到 ~/.claude/cache/：

if [ ! -f "$PRICING_CACHE" ] || \
   [ "$(( $(date +%s) - $(stat -f %m "$PRICING_CACHE") ))" -gt 86400 ]; then
    bash "$PRICING_SCRIPT" &>/dev/null &
fi

不需要 API key。我盯得最多的其实是那根变颜色的上下文条 —— 一旦变黄就该在合适的地方 /compact 了，不等它爆。

自动记忆 —— 跨会话学习

规则和 CLAUDE.md 是静态的 —— 你写，Claude 读。自动记忆是动态的，而且从 Claude Code v2.1.59 起它就是内建功能了。Claude 会在会话过程中自己记笔记 —— 它搞清楚的构建命令、你做过的纠正、它学到的架构模式 —— 存在 ~/.claude/projects/<project>/memory/ 下，全是纯 markdown 文件。

目录里有一份 MEMORY.md 做入口，外加若干 Claude 按需要创建的主题文件：

~/.claude/projects/<project>/memory/
├── MEMORY.md           # 索引，每次会话加载
├── user-profile.md     # 角色、偏好、技术水平
├── feedback.md         # 纠正和确认有效的做法
├── architecture.md     # 值得记住的决策
└── references.md       # 外部系统指引

会话开始时，MEMORY.md 的前 200 行（或 25 KB，先到者为准）自动加载进上下文。其它文件按需读，Claude 觉得需要再去取。整套东西都是纯 markdown —— 可以直接读、改、删，或者在会话里用 /memory 打开这个目录。

我在内建行为之上加了几样：

1. 约定格式。 每个记忆文件带 YAML frontmatter（name、description、type），MEMORY.md 这张索引就能一眼扫，以后的 Claude 也知道每个文件是干嘛的。
2. 四种分类。 user（身份、偏好）、feedback（纠正）、project（架构决策）、reference（外部系统指引）。纯粹是写在全局 CLAUDE.md 里的一个约定，但能避免目录变成一堆散文件。
3. 明确授权它写。 CLAUDE.md 里写一句"遇到值得保留的信息就写进自动记忆" —— 默认行为偏保守。

实际效果是：Claude 已经知道我是中文母语、喜欢简短回复、Efision 用 5 层 Clean Architecture 和 Service<R> 泛型、在 pnpm 项目里跑 npm 是我纠正过的错。这些细节会积累，几个月下来慢慢改变它处理任务的方式。

让记忆真正有用的那点自律：别想着一次性全写好。让它从真实的纠正中长出来。因为模型实际犯过错而写的记忆是有分量的；提前脑补写进去的基本是噪音。

自定义技能 —— 可复用的工作流

技能是 Claude Code 里"可复用工作流"的基本单位。一个技能就是 ~/.claude/skills/（或项目里 .claude/skills/）下的一个目录，里面有 SKILL.md 和任意辅助文件。frontmatter 告诉 Claude 什么时候用它，markdown 正文告诉它怎么做。

一个最小例子：

---
name: deploy
description: Deploy the application to production
disable-model-invocation: true
allowed-tools: Bash(gh *) Bash(vercel *)
---
 
Deploy $ARGUMENTS to production:
 
1. Run the test suite
2. Build the application
3. Push to the deployment target
4. Verify the deployment succeeded

我常用的几个 frontmatter 字段：

• disable-model-invocation: true —— "只有用户能调"。给有副作用的工作流用，防止 Claude 自己觉得代码写好了就触发一次部署。
• allowed-tools —— 技能激活时无需再逐次问权限就能用的工具。
• context: fork 加上 agent: Explore —— 在子代理的独立上下文里跑，适合那种不想污染主会话的研究型任务。

用得最多的是 /ship。一条命令，从工作区到 PR 合并：

1. 测试 —— 跑测试，失败自动修，最多 2 次。
2. 提交 —— 暂存、从 diff 生成 conventional commit 消息。
3. PR —— 建分支、推送、开 PR（带摘要和测试计划）。
4. CI —— 每 30 秒轮询 gh pr checks，10 分钟超时；失败就读日志、修、推，最多重试 2 次。
5. 合并 —— squash merge，删分支，报告 PR URL。

没有代码，全是 markdown。Claude 按步骤走，出问题就停下来问。一条 /ship 顶过去 5–10 条手动命令。

还有一个 deep-research 技能 —— 八步把模糊问题变成结构化报告，信源按权威度分级，中间产物写到 ~/Downloads/research/<topic>/。技能版的实验室笔记本。

插件里的技能用带命名空间的形式调：/interface-design:audit、/commit-commands:commit-push-pr。~/.claude/skills/ 下你自己的技能就用裸名：/ship、/deep-research。

日常怎么用

上面这些配好之后，一天大致是这样：

1. 在项目里打开 Claude Code。状态栏马上显示模型、分支、费用、上下文。
2. 全局 CLAUDE.md、项目 CLAUDE.md、规则、自动记忆、插件技能全部自动加载。
3. 我说要做什么。Claude 先读相关代码（规则里写了的），不清楚就问，然后动手。
4. 每次编辑 Hooks 都会提醒跑 linter，push 前再确认一次分支。
5. 上下文条变黄，在合适的地方 /compact。根部的规则和 CLAUDE.md 会从磁盘重新注入。
6. 大功能走 Plan 模式，或者开子代理并行跑。
7. 值得带进下一次会话的，写进自动记忆。

整个过程不太像在"操控一个 AI"，更像是在和一个已经读过代码、了解我偏好、对用什么工具有自己主见的同事结对。

从零开始，先配这几样

从一张白纸起步，按投入产出比排序：

1. 先写拒绝列表。 把 rm -rf、--force、publish、curl | bash 封掉。在你需要封掉它们之前就封。
2. 写全局 CLAUDE.md。 保持短 —— 200 行以内。身份、工作方式、几条行为规则。
3. 把约定外置到 .claude/rules/。 任何你已经在会话里打了第二遍的东西，都值得写成规则文件。用 paths frontmatter 把只适用于某部分目录的规则限定好。
4. 加一个 PostToolUse linter 提醒。 一行配置，能拦住不少事。
5. 自定义状态栏。 一旦能实时看到费用和上下文，你的工作方式会变 —— 会更早 /compact，会更早发现跑偏的会话。
6. 装上你基础设施实际在用的那几个官方插件。 一条 /plugin install github@claude-plugins-official 一周就把投入赚回来了。
7. 让自动记忆自己长出来。 别提前填满。Claude 犯错你纠正，纠正就成了记忆。
8. 分层配置。 全局管通用标准，项目管本地约定，local 管机器差异。

这套配置大半是从真实的坑里长出来的 —— 一次不该发生的 force-push、在 pnpm 项目里跑了 npm、一场写到一半上下文就爆的会话。规则文件里的每一条，都是因为我曾经需要它。

参考资料

下面每个链接都是写这篇时实际翻过的页面。一句话注释说的是"点进去你真正能拿到什么"，不是页面标题的复述。

1. Settings↗︎ —— 四层作用域和 settings.json 每一个字段的权威参考。从零搭配置时从这里开始。
2. Memory↗︎ —— Claude Code 记忆体系的两半都在这里：CLAUDE.md 的加载顺序、.claude/rules/ 的 paths frontmatter、内建自动记忆目录怎么存和怎么在压缩后重新注入。
3. Hooks↗︎ —— 完整事件目录（二十多个）、matcher 正则语法、以及 command / http / prompt / agent 几种 handler 的 JSON I/O 约定。想让 hook 真的"做事"而不仅仅是打印提醒的话，必读。
4. Skills↗︎ —— frontmatter 字段、$ARGUMENTS 替换、内联 shell 执行块、以及用 context: fork 把技能放到子代理里跑。写任何超出玩具级 /command 的东西之前应该先看。
5. Plugins↗︎ 和 Plugin marketplaces↗︎ —— 插件结构、manifest schema，以及 /plugin install <name>@<marketplace> 的完整流程。第二篇才真正讲清楚 extraKnownMarketplaces 怎么用。
6. Subagents↗︎ 和 MCP↗︎ —— 当你开始把 Claude Code 当编排器而不是单个 agent 来用时要读的两篇：子代理委派、预加载技能、以及通过 Model Context Protocol 接外部工具。