斜杠命令全解

系列入口：如何使用 Agent。相关：当命令复杂到需要脚本和多文件时，应升级为 Skill。

一、斜杠命令解决什么问题

每次让 Agent 干活都要打一段完整的自然语言，重复且容易说得不一致。同一个「生成提交信息」的动作，你今天这样说、明天那样说，效果时好时坏。斜杠命令把一段常用、固定的指令压缩成一个以 / 开头的短命令，输入 /命令名 就等价于发出那段精心设计过的完整提示。

它的价值有两层：一是快，省去重复打字；二是稳，把你验证过效果好的那段提示固化下来，每次调用都是同一个高质量版本，不再受临场措辞影响。它是把个人最佳实践沉淀成一键动作的最轻方式。

二、内置命令：先把现成的用好

客户端通常自带一批斜杠命令，覆盖高频操作，比如切换模式、查看帮助、初始化、管理配置等。在急着自定义前，先熟悉这些内置命令，因为它们经过设计、开箱即用。

理解内置命令的意义，不只是记住几个名字，而是建立「这类动作有标准入口」的意识：凡是要切换工作模式、触发某个固定流程、查询状态，先想想是否已有命令。直接用内置命令，比每次用自然语言重新描述同一动作更快、也更不易产生歧义。

三、自定义命令：把重复的话固化下来

当你发现某段提示自己反复在说、且措辞已经相对稳定，就值得把它做成自定义命令。

3.1 一个最小例子

自定义命令通常就是一个文件，文件名即命令名，内容是要展开的提示文本。例如做一个「检查改动并给出评审意见」的命令：

---
description: 审查当前未提交的改动，按风险分级给出意见
---

请审查我当前工作区相对于上次提交的所有改动：
1. 先用版本控制查看具体 diff；
2. 按「正确性、安全、性能、可维护性」逐项检查；
3. 先列出高风险问题，再给一般建议；没有明显问题也请明确说明。

之后输入对应命令，Agent 就会按这段固定流程执行，而不必每次重新交代「先看 diff、再分四类、先说高风险」。注意这段提示是可执行、有步骤的，而不是模糊的「帮我看看代码」——这正是命令效果稳定的原因。

3.2 用参数占位提升复用

写死的命令只能处理一种情况，加入参数占位能让它复用得更广。命令里用约定的占位符表示「调用时再填」的部分，比如文件名、模块名、目标语言。调用时把具体内容带在命令后，命令内部把它插入到提示的相应位置。

这样一个「为某模块生成说明文档」的命令，可以通过传入不同模块名反复使用，而不必为每个模块各做一个命令。判断是否值得加参数，看同一流程是否只是其中一两处会变化：会变的部分抽成参数，固定的步骤保留，复用率会大幅提升。

3.3 命令文本怎么写才好用

• 写清步骤顺序，让 Agent 每次走相同、可靠的路径。
• 包含必要的上下文获取动作（如「先看 diff」），而不是假设它已经知道。
• 规定输出结构（先高风险后建议、或固定分段），结果更好读。
• 保持单一职责，一个命令做好一件事，别把十几个用途塞进一个命令。

四、个人命令与团队命令库

和 MCP、规则文件一样，命令也分作用范围。只对你自己有用的命令，放个人配置；团队通用的高质量命令，放进共享目录、纳入版本控制，让所有人都能一键调用同一套经过验证的动作。

团队命令库的价值在于把个体摸索出的好实践快速扩散：某人调出一个特别好用的「事故复盘」或「发布检查」命令，分享后全员复用，不必各自重新打磨。维护上要避免命令泛滥和重复——命名清晰、职责区分明确，并定期清理不再好用的命令。让命令库像代码一样被评审和维护，它才会越积越有用，而不是变成一堆没人记得含义的快捷方式。

五、斜杠命令 vs Skill：何时该升级

这两者最容易混淆，关键区别在复杂度和承载能力。

斜杠命令本质是「一段提示文本的快捷方式」，它能做的就是展开成提示，适合那种靠一段话就能稳定完成、不需要附带脚本或多文件资源的动作，轻量、零门槛。当你的需求开始需要附带可执行脚本、多个资源文件、分步骤调用工具、或较长的流程封装，单段提示已经难以承载，这时就该升级成 Skill。

可以沿一个阶梯理解演进：最初用自然语言临时说 → 反复说就固化成斜杠命令 → 命令里需要脚本和多资源、流程变复杂，再升级为 Skill。不要一上来就写复杂 Skill，也不要在命令已经塞不下时还硬撑；用复杂度决定形态，既能保持轻量，又不会让简单快捷方式被过度压垮。

五点五、好命令长什么样：从一次低效请求说起

要理解命令文本的写法，先看一个反例。很多人第一次做命令，内容写的是「帮我看看代码有没有问题」。这类提示的毛病在于：没说看哪部分、按什么标准、输出成什么结构。于是 Agent 每次都自由发挥——有时只扫一眼说「没问题」，有时东拉西扯一堆无关紧要的风格意见，效果完全看运气。这其实只是把一句不可靠的话存了起来，并没有沉淀任何可靠做法。

把它改成前面示例那种「先用版本控制看 diff、再按正确性/安全/性能/可维护性四类检查、先列高风险再给建议、没问题也要明说」，差别是本质的：它固化的是一条经过设计、可重复的行动路径，而不是一个模糊愿望。 判断一段命令文本好不好，可以问三个问题：它有没有规定先做什么后做什么？有没有说清依据什么标准？有没有约定输出长什么样？三者都具备，命令的效果才会稳定。

还有个常被忽视的细节：好命令会显式要求 Agent「先获取必要上下文」（看 diff、读相关文件），而不是假设它已经掌握。因为命令是被反复调用的，调用时上下文各不相同，让命令自带「取数」动作，才能保证它在任何时候都基于真实材料工作，而不是凭记忆空谈。

五点六、命令、模板、代码片段：别混淆三者

斜杠命令在形态上容易和「代码片段（snippet）」混淆，理清边界能避免用错工具。

代码片段展开的是给编辑器的静态文本——一段代码模板，插入后由你继续编辑，它本身不触发任何智能行为。斜杠命令展开的是给 Agent 的指令，它会被执行、产生动作和回应。一个是文本填充，一个是任务发起，方向完全不同。理解这点，你就不会试图用命令去「插入一段代码」，也不会指望 snippet 帮你完成审查。

再看参数：代码片段的参数（tab 占位）是留给你手动填的光标跳转；斜杠命令的参数是你在调用时传入、由 Agent 纳入推理的内容。虽然都叫「占位」，一个服务于编辑、一个服务于推理。把这层区别想清楚，你在固化个人工作流时才能选对载体——要复用文字用 snippet，要复用动作与判断流程用斜杠命令。

五点七、让命令库保持「记得住、敢信任」

命令一旦多起来，会遇到两个问题：记不住有哪些，以及不敢确定某个命令到底好不好用。这里讲轻量的维护方法。

对付「记不住」，靠的是命令的 description 字段和自动补全，而不是背诵。每个命令用一句话写清它做什么，触发补全时就能看到；命名也应直观、成体系（比如同类动作统一前缀），看到名字大致能猜用途。对付「不敢信」，靠的是把命令当可迭代的资产：用过发现某步不灵就改文本，让命令始终对应你验证过的最佳版本；明显失效或重复的及时删掉。

团队层面，命令库纳入版本控制后，改动可评审、可追溯，谁改进了某个命令、为什么改，都有记录。但要警惕命令泛滥——人人都往里加，很快出现一堆功能重叠、措辞各异的命令，反而增加选择负担。指定人轻量梳理、合并重复、保持命名一致，命令库才会越用越精炼。目标不是收藏尽可能多的命令，而是保有一小撮你闭着眼都敢调用的可靠动作。

五点八、参数设计：一个命令顶十个

参数是让命令从「专用」变「通用」的关键，值得讲清楚怎么设计最值。

新手常犯两个相反的错。一是完全不用参数，为每个微小差异各做一个命令——「审前端」「审后端」「审这个文件」，命令数量爆炸、内容还大量重复，改一处要改十份。二是把命令做成什么都靠参数决定的大杂烩，参数多到自己都记不住顺序，命令失去了「固定流程」的意义。

健康的做法是先识别那段流程里真正会变的只有哪一两处：通常是目标对象（文件/模块/分支）、或某种模式选择。把这些抽成参数，其余步骤保持固定。这样一个「审查某模块改动」的命令传入不同模块名即可复用，简洁又灵活。判断参数是否抽得好，看它是否既消除了重复、又没有让命令的使用变得比直接打字还复杂。参数命名也应直观，调用时一眼知道该传什么。

五点九、从命令到 Skill 的临界点怎么判断

这个决策在实际中很常见，给一个可操作的判断标尺，避免过早或过晚升级。

还留在命令层，当你的动作本质上是「一段话就能让 Agent 稳定完成」，不需要附带可执行脚本、不需要多个外部资源文件，每次结果也都令人满意——这时命令最轻，零维护负担。该升级到 Skill，当你开始发现这段提示里反复要求执行同一个脚本、需要读取一组配套文件、流程长到单段提示难以讲清，或希望把它分发给别人时连同资源一起带走——这些都是复杂度超出「纯文本快捷方式」承载的信号。

一个中间的过渡做法：当命令只是「有点长」但仍是纯提示，不必急着升级，保持简单；只有当出现真正的脚本或多文件依赖时才动手。升级时把命令里验证有效的步骤直接搬进 Skill 的流程定义，相当于在已沉淀的基础上演进，而不是推倒重来。让升级被「需要」触发，而不是被「Skill 更高级」的想象触发。

五点十、命名命令：被忽视却决定好用与否

命令好不好用，名字占了一半，这点常被忽略。一个含义清晰、成体系的命名，能让你在补全列表里一眼选中，也让团队协作时不用额外解释。

坏命名通常是两类：过于随意（「处理一下」「test2」），几周后连自己都不知道它干嘛；或过于笼统，多个命令名字相似却各做不同的事，调用时只能靠试。好名字应直接说出动作与对象，必要时用统一前缀把同类命令分组，让人看到名字就能推断用途和归属。

命名时还可以把「最常用」留给最短、最好打的名字，因为高频命令的输入成本最值得优化。团队共享时，命名约定更要提前统一，避免每人各起一套、同义命令泛滥。把命名当作命令 API 的一部分来设计——清晰、稳定、可预期，你调用时才真正做到不假思索。

六、常见问题

Q：斜杠命令和直接打自然语言，效果差很多吗？ 对简单一次性问题差别不大；但对反复出现、需要固定步骤的动作，固化命令能保证每次都走同一条验证过的路径，稳定性明显更高，也更省时。

Q：参数一般怎么传给命令？ 在命令后追加内容，命令文本里用占位符引用；具体语法以你所用客户端为准，思路都是「固定模板 + 可变部分」。

Q：命令太多记不住怎么办？ 依赖命令的自动补全和描述字段，不必死记；同时控制命令数量、保持命名直观，把真正高频的留下。

Q：能不能在命令里直接执行脚本？ 纯提示型命令不行，它只展开文本。需要绑定脚本或资源时，应使用 Skill 这类更完整的机制。

Q：命令效果时好时坏，问题出在哪？ 多半是命令文本没把步骤和依据写死，给 Agent 留了自由发挥空间。把「先获取什么、按什么标准、输出什么结构」写具体，并让它基于真实材料执行，稳定性会显著提升。

七、使用检查清单

• 已熟悉高频内置命令，没有重复造轮子。
• 把反复使用、步骤稳定的提示固化成了自定义命令。
• 命令文本步骤清晰、规定了输出结构、单一职责。
• 可变部分用参数占位，提升复用率。
• 团队通用命令已共享并纳入版本控制，命名清晰无重复。
• 需要脚本或多文件的复杂流程已升级为 Skill，而非硬塞进命令。

总结

斜杠命令把一段验证过的提示压缩成 /短命令，既快又稳：先用好内置命令，再把反复出现、步骤固定的动作做成自定义命令，用参数占位提升复用，团队命令共享进版本库；当需求需要脚本、多资源和复杂流程时，就从「一段提示的快捷方式」升级为 Skill——按复杂度选形态，让好实践一键复用。