从0到1：创建出自己的skill（skill如何编写）_skill语言用什么软件编写-CSDN博客

AI入门——一文读懂什么是Skill以及如何开发Skill_skill开发-CSDN博客

Skills 编写规范与经验指南_skills编写指南-CSDN博客

为什么要创建Skill：

在每次给大模型输入提示词中，使用场景有着相同的设计风格，在后续关于该网站的设计风格很大可能沿用这种设计，每次都在提示词中加入设计风格，这显然有些麻烦。

这时，我们可以将有关设计风格的提示词写入一个skill.md文件中，并在提示词的基础上加入调用说明（调用说明要尽可能的短），最后将这个文件导入到使用ai编程ide中。

这样，我们在和大模型对话时，ide会自动把skill的调用说明拼在我们的提示词上，让大模型自己来判断是否要使用。

大模型要使用，ide就会再重新将完整的skill发送给大模型；大模型不使用，由于我们的调用说明短，也不会对模型造成太大的干扰。

Skill的基本概念：

Skills（技能）：Agent的能力模块

本质：Agent 能调用的“可复用、模块化”的功能，每个 Skill 对应一个具体的“做事能力”，通常是函数 / API / 脚本。

常见类型：

①基础 Skill：文本总结、翻译、格式转换；

②工具类 Skill：调用天气 API 查天气、调用数据库查订单、调用邮件服务发邮件；

③复杂 Skill：写 Python 代码、执行 Shell 命令、生成 Excel 报表。

工作方式：

① Agent 通过 Prompt 识别“需要用到的 Skill”，比如用户问“查一下我的订单退货进度”→ 触发“查询订单 Skill”；

② Agent 调用对应的 Skill 函数，传入参数（比如订单号）；

③ Skill 执行后返回结果，Agent 再根据 Prompt 规则整理结果反馈给用户。

skill的底层需求代码：

# 定义「查询订单」Skill
def check_order_skill(order_id):
    # 调用订单数据库API
    result = db_api.get_order_status(order_id)
    return result

# Agent逻辑：识别需求→调用Skill→返回结果
user_input = "查订单12345的退货进度"
order_id = extract_order_id(user_input)  # 从用户输入提取订单号（Prompt定义的规则）
skill_result = check_order_skill(order_id)  # 调用Skill
final_answer = format_result(skill_result)  # 按Prompt格式整理
print(final_answer)

Skill和Prompt的区别与联系：

定义：

prompt：是“给模型的一次性指令表达”，特点用完即弃（或临时复用）

Skill：是把一类可复用的 prompt + 工作流 + 资源约束打包成模块化能力

所以 Skill 不是 Prompt 的对立面，而更像是结构化、可复用、可发现、可按需加载的 Prompt 工程产物。

Skill和Prompt的相同点：

从本质上看，Skill 仍然建立在 Prompt 之上。无论一个 Skill 多么工程化，最终都需要通过上下文注入的方式让模型理解，例如：

①System Prompt（系统提示词）：模型的“人设”和“最高宪法”。比如：“你叫小A，是财务助手，必须用中文回答，不许编造数据。”，这是死的规矩，每次对话都焊死在最前面。

②Developer Prompt（开发者提示词）：比System权限更高，通常是平台开发者用来限制模型行为的底层指令，防止用户把模型玩坏。

③Tool Description（工具说明书）：自然语言写的“说明书”。Agent会在后台把你的Skill翻译成一段文字塞给模型，比如：“有一个叫 check_order 的工具，当用户问订单进度时调用，参数是订单号。”，模型读到这段文字，才知道有这个功能。

④Tool Result（工具执行结果）：Python代码跑完数据库，返回了一串JSON数据

比如：这段JSON会被包装成一段文字，塞进模型的眼睛里。模型看着这段文字，才知道数据库里查出了什么。

⑤Hidden Context（隐藏上下文）：比如用户当前的IP地址、登录ID、上一次对话的摘要。这些不显示在聊天框里，但塞给模型了，方便它做个性化判断。

⑥Synthetic Message（合成消息）：为了让模型“看懂”执行过程，Agent会在后台伪造一些对话记录。比如伪造一条“系统”发给“助手”的消息，写着：“工具执行成功，返回结果如下...”。这是为了把生硬的代码执行结果，润色成模型最容易理解的对话格式。

所以可以理解为：Skill = Prompt + 触发机制 + 资源组织 + 执行约定 + 权限/作用域管理

也就是说：Prompt 更偏“内容”，Skill 更偏“机制 + 容器 + 生命周期”

总的来说：

①都用于影响模型行为：无论是 Prompt 还是 Skill，目的都是引导模型如何理解任务、如何输出结果、如何遵守约束。

②都依赖上下文注入：它们都不是修改模型参数，而是通过输入上下文来影响模型推理过程。

③都可以包含相似的信息结构：一个高质量 Prompt 和一个高质量 Skill，通常都可能包含：角色、背景、任务目标、约束条件、输出格式、示例、注意事项

④都会影响输出稳定性：写得好的 Prompt 能提高结果质量，设计得好的 Skill 也能显著提升稳定性和一致性。

⑤都需要持续迭代优化：Prompt 和 Skill 都不是一次写完就永远正确，通常需要根据实际效果不断调整。

⑥都属于 Prompt Engineering 的范畴：从广义上讲，Skill 仍然属于 Prompt Engineering，只是它更加工程化和结构化。

Skill和Prompt的区别：

①粒度不同：Prompt 通常面向一次请求或单次任务，Skill 通常面向一类重复出现的任务。

②生命周期不同：Prompt 往往是临时的、一次性的，Skill 往往是长期存在、可复用、可版本管理的。

③复用方式不同：Prompt 往往通过复制、模板或人工复用。
Skill 往往由客户端自动发现、匹配、加载和注入。

④触发方式不同：Prompt 通常由用户直接输入；Skill 可以自动触发，也可以手动显式调用。

⑤结构化程度不同：Prompt 可以是一段自由文本。；Skill 一般有固定结构，例如 SKILL.md、scripts/、references/、assets/ 等。

⑥工程集成程度不同：Prompt 更偏向“和模型对话”；Skill 更偏向“作为 Agent Runtime 中的能力模块”。

⑦可发现性不同：Prompt 不会被系统主动发现和管理；Skill 通常会被客户端扫描、索引，并暴露给模型进行选择。

⑧权限管理不同：Prompt 一般没有独立权限体系；Skill 在很多 Agent 系统中可以单独控制访问权限，例如 allow、deny、ask。

⑨资源承载能力不同：Prompt 主要承载文本；Skill 除了文本，还可以挂载脚本、模板、参考文档和静态资源。

⑩执行方式不同：Prompt 往往是模型读完后直接回答；Skill 往往是模型读完后继续调用工具、脚本或参考资料来完成任务。

⑪适用场景不同：Prompt 适合探索性、临时性、开放性任务；Skill 适合重复性、流程化、专业化任务。

⑫维护方式不同：Prompt 更偏个人使用、分散维护；Skill 更适合团队共享、版本控制和协作演进。

Skill和Prompt的对比总结：

相同点：

都用于引导模型行为；都依赖上下文注入；都可以包含目标、约束、步骤和示例；都会影响输出质量和稳定性；都需要持续优化；都属于广义 Prompt Engineering

区别点：

Prompt 面向单次任务，Skill 面向重复任务；

Prompt 偏临时输入，Skill 偏长期沉淀；

Prompt 是自由文本，Skill 是结构化模块；

Prompt 通常手动输入，Skill 可以自动匹配和调用；

Prompt 通常无独立权限，Skill 通常可做权限控制；

Prompt 主要是文本，Skill 可附带脚本和资源；

Prompt 偏表达需求，Skill 偏封装工作流；

Prompt 适合即时交互，Skill 适合工程化复用。

什么时候使用 Prompt，什么时候使用 Skill：

适合直接写 Prompt 的场景：一次性任务、探索性需求、需求尚不稳定、快速试验输出效果、没有长期复用价值

适合沉淀为 Skill 的场景：某类任务经常重复出现、工作步骤比较固定、对输出一致性要求高
需要配套脚本、模板或参考资料、希望团队共享和版本化维护

一句话总结：重复、稳定、可流程化的 Prompt，值得进一步抽象成 Skill。

如何开发一个Skill：

skill的官方规范：https://agentskills.io/home

skill创建的使用工具：

Typora：是目前手写markdown格式最好用的工具之一，可以很直观地看到写出内容结构。

jetbrains：它旗下的ide，都支持markdown格式的实时预览，而且大多数的开发者都装有jetbrains旗下的ide，不用另外安装。

集成ai的ide：如：trae、cursor等等，支持对markdown格式的预览，在这种集成ai的ide中，我们可以使用ai来辅助创建、润色skill。

skill的目录结构：

skill-name/                       # 目录名建议 kebab-case
├── SKILL.md                      # 必需：YAML frontmatter + Markdown 正文
├── LICENSE.txt                   # 强烈建议：非必需，用于公开发布时的免责与产权的声明
├── scripts/                      # 可选：可执行的确定性脚本（Python/Node/Bash）
│   ├── main_tool.py
│   └── utils.py
├── references/                   # 可选：按需加载的深度文档
│   ├── advanced.md
│   └── schemas.md
├── assets/                       # 可选：产物中直接使用的静态资源
│   ├── template.html
│   └── fonts/
├── examples/                     # 可选：范例、样例输入输出
│   └── sample-input.md
├── templates/                    # 可选：起始模板（如 HTML/JS 骨架）
├── agents/                       # 可选：子 agent 的 system prompt 片段
│   └── grader.md
└── requirements.txt              # 可选：Python 依赖清单

目录 / 文件	用途	何时使用
SKILL.md	Skill 主入口，含 YAML frontmatter + Markdown 正文	必需
LICENSE.txt	完整 license 文本，供 frontmatter 中的 license 字段指向	非必需；公开发布时推荐随 skill 一起分发
scripts/	确定性代码，模型直接调用而不必读源码	有重复性/可自动化的步骤时
references/	长参考文档，模型「按需」读取	单个 SKILL.md 装不下、或按主题拆分时
assets/	出现在最终产物里的资源（字体、图标、模板）	需要打包到输出中
examples/	样例集（正/反例、模板问答）	类目繁多，SKILL.md 只做路由
templates/	起始骨架（HTML/JS/JSON schema 等）	输出遵循固定模板
agents/	子 agent 的 system prompt 片段	skill 会 spawn subagent 时
requirements.txt	Python 依赖清单（Node 项目对应 package.json）	scripts/ 里存在需外部依赖的脚本时

约定 1：文件夹名、name frontmatter 字段、marketplace 中注册的 skill 名，三者严格一致（如 pdf、docx、skill-creator）。

约定 2：把 skill 视为「一个可移植的最小单元」——不要在 SKILL.md 里引用文件夹外的路径。

skill-name/:

这是 skill 的根目录，也是一个技能包的边界。

作用：

①作为一个独立 skill 的容器

②承载这个 skill 的所有文件

③让客户端按目录为单位发现和管理 skill

通常这个目录名要和 SKILL.md frontmatter 里的 name 一致，例如：

pdf-processing/
# 对应yaml
---
name: pdf-processing
description: ...
---

这样客户端才能正确建立索引和匹配关系。

SKILL.md:

这是 skill 最核心、也是必需的文件。

两层职责：

①元数据：就是让客户端和模型知道这个 skill 叫什么、它做什么、什么时候用

②主说明书：告诉用户遇到这类问题如何应用、主步骤是什么、有哪些约束、有什么边界

通常包括：

• YAML frontmatter
• Markdown 正文说明

---
name: deploy-app
description: Deploy an app to staging or production. Use when the user asks for deployment, release, or rollout tasks.
---

# Deploy App

## When to use
...

## Instructions
...

SKILL.md 之所以必须存在，是因为在 skill 的加载链路里：客户端先读 name 和 description
建立 skill catalog；模型根据 description 判断是否要激活 skill；激活后再读完整正文。

所以 SKILL.md 是 skill 的核心入口。

scripts/：

这是 可执行脚本目录，是可选的。当 skill 不只是“给建议”，还需要执行一些确定性动作时，就可以把这些动作写成脚本放在这里。

例如：

scripts/deploy.sh
scripts/validate.py
scripts/generate_report.js

这类脚本适合承载：稳定、可重复执行的程序化动作、带明确输入输出的流程脚本。

skill 里可能会写：

Run:
scripts/validate.py

然后 agent 看到后，会调用 shell、python 或其他工具执行它。

reference/：

这是参考文档目录，也是可选的。它用来存放不适合全塞进 SKILL.md 正文的补充资料，例如：详细流程说明、领域知识、输入输出规范、术语定义、常见问题、边界条件说明

拆到 references/ 的好处是支持渐进式加载：启动时只读 name 和 description、激活时读 SKILL.md、需要深入细节时，再按需读取 references/ 里的内容。

references/
├── REFERENCE.md
├── API-GUIDE.md
├── TROUBLESHOOTING.md
└── EDGE-CASES.md

assets/：

这是 静态资源目录，也是可选的。它用来存放 skill 运行或输出时需要引用的静态文件，例如：模板文件、配置样例、图片、JSON Schema、样本文档、映射表、表单模板

可以简单理解为references/ 偏“给模型看的说明文档”，assets/ 偏“任务执行时要用到的材料”

assets/
├── config-template.json
├── report-template.md
├── architecture.png
└── schema.json

skill的加载：

Skill 的加载分三级，写作时必须按这三级来切分内容：

层级	加载时机	大小预算	承担内容
L1 元数据（name + description）	永远在上下文中	~100 词	触发决策所需的最小信息
L2 SKILL.md 正文	skill 被触发后立刻加载	建议 <500 行	核心工作流、决策树、路由到附属文件的指针
L3 附属文件	模型按需 Read	无限	深度参考、模板、示例、可执行脚本

核心原则：L2 是路由，不是百科全书。当 SKILL.md 快要超过 500 行、或某一节篇幅过大时，就要把细节剥离到 references/ 或 examples/，SKILL.md 里只留一句「如果要做 X，请阅读 references/x.md」。

skill开发最终总结：

这个目录结构的设计目标，是把一个 skill 拆成三层：

发现层：通过 SKILL.md 的元数据知道它是什么

指令层：通过 SKILL.md 正文知道该怎么做

资源层：通过 scripts/、references/、assets/ 支撑复杂任务执行

所以 skill 目录不是简单的“一个 prompt 文件夹”，而是一个面向 agent 的、支持渐进式加载的能力包。