Claude Code 斜杠命令完全指南：从聊天框到高效工作流的 12 个必备技巧

我先说一个真实的场景。前几天有个同事跟我吐槽说 Claude Code 越用越“笨”同一个需求前面还能一次改对到后面就开始反复横跳甚至漏掉关键文件。我过去瞄了一眼他的终端问他“你用过/compact吗”他愣了一下“这是什么我用 Claude Code 从来只打字。”这一下把我点醒了很多人嘴上在用 Claude Code实际上还停留在把它当成“长得像命令行的聊天框”的阶段。Claude Code 真正值钱的地方其实是从输入框里敲/之后展开的那一整套命令体系。这套斜杠命令相当于给 AI 预设了动作压缩上下文、初始化项目规则、代码审查、切换模型、导出对话……每一条都在解决一个你靠“自由对话”很难稳定完成的问题。这篇文章我就按使用场景把 12 个最容易被忽略、但实际帮我省了大量时间、金钱和头发的命令拆开讲透。适合刚上手想少走弯路的新手也适合已经用了一段时间但还停留在“打字对话”阶段的老手。1. 为什么我劝你别再把 Claude Code 当聊天框用1.1 聊天框式用法的三个隐形代价我见过太多人把 Claude Code 当 ChatGPT 的终端版在用敲一句需求等它输出一段代码再敲一句再等。这种用法不是不行但它会让整个工具的效率上限被锁死而且会悄悄付出三个代价。第一个代价是上下文膨胀。Claude Code 的每次对话都要把当前会话的历史记录一并发给模型。你前面讨论过的技术选型、它写过的代码、你纠正过的问题全都会累积在上下文里。聊到三四十轮之后模型开始“忘事儿”其实是正常现象——它没有忘是它的工作记忆里塞了太多杂物导致注意力被稀释输出质量自然崩。第二个代价是token 开销水涨船高。历史越长单轮请求的 token 成本就越高。你以为自己在正常聊天其实每一轮都在为前面的废话重复买单。第三个代价是行为不可控自由对话没有固定格式同一个需求换个问法输出风格和质量天差地别。而斜杠命令是确定性动作执行逻辑固定输出结构也固定这是自由对话给不了的东西。1.2 斜杠命令是 Claude Code 的“快捷键层”你会用图形界面软件一定知道“快捷键”的存在。菜单栏里的功能全部能用快捷键触发但没人会一个个去背。Claude Code 也一样对话只是它的最小交互单位斜杠命令才是为高频动作准备的快捷键层。在 Claude Code 输入框里敲一个/它会把当前版本支持的所有命令列出来。你可以把每个命令理解为一段预设好的“工作流”你不需要描述“请把我们的对话总结一下然后重新开始”你只需要敲/compact你不需要说“请以代码审查者的身份审阅一下当前工作区的改动”你只需要敲/review。命令把意图固定下来模型的发挥空间被框在一个合理的范围内质量和可预期性都大幅提升。1.3 先收下这张速查表下面这张表是我日常使用频率最高的 12 条命令。先记住“什么场景找什么命令”后文再逐个展开原理和细节。命令一句话用途建议使用时机/compact压缩上下文把长历史提炼成摘要会话变长、输出质量下降、想省钱/init初始化或更新项目规则CLAUDE.md新项目开局、项目结构大幅调整/add-dir把指定目录精准加入上下文仓库很大只想让 AI 看某个模块/clear清空当前会话上下文任务切换、项目切换、思路打结/review对当前代码改动做结构化审查提 PR 前、合并分支前/model在 Opus / Sonnet / Haiku 之间切换任务难度变化、需要控制成本/vim启用 Vim 键位编辑输入框习惯 Vim 键位的人/status查看上下文占用与任务状态感觉卡顿、摸不清进度时第一时间敲/doctor自检环境配置、登录态、连通性登录失败、配置异常、行为诡异/config打开配置面板调整参数改权限模式、模型偏好、自动压缩/resume恢复历史会话终端断开、换机器、想接着上次干/export把会话导出为 Markdown 文件写周报、存档排查过程、分享给同事你不需要一次性记全。但接下来的每一节我都建议你对照着用到自己日常里才能真正形成肌肉记忆。2. 上下文管理token 花得值不值就看这几条命令2.1 /compact上下文快爆炸时的“压缩饼干”/compact可能是这 12 条命令里价值最高的一条也是最容易被忽略的一条因为它的作用原理反直觉你以为对话越长 AI 越聪明实际上恰恰相反对话越长 AI 越容易被垃圾历史拖垮。执行/compact的时候Claude Code 会读取当前整段会话提炼出一份摘要然后清空原有历史用这份摘要作为新的对话起点。它相当于把一本写满涂鸦的草稿本换成一页干净的重点笔记。你不需要担心之前写进代码文件里的修改会丢磁盘上的改动是落盘的不依赖会话记忆。丢掉的只是对话中原有的“过程性信息”比如你说过的模糊描述、它给过但又被推翻的中间方案。什么时候该主动压我的判断标准很简单当你发现 Claude Code 开始不记得你自己说过的话或者一个改了好几次的问题又开始往老路子上走二话不说先/compact。还有更前置的判断法打开/status看上下文占用超过 70% 就主动压一次不要等它彻底卡死。另外有一个容易被忽略的配置项叫autoCompactEnabled可以在设置文件里打开{ autoCompactEnabled: true }打开了自动压缩之后Claude Code 会在接近上下文上限时尝试自己做压缩。但你千万别把自动压缩当成免死金牌它的触发时机偏保守等它动手时前面已经浪费了好几轮高成本的请求了。我的习惯是长会话里把主动/compact当作常规操作每完成一个子任务就评估一次是否该压。2.2 /init让 AI 长期记住项目规则如果说/compact管的是“短期记忆”那/init管的就是“长期记忆”。在全新的项目目录里执行/initClaude Code 会扫描项目结构、分析技术栈和代码组织方式然后在项目根目录生成一份CLAUDE.md。这份文件就是它的“项目入职手册”之后每次会话启动和对话过程中它都会参考这份说明来回答问题。很多人的误区是“跑过一次就完事”。实际做法应该是只要项目结构有大变化、技术栈有调整、团队规范有更新就再跑一次/init让它刷新记忆。你甚至可以直接手动维护这份文件把它当成给 AI 写的大纲。下面是一个精简示例# 项目说明 - 技术栈TypeScript React Vite - 包管理pnpm - 组件开发规范函数组件 Hooks禁止类组件 - 样式方案Tailwind CSS不要引入 CSS Modules - 接口请求统一走 src/api/client.ts禁止散落 fetch - 输出要求新增业务组件必须包含 loading 和 error 状态写规则时我踩过一个很实在的坑前后条款自相矛盾。我有一次在前面写了“优先函数组件”后面又写了“新页面必须用类组件”结果 AI 行为变得随机飘忽同一个需求这次给函数式方案下次给类式方案。CLAUDE.md 的条款必须互斥且明确否则它就会给模型埋下混乱的种子。新版 Claude Code 的/init还会生成.claude/skills之类的目录结构这是它向“项目级 Agent 配置”演进的方向。团队项目里把这套文件纳入版本管理每个人打开项目都能自动继承同一套 AI 行为规则这比口头约定靠谱得多。2.3 /add-dir精确指定 AI 的“阅读范围”很多仓库动辄几十上百个目录里面还有 node_modules、dist、build 这种一眼就不可能被关心的文件夹。如果你在对话里直接说“看一下 src/modules/order 目录”模型可能要自己猜该读哪些文件猜错就白折腾。/add-dir的价值在于它把指定目录显式注册进上下文告诉模型“这就是你这次工作的工作区相关文件从这里找”。这个命令对“省 token”的意义是实打实的。它不用把整个项目塞进上下文只把目标目录的入口和结构信息挂载进来后续按需读取具体文件。大型项目里效果尤其明显同样做一次订单模块的改动全量投喂可能几十分钟上下文就满了用/add-dir只挂src/modules/order能干到任务结束上下文还有富余。实际操作里我会配合/init一起用/init保证它懂项目全局规则/add-dir保证它聚焦在局部模块。它俩一个是“宏观视野”一个是“局部聚焦”组合起来正是省 token 又不丢精度的最佳姿势。2.4 /clear该换脑子时就换脑子/clear看起来太基础了基础到所有人都知道但恰恰因为它太简单很多人反而不把它当“高效命令”看。我观察到的情况是很多同事一个会话从早上聊到晚上需求一个接一个地塞进去AI 上一个任务的状态还没完全退出来就开始处理下一个任务两边互相污染。我的原则是“一个会话只干一件事”。上一个任务已经收尾下一个任务哪怕只是换个页面改样式也要先/clear。这个命令的作用是清空上下文给模型一个干净的工作记忆效果等同于让它“先忘掉上一件事”。别小看这一步很多你以为的“AI 变笨了”其实都是两个任务叠加导致的串味。那/clear和/compact的区别到底是什么我做了个小决策表直接照抄就行当前情况用哪条理由历史太长但主线任务还要继续/compact保留核心清除杂质任务不断一个任务彻底完成要开新任务/clear不残留上一任务的上下文对话已经来回漂移自己都接不回去/clear或/resume与其修补烂摊子不如重开干净局面有一个细节要特别注意/clear之前如果会话里有一些重要的中间结论比如某个排查过程的关键根因、某个临时决定的方案取舍先让它把这些结论写进文件或直接用章节里要讲的/export存下来。清空操作不可逆别指望回头还能捞出历史记忆。3. 代码工作流提效从“问一句答一句”到“批量干活”3.1 /review让 Claude 自己审自己的活我身边大部分人的“代码审查”姿势是这样的手动把文件复制进对话里然后写一句“帮我看看有没有问题”。且不说文件一长发出去就超长单说这种没有边界的提问模型根本不知道你要它审什么——是审逻辑审风格还是审性能所以输出往往泛泛而谈没有太多实际参考价值。/review把这件事流程化了。它默认基于当前工作区的 git 改动来定位审查范围执行后输出结构化的审查结论通常包含问题列表、风险等级和修改建议。不用你贴文件不用你描述范围只要改动在工作区里它自己就能找到。新版本 CLI 里这个命令叫/review老版本可能还叫/code-review。如果你的 claude 命令版本比较旧敲/review没反应先跑一下/update再试试。实操里我习惯把它和git diff串在一起这是我提 PR 前的固定动作 git diff /review先让改动进入模型视线再触发审查流程这样它既能结合 diff 又有一套固定审查逻辑比单纯丢文件可靠得多。另外注意一点审查前最好只保留和本次改动相关的文件别把一堆临时输出文件、配置备份文件也放在工作区里否则它会花大量 token 在无关改动上重点问题反而被稀释。3.2 /model按任务难度灵活调度模型Claude Code 底层可以调用不同规格的模型指令就是/model。默认配置通常用均衡型模型适合绝大多数开发场景。但你如果所有任务都跑默认模型等于把“重火力”和“轻任务”全部混在一起写一个 5 行的工具函数和设计一个跨模块的架构方案消耗的成本和资源却是一样的。我现在的调度策略大致是这样的架构设计、跨模块重构、疑难调试切换到最强模型 Opus。这类任务需要强推理能力多花点成本是值得的因为它能省下后续反复返工的时间。日常编码、按需求实现功能、修改现有逻辑跑默认均衡模型 Sonnet。覆盖绝大多数场景能力够用成本和速度都适中。批量改名、格式转换、补注释、写测试骨架直接降级到 Haiku。这些任务模式明确、难度低快是最重要的没必要让大模型来干。一个常见的疑问是切换模型会不会丢上下文实测下来不会。会话历史会被保留你可以中途任意切换模型只是换了对话仍然连贯。于是就有了一个很省钱的组合打法开场先用最强模型把设计思路理清楚然后切成均衡模型让它写实现到了明显机械化的收尾阶段再降级到轻量模型批量处理。同样一个需求token 费用可以差出好几倍。3.3 /vim给键位肌肉记忆留一条活路如果你是 Vim 用户这条命令属于“用过就回不去”的类型。Claude Code 默认的输入框是普通编辑模式但敲一下/vim之后整个输入框就切换成 Vim 键位i进入插入模式Esc回到普通模式dd删一行u撤销/搜索历史。凡是你脑子里存的 Vim 肌肉记忆全都能用上。很多人会忽略这条命令原因是它默认不开而且大多数人压根没想到会有人需要在终端输入框里用 Vim 键位。但对 Vim 党来说编辑一段长 prompt 的效率提升是非常明显的。你要是纯粹 VS Code 流用户这条可以跳过但这不妨碍它成为不少人的“隐藏快捷键”。3.4 /status在出问题之前先看一眼仪表盘/status是我每天敲得最多的诊断命令。它展示的是当前会话的健康度上下文占用比例、任务执行状态、相关耗时信息。你可以在会话一开始就敲一次建立基线也可以在任务过程中随时敲判断要不要主动/compact。我有一次印象特别深Claude Code 突然不按指令走了让它改 A 文件它偏去翻 B 文件指令好像完全失效。我第一反应不是骂模型“傻了”而是/status看了一眼上下文占用已经逼近极限。这就是问题根因——它脑子塞得太满接收新指令的余量已经所剩无几。接着一个/compact问题立刻恢复。这种“行为异常其实是上下文过载”的规律不跑/status很难第一时间定位。养成习惯每完成一个任务块敲一下/status心里对会话余量始终有数比等到崩了再排查省事得多。4. 环境诊断与团队协作出问题别急着重装4.1 /doctor先体检再排查很多人一遇到 Claude Code 行为诡异第一反应是“重装”或者“清缓存”。其实多数环境问题都可以用/doctor在几秒内定位。这个命令会对当前环境做一轮自检覆盖版本信息、登录状态、配置完整性、API 连通性等关键项。执行完会输出一份检查结果告诉你哪一块有问题。我自己的经历是有一段时间调用总是静默失败提示权限相关的问题但又没有明确报错来自哪一层。我当时以为是代码逻辑问题翻了一下午没结果。最后跑了一次/doctor才显示当前登录身份异常重新登录后立刻恢复。这种问题不跑/doctor根本不可能靠“猜”定位出来。从那以后我给自己立了个规矩凡是出现诡异现象先跑/doctor再做任何代码改动。这不是能力问题是排错顺序问题。4.2 /config用面板而不是手改文件配置 Claude Code 常见的方式是去改settings.json但如果你不熟悉它的配置结构手改文件容易把 JSON 写错而且改完还要重启才会生效。更友好的做法是直接在会话里执行/config它会打开一个配置面板权限模式、模型偏好、自动压缩、交互细节这些参数都可以可视化调整。配置本身是分层的理解这个分层能帮你少踩很多坑用户级配置~/.claude/settings.json对你机器上的所有项目生效。项目级配置.claude/settings.json只对当前项目生效适合团队统一行为规范。项目级配置会覆盖用户级配置。这也是一个常见坑你在个人全局配置里改了某个权限策略但项目里如果存在一份项目级配置很可能把你全局的配置顶掉。所以遇到“怎么改都不生效”的情况先检查项目目录下有没有一份团队级的settings.json。4.3 /resume换机器、断终端都能无缝接上用 Claude Code 干活最怕的就是干到一半终端断了尤其是我这种经常远程连服务器的人。好在它的会话记录是持久化的不需要你手动保存什么。命令行直接恢复claude --continue这是恢复最近一次会话。如果你想选择性恢复历史会话claude --resume它会列出历史会话列表挑一个进去接着聊。更顺手的是--continue后面可以直接跟新指令claude --continue 接着改刚才的接口这次把参数校验补上我前阵子远程跑代码就在终端里跟 Claude Code 聊到关键步骤结果网络一断整个人懵了。重连之后抱着试试的心态敲了claude --continue它真的把上次的上下文接了回来连之前讨论到一半的方案都能继续。这个命令救过我好几次。不过有一点要注意resume恢复的是会话记忆不保证代码分支和工作区状态也跟着恢复。如果你恢复会话之前还没提交代码先确认当前分支对不对别在错误版本上继续往下写。4.4 /export把会话变成团队知识资产Claude Code 的会话记录如果不主动保留关掉终端就等于没了。但很多时候你花了两三个小时排查一个棘手问题这个排查链路本身有极高的分享价值。/export干的就是这件事把当前会话整理成 Markdown 导出。执行/export之后Claude Code 会将会话内容按结构导出为可读的 Markdown 文件你可以选择保存路径。这个导出文件里包含你每一步的指令、它每一步的输出相当于一份完整的排障回放。我通常的用法是周末复盘时导出整周的关键会话提炼成自己的问题案例库排查完一个难搞的问题后导出贴到内部知识库配合简单的二次总结供团队其他人直接参考需要给同事同步一个复杂上下文时不靠口述直接丢一份导出文件过去。导出后的文件信息密度很高如果只是给同事参考建议在导出基础上再写两三句总结而不是原样扔过去。它最合适的定位是“素材底稿”不是“成品文档”。5. 把命令串起来我日常最顺手的几个组合用法5.1 新任务的标准开局我接手一个新项目或一个新需求时第一组命令永远是 /init /clear # 然后开始描述任务/init先确保项目规则文件存在且最新让 AI 拿到“入职手册”紧接着/clear把生成和扫描规则过程产生的冗余对话清掉确保正式任务的上下文从干净状态开始。顺序不能反先init再clear如果先清空再 init扫描过程又会产生新的杂质。已经有 CLAUDE.md 的存量项目直接检查文件是否过期过期就重新跑一次/init。5.2 合代码前的“三道闸”每次准备提交代码或提 PR 之前我基本固定走一遍这个流程 /status git diff /review /export/status检查上下文余量如果快满了先压一次git diff把改动喂给模型/review触发结构化审查审查结论满意之后/export把审查记录存成文件修改建议逐条对照修改。这四步走下来改完直接提 PR心里踏实很多。审查记录留着也是好东西后续如果要跟人解释“为什么这里这样改”直接翻导出文件就行。5.3 长会话的“保命三部曲”遇到一个大需求必须在一个会话里连续干好几个小时的时候我的节奏是这么控制的主动/compact不要等自动压缩兜底每完成一个模块就判断一次上下文是否该压用/resume拆会话大任务按里程碑拆成多段每完成一段就/export存档然后/clear下一次用claude --continue接着推进全程靠/status巡检每次准备切换子任务前先看一眼健康度。这样做的收益很直观每次会话的上下文范围可控模型不会因为塞了太多历史而“精神涣散”成本也被压在一个可预期的范围里。你以为多开几个会话会麻烦实际上反而比“一个会话硬撑到底”更稳、更省钱。5.4 关于这 12 条命令最后几句大实话不要试图一次全背下来。命令这东西背下来没用用熟了才是你的。我最建议你先从三条开始/compact、/init、/status。这三条解决的是“上下文失控”这个最普遍也最致命的问题几乎每个深度用户都会遇到。等你把这三条练成肌肉记忆再慢慢把/model、/review、/resume加进日常流程。我自己用下来的体会是Claude Code 的真正分水岭不是你用的模型多强、配置多花哨而是你有没有建立一套稳定的“命令使用节奏”。聊天框式的用法上限很低斜杠命令才是把这个工具从“能聊”推向“能用、好用、省着用”的关键一层。希望这篇整理能让你少走一些我走过的弯路。