1. 为什么需要一个命令速查手册用 Claude Code 的人大概都经历过这么一个阶段刚装好那会儿觉得新鲜敲几个指令看它自动改代码、跑测试、提交 commit感觉像多了个不用发工资的实习生。可用了一两周之后问题就来了——昨天刚记住的那个斜杠命令今天死活想不起来上次配置好的那个工作流这次又得重新翻文档快捷键更是按一次忘一次。这不是你记性差是 Claude Code 的命令体系确实有点“散”。它不像 Vim 那样有一套高度自洽的模态逻辑也不像 VSCode 那样所有操作都能在命令面板里搜到。Claude Code 的交互层揉了三样东西斜杠命令Slash Commands、自然语言指令、终端快捷键。这三套东西各管一摊混在一起用的时候特别容易乱。我自己的习惯是凡是高频但记不住的东西一律整理成一张速查表贴在显示器旁边。这份手册就是这么来的——不是官方文档的翻译是我自己用了几个月、踩了若干坑之后把真正高频、真正省时间的部分筛出来重新组织的。它适合两类人一类是刚装好 Claude Code、还在摸索阶段的新手另一类是已经用了一阵子但总觉得效率没拉满的老用户。前者可以照着抄后者可以对照着查漏补缺。下面我会按“命令体系拆解 → 核心命令详解 → 快捷键与终端操作 → 工作流搭建 → 配置文件管理 → 问题排查”这个顺序展开。每一块都尽量给到能直接复现的步骤和参数而不是泛泛而谈“你可以这样那样”。2. Claude Code 命令体系全拆解2.1 三套命令系统的分工逻辑很多人一开始搞不清 Claude Code 里到底有几种“命令”其实按触发方式和作用范围可以分成三类类型触发方式作用范围典型例子斜杠命令输入/开头会话控制、模式切换、配置管理/compact、/model、/resume自然语言指令直接打字描述需求代码修改、文件操作、任务执行“把这个函数拆成两个”终端快捷键组合键输入编辑、历史调用、中断操作CtrlC、CtrlR、Esc这三类的设计意图很清楚斜杠命令管“元操作”也就是控制 Claude Code 本身怎么运行自然语言管“干活”也就是让它去改代码、跑命令快捷键管“手感”让你在终端里操作得更顺手。理解这个分工之后你就不会在想要压缩上下文的时候去敲自然语言也不会在想要改代码的时候去找斜杠命令了。2.2 斜杠命令的完整清单与使用场景斜杠命令是 Claude Code 里最“像工具”的部分。截至我写这份手册时的版本常用的斜杠命令大概有这些/help列出所有可用命令。记不住的时候先敲这个。/compact压缩当前会话的上下文。对话太长、响应变慢、或者快到 token 上限时用。/clear清空当前会话重新开始。和/compact的区别是它不保留摘要直接归零。/model切换底层模型。比如从默认模型切到更快的轻量模型或者切到更强的推理模型。/resume恢复之前的会话。误关终端或者想接着上次的进度继续时用。/config查看和修改配置。包括 API 相关设置、默认模型、权限模式等。/cost查看当前会话的 token 消耗和费用估算。长会话里定期看一眼心里有数。/doctor诊断环境问题。安装出问题、命令不响应、权限报错时先跑这个。/init在当前项目里初始化CLAUDE.md文件。新项目接入时的第一步。/review对当前改动做代码审查。提交前跑一遍能抓到不少低级问题。/pr创建 Pull Request 相关的操作。配合 Git 工作流使用。/terminal-setup配置终端集成。让 Claude Code 更好地和你的终端环境配合。这些命令里/compact、/clear、/model、/resume、/init是我用得最频繁的五个。尤其是/compact长会话里不用它响应速度会肉眼可见地变慢而且容易在关键问题上“失忆”。注意/compact和/clear的区别值得单独记一下。/compact会把之前的对话压缩成摘要保留Claude 还能记得你之前干了什么/clear是彻底清空适合切换任务或者开新坑的时候用。用错了会导致要么上下文丢失要么该清的时候没清干净。2.3 自然语言指令的写法技巧自然语言指令看起来最简单其实最考验表达。同样一个需求说法不同Claude Code 的执行结果可能差很远。我总结下来有效的自然语言指令通常包含三个要素动作、范围、约束。举个例子你想让它重构一个函数差的写法“帮我改一下这个函数。”太模糊它不知道改什么、改成什么样好的写法“把processOrder这个函数拆成两个一个负责参数校验一个负责业务逻辑。保持原有的错误处理不变拆完之后更新对应的单元测试。”再比如你想让它排查一个 bug差的写法“这里有问题。”它得先猜是什么问题好的写法“getUserInfo在传入空字符串时会抛异常帮我定位原因并修复。先看调用链再看边界条件处理。”核心原则就一条把它当成一个刚进项目的新同事你需要给足上下文但不要替它做决定。你告诉它“做什么”和“约束是什么”具体“怎么做”交给它。另外自然语言指令里可以嵌入文件路径、函数名、行号这些具体信息Claude Code 能识别并直接定位。比如“看一下src/utils/date.ts第 42 行的那个格式化函数”比“看一下日期工具文件”要高效得多。3. 高频斜杠命令的深度用法3.1 /compact 的正确使用时机与参数/compact是 Claude Code 里最被低估的命令之一。很多人要么不用要么用得太晚。先说什么时候该用。我的经验是当出现以下任一信号时就该考虑压缩了响应速度明显变慢尤其是简单问题也要等好几秒Claude 开始“忘记”之前明确说过的约束比如你之前说过“不要改测试文件”它又开始改了/cost显示的 token 消耗增长曲线变陡你感觉对话历史里已经积累了大量和当前任务无关的内容/compact本身不带参数但你可以通过自然语言给它指令比如“压缩上下文重点保留关于数据库 schema 的讨论”。这样压缩后的摘要会更有针对性。实操心得我习惯在完成一个阶段性任务之后主动跑一次/compact而不是等到出问题了才跑。比如改完一个模块、跑完一轮测试之后顺手压缩一下把之前的细节收拢成摘要给后续任务腾出上下文空间。这个习惯让我的长会话稳定性提升了很多。3.2 /model 切换模型的策略/model命令用来切换底层模型。不同模型在速度、推理深度、成本上差异明显所以切换策略值得单独说一下。我的用法是这样的日常改代码、写测试、做重构用默认模型就够了速度和质量的平衡最好复杂架构设计、疑难 bug 排查切到推理能力更强的模型虽然慢一点但值得简单的格式化、重命名、批量替换切到更快的轻量模型省时间也省成本长文档总结、代码审查看情况如果文档很长用上下文窗口大的模型切换的时候直接敲/model然后按提示选就行。有些版本支持直接带参数比如/model opus或/model sonnet具体看你装的版本。注意切换模型不会丢失当前会话的上下文但不同模型对同一段上下文的理解可能有细微差异。如果你在一个长会话中途切模型建议先/compact一下让新模型从摘要开始接手避免它被之前冗长的对话带偏。3.3 /init 与 CLAUDE.md 的初始化/init是在一个新项目里接入 Claude Code 的第一步。它会扫描你的项目结构生成一个CLAUDE.md文件里面包含项目的基本信息、技术栈、目录结构、常用命令等。这个文件的作用是给 Claude Code 提供“项目背景”。有了它你就不用每次开新会话都重新解释“这是个什么项目、用什么框架、怎么跑测试”。/init生成的CLAUDE.md是一个起点不是终点。我通常会在它生成的基础上手动补充几类信息项目特有的约定比如“所有 API 响应必须用统一的ResponseWrapper包装”容易踩的坑比如“不要直接改generated目录下的文件那是自动生成的”常用命令比如“跑测试用pnpm test:unit不要用npm test”代码风格偏好比如“函数参数超过三个时用对象传参”这些信息写进去之后Claude Code 在后续所有会话里都会遵守省去了大量重复解释的时间。3.4 /resume 恢复会话的注意事项/resume用来恢复之前的会话。终端意外关闭、或者你主动退出之后想接着上次的进度继续就用它。敲/resume之后会列出最近的会话选一个恢复就行。恢复之后之前的对话历史、文件改动记录、上下文都会回来。但有几个坑要注意恢复的会话可能已经“过期”如果你上次会话里改的文件在会话关闭期间被其他方式修改了恢复后 Claude 的认知可能和实际文件状态不一致。恢复后先让它重新读一下相关文件。不要跨项目恢复不同项目的会话上下文差异太大恢复过来反而容易混淆。/resume列表里如果混了多个项目的会话选的时候看清楚。恢复后先/cost看一眼如果之前的会话已经消耗了很多 token恢复后继续用可能会很快触顶。必要时先/compact。4. 终端快捷键与输入效率4.1 输入编辑类快捷键Claude Code 跑在终端里所以终端本身的快捷键大部分都能用。但有几组是特别高频的值得单独练熟快捷键作用使用场景CtrlA光标移到行首修改长指令的开头部分CtrlE光标移到行尾快速跳到末尾继续输入CtrlU删除光标前所有内容整行重写时用CtrlK删除光标后所有内容保留前半段重写后半段CtrlW删除光标前一个单词改错一个词时用CtrlY粘贴之前删除的内容配合CtrlU/CtrlK做剪切粘贴Option左/右Mac按单词移动光标长指令里快速定位Alt左/右Win/Linux按单词移动光标同上这些快捷键里CtrlA、CtrlE、CtrlU、CtrlW是我用得最多的。尤其是CtrlW改指令里打错的一个词时比按一堆退格键快多了。4.2 会话控制类快捷键除了输入编辑还有一组控制会话行为的快捷键CtrlC中断当前操作。Claude 正在跑一个长任务、或者你想取消当前指令时用。CtrlD退出会话。相当于正常关闭。CtrlL清屏。终端输出太多时清一下但不清除会话上下文。CtrlR搜索历史指令。想重复之前敲过的一条指令时用。Esc取消当前输入。和CtrlC的区别是它只清空输入框不中断正在执行的任务。上/下箭头翻阅历史指令。比CtrlR更直观适合快速找最近几条。实操心得CtrlC和Esc的区别我踩过坑。有一次 Claude 正在跑一个批量重命名的任务我想取消按了Esc结果只是清空了输入框任务还在跑。后来才知道要按CtrlC才能真正中断。记住Esc管输入框CtrlC管任务执行。4.3 多行输入与特殊字符处理Claude Code 的输入框默认是单行回车即发送。但有时候你需要输入多行内容比如一段带格式的代码或者一个多步骤的指令。多行输入的方式通常是ShiftEnter换行但不发送部分终端需要配置CtrlJ插入换行符或者直接用\结尾表示续行如果ShiftEnter不生效可能是终端配置问题。可以在/terminal-setup里检查一下终端集成设置。特殊字符方面反引号、美元符号、反斜杠这些在终端里有特殊含义的字符直接输入通常没问题但如果遇到解析异常可以用单引号包裹或者转义。5. 高效工作流的搭建方法5.1 从零搭建一个 Claude Code 工作流工作流这个词听起来很大其实拆开就是在什么场景下按什么顺序用哪些命令和配置完成一类任务。我拿“日常功能开发”这个场景举例完整的工作流是这样的进入项目目录启动 Claude Code。如果是新项目先跑/init生成CLAUDE.md然后手动补充项目约定。描述需求。用自然语言说清楚要做什么包含动作、范围、约束。比如“在user模块里加一个根据邮箱查用户的方法要处理邮箱不存在的情况返回统一的错误结构”。让它先出方案。不要直接让它改代码先说“先给我一个实现方案不要动代码”。这样你可以先审一遍思路避免它跑偏。确认方案后让它执行。执行过程中如果发现方向不对及时CtrlC中断补充约束后重新来。跑测试。让它跑相关测试或者你自己跑。如果有失败把失败信息贴给它让它修。/review审查。提交前跑一遍代码审查看有没有遗漏的边界情况或者风格问题。/compact压缩。这个任务告一段落压缩上下文为下一个任务腾空间。提交。让它生成 commit message或者你自己写。这个流程跑熟之后一个中等复杂度的功能开发从描述需求到提交大概能比纯手写快 40% 到 60%。当然具体取决于任务类型和你的描述质量。5.2 多任务切换时的上下文管理实际工作中很少一次只干一件事。经常是写着 A 功能突然要修 B bug修完 B 又想起来 C 还没改。这种多任务切换的场景上下文管理就特别重要。我的做法是每个独立任务开始前先/clear。不要在一个会话里混着干几件事上下文会互相污染。如果任务之间有依赖用/compact而不是/clear。比如修完 B bug 之后要接着改 A 功能而 B 的修改会影响 A那就压缩而不是清空。善用/resume。如果某个任务做到一半被打断先退出处理完紧急的事再/resume回来接着做。给每个会话起个能认出来的开头。比如第一句话就说“现在处理用户登录的 token 刷新问题”这样/resume列表里一眼就能认出来。注意不要在同一个会话里既改前端又改后端还改数据库 migration。Claude 的上下文是有限的混太多东西进去它会在关键细节上出错。宁可多开几个会话也不要图省事混在一起。5.3 结合 Git 的工作流实践Claude Code 和 Git 配合得好能省很多事。我常用的几个操作提交前审查/review之后让它生成 commit message。它的 message 通常比我自己写的规范尤其是 conventional commits 格式。分支管理让它帮你创建分支、切换分支、合并分支。比如“从 main 切一个新分支叫feat/user-email-query”。冲突解决遇到 merge conflict 时把冲突文件指给它让它分析两边改动并给出解决方案。但最终决定权在你不要让它自动 resolve。查看历史让它帮你查某个文件的修改历史或者某个功能是什么时候引入的。比手动git log加git blame快。但有一条红线不要让它自动 push 或者自动 merge 到主分支。所有涉及远程仓库和主分支的操作都要你手动确认。这是安全底线。6. CLAUDE.md 配置文件的深度管理6.1 CLAUDE.md 的层级结构CLAUDE.md可以放在多个位置不同位置的生效范围和优先级不同位置生效范围适用内容项目根目录当前项目所有会话项目约定、技术栈、常用命令子目录该目录及子目录模块特有的约定用户主目录所有项目个人偏好、通用规则优先级是子目录 项目根目录 用户主目录。也就是说如果子目录里的CLAUDE.md和根目录的冲突以子目录为准。这个层级结构很有用。比如你可以在用户主目录放一些通用偏好“回答用中文”、“代码注释用英文”在项目根目录放项目约定在某个特殊模块的子目录放该模块的特有规则。6.2 写 CLAUDE.md 的实用技巧写CLAUDE.md不是写文档不需要面面俱到。它的核心目的是让 Claude Code 少犯错、少问重复问题。所以内容应该聚焦在它容易搞错的地方比如项目用的是 pnpm 不是 npm测试命令是pnpm test:unit不是pnpm test它不知道的约定比如错误处理必须用某个特定的类日志必须走某个 logger它需要知道的背景比如这个项目是从某个老系统迁移过来的有些历史包袱不能动明确的禁止项比如“不要改vendor目录”、“不要动legacy文件夹里的代码”我见过有人把CLAUDE.md写成项目 README 的翻版其实没必要。README 是给人看的CLAUDE.md是给 Claude 看的。给 Claude 看的东西越具体、越可执行越好。实操心得CLAUDE.md要定期更新。项目在演进约定在变化如果CLAUDE.md还是三个月前的内容Claude 可能会按过时的规则行事。我习惯在每个大版本发布后花五分钟过一遍CLAUDE.md把过时的条目删掉把新约定加上。6.3 配置文件的版本管理CLAUDE.md应该提交到 Git 仓库里和代码一起管理。这样团队里每个人用的都是同一份项目约定不会出现“你那边 Claude 知道这个规则我这边不知道”的情况。但用户主目录的CLAUDE.md不要提交那是个人偏好每个人可以不一样。如果团队里对CLAUDE.md的内容有争议我的建议是只把无争议的、客观的约定写进去。比如“用 pnpm”是客观的“函数不要超过 50 行”是有争议的。有争议的规则写进去反而会让 Claude 在不同人的会话里表现不一致。7. 常见问题与排查技巧实录7.1 安装与启动类问题问题敲了claude命令提示找不到。先确认安装路径在PATH里。如果是通过 npm 全局安装的检查 npm 的全局 bin 目录是否在PATH中。可以用which claudeMac/Linux或where claudeWindows看一下能不能找到。如果找不到重新安装一遍注意看安装过程中的提示。有些安装方式需要手动把安装目录加到PATH里。问题启动后一直卡在加载界面。先跑/doctor诊断。常见原因包括网络问题、API 配置问题、或者版本过旧。如果是版本问题升级到最新版通常能解决。问题Windows 下脚本闪退。Windows 的终端环境比较复杂建议用 Windows Terminal 或者 Git Bash不要用老式的 cmd。另外确认 Node.js 版本符合要求太老的版本会有兼容问题。7.2 命令执行类问题问题/compact之后 Claude 好像“失忆”了。这是正常的。/compact会把详细对话压缩成摘要细节肯定会丢失。如果某些信息很重要在压缩前用自然语言强调一下“压缩时保留关于数据库 schema 的所有细节。”问题/resume恢复的会话和实际文件状态不一致。恢复后先让它重新读一下相关文件。可以这样说“重新读一下src/user/service.ts然后告诉我你看到的当前状态。”这样它的认知就和实际文件对齐了。问题斜杠命令敲了没反应。先确认命令拼写正确然后确认当前版本支持这个命令。不同版本的命令集可能有差异/help里列出来的才是当前版本可用的。7.3 上下文与性能类问题问题响应越来越慢。大概率是上下文太长了。先/cost看一眼 token 消耗然后/compact压缩。如果压缩后还是慢考虑/clear重开把关键信息重新说一遍。问题Claude 开始重复之前已经纠正过的错误。这是上下文过长的典型症状。它在长对话里会“遗忘”早期的约束。解决办法是/compact并在压缩指令里强调那些被遗忘的约束。如果还不行就/clear重开把约束写在最前面。问题token 消耗太快。检查一下是不是把大文件整个读进来了。可以让它只读相关部分而不是整个文件。另外长会话定期/compact也能控制消耗。7.4 常见问题速查表症状可能原因解决方式命令找不到PATH 配置问题检查安装路径重新安装启动卡住网络/配置/版本问题跑/doctor升级版本响应变慢上下文过长/compact或/clear遗忘约束上下文过长/compact并强调关键约束恢复后状态不一致文件被外部修改让它重新读相关文件斜杠命令无效拼写错误或版本不支持/help确认可用命令token 消耗快读入了大文件只读相关部分定期压缩8. 我个人的几条使用原则用了这么久有几条原则是我觉得比具体命令更重要的。第一条描述需求时宁可啰嗦不要含糊。你多花三十秒说清楚约束和期望能省掉后面十分钟的来回纠正。Claude Code 不怕你话多怕你话少。第二条重要操作前先让它出方案。尤其是涉及多个文件、多个模块的改动先看方案再执行比直接让它改要稳得多。改错了回滚的成本远高于看方案的时间成本。第三条定期清理上下文不要攒着。上下文就像工作台堆太多东西就没法干活了。完成一个任务就/compact一下切换任务就/clear一下保持工作台干净。第四条CLAUDE.md是活的不是死的。每次发现它犯了某个本可以避免的错误就把对应的规则补进CLAUDE.md。日积月累它会越来越懂你的项目你解释的成本会越来越低。第五条涉及远程仓库和主分支的操作永远手动确认。这是安全底线没有例外。自动化能省时间但省出来的时间不值得用一次误操作来换。最后再分享一个小技巧如果你经常忘记某个斜杠命令的拼写可以在CLAUDE.md里加一条“常用命令速查”把高频命令列出来。这样你问它“压缩上下文的命令是什么”的时候它能直接告诉你不用你去翻文档。这个技巧我用得很多尤其是刚换版本、命令集有变化的时候。