Claude Code斜杠命令实战：从内置指令到自定义高效工作流

最近在折腾 Claude Code 的时候我发现很多刚接触它的朋友都卡在一个很基础的环节上虽然能跑起来但总感觉用得不顺每次都要反复敲同样的话或者频繁手动确认效率非常低。其实 Claude Code 真正拉开体验差距的地方不是模型本身而是它那一套斜杠命令系统也就是 Slash Commands。这玩意儿说简单点就是把“你平时反复输入的一大段指令”压缩成几个字符同时它还能自己携带参数、多行提示词、甚至绑定到某个流程上。第 8 章的内容正好就是围绕这个主题展开的也是我玩了一个多月后觉得最值得深挖的部分。先说结论如果你只用/clear和/help那等于没真正用上 Claude Code。Slash Commands 不光是内置的那几个快捷方式更厉害的是你可以在项目里自定义自己的命令把团队的代码规范、commit 风格、Review 清单全部变成一条命令让 AI 每次都以同样的标准执行。这篇文章我会把内置命令、自定义命令的写法、参数传递的坑、以及和 DeepSeek 等不同模型 API 搭配时的注意事项全部过一遍适合所有已经在用 Claude Code、或者正准备装好它的朋友。1. 为什么 Slash Commands 是 Claude Code 的“快捷键中枢”1.1 从新手困惑说起我第一次用 Claude Code 的时候其实是在终端里跑了个claude命令然后进到一个交互式界面里。说实话第一印象并不惊艳它看起来就是一个能聊天的命令行工具我输入文字它输出结果。但真正让我觉得“这东西不一样”的瞬间是我发现它支持一堆以/开头的命令而且这些命令不是摆设而是真正能改变 AI 行为的。比如说/compact可以压缩上下文/review可以让我快速过一遍代码 diff/init能扫描项目结构并生成 CLAUDE.md 文件。这些命令看起来简单但背后改变的其实是整条工作流。这里插一句新手常见的问题很多人装完 Claude Code 之后在 PowerShell 里执行安装命令结果报错iex 所在位置 行:1大概率是执行策略限制不是工具本身的问题。我当时的处理办法是先用Get-ExecutionPolicy看了一眼发现是Restricted然后临时改成RemoteSigned再跑安装命令装完后再改回来。这种琐碎的小问题特别容易劝退新手但其实跟后面的命令系统无关你只要把环境跑通剩下的才能真正体会到什么叫“效率”。1.2 Slash Commands 到底解决什么问题如果我们把 Claude Code 当成一个“能操作你代码库的 AI 助手”那 Slash Commands 就是给这个助手预置的指令模板。没有这些命令时你需要把需求描述得非常具体比如“请你先看一下 src 目录下的改动然后按照我们团队的规范帮我生成一个符合 Conventional Commits 的 commit message注意 scope 要写到模块名”。有了命令之后你只需要输入/commit它就会自动按你事先定义好的格式执行。所以它解决的核心问题是三个第一减少重复输入把高频操作变成肌肉记忆第二统一 AI 的输出标准避免每次生成的内容风格飘忽第三把复杂的、多步骤的提示词封装成可复用的“函数”让协作中的每个人都用同一个按钮。这一点在实际项目中特别重要。以前我们团队让 AI 做代码审查每个人写出来的提示词五花八门出来的结果也千奇百怪。后来我把/review命令做成了统一模板里面规定了检查优先级、输出格式、风险等级标准整个团队的 Review 质量一下就稳了。2. 内置命令逐个拆解2.1 会话控制类/clear、/compact、/stop内置命令里我使用频率最高的是/clear、/compact和/stop。/clear的作用是清空当前会话的上下文让 AI “忘掉”之前聊过的内容。这个命令看似简单但有个细节很多人不知道/clear之后当前会话仍然保留在同一个交互进程里只是上下文被清掉了。如果你在做一次长任务比如连续改了十几个文件上下文很容易被塞满这时候直接用/clear会丢失之前的任务背景更稳妥的做法是先确认关键信息已经写入文件再执行/clear。/compact则是另一种思路它会先把当前对话压缩成一份摘要然后在此基础上继续而不是彻底清空。我用它最多的场景是一个功能从设计聊到实现聊了非常久中间有很多和当前目标无关的试错内容我会执行一下/compact把无关内容过滤掉保留核心结论这样后面的响应速度会明显变快也不会因为上下文溢出而突然“失忆”。/stop更偏向于“刹车”。当 AI 在生成代码的过程中方向偏了或者你发现自己给的指令本身就是错的直接按 Esc 或者输入/stop让它停下来比等它跑完再去纠正要省时间得多。我一直觉得能不能熟练使用/stop是判断一个人有没有真正掌控 AI 的标志新手往往不好意思打断结果浪费了大量 token。2.2 上下文与编辑类/init、/model、/config/init是另一个我非常推荐上来就执行的命令。它做的事情是扫描项目的目录结构、读取关键配置文件、理解当前技术栈然后生成一个CLAUDE.md文件。这个文件相当于给 AI 的“项目说明书”里面写清楚了这个项目是什么、用的什么框架、目录怎么组织、有没有特殊约定。后续每次会话开始Claude Code 会自动读取这个文件AI 对项目的理解会准确很多。如果你感觉 AI 经常答非所问先检查一下项目根目录有没有CLAUDE.md没有就赶紧跑/init。/model是用来切换模型或调模型参数的。默认情况下的入口可能需要你按 Tab 或 ShiftTab 切到某个模式但用/model可以更直接地查看和切换。我在同时接入了多套 API 的时候特别依赖这个。比如我本地有一个主用的官方模型另外接了一个 DeepSeek 的 API 作为备选Sonnet 模型负责写代码Haiku 模型负责快速摘要通过/model我能在会话中间直接切不用重启进程。/config是用来打开配置界面或者查看配置文件的。很多操作系统层面的偏好比如是否自动接受工具调用、最大思考轮数、权限策略都藏在配置里。我习惯把自动确认相关的选项单独看一遍因为默认情况下 Claude Code 执行一些操作时会频繁询问“是否允许”如果项目是临时测试可以把确认级别调低一点体验会流畅很多如果是正式仓库建议保持严格防止 AI 误操作。2.3 调试排查类/help、/status、/doctor/help是内置命令里最容易被忽略的一个。大多数人以为它只是显示命令列表但其实你在命令后面加上参数还能看到具体某个命令的用法。比如输入/help custom就能看到跟自定义命令相关的文档输入/help slash能看到斜杠命令的语法详情。这比去翻在线文档快多了而且版本更新后文档也会同步更新不会出现“网上教程跟本地版本对不上”的情况。/status能查看当前会话的状态比如上下文占用情况、当前使用的模型、API 调用是否正常。它对于那些用 API 接入的朋友来说是排查问题的重要起点。我遇到过一种情况命令执行到一半突然没反应输入任何内容都不回复。用/status一看发现是上下文占用已经接近上限于是执行/compact解决问题。/doctor是环境自检工具如果 Claude Code 某个功能坏了比如权限不对、临时目录失效、某个依赖缺失它会给出诊断信息。这个命令在官方文档里提到得不多但实际运维场景里很好用。我每次升级完又遇到莫名奇妙的报错第一件事就是跑/doctor把输出贴给 AI 让它分析基本能定位到大多数环境问题。3. 自定义 Slash Commands 的完整写法3.1 目录结构与基础格式自定义 Slash Commands 是这一章的重头戏。先明确一个概念它本质上就是一个 Markdown 文件放在项目的.claude/commands/目录下文件名就是命令名。比如你创建一个.claude/commands/commit.md那么在 Claude Code 对话界面里输入/commit就能触发这个命令。非常简单直接不需要写任何插件代码不需要注册也不用重启。文件内容有固定的结构最核心的是 frontmatter 和主体提示词。frontmatter 用 YAML 格式写放在文件最上方用---包裹起来。里面可以定义命令的描述、参数、是否需要用户确认等信息。主体部分就是普通的 Markdown 文本里面可以写命令的具体要求、步骤、示例甚至可以包含变量引用。Claude Code 在执行命令时会把主体内容作为用户消息的一部分发送给模型。下面是一个最简单的自定义命令示例假设我想让 AI 帮我把所有 TODO 注释整理成一份清单--- description: 扫描项目中的 TODO 注释并生成清单 --- 请扫描当前项目中的所有代码文件找出所有包含 TODO、FIXME、HACK 的注释。 按模块分类列出并标注文件名和行号。 最后输出一份 Markdown 格式的 TODO 清单放在 docs/todo.md 中。注意description会在你输入/时的命令提示列表里显示所以尽量写得直白点。这个文件本身不需要加claude之类的块因为整个文件就是提示词本身。我第一次写的时候老想给它包一层代码块导致命令一直不生效后来才意识到设计理念就是“文件即提示词”。3.2 参数传递与多行命令实战如果只是写固定文本那 Slash Commands 还不够强大。真正厉害的是参数传递。你可以在 frontmatter 里用argument-hint或allowed-tools等字段来定义参数但更常用的是在提示词主体里引用$ARGUMENTS这个变量。举个例子我经常需要让 AI 针对指定文件做代码审查于是写了一个.claude/commands/review.md--- description: 对指定文件或目录进行代码审查 argument-hint: [文件路径或模块名] --- 请对路径为 $ARGUMENTS 的代码进行仔细审查。 审查要点 - 是否存在明显的 bug 和边界条件遗漏 - 是否有安全隐患SQL 注入、XSS、敏感信息硬编码 - 是否遵循当前项目的代码规范 - 是否缺少必要的错误处理 输出要求 1. 按严重程度从高到低列出问题 2. 每个问题给出具体行号和修改建议 3. 如果没有发现问题请明确说明“未发现高危问题”这样我在对话框里输入/review src/utils/date.tsAI 就会自动把我传入的src/utils/date.ts替换到$ARGUMENTS的位置。这里有一个小细节$ARGUMENTS捕获的是输入命令后剩余的全部文本所以你如果想传多个参数可以自己约定分隔符比如/review src/A src/B然后在提示词里写“把 $ARGUMENTS 按空格拆分分别处理”。或者你也可以自定义更复杂的参数名称。多行命令的意思不是“命令跨多行输入”而是指命令执行后产生的提示词包含多个步骤。这是通过主体 Markdown 的多级列表来实现的。我建议所有自定义命令都写成“第一步做什么第二步做什么最后输出什么”的结构模型执行起来会更稳定。如果只是一句孤零零的话模型往往会自由发挥达不到预期。3.3 用 Slash Commands 固化团队工程规范我之所以觉得自定义 Slash Commands 的价值被严重低估是因为它特别适合承载工程规范。工程规范这种东西写在文档里没人看靠人肉记根本记不住。但如果把它做成命令AI 每次都会按同样的标准执行久而久之整个代码库的质量风格会高度统一。举一个例子。我们团队用 Conventional Commits但每个人写的 commit message 风格都不一样。有的喜欢加 emoji有的喜欢把 subject 写得又长又啰嗦有的 scope 写模块名有的 scope 写版本号。后来我建了一个.claude/commands/commit.md--- description: 生成符合 Conventional Commits 规范的提交信息 --- 请根据当前 git diff 生成 commit message。 要求 - 使用 Conventional Commits 格式type(scope): subject - type 只能是 feat、fix、docs、style、refactor、perf、test、build、ci、chore 之一 - scope 使用具体的模块名例如 api、ui、utils不要使用版本号 - subject 不超过 50 个字符使用祈使句不要大写开头 - 主体部分列出关键改动点控制在 3 条以内这样每次执行/commitAI 生成的提交信息都符合规范。更重要的是团队成员不需要在脑子里背规范只需要敲/commitAI 就变成了一位“装了规范插件的代码助手”。同一原理也可以用于 RPC 接口设计评审、重构前的改动清单、发布前的自检清单等。把这些固定的质量门禁做成命令就是在给团队增加一套可执行的知识库而不是停留在 README 里的空话。4. 日常使用的几个高频场景4.1 代码审查代码审查是我用得最多的场景。之前我写的/review已经覆盖了单个文件的审查但实际项目里更常见的是审查整个分支的改动也就是 diff review。我后来扩展了一个.claude/commands/review-diff.md命令主体要求 AI 先运行git diff获取改动内容再结合项目上下文逐文件分析。这里有一个很关键的提示词写法不要只说“帮我看看改了什么”而要给模型设定一个“审查者视角”。我会在命令里明确写“假设你是这个项目的高级工程师你需要对这个改动提出必须修改项和可选建议项”。这样模型输出的结果更像真正的 Code Review而不是简单的代码摘要。我测过很多次有没有这段角色设定输出质量差距非常大。另外审查时一定要让 AI 关注“不在 diff 里”的东西。比如某个函数改了但它影响到的调用方有没有同步改公共变量改了有没有留下没用的导入这些语义层面的问题 AI 能发现但需要你在命令里提示它。所以我通常会在命令里加一句“除了 diff 本身还要检查变更是否破坏了其他模块的约定。”4.2 生成提交信息与清理临时文件除了 commit message我还会用命令来清理项目里的临时产物。Claude Code 在自动执行任务时会产生一些临时文件或修改虽然大部分会自动清理但偶尔会有残留。我写了一个/cleanup命令让它扫描项目找出备份文件、日志文件、调试输出等并列出清单让我确认后删除。这样做的好处是安全AI 不会直接暴力删除而是先给清单。对于容易误操作的文件类型比如.bak、.log、*.tmp我会在命令里明确排除某些目录比如node_modules和.git不能动避免 AI 帮倒忙。git worktree多工作区协作时我也习惯让 AI 帮忙同步分支状态。比如执行/sync命令AI 会自动检查当前分支是否有未推送的提交、远端是否有更新、有没有需要 stash 的内容然后分步执行。这个命令本质上就是一系列git status、git log、git pull --rebase的组合但封装成命令之后我可以避免每次手敲长短命令而且 AI 会基于输出来决定下一步动作比我无脑输入安全得多。4.3 子代理与复杂任务编排Claude Code 里还有一个和 Slash Commands 配合得很好的功能就是子代理sub-agent。热词里有人问“怎么创建子 agent”其实就是用Task工具在一个大的任务里派生出一个小任务给另一个模型实例去执行。而 Slash Commands 可以成为触发这种编排的入口。举个例子。我处理一个跨前后端的大需求时会定义一个/fullstack-task命令命令主体里包含“先拆分任务后端部分交给子代理 A 完成前端部分交给子代理 B 完成最后合并结果并检查集成问题”。这样通过一个斜杠命令就把整个工作流驱动起来了。子代理的粒度不用太细否则 token 消耗会很夸张我习惯只在真正需要隔离上下文时使用。用 Slash Commands 做入口的好处是团队成员不需要理解 Task 工具的细节只需要知道“跑这个命令就能拿到结果”。这里顺带提一下网上有人纠结“codex 和 claudecode 哪个好”我个人的看法是它们的模型能力各有千秋但 Claude Code 的 Slash Commands 自定义体系确实让它在工程化落地时更有优势。Codex 也有一套自己的指令方式但 Slash Commands 的 Markdown 即配置的设计门槛更低更好维护。你把命令文件放进 git 仓库整个团队就共享了。5. 常见问题与排查技巧实录5.1 命令不生效、路径错误自定义命令不生效最常见的原因有三个文件名拼写错误、文件放错目录、frontmatter 格式不对。.claude/commands/这个目录必须放在“当前工作目录”的根下如果你在一个子目录里启动 Claude Code它默认看到的项目根可能不是你预期的。我建议在项目根目录启动claude这样路径不容易乱。frontmatter 格式错误也经常发生尤其是 YAML 里冒号后面必须有空格否则解析失败。我踩过一次坑description: 生成提交信息写成了description:生成提交信息命令根本识别不出来。这种问题不会报错只是命令不出现在提示列表里非常隐蔽。排查时可以先输入/看看列表里有没有你刚建的命令如果不在优先检查 frontmatter。还有就是 Windows 系统下的文件名大小写问题。Commit.md和commit.md在有些文件系统里是同一个文件但命令调用时可能区分大小写。为了避免歧义我统一用小写加横线命名比如review-diff.md、cleanup-logs.md。5.2 动态参数中的坑$ARGUMENTS这个变量虽然好用但有几个坑值得注意。第一如果参数包含特殊字符比如引号、$、反引号可能会被 shell 解释掉导致传入的值不完整。我一般建议用户在命令里使用参数时尽量传相对路径不要传带空格的复杂字符串。如果真需要传多词参数可以夹在引号里但最好在命令主体里让 AI 忽略引号本身。第二$ARGUMENTS在提示词中只能出现一次还是多次我实测过可以出现多次模型会把它替换成同一个值。但你最好不要在一句话里塞很多次容易让模型产生混淆。我更推荐的做法是先用一句话明确定义参数含义再在后续步骤中引用。第三如果命令主体里需要用到字面上的$字符比如让 AI 生成 shell 脚本那要小心。因为$ARGUMENTS是被 Claude Code 替换的其他的$会不会被解释取决于版本。稳妥的做法是不要在自定义命令主体里直接写包含$的敏感代码或者先用文字描述让 AI 生成而不是直接写在命令里。5.3 和 DeepSeek 等模型 API 搭配要注意的事现在很多人通过环境变量或配置文件把 Claude Code 接到 DeepSeek、通义千问等模型 API 上。这种玩法能降低使用成本但 Slash Commands 的表现可能和官方模型不完全一样。最明显的差异是“指令遵循能力”。Slash Commands 本质上是一段提示词模型能力越强执行效果越稳定。如果你发现某个命令在官方模型上表现得很好但换成 DeepSeek 后频繁偏离要求不要急着改命令先检查模型本身的系统提示词是否覆盖了工具调用规则。我的经验是把命令拆得更细、步骤更明确能显著提升在非官方模型上的表现。官方模型可以接受“请看一下项目结构”这种模糊指令但换成其他模型时最好明确到“先运行find . -type f -name *.py读取其中 3 个核心文件再总结”。这就是为什么你会看到很多“deepseek api 接入 claudecode 教程”里反复强调提示词要结构化本质是模型指令遵循能力差异带来的。另外不同 API 的工具调用格式可能不一样执行 Slash Commands 时如果遇到“工具调用失败”的提示先确认 API 有没有完整支持 Claude Code 所需的工具协议。我遇到过一次某个 API 能正常聊天但执行/init时报错排查半天发现是工具调用接口不兼容。这种问题不是 Slash Commands 本身的锅而是模型服务端能力限制。5.4 Windows 下 .exe 失效与“一直点确认”的问题热词里有人提到“每次使用完 .exe 就失效”这个问题我也遇到过。Claude Code 在 Windows 上安装后可执行文件路径偶尔会因为环境变量或权限问题找不到。一个笨但有效的办法是不要反复重新安装先用/doctor检查环境看可执行文件是否在预期路径。如果每次都失效多半是系统临时目录被清理或安装路径被安全软件拦截。把安装路径加到白名单或者换一个稳定目录比反复重装靠谱。还有一个被问得非常多的问题“claudecode 如何不用一直点确认”。这里的确认指 Claude Code 执行写文件、运行命令前会弹出许可确认。要减少这种确认可以在配置里调整权限策略把信任的项目目录设为完整可执行。但我要强烈建议不要在正式仓库里完全关闭确认。AI 的执行力越强误操作的风险也越大。我在个人实验项目里会把确认关掉一部分在团队协作项目里一定保持严格这个平衡要自己把握。6. 用 Slash Commands 整理自己的工作流6.1 从零开始构建自己的命令库如果你准备开始给自己的项目搭建一套 Slash Commands我建议分三步走。第一步先列出你过去一周在 Claude Code 里反复输入过 3 遍以上的提示词这些就是最值得做成命令的候选。第二步从最简单的固定模板开始做一个不需要参数的版本跑通后再加上$ARGUMENTS动态参数。第三步把命令文件纳入版本管理和团队一起维护。我自己的.claude/commands/目录现在已经有不少文件了但不是一蹴而就的。我建得最早的是/commit用了一周后又加了/review然后是/generate-doc、/refactor、/test-generator。每加一个命令我都会在真实任务里试几次不满意就改提示词改到输出稳定为止。这个过程比想象中花时间但收益很大因为每次改都是对“AI 协作方式”的一次打磨。6.2 命令与记忆文件配合使用Slash Commands 不是孤立的它最好和 CLAUDE.md 记忆文件配合。比如我在 CLAUDE.md 里写了“项目禁止使用某个依赖”那么在/review执行时AI 也会读到这个约定审查结果会更加准确。命令负责“怎么做”记忆文件负责“知什么”两者缺一不可。我甚至会在某些自定义命令的提示词里写“先读取 CLAUDE.md再开始执行”。虽然 Claude Code 默认会加载这份文件但显式提一句能让模型在长时间对话里更重视它。特别是在使用其他模型的 API 时显式引用比依赖默认行为可靠得多。6.3 关于命令颗粒度的一点心得最后想聊聊命令的颗粒度。刚开始我容易犯一个错误把一个大而全的流程写进一个命令里结果命令又长又复杂模型执行到后面经常丢失前面步骤。后来我学乖了会按“原子操作”来拆。比如“生成单测”和“运行单测并修复失败”是两个命令不要并成一个。“审查当前改动”和“根据审查意见修改代码”也分开。这样每个命令的目标单一模型执行起来更稳定也更容易定位问题。拆细之后还有一个好处你能复用这些原子命令组合出更复杂的流程。我常在一个任务里先跑/review-diff根据输出再跑/fix-issues而不是让一个命令从头做到尾。虽然多敲几次命令但每一步的产出都在我的掌控之内token 消耗反而更可控。这个思路我觉得跟写代码很像函数越短越容易测试和复用。总的来说Slash Commands 是 Claude Code 里性价比很高的一个功能。它不仅让高频操作变快更重要的是把“人怎么跟 AI 协作”这件事沉淀成了文件可以分享、可以迭代、可以随着项目一起成长。如果你现在还在把 Claude Code 当普通聊天窗口用我建议你从今天开始建一个自己的.claude/commands/目录把你最常说的那句话变成一个斜杠命令。用上一周你会回来感谢这个决定的。