骑lv上高速一开始用 Claude Code，我的用法跟大多数人差不多：把报错贴给它，让它写个函数，再让它解释一段看不懂的代码。直到有一次我让它做全仓库重构，它不只改了目标文件，还顺手统一了引号风格、调整了缩进，甚至把无关模块里的循环也“优化”了一遍。那一刻我意识到，Claude Code 根本不是一个聊天框，而是一个能自己动手的自动化执行器。想用好它，靠“聊得来”远远不够——你得先搞清楚它内部怎么跑，再针对性地给它设定规则、权限和工具边界。这篇文章就把我总结的原理和 6 个进阶技巧一次说清楚，适合已经用过基础命令、想系统提升效率的开发者。
1. 先搞清楚它的工作链路：任务循环、上下文与权限
1.1 它不是一个“问答程序”，而是一个“执行闭环”
很多人的误区是拿 Claude Code 当更聪明的搜索引擎：问一句，它答一段，然后自己复制执行。但 Claude Code 在工作时其实是在跑一个闭环：接收任务 → 制定计划 → 调用工具（读文件、搜代码、执行命令）→ 观察返回结果 → 调整计划 → 继续调用工具，直到任务完成。
这个链条看起来简单，但它解释了为什么同样的任务，有人用起来顺手，有人用起来失控。你把任务描述得越清楚，它制定的计划就越接近你想要的路径；你给它的工具权限越大，它在“观察结果”之后就越敢动手修正。反过来，如果你不懂这个闭环，只把它当一问一答的工具，那你永远停留在低阶用法——它真正值钱的地方，不是生成代码片段，而是帮你把一整件事办完。
理解这个闭环还有一个实际好处：你能判断任务卡在哪一步。比如它突然停下来不动了，大概率是工具调用返回了异常结果，它在等你决定是继续还是换方案。这时候不盲目说“继续”，而是看一眼它上一步干了什么，再决定下一步授权。
1.2 上下文从哪里来，到哪里去
Claude Code 每次会话启动时，会把几类信息拼进上下文：
- 模型自带的系统提示：定义了它作为编码助手的基本行为。
- 项目规则文件（CLAUDE.md）：如果项目根目录存在这个文件，会自动加载。
- 当前会话里你输入的任务和对话历史。
- 每次工具调用返回的内容，比如读到的文件片段、命令行输出、搜索的命中结果。
这些内容全部挤在同一个上下文窗口里。窗口是有限的，一旦工具返回的东西太多，早期的内容就有被压缩或截断的风险。这也是为什么很多人在长任务里遇到“失忆”：不是模型坏了，而是早期指令被挤出了有效上下文。
所以进阶的第一个认知是：上下文是需要管理的资源。不要把整个大文件直接丢给它读，而是让它先定位、再按需读取关键片段；不要把几十条注意事项都放在对话里说一遍，而是写进规则文件，让它每次开工前自动看到。很多玄学问题，追到根上都是上下文管理的问题。
1.3 权限模型：为什么默认不直接改文件
Claude Code 默认情况下不是“想改就改”，而是在执行敏感操作前征求你的确认。比如修改文件、运行可能改变环境的命令，都会先停下来问一句。这个设计不是为了让操作变麻烦，而是因为工具一旦能自动改文件，失控的代价就很高。
权限模型大致分三层：逐次确认、允许列表、拒绝列表。你可以把高频安全操作放进允许列表免确认，把绝对不想让它碰的命令放进拒绝列表强制拦截。理解这个结构之后，你会意识到一件事：进阶技巧的很大一部分，都是在“执行闭环”的权限环节上做文章——不是限制它，而是用规则保护你和你的仓库。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技巧01与02：从规则文件到会话恢复，稳住上下文
2.1 技巧01：用 CLAUDE.md 给每个仓库注入“项目共识”
CLAUDE.md 是放在项目根目录的规则文件，每次会话启动都会被自动读入上下文。它相当于你用文字给模型做了一次“项目入职培训”，告诉它这个仓库的构建方式、测试命令、代码风格和红线。
我强烈建议在要长期维护的仓库里写这个文件。比如一个 Python 项目的 CLAUDE.md 可以长这样：
markdown复制# 模拟项目X 开发规则
- 语言：Python 3.11 + pytest
- 测试命令：pytest tests/ -q
- 所有公共函数必须有类型标注
- 业务代码禁止直接 print，统一使用 logger
- 改动代码前先运行 git pull --rebase
- 不要修改 tests/ 之外的测试文件来迁就实现
有了这些规则，它后续读代码、提方案时会明显更贴合项目的实际约定。比如没有这条规则时，它可能给你生成 print 调试语句的代码；写上“统一使用 logger”之后，它自己就会绕开 print。
CLAUDE.md 不是越长越好，建议控制在几十行。写得太多，关键信息反而会被稀释。我个人的写法是只放四类内容：项目是怎么构建和测试的、代码风格有什么硬性要求、哪些操作是明令禁止的、以及常见目录的作用。它应该是一份可执行的行为指令，不是项目 README 的复述。
另外，Claude Code 支持多级规则：根目录放基础共识，子目录放专项规则，处理某个子模块时它会更优先参考靠近当前任务的规则。所以我通常在根目录写仓库级约定，在容易出错的子模块目录里补充局部约定，比如“这个目录下的代码禁止访问数据库”。
2.2 技巧02：会话快照与恢复，让长任务不丢上下文
一次复杂任务往往要跑很多轮，中间你可能要停下来吃个饭、处理个紧急 bug，或者只是想换到另一个分支干点别的。如果直接关掉终端，下一次又从头开始，上下文就清零了。Claude Code 提供的会话机制就是为这种场景准备的。
我最常用的两个命令是 claude --continue 和 claude --resume。--continue 直接回到最近一次会话，适合手头只有一条主线时；--resume 可以列出历史会话并选择恢复，适合同时推进多条任务线。
实操时我一般这样做：开始一个较大的重构任务前，先用独立终端开一个专属会话，这个会话只负责重构，不聊别的。如果在任务中间要插别的事，就另开一个会话去处理，不要混在一起。因为混着聊，上下文里会塞入太多无关内容，挤占本来就有限的窗口。
还有个技巧：在长时间任务里，每隔一段时间就用一句话让模型“总结当前进度和剩余步骤”，并把这段总结粘贴进 CLAUDE.md 或任务说明里。这样即使上下文被压缩，核心进度仍然保留在规则文件中，下次恢复会话时不会被“失忆”打乱节奏。
3. 技巧03与04：用命令和 Hook 把重复操作变成自动化流程
3.1 技巧03：自定义斜杠命令，把固定流程固化成一键调用
如果你有一些反复让 Claude Code 做的事情——比如代码审查、补全测试、整理 import、按团队规范格式化——每次都用自然语言重复描述一遍又长又容易漏。Claude Code 支持在 .claude/commands/ 目录下放 Markdown 文件，文件名就是斜杠命令名。
假设我想固化一个代码审查流程，就新建 .claude/commands/review.md：
markdown复制---
description: 对指定文件做代码审查
---
请对 $ARGUMENTS 做一次代码审查，重点检查以下内容：
1. 错误处理是否覆盖了网络异常、参数非法、资源未释放等场景。
2. 是否存在复制粘贴式的重复逻辑。
3. 测试是否覆盖了主流程和边界条件。
4. 命名是否与项目现有风格一致。
逐条给出结论，并给出最小修改建议。
之后在会话里输入 /review src/api.py，它就会按照你写好的流程执行，不需要每次重新组织语言。命令模板里可以用 $ARGUMENTS 引用你输入的具体参数，所以同一个命令可以套用在不同的文件或模块上。
写命令模板时有个心得：模板不是越细越好，而是要让模型有判断空间。比如审查命令里列出重点项，但不规定每一个重点项的具体结论格式，它就能根据文件实际情况做判断。如果全部规定死，反而容易得到千篇一律的敷衍结果。
3.2 技巧04：用 Hook 在关键动作前后自动拦截
自定义斜杠命令是把“人的指令”固化下来，Hook 则是把“程序的判断”插到 Claude Code 的工具调用链路上。它监听事件，比如调用 Bash 之前、修改文件之后、会话停止时，然后执行你自己的脚本。
一个典型场景是安全检查。你可以在 .claude/settings.json 里加一个 PreToolUse 钩子，让它在 Claude Code 即将运行 Bash 命令之前先跑一遍检查脚本：
json复制{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "python scripts/check_bash_command.py"
}
]
}
]
}
}
检查脚本收到 Claude Code 传来的 JSON，包含工具名和输入参数。脚本里可以判断命令是否包含危险模式，比如强制删除、直接往生产环境写东西。如果判断不安全，就返回非零退出码，Claude Code 会因此停止调用该工具。
Hook 的价值在于，它把“人工把关”变成了“程序把关”。否则在高频操作里，你很容易因为确认弹窗太多而麻木，到最后闭着眼点允许。有了自动拦截，至少能挡住最明显的几个坑。我的经验是，Hook 脚本要保持轻量和快速，不要在里面做网络请求或复杂计算，否则每次工具调用都会被拖慢。
4. 技巧05与06：把执行边界收紧，再接入受控的外部能力
4.1 技巧05：白名单式最小权限，给工具上锁
权限配置是进阶和翻车之间的分界线。默认的“逐个确认”在高频操作时很烦，但一次性放行所有操作又太危险。我的方案是：允许列表只放高频且安全的操作，剩下的保留确认；危险操作直接进拒绝列表。
在 .claude/settings.json 里可以这样配：
json复制{
"permissions": {
"allow": [
"Read",
"Edit",
"Bash(git status)",
"Bash(git diff)",
"Bash(pytest tests/)"
],
"deny": [
"Bash(rm -rf *)",
"Bash(npm install)"
]
},
"hooks": {
"PreToolUse": [
{
"matcher": "Edit",
"hooks": [
{
"type": "command",
"command": "python scripts/check_edit_path.py"
}
]
}
]
}
}
注意一个细节：allow 里的 Edit 表示允许所有编辑操作，但结合 PreToolUse 里的路径检查脚本，可以把 Edit 的范围进一步限制到特定目录。如果脚本发现它要改的文件不在允许清单里，就返回非零退出码，阻止这次编辑。
我用下来最舒服的配置是：Read 和安全的 Git 命令可以放行，测试命令放行，但安装依赖、批量删除、push 到远端这类操作全部默认确认或拒绝。这样日常工作效率高，又不会出现“一觉醒来它把配置全改了”的惊吓。
4.2 技巧06：用 MCP 拓展能力边界，而不是让模型“裸奔”跑命令
MCP（Model Context Protocol）是把外部能力以统一接口接入 Claude Code 的方式。接入之后，Claude Code 可以使用你定义的 MCP 工具，比如查询内部文档、读取指定 API 的 schema、检索代码索引。和直接让它跑 Shell 命令相比，MCP 的好处是暴露给它的是一组受控函数，而不是万能终端入口。
举个例子：如果你的服务有内部 API 文档，写一个本地 MCP server 暴露 search_api_docs(module_name) 这个查询工具，然后注册到 Claude Code 上。它要查接口参数时，就会通过这个工具去查，而不是自己去翻目录或者猜路径。注册命令类似：
bash复制claude mcp add api-docs -- python scripts/api_docs_server.py
注册成功之后，Claude Code 会在会话里看到新增的工具，并像使用普通工具一样使用它。我个人会把“查询类”的 MCP 工具当成优先接入对象，比如查文档、查代码索引、查数据库只读视图。这类工具给模型提供了准确信息，又不会让任意命令被直接执行。
写操作也尽量封装成 MCP 工具，但接得谨慎一些：把“查询”和“变更”拆分成不同的工具名，变更类工具单独配置权限。这样它在执行写操作时，仍然走我们的权限确认流程，不会因为是标准命令就绕过检查。
5. 进阶路上我踩过的三个坑：从症状到根因
5.1 案例一：改了半天的任务突然“失忆”
现象是任务进行到一半，Claude Code 开始重复问已经确认过的问题，比如“这个目录的日志组件用的是什么框架”——事实上前面两轮它已经知道了。第一次遇到时我以为模型出 bug 了，后来才明白是上下文被早期的大量文件内容挤爆了。
排查链路是这样的：先看会话里是否插入过大块内容，比如一次性展示了整个文件或者很长的命令输出。如果是，就说明这些内容把早期约定挤出了有效上下文。解决办法有两个：一个是把关键约束写进 CLAUDE.md，让它每次都能重新读到；另一个是调整输入方式，别让它整个读大文件，而是让它先用 grep 定位片段，再读小范围代码。
把这两条都做了之后，“失忆”的概率大幅下降。现在但凡遇到需要跨很多文件的改动，我都会在一开始就把“当前任务目标”和“不允许触碰的文件列表”写进规则文件，而不去赌它能一直记住。
5.2 案例二：一次重构把无关文件全改了一遍
这就是文章开头那个事故。我放了 Edit 权限之后，它把多个文件里不一致的引号和缩进全部统一了。改动本身未必错，但混进了这次重构的 diff 里，后续 review 根本没法看。
根因是权限白名单太宽：我只说了“可以编辑”，没限定“只能编辑这几个文件”。排查时我用 git diff --stat 看到了超出预期的文件列表，才意识到是权限粒度的问题。
现在我的做法是：涉及大批量改动时，先让模型产出“目标文件清单”写入上下文或规则文件，再在 PreToolUse 的 Hook 里做路径校验，凡是不在清单里的文件一律拦截。这相当于给改动加了围栏，效率损失很小，但再也没有出现过“顺手改一堆”的混乱。
5.3 案例三：多文件重构的依赖顺序错乱
做一次涉及多个模块的重构时，Claude Code 按对话顺序逐个改文件：先改了 A，再改 B，但 B 里还在用 A 的旧接口，结果编译直接崩。这件事让我意识到，Claude Code 对“文件间依赖顺序”的感知没有人类那么强，它会顺着对话的推进逐个击破，而不是先画一张依赖图。
解决办法是别让它“边说边改”，而是要求它在开始修改前先输出一份改动计划，明确列出：哪些文件是底层依赖、哪些是上层调用、按什么顺序改才能保持中间状态可运行。我会把这一步直接写进 CLAUDE.md：
markdown复制涉及多文件重构时，必须先列出文件依赖顺序再动手修改。优先修改底层模块，严禁一次性改动超过三个文件而不运行测试。
加了这条之后，它会在动手前主动整理顺序，而不是想到哪改到哪。如果你有更复杂的仓库结构，甚至可以把这一步做成一个自定义斜杠命令，每次重构前先跑一遍计划生成流程。
这三个坑本质上都是同一个问题在三个环节的表现：上下文管理不当、权限控制过粗、执行顺序缺少约束。把它们对应到原理部分的工作链路，就会发现每个坑都有对应的技巧可以防住。
以我目前的习惯，会把六个技巧分成两个阶段逐步落地。第一阶段先做 CLAUDE.md、会话恢复和最小权限，这三项能让日常使用的稳定性和安全性立刻提升；第二阶段再碰斜杠命令、Hook 和 MCP，真正把重复流程自动化。不要一上来全配齐，否则出了问题都不知道是哪个配置在起作用。每加一项配置，就故意让它执行一次高风险操作验证拦截效果，再放心交给它干正事。这样反复打磨几次，你就能找到最适合自己项目的一套组合。