增强人与 Agent 交互体验的 Slash Command

“只要重复 3 次的，就给它自动化。”这句话可能有点夸张，但是背后的思路值得借鉴。当我们和 Agent 进行交流的过程中，经常会发现有一些需求会反复出现。此时如果把这些需求进行标准化，通过一些简短的命令来引用大段的提示词描述，既能让 Agent 很清楚地理解我们的需求，又能让我们自己在表达的时候，减少许多不必要的认知负担和操作步骤。道理很简单，如果一件事情在未来会需要我们反复去做的话，那么对完成这件事的效率提升，未来每执行一次，对我们来说都是一笔可观的注意力收益。

本文就来分享一些个人使用下来比较实用的自定义 Slash Command。提示词写的一定不是最好的，但希望思路对你有所启发。同时，这篇文章并不介绍具体实现格式和编写的技术细节，因为本篇文章的受众，应该都有方法来询问 AI 来解决。

什么是 Slash Command？

Slash Command（斜杠命令）是一种简化用户与系统交互的方式，用户通过输入特定的命令（通常以斜杠开头）来触发预定义的操作或功能。用过 Claude Code 等 Coding Agent 用于开发的读者一定比较熟悉。

Slash Command 思路分享

下面分享一些我从实践中总结出来的，那些对我比较有用的自定义 Slash Command，供读者参考。再次强调，本文不分享在工程实践中，简单通过把提示词进行封装，来实现的功能性的命令，如一键测试、提交等。这些对一个合格的 Agent 交互者来说，都是基本功，应该有意识把常用的提示词封装成这种 Skill 或者 Slash Command。本文主要从人与 Agent 交互的特征出发，从更高维度，尝试设计一些能够提升 Agent 交互体验的 Slash Command。

1️⃣ /notify - 任务完成通知

我经常让 Coding Agent 在后台工作，但是等它做完的时候，我可能并不知道这件事情，相当于说，Agent 浪费了这段宝贵的时间，什么事情都没干。我作为它的老板，怎么可以希望员工偷懒呢？那如果我一直盯着它干活，又太浪费我的时间了，究竟我是老板还是它是老板？😄

因此我设计了一个 /notify 的命令，意思是说，当你完成了这个任务之后，给我发一个 Telegram 的通知。这样的话，我就可以在 Telegram 上收到这个通知了。Telegram 推送在我这里的优先级比较高，因此我大概率是可以看到的，而经过我实际测试下来，Agent 在做完哪怕是比较长的工作后，仍然会记得这件事情。这相当于给 Agent 完成任务这件事情，添加了一个 hook。 你也可以按照自己的需求修改这个命令的提示词，大概是这样的：

注：此处使用 apprise 来发送 Telegram 通知，你也可以根据自己的需求，使用其他的工具来实现通知功能。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

---
description: Send Telegram notification when task completes
---

Send a Telegram notification only after the task is fully completed and verified.

## Instructions

1. **Complete the user's task** as requested.

2. **After completion**, send a notification using:
   `apprise -t "Task Complete" -b "<summary>"`

   Build <summary> as a concrete result summary (2-4 sentences). It must include:
   - What was done (specific actions)
   - Key result(s) or evidence (file paths, logs, screenshots, or checks)
   - Current status: success / partial / failed

   If $ARGUMENTS is not empty, append it as the last sentence.
   Do **not** use $ARGUMENTS as the entire summary.

3. **Timing**: Send notification AFTER all work is done, verified, and ready for user review.

## User Input

$ARGUMENTS

---

**Remember**: Complete the task first, then notify.

2️⃣ /learn - 从对话中学习

如果对模型的“记忆”相关分析不感兴趣的读者，可以直接跳转到使用方式部分。

Agent 和人不一样。在某种程度上，人的意识和记忆管理是非常紧密的，二者有一定的耦合性。但 Agent 的底座是 LLM，LLM 本身是 stateless 的，也就是说，它没有记忆的能力。如果说有的话，所谓”记忆”能力也是通过外部的文件来实现的，它们本质上是存储在磁盘上的提示词，并通过一定的方式用软件加以组织，并最终传递给 LLM。

好在现在已经有很多规范的记忆管理标准了，比如说 Claude Code 的 CLAUDE.md，在每轮对话/工具调用的时候，都会传入，作为全局性的记忆。OpenClaw 的 MEMORY.md 文件也提供了类似的机制。

还有一种我个人认为比较优雅的方式，是通过 skill。Agent 的记忆本质上都是提示词，那么从记忆的角度来说，skill 的优势在哪呢？我认为，至少有两个方面：

第一，**skill 实现了”渐进式上下文管理”。在 Agent 的上下文中，上下文是比较宝贵的。Agent 在需要时调用的 skill，其实会占据非常多的上下文空间。这实质上是 Agent 在按需获取记忆的过程中，成本和效率这二者的权衡。** 如果完整的提示词都放在全局性的记忆文件里，虽然一定能直接找到，但每次调用的时候，都会占据大量的上下文空间，不仅开销大，也会影响 Agent 推理的效果。人难以一心二用，Agent 在一定程度上也是如此。

而标准的 skill 在其 SKILL.md 头部，有一些 yaml 格式的自定义字段，其中最主要的是 name 和 description。在 Agent 运行使用的时候，这些字段实际上充当了「索引」的作用，以一个比较小的上下文代价，来实现对大量提示词的「引用」。 在需要的时候，Agent 可以通过 name 来调用这个 skill，来获取这个 skill 的 SKILL.md 的全量提示词内容。

更近一步，在 skill.md 中，还可以把一些不那么重要的、按需查看的内容，放在 references 目录下，来实现更进一步的上下文渐进式管理。

第二，**skill 实现了智能与代码的有机融合**。LLM 和代码其实是两种拥有不同优势的工具。

LLM 以人类知识的一部分为训练语料，本身具有一定的通用性的智能。借助提示词和外部的工具环境，这种智能可以做很多之前我们人类引以为豪的事情，比如说写作、翻译、使用工具等。但它又具有不稳定性的缺点，尤其是在一些需要非常精确的、结构化的输出的时候，LLM 可能就不太可靠了。而且，使用 LLM 的话，需要一定推理成本，如果让它处理一些计算量较大的任务的话，效率也不高。

而代码在确定性和效率上大大占优。对于一些需要非常精确的、结构化的输出，或者说需要处理一些计算量较大的任务，代码就非常适合了。但是代码在编写和测试上，需要一定编写、调试和维护成本，可扩展性比提示词差一些。

skill 恰好综合了这两者。一个 skill 里面，实际上可以包含提示词和代码两部分内容。提示词部分可以用来驱动智能，来指导 Agent 在使用这个 skill 的时候，应该怎么做；代码部分则可以用来成为 Agent 的工具，来弥补 LLM 在效率和确定性上的不足。从记忆的角度来说，把一些功能程序化，放在 skill 的代码里，可以很大程度上节省 Agent 的记忆空间。

当我们使用类似 OpenClaw 这样，具有一定持久化记忆能力的 Agent，或者是使用其他 Coding Agent 来辅助自己进行开发、写作等标准化的流程时，我们可能发现很多时候 Agent 对工具调用等过程，经常犯错；或是经常理解错误，需要人类反复确认。但这些又可以通过试错和调试来解决。在它反复尝试后终于解决问题的时候，上下文里面刚好包含了它完整的试错过程，对 Agent 来说，是一个完美的学习机会。

使用方式：

因此我设计了一个 /learn 的命令，让 Agent 在完成某个任务后总结一下它在这个过程中学到了什么。使用时机可以是，当 Agent 经过多次试错终于解决问题时，或在每天空闲时段（如凌晨）让它总结当天经验。这个命令很简单，甚至不需要各种复杂的提示词技巧：

1
2
3

请你深入分析，在前面试错过程中，可以总结哪些宝贵经验？请分别整理到Skill（如有对应）或项目的CLAUDE.md中，这样可以避免未来重复犯错。注意，如果这些文件中有层级引用结构的话，请按照对应的层级设计，放在合适的位置。

如果你有自己的一套记忆文件体系，也可以根据具体情况调整命令。如果使用 OpenClaw 这种长时间自主运行的 Agent，你甚至可以把这个命令设计成一个定时触发的任务，让 Agent 在每天空闲的时候（如凌晨 4 点），总结当天的经验。

3️⃣ /align - 人与 Agent 的需求对齐

在使用 Agent 的过程中，经常会发现，有时 Agent 对你的需求的理解，并不完全准确。在大多数情况下，是因为你在和他交流的有限的上下文中，没有意识到，有一些对完成需求非常重要的信息，并没有传递给它。如果早发现这种现象还好，可以通过即时纠偏和补充信息，让 Agent 更好地理解你的需求；但如果没有发现的话，Agent 就可能会按照它的理解来完成任务，浪费了宝贵的时间和 Token。

这背后有一个技术原因：在 LLM 的 RLHF 训练过程中，人类标注者通常更偏好”给出完整流畅的回答”而非”承认不知道”，这导致模型在不确定时倾向于强行完成任务，而不是主动澄清理解。 但在实际使用中，我们反而希望模型在理解不清晰时主动提问，而不是按照可能错误的理解去执行。

作为用户来说，我们很难接触和干预模型的训练过程，我们应该思考的是，我们可以决定的那些事情中，可以如何更好解决这个问题呢？那就是在开始工作之前，就对齐好需求。 具体来说，我们可以在写 prompt 的时候尽可能写得详细一些，这当然是一个好习惯。但我认为，有一个更好的方式是，在 Agent 开始工作之前，就让它主动通过提问的方式，来确定它对这个任务的理解是否正确，以及人类有没有一些欠考虑的地方。这样的话，我们既可以比较轻松地通过回答问题的方式来对齐需求，也可以看到那些我们认知之外的，没有想到要交代给模型的部分，进一步增强了我们对 Prompt 设计的理解。

因此我设计了一个 /align 的命令，来让 Agent 在开始某个任务前，总结一下它对这个任务的理解，并且和我的需求进行对齐。使用这个命令后，Agent 会主动向你提出 2-3 个澄清问题，逐步确认对需求的理解，直到双方完全对齐后才开始执行。这个命令也很简单：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

---
description: 与用户多轮交互澄清需求，直到完全对齐再执行。支持参数：/align <粗略需求>
---

你现在进入「需求对齐模式」（Alignment Mode）。

## 核心规则（严格遵守）

1. **绝不** 直接开始实现或写代码、写文档、生成任何输出物。
2. **唯一允许的行为**：使用 AskUserQuestion 工具（或系统提供的提问工具）向用户提问，问那些你还不太明确，或者用户欠考虑的问题。
3. 问题要**具体、聚焦、可回答**（避免开放式大问题）。
4. 每轮收到用户回答后，**立即**：
   - 简短确认理解（1–2 句）
   - 判断是否还需要更多澄清
   - 如果还不够 → 继续问下一个最重要的问题
   - 如果已经足够清晰 → 输出最终的「对齐后需求总结」，然后问：“以上理解是否正确？可以开始执行了吗？”
5. **对齐后需求总结** 必须结构化，使用 markdown 格式，包含：
   - 目标（一句话）
   - 关键约束 / 非功能需求
   - 验收标准（用户最在意的 Done 定义）
   - 优先级 / 范围（what in / what out）
   - 任何已确认的假设
6. 整个过程保持**礼貌、耐心、高效**。目标是用最少轮次达到最高理解一致性。

## 当前用户输入（原始需求）

$ARGUMENTS

## 第一步（现在立即执行）

- 仔细阅读上面的 $ARGUMENTS
- 思考：最容易导致偏离、最模棱两可、最关键的 1–2 个点是什么？
- 使用 AskUserQuestion 工具提出**第一个（或前两个）澄清问题**

开始吧。

在未来对 Agent 布置需求性任务时，不妨都使用这个命令来开头，来让 Agent 先对齐需求。虽然可能会增加一些前期的沟通成本，但从数学期望上来看，应该是可以节省后续开发过程中潜在的时间、精力和金钱成本的。

总结

这三个命令分别解决了通知、记忆迭代和需求对齐三个核心问题。使用 /align 来事先对齐，减少返工；用 /learn 来利用宝贵的试错，为Agent积累经验；用 /notify 来降低自己内耗的部分或是节省时间，提高并行效率。

本文仅是抛砖引玉，希望可以为读者提供思路和启发。如果有一个命令，或者其中的思考对你有所启发，其目的就已达到。欢迎读者补充：还有哪些你认为比较有意思的、提升在与 Agent 交互时的“幸福感”的 Slash Command 呢？欢迎在评论区交流！