📒 学霸笔记：08｜自定义指令：精通 Slash Commands，打造你的私人命令集

Top Student Notes: 08 | Custom Instructions — Mastering Slash Commands to Build Your Personal Command Set

课程 / Course: AI 原生开发工作流实战 / AI-Native Development Workflow in Practice
讲师 / Instructor: Tony Bai
章节 / Chapter: 08
主题 / Topic: Slash Commands、内置命令、自定义命令、参数系统、Frontmatter、命令内嵌 Shell、团队工作流固化

一、这一讲在解决什么问题？

What Problem Does This Lecture Solve?

前几讲我们已经做了很多准备：

• 用 @ 提供上下文
• 用 ! 执行 shell
• 用 CLAUDE.md 提供长期记忆
• 用 constitution.md 约束 AI 的高层原则

现在 AI 已经“懂项目”了，但新的效率问题出现了：

你开始反复输入一类“高频、固定模式、但很长”的提示。

比如：

• 审查某个包并结合宪法原则给反馈
• 为某个文件生成表格驱动测试
• 读取 staged diff 自动生成 commit message

这些事情不是不会做，而是：

• 太重复
• 太啰嗦
• 容易打错
• 不利于团队共享最佳实践

所以这一讲解决的是：

如何把高频工作流封装成可复用、可共享、可参数化的指令。

这个机制就是：

Slash Commands（斜杠指令）

二、本讲核心结论

Core Conclusion of This Lecture

一句话总结

Slash Commands 的本质，是把“重复描述的动态 Prompt”升级为“可复用、可共享、可组合的工作流模板”。

三、为什么 Slash Commands 很重要？

Why Slash Commands Matter

Tony 认为，Slash Commands 不只是一个“快捷输入机制”，而是：

开发者从“AI 使用者”转向“AI 指令设计师”的第一步。

没有 Slash Commands 时

你每天都在：

• 重复写长 prompt
• 人肉拼上下文
• 手动描述步骤
• 手动约束风格和规范

这很像没有 shell script 的时代：

• 每次都手敲长串命令
• 没法沉淀流程
• 没法标准化

有了 Slash Commands 后

你可以把：

• 代码审查流程
• 生成测试流程
• Git 提交流程
• 分析 diff 流程
• 团队规定动作

封装成一个简单命令：

/review-go-code internal/converter/
/commit
/gen-test-for-service internal/foo/bar.go ParseFoo

一句话

Slash Commands = AI 时代的 prompt 脚本化 / 工作流原子化

四、内置 Slash Commands：日常提效的瑞士军刀

Built-in Slash Commands: The Swiss Army Knife for Daily Productivity

Claude Code 已经内置了不少 Slash Commands。
Tony 认为不需要全部死记，只要掌握常用高价值命令即可。

他把这些命令按功能分成四类：

1. 会话与上下文管理
2. 环境与配置
3. 项目与协作
4. 元信息与帮助

五、第一类：会话与上下文管理

Category 1: Session and Context Management

这类命令管理的是：

AI 当前的短期工作记忆

它们的作用是：

• 清理上下文
• 重置会话聚焦点
• 避免 AI 被上一个任务残留影响
• 帮你在多个任务之间快速切换

学霸理解

这类命令解决的问题是：

“AI 记忆太短” 不是唯一问题，
“AI 记忆太杂” 也是问题。

所以这类命令本质上是：

上下文卫生管理工具

六、第二类：环境与配置

Category 2: Environment and Configuration

这类命令相当于 Claude Code 的“控制面板”。

它们帮助你：

• 查看当前模型
• 检查当前配置
• 调整主题
• 修改终端行为
• 校验运行状态

学霸理解

这类命令的价值在于：

你不是把 Claude Code 当黑盒用，而是在主动调校它。

也就是说：

• AI 不是“神秘存在”
• 而是一个可以配置、检查、治理的工作系统

七、第三类：项目与协作

Category 3: Project and Collaboration

这类命令直接嵌入工程任务中，通常和以下有关：

• 项目初始化
• 记忆管理
• 团队共享上下文
• 工作流协作

学霸理解

这一类命令是 Claude Code 从“聊天工具”走向“工程平台”的体现。

因为这意味着：

• 它不是只回答问题
• 而是深度进入项目协作面

八、第四类：元信息与帮助

Category 4: Meta Information and Help

这类命令包括：

• 查看帮助
• 查看可用命令
• 查看状态
• 了解系统当前能力

学霸理解

它们像实时说明书和控制台。

一个成熟开发者不是“背下来所有命令”，而是知道：

• 有哪些类别
• 去哪里查
• 如何自发现

九、真正的重点：自定义 Slash Commands

The Real Core: Custom Slash Commands

Tony 明确指出：

真正的革命，不是会用内置指令，而是开始创造你自己的指令。

这一步意味着开发者角色变化：

• 从被动提问
• 到主动封装工作流
• 再到把团队经验沉淀成 AI 能力

十、自定义指令的核心理念

Core Idea of Custom Commands

1. 把高频工作流封装成原子能力

Tony 认为适合封装成命令的工作流，通常有三个特征：

① 高频

你经常做：

• 每天多次
• 每周多次
• 团队很多人反复做

② 模式固定

步骤大体一样：

• 看代码
• 跑检查
• 按宪法审查
• 输出固定格式报告

③ 含隐性知识

背后不只是一个 prompt，而是一套约束：

• 要符合团队规范
• 要看 constitution.md
• 要优先表格驱动测试
• 要遵循 Conventional Commits

2. 从动态 Prompt 到静态模板

这句话非常关键：

自定义命令就是把“每次现编的动态 prompt”变成“可复用的静态模板”。

学霸理解

这本质上是：

• 把 prompt 工程化
• 把经验资产化
• 把个人技巧团队化

十一、两种作用域：Project 级 vs User 级

Two Scopes: Project-Level vs User-Level

Claude Code 的自定义命令支持两级作用域，这一点非常工程化。

1. Project 级命令

Project-Level Commands

存放位置

./.claude/commands/

特点

• 属于项目的一部分
• 应该提交到 Git 仓库
• 团队成员共享
• 克隆项目即获得同样命令

适合场景

• 团队统一审查流程
• 团队统一测试生成方式
• 团队统一部署 / 提交流程
• 项目专属能力

典型例子

• /review-go-code
• /gen-test-for-service
• /deploy-to-staging

2. User 级命令

User-Level Commands

存放位置

~/.claude/commands/

特点

• 只存在于你本机
• 所有项目可用
• 不与项目仓库绑定
• 更适合个人习惯

适合场景

• 个人常用 diff 总结
• 个人翻译习惯
• 个人 TODO 搜索
• 个人代码分析偏好

典型例子

• /summarize-diff
• /translate-to-english
• /find-todos-in-code

学霸理解

这里其实是在平衡两件事：

• 团队共享规范
• 个人效率偏好

也就是说，自定义命令不仅是能力封装机制，也是作用域治理机制。

十二、参数系统：让命令“活”起来

Parameter System: Making Commands Dynamic

如果命令只能是死模板，那价值有限。
真正强大的地方在于：

命令可以带参数。

Tony 介绍了两种参数方式。

十三、第一种参数：$ARGUMENTS

First Parameter Form: $ARGUMENTS

含义

它表示：

捕获命令名后面的所有文本

例如：

/fix-github-issue 1234

在模板中写：

Please analyze and fix the GitHub issue: $ARGUMENTS

最终 AI 看到的就是：

Please analyze and fix the GitHub issue: 1234

适合场景

• 一个 issue id
• 一句自然语言描述
• 一段不定长说明
• 一个整体查询条件

学霸理解

$ARGUMENTS 适合：

内容长度不固定，但语义上整体就是一个输入

十四、第二种参数：$1, $2, $3

Second Parameter Form: $1, $2, $3

含义

类似 shell 位置参数：

• $1：第一个参数
• $2：第二个参数
• $3：第三个参数

例如：

/review-pr 456 high tonybai

模板：

Please review Pull Request #$1.
The priority for this review is: $2.
Please focus your review on the changes made by author: $3.

最终 AI 收到：

Please review Pull Request #456.
The priority for this review is: high.
Please focus your review on the changes made by author: tonybai.

适合场景

• 参数结构明确
• 参数顺序固定
• 每个参数语义不同

例如：

• 文件路径 + 函数名
• PR 号 + 优先级 + 作者
• 服务名 + 环境名 + 发布版本

如何选择？

十五、高级技巧一：Frontmatter 元数据

Advanced Technique 1: Frontmatter Metadata

对于更专业的命令，可以在 Markdown 文件顶部写 YAML Frontmatter。

这是自定义命令“专业化”的关键步骤。

示例字段

1. description

命令说明。
作用：

• 在命令列表中显示描述
• 提高可发现性
• 让团队成员更容易理解用途

2. argument-hint

参数提示。
作用：

• 提示用户该命令应该输入什么参数
• 减少误用
• 提升可用性

3. model

可以为该命令指定专属模型。

例如：

• 一般任务用便宜模型
• 高质量审查强制用 opus

学霸理解

这体现出一个重要思想：

不是所有任务都值得用最强模型，但关键任务应该明确配最强模型。

4. allowed-tools

这是特别关键的安全与治理机制。

它允许你为这个命令单独配置：

哪些工具可以用，哪些不可以用

例如：

• 只允许 Read
• 只允许 go vet
• 不允许写文件
• 不允许执行任意 git 或 rm 命令

为什么 allowed-tools 非常重要？

因为一个团队命令如果要共享，就必须可控。
否则“共享能力”会变成“共享风险”。

学霸理解

allowed-tools 本质上是：

为命令设置最小权限边界

这和操作系统权限控制、云平台 IAM、数据库 RBAC 是同一种治理思想。

十六、高级技巧二：在命令中嵌入 ! Shell 命令

Advanced Technique 2: Embedding ! Shell Commands Inside Commands

这是本讲最强大的特性之一。

核心机制

在命令模板内部可以直接写：

!`git diff --staged`

当命令被执行时：

1. Claude Code 先执行这个 shell 命令
2. 拿到输出
3. 用输出替换原位置
4. 再把完整 prompt 发给 AI

这意味着什么？

命令不仅是静态模板，还能自动准备实时上下文。

经典例子：/commit

模板里嵌入：

• 当前分支
• staged diff

然后让 AI 基于这些实时信息生成 commit message。

为什么这个能力非常强？

因为它让 Slash Command 从：

• “prompt 快捷方式”

升级为：

带上下文预处理能力的工作流脚本

学霸理解

这很像 shell script 里的：

• 先执行若干命令
• 再把结果喂给后续逻辑

只是这里的“后续逻辑”不再是 bash，而是 LLM 推理。

十七、Slash Command 的真实价值：自动化上下文准备

The Real Value: Automated Context Preparation

这一点非常值得单独记住。

以前你要写一个高质量 commit prompt，步骤可能是：

1. git branch --show-current
2. git diff --staged
3. 复制输出
4. 再写 prompt

现在只要：

/commit

Slash Command 自动完成：

• 状态采集
• 上下文拼接
• 提示模板补全

一句话

Slash Commands 最大的价值不只是缩短输入，而是自动化准备优质上下文。

十八、实战案例：/review-go-code

Practical Example: /review-go-code

这是本讲最重要的综合案例。

Tony 不是简单做了一个“代码审查 prompt”，而是设计了一个：

结合静态工具 + 项目宪法 + AI 深度分析的系统化审查工作流

十九、这个审查工作流为什么设计得好？

Why This Review Workflow Is Well Designed

步骤 1：开发者只提供目标路径

例如：

/review-go-code internal/converter/

这降低了使用门槛。

步骤 2：先跑确定性工具 go vet

这是很关键的设计思想：

先让传统工具做基础体检，再让 AI 做高维判断

这样做的好处：

• 明显问题先被确定性工具发现
• AI 不需要从零判断所有基础错误
• 审查更扎实，也更高效

步骤 3：把 go vet 输出 + 代码 + constitution.md 一起喂给 AI

这一步非常像一个成熟工程师的工作方式：

• 不只是看代码
• 还看静态报告
• 还对照团队原则

这意味着 AI 审查不是“凭感觉”，而是：

有工具支撑、有原则约束的结构化审查

步骤 4：输出结构化报告

包括：

• 总体评价
• 优点
• 待改进项
• 按优先级排序
• 指明文件、行号、建议

学霸理解

这不是让 AI“随便说几句意见”，而是在要求它产出：

可执行、可追踪、可进入修复流程的工程报告

二十、为什么 Frontmatter 配置很关键？

Why the Frontmatter in This Example Matters

1. model: opus

说明：

• 代码审查是高价值任务
• 值得用更强模型
• 这是“资源分配”的体现

2. allowed-tools

只允许：

• Read
• Grep
• Glob
• Bash(go vet:*)

说明：

• 只能读
• 只能运行指定静态分析
• 不允许随便写文件、改代码、执行危险命令

学霸理解

这把代码审查命令变成了：

只读、安全、受限、可共享的审查工具

二十一、这一讲真正的升级点

The Real Upgrade in This Lecture

这讲看似在教“写命令文件”，其实真正完成的是一个角色升级：

从 prompt 用户，升级为 AI 能力设计师

因为你开始做的不再是：

• 向 AI 提问

而是：

• 定义一个可复用能力
• 规定这个能力的输入格式
• 指定这个能力的模型
• 约束它的权限
• 固化它的输出形式
• 让团队所有人都能复用

这其实已经很像：

• 设计 API
• 设计 CLI
• 设计内部平台能力

二十二、Slash Commands 与前几讲的关系

How Slash Commands Connect to Previous Lectures

和 @ 的关系

@ 负责上下文注入。
Slash Commands 把这种注入模式模板化、自动化。

和 ! 的关系

! 负责实时执行 shell。
Slash Commands 把 shell 执行嵌入模板，形成自动上下文准备流程。

和 CLAUDE.md 的关系

CLAUDE.md 提供长期记忆与行为规范。
Slash Commands 可以引用并利用这些规范，形成更稳定输出。

和 constitution.md 的关系

constitution.md 提供最高原则。
Slash Commands 可以把“合宪审查”嵌入具体工作流，例如代码审查、功能设计、测试生成。

一句话总结

Slash Commands 是把前几讲学到的上下文、原则、工具能力，封装成“可调用工作流”的那一步。

二十三、思考题怎么答：如何改进 /commit

How to Improve /commit (Reflection Question)

题目指出的问题是：

• 如果忘了 git add
• git diff --staged 就为空
• 生成的 commit message 会失真

改进思路

Slash Command 里可以同时检查：

• git diff --staged
• git diff

然后通过自然语言告诉 AI：

逻辑设计

1. 如果 staged diff 非空
   → 基于 staged diff 生成 commit message

2. 如果 staged diff 为空，但 working tree diff 非空
   → 提醒用户还没有 git add
   → 总结 working tree 改动
   → 询问是要先生成建议 message，还是先提醒用户暂存

3. 如果两个都为空
   → 明确告诉用户当前没有改动可提交

示例思路（伪模板）

---
description: 智能生成 commit message，并检查 staged/unstaged 状态
allowed-tools: Bash(git diff:*), Bash(git branch:*), Bash(git status:*)
---

你是一位 Git 专家。请根据以下 Git 状态帮助我生成合适的 commit message。

当前分支：
!`git branch --show-current`

Git 状态：
!`git status --short`

暂存区变更：
!`git diff --staged`

工作区未暂存变更：
!`git diff`

请按以下规则处理：
1. 如果“暂存区变更”非空，则仅基于暂存区变更生成符合 Conventional Commits 的 commit message。
2. 如果“暂存区变更”为空，但“工作区未暂存变更”非空，则先明确提醒我当前尚未 git add，并基于未暂存变更给出一个“建议的 commit message 草案”，同时提醒我先确认是否需要暂存这些改动。
3. 如果两者都为空，则直接告诉我当前没有可提交的改动。

只输出最必要的结果，不要冗长解释。

学霸理解

这道题考查的是：

你是否真正理解 Slash Command 不只是模板，而是可以带有“状态判断语义”的工作流设计。

二十四、本讲知识结构图

Knowledge Structure of This Lecture

AI 已经懂项目
        ↓
但高频 prompt 仍然重复、冗长
        ↓
需要将高频工作流模板化
        ↓
Slash Commands 登场
        ↓
先掌握内置命令
        ↓
再创造自定义命令
        ↓
自定义命令包含：
- 作用域（project / user）
- 参数（$ARGUMENTS / $1 $2）
- 元数据（description / model / allowed-tools）
- 实时上下文准备（嵌入 ! shell）
        ↓
最终把团队经验、审查流程、测试规范
封装成可共享的 AI 原子能力

二十五、学霸速记表

Quick Revision Table

二十六、学霸自检题

Self-Check Questions

基础题

1. Slash Commands 为什么能显著提升 AI 协作效率？
2. Project 级和 User 级自定义命令有什么区别？
3. $ARGUMENTS 和 $1/$2/$3 分别适合什么场景？

进阶题

4. 为什么 allowed-tools 是团队共享命令中非常关键的字段？
5. 命令中嵌入 ! shell 命令的真正价值是什么？
6. 为什么 /review-go-code 先跑 go vet 再交给 AI 审查，是一种更合理的工作流设计？

思辨题

7. 你当前项目中有哪些高频 prompt 适合抽成 Slash Command？
8. 哪些命令应该做成 Project 级，哪些适合 User 级？
9. 你是否能设计一个“防呆版 /commit”或“自动生成测试版 /gen-test”命令？

二十七、学霸总结

Top-Student Summary

这一讲的主题是 Slash Commands，但本质上讲的是：

如何把人与 AI 的协作，从一次次临时对话，升级为可复用、可共享、可治理的工程能力。

Claude Code 的内置 Slash Commands 是日常提效的基础工具；
而真正有价值的是自定义 Slash Commands，它让开发者可以把：

• 高频动作
• 重复流程
• 团队最佳实践
• 隐性经验
• 安全边界
• 输出格式要求

全部封装成一个可以复用的命令。

其中最关键的几个能力包括：

• 作用域划分：Project 级共享，User 级私人
• 参数系统：支持整体参数与位置参数
• Frontmatter 元数据：让命令具备描述、参数提示、模型选择和工具权限控制
• 命令内嵌 !：自动执行 shell 命令，动态准备实时上下文

通过实战 /review-go-code，Tony 展示了最成熟的命令设计思路：
不是单纯把一段 prompt 缩短，而是将：

• 静态工具（go vet）
• 项目宪法（constitution.md）
• 模型能力（opus）
• 安全约束（allowed-tools）
• 结构化输出要求

组合成一个真正可共享、可治理、可复用的 AI 原子能力。

这也意味着开发者角色再次升级：

你不再只是“会提问的人”，而是开始成为“AI 能力平台的设计者”。

二十八、一句话记忆

One-Sentence Memory Hook

Slash Commands 不是输入快捷键，而是把你的经验、规范和工作流封装成 AI 可执行能力的第一种工程化形式。