01 · 什么是 Skill

系统提示词的膨胀问题

到第 6 章结束时，系统提示词已经包含了很多内容：角色定位、工具列表、工作方式、行为准则、项目规则、会话上下文。每次调用模型，这些内容全部发过去。

问题是：不是所有任务都需要所有指令。

用户让 agent "修复一个 bug"，它不需要代码审查的规则。用户让 agent "review 这段代码"，它不需要 debug 的步骤指南。但现在的系统提示词是"一刀切"——不管什么任务，都给模型同样的指令。

这有两个坏处：

• 浪费 token。 不相关的指令占用了上下文空间，增加成本。
• 干扰判断。 太多指令会让模型困惑——"我到底该按 debug 模式还是 review 模式工作？"

Skill：按任务类型分发指令

解决思路很简单：根据任务类型，只注入相关的指令。

这就是 Skill 的概念。一个 Skill 是针对某类任务的专门指令集合，包含规则、步骤、约束和输出要求。

没有 skill 时：
  系统提示词 = 通用指令 + 所有任务的规则（混杂在一起）

有了 skill 后：
  系统提示词 = 通用指令 + 当前任务类型的专门规则（精准匹配）

类比一下：通用指令像是一份"员工手册"，告诉模型基本的角色和工作方式。Skill 像是"专项培训材料"——debug 任务就给 debug 培训，review 任务就给 review 培训。

Skill 的结构

在 src/skills/types.ts 中定义 Skill 的结构：

export interface Skill {
  /** 技能名称，用于标识和匹配 */
  name: string;
  /** 简短描述 */
  description: string;
  /** 触发关键词，用于自动匹配用户任务 */
  keywords: string[];
  /** 注入到系统提示词中的指令内容 */
  instructions: string;
}

四个字段各司其职：

• name：标识。用户可以用 /debug 显式选择，系统也用它来区分不同 skill。
• description：给人类看的说明。在 /skills 列表中展示。
• keywords：自动匹配的关键词。当用户说"帮我修复这个 bug"时，"bug" 匹配到 debug skill。
• instructions：给模型看的指令。匹配到 skill 后，这段文字会被注入到系统提示词中。

和大 prompt 的区别

为什么不直接把所有规则都写在系统提示词里？

可维护性。 一个 2000 字的系统提示词很难维护——改一处可能影响其他部分。把规则拆成独立的 skill，每个 skill 独立维护，互不影响。

精准性。 大 prompt 里什么都有，模型可能被不相关的规则干扰。Skill 只在需要时注入，模型拿到的是精准的、和当前任务相关的指令。

可扩展性。 添加新能力只需要注册一个新 skill，不需要修改系统提示词或 agent 代码。例如将来要加一个 "test" skill（专门写测试），只需要新建一个 skill 定义文件。

可复用性。 同一个 skill 可以在不同项目中使用。团队可以把常用的 skill 做成配置文件，在项目间共享。

和项目规则（AGENTS.md）的区别

第 6 章实现了项目规则加载（AGENTS.md），第 7 章实现了 skill。两者都往系统提示词中注入额外的指令，但用途不同：

项目规则回答的是"这个项目有什么特殊要求"。Skill 回答的是"这种任务应该怎么做"。两者正交，可以同时生效。

下一节会设计三个内置 skill。