从折腾 Claude Code 到现在，我几乎把大部分时间花在琢磨它的效率工具上，而 Slash Commands 是我觉得投入产出比最高的一个模块。刚开始用的时候，我也只是图个新鲜，输入/看到一串内置命令，觉得挺方便，但真正深入了解之后才发现，这套斜杠命令系统其实是可以被完全自定义的工作流引擎。尤其是当你在一个多模块项目里反复切换角色、需要频繁给模型交代固定背景时，自定义斜杠命令的价值就会成倍放大。
这篇内容围绕着 Claude Code 的 Slash Commands 展开，重点解决这几个问题：它到底是什么、内置命令分别能干什么、怎么自己做一套符合团队习惯的自定义命令、以及我在实际使用中踩过的坑和对这个机制的思考。不管你是刚装好 Claude Code 没多久的新手，还是已经写了一段时间自定义命令的老手，这篇文章应该都能给你一点参考。
1. 先理解 Slash Commands 的设计思路，再谈用法
1.1 一句话说清斜杠命令的定位
Slash Commands 本质上就是一套以/开头的快捷键协议，作用的对象是 Claude 的对话上下文和运行环境。你可以把它理解成给模型预置的一批“话术模板”，也可以把它看成是给命令行终端加的一层快捷宏。它和普通 prompt 的核心区别在于：斜杠命令不只是输入一句话，而是会被 Claude Code 解析成系统指令、上下文片段、参数占位符和工具调用权限的组合，从而触发一个预先定义好的完整行为。
比如说，当你输入/review时，模型会立即切换到代码审查模式，自动读取当前工作区的代码变更范围，然后按照内置的审查维度输出结果。这个过程背后关联了多条系统指令和上下文规则，并不是单纯在会话框里多打几个字就能复现的。这也是为什么我建议所有认真使用 Claude Code 的人都去研究一下斜杠命令——它把“临时起意”和“标准化动作”做了很好的区隔。
1.2 为什么有人觉得 Slash Commands 不够好用
网上偶尔能看到有人说斜杠命令“鸡肋”，我一开始也差点这么认为。但这个印象多半来自对自定义机制的不了解。Claude Code 内置的斜杠命令覆盖面已经比较广，从清理会话、查看成本到切换模型都有对应入口；然而面对一些具体场景时，内置命令往往不够精准。
举个例子，我经常需要让模型以“代码评审委员会”的身份，针对某个指定目录的改动做严格审查，并且输出格式要符合团队评审单的模板。这种需求用内置命令无法一次完成，但如果创建一个自定义命令，把所有背景、角色设定、输出格式、审查维度都写进模板，那就变成一个固定动作了。所以，Slash Commands 的真正价值不在于内置了哪些功能，而在于你能不能基于它搭出自己的工作流。想明白这一点，你再回看那些“不好用”的说法，多半是因为还没有进入自定义这个层面。
1.3 斜杠命令和普通 Prompt 的本质差别
我从三个维度给你对比一下：
- 确定性：普通 Prompt 的效果受措辞影响比较大，同一个意思换个说法，模型输出的结构可能完全不同。而斜杠命令背后的模板是固定的，不管你什么时候调用，它给模型注入的上下文基本一致，输出质量更可控。
- 上下文效率：长项目里，每次都把角色设定、目录结构、输出要求重新输入一遍，既浪费 tokens 又容易遗漏关键信息。斜杠命令把整段背景压缩成一个短指令，可以显著降低上下文混乱的概率。
- 复用性：Prompt 散落在历史会话里，今天写明天就找不到了。斜杠命令以文件形式落地，可以和团队共享，也可以跨项目复用。这一点在多人协作时尤其明显。
2. 内置斜杠命令全拆解：哪些该用，哪些该配合自定义
2.1 会话清理类：/clear、/compact 的使用时机
内置命令里，/clear和/compact是我几乎每天都会碰到的。/clear的作用是清空当前回话的对话历史，让模型从“失忆”状态重新开始。它适合在确认当前上下文已经没参考价值时使用。但我要提醒一句：不要频繁用/clear。如果对话里还有一些关键决策记录，清掉之后可能需要重新让模型读一遍文件才能恢复上下文，反而更费时间。
/compact则是自动压缩上下文而非彻底清空。执行后，Claude 会把当前对话里比较重要的信息精简成一段摘要，然后继续保留在上下文中。我在长会话、多文件修改的场景下，只要有上下文变慢的感觉，就会优先用/compact而不是/clear。两者看起来都是“重置”，但使用逻辑完全不同：/clear偏向推翻重来，/compact偏向精简续跑。
2.2 配置与管理类：/config、/memory、/cost 的实际功效
/config是打开 Claude Code 配置设置的总入口，可以调整各类行为参数，包括模型选择、权限设置、主题偏好等。它适合做全局性的环境调整。如果你想看当前会话已经花了多少钱，用/cost是最直观的。这个命令尤其适合负责项目预算的开发者，做完一个大功能之后顺手看一眼成本，心里有数。
/memory在我眼里是内置命令里被低估的一个。它负责管理 Claude 的长期记忆规则，你可以通过它查看、添加或删除一些全局性的行为约束。比如我给自己全局设了一条规则：“所有生成代码必须包含必要的类型注释”，这样在任何项目里模型都会默认遵守。这个机制和自定义斜杠命令的配合度很高，后面我会说到为什么。
2.3 工作流转类：/model、/new、/review、/status 的场景选择
内置命令里还覆盖了会话流转的不少场景。/model可以在不退出会话的情况下切换模型类型，我用它来临时换用成本更低的模型处理批量文件或简单重构。/new则相当于开启一个全新的会话，适合在访谈思路卡住或者任务边界发生重大变化时使用。
/review是代码审查命令，它会让模型基于当前代码变更生成审查意见。个人建议把它作为提交前的一层辅助检查，不要当成完整的评审流程。/status可以查看当前会话的状态信息，比如是否处于多步骤任务中、工具使用情况等。这组命令单独看都很直接，但如果能和自定义命令组合起来用，威力会高好几个级别。
为了让你快速对照，我把内置高频命令的用途整理成了一个小表：
| 命令 | 核心用途 | 适合场景 |
|---|---|---|
/clear | 清空会话历史 | 任务边界清晰，不需要旧上下文 |
/compact | 压缩上下文 | 长会话、上下文过长但还想续跑 |
/config | 打开配置入口 | 调整模型、权限、偏好 |
/memory | 查看/编辑全局记忆规则 | 想要全局行为约束 |
/cost | 查看会话费用 | 预算把控、成本结算 |
/model | 切换模型 | 临时换低成本模型处理批量任务 |
/new | 开启新会话 | 彻底转换任务方向 |
/review | 代码审查 | 提交前辅助检查 |
/status | 会话状态查看 | 多步骤执行遇阻时诊断 |
3. 自定义 Slash Commands 的完整实操
3.1 目录结构、最小示例与命名规则
自定义命令的存放目录是项目根目录下的.claude/commands/。你也可以放在用户级的~/.claude/commands/，区别在于项目级命令只对当前项目生效，用户级命令对所有项目生效。文件格式是 Markdown，一个文件对应一个命令，文件名去掉.md后缀就是命令名。比如说你建了.claude/commands/code-review.md，那么在对话里输入/code-review就能触发它。
我建议从最小示例开始理解。建一个hello.md，内容只要写一段普通 prompt，比如：
请针对当前项目的整体结构做一个简短说明，包括职责划分和潜在风险点。然后输入/hello，模型就会执行这个指令。这个例子虽然简单，但说明了自定义命令的基本原理：文件里的内容会被当作系统级 prompt 注入到当前上下文中。注意，自定义命令不是独立的程序，它本质上是 prompt 的“文件化容器”，理解这一点你后面设计命令时就不会跑偏。
3.2 使用 Front Matter 给命令加上元信息
如果文件里只有 prompt 文本，功能还是太单薄。Claude Code 支持在 Markdown 文件开头添加 YAML 格式的 front matter，用来描述命令的元信息。我通常会在每个命令文件头部写上类似这样的内容：
--- description: 按团队规范对最近改动进行代码审查 argument-hint: [可选参数说明] allowed-tools: Read, Grep, Glob model: sonnet ---description会让命令在/提示列表中显示说明文字，方便快速识别。argument-hint用来提示调用者需要输入的参数格式，比如[目录名]，能减少误用。allowed-tools限制了这条命令运行时可以使用的工具集合，对提升执行安全性很有帮助。model可以指定该命令默认使用的模型，适合重型任务和轻量任务分开跑的团队。
我举个例子：如果一条命令是为了做数据库迁移检查，那么通常只需要读取代码文件、搜索关键字即可，没必要让模型执行文件写入。用allowed-tools做限制，能有效防止它“顺手”改坏东西。
3.3 参数传递与插值：$ARGUMENTS 和其他变量
自定义命令最核心的进阶点就是参数传递。Claude Code 会把你在命令后输入的内容作为参数注入到命令模板中。常用的变量是$ARGUMENTS，它代表你输入的全部参数文本。比如你定义了review.md，内容是：
请以代码评审员的身份，重点审查以下文件或目录的潜在问题：$ARGUMENTS 输出时按“严重问题 / 一般问题 / 建议优化”三个维度组织。实际使用时输入/review src/utils/string.ts，那么$ARGUMENTS就会被替换成src/utils/string.ts，相当于你每次调用都能精确传入当次要审查的对象。这样既保留了固定模板的规范，又让命令具备了每次调用的灵活性，非常实用。
除了$ARGUMENTS，还有一些环境变量可以用。比如$CLAUDE_PROJECT_DIR代表当前项目的根目录绝对路径，$CLAUDE_PWD代表当前工作目录路径。在编写多目录、多脚本任务时，这些变量能帮助模型准确找到文件位置，减少路径混乱。
3.4 结合子目录给命令做分类
命令多了之后，全平铺在一个目录里会很乱。我目前的做法是用子目录做分类。比如：
.claude/commands/ ├── review/ │ ├── code.md │ └── design.md ├── generate/ │ ├── component.md │ └── test.md └── utils/ └── explain.md这样命令会变成/review/code、/generate/component、/utils/explain。因为名字本身已经带了层级，即使团队里命令数量上了三四十个，也不会觉得混乱。我还习惯在文件名里用连字符连接多个单词，比如db-migration-check.md，避免直接用大写字母和空格，因为空格会导致命令输入时产生歧义。
4. 实际问题排查与避坑记录
4.1 命令不生效，十有八九是目录和文件名的问题
我在实际使用中碰到最多的“命令找不到”问题，基本都是因为以下三个原因之一：文件放在了错误的目录、文件名有拼写错误、文件编码格式不对。Claude Code 只会扫描固定目录下的.md文件，而且文件名是严格匹配的。如果你在 Windows 上记事本创建文件，默认编码可能是 GBK 或带 BOM 的 UTF-8，这种情况下命令内容偶尔会出现乱码或者解析失败。
我个人的经验是：尽量用 VS Code、Sublime 这类现代编辑器来创建命令文件，统一保存为 UTF-8 无 BOM 格式。另外，修改命令文件之后，某些版本需要重启会话或者重新打开/提示列表才能刷新，这一点容易被忽略。如果你改了文件但是命令还是旧行为，先看是不是缓存没刷新，再继续排查。
4.2 参数传递：为什么用了 $ARGUMENTS 但还是拿不到值
参数不生效的情况也遇到过几次。首先要确认你是否在命令名后面真的输入了参数。其次要确认变量名拼写是否准确。$ARGUMENTS是全大写的，不能写成$arguments。还有一点，如果你在 front matter 里没有写argument-hint，有些场景下模型可能不太理解你的参数边界，但不影响变量替换本身。
还有个比较隐蔽的问题：命令模板中如果出现了多个$ARGUMENTS，那么每一处都会被替换成相同的参数文本。如果我只想取第一个词作为主要参数，就不能用$ARGUMENTS，而应该考虑拆分成更细的变量，或者用自然语言描述来引导模型“从参数中识别第一项作为主目录”。模板越短、指令越明确，模型的执行效果越稳定。
4.3 安全与权限：避免自定义命令造成意外写入
自定义命令默认继承了当前会话的权限和工具集合。也就是说，如果当前会话已经授予了文件编辑权限，那么一条自定义命令同样可以执行写操作。这在自动化批量任务时是好事，但也是一个风险点。我建议你在设计命令时，通过allowed-tools字段把工具范围缩小。
举个例子，如果你写一条“生成项目报告”的命令，模型其实只需要读文件和统计文件，完全不需要 Write 权限。那就在 front matter 里限制掉，不要给它留出写文件的余地。另外，如果你的命令会调用外部 shell 命令，务必确认命令的逻辑里带有明确的白名单校验，而不是直接拼接用户参数。我在给团队写自动化命令时，会专门用一层“参数校验描述”来告诉模型哪些输入是合法的，哪些必须拒绝。
4.4 环境问题里的高频坑，顺手一起说
热词里很多人搜“claudecode安装提示iex 所在位置 行:1”，这其实是 PowerShell 环境下安装脚本执行策略导致的报错。如果你在 Windows 上遇到类似问题，大概率是你的 PowerShell 执行策略禁止了脚本运行，需要在管理员模式下调整ExecutionPolicy，或者换到 CMD 环境下执行安装命令。还有一个高频坑是“每次使用完 .exe 就失效”，这种通常和系统环境变量 PATH 没有配置好有关，安装完记得检查claude命令是否在全局 PATH 中。
deepseek api 接入 claude code这类问题则是 API 配置层面的。本质上 Claude Code 支持自定义 API 地址，通过环境变量指定模型接入端点，Slash Commands 本身不受影响，但如果你自定义命令中用到了模型切换，就得确保所有模型端点都被正确配置。否则会出现/model切换时报错，进而让人误以为是命令的问题。
5. 我对 Slash Commands 的一些个人心得
自定义斜杠命令做到后期，我的体感是：它其实是一种“把团队工作流显式化”的载体。以前我们靠口头交代上下文、靠文档手动同步规则，现在可以通过一组命令文件把这些约定固化下来。谁用都是一样的入口、一样的约束、一样的输出结构。这不仅减少了人与模型之间反复沟通的成本，也变相统一了团队的代码评审、任务生成和文档整理标准。
我在实际项目里最满意的用法是为每个模块单独建一条context-loader类型的命令，里面写清楚模块的目录结构、核心文件职责、常见历史坑点，然后每次切入该模块时，一条命令就把模型带入状态。这比每次手动重复描述项目背景高效太多。同时我也会配合/memory把一些跨项目的通用规则沉淀在全局记忆里，两条路线配合，模型对我的工作习惯越来越熟悉。
另外想说一个容易被忽略的点：不要过度封装。如果你的模板太长，塞进去几十条规则，模型执行时反而会迷失重点。我把每条命令都尽量控制在一次能读完的篇幅，核心信息优先，输出格式清晰，参数明确。规则太多就拆成多条命令，或者把公共背景放到全局记忆里。好的自定义命令，应该是“一份精炼的标准操作流程”，而不是一份大而全的说明书。
从第 8 章这个学习节点往后，我建议你挑自己日常最高频的三个动作，先做成自定义命令。跑几天看看效果，再迭代模板内容和参数设计。只有当你真的基于自己的项目去写命令、用命令、改命令，你才会理解这套机制的设计精妙之处。毕竟，Slash Commands 的最终目的，不是让你记住更多命令，而是让你把自己最熟悉的工作方式，原原本本地教给模型。
