Claude Code 常用指令全解析：终端 AI 编程助手高效工作流

最近这两个月我几乎天天泡在终端里跟 claude code 打交道，从最开始只会敲几行自然语言让它改 bug，到现在已经形成了一套相对固定的工作流。如果你也刚开始用 claude code，或者用了几天总觉得“对话归对话、写代码归写代码”，那这篇 claude code 常用指令整理应该能帮你把效率再往上拉一截。

一句话讲清楚它是什么：claude code 是 Anthropic 出的终端 AI 编程助手，装上之后你可以在命令行里直接和 Claude 对话，让它读代码、改代码、跑命令、跑测试，它甚至能跨多个文件完成重构。它不是又一个聊天窗口，而是直接住在你终端里的“结对程序员”。用的时间越久，你越会发现一个规律：决定使用体验好不好的，往往不是模型本身多聪明，而是你会不会用那些斜杠指令把会话控制住。这篇就把我实际用下来最高频、最有价值的指令全拆开讲一遍，配合安装配置、实操示例和踩坑记录，新手照着敲一遍就能上手，老手也能看看自己是不是还有漏掉的好用指令。

1. 先把 claude code 的工作方式搞清楚

1.1 它不是聊天框，是终端里的编程搭档

很多人第一次打开 claude code，下意识会把它当成 ChatGPT 那样的问答工具：问一句答一句，答案复制粘贴到项目里。这么用当然也能用，但完全浪费了它的设计初衷。claude code 运行在你项目的根目录下，它能看到你整个工作区的文件结构，能调用终端命令，能执行测试，能修改文件。换句话说，它拥有“动你项目”的能力，而不只是给你贴代码。

这种设计带来的最大改变是：你不需要把代码复制进对话框，只需要说“帮我看看 test/test_login.py 为什么跑不过”，claude code 会自己打开文件、定位问题、修改代码、再跑一遍测试给你看。整个流程里你只需要做决策，不需要做搬砖。这跟 Cursor 这类编辑器内嵌 AI 有些类似，但 claude code 把场景彻底搬到了终端，对用 vim、用远程服务器、喜欢“纯键盘流”的开发者非常友好。

这也是为什么常用指令这么重要——指令决定了你如何“指挥”这个搭档干活。你直接说自然语言它能听懂，但斜杠指令能让你精准控制它的工作范围、状态、上下文和权限。两者配合，才是完整的使用方法。

1.2 为什么指令比聊天窗口更重要

聊天工具里的对话上下文是无限累积的，但在 claude code 里，你的每轮对话都会被算进模型上下文窗口。项目一大、改动一多，上下文很快会被填满。填满之后模型会表现出“前面说过的事情全忘了”“改了这个文件忘了那个文件”的症状。如果你只会拼命说“我刚才不是让你改了 X 吗”，那是你的问题；如果你知道这时候敲个 /compact 把上下文压缩一下，那就是老手和新手的差距。

另外，claude code 跟 IDE 插件最大的不同，是它默认拥有较高的操作自由度。它可以自动运行命令、安装依赖、修改配置文件。这份自由度是一把双刃剑：用得好了效率惊人，用得不好它会在你不知情的情况下改坏东西。所以主角指令里头，权限类的 /permissions、状态类的 /status 是全职编程者每天都要碰的东西。

1.3 几个核心概念先过一遍

进入指令拆解前，先花 30 秒过一遍它工作区里的几个核心概念，不然后面讲到指令你会一头雾水。

• 项目记忆（CLAUDE.md）：claude code 会把项目根目录下的 CLAUDE.md 当作“项目说明书”，启动时会自动读取。它记录项目结构、代码风格、测试命令、常见坑等。你可以手动写，也可以用 /init 指令让它自动生成。
• 工作区（workspace）：claude code 默认能看到启动时所在目录下的所有文件。你也可以用 /add-dir 把其他目录加入进来，实现多目录协作。
• 会话上下文（context）：指它当前能“记住”的对话和操作记录。这个不是无限大的，需要 /compact 或 /clear 来管理。
• 权限规则（permissions）：claude code 执行操作前会弹出询问，你可以通过 /permissions 查看和配置哪些命令可以放行、哪些必须确认。

理解了这几个概念，后面所有指令都不难记了：它们本质上是给你控制“记忆、视野、权限、行为模式”四个维度的开关。

2. 装好工具，进入终端

2.1 安装与验证

claude code 的安装方式对开发者来说不算陌生，前提是你本机有 Node.js 18 以上的环境。打开终端，执行：

npm install -g @anthropic-ai/claude-code

安装完成后，验证一下是否成功：

claude --version

能看到版本号就说明装好了。如果你平时主力用 VS Code，也可以直接在扩展市场搜“Claude Code for VS Code”安装，这样不用切终端，直接在编辑器底部面板里使用同一个 claude 会话。它的体验和单独开终端几乎完全一致，唯一区别是你能在编辑器侧边实时看到它改动文件的内容，对新手更友好一点。

2.2 配置模型和密钥

装好之后第一次运行，claude code 会引导你登录。最省事的方式是登录你的 Claude 账号，账号权限会直接跟当前终端环境绑定。如果是团队协作或者公司内网环境，一般会用 API 密钥，设置环境变量即可：

export ANTHROPIC_API_KEY="你的密钥"

需要注意：环境变量只是当前终端会话有效，关掉终端再开就要重新设置。如果想长期生效，可以把它写进 shell 的配置文件。比如在 zsh 里：

echo 'export ANTHROPIC_API_KEY="你的密钥"' >> ~/.zshrc source ~/.zshrc

如果你用的是 Windows PowerShell，命令略有不同，建议直接走 VS Code 插件的图形化登录，体验最顺。

2.3 在 VS Code 里跑起来

在 VS Code 里安装好扩展后，按Ctrl+Shift+P打开命令面板，输入Claude Code，选择启动。它会新建一个终端面板，并自动定位到当前打开的工作区目录。这时候你直接输入中文或英文的自然语言就能开始干活了。

这个模式我建议新手优先用。理由很朴素：claude code 在终端里改文件，你如果眼睛不盯着代码，很难察觉它改了什么。但在 VS Code 扩展里，它能高亮显示当前正在编辑的文件和行号，你能实时看到它动手的过程。等习惯它的节奏后，再切换到纯终端也不迟。

2.4 第一次启动该做什么

我第一次启动 claude code 时做的事情其实没什么章法，就是让它“帮我看看这个项目怎么跑”。后来才知道有个更科学的开场姿势——先让它 /init。这个指令会自动扫描项目结构，生成一份 CLAUDE.md，把项目的目录结构、构建命令、测试命令、依赖关系都记下来。从这之后，每次启动 claude code，它都对项目“心里有数”，回答质量会高很多。

所以我的建议是：装好之后别急着提需求，先在项目根目录跑一次 /init，把项目说明书建起来。这一步对项目越大收益越明显。

3. claude code 常用指令逐条拆解

3.1 查看帮助和状态

/help

这是所有指令里最简单的入门动作。它会列出当前版本支持的全部斜杠指令、快捷键说明和常用玩法。我建议高手也偶尔敲一次，因为 claude code 迭代速度极快，隔两个版本就会多出几个新指令，看一遍往往能发现意外惊喜。

/status

这个指令相当于汽车的仪表盘。它显示当前会话的工作目录、使用中的模型、当前模式（普通还是自动批准）、以及 CLAUDE.md 有没有被加载。我一般每天开工第一件事先跑一次 /status，确认模型没被误切、目录没跑偏，再开始让 claude 干活。如果你发现 claude 好像“变笨了”，先敲 /status 看模型是不是被切到轻量版了。

3.2 初始化与目录管理

/init

前面提过，/init 会在项目根目录生成 CLAUDE.md。它的一个容易被忽略的细节：如果项目里已经有 CLAUDE.md，再跑 /init 会提示你是否用新生成的内容覆盖。如果你之前手工改过这个文件，选择前要小心，建议先看一眼旧文件内容再决定。

/add-dir <路径>

单项目开发时不太用得上，但在 monorepo 或者前后端分离的项目里，这个指令能救命。它可以把另一个目录加入当前工作区，让 claude code 能读取和修改那个目录下的文件。比如你在服务端项目里启动 claude code，想让前端同事的代码也参与改动，直接/add-dir ../frontend就行。

对应的反向操作是移除目录，在交互界面里输入/remove-dir或者直接重新启动 claude code，新会话默认只保留启动目录。这里要注意：claude code 的“工作区”只是它能看到的范围，并不代表加入了目录你就可以让它顺手把那个目录删了，删除这类危险操作仍然会受到权限系统管控。

3.3 上下文管理：/clear 与 /compact

先说 /clear：

/clear

它的作用是把当前会话的上下文全部清空，相当于给模型“换个新脑子”。当你开启了一个完全不同方向的任务，或者前面的对话里夹带了太多无关信息，直接 /clear 比继续硬着头皮对话要高效得多。

但 /clear 的代价是：它连之前的项目背景也一并忘了。如果你在同一个项目里只是换了任务，我更推荐 /compact。

/compact

/compact 会先把当前会话里已经完成的工作压缩成一份摘要，然后带着这份摘要开启新一轮上下文。它比 /clear 高级的地方在于：模型的“记忆”被清洗了，但关键决策被保留了下来。比如你俩刚才花了半小时讨论某个接口为什么要这么设计，那这部分结论会在压缩后被保留；而那些具体改了哪个文件的细节会被丢掉。

实操建议：当你感觉 claude code 开始遗忘前面的指令，或者一个任务干了很久、上下文已经拖得很长，就果断 /compact。我自己一般是每完成一个大功能模块就 compact 一次，然后重新确认当前任务清单，这样整个项目过程中它都保持“清醒”。

3.4 代码审查：/review

/review

这是被很多人低估的一条指令。它不直接用你的对话历史做审查，而是对比当前工作区的 git 改动，帮你做一轮代码评审。它会检查改了哪些文件、新增了哪些逻辑，然后给出潜在 bug、边界条件、风格问题等反馈。

我第一次在项目里用它，它抓出了一个我完全没注意到的并发问题：我在一个异步回调里改了共享对象，但它指出这个回调在极端情况下会被调用两次，导致状态覆盖。这种问题靠人肉 review 很难发现，但它把整个调用链捋了一遍就找到了。

优点是省心、覆盖面广；缺点是有时候会“挑刺挑过头”，对一些风格性问题过于较真。遇到这种情况，我一般会在对话里追加一句“只关注会造成实际问题的点，忽略风格建议”，它就会收敛。

3.5 权限和配置管理

/permissions

权限是 claude code 的重灾区。默认情况下，它执行命令前会弹出确认框，比如要运行npm install、要修改某个文件，都会问你“要不要允许”。对新手这是安全兜底，但用久了你就会发现弹窗频率高得让人崩溃。

/permissions 做的事情是让你集中管理授权规则。你可以看到某次操作是否已获得允许，也可以手动添加或移除规则。比如你信任 claude code 在某个目录下运行测试命令，可以给它放行pytest:*，这样以后再跑 pytest 就不会弹窗了。

关联的还有一个隐藏玩法：/config打开配置文件。claude code 的配置文件里可以写 permissions、hooks 等更复杂的内容。我用 /config 改过的最多的就是把一些高频命令加入 allow 列表，同时把rm -rf这类危险命令写进 deny 列表，强制让 claude code 每次执行都确认。

3.6 模型切换与记忆管理

/model

这个指令会列出当前可用的模型让你切换。claude code 通常默认使用最新、最强的模型，但你完全可以按任务拆分：简单补全、格式化、写测试用例时，切到轻量模型能明显降低延迟和成本；涉及复杂重构、跨文件架构设计时，再切回强模型。

实际感受：用轻量模型跑单元测试和修 lint 错误超快，几乎零等待；但让它设计一个模块划分方案，明显不如强模型考虑全面。所以我在一个会话里经常来回切，这是 claude code 比很多 IDE 插件灵活的地方。

/memory

记忆管理指令，用来查看和管理跨会话的长期记忆。claude code 支持把关键信息写进全局记忆文件或项目记忆文件。比如你的项目里有个约定“所有接口返回格式必须包一层 data 字段”，你可以在对话里让它记住，或者直接写进 CLAUDE.md。有了这种记忆，下次开新会话它也能遵循你的约定。

这个能力很实用但要注意别滥用。记忆一多，模型每次启动的读取开销会增加，关键是记忆之间还会互相干扰。我一般只在“这个项目的规矩”和“这个团队的工作流”两个维度上写记忆，其他临时信息尽量靠 /compact 保留。

3.7 任务管理与其他指令

/todos

这是 2.0 版本后我越来越依赖的指令。它可以把当前项目里待办事项以清单形式列出来，并且支持勾选状态同步。用法很有意思：你可以在对话里说“帮我拆解一下这个功能的实现步骤”，claude code 会自动把步骤写到 /todos 清单里，然后每完成一步就勾掉一步。这比让它在对话里持续“纸面跟踪”可靠，因为上下文被压缩也不怕丢。

/agents

多代理模式的切换指令。严格说这是一整套能力，不是单个开关，但日常使用中你确实可以通过 /agents 看到当前有哪些代理在工作。它对多人协作、多模块并行的大型项目价值很大；对个人小项目，暂时可以不用管它。

还有一个值得提的是非交互模式：

claude -p "审查一下当前代码的潜在问题"

-p是 print 模式，适合在脚本里调用 claude code 批量完成审查、生成注释、批处理文件。比如我在 CI 脚本里就让 claude code 跑一轮快速 review，然后把结果写入日志文件。

4. 一套可复用的实操工作流

4.1 新项目开场：先用 /init 建立项目背景

我最近接手一个老旧的后端服务，目录嵌套很深，技术栈混杂。上来直接让 claude code 改需求，它大概率会瞎猜。我选择先跑 /init：

/init

它会花一点时间扫描项目结构，然后生成 CLAUDE.md。生成之后我先看一眼内容，发现它对技术栈的判断基本正确，但漏了我们内部的构建脚本说明。我直接编辑 CLAUDE.md，补上这两行：

- 构建命令: make build - 测试命令: make test

之后再开新会话，claude code 能正确区分构建和测试脚本，不会再把 lint 命令和测试命令混为一谈。这个基础打得越好，后面所有对话的质量越高。

4.2 写代码过程中的指令组合

在实际开发过程中，我最常用的组合是：对话 + /todos + /compact。

比如要实现一个“导出报表并发送邮件”的功能，我先让 claude code 拆分任务，它会把这些放进 /todos。然后我让它开始实现第一项“封装报表导出函数”。这个过程里，如果项目文件很多，我可能会先 /add-dir 把相关模块目录加进来，缩小它的搜索范围，也能减少不必要的上下文消耗。

实现到一半，如果发现它有点卡顿、或者开始忽略我前面的要求，我会先敲 /status 确认上下文没爆，再决定是 /compact 还是 /clear。如果只是同一功能内的小调整，我倾向于 /compact 保留任务背景；如果是完全换个方向，直接 /clear 更干净。

4.3 收尾阶段：审查、压缩、提交

一个功能写完后，我不会急着提交代码。先让它自己过一遍：

/review

看完 review 意见，挑出真正有影响的问题让 claude code 修复，然后再跑一遍完整测试。测试通过后，我会让 claude code 根据 diff 生成提交信息。这里有个小技巧：让它用中文写提交信息会带一点生硬感，我更习惯让它按“type: 描述”的规范来：

claude -p "根据当前 git diff 生成符合 conventional commits 规范的提交信息"

输出结果基本可以直接拿来用。整个流程走下来，我从“一个人闷头写代码”变成了“自己定方向、claude code 干重活、自己 review 兜底”的节奏，单位时间产出提升非常明显。

5. 高频问题和避坑记录

5.1 常见问题速查表

5.2 我在项目里踩过的几个坑

第一个坑：不建 CLAUDE.md 就硬聊。我有个同事用它改 Dockerfile，因为项目里没有 CLAUDE.md，claude code 不知道这是个多阶段构建的镜像，结果一口咬定基础镜像缺依赖，瞎折腾了半小时。后来 /init 建了说明文件，再处理同类问题就顺畅很多。所以，不要省这个初始化动作。

第二个坑：权限给得太宽。有一次为了图省事，我在 /config 里把 noreadonly 模式打开了，想着让它干得痛快。结果 claude code 在一次重构时自动替换了好几处公共工具的引用，虽然它做的改动本身没问题，但我没在改动前逐条确认，代码合进主干后跑了一个隐藏的边界用例才发现行为变了，回滚了一版。从那以后我再也不给全自动权限，而是指定目录和指定命令放行。

第三个坑：对 /compact 的畏难情绪。早期我怕压缩丢上下文，处处不舍得用，结果拖到上下文爆了，claude code 开始胡言乱语，最后不得不 /clear 全丢。后来想通了：该压就压，关键结论提前让它口述一遍放在 CLAUDE.md 或者 /todos 里，压缩之后它能从这些文件里把语境捡回来。这招非常管用。

5.3 关于权限和安全的提醒

claude code 的能力越强，越要管住它的权限边界。我个人的安全红线是：

• 绝不放行rm -rf，不管当时多急。
• pull、push、force push 这类操作一律保持确认弹窗。
• 生产环境的密钥、证书文件路径，写进 CLAUDE.md 的“不可读取”列表。
• 每次会话结束前，花 30 秒看一眼它的改动 diff，确认没有它私自改掉不属于任务范围的文件。

这些规则听起来像老生常谈，但真正做到的人不多。我自己就是从“完全交给它”慢慢调整成“信任但校验”的节奏，踩过坑之后才理解权限控制不是额外的负担，而是保住项目安全的底线。

6. 最后分享两个我一直在用的小技巧

第一个技巧：在 /clear 之前，先让它把当前进度写进 CLAUDE.md 或者 /todos。比如你说“把目前已经完成的部分和未完成的部分整理一下，写进 /todos”，然后再 /clear。这样清空上下文不会丢进度，后续新会话一打开就能接上。

第二个技巧：别把所有脏活累活都丢给对话。凡是重复性高、模式固定的工作，比如“给所有视图函数加上异常捕获”，用 claude code 非交互模式写一段脚本去处理效率更高，还能保证改动一致性。方法很简单，把需求写清楚后用claude -p "给 src/api 下所有视图函数加统一异常捕获，注意保留原有 docstring"，让它批量改完，你再逐个 diff 确认即可。

从我个人的使用体感来说，claude code 的常用指令并不复杂，核心就那么二三十个，真正高频的也就前面列出的这些。难的不是记指令，而是养成“用指令控制会话”的习惯。项目开始前记得 /init，对话变得迟钝就 /compact，写完功能随手 /review，权限要定期 /permissions 复查，状态不对先 /status。把这几个动作内化成肌肉记忆，你的 claude code 使用体验会拉开别人一大截。