DevPawDEVPAW · GROUND-UP DEV NOTES
搜索
菜单
ZH-HANS
한국어English日本語繁體中文EspañolPortuguês简体中文
AI 编程与智能体

[MCP·Skill #2] AI 代理 Skill 完整解析：从斜杠命令到自动触发

使用 AI 编程工具时，我们经常会重复相同的指令，比如“提交信息使用这种格式”或“部署前按这份检查清单执行”。

5 分钟阅读
[MCP·Skill #2] AI 代理 Skill 完整解析：从斜杠命令到自动触发 封面图

使用 AI 编程工具时，我们经常会重复相同的指令，比如“提交信息使用这种格式”或“部署前按这份检查清单执行”。

每次都在提示词中解释会很冗长，全部放进 CLAUDE.md 或 AGENTS.md 这类常驻规则文件，又会让每个会话的上下文变得沉重。

Skill 就是为了解决这种重复。简单来说，它把特定任务的流程和知识打包成文件，只在需要时加载。

它最初是 Claude Code 的功能，但现在已不再专属于某个工具。2025 年 12 月，Anthropic 以 Agent Skills 的名义公开了规范，将其作为开放标准；此后，OpenAI Codex、Gemini CLI、Cursor、VS Code（GitHub Copilot）等 30 多个工具都采用了相同格式。也就是说，创建一次的 SKILL.md 即使更换工具也能继续使用。

本文将整理 Skill 的结构、斜杠命令和自动触发这两种调用方式、各工具的支持情况，以及它与常驻规则文件的职责划分。示例以最早引入此功能的 Claude Code 为主，但概念在任何工具中都相同。

先来看核心总结。

  1. Skill 是从一个 SKILL.md 文件开始的指令文件夹，如今已成为不受工具限制的开放标准
  2. 调用方式有两种：用户直接调用的斜杠命令，以及模型自行调用的自动触发
  3. 核心设计是渐进式加载。通常只加载名称和描述，执行时才读取正文
  4. 始终适用的规则放入 CLAUDE.md、AGENTS.md 等常驻规则文件，特定任务的流程则放入 Skill

Skill 的本质是一个 Markdown 文件夹

Skill 的结构很简单：一个文件夹中包含一个 SKILL.md，就满足最低要求。

---
name: release-note
description: 编写版本说明草稿。用于“版本说明”或“部署说明”等请求
---

# 版本说明编写流程
1. 收集上一个标签之后的提交
2. feat/fix/chore进行分类
3. 按对用户的影响排序并编写草稿

顶部 frontmatter 中的 name 和 description 是注册信息，下面的正文则是实际流程。还可以在文件夹中加入参考文档或脚本，将其扩展为“指令手册 + 工具箱”。

标准只定义到这种格式。文件从哪个文件夹读取由各工具决定，因此只需了解主要使用工具的路径即可。

工具 Skill 目录
Claude Code ~/.claude/skills/（全局）、프로젝트/.claude/skills/（项目）
OpenAI Codex .agents/skills/
Gemini CLI (Antigravity) ~/.gemini/antigravity/skills/

放入项目文件夹后，可以通过 Git 与团队成员共享，这在实际工作中特别有用。工作经验不再是个人笔记，而会成为仓库资产。即使团队成员使用不同的编程代理，也能读取同一个 SKILL.md，无需统一工具即可共享流程。

两种调用方式：手动与自动

Skill 的执行路径分为两种。

第一种是斜杠命令。用户像 /release-note 这样直接输入，显式调用它。由人决定何时执行。

第二种是自动触发。模型查看对话内容后判断“这个请求归那个 Skill 负责”，然后自行加载。判断依据就是 frontmatter 中的 description。

description 不是面向人的说明，而是面向模型的路由条件。越具体地写明“何时使用这个 Skill”，并包含触发语句，自动调用就越准确。

无论直接调用还是自动触发，最终读取的都是同一个 SKILL.md
无论直接调用还是自动触发，最终读取的都是同一个 SKILL.md

这里渐进式加载（progressive disclosure）的设计很重要。会话开始时，进入上下文的只有每个 Skill 的名称和一行 description。完整正文只有在该 Skill 实际被调用时才会读取。

因此，即使注册几十个 Skill，平时的上下文负担也几乎不会增加。这正是与把所有流程塞进常驻规则文件的决定性区别。许多厂商采用这种格式的主要原因也在于渐进式加载，因为上下文窗口对任何模型来说都是昂贵资源。

与常驻规则文件划分职责

每种工具都有自己的“始终读取的规则文件”，例如 Claude Code 的 CLAUDE.md、Codex 的 AGENTS.md 或 Cursor 的 rules。两者都是“提供给模型的指令”，很容易混淆。判断标准是适用时机。

  • 常驻规则文件（CLAUDE.md、AGENTS.md 等）：每个会话、所有任务都始终适用的规则，例如编码规范、禁止事项和项目背景
  • Skill：仅在执行特定任务时需要的流程，例如部署、评审和文档生成

问自己：“它是否必须始终成立？”如果是，就使用常驻规则文件；如果只在特定情况下成立，就使用 Skill。把始终适用的规则移到 Skill 后，在未触发时规则就会消失。反过来，把所有流程都放进常驻规则文件又会浪费上下文。

Skill 的本质就是在编辑器中打开的一个 Markdown 文件
Skill 的本质就是在编辑器中打开的一个 Markdown 文件

创建时容易遇到的问题

先记住实际使用中最常遇到的两个问题。

自动触发不起作用时，几乎总是 description 的问题。如果只写“文档编写助手”这种抽象描述，模型无法判断何时使用。列出真实用户可能输入的语句会更有效。

相反，如果触发过于频繁，可以在 description 中明确排除条件，例如“仅在……时使用，简单问题不要使用”。

这个技巧适用于任何工具。因为自动触发的判断主体最终都是模型，而模型看到的只有一行 description；这一结构在标准层面是相同的。

总结

Skill 归根结底是把提示词函数化。与其复制粘贴重复指令，不如给它命名并保存，只在需要时加载。如今，这个函数也已成为不依赖特定工具的标准格式。

只要曾经把同一条指令输入过两次，它就是第一个 Skill 候选。今天创建的 SKILL.md，明年无论使用哪个代理都会跟随你。

延伸阅读