Claude Code 常用指令实战：上下文管理与效率提升指南

1. 为什么“指令”才是 Claude Code 真正的效率杠杆

用 Claude Code 的人分两种：一种把它当聊天窗口，问一句答一句；另一种把它当一台可编程的终端搭档，用指令把重复劳动压成一行。半年下来，两者的产出差距不是百分之几十，而是几倍。原因很简单——Claude Code 的交互面其实有三层：自然语言对话、斜杠指令（Slash Commands）、以及 CLI 层面的启动参数与管道组合。大多数人只用了第一层，而真正每天泡在里面的人，重心在第二、第三层。

这篇内容就是围绕“常用指令”这件事展开的。我会把日常高频用到的指令按使用场景拆开讲：会话与上下文管理、文件与代码操作、Git 与提交、权限与安全、模型与成本控制、以及自定义指令的扩展。每一条我都会说清楚它解决什么问题、什么时候该用、以及我踩过的坑。目标很直接：让你看完之后，能把这套东西直接搬进自己的日常工作流，而不是停留在“知道有这么个命令”。

适合谁看？如果你已经在终端里跑 Claude Code，但总觉得自己在用蛮力；如果你刚装好还在摸索斜杠指令有哪些；如果你团队里想统一一套 CLI 使用规范——这篇都够用。基础部分我会补，进阶部分我会给参数和组合方式，尽量做到新手能抄、老手能挑。

先说一个底层认知：Claude Code 的指令设计哲学是“上下文即成本”。你喂进去的每一个文件、每一段历史、每一次工具调用，都会占用上下文窗口，也都会影响响应速度和费用。所以高频指令里，很大一部分本质是在做“上下文的增删改查”。理解了这一点，你就能明白为什么有些指令看起来只是小功能，实际却是每天必用的。

2. 会话与上下文管理：把窗口当成稀缺资源

2.1 启动阶段的指令选择

很多人安装完就直接敲claude回车，其实启动那一刻就有讲究。Claude Code 的 CLI 支持在启动时指定工作目录、模型、以及是否加载项目级配置。我习惯的做法是：进入项目根目录再启动，而不是在 home 目录启动后手动 cd。原因是 Claude Code 会以启动目录为基准去扫描项目结构、读取CLAUDE.md之类的上下文文件。你在错误目录启动，它扫到的就是一堆无关文件，白白吃掉上下文。

启动时常用的几个参数，我列一下实际会用的：

• claude：最基础的交互式启动，进入 REPL 会话。
• claude "你的任务描述"：带初始 prompt 启动，适合一次性任务，省去进入后再打一遍。
• claude -p "任务"：非交互模式（print 模式），执行完直接输出结果退出，适合脚本和管道。
• claude --model <模型名>：指定本次会话使用的模型，做成本控制时很有用。
• claude --continue：继续上一次会话，不用重新交代背景。
• claude --resume：从历史会话列表里挑一个恢复。

这里重点说-p和--continue。-p是自动化的入口，你可以把它塞进 shell 脚本、Makefile、CI 流程里。比如批量给一批文件生成注释、批量做代码审查摘要，用-p配合管道比交互式快得多。而--continue解决的是“昨天聊到一半今天接着聊”的问题，尤其是排查一个跨天的问题时，上下文不用重建。

注意：--continue恢复的是最近一次会话，如果你中间开了别的会话，恢复的可能不是你想要的。养成习惯：重要排查会话结束时记一下会话 ID，用--resume精确恢复。

2.2 会话内的上下文指令

进入会话后，斜杠指令是主战场。最该先记住的是这几个：

• /help：列出当前可用的所有斜杠指令。版本更新后指令会变，遇到不认识的先敲这个。
• /clear：清空当前会话上下文，相当于开新对话但保留会话。任务切换时必用。
• /compact：压缩上下文，把历史对话总结成摘要，释放窗口空间但保留关键信息。
• /context：查看当前上下文占用情况，哪些文件、多少 token，一目了然。
• /cost：查看本次会话的 token 消耗和费用估算。

/compact和/clear的区别很多人搞混。/clear是彻底清空，之前聊的全没了，适合完全无关的新任务。/compact是“压缩但保留”，它会用模型把前面的对话总结成一段精简摘要，适合长任务中途窗口快满了但你还想接着做。我的经验是：一个任务如果预计要跨很多轮，中途用/compact比硬撑到爆窗口再/clear要稳，因为后者会让你丢失已经建立的共识。

/context这个指令我强烈建议养成定期敲的习惯。它会告诉你当前上下文里都有什么，很多时候你会发现某个大文件被自动加载进来了，占了几万 token，而你根本不需要它。这时候就可以用/remove之类的指令把它踢出去。上下文干净，响应质量和速度都会明显改善。

2.3 上下文增删的实操技巧

除了斜杠指令，还有一类操作是通过自然语言触发的，比如“把 src/utils 目录下的文件加入上下文”“忽略 node_modules”。但更可控的方式是用@引用文件。在输入框里打@会触发文件路径补全，选中后该文件内容会被精确加入上下文。这比让模型自己去读要准得多，也省 token。

我常用的一个组合是：先用/context看占用，发现某个测试文件占了大头，然后/clear重来，这次用@只引用真正需要的三个源文件。同样的任务，上下文从 80% 降到 20%，响应快了一截，费用也降了。

还有一个容易被忽略的点：项目根目录的CLAUDE.md文件会在每次会话启动时自动加载。这个文件是放项目约定、编码规范、常用命令的地方。写得好，相当于每次会话都自带一份“项目说明书”，省去反复交代。但要注意别把它写太长，否则每次启动都吃一笔固定上下文。我的做法是控制在 100 行以内，只放真正每次都需要的信息。

3. 文件与代码操作：让模型精准动刀

3.1 读取与搜索类指令

Claude Code 内置了文件读取和搜索能力，但用指令引导它比让它自由发挥更高效。常用的自然语言触发方式包括“读取 xxx 文件”“在项目里搜索 xxx”“找出所有引用了 xxx 的地方”。不过更精准的是配合 CLI 工具，比如让它调用grep、rg（ripgrep）、find。

我实测下来，明确告诉它用rg比让它自己选工具要快。比如：“用 rg 搜索所有调用parseConfig的地方，列出文件路径和行号”。这样它不会去遍历整个目录树，直接走 ripgrep，秒出结果。如果你的环境里没装rg，先装一个，这是提升搜索效率性价比最高的一步。

读取文件时有个技巧：大文件不要整个读。你可以说“读取 config.py 的前 50 行”或者“读取这个函数的定义部分”。模型按需读取，上下文就不会被一个几千行的文件撑爆。我见过有人让 Claude 读一个 5000 行的日志文件，结果上下文直接满了，后面啥也干不了。

3.2 编辑与重构类指令

编辑是 Claude Code 的核心能力，但也是最容易出问题的地方。高频指令包括“修改 xxx 函数”“重构这个类”“给这个文件加上类型注解”。这里的关键是限定范围。你给的指令越具体，它改错地方的概率越低。

我的习惯是三步走：先让它读，再让它说方案，最后让它改。比如：“先读 src/parser.py，然后告诉我你打算怎么重构 parse 函数，先别改。”等它说完方案，确认没问题，再说“按你说的改”。这样多一轮交互，但避免了它直接动手改出一堆你不想要的东西。

还有一个指令模式很好用：“只修改 xxx 函数，不要动其他任何代码。”这句话能有效防止它顺手“优化”别的地方。Claude Code 有时候会自作主张，加个类型注解、改个命名风格，如果你不想要这些，就明确说“最小改动”。

回滚也是个必须掌握的技能。如果它改坏了，直接说“撤销上一次修改”或者用 Git 恢复。所以我在让 Claude 改代码前，一定确保工作区是干净的，或者先 commit 一次。这是血泪教训——有一次它改了一个文件，我没注意，后面又改了几个，想回滚发现混在一起了。

3.3 批量操作的指令写法

批量操作是 CLI 模式的主场。比如给一个目录下所有 Python 文件加文件头注释，交互式一个个改太慢，用-p模式配合 shell 循环：

for f in src/*.py; do claude -p "给 $f 文件顶部加一段版权注释，不要改其他内容" done

但这样每次启动都有开销。更好的方式是在一个会话里说“遍历 src 目录下所有 .py 文件，给每个文件顶部加版权注释”。它会自己规划批量操作。不过要注意，批量改之前一定先在小范围试，确认输出符合预期再全量跑。

提示：批量操作前先git commit，跑完用git diff检查。如果结果不对，git checkout .一键回滚。这个流程能救你无数次。

4. Git 与提交：把版本控制交给指令

4.1 提交信息的生成

Claude Code 生成 commit message 是我用得最顺的功能之一。常用指令就是“帮我写一个 commit message”或者“根据当前改动生成提交信息”。它会读git diff，然后给出一段符合 Conventional Commits 规范的描述。

但直接用它给的还不够，我一般会加一句“用中文，简洁一点，不超过 50 字”。默认它可能给你一段英文的、比较啰嗦的描述。加上约束后，出来的信息基本可以直接用。

更进阶的用法是让它解释改动：“总结一下当前工作区的改动，分点列出”。这在提交前自查很有用，有时候你自己都忘了改了哪些文件，它一列你就想起来了。

4.2 分支与合并相关指令

“创建一个新分支叫 feature/xxx”“切换到 main 分支”“把当前分支 rebase 到 main 上”——这些都可以用自然语言触发。但涉及 rebase、merge 这种有风险的操作，我建议还是自己敲命令，或者至少让它先说方案再执行。

原因是 Git 的冲突处理很依赖具体上下文，模型有时候会给出一个“看起来对但实际会丢改动”的方案。我的做法是：让 Claude 做只读的 Git 操作（status、log、diff、branch 列表），写操作（commit、push、rebase）自己来，或者让它生成命令我来执行。

有一个指令很好用：“查看最近 10 条提交记录，总结这个项目最近的改动方向”。这在接手一个新项目或者回顾自己一周工作时特别省事。

4.3 代码审查与 diff 分析

“审查当前分支相对于 main 的所有改动，指出潜在问题”——这个指令我每周至少用一次。它会逐文件看 diff，然后给出问题列表。实测下来，它能抓到一些明显的 bug、遗漏的错误处理、以及不一致的命名风格。

但别指望它抓到所有逻辑错误。它的审查更偏“模式识别”，对于业务逻辑的深层问题，还是得靠人。我的用法是把它当第一道筛子，先过一遍，把低级问题清掉，然后自己再看一遍关键逻辑。

审查时加一句“按严重程度排序，只列前 5 个问题”，能让输出更聚焦。否则它可能给你列 20 条，其中一半是吹毛求疵的风格建议。

5. 权限、安全与成本控制：别让便利变成风险

5.1 权限模式的选择

Claude Code 在执行命令和修改文件前，默认会请求确认。这个确认机制是安全底线，但频繁确认也烦。CLI 提供了不同的权限模式，常见的有：

• 默认模式：每次工具调用都确认。
• 自动接受编辑：文件编辑不确认，但命令执行仍确认。
• 完全信任模式：全部自动执行，不再确认。

完全信任模式效率最高，但风险也最大。我的建议是：只在隔离环境或者你完全掌控的项目里用。日常开发用“自动接受编辑”就够了，命令执行还是确认一下，尤其是rm、git push这类。

启动时可以用参数指定权限模式，具体参数名各版本略有差异，敲/help或看启动帮助确认。关键是理解：权限越松，效率越高，但一次误操作的成本也越高。这个权衡自己把握。

5.2 敏感信息的防护

有一条铁律：不要把密钥、token、密码贴进对话。Claude Code 的上下文会经过网络传输，虽然官方有安全措施，但你自己不该主动把敏感信息放进去。

如果代码里有硬编码的密钥，让它帮你改成读环境变量，但别把真实密钥值告诉它。你可以说“把这里的 API key 改成从环境变量读取，变量名叫 XXX_API_KEY”，不需要给它真实值。

.env文件默认应该被忽略。检查一下你的项目里有没有把.env加进上下文，用/context能看到。如果被加载了，赶紧排除掉。

5.3 成本控制的实操

/cost是必用指令。我一般在一个大任务开始前敲一次，结束后再敲一次，看看这个任务花了多少。时间长了你就对“什么任务大概花多少钱”有感觉了。

控制成本的核心还是控制上下文。几个具体做法：

• 用@精确引用文件，而不是让它自己扫。
• 长会话中途/compact，别硬撑。
• 简单任务用便宜模型，复杂任务再切贵的。启动时--model指定。
• 批量任务用-p模式，避免交互式来回的开销。

我做过一个对比：同一个重构任务，上下文管理得好的会话花了不到管理差的会话的三分之一。差距就在那些被无意识加载进来的大文件上。

6. 自定义指令：把重复劳动固化下来

6.1 自定义斜杠指令的创建

Claude Code 支持自定义斜杠指令，这是把个人工作流沉淀下来的关键。创建方式通常是在项目或用户目录下放一个约定格式的 Markdown 文件，文件名就是指令名。比如创建一个/review指令，就放一个review.md，里面写清楚这个指令要做什么。

我常用的自定义指令有几个：

• /review：审查当前 diff，按严重程度列问题。
• /test：为指定文件生成单元测试。
• /doc：为指定函数生成文档注释。
• /explain：用通俗语言解释一段代码的逻辑。

每个指令文件里其实就是一段 prompt 模板。你可以用占位符让它接收参数，比如$ARGUMENTS。这样/review src/parser.py就能把文件路径传进去。

自定义指令的价值在于“一致性”。团队里每个人敲/review，出来的审查标准是一样的。这比每个人自己组织语言要靠谱得多。

6.2 项目级配置的写法

项目根目录的CLAUDE.md是另一个固化点。我一般会写这几块内容：

• 项目简介：一句话说清楚这是什么项目。
• 技术栈：语言、框架、关键依赖。
• 常用命令：怎么跑测试、怎么构建、怎么启动。
• 编码规范：命名、格式、提交信息格式。
• 注意事项：哪些目录不要动、哪些操作要谨慎。

写的时候注意精简。每多一行，每次会话启动就多占一点上下文。我见过有人写了 500 行的CLAUDE.md，结果每次启动先吃掉一大块窗口，得不偿失。控制在 100 行以内，只放真正高频需要的信息。

6.3 指令组合与工作流编排

单个指令是点，组合起来才是线。我日常的一个典型工作流是这样的：

1. claude --continue恢复昨天的排查会话。
2. /context看上下文占用，必要时/compact。
3. 用@引用相关文件，说“继续排查 xxx 问题”。
4. 定位到问题后，说“给出修复方案，先别改”。
5. 确认方案后，说“按方案修改，最小改动”。
6. 改完说“为这个改动生成测试”。
7. 测试通过后说“生成 commit message”。
8. 自己执行git commit。

这套流程跑顺了，一个 bug 从定位到提交可能就十几分钟。关键是把每一步的指令固定下来，形成肌肉记忆，不用每次想“我该怎么说”。

7. 常见问题与排查技巧实录

7.1 指令不生效或行为异常

最常见的问题是“我敲了指令但它没按预期执行”。排查顺序：

• 先/help确认这个指令在当前版本是否存在。版本更新会增删指令。
• 检查是不是拼写问题，斜杠指令对拼写敏感。
• 如果是自定义指令，检查文件路径和格式对不对。
• 看/context，确认相关文件是否真的在上下文里。

还有一种情况是模型“理解偏了”。比如你说“优化这个函数”，它可能理解成“重写整个文件”。这时候把指令拆细：“只优化这个函数的循环部分，其他不动”。指令越具体，偏差越小。

7.2 上下文溢出与响应变慢

上下文快满的时候，响应会明显变慢，甚至开始丢信息。症状是它“忘记”了前面说过的话。这时候/context一看就知道。

解决办法按优先级：先/compact压缩；如果还不行，/clear重来，这次用@精确引用；再不行就拆任务，分多次会话做。别指望在一个爆满的会话里硬撑，越撑越乱。

7.3 修改结果不符合预期

它改错了地方，或者改出了 bug。第一反应应该是回滚，而不是让它“再改改”。因为在一个已经混乱的上下文里继续改，只会越来越乱。

回滚后，重新组织指令：明确范围、给出约束、先要方案再动手。我踩过的坑就是让它连续改了五六轮，结果越改越偏，最后只能全部回滚重来。从那以后我定了规矩：改错一次就回滚，重新说清楚再改。

7.4 常见问题速查表

7.5 几条独家避坑心得

第一，永远在干净的工作区开始。让 Claude 改代码前，先git status确认没有未提交的改动，或者先 commit。这样出问题能一键回滚。

第二，重要操作让它先说方案。涉及重构、删除、批量修改的，先要方案再执行。多花一轮交互，省下的是回滚的时间。

第三，别把CLAUDE.md当垃圾桶。只放高频需要的信息，其他放文档里，需要时用@引用。

第四，定期清理历史会话。会话积累多了，--resume列表会很长，找起来烦。定期清理不用的。

第五，模型选择要务实。简单任务用快模型，复杂推理再用强模型。一直用最强的，费用会很难看。

8. 把指令变成肌肉记忆

用 Claude Code 这半年，我最大的体会是：效率提升不来自“知道更多指令”，而来自“把少数指令用熟”。你不需要记住一百条，只需要把十几条高频的练到不用想就能敲出来，剩下的遇到再查。

我自己的高频清单其实就这些：/context、/compact、/clear、/cost、@引用、--continue、-p模式，加上三四个自定义指令。就这些，覆盖了我日常九成以上的操作。剩下的指令，/help里都有，需要时看一眼就行。

最后分享一个小习惯：我会在CLAUDE.md里维护一个“本项目常用指令”小节，把团队约定的自定义指令和用法写进去。新人进来，看一眼就知道该怎么用，不用口口相传。这个习惯让我们的协作成本降了不少，也让指令真正变成了团队资产，而不是个人技巧。