第一次用 Claude Code 的朋友，十个里有九个会把它当成一个高级聊天窗口：输入需求、等代码、再输入、再等。打字当然没错，但如果你只会打字，你等于租了一辆跑车却永远挂在二档。真正让这套工具区别于普通对话的，是那些以斜杠开头的内置命令——它们不需要你组织语言，不依赖模型临时发挥，而是由客户端直接执行固定动作。这篇速查手册，我不打算只贴一张命令清单，我会把每个命令背后的使用逻辑、适合什么时候用、踩过什么坑一起写进来。适合刚接触 Claude Code、正在被长会话折磨、或者被 AI 乱改文件吓到过的人。
1. 为什么说“只会打字”是浪费：斜杠命令到底在做什么
1.1 斜杠命令不是“发消息”，是“发指令”
很多人误以为斜杠命令也是一种 prompt，只是格式特殊一点，其实完全不是一回事。普通打字时，你的所有文字都会进入模型上下文，模型用自己的能力去「理解」你想要什么，然后自由发挥。而/clear、/status这类命令，一般在输入框里被识别后就直接被客户端截获了，模型根本看不到这条消息，更不涉及“理解”。客户端自己完成了清理、查询状态、读取配置等动作，然后把结果拼进上下文，模型只是在后续轮次里使用这个结果。
这个区别非常重要：普通打字的成功率取决于模型的临场发挥，斜杠命令的确定性则由代码保证。所以当你想让 AI “记住项目背景”的时候，与其反复叮嘱“你要记得我们项目的技术栈是 XX”，不如直接用/init生成一份项目档案；当你想让对话回到干净状态时，与其长篇大论解释“刚才那些内容不要管了”，不如直接/clear。你可以把斜杠命令理解为大厨餐厅里的固定菜单——不用跟大厨解释什么是盐、什么是糖，菜单上写了，后厨就直接照做。
1.2 从 /help 开始，而不是从百度开始
第一次接触这套工具，建议先敲一个/help。这一步会列出一批命令名、用途说明和常用快捷键，而且它会根据你客户端的版本输出对应的内容。很多网上搜到的命令用法，其实已经落后了好几个版本，新版本可能改了名字、加了新参数，甚至废弃了旧命令。我见过有人照着老教程去用某个命令，结果终端直接提示“未知的斜杠命令”，这就是版本差异的坑。
正确的上手顺序是：先/help看全量命令，再针对自己关心的命令去查文档，最后实际跑一遍验证效果。不要一上来就照抄别人贴在社区里的完整配置，因为对方的版本、平台、项目类型都可能跟你不一样。/help这个命令本身也是少数几个“不会出错”的命令，新手随便折腾也不会有副作用。
1.3 一套粗但好用的命令分类法
命令数量看起来不少，但按功能可以分成四类，记起来就轻松很多：
- 会话控制类：管理上下文和对话状态，比如
/clear、/compact、/resume，解决“AI 记不住、记太乱、状态错乱”的问题。 - 项目记忆类：让 AI 了解项目背景，比如
/init、/memory，本质上是读写项目档案和用户偏好文件。 - 运行监控类：查看和管理当前会话的模型、状态、环境变量，比如
/model、/status、/env。 - 权限配置类：控制 AI 能做什么、不能做什么，比如
/permissions、/config。
这个分类不是官方文档里的，但对我来说非常实用。遇到问题时，先判断是“上下文乱了”还是“权限不够”，还是“模型选错了”，然后对应去找那一类命令，而不是把命令当字典死记。后面几节我会按这个分类，把每个命令的使用场景和注意事项展开讲。
2. 会话管理三件套：/clear、/compact、/init 的适用场景与误用提醒
2.1 /clear：治“AI 突然变傻”的第一步
用 Claude Code 时间长了你会发现一个规律：对话开始时模型很聪明，两三个小时之后就开始“犯糊涂”——明明刚才确认过的事又忘了，或者把上一个任务的变量名带到新任务里。这通常不是模型变笨了，而是上下文被无关内容塞满了，注意力分散了。这时候最直接的办法就是/clear，把历史消息清空，从干净的状态重新开始。
但/clear有一个很坑的地方：它把历史记录清掉之后，你没法再就刚才的话题继续追问。假如你刚让 AI 分析了某段日志，正准备针对第一行日志继续排查，一个手滑/clear下去，刚才的分析内容就没了，只能从头再来。所以我的习惯是：清空之前，先把重要结论复制到项目里的临时笔记文件，或者干脆先/compact压缩而不是直接清空。/clear是重拳，要确认自己真的不需要旧上下文了才用。
还有个使用时机：一次任务完成后，要切换到完全不相关的另一个任务，强烈建议/clear。举例来说，你刚让 AI 检索完线上日志，又让它帮你写一个新模块的代码，这时如果不清理，模型很容易把日志里出现的字段名、报错信息“梦游式”写进新代码。我曾经就在一次会话里，让 AI 写完模块再用日志里的字段做了个判断，最后改了半天才发现是上下文污染。清一下，通常是最省时间的。
2.2 /compact：给上下文瘦身的正确时机
长会话之所以会“失忆”，是因为上下文窗口有上限。接近上限时，客户端一般有两种做法：丢弃最早的消息，或者把历史压缩成摘要。/compact做的就是后者——把之前的对话内容概括成一段摘要，腾出空间给后续对话。这个机制听起来很美好，但代价是细节会丢失。
所以/compact不是随时随地都能用的。我的经验是，当/status显示上下文占用已经超过六七成，或者感觉模型开始忽略早期指令时，就该压缩了。比较理想的压缩时机是“一个子任务收尾之后”。比如你刚让 AI 完成了某个函数的实现，并且验证通过，这时候旧对话里的细节已经没那么重要了，压缩摘要里保留“已完成 XX 函数”这个结论就够了，接下来可以继续下一个任务。
反过来说，如果你正在排查一个很细的问题，每一条日志、每一个报错都很关键，那你就不该急着/compact，否则模型会把细节丢掉，回答变成“根据之前的分析，问题可能与 A 有关”这种模糊结论。我踩过最痛的一次坑，是让 AI 分析一个较长的堆栈追踪，眼看上下文要爆，我直接/compact了一下，结果它把堆栈中间的关键异常类名给概括丢了，排查直接断掉。这也再次说明：压缩前，先问自己“接下来的对话还需要这些细节吗”。
2.3 /init：把项目背景装进 CLAUDE.md
/init对第一次接触一个老项目的人来说，几乎就是救命稻草。它的作用是扫描当前项目，读取已有的说明文档、代码目录结构、配置文件等，生成一份CLAUDE.md档案。这个文件之后会被自动放进每个新会话的上下文，相当于给 AI 一份“项目入职手册”。有了它，你不需要在每次对话开头都重新介绍一遍“我们的项目是干什么的、用了什么框架、目录结构是怎样的”。
但这里有个很大的误区：/init生成的文件不能直接用。自动生成的CLAUDE.md往往会有问题——它可能把大量依赖包名塞进去，可能把已经废弃的目录也写进结构说明，甚至包含一些过度细节的内容，让文件变得冗长、占上下文空间。我在一个老项目中跑了/init，生成出来的文档有几百行，其中一半是 AI 自己推测的错误结论。所以我拿到自动生成的档案后，一定会人工审核一遍，把内容精简到“人能流畅读完、AI 能快速定位”的程度。
理想状态下的CLAUDE.md大概就这些内容：项目是做什么的、如何启动、核心目录结构、常用命令、编码约定、已知的特殊坑。控制在 200 行以内比较合适。这个文件写得好，AI 后续写出来的代码风格都会更贴近项目，错误率明显下降。如果项目本身已经有很完善的 README，你甚至可以考虑不跑/init，手动写一个精简版放进CLAUDE.md反而更准确。
2.4 三个命令的组合节奏
这三个命令经常要配合使用，我总结了一套“三连”流程。接手一个陌生项目时：先/init生成项目档案，人工精简之后，再正式提需求。对话进行中，每当完成一个小里程碑，用/compact压缩旧上下文；只有需要彻底切换任务时，才用/clear。曾经带过一个对 AI 工具不熟悉的同事，他不管三七二十一，每天早上一上来就/clear清掉前一天所有对话，导致 AI 完全不记得昨天已确认的技术决策。后来改成每天收工时先/compact，并在CLAUDE.md里追加一条当天决策摘要，第二天直接继续，效率提升不止一点。
3. 监控与控制：用 /model、/status、/env 管好模型选择和运行成本
3.1 /model：别让大材小用烧掉你的额度
很多人从头到尾只用一个模型，这其实是性能与成本的浪费。任务复杂度差异很大：改一个 JSON 配置、格式化一段代码，和跨文件重构一个模块，对模型能力的要求完全不同。通过/model可以在会话中直接切换模型。我的习惯是：简单机械任务用轻量模型，快速且费用低；复杂推理任务再接权重更高、能力更强的模型。
但切换模型有几个坑。首先，不同模型之间对上下文的“记忆能力”不完全一样，切换后模型可能没有沿用之前的全部上下文约定，所以重要约束最好在切完后重新强调一遍。其次，不要在任务进行到一半时随意切换——比如你正在调试一个很难的问题，AI 已经掌握了很多中间线索，这时切到另一个模型，新模型可能无法继承那些隐性的“分析思路”，反而要重新摸索。切换前如果上下文问题很大，建议先/compact或把当前结论写入笔记文件。
还要注意，模型选择不是越强越好。强模型响应慢、费用高，在简单问题上往往体现不出优势，反而拖慢节奏。我见过有人连让 AI 猜一个正则表达式都切换到最高规格的模型，一个上午下来额度烧得飞快，实在没必要。你可以把/model理解为变速箱：起步用一档，高速再换到高档，别一直拉到红线。
3.2 /status：成本与上下文的实时账本
/status是我用得最频繁的命令之一，它的价值被很多人低估了。它能告诉你当前会话的模型、上下文占用情况、请求次数，以及估算消耗。刚开始我根本没注意这个命令，直到有次月底看账单吓一跳，才意识到上下文消耗有多夸张——而/status就是那个能让你随时看清“钱在怎么烧”的地方。
有个真实案例：我在做一个数据同步任务时，让 AI 分析一个比较庞大的模块，结果它反复调用文件读取工具，把同一个目录下的文件来来回回读了很多遍，一次对话竟然消耗了相当可观的 token。我打开/status才发现问题，调整策略——明确告诉它“优先看这两个文件，不要扫描全仓库”，后面消耗立刻降下来了。如果没有/status，我可能要等账单出来才发现问题。现在我的习惯是，每完成一个子任务，瞄一眼/status；一旦发现上下文占用异常高，马上检查是不是有大量重复的工具调用。
另一个实用场景：同时跑多个会话时，/status能帮你找出“哪个窗口在偷偷烧钱”。我自己经常同时开两三个会话，分别处理不同子任务，如果不看状态，很难判断消耗主要集中在哪边。用/status对比几个会话的数据，把重任务集中到最有必要的会话里，其他会话尽量缩短，开销能省不少。
3.3 /env：环境变量是排查问题的入口
环境变量对这类终端工具的运行影响很大，比如默认编辑器路径、API 密钥、目录权限等。当 AI 行为不符合预期时——明明让它写文件却报权限错误，或者一直用的不是你预期的配置文件——第一件事就是用/env查看当前环境变量，确认客户端到底看到了什么。
我记得有个项目，/config里明明把默认编辑器设置成了 VS Code 风格的路径，可实际操作时 AI 总是打不开编辑器配置。排查了半天才发现是环境变量里有一个覆盖项，把客户端实际的编辑器路径指到了另一个地方。这就是/env的价值：它能帮你排除“客户端实际看到的配置”和“你以为的配置”之间的差异。
不过要注意，/env会展示环境变量的值，其中包括密钥类信息。尽量不要把完整输出直接贴到公开渠道，尤其是和 API 密钥、秘钥相关的条目，最好只说变量名，不说值。排查环境问题之前，心里要有个数：通常只需要确认“哪个变量被设置成了什么”，不是把整个环境 dump 给别人看。
3.4 监控意识比命令本身更值钱
斜杠命令是工具，但真正能帮你省钱的，是“监控意识”。我认识很多把这类工具用得很溜的人，并不是因为他们记住了一堆命令，而是因为他们在关键节点看状态、控制成本。比如：开始一个大任务前，先/status看当前会话状态；跑了一段时间后，再/status看消耗；任务偏离预期时，不要硬撑着让 AI 继续摸索，而是停下来判断是上下文问题还是模型问题。
这种意识的养成，依赖于对上下文的“定量理解”。你可以把上下文想象成一个杯子，你不加控制地持续往里倒水，最后总会溢出；溢出前要么倒掉一些（/clear），要么把水浓缩成冰块（/compact）。而/status就是那个杯子上的刻度线，让你知道水到了什么位置。没有刻度线的人，永远在“快溢出了才发现”。
4. 权限与记忆：/permissions、/config、/memory 的安全边界
4.1 /permissions：权限不是越宽越好
很多新手为了省事，第一次弹出权限确认时直接选择“总是允许”，甚至把所有操作都设成自动放行。结果就是 AI 可以随意修改文件、执行命令、调用外部工具，然后出了一个很难收拾的局面。权限管理的核心原则应该是“读写分离、最小授权”：读取文件这类低风险操作可以适当放宽，修改、删除、覆盖文件，以及执行命令这种高风险操作，一定要保持确认，尤其在项目早期。
/permissions就是用来管理这套规则的。按客户端的设计，你可以让它在执行每种操作前问你一次、直接通过、还是直接拒绝。我的推荐配置是：普通文件读取直接通过，减少无意义的打断；但文件写入、命令执行、网络操作都保持“询问”，宁可多打断几次，也不要给 AI 一把万能钥匙。
这里有个比较容易犯的错误：权限规则是按目录或命令模式来配置的，一不小心就会把范围写得过宽。比如你为了让它能改某个配置目录，规则写成了“对某配置文件允许修改”，结果配置文件所在目录下的其他文件也一起被放行了。所以每加一条权限规则，最好自己先确认覆盖范围，别只图顺手。
4.2 /config：配置文件的改动要留后路
/config用于查看和修改客户端偏好设置。这类配置项很多，比如默认编辑器、是否自动确认权限提示、主题样式等。区别于/permissions的地方在于，/config更偏向“客户端本身”的行为，而权限规则更像是“当前项目”的操作边界。
修改配置之前，建议先用/config看看当前值，再决定改哪些项。最怕的情况是，看到一大串配置项后“顺手”把某个看起来不相关的值改了，结果导致行为怪异，又找不到原因。我犯过这种错误：为了调整自动补全行为，我把某个配置项的值改成了错误格式，客户端直接罢工，最后还是靠备份恢复才解决。现在我的习惯是，任何配置改动前，先把原值写在笔记里；一次只改一个项，改完立即跑一个小任务验证。配置这东西，讲究的是“留后路”。
4.3 /memory：区分全局记忆与项目记忆
CLAUDE.md和/memory容易被人搞混。简单来说，CLAUDE.md是项目级别的记忆，只对当前项目生效；而/memory维护的是用户级的全局记忆，跨项目生效。项目特有的技术栈、目录约定、编码规范，应该放进CLAUDE.md；而你个人的偏好——比如“代码注释用中文”、“提交信息遵循某种格式”——适合写进/memory。
我第一次用/memory的时候，恨不得把所有偏好都塞进去，结果文件越来越长，启动时拉取的上下文也变多，而且有些偏好在不同项目里互相矛盾。后来我做了取舍：/memory只保留跨项目通用的偏好，并且尽量简洁；项目相关的细节全部交给CLAUDE.md。这个边界一旦清晰，AI 的表现会稳定很多——它不会在某个项目里调出你在另一个项目里的语言偏好，也不会把个人习惯误当成团队规范。
4.4 权限事故的真实翻车现场
讲一个真实教训。某次我在帮团队配置一个自动化脚本时，为了追求“顺畅体验”，把所有权限弹窗都设成了自动允许，包括执行任意命令。结果隔天讨论一个需求时，AI 在修改某个脚本的过程中，因为理解偏差，用一句不太精确的指令触发了一次大范围清理操作，虽然最后通过备份找回，但当时的惊吓和返工成本足够让人记住一辈子。打那以后，我给自己立了一条铁律：永远不允许“执行任意命令”这类全放行规则，复杂操作保持每一步确认。
权限意识不只是保护你的代码，它也在保护你的时间——很多误操作，一旦发生，找问题比当初不提权限花的时间还多。尤其是自动生成的代码，AI 对自己的输出往往过于自信，没有权限确认的情况下，它改了文件也不会告诉你。这时候再手动对比改动，成本极高。
5. 容易被忽略的保命细节：中断、恢复、拖拽与多会话切换
5.1 中断：停止不当操作得靠快捷键
斜杠命令能帮我们管理会话，但真正的“紧急制动”是快捷键。当 AI 开始执行一个你不想让它做的操作，或者生成的内容明显跑偏时，不要等着它结束，直接用终端的中断快捷键把它停下来。这一点很多人不知道，只会干瞪眼任由 AI 继续调用工具。
中断的时机很关键。很多时候模型已经生成了几条错误的指令，只是还没来得及执行，这时你及时打断，就能避免后续一连串的错误文件操作。我有一次让它批量重命名一组文件，结果规则写错了，眼看要执行时我按下中断，挽救了十几个文件；如果当时只知道发慌，后果就是逐个找回。Ctrl+C 或者 Esc 具体是哪个键，看客户端提示，但一定要养成“紧急就停”的肌肉记忆。
5.2 拖拽与剪贴板：不用反复复制粘贴路径
这类终端工具通常支持拖拽文件到窗口，直接把文件路径或内容注入输入框，省去手动粘贴长路径的麻烦。这个细节看起来不起眼，但在处理较长的文件路径时非常省时间，而且能避免手打路径出错。用了几次之后你会发现，原来需要三步的操作（复制路径、粘贴、确认存在）变成一步就完成了。
还有剪贴板粘贴。遇到要贴一大段日志或配置时，不要把内容直接扔进 prompt 让 AI 理解上下文，容易造成上下文膨胀。我的做法是：先把日志保存到项目临时文件里，再让 AI 读取那个文件，需要精确匹配的部分再贴原文。这个思路本质上是把“非结构化文本”转变为“可复用文件”，既减少上下文负担，也方便后续回溯。
5.3 多会话与断点续谈：别让一切从零开始
如果你同时处理多个任务，不要在一个会话里来回切换主题，那样只会加速上下文污染。更合理的做法是：每个任务开一个独立会话，任务之间通过/clear或新建会话隔离开。而一旦中间断开（比如关闭终端、网络中断），别急着从头再来，很多客户端支持查看历史会话列表，找到之前的会话恢复，继续未完成的对话。
我自己经常同时跑两三个会话：一个负责调研，一个负责实现功能，一个负责写文档。任务之间绝不交叉。这个习惯让 AI 在每个会话里的上下文都相对干净，准确率高很多。很多人觉得“开多个会话太乱”，其实乱的不是会话数，而是你让每个会话承担了太多无关职责。一个会话只干一件事，这是我一直坚持的用法。
5.4 这些细节为什么值得单独练
你可能觉得这些细节太琐碎，不值一提。但真正拉开使用效率差距的，往往就是这些“琐碎”之处。会打字只能保证你和 AI 能沟通，而熟练中断、恢复、切换会话，才能保证你在沟通失控时第一时间止损。会拆任务、会管理会话，才能让 AI 始终在一个干净的上下文里工作。这些能力不是学一个命令就会的，而是用一阵子之后自然总结出来的手感。我建议你把它们当成习惯去练，而不是当知识去记。
6. 把它们串起来：一次老项目接入的完整复盘
6.1 接入前：先跑 /init 和权限配置
前段时间我接手一个某内部数据同步项目，代码库用的技术栈不算新，文档也比较陈旧，现场唯一有价值的信息散落在几个核心目录里。按我现在的习惯，我没有直接给 AI 提需求，而是先跑了一遍/init。客户端扫描项目后生成了初版CLAUDE.md，里面把主要模块、目录用途、启动脚本等整理了出来。随后我花大约二十分钟人工精简：删掉它罗列的无关依赖，补充几个自动生成里缺失的“约定俗成”规则，比如代码风格、异常处理方式。
紧接着做了权限配置。我没有选择全放开，而是把读取操作设为自动允许，修改文件和执行命令保持询问。这步决定了后续几周的工作体验——AI 可以自由读代码、分析结构，但在任何可能改变项目内容的动作前都会和我确认。虽然多几次确认弹窗略有打断，但换来的是对改动的完全掌控，值得。
6.2 接入后：让 CLAUDE.md 成为项目说明书
精简后的CLAUDE.md成了这个项目所有对话的底子。接下去的对话里，我让 AI 分析数据同步的核心链路，它直接按档案里的目录结构定位到关键模块，省去了前期“翻代码猜结构”的大量时间。这是/init最值钱的地方：一次性把项目背景写进文件，之后每个新会话都自动带上背景，不再需要重复“我给你介绍一下这个项目”这种话。
我在这个项目里还发现了CLAUDE.md的另一个妙用：它可以当“项目日报”来维护。每完成一个重要决策，我就追加一两行结论。几天后再开启新会话时，AI 不仅能看懂代码，还能知道这几个模块为什么这么设计、哪些地方有已知坑。这相当于给 AI 装了一个长期更新的记忆库，每次重新开始对话都不必从零摸索。
6.3 翻车点复盘：一个误改配置的教训
这个项目也不是没翻过车。有一次调整同步参数时，AI 需要改动某个环境配置文件。因为我在权限里把“写文件”设成了询问，它弹窗问我是否允许修改，我那时正赶进度，点了“总是允许”。结果它不只改了目标配置，还顺手调整了同目录下另一个配置项的格式。当时没注意，直到第二天运行任务报错，排查了很久才发现是那个“附赠”改动导致的。
复盘之后，我收敛了那次授权，把权限恢复成按次询问。最大的教训是：永远不要在赶进度的时候图省事开放权限。一次偷懒，后续可能要花十倍的排查时间去填坑。权限弹窗看起来很烦，它其实是一道保险，每次点“总是允许”之前，都要想清楚这次特例会带来什么长期影响。
6.4 给三类使用者的命令清单
根据角色的不同，命令的使用侧重也有差异。如果你主要用 Claude Code 写代码、改代码，核心命令是/init、/clear、/compact和/permissions，优先练熟会话管理和权限控制。如果你的工作偏代码审查和项目分析，/status、/env、/model更常用，因为你需要掌控上下文长度、切换模型成本、排查环境差异。如果你是新手，建议从/help、/clear、/status开始，先学会看状态和止损，再逐步扩充其他命令。
最后分享一个小技巧。我现在几乎每个有长期价值的项目都会维护一份精简的CLAUDE.md，但并不是靠直觉写，而是每轮任务收尾时，问 AI 一句“今天我们做的哪些事值得写进项目档案”，让它来总结要点，我审核后追加进去。这样档案始终跟着项目演进，不用专门花时间维护，也不容易落后于代码变更。工具是用来伺候人的，不是反过来让人伺候工具的。内置命令也一样——少打字，多控制，把 AI 变成一个真正有分寸的搭档。
