Skills就是给AI Agent写的操作手册，本质上是一份结构化的指令文件。
当Agent碰到某类任务，就去读对应的Skill，按里面的步骤一步步执行，不用每次从头教它。

比如想让AI帮我创建Cursor的自定义规则文件
规则文件放哪个目录、格式长啥样、有哪些字段，这些东西写一个create-rule 的skill就搞定了。
Agent碰到相关任务自动加载，不需要每次重复沟通。
核心价值有三点：

• 把某个领域的专业知识、操作步骤、注意事项打包成一个文件，Agent读了就能干活，不需要每次重复教
• 同一个任务不管执行多少次，Agent都按skill定义的流程走，输出质量可预期
• 通过编写不同的skills，让一个通用Agent具备各种垂直领域的专业能力，不需要重新训练模型。

一个典型的Skill文件通常是Markdown格式，包含触发条件、操作步骤、输入输出规范、常见坑点 这几个核心部分

1.触发条件：
什么情况下使用这个Skill
例如：

• 特定系统警告出现
• 满足特定时间或状态要求

需要明确的激活信号When

2.操作步骤：
要执行那些行动，按什么顺序
动作序列必须清晰

3.输入输出规范：
需要什么参数，产出什么结果
输入参数：定义所需数据类型(如JSON，文本)
输出参数：定义产出格式(如报告、状态码)
接口标准要统一

4.注意事项：

• 边界情况和常见坑点
• 处理异常和错误情况
• 性能限制和依赖项
• 安全和权限提醒

Skills出现之前的痛点

没有Skills的时候，每次让Agent干一件稍微优点规范要求的活儿，都得从头把要求说一遍。
比如：要求函数命名用驼峰，异常处理要统一格式，说了一次Agent记住了，下次新对话又忘了
更要命的是，不同的人给Agent的指令不同，同一个团队里10个人，可能写出10种风格的代码来。
Skills就是来解决这个问题的，把反复出现的指令和规范固化成文件，让Agent每次都能自动读取，保证行为一致。

Skills的技术实现原理

Skills 的底层原理其实并不复杂，本质上就是一种Prompt注入机制
在Agent执行任务之前，系统根据任务类型匹配合适的Skill文件，把文件内容注入到LLM的上下文中，相当于对话开始前先给AI补课。
分三步走：
1.首先是匹配阶段，系统根据用户意图或关键词，从Skill库中找到相关的Skill，匹配方式可以是关键词规则、语义检索，也可以直接在Agent的System Prompt里列出所有可用的Skill让LLM自己判断

2.加载阶段
读取匹配到的Skill文件内容，注入到当前对话的上下文中

3.最后是执行阶段，LLM根据Skill中定义的步骤和约束来完成任务

这与RAG有点像，但关键区别在于：RAG检索的是知识片段，目的是回答问题
Skill加载的是操作指令，目的是指导行动

Skill的设计原则

写一个好的Skill跟写一个好的Prompt一样需要技巧
1.一个Skill只解决一类问题，别把所有东西塞到一个文件里。
2.操作流程要清晰，每一步做什么、用什么工具都写明白，最好用编号列表。
3.明确定义输入参数和输出格式，减少歧义
4.给出正确和错误的示例，比纯文字描述有效得多
5.Skill不是写完就不管了，要根据实际使用效果不断迭代优化

Skills和RAG都是往上下文塞内容，具体却别在哪？

RAG检索的是知识片段，目的是让模型基于这些信息回答问题，给AI喂资料
Skills加载的是操作指令，目的是让模型按照固定流程执行任务，给AI定规矩
检索力度：
RAG的检索力度通常是段落级别的，一次可能检索5-10个相关文档片段
Skills通常是整份文件加载，一次加载1-2个Skill

如果Skill文件内容特别长，塞进上下文会不会有问题？

会的。
LLM的上下文窗口是有限的
比如Claude的上下文是200K token
一个Skill文件如果写了好几千token，再加上用户对话历史和系统提示词，很容易把上下文撑满。
解决办法：
1.控制Skill文件的长度，把非核心内容拆成子文件按需加载
2.做分层加载，先加载一个精简版的摘要，Agent判断需要更多细节时再加载完整内容。Cursor就是这么干的，鼓励把大Skill拆分成多个小文件

怎么判断一个任务应该用Skill来解决还是用Tool来解决？

看这个任务是否需要跟外部系统打交道
如果只是需要AI按照特定流程去思考和组织输出，比如生成代码要遵循某种规范、创建文件要按照特定模板，用Skill就够了
如果需要查数据库、调API、操作文件系统这些实际的外部操作，那就得上Tool
总结一下，Skill管的是怎么想，Tool管的是怎么做，两者也经常配合着用，Skill里面会写明在某一步调用哪个Tool