用过一阵 Claude Code 之后，你大概会发现一件怪事：这玩意儿很聪明，但每次都像第一次见你。
昨天纠正过它”用 pnpm 别用 npm”，今天它还是给你敲 npm install。前天说过”删文件先问我”，今天照样一顿 rm -rf。

这不是它蠢——是你没告诉它。

这篇文章讲怎么让 Claude Code 真正记住你、贴合你，从最简单的一行配置，到能改变工作流的自动化 hook。

为什么默认的 Claude 不够用

先讲个我自己的经历。

刚开始用 Claude Code 的时候，我一度觉得它”什么都会但什么都不精”。写 Python 它爱加一堆废话注释，写 Bash 它老忘了我在 Windows 上，让我在 Slack 里回消息它给我一段商务邮件模板。

后来我才明白，问题不在 Claude，在我。

它默认对所有人是一套通用模板——一个刚工作两三年的、英文母语的、Linux 用户的、混合各种技术栈的、比较正式的助手。这个模板对任何一个具体的人来说都不完全合适。

想让它变”合适”，本质是一件事：把它每次都要从零猜的东西，变成它一开始就知道的事实。

具体三条路径，由浅入深：

三个都不难。往下看。

第一层：写好 CLAUDE.md（最重要，占 80% 效果）

CLAUDE.md 是 Claude Code 每次启动会话时自动加载的说明书。你在里面写什么，它就知道什么。

两种位置：

• 全局 CLAUDE.md：~/.claude/CLAUDE.md（Windows 上是 C:\Users\你的用户名\.claude\CLAUDE.md）——所有项目共享
• 项目级 CLAUDE.md：项目根目录下的 CLAUDE.md——只在这个项目里生效，会追加在全局之后（不会覆盖）

新手常犯的错是把 CLAUDE.md 当成”日记本”或者”AI 咒语”，写一堆玄学。别这样。CLAUDE.md 应该是一份给同事看的入职文档——如果一个新同事今天来跟你结对编程，你会告诉他哪些事？

该写什么

按重要性排：

1. 你是谁

一两句话说清楚身份、水平、母语。

1
2
3

- 使用中文交流为主。
- 我是独立开发者，主要写 Python 和 TypeScript。
- 5 年经验，术语可以直接用，不用解释 git 和 Docker 是什么。

2. 沟通风格

回复用什么语言？要不要先解释再动手？简短还是详细？

1
2
3
4

- 回复语言：中文为主，代码/命令/报错保留英文。
- 风格：先解释思路再动手。有实际影响的操作（写文件、跑脚本、装依赖），
  先用 1–3 句说清楚要做什么、为什么，再动手。纯读取搜索不用铺垫。
- 不要过度道歉，不要重复我说过的话来"确认理解"。

3. 做事约束

这一节最容易被忽略，也最能救命。

明确列出”必须先问我”的清单，越具体越好。

1
2
3
4
5

- 不可逆操作必须先问我：删除文件、git commit / push、发布/上线、
  覆盖已有内容、清空目录。哪怕之前授权过一次，下一次也要再问。
- 不要自动装依赖（npm install、pip install、winget install）。
  要装的时候先说要装什么、为什么。
- 修改配置文件前，先展示内容让我确认。

写”谨慎点”没用。要写”删文件前必须问我”。

4. 环境相关的坑

你的机器有什么特别的地方？

1
2
3
4

- Windows 11，工作目录常在 C:\Users\你的用户名。
- Claude Code 里的 bash 是 Git Bash（POSIX sh），不是 cmd 也不是 PowerShell。
  用 /dev/null 不是 NUL，用正斜杠，用 $VAR 不是 %VAR%。
- 路径里有中文/空格时用引号包起来。

Windows 用户尤其要写这段——Claude 默认按 Linux 假设，会给你一堆 NUL、&&、反斜杠转义之类的东西，跑起来一半错。

5. 分场景规则

如果你的用途混杂（写代码 + 写作 + 脚本 + 查资料），一套规则套不了所有事。分开写：

1
2
3
4
5
6
7
8
9
10
11
12
13

## 写代码时
- 匹配周围代码的风格，不要强行套外来风格。
- 不要主动加不必要的注释——只在逻辑不明显时写。
- 优先修根因，不要加 try/catch 吞错误。

## 写作时
- 用户是中文母语，避免机翻感。
- 除非我说"扩写"，否则不要注水。删掉"综上所述"、"总的来说"这种。
- 保留我原稿的语气，不要擅自"提升文采"。

## 查资料时
- 引用具体来源，不要说"根据某某研究"。
- 时效性强的问题（价格、版本号），先 WebSearch 不要凭记忆答。

6. 讨厌行为清单

正面规则容易被绕过，反面规则更硬。写下你被惹烦过的具体行为：

1
2
3
4
5

## 我最讨厌的行为
- 明明失败了却说"完成了 ✅"。
- 每一步都问"要继续吗"（该问的不问，不该问的一直问）。
- 一次改一堆无关文件，diff 没法审。
- 报错时不看真正的错误，先猜三个可能的原因。

这一节我强烈建议用一周迭代——每次被 Claude 惹到，就把那个具体行为补进来。三四周之后你的 Claude 会明显变得”识相”。

该避免什么

• 别写永远不会更新的信息。比如”今天是 2026-07-10”——明天就过期了。系统本身就知道日期。
• 别写玄学。”请像一个资深工程师一样思考”这种没用。写具体行为。
• 别写代码结构 / git 历史。那些 Claude 自己能查到，写在 CLAUDE.md 里是浪费。
• 别写太长。CLAUDE.md 每次都要加载进上下文，写 3000 字的哲学思考没意义。3–5KB 是舒服的长度。

一个最小起步模板

不知道怎么开始就抄这个，改成你的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# User Memory

## 关于我
- 使用中文交流。
- 主要用途：[写代码 / 写作 / 脚本 / 查资料，删掉不需要的]。
- 平台：[Windows / macOS / Linux]。

## 沟通偏好
- 回复语言：中文为主，代码保留英文。
- 有实际影响的操作前，用 1–3 句说明思路再动手。
- 不要过度道歉，不要重复我说过的话。

## 做事约束
- 不可逆操作先问我：删文件、git commit/push、装依赖、改配置。
- 不要主动装依赖，要装先告诉我装什么。

## 讨厌行为
- 失败了却说完成。
- 每步都问要不要继续。
- 一次改一堆无关文件。

先从这个跑起来，用一两周之后再迭代。不要一开始就想写完美——你还不知道自己会被什么惹烦。

第二层：用好 memory（长期累积的具体事实）

CLAUDE.md 回答”我是谁”，memory 回答”这件具体的事，以后要记住”。

memory 存在 ~/.claude/memory/ 目录下，每条记忆是一个 Markdown 文件，带 frontmatter。索引在 MEMORY.md，Claude 每次会话都会读。

怎么触发

最简单的方式：直接跟 Claude 说 “记住这个” 或者 “这个以后要注意”。它会自动写进 memory。

或者用斜杠命令 /remember。

什么值得存

按 memory 系统本身的分类：

• user：你是谁的补充。角色、专长、口味偏好。

  • 例：“我是产品经理不是工程师，看到代码需要多加解释”

• feedback：你对 Claude 行为的具体反馈。这个最有价值。

  • 例：“我说’跑一下测试’时，指的是 pytest 不是 unittest，因为我的项目用 pytest”
  • 例：“我讨厌你在总结里用 emoji，一个都不要用”

• project：某个项目的隐性知识。

  • 例：“XX 项目的部署命令是 make deploy-prod，不要用 kubectl 直接改”

• reference：外部资源指针。

  • 例：“公司的 API 文档在 confluence.xxx.com/api”

什么不该存

• 代码库里已经有的（README、注释、CLAUDE.md 写过的）
• 只对本次对话有意义的临时信息
• 会变的东西（”当前版本是 v1.2”——下周就错了）

一个好习惯

被 Claude 惹烦第二次的时候，让它记下来。

第一次可以当偶发，第二次就是模式。这时候说一句”以后都别这样，记下来”，它会存到 memory。下一次会话就不会犯了。

第三层：减少权限弹窗

Claude Code 默认会在跑很多命令前弹窗问你”允许吗？”。刚开始这挺好——安全。但一旦你信任了自己的工作流，这些弹窗就变成噪音了。

最快的减噪方式：跑斜杠命令 /fewer-permission-prompts。

它会扫你的历史命令，把常用的只读命令（ls、git status、cat、grep 等）加到 .claude/settings.json 的白名单里。写命令和危险命令仍然会问你——安全性没降。

跑完立刻能感觉到差别。这是投入产出比最高的一步。

第四层：hooks（真正的自动化）

前面三层都是”让 Claude 更懂你”。这一层不一样——是让 Claude 能自动完成你需要的动作。

关键理解：Claude 自己不能”每次做完 X 就自动做 Y”。它没有那个能力——它只是回答你的对话。真正执行”每次自动”的是 Claude Code 这个 harness（宿主程序）。所以想自动化必须配 hook。

如果你只在 memory 里写”每次编辑完 Python 文件自动 format”——不会生效。因为 Claude 读到这句话时，可能已经编辑完文件了，它没办法穿越回过去。

hook 长这样（在 ~/.claude/settings.json 里）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "if [[ \"$CLAUDE_TOOL_INPUT_file_path\" == *.py ]]; then ruff format \"$CLAUDE_TOOL_INPUT_file_path\"; fi"
          }
        ]
      }
    ]
  }
}

看起来复杂？用斜杠命令 /update-config，它会带你交互式地配置。

有用的 hook 场景

• 编辑完 Python 文件自动 ruff format / black
• 编辑完 TypeScript 文件自动 prettier --write
• 编辑完 .ps1 自动跑 PowerShell 语法检查
• Claude 停下来的时候发桌面通知（防止你等半天没意识到它已经好了）
• 每次 commit 前自动跑测试

什么时候别用 hook

• 你还不确定要不要自动化的时候——先手动做几次，模式清楚了再自动化
• 每次都不一样的动作——那本来就不该自动化
• 会影响其他工具正在做的事的动作（比如中途改文件让另一个程序困惑）

第五层：skills 和斜杠命令

Claude Code 内置了一堆”技能包”，输入 / 能看到全部。我用得最多的：

大部分斜杠命令不用记参数——直接敲上去，它会问你要什么。

一个推荐的上手顺序

如果你从零开始，我建议按这个顺序做，每一步产出立竿见影：

第 1 天（15 分钟）：

1. 写全局 CLAUDE.md，用上面那个最小模板。
2. 跑 /fewer-permission-prompts。

第 1 周：
3. 每次被 Claude 惹烦，把具体行为补到 CLAUDE.md 的”讨厌行为”清单。
4. 遇到需要”这个以后要记住”的时候，说”记住这个”。

第 2 周：
5. 有明确重复动作了，配一两个 hook。
6. 给最常用的项目建项目级 CLAUDE.md，把项目特有的命令和约定放进去。

长期：
7. 每一两个月回头看看 memory 和 CLAUDE.md，删掉过时的、合并重复的。

不要一开始就想配完美。 你还不知道自己真正的痛点在哪。让它跑，让它烦你，然后针对性地补——这才是最有效的路径。

常见误区

误区 1：CLAUDE.md 越长越好

不是。它每次都要加载进上下文，写得像本书反而稀释重点。3–5KB、覆盖高频场景就够。

误区 2：把偏好写进 memory 而不是 CLAUDE.md

memory 适合”具体事实”（某个项目的部署命令、某个 API 的怪癖），偏好和身份写 CLAUDE.md 更合适——每次都会加载。memory 是按相关性召回的，不保证每次都读到。

误区 3：期待 Claude 自动做 harness 层的事

“每次做完 X 就自动做 Y”——这类只能靠 hook。memory 里写没用。

误区 4：写玄学咒语

“请深呼吸再回答”、”想象你是一个 10x 工程师”——这些在 API 上有时有点点效果，但在 Claude Code 这种长时间任务型场景里几乎没有意义。具体行为规则 > 人格 prompt。

误区 5：不敢改 settings.json

它就是个 JSON 文件。改坏了删掉重来就行。真怕的话先备份一份。别把它当成什么神秘配置。

尾声

让 Claude 更懂你这件事，没有一劳永逸的方法——你和你的工作习惯会一直变，Claude 会一直更新，配置也就一直要跟着调。

但这件事的投入产出比高得离谱。花两小时把 CLAUDE.md 写好，接下来几个月每天省下的对话摩擦，加起来可能是几十小时。

而且比省时间更重要的是——一个真的懂你的工具，用起来的感觉，跟一个通用工具是两回事。

祝你调教顺利。