前言
此文是我近期学习Agent中关于Skill使用的一点心得,结合AI整理总结而来,分享给大家。一是为了记录,二是用于日后的回顾,三也是希望能给其他初学者带来一点点帮助。
目录
- [1. 为什么我会开始关注 Skill?](#1. 为什么我会开始关注 Skill?)
- [2. Skill 到底解决了什么问题?](#2. Skill 到底解决了什么问题?)
- [3. 从写博客这个例子理解 Skill 的价值](#3. 从写博客这个例子理解 Skill 的价值)
- [4. 一个 Skill 通常包含哪些内容?](#4. 一个 Skill 通常包含哪些内容?)
- [5. Skill 使用时会加载哪些上下文?](#5. Skill 使用时会加载哪些上下文?)
- [6. 写 Skill 时我踩到的几个细节](#6. 写 Skill 时我踩到的几个细节)
- [7. 什么样的工作流适合沉淀成 Skill?](#7. 什么样的工作流适合沉淀成 Skill?)
- [8. 总结](#8. 总结)
1. 为什么我会开始关注 Skill?
最近在学习 Agent 项目时,我遇到了一个很实际的问题:AI 确实能帮我写文章、整理笔记、解释代码,但每次都要重复告诉它我的习惯。
比如我让 AI 帮我写 CSDN 博客时,会反复强调这些要求:
text
1. 要写成 CSDN 可发布的 Markdown。
2. 要保留固定的前言。
3. 要保留固定的飞书结尾。
4. 代码示例最好优先用 Java,其次 Python。
5. 文章要适合初学者。
6. 不要机械套固定标题。
7. 输出文件要放到 C:\Users\52412\Desktop\blog。
8. 不要一上来就写全文,要先给标题和子标题,确认后再写。
如果每次都手动说一遍,这件事就很低效。
于是我开始思考一个问题:
text
能不能把这些固定要求沉淀下来,让 Agent 下次自动按这个流程做?
这就是 Skill 的价值。
在我这次实践里,最后沉淀出了两个博客相关的 Skill:
text
blog-csdn-from-chat
从已有对话、学习笔记、草稿中整理成 CSDN 博客。
blog-csdn-from-title
从一个标题、主题或一句话扩展成 CSDN 博客。
它们解决的不是"AI 会不会写文章"的问题,而是:
text
AI 能不能按照我的固定风格、固定流程、固定目录来写文章。
2. Skill 到底解决了什么问题?
很多人第一次听到 Skill,可能会把它理解成:
text
Skill = 一段更长的提示词
这个理解有一部分对,但不完整。
更准确地说:
text
Skill = 给 Agent 使用的一套专项工作流说明。
它不仅告诉 Agent "要做什么",还告诉 Agent:
text
1. 什么情况下应该使用这个 Skill。
2. 这个任务应该分几步做。
3. 输出格式应该是什么样。
4. 有哪些模板和检查清单可以复用。
5. 哪些事情不能做,比如泄露 API Key。
普通提示词更像一次性命令:
text
帮我写一篇关于 Skill 的博客。
Skill 更像一份长期可复用的工作规范:
text
以后遇到"从主题写 CSDN 技术博客"的任务:
先给标题和子标题让我确认;
确认后再写全文;
默认放到指定目录;
代码优先 Java;
保留固定前言和结尾。
所以,Skill 真正解决的是重复沟通成本。
它把人的经验和偏好,变成 Agent 能复用的流程。
3. 从写博客这个例子理解 Skill 的价值
这次我和 AI 的对话,其实就是一个很典型的 Skill 形成过程。
一开始,我只是让 AI 根据一次技术讨论写博客。
后来我发现,单纯"写出来"还不够,还要满足这些要求:
text
1. 文章要符合 CSDN 的 Markdown 习惯。
2. 前言要保留我的固定表达。
3. 结尾要保留飞书链接和点赞收藏引导。
4. 正文标题不能死套模板。
5. 如果从主题写文章,要优先使用 Java 代码。
6. 输出文件不能乱放,要统一放到桌面 blog 文件夹。
7. 写之前要先给我主题和子标题,我确认后再写。
这些规则越聊越多,如果只靠临时提示词,后面很容易漏掉。
于是就可以把它沉淀成 Skill。
比如 blog-csdn-from-title 的核心目标可以概括成:
text
用户给一个标题、主题或一句话,
Agent 先生成文章主题、角度、子标题和代码计划,
用户确认后,
再写成 CSDN 可发布的 Markdown 文件。
这个流程沉淀下来之后,下次我只需要说:
text
用 blog-csdn-from-title 写一篇关于 Redis 过期删除的文章。
Agent 就知道应该先给我大纲,而不是直接写全文。
这就是 Skill 的实际价值:
text
把一次沟通中反复修正出来的经验,变成下次可以直接复用的流程。
4. 一个 Skill 通常包含哪些内容?
一个 Skill 通常不是单个文件,而是一个小目录。
比如:
text
blog-csdn-from-title/
├── SKILL.md
├── agents/
│ └── openai.yaml
└── references/
├── csdn-title-article-template.md
└── review-checklist.md
其中最核心的是 SKILL.md。
它通常包含:
text
1. name
Skill 的名字。
2. description
告诉 Agent 什么时候应该使用这个 Skill。
3. workflow
具体执行流程。
4. rules
输出格式、代码偏好、安全要求等。
5. references
需要时可以读取的模板和检查清单。
一个简化版 SKILL.md 可以像这样:
markdown
---
name: blog-csdn-from-title
description: Expand a user-provided title, topic, one-sentence idea, or rough outline into a CSDN-ready Chinese technical blog.
---
# Blog CSDN From Title
## Workflow
1. 先根据主题生成文章标题、角度和子标题。
2. 等用户确认后再写全文。
3. 代码优先使用 Java,其次 Python。
4. 默认保存到 C:\Users\52412\Desktop\blog。
5. 写完后检查 Markdown、代码和隐私信息。
这里最值得注意的是 description。
因为 Skill 没有被正式使用之前,系统通常不会把完整 SKILL.md 都加载进上下文,只会根据 name 和 description 判断是否要触发。
所以 description 不能写得太随便。
比如这样就太模糊:
yaml
description: Write blogs.
更好的写法是:
yaml
description: Expand a user-provided title, topic, one-sentence idea, or rough outline into a CSDN-ready Chinese technical blog with beginner-friendly explanations and concise key code examples.
一句话总结:
text
description 决定 Skill 能不能被正确触发。
SKILL.md 决定 Skill 被触发后怎么执行。
5. Skill 使用时会加载哪些上下文?
Skill 不是一上来就把所有内容都塞给 Agent。
更合理的方式是分层加载。
可以理解成三层:
text
第一层:未触发时
只暴露 name + description。
第二层:触发后
加载 SKILL.md 正文。
第三层:需要时
再读取 references、scripts、assets 等资源。
比如我创建的博客 Skill 里有两个 reference 文件:
text
references/
├── csdn-title-article-template.md
└── review-checklist.md
这些文件不会每次都自动加载。
只有当 Agent 需要文章模板或发布检查清单时,才会读取它们。
这样设计有两个好处:
text
1. 节省上下文空间。
2. 避免不相关资料干扰当前任务。
这也提醒我们,写 Skill 时要注意分层:
text
常用触发信息:放在 description。
核心流程:放在 SKILL.md。
详细模板:放在 references。
可执行脚本:放在 scripts。
输出素材:放在 assets。
不要把所有东西都堆进 SKILL.md。
6. 写 Skill 时我踩到的几个细节
第一个细节:Skill 名字要准确。
我一开始把名字写成了:
text
blog-cndn-from-chat
后来发现应该是:
text
blog-csdn-from-chat
名字一旦写错,不只是显示不好看,后续触发时也容易混乱。
第二个细节:模板不能写得太死。
一开始模板里有类似这样的固定标题:
markdown
## 背景问题
## 核心概念
## 代码示例
## 常见误区
看起来很完整,但问题是:每篇文章都会被带偏成同一种结构。
后来我把规则改成:
text
根据文章主题生成自然的小标题。
模板只是结构参考,不是固定大纲。
第三个细节:输出目录也应该沉淀。
如果不写清楚,Agent 可能会把文章输出到当前项目目录,也可能直接发在聊天里。
所以我把默认输出目录固定成:
text
C:\Users\52412\Desktop\blog
第四个细节:写之前先确认大纲。
一开始 Agent 可能会直接写全文。
但写博客时,标题和子标题一旦方向错了,整篇文章都会偏。
所以我后来把流程改成两阶段:
text
第一阶段:
只给主题、文章角度、子标题、代码示例计划。
第二阶段:
用户确认后,再写全文并保存文件。
这个规则非常实用。
第五个细节:安全规则必须写进去。
因为写文章时可能参考真实项目、真实配置、真实截图,所以 Skill 里应该明确写:
text
不要输出真实 API Key。
不要暴露 token。
不要暴露私有路径、账号、业务空间 ID。
这些细节虽然不复杂,但非常重要。
7. 什么样的工作流适合沉淀成 Skill?
不是所有任务都适合写成 Skill。
我现在的理解是:如果一件事具备下面几个特点,就很适合沉淀成 Skill。
第一,它会重复出现。
比如:
text
写 CSDN 博客
整理学习笔记
代码审查
生成发布说明
分析报错日志
创建项目模板
第二,它有固定偏好。
比如:
text
代码优先 Java
文章要有固定前言
文件要保存到固定目录
先给大纲,确认后再写
第三,它有固定质量标准。
比如:
text
不能泄露密钥
代码要短
标题不能太泛
目录要和正文一致
Markdown 要能正常预览
第四,它需要参考模板或资料。
比如:
text
文章模板
检查清单
接口文档
公司规范
项目结构说明
如果一件事只是偶尔做一次,用普通提示词就够了。
但如果你发现自己总是在反复补充同样的要求,那就说明它可能适合变成 Skill。
用一句话判断:
text
凡是需要反复解释"我希望你按这个流程做"的任务,都值得考虑写成 Skill。
8. 总结
通过这次实践,我对 Agent 中的 Skill 有了更具体的理解。
text
1. Skill 不是简单的提示词合集,而是一套可复用工作流。
2. Skill 可以把个人偏好、模板、输出目录和质量标准固定下来。
3. description 决定 Skill 是否容易被正确触发。
4. SKILL.md 应该写核心流程,详细模板适合放到 references。
5. 好的 Skill 应该先明确边界,不要什么任务都管。
6. 对写博客这类重复任务来说,Skill 非常适合沉淀流程。
如果用一句话总结:
text
Skill 的意义,是把一次次和 AI 沟通出来的经验,变成下一次可以直接复用的能力。
这也是我这次最大的感受:
当你不再只是让 AI 完成一次任务,而是让它记住一套做事方式时,Agent 才真正开始变得像一个"长期协作的助手"。
上述内容也同步在我的飞书,欢迎访问
https://my.feishu.cn/wiki/QLauws6lWif1pnkhB8IcAvkhncc?from=from_copylink
如果我的内容对你有帮助,请点赞,评论,收藏。创作不易,你们的支持就是我坚持下去的动力!