★ FEATURED ARTICLE 从折腾 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 的最终目的不是让你记住更多命令而是让你把自己最熟悉的工作方式原原本本地教给模型。
阅读完成 · 觉得有帮助？
