4. Skills and slash commands — 哪些重复值得压缩成一行

这是 Alice Way 系列的第 4 篇。第 2 篇 人格设计 和第 3 篇 记忆系统 涵盖了心智在哪里被刻写和保存。本篇涵盖下一层——如何把心智的重复动作压缩成一行。

0. Skill 把反复出现的心智动作凝结成一行

操作者心智中有两种内容。一种是「我现在需要决定什么」。另一种是「我要通过什么流程展开那个决定」。前者每次都在变。后者往往是一样的。

如果同一套流程每天重复，而你每天都用同样的话向协作者解释它，那个流程已经凝结成了一种心智模式。凝结的动作应该有一个一行的名称。

Skills 和 slash commands 就是那个名称。它们把反复出现的心智动作凝结成单词调用。 名称的存在，让同一套流程不必每次都用语言重新展开。

本篇汇集了哪些重复值得那个名称、以及如何设计那些名称的标准。

我认为 skills 的积累效果不在单个节省，而在网络效应。以前每个流程各自独立；如今 skills 互相调用，因为那个调用链让操作者的心智以更大单元运作。

"Skill"机制本身借鉴自 Anthropic Claude Code 的 Skill 系统。本篇是如何使用那个机制的记录，而非对它的发明。

1. 晋升标准 — 哪些重复成为 skills

并非每个日常流程都应该成为 skill。只有通过以下全部五条的才能得到一行名称。

1.1 它已经重复了至少两次吗？

一次是巧合。两次是模式。同一套流程必须至少运行过两次才有资格。

这条标准是最简单的，也是最常被违反的。它阻断了「我可能会经常做这个，先做一个 skill」的冲动。未来的重复是猜测；过去的重复是事实。只在事实基础上晋升。

1.2 开始和结束有明确定义吗？

Skill 需要明确的开始和结束条件。「进入项目」、「关闭会话」、「lint 后构建」——这些有清晰的边界。「写代码」在任何方向上都没有，也不会成为 skill。

没有清晰的边界，协作者不知道调用后在哪里停止。结束条件模糊的 skill 每次都要由操作者手动叫停。

1.3 调用时机是可判断的吗？

调用有两种形式。操作者有意识地（slash commands）或系统驱动地（hooks——下一篇）。无论哪种，调用时机必须是可判断的。

「视情况而定」不是 skill。那把判断权每次都还给协作者，而那个判断本身就需要新的心智。

1.4 输入是相同的（或只有简单参数）吗？

输入必须简单。要么没有参数，要么一两个简短的参数。多个参数会把填写参数本身变成一套新流程——节省就消失了。

1.5 结果可以一致地验证吗？

运行后，skill 应该让协作者能够自我验证结果。"成功"、"失败"、"前提条件缺失"这样的信号需要清晰。

无法验证结果的 skill 意味着操作者每次都要手动检查。一半的收益在那里蒸发了。

2. Skills · slash commands · 函数 — 分离角色

三者都减少重复，但扮演不同角色。

Skill 是共享的流程定义，slash commands 和 hooks 都可以调用。同一个 /verify 流程可以由操作者输入，也可以在「完成」报告前由 hook 自动触发。两条路径指向同一个 skill。

如果这个分工不清晰，要么所有自动化都变成函数，协作者的上下文感知被闲置；要么所有东西都变成 slash command，操作者不得不手动调用每一个。

3. 实际轮转中的 skills — 积累效果

我每天调用的一部分 skills。

3.1 /start <project> — 进入项目

进入指定项目，自动加载 README.md、CLAUDE.md、HANDOFF.md、PLAN.md，然后在一个视图中报告当前 git 状态和上次会话交接。停止等待操作者的下一条指令。

没有这个 skill，每次进入都需要操作者展开「去那个文件夹，读 README，读 HANDOFF，检查 git 状态，给我看最后一次提交信息」。压缩成一个词。

3.2 /session-end — 关闭会话

写工作日志，更新 HANDOFF.md（系统自动加载的下一次会话交接），提交，推送——一气呵成。不再拼写「把今天总结进 history.md，把下一次会话需要的内容写进 HANDOFF，提交，推送」。

3.3 /verify — 验证循环

代码修改后，自动运行 lint、构建、测试、安全检查、diff 审查。通过前不能发出"完成"报告。系列后文详细介绍。

3.4 /council — 四视角并行分析

对于真正模糊的决策，并行运行架构师、怀疑论者、实用主义者、批评者视角并综合结果。这个模式改编自 Andrej Karpathy 对 LLM 推理的多视角批评方法。

3.5 积累效果

这些 skills 本身都不是什么重大发明。但当大约 30 个一行名称每天被调用时，操作者花在用语言展开流程上的时间几乎消失了。操作者的心智只需专注于「我现在需要决定什么」；名称负责「如何展开那个决定」。

4. 设计原则 — 构建 skill 时我坚守的

我收敛出来的 skill 设计原则。

4.1 幂等

用同样的参数调用两次，应该产生相同的结果，或者至少不会破坏。非幂等的 skill 让操作者每次都要想"现在调用它安全吗"。那是新的心智税。

4.2 快速失败

如果前提条件不满足，skill 在第一行就停下来，给出清晰的消息。"这个目录不是 git 仓库。运行 git init 后再试。"处于中间状态的半执行 skill 是最危险的。

4.3 简短输出

Skill 结束时，输出应该简短。"OK: pushed 3 files"，一行。详细日志只按需提供，在选项后面。长输出迫使协作者每次都要总结，操作者也要重新阅读。

4.4 声明副作用

如果 skill 改变外部状态——写文件、发网络请求、推送——这个事实在 skill 定义顶部声明。「此 skill 会推送到 origin。」操作者在调用前应该知道这一点。

4.5 单一职责

Skill 做一件事。不要把「并且也安装依赖」塞进 /start。那是另一个 skill。单一职责被打破时，名称就不再描述动作了。

5. Skills 积累时 — 网络效应

单个 skill 的价值是节省时间。但当 30 个 skills 积累起来，更大的事情发生了。Skills 开始互相调用。

例如：

• /session-end 内部调用 /verify——未验证的变更不会被推送
• /start 自动刷新记忆索引
• /council 在决策后建议调用 /btw（决策队列处理）

当每个 skill 可以通过定义良好的接口调用其他 skills 时，操作者的心智以更大的单元运作。「结束今天的工作」这一个决定，内部展开成 7 或 8 个 skill 调用。操作者不必意识到那 7 或 8 个。

这是积累 skill 集的真正价值。节省时间是副作用；心智能够以更大单元运作才是本质。

6. 不要 skill 化的东西 — 陷阱

晋升标准的另一面。以下内容作为 skill 会亏本。

6.1 可能只运行一次的流程

「这次迁移只运行一次，让我写个脚本。」那不应该成为 skill。一次性流程运行一次就消失。作为 skill，它成了维护负担，六个月后你在努力回忆它是什么。

6.2 上下文依赖很重的东西

「审查这段代码」无法成为 skill，因为每次调用都需要不同的上下文。如果把上下文作为参数，最终还是要每次拼写出来，好处也就蒸发了。

6.3 把心智本身外包出去

「告诉我我应该决定什么」不是 skill。那把操作者的心智外包出去了，操作者随后就不再是决策的主人。

Skill 辅助操作者的心智；不替代它。

6.4 变化太频繁的流程

Skill 一旦定义，应该能持续数天。每周都在变化的流程不会凝结。如果凝结了，下周就会崩溃。

7. 演进模式 — Skill 如何被打磨

我观察到 skill 的自然生命周期。

1. 发现重复：同一套流程拼写了两次或更多 → 候选
2. 手动写下来：在 README 或笔记中列出步骤 → 可手工执行
3. Skill 化：步骤稳定后，压缩成 slash command 或 skill 定义
4. 飞行中打磨：在实际使用中发现边缘情况，修复
5. 外部可调用：清理接口，让其他 skills 可以调用它
6. 晋升或降级：大量使用 → 在人格中添加自动触发（下一篇关于 hooks）/ 不使用 → 降级外部或删除

没有经历这个循环的 skills 活不长。它们容易制作，难以维护，所以需要自然选择。

下载 — /verify skill

第 7 篇中的七步验证循环，打包成一个 slash-command skill 文件。这是将反复执行的流程压缩为一行调用的典型示例——把其中的构建/测试命令换成你自己的即可。

shasum -a 256 verify.md
# expected: 8cabf33a2711a0501ee3f65f630bc49868a710cfa973910b7c33e253091dea12

8. 压缩成一条原则

Skill 和 slash command 设计的核心压缩成一句话：

「只给反复出现的心智动作起一行名称。其他一切都拼写出来。」

这条成立时，skill 集成为操作者心智的加速器。它崩溃时——skills 建立得太早，或过于复杂——它们反而成为操作者每次都要思考的开销。

下一篇涵盖与 skills 配对的另一半——Hooks and automation，即系统无需操作者调用就自动触发的流程。