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

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

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 很聪明，壳是你要配的东西。

配置放在哪里

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

作用域	位置	影响	是否共享
受管策略	操作系统级别的策略目录	机器上所有用户	IT 部署
用户	`~/.claude/`	你自己所有项目	否
项目	仓库根的 `.claude/` + `CLAUDE.md`	仓库里所有协作者	是（提交进 git）
本地	`.claude/settings.local.json`	你在这个仓库	否（在 `.gitignore` 里）

后面讲到的每一样东西都落在这个阶梯的某一层。规则对所有项目成立 → 用户层；约定只对这个仓库成立 → 项目层；和你本机相关的差异（某个工具的本地路径、私人 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 文件时才进入上下文，其它时候不占位置。

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

文件	管什么
`coding-style.md`	单一职责、函数不超过 50 行、注释写"为什么"
`git-workflow.md`	祈使句 commit、feature 分支、提交前跑 linter
`security.md`	不提交密钥、参数化 SQL、只走 HTTPS
`testing.md`	正常路径 + 边界 + 错误路径，各语言各自的测试框架
`rust.md`	`anyhow` / `thiserror`、禁用 `unwrap()`、`Service<R: Repository>` 模式
`python-django.md`	Django 5 + DRF、`mssql-django`、`managed = False`、用 `uv` 不用 pip

这样做换来两个好处：

规则扛得住压缩。 Claude 在会话过程中学到的东西，被压缩时可能丢；项目根的 CLAUDE.md 和 .claude/rules/ 文件会在压缩后从磁盘重新注入。
它们可以 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 不用问就能选对：

任务	插件
规划功能	`/feature-dev` 或 Plan 模式
审查代码 / PR	`/code-review`
简化代码	`/simplify`
Git 提交	`/commit-commands:commit`
提交 + 推送 + PR	`/commit-commands:commit-push-pr`
Rust 诊断	`rust-analyzer-lsp`
浏览器测试	`playwright`

平台 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 打开这个目录。

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

约定格式。 每个记忆文件带 YAML frontmatter（name、description、type），MEMORY.md 这张索引就能一眼扫，以后的 Claude 也知道每个文件是干嘛的。
四种分类。 user（身份、偏好）、feedback（纠正）、project（架构决策）、reference（外部系统指引）。纯粹是写在全局 CLAUDE.md 里的一个约定，但能避免目录变成一堆散文件。
明确授权它写。 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 合并：

测试 —— 跑测试，失败自动修，最多 2 次。
提交 —— 暂存、从 diff 生成 conventional commit 消息。
PR —— 建分支、推送、开 PR（带摘要和测试计划）。
CI —— 每 30 秒轮询 gh pr checks，10 分钟超时；失败就读日志、修、推，最多重试 2 次。
合并 —— 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。

日常怎么用

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

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

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

从零开始，先配这几样

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

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

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

参考资料

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

Settings —— 四层作用域和 settings.json 每一个字段的权威参考。从零搭配置时从这里开始。
Memory —— Claude Code 记忆体系的两半都在这里：CLAUDE.md 的加载顺序、.claude/rules/ 的 paths frontmatter、内建自动记忆目录怎么存和怎么在压缩后重新注入。
Hooks —— 完整事件目录（二十多个）、matcher 正则语法、以及 command / http / prompt / agent 几种 handler 的 JSON I/O 约定。想让 hook 真的"做事"而不仅仅是打印提醒的话，必读。
Skills —— frontmatter 字段、$ARGUMENTS 替换、内联 shell 执行块、以及用 context: fork 把技能放到子代理里跑。写任何超出玩具级的东西之前应该先看。

api-design.md