Star-Studio

如果你想让 AI 完成一项专业任务，你会怎么做？

传统方式是：不断向 AI 解释规则、提供示例、纠正错误，直到它理解你的需求。这个过程在每个新任务中都要重复一遍。

但如果有一种方式，能让你把专业知识打包成一个「能力扩展包」，AI 可以随时加载使用呢？

这就是 Agent Skills 要解决的核心问题：如何将专业知识、工作方法和可用资源封装成可复用的能力模块，让通用 AI Agent 能够稳定完成特定任务。

这不是一个新问题。在此之前，已经有 Workflow 平台（Coze、Dify、N8N）和程序化开发两种方式。但 Skills 以一种全新的架构设计，提供了零代码、高智能上限的解决方案。

Skills 的本质

定义与类比

Anthropic 对 Skills 的定义是：模块化的能力扩展，每个 Skill 打包了 LLM 指令、元数据和可选资源（脚本、模板等），Agent 会在需要时自动使用它们。

这个定义略显抽象。一个更直观的理解方式是：Skill 就像给新同事准备的「工作交接 SOP 大礼包」。

想象你要把一项工作交给新同事，而且只能通过文档一次性交接完成。你会准备什么？

任务的执行 SOP 与必要背景知识
工具的使用说明
要用到的模板、素材
可能遇到的问题和解决方案

Skill 的设计架构，几乎是这个交接大礼包的数字版本：

my-skill/
├── SKILL.md           # 执行 SOP（必需）
├── scripts/           # 工具脚本
├── reference/         # 参考文档
└── assets/            # 模板素材

当 Agent 运行某个 Skill 时，会：

以 SKILL.md 为第一指引
判断何时需要调用代码脚本
翻阅参考文档
使用素材资源
通过「规划-执行-观察」的循环完成任务

与其他方案的区别

为了更好地理解 Skills 的定位，我们需要把它和常见的两种方案对比。

Workflow 平台（Coze/Dify/N8N）

这类平台的可视化节点系统本质上仍是「编程」，只是界面更友好。你需要理解节点配置、条件分支、数据流等概念。而且 Workflow 的核心问题是：它们假设所有情况都能预设。

一旦遇到预设之外的情况（用户上传了意外的文件格式、数据字段不符、出现了边缘问题），Workflow 就只能报错或要求用户自行解决。

程序化开发

传统开发的灵活性更高，但门槛也最高。你需要懂程序逻辑、技术实现、系统架构。开发一个垂直 Agent 至少需要数周时间。

Skills 的独特之处

Skills 结合了两者的优势：

零代码、自然语言编写
能突破预设限制，灵活应对边缘情况
通用 Agent 提供智能，人提供专业知识

关键区别在于：Workflow 或传统程序假设所有情况都能预设，而 Skills + Agent 的运作方式是「人给出专业知识与工具方法，通用 Agent 提供智能，自主理解，主动执行」。

这意味着 Agent 能根据自己的智力看着执行，遇到意外情况时能推理解决，而不是卡在预设路径上。

与 MCP 的关系

这是最常见的疑惑：Skills 和 MCP 有什么区别？

一句话总结：MCP 给 Claude 供给数据，Skills 教 Claude 如何处理这些数据。

MCP（Model Context Protocol）是一种开放标准的协议，关注的是 AI 如何以统一方式调用外部的工具、数据和服务。它本身不定义任务逻辑或执行流程。

Skill 则教 Agent 如何完整处理特定工作。它将执行方法、工具调用方式以及相关知识材料，封装为一个完整的「能力扩展包」。

以一个具体的任务为例：

场景：分析公司的销售数据并生成报告

MCP 的作用：连接数据库，查询昨天的销售记录
Skill 的作用：教 AI 如何分析这些数据（先用中位数而非平均值、异常值如何筛选、图表按什么配色方案制作）

实际上，Agent Skill 也能连接数据，功能上与 MCP 有重叠。但「能干」不代表「适合干」。

MCP 本质上是一个独立运行的程序，在代码执行的安全性和稳定性方面更优
Agent Skill 本质上是一段说明文档，更适合跑轻量的脚本和处理简单的逻辑

因此在很多场景下，我们需要把 Agent Skill 和 MCP 结合使用，以便尽可能满足需求。

Skills 的核心运行机制

理解 Skills 的价值，需要深入其运行机制。这部分内容对理解 Skills 的工作原理至关重要。

渐进式披露的三层结构

Skills 的设计采用了一个精密的渐进式披露结构，包含三个层级，每层的加载机制都不同。

这是理解 Skills 为什么能够「既强大又高效」的关键。

Level 1：元数据层（始终加载）

包含所有 Skill 的名称（name）和描述（description），大约 100 tokens。

Agent 启动时，就会在 Context Window 中加载 Skill 元数据，将其包含在系统提示中。AI 通过理解用户消息与 Skills 元数据的匹配情况，判断是否需要自动使用技能。

这层设计的意义：

默认只加载元数据，意味着可以给一个 Agent 同时安装很多 Skills，但不影响上下文性能。就像你书架上有很多书，但只有在你需要时才会打开某一本阅读。

示例：

---
name: pdf
description: 全面的 PDF 操作工具包，用于提取文本和表格、创建新 PDF、合并/拆分文档以及处理表单
---

Level 2：指令层（按需加载）

包含 SKILL.md 文档内的正文内容，也就是主要技能指令，一般包含工作流程、最佳实践和指导。建议少于 5000 tokens。

当用户发出的消息与 Skill 元数据的描述匹配，需要调用 Skill 时，Agent 才会用 bash 读取文档正文。读取时文档内容才加载到 Context Window 中。

这层设计的意义：

「按需加载」确保了只有相关的 Skill 指令才会进入上下文。如果你有 20 个 Skills 但当前任务只需要其中 1 个，那么只有这 1 个 Skill 的完整内容会被加载。

Level 3：资源层（按需动态加载）

由子技能文档、代码脚本、参考文档、可用资源等文件构成。这一层是「按需中的按需」，只有在指令层中明确指定需要时，才会被加载。

子技能文档（Sub-SKILL.md）

当一个 Skill 的复杂度提升，可能因为技能知识的上下文过长，或者有些知识仅在特定场景使用，不适合放入单个 SKILL.md，可被分拆为独立指令文档。

例如 PPTX Skill 中，「如何将 HTML 导出为 PPTX」这个独立流程被拆分为 html2pptx.md，只有在需要执行这个操作时才会被加载。

代码脚本（Scripts）

视作「Agent 的可执行资源」，而不算 tool use（tool use 是 Agent 外部调用的独立服务）。Agent 在 Agent 电脑（虚拟机）中直接调用脚本，脚本代码本身不进 Context Window，只有脚本运行完成后的输出会进 Agent 的 Context。

参考文档（Reference）和可用资源（Assets）

这些都是 Level 3，仅在必需时动态读取加载。因为按需加载的特性，文件在被访问前不会占用 Context 长度，所以没有内容大小限制，可按业务实际需要添加材料。

Reference 和 Script 的区别

虽然在 Level 3 中都属于「按需加载」，但 Reference 和 Script 的加载方式截然不同。

Reference 是「读」

文件内容会被加载到上下文中，供 Agent 参考使用。所以会消耗 token。

一个典型的应用场景是：会议总结 Skill 中，只有当会议内容提到「钱」或「财务」时，才会加载「集团财务手册」，用于检查会议决定的金额是否超标、审批人是谁。

如果是技术复盘会，这个财务文件就只会躺在硬盘里，绝不占用哪怕一个 token 的上下文。

Script 是「跑」

代码只会被执行，不会被读取。这意味着，哪怕你的脚本写了一万行复杂的业务逻辑，他消耗的模型上下文也几乎是 0。

Cloud Code 只关心脚本的运行方法和运行结果，至于脚本的内容，可以说是毫不在意。

一个典型的应用场景是：会议总结完成后，如果用户提到「上传」或「发送到服务器」，Agent 会自动运行 upload.py 脚本，将总结内容上传到服务器。

关键区别：

Reference：条件触发，被读取，会消耗 token
Script：条件触发，被执行，几乎不消耗 token

这带来了一个重要启示：如果你的 Skill 需要处理大量固定逻辑（比如复杂的计算、数据处理），应该写成 Script 而不是在 SKILL.md 中用自然语言描述。这样可以让 Agent 快速执行，而不需要消耗大量 token 去推理。

动态上下文注入

Skills 支持一个强大的特性：动态上下文注入。

使用 !command`` 语法，可以在 Skill 内容发送给 Claude 之前运行 shell 命令，命令输出会替换占位符。

应用场景：Pull Request 总结

这个 Skill 总结一个 Pull Request，通过 GitHub CLI 获取实时 PR 数据：

---
name: pr-summary
description: Summarize changes in a pull request
allowed-tools: Bash(gh:*)
---
 
## Pull request context
- PR diff: !`gh pr diff`
- PR comments: !`gh pr view --comments`
- Changed files: !`gh pr diff --name-only`
 
## Your task
Summarize this pull request...

当这个 Skill 运行时：

每个 !command`` 立即执行（在 Claude 看到任何内容之前）
输出替换 Skill 内容中的占位符
Claude 收到完全渲染的提示词，包含实际的 PR 数据

这是预处理，不是 Claude 执行的内容。Claude 只看到最终结果。

这个特性的价值在于：可以让 Skill 始终使用最新数据，而不需要手动复制粘贴。

Skill 的两种调用模式

显式调用

用户直接通过 /skill-name 或 /skill-name arguments 的方式调用。

这种方式适合：

明确知道要执行某个任务
工作流类的 Skill（如 /commit、/deploy）
需要特定参数的任务

示例：

/explain-code src/auth/login.ts
/fix-issue 123
/deploy production

隐式调用

Agent 根据任务与 Skill 元数据中 description 的匹配情况，LLM 自动判断是否需要加载某个 Skill。

这种方式适合：

知识类的 Skill（如 API 规范、代码风格指南）
不确定用户需求的具体场景
辅助性的专业知识

示例：

用户问「这段代码是怎么工作的？」，Agent 会自动加载 description: Explains code with visual diagrams and analogies 的 Skill。

用户问「帮我总结这个会议」，Agent 会自动加载 description: Summarize meeting transcripts 的 Skill。

Skills 的真实价值

理解了运行机制后，我们需要探讨：Skills 到底能解决什么实际问题？它的价值上限在哪里？

零代码、高智能上限

纵观此前的 AI 应用开发方法：

程序编写的 AI 应用：必须懂程序逻辑、懂技术实现
Workflow 平台：得理解节点配置、条件分支，仍算「编程」，只是界面友好一些

而 Skills 的创建门槛完全不同：入门门槛极低，智能上限极高。

最简单的：纯文本 Skill

Anthropic 的 brand-guidelines skill 只有一个 SKILL.md，纯自然语言写成，包含品牌颜色、字体等文本描述信息。

但足以引导 Agent 变成符合 Anthropic 品牌设计的垂直 Agent，可用于品牌官网、海报、PPT 设计。

当你要设计一个符合 Anthropic 公司设计规范的 AI 搜索网站，Agent 就会自动运行该 Skill，一次性生成调性接近 Claude 官网设计的网站。

复杂的：一个 Skill 就是一个完整 Agent

以 AI-Partner Skill 为例，包含 SKILL 文档、向量数据库构建指南、向量数据库使用脚本、AI 伴侣与用户的 Persona 模板资源。

SKILL.md 本体依然由自然语言写成。Agent 能理解 AI-Partner 的初始化与对话方法：

引导用户上传包含个人记忆的文档语料
在用户端智能切分笔记片段
构建向量数据库
解析用户记忆文档，提炼个性化的 AI 伴侣与用户画像设定
最终智能检索用户记忆，提供懂你的 AI Partner 对话体验

这能验证：单靠 Skill + Agent 所构造的垂直 Agent，所实现的智能效果，无异甚至可超过同类 AI 产品。

而做这些垂直 Agent，都不用编写程序代码。

非技术出身的领域专家，离自己做专业 Agent 只剩隔着一层窗户纸——把你的专业经验和工作流程，用文档形式写清楚，Agent 就能照着执行。

突破预设限制，灵活应对实际情况

Skills 的这一优势往往被忽视。

Workflow 或传统程序的核心问题是：它们假设所有情况都能预设。

比如基于用户记忆的 AI 个性化助理，往往需要提前设定：

用户导入记忆文件的入口
允许用户上传的文件格式
数据应该包含哪些字段
以及可能出现哪些特殊情况，每种情况如何处理

但现实往往是：

需要教育用户在哪点击「导入」
用户只有预期之外的格式：预期支持 md，但实际只有 doc
数据字段不符：预期每个文件需要一个标题，但用户文件没有标题
或者出现了预设之外的边缘情况

这时 Workflow 或传统程序就卡住了，它只能按预设路径执行，遇到意外就报错，或要求用户自行消除差距。

而通用 Agent + Skill 应用的运作方式完全不同：

能在统一的对话框，接收各类用户数据（文本、文件、图片）
能自主调用其他 Skill，或即时编写 doc2md 脚本，自动转换用户格式
能提炼补充每个文件的标题，完成数据入库处理
能基于 LLM 的推理智能，弥合各类边缘问题

用 Skill 做的垂直 Agent，以 Skill 的知识与方法为指引，能巧借 Agent 内的 LLM 智能，灵活应对各类问题。

一个实际的例子：

在 AI-Partner-Chat 中，有一个很有意思的设计：借 Agent 本身的「观察-规划-执行」的动态智能，对用户文档进行自适应切片，而非所有文件都按照固定的分隔符或字数切分。

DailyNotes 按照日期标题切分
项目笔记按照标题级别与语义切分

这样能得到更符合实际情况的 RAG 切片。

这种自适应的处理方式，是传统预设程序难以实现的。但有了 LLM 的推理能力 + Skill 的方法指引，Agent 就能根据实际情况灵活调整。

多 Skills 自由联用

Agent Skills 实质仍是 Context 工程，Skills 只是把垂直领域的知识、脚本调用方法等挂载到 Agent 的上下文窗口。

所以 Skills 在实际应用中极其灵活，甚至在一次任务中能调用多个 Skill。

简单组合：

联用 brand-guidelines + pptx，自动制作符合品牌规范的 pptx
联用 AI-Partner-Chat + Article-Copilot，写出更符合个人思考与文风的内容

复杂场景：做一份产品分析报告

从网页抓取竞品数据（Web Scraping Skill）
提取 PDF 中的用户反馈（PDF Skill）
分析数据并生成图表（Data Analysis Skill）
按品牌规范制作 PPT（Brand Guidelines + PPTX Skill）

每多一个 Skill，就多一种能力，N 个 Skill 可以应对远超 N 的应用场景。

一个重要洞察：

Skills 的价值不是简单的「1 + 1 = 2」，而是「N 个 Skill 可以应对远超 N 的应用场景」。因为不同 Skill 的组合可以创造出新的能力，而且 Agent 的推理智能能够在组合中找到最佳的执行路径。

创建和使用 Skills

理解了概念和价值后，我们进入实践部分。

Skills 的存放位置

Skills 可以存放在不同位置，作用范围也不同：

位置	路径	作用范围
Enterprise	管理设置配置	组织内所有用户
Personal	`~/.claude/skills/<skill-name>/SKILL.md`	所有项目
Project	`.claude/skills/<skill-name>/SKILL.md`	当前项目
Plugin	`<plugin>/skills/<skill-name>/SKILL.md`	插件启用时

优先级顺序： enterprise > personal > project

Plugin skills 使用 plugin-name:skill-name 命名空间，避免冲突。

创建第一个 Skill

我们用一个实际的例子演示：创建一个「会议总结助手」Skill。

Step 1：创建 Skill 目录

mkdir -p ~/.claude/skills/meeting-summary

Step 2：编写 SKILL.md

每个 Skill 都需要一个 SKILL.md 文件，包含两部分：

YAML frontmatter（在 --- 标记之间）：告诉 Claude 何时使用这个 Skill
Markdown 内容：Skill 被调用时遵循的指令

创建 ~/.claude/skills/meeting-summary/SKILL.md：

---
name: meeting-summary
description: 总结会议录音内容，提取参会人员、议题和决定。当用户要求总结会议或分析会议记录时使用。
---
 
# 会议总结助手
 
当总结会议内容时，必须包含以下部分：
 
1. **参会人员**：列出所有参与会议的人员
2. **讨论议题**：总结会议讨论的主要话题
3. **做出的决定**：明确记录会议达成的决定和行动项
4. **待办事项**：列出需要跟进的任务，包括负责人和时间节点
 
## 输出格式
 
使用以下格式输出：
 
---
**参会人员**：[人员列表]
 
**讨论议题**：
- [议题1]
- [议题2]
 
**做出的决定**：
- [决定1]
- [决定2]
 
**待办事项**：
- [ ] [任务1] - [负责人] - [截止日期]
- [ ] [任务2] - [负责人] - [截止日期]
---
 
## 注意事项
 
- 如果会议中涉及金额，请务必标注
- 如果会议中涉及法律或合规问题，请添加风险提示
- 保持客观，不添加个人观点

Step 3：测试 Skill

有两种测试方式：

让 Claude 自动调用：

总结以下会议的内容
[粘贴会议录音文本]

直接调用：

/meeting-summary [粘贴会议录音文本]

进阶：添加 Reference 和 Script

添加 Reference（参考文档）

假设我们想让会议总结在涉及金额时，能够自动检查是否符合财务规定。

创建 ~/.claude/skills/meeting-summary/reference/财务手册.md：

# 集团财务报销标准
 
## 住宿补贴
- 一线城市：500元/晚
- 二线城市：400元/晚
- 三线城市：300元/晚
 
## 餐饮费
- 早餐：50元/人
- 午餐：100元/人
- 晚餐：150元/人
 
## 审批权限
- 5000元以下：部门经理审批
- 5000-20000元：总监审批
- 20000元以上：副总裁审批

然后修改 SKILL.md，添加财务提醒规则：

---
name: meeting-summary
description: 总结会议录音内容，提取参会人员、议题和决定
---
 
# 会议总结助手
 
[原有的会议总结指令...]
 
## 财务提醒规则
 
**仅在会议内容提到「钱」、「费用」、「预算」、「支出」等关键词时触发：**
 
1. 读取 [reference/财务手册.md](reference/财务手册.md)
2. 检查会议决定的金额是否符合财务规定
3. 如果超标，明确标注并指出审批人
4. 在总结中添加「财务提醒」部分

关键点：

财务手册只有在会议内容提到钱时才会被加载
如果是技术复盘会，这个文件就只会躺在硬盘里，不占用任何 token
这就是「按需中的按需」的典型应用

添加 Script（可执行脚本）

假设我们想在会议总结完成后，能够自动上传到服务器。

创建 ~/.claude/skills/meeting-summary/scripts/upload.py：

#!/usr/bin/env python3
import requests
import sys
from datetime import datetime
 
def upload_to_server(summary_content):
    """上传会议总结到服务器"""
    url = "https://your-server.com/api/meeting-summary"
 
    payload = {
        "content": summary_content,
        "timestamp": datetime.now().isoformat(),
        "source": "meeting-summary-skill"
    }
 
    response = requests.post(url, json=payload)
 
    if response.status_code == 200:
        print(f"✓ 上传成功：{response.json().get('url')}")
        return True
    else:
        print(f"✗ 上传失败：{response.status_code}")
        return False
 
if __name__ == "__main__":
    summary = sys.stdin.read()
    upload_to_server(summary)

然后修改 SKILL.md，添加上传规则：

---
name: meeting-summary
description: 总结会议录音内容，提取参会人员、议题和决定
---
 
# 会议总结助手
 
[原有的会议总结指令...]
 
## 上传规则
 
**仅当用户明确提到「上传」、「发送到服务器」、「同步」等关键词时：**
 
1. 运行 `python scripts/upload.py`
2. 将会议总结内容通过 stdin 传递给脚本
3. 显示脚本执行结果

关键点：

upload.py 只会被执行，不会被读取
哪怕脚本有一万行代码，也几乎不消耗 token
Agent 只关心脚本的运行方法和结果

使用 Skill-Creator 加速开发

手动创建 Skill 虽然不难，但如果能有一个「创建 Skill 的 Skill」，会大大提升效率。

Anthropic 官方提供了 skill-creator，顾名思义，用来帮你自动开发 Skill 的 Skill。

安装 skill-creator

# 克隆官方 Skills 仓库
git clone https://github.com/anthropics/skills.git
 
# 复制 skill-creator 到你的 skills 目录
cp -r skills/skills/skill-creator ~/.claude/skills/

使用 skill-creator

在 Claude Code 中发送：

创建一个 skill，功能是：按照我的写作风格写文章

Agent 会自动调用 skill-creator，引导你完成：

收集你的写作样本
分析你的写作风格特点
编写 SKILL.md
创建必要的脚本和模板

最终生成一个完整的 Skill 包。

这个方法的价值：

你不需要了解 Skill 的所有细节
skill-creator 会帮你创建高质量的 SKILL.md
适合快速验证想法，之后再手动精调

控制 Skill 的行为

随着 Skill 数量的增加，你需要更精细地控制它们的行为。

控制谁可以调用 Skill

默认情况下，你和 Claude 都可以调用任何 Skill。但有时你需要更精确的控制。

只允许手动调用

设置 disable-model-invocation: true，只有你可以调用这个 Skill。

适用场景：

有副作用的操作（如 /deploy、/send-slack-message）
需要控制时机的任务（如 /commit）
不希望 Claude 自动触发的工作流

示例：

---
name: deploy
description: Deploy the application to production
disable-model-invocation: true
---
 
Deploy $ARGUMENTS to production：
 
1. Run the test suite
2. Build the application
3. Push to the deployment target
4. Verify the deployment succeeded

这样 Claude 不会因为「代码看起来准备好了」就自动部署。

只允许 Claude 调用

设置 user-invocable: false，只有 Claude 可以调用这个 Skill。

适用场景：

背景知识（如 legacy-system-context）
不适合作为命令执行的内容

示例：

---
name: legacy-system-context
description: 理解旧系统的架构和工作原理
user-invocable: false
---
 
这个旧系统使用的是...
[详细的系统说明]

这样 Claude 会在相关时自动加载这些知识，但用户无法通过 /legacy-system-context 直接调用。

限制工具访问

使用 allowed-tools 字段，可以限制 Skill 激活时 Claude 可以使用的工具。

创建一个只读模式的 Skill：

---
name: safe-reader
description: Read files without making changes
allowed-tools: Read, Grep, Glob
---

这样 Claude 在使用这个 Skill 时，只能读取文件，无法修改。

在 Subagent 中运行 Skill

添加 context: fork，可以让 Skill 在隔离的子 Agent 中运行。

适用场景：

需要独立环境的任务
不希望污染主对话上下文
需要使用特定 Agent 类型的能力

示例：

---
name: deep-research
description: Research a topic thoroughly
context: fork
agent: Explore
---
 
Research $ARGUMENTS thoroughly：
 
1. Find relevant files using Glob and Grep
2. Read and analyze the code
3. Summarize findings with specific file references

当这个 Skill 运行时：

创建一个新的隔离上下文
子 Agent 收到 Skill 内容作为任务
agent 字段决定执行环境（模型、工具、权限）
结果会被总结并返回到主对话

使用 Skills 的时机

理解了如何创建和使用 Skills 后，更重要的问题是：什么场景值得「用 Skill 来解决」、「开发一个 Skill」？

根据 Anthropic 官方建议和实际经验，有三种明显的信号。

发现自己在向 AI 反复解释同一件事

最典型的信号是：为了完成某个任务，在多轮对话中，需要不断向 AI 解释一件事应该怎么做。

场景示例 1：技术文档写作

「帮我写一份技术文档」
「不对，我们公司的技术文档格式是这样的……」
「还有，代码示例要按这个模板来……」
「上次不是说了吗，章节标题要三级标题……」

场景示例 2：数据分析

「帮我分析这个数据」
「先把 > XX 的异常值筛掉」
「不对，应该用中位数，不是平均值」
「图表要按我们公司文档的配色方案……」

这时候就该想到：与其每次都解释一遍，不如把这些规则打包成一个 Skill，一次创建永久复用。

发现某些任务需要特定知识、模板、材料才能做好

有时候 AI 的通用能力够了，但缺「特定场景的知识材料」。

典型场景：

技术文档写作：需要参考代码规范、术语表，使用文档模板
品牌设计：需要参考品牌手册、色彩规范，使用 Logo 资源
数据分析：需要参考指标定义、计算公式，使用报表模板

这些都是「通用 Agent + 垂直知识」的典型场景：人提供材料，Agent 才能具备场景 Context。

在 Skill 包里放对应的知识材料：

把模板、规范、案例放到 assets/、reference/ 目录
或者直接描述在 SKILL.md 中

Agent 就能一次性输出符合任务需要的精准结果。

发现一个任务要多个流程协同完成

有些任务更加复杂，往往需要「组合多个流程」才能完成。

场景示例：

竞品分析报告：检索竞品数据 + 数据分析 + 制作 PPT
内容生产：收集参考资料 + 学习风格 + 大纲协作 + 正文写作

把这类任务中每个环节的指令文档、可执行脚本、参考材料、可用资源打包成单个或多个 Skill，也是不错的 AI 解决方法。

让 Agent 根据任务描述，智能调用不同的 Skill 模块，通过「规划-执行-观察」的交错式行动，一次性完成原本需要多个流程协同完成的复杂任务。

最佳实践与注意事项

在实际使用 Skills 时，有一些最佳实践可以帮助你创造更好的 Skills。

SKILL.md 编写建议

保持简洁

建议 SKILL.md 不超过 500 行。移动详细参考材料到单独的文件。

清晰的 description

description 字段是 Claude 判断何时使用 Skill 的关键。包含用户会自然说的关键词。

不好的例子：

description: 处理文档

好的例子：

description: 从 PDF 提取文本和表格、创建新 PDF、合并/拆分文档以及处理表单

明确的触发条件

如果 Skill 包含多个功能，明确说明何时使用哪个功能。

## 触发条件
 
- 用户提到「合并 PDF」时，使用 merge 功能
- 用户提到「提取文本」时，使用 extract 功能
- 用户提到「填写表单」时，使用 fill 功能

提供示例

在 SKILL.md 中包含输入输出示例，帮助 Agent 理解期望的格式。

Reference 文档组织

按功能拆分

如果参考文档很长，按功能拆分成多个文件。

reference/
├── 财务规定.md
├── 法律合规.md
└── 技术规范.md

在 SKILL.md 中明确引用

## 额外资源
 
- 财务规定：参见 [reference/财务规定.md](reference/财务规定.md)
- 法律合规：参见 [reference/法律合规.md](reference/法律合规.md)
- 技术规范：参见 [reference/技术规范.md](reference/技术规范.md)

说明何时使用

## 财务规定
 
**仅在会议内容涉及金额、预算、费用时，读取 [reference/财务规定.md](reference/财务规定.md) 并：**
1. 检查金额是否符合规定
2. 标注审批权限
3. 添加风险提示

Script 编写建议

提供清晰的接口

在 SKILL.md 中明确说明如何调用脚本。

## 上传到服务器
 
当用户要求上传时，运行：
 
```bash
python scripts/upload.py --content "$CONTENT" --recipient "$EMAIL"

其中：

$CONTENT：会议总结内容
$EMAIL：接收人邮箱


**处理错误**

在脚本中包含错误处理，并提供清晰的错误信息。

```python
try:
    upload_to_server(content)
except Exception as e:
    print(f"✗ 上传失败：{str(e)}")
    sys.exit(1)

使用环境变量

敏感信息（如 API keys）应该从环境变量读取，而不是硬编码。

import os
 
api_key = os.getenv("SERVER_API_KEY")
if not api_key:
    print("✗ 缺少 SERVER_API_KEY 环境变量")
    sys.exit(1)

性能优化

使用 Script 替代复杂指令

如果你的 Skill 需要处理大量固定逻辑，应该写成 Script。

比如「将 Markdown 转换为 PDF」：

不推荐：在 SKILL.md 中详细描述转换步骤
推荐：编写一个 md2pdf.py 脚本，在 SKILL.md 中简单说明「运行此脚本」

好处：

执行速度快
不消耗 token
结果可预测

控制 Reference 的大小

虽然 Reference 文件理论上可以无限大，但实际上应该：

只包含必要的信息
按功能拆分
明确触发条件

避免「为了简单而把所有东西都塞进一个文件」，这样会浪费 token。

渐进式加载

充分利用 Skills 的三层结构：

Level 1：简洁的 name 和 description
Level 2：适中的指令内容（< 5000 tokens）
Level 3：大型参考文档和复杂脚本

不要把所有内容都塞进 Level 2。

Skills 对 AI 产品设计的影响

Skills 不仅是一个工具，更代表了一种新的 AI 产品设计范式。

AI Native 产品的特征

传统的软件产品逻辑是：输入 → 代码处理 → 输出。比如一个笔记 APP，你写的新笔记会被原模原样地直接入库。

但 AI Native 式的产品会不同：它们可能会内置一些类似 Skill 的指引。

以笔记 APP 为例：

笔记入库指引
智能纠错指引
冗余笔记合并指引

这些指引有些可能以 prompt 为主（需要生成），有些基本只有代码逻辑（快速响应）。

当用户写新笔记时，AI 快速自行判断：

能不能直接入库？
要不要智能纠错？
有没有冗余的历史相似笔记需要合并？

每种情况，都由 Agent 拿着各种 Skills 自动匹配来处理。

优势分析

统一的输入接口

Skills-based 的 Agent 产品，能用同一个多模态输入框，处理用户各种不同的输入。不需要为每种输入类型设计专门的 UI。

灵活应对边缘问题

能够灵活应对未被规划的边缘问题，为用户提供绝对个性化的生成需求。

降低开发成本

不必为了一个内部小工具开发完整产品，打包一个 Skill 就能解决。

不必说服 IT 团队理解你的需求，自己就能创建工具。

不必等待产品迭代，你可以随时调整 Skill 的行为。

性能与开销的平衡

基于 Skills 做的垂直 Agent 应用，会不会有依赖推理、响应速度降低的问题？

三个关键洞察：

Skills 是一种非常宽容的 Agent 设计架构

Skills 可以被设计为很多 tokens 的指令文档，引导模型思考；也可以是无需思考的简单指令，直接指向可直接运行的脚本代码。

因为 Skills 能直接调用代码逻辑

不进 Context 窗口。所以用 skill 也不需要 agent 一直推理，agent 也可以只承担类似 hook 的角色，实质上和正常程序运行并无差别。

两个趋势的极端判断

Token 价格会下降
Agent 速度会提升

所以，以 Skills 为基础的垂直 Agent，在性能、开销上的问题，也不是不可解决的持续性问题。

结论：Skills 慢起来可以是 prompt，快起来也可以是 workflow。

未来展望

现在还是 Skill 生态的早期，Agent Skills 开放标准发布不到一个月（2024年10月发布，12月成为开放标准），工具在完善，社区在成长。

这个方向有意思的地方在于：终于能让更多人、组织、行业参与 AI 应用的创造了。

垂直 Agent 工具，如果按传统方式开发，周期至少数周
但用 Skill 的方式，几小时甚至几分钟就能测试起来
且智力与能力上限也有机会直逼通用 Agent

从这个角度看，Skill 更是降低了验证想法的成本。

两个趋势判断：

个人创作者的崛起

非技术出身的领域专家，离自己做专业 Agent 只剩隔着一层窗户纸。把你的专业经验和工作流程，用文档形式写清楚，Agent 就能照着执行。

Agent 交易平台的出现

Mulerun 等平台正在打造全球性的 Agent 市场，支持创作者在平台上开发并上架 Skill、N8N 等形式的 AI Agent。

Agent 创作者做全球分发、增长（类似 Agent 向的 APP Store）
上架后，Agent 能被其他用户付费使用
会引入自动评分、精选的 Skills 发现机制

这就像 Steam + 创意工坊的模式，让 Agent 开发变成一个可持续的生态。

总结与展望

核心要点回顾

Skills 是什么：

模块化的能力扩展包
打包了 LLM 指令、元数据和可选资源
Agent 会在需要时自动使用它们

Skills 的核心机制：

渐进式披露的三层结构
Level 1（元数据）：始终加载
Level 2（指令）：按需加载
Level 3（资源）：按需中的按需

Skills 的价值：

零代码、高智能上限
突破预设限制，灵活应对边缘情况
多 Skills 自由联用

何时使用 Skills：

发现自己在向 AI 反复解释同一件事
某些任务需要特定知识、模板、材料
一个任务要多个流程协同完成

未来展望

生态早期，但趋势明显

Agent Skills 开放标准发布不到一个月（2024年10月发布，12月成为开放标准），但已经：

OpenAI、Github、VS Code、Cursor 等工具陆续跟进
社区开始创建和分享 Skills
Agent 交易平台正在兴起

两个重要趋势：

个人创作者的崛起

非技术出身的领域专家，可以通过创建 Skills 来开发专业 Agent。

AI Native 产品的范式转移

传统的「输入 → 代码处理 → 输出」模式，正在被「Agent + Skills」的灵活模式取代。

最终思考

Skills 的价值在于：巧借通用 Agent 内核，只关注 Skills 设计，就能低成本创造兼具通用 AI 智能上限的垂直 Agent 应用。

这不是说 Agent Skill 必然全面替代传统开发。两种方式各有适用场景，但 Skill 确实让更多人、更多场景接入 Agent 能力变得更为可行。

从这个角度看，Skill 更是降低了验证想法的成本。

对于 Agent 创业者，乃至非技术的领域专家来说，Skills 代表了很多的新机会：

不必为了一个内部小工具开发完整产品
不必说服 IT 团队理解你的需求
不必等待产品迭代，你可以随时调整

现在还是早期，但未来已来。

附录：资源链接

官方文档

官方 Skills 仓库

Anthropic 官方 Skills 仓库

Skills 的本质

定义与类比

与其他方案的区别

与 MCP 的关系

Skills 的核心运行机制

渐进式披露的三层结构

Level 1：元数据层（始终加载）

Level 2：指令层（按需加载）

Level 3：资源层（按需动态加载）

Reference 和 Script 的区别

动态上下文注入

Skill 的两种调用模式

显式调用

隐式调用

Skills 的真实价值

零代码、高智能上限

最简单的：纯文本 Skill

复杂的：一个 Skill 就是一个完整 Agent

突破预设限制，灵活应对实际情况

多 Skills 自由联用

创建和使用 Skills

Skills 的存放位置

创建第一个 Skill

Step 1：创建 Skill 目录

Step 2：编写 SKILL.md

Step 3：测试 Skill

进阶：添加 Reference 和 Script

添加 Reference（参考文档）

添加 Script（可执行脚本）

使用 Skill-Creator 加速开发

安装 skill-creator

使用 skill-creator

控制 Skill 的行为

控制谁可以调用 Skill

只允许手动调用

只允许 Claude 调用

限制工具访问

在 Subagent 中运行 Skill

使用 Skills 的时机

发现自己在向 AI 反复解释同一件事

发现某些任务需要特定知识、模板、材料才能做好

发现一个任务要多个流程协同完成

最佳实践与注意事项

SKILL.md 编写建议

Reference 文档组织

Script 编写建议

性能优化

Skills 对 AI 产品设计的影响

AI Native 产品的特征

优势分析

性能与开销的平衡

未来展望

总结与展望

核心要点回顾

未来展望

附录：资源链接

官方文档

官方 Skills 仓库

社区资源