从0到1创建出自己的skillskill如何编写_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。如何开发一个Skillskill的官方规范https://agentskills.io/homeskill创建的使用工具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.mdSkill 主入口含 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.txtPython 依赖清单Node 项目对应package.jsonscripts/ 里存在需外部依赖的脚本时约定 1文件夹名、name frontmatter 字段、marketplace 中注册的 skill 名三者严格一致如 pdf、docx、skill-creator。约定 2把 skill 视为「一个可移植的最小单元」——不要在 SKILL.md 里引用文件夹外的路径。skill-name/:这是 skill 的根目录也是一个技能包的边界。作用①作为一个独立 skill 的容器②承载这个 skill 的所有文件③让客户端按目录为单位发现和管理 skill通常这个目录名要和SKILL.mdfrontmatter 里的name一致例如pdf-processing/ # 对应yaml --- name: pdf-processing description: ... ---这样客户端才能正确建立索引和匹配关系。SKILL.md:这是 skill 最核心、也是必需的文件。两层职责①元数据就是让客户端和模型知道这个 skill 叫什么、它做什么、什么时候用②主说明书告诉用户遇到这类问题如何应用、主步骤是什么、有哪些约束、有什么边界通常包括YAML frontmatterMarkdown 正文说明--- 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.shscripts/validate.pyscripts/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.mdassets/这是 静态资源目录也是可选的。它用来存放 skill 运行或输出时需要引用的静态文件例如模板文件、配置样例、图片、JSON Schema、样本文档、映射表、表单模板可以简单理解为references/ 偏“给模型看的说明文档”assets/ 偏“任务执行时要用到的材料”assets/ ├── config-template.json ├── report-template.md ├── architecture.png └── schema.jsonskill的加载Skill 的加载分三级写作时必须按这三级来切分内容层级加载时机大小预算承担内容L1 元数据namedescription永远在上下文中~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 的、支持渐进式加载的能力包。