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