1. 为什么我要把 Claude Code 的指令系统彻底梳理一遍
用 Claude Code 超过三个月之后，我发现自己陷入了一个很尴尬的状态：每天开着终端，敲来敲去就那么七八条指令，剩下的功能全靠"感觉"和临时查文档。直到有一次看同事操作，同一个重构任务，他用三条指令搞定，我折腾了快二十分钟。那一刻我才意识到，Claude Code 真正的效率差距不在模型本身，而在你对指令系统的熟悉程度。
Claude Code 是 Anthropic 推出的命令行 AI 编程工具，它把大模型的代码理解与生成能力直接嵌进了终端工作流。和网页版对话不同，它的核心价值在于能读写你本地的真实项目文件、执行命令、跑测试、管理 Git，而这些能力全部通过指令来触发。指令体系大致分三类：CLI 启动参数（决定会话怎么开）、斜杠指令（会话内的功能开关）、内置工具调用（模型自主或你显式触发的文件与命令操作）。很多人只用了第一类的皮毛，后两类几乎没碰过。
这篇内容适合三类人：刚装好 Claude Code 还在摸索的新手、用了一段时间但指令记不全的中级用户、以及想把它接进团队工作流的老手。我会把日常高频指令按场景拆开讲，每条都说清楚它解决什么问题、什么时候用、有什么坑。文中涉及的具体参数以官方文档和我的实测为准，部分操作细节是基于常见实践的合理补充，你照着试基本不会跑偏。
先说一个我踩过的大坑：别一上来就背指令表。指令是长在场景里的，脱离场景记指令，用的时候照样想不起来。所以我下面的组织方式全部按"你要干什么"来分，而不是按字母顺序罗列。
2. 安装、启动与 CLI 参数：会话怎么开决定了后面顺不顺
2.1 安装路径选择与常见报错处理
Claude Code 的安装方式主要有两种：npm 全局安装和官方安装脚本。我两种都试过，npm 方式在版本管理和卸载上更干净，脚本方式在权限处理上更省心。如果你机器上 Node 环境本来就乱，建议直接用 npm。
# npm 全局安装 npm install -g @anthropic-ai/claude-code # 验证安装 claude --version安装完第一件事不是急着跑，而是确认claude命令在 PATH 里。我遇到过好几次"装完了但终端找不到命令"，八成是 npm 全局 bin 目录没进 PATH。用npm config get prefix看一下路径，再对照你的 shell 配置文件。
卸载也很简单，npm uninstall -g @anthropic-ai/claude-code就行。但要注意，卸载不会删除你的配置文件和会话历史，这些通常放在用户目录下的隐藏文件夹里，想彻底清干净得手动删。
注意：如果你在受限网络环境下遇到"might not be available in your country"这类提示，那是区域可用性问题，不在本文讨论范围，请以官方支持列表为准。
2.2 启动参数：一次配对，长期省事
直接敲claude会进入交互式会话，但真正高效的人几乎都会带参数启动。下面这几个是我每天必用的：
| 参数 | 作用 | 我的使用场景 |
|---|---|---|
claude | 进入交互式会话 | 日常开发主入口 |
claude "任务描述" | 带初始任务启动 | 明确知道要干什么时 |
claude -p "问题" | 单次问答后退出 | 脚本里调用、快速查东西 |
claude -c | 继续上一次会话 | 昨天没干完的活接着干 |
claude -r | 选择历史会话恢复 | 多个项目来回切换 |
-p（print 模式）是我用得最狠的一个。它不进入交互界面，直接输出结果就退出，特别适合塞进 shell 脚本或者和其他命令管道组合。比如你想让它解释一段报错，可以cat error.log | claude -p "解释这个错误并给出修复建议"。
-c和-r的区别很多人搞混：-c是直接续上最近一次会话，-r是弹出列表让你挑。我一般用-c，因为大多数时候就是接着昨天的活干。
2.3 权限模式：别让确认弹窗打断你的心流
新手最烦的一点就是 Claude Code 每动一个文件、跑一条命令都要问你"是否允许"。这是安全设计，但高频操作时确实打断节奏。解决办法是理解权限模式：
- 默认模式：每个敏感操作都确认，最安全
- 接受编辑模式：文件编辑自动通过，命令执行仍需确认
- 计划模式：只读分析，不改任何东西，适合先让它摸清项目
- 跳过确认模式：全部自动执行，风险最高
我的建议是：探索陌生项目时用计划模式，改自己熟悉的项目时用接受编辑模式，跳过确认模式只在完全可控的沙箱里用。很多人问"怎么避开每次确认"，答案不是无脑跳过，而是选对模式。你可以在会话里用斜杠指令随时切换，不用重启。
3. 斜杠指令：会话内的功能总控台
斜杠指令是 Claude Code 交互体验的核心，输入/就会弹出补全列表。下面按功能分组讲，这些都是我实测高频的。
3.1 会话与上下文管理类
/clear是我用得最多的指令，没有之一。它会清空当前会话的上下文，但保留你的项目状态。什么时候用？当你发现模型开始"胡言乱语"、答非所问，或者上下文太长导致响应变慢时，清一下往往立竿见影。我一般完成一个独立任务后就/clear，避免上一个任务的上下文污染下一个。
/compact和/clear不一样。它不删除上下文，而是把历史对话压缩成摘要，保留关键信息的同时释放 token 空间。长任务做到一半上下文快满了，用/compact比/clear更合适，因为不会丢失之前的决策脉络。
/context能让你看到当前上下文占用了多少，这个指令很多人不知道，但它能帮你判断该不该压缩。我习惯在感觉响应变慢时先看一眼。
/resume用于恢复历史会话，和启动参数-r效果类似，但在会话内操作更方便。
3.2 项目与文件操作类
/init是进入新项目后的第一个指令。它会扫描你的代码库，生成一个项目说明文件（通常是 CLAUDE.md），记录项目结构、技术栈、约定规范。这个文件是 Claude Code 理解你项目的"说明书"，生成后每次会话它都会读。我强烈建议每个项目都跑一次/init，然后手动补充它没抓到的约定，比如"我们不用分号""提交信息用中文"这类。
/add-dir用于把额外的目录加入工作范围。默认情况下 Claude Code 只能访问启动目录，如果你的项目是多仓库结构，用这个指令把相关目录都加进来。
/vim切换编辑器的键位模式，习惯 Vim 的人会喜欢。
3.3 模型与行为控制类
/model用来切换底层模型。不同模型在速度和能力上有差异，简单任务用快模型省钱省时间，复杂重构用强模型保质量。我一般日常用默认，遇到硬骨头再切。
/config打开配置面板，可以改主题、改默认行为、管理各种开关。第一次用建议进去逛一圈，把该关的关了。
/permissions管理权限规则。你可以把某些命令加进白名单，比如git status、ls这种只读命令，让它们不再弹确认。这是提升流畅度的关键操作，比直接跳过所有确认安全得多。
/cost查看当前会话的 token 消耗和费用。团队协作或者预算敏感的场景，这个指令要常看。
3.4 输出与交互类
/help列出所有可用指令，忘了什么就敲它。
/status显示当前会话状态，包括模型、目录、权限模式等。
/doctor是排查环境问题的利器。安装出问题、命令找不到、连接异常，先跑/doctor，它会把环境检查一遍并给出建议。
/bug用于反馈问题，会收集诊断信息。
/review让模型审查你的代码改动，相当于一个内置的 code review 助手。提交前跑一下，能抓到不少低级错误。
/pr相关指令用于处理 Pull Request 流程，团队协作时很实用。
4. 内置工具调用：真正干活的那些指令
斜杠指令是"开关"，内置工具才是"手脚"。Claude Code 能读写文件、执行命令、搜索代码，这些能力通过自然语言触发，但了解背后的工具机制能让你用得更精准。
4.1 文件读写与编辑
当你让 Claude Code "修改某个文件"时，它实际调用的是文件编辑工具。这里有个关键点：它默认是精确替换而非整文件重写，所以你要给它足够的上下文定位。我一般会说"把 xxx 函数里的 yyy 改成 zzz"，而不是"优化一下这个文件"，后者容易改出你不想要的结果。
读取文件时，如果文件很大，它会分段读。你可以明确告诉它"只看前 100 行"或者"搜索包含 xxx 的部分"，能省不少 token。
4.2 命令执行与 Bash 集成
Claude Code 能直接跑 shell 命令，这是它区别于纯对话工具的核心。你可以说"跑一下测试""看看 git 状态""安装这个依赖"，它会执行并把结果读回来分析。
但这里有个必须注意的坑：它执行命令是在你的真实环境里，不是沙箱。所以涉及删除、覆盖、推送这类破坏性操作时，务必保持确认模式开启。我见过有人让它"清理一下临时文件"，结果它把有用的东西也删了。
4.3 代码搜索与理解
搜索工具让它能在整个代码库里找东西。你可以问"哪里定义了这个函数""哪些文件引用了这个模块"，它会用类似 grep 的机制搜索并汇总。
实测下来，给它明确的搜索范围能大幅提升准确率。比如"在 src 目录下找所有调用 xxx 的地方"，比"找找 xxx"精确得多。
4.4 Git 操作集成
Claude Code 对 Git 的支持相当完整。你可以让它：
- 查看改动：
git diff相关 - 生成提交信息：它会读 diff 然后写 message
- 创建分支、切换分支
- 处理冲突
我常用的一个组合是：改完代码后说"看一下改动，生成一个符合规范的提交信息"，它会读 diff 并给出 message，我确认后它再执行提交。提交信息质量比我自己写的高，因为它会通读所有改动。
5. 高频场景指令组合：把指令用成肌肉记忆
单条指令谁都会敲，真正拉开差距的是组合。下面是我日常最高频的几个场景，每个都给出完整的指令序列。
5.1 接手陌生项目：五步摸清底细
刚 clone 一个项目，别急着改代码。我的标准流程：
claude启动，进入项目目录/init生成项目说明- 问它"这个项目的入口在哪，主要模块怎么划分"
- 让它"跑一下测试，看看当前状态"
/clear清空，开始正式任务
这套下来，你对项目的理解速度比手动翻代码快好几倍。关键是第 2 步生成的说明文件会一直生效，后续会话都受益。
5.2 修 Bug：从复现到验证的闭环
修 bug 最怕改完不知道好没好。我的流程是：
- 把报错信息贴给它，让它"分析根因"
- 让它"找到相关代码并解释逻辑"
- 讨论修复方案，确认后让它改
- 让它"跑相关测试验证"
- 如果没测试，让它"写一个能复现这个 bug 的测试"
第 5 步是精髓。让 AI 写复现测试，既验证了修复，又给项目补了测试覆盖，一举两得。
5.3 重构：小步快跑，随时可回退
重构最忌讳一次性大改。我的做法是：
- 先让它"分析这段代码的问题，列出重构点"
- 一次只改一个点，改完立刻跑测试
- 每完成一个点就提交一次
- 用
/review让它自查改动
每步都提交是关键，出问题随时git reset回退。我吃过一次亏，让它一口气重构三个文件，结果中间某步引入的 bug 很难定位，最后只能全部回退重来。
5.4 写新功能：先设计后实现
新功能别上来就让它写代码。我的流程：
- 描述需求，让它"给出实现方案和涉及的文件"
- 讨论方案，确认技术选型
- 让它"先写接口和类型定义"
- 再让它"实现具体逻辑"
- 最后"补测试"
先接口后实现的好处是，你能在早期发现设计问题，而不是等一堆代码写完才发现方向错了。
6. 常见问题与排查技巧实录
用了这么久，踩的坑足够写一本小册子。挑几个最高频的分享。
6.1 指令不生效或找不到
最常见的原因是版本太旧。Claude Code 更新很快，新指令在老版本里可能不存在。先claude --version看版本，再npm update -g @anthropic-ai/claude-code更新。
如果更新后还不行，跑/doctor做环境诊断。十有八九是 PATH 或者权限问题。
6.2 上下文混乱，答非所问
这是新手最常遇到的。症状是模型开始重复、跑题、忘记之前的约定。九成是上下文太长或污染了。解决办法按顺序试：先/compact压缩，不行就/clear重来。养成完成一个任务就清一次的习惯，能避免大部分问题。
6.3 改文件改错地方
模型改错文件通常是因为你的描述不够精确。别说"改一下配置"，要说"改 config/database.yml 里的连接超时时间"。给它明确的文件路径和具体的改动点，准确率会高很多。
如果它已经改错了，别慌，git diff看改动，git checkout回退单个文件。这也是为什么我强调改之前确保工作区干净。
6.4 命令执行卡住或超时
有些命令会一直跑（比如启动服务器），Claude Code 会等它结束。遇到这种情况，明确告诉它这是长期运行的命令，或者用带超时的方式执行。我一般会说"这个命令会一直跑，你启动后确认端口监听就行，不用等它结束"。
6.5 费用超预期
/cost常看。费用高的原因通常是上下文太长（每次请求都带全部历史）或者用了强模型干简单活。对策：勤/clear、简单任务切快模型、大文件分段读。
下面这张表是我整理的速查：
| 症状 | 最可能原因 | 首选解决 |
|---|---|---|
| 指令不存在 | 版本旧 | 更新 |
| 答非所问 | 上下文污染 | /clear |
| 改错文件 | 描述不精确 | 给明确路径 |
| 命令卡住 | 长期运行命令 | 说明不用等 |
| 费用高 | 上下文长/模型强 | 勤清理/切模型 |
| 环境异常 | 配置问题 | /doctor |
6.6 几个独家避坑心得
第一，别在同一个会话里混多个不相关任务。上下文会互相干扰，模型容易把 A 任务的约定带到 B 任务。一个任务一个会话，干净利落。
第二，重要改动前先提交。让 AI 改代码前，确保工作区是干净的，这样出问题能一键回退。我现在的习惯是改之前先git add -A && git commit -m "checkpoint"，虽然糙但管用。
第三，善用 CLAUDE.md 沉淀约定。项目里反复出现的规范，写进这个文件，比每次口头交代强。比如"测试用 pytest""提交信息用中文""不要动 legacy 目录"，写一次，永久生效。
第四，让它解释而不是直接改。遇到不确定的改动，先让它"解释你打算怎么改，先别动手"，确认思路对了再让它执行。这一步能拦下很多想当然的错误。
7. 把指令变成工作流的一部分
指令记得再全，不用也是白搭。我的建议是先挑三五个高频场景，把对应的指令组合练成肌肉记忆，再逐步扩展。比如先把"接手项目"和"修 bug"两个流程跑熟，你会发现日常开发已经顺畅很多。
Claude Code 这类工具的价值，不在于它多聪明，而在于它能不能无缝嵌进你已有的工作流。指令就是那个接口。接口越熟，工具越像你手的延伸，而不是一个需要你迁就的外挂。
我个人的体会是，真正提升效率的不是学会了多少条指令，而是想清楚了哪些环节可以交给它、哪些必须自己把关。指令只是手段，判断力才是核心。
