之前我写过关于如何使用 Skill 的文章，也探讨过为什么要用以及如何去用。
链接：Skill 原理解读、从 Prompt 到 Skills

今天，主要分享一下我创建 Skill 的过程。

以聊天为例，我来说说创建一个 聊天 Skill 的大致流程。这个 Skill 我本来是没有的，是突然想到可以做，就把它当作一个例子来讲解（请注意，这只是一个例子，具体的聊天过程可能并不适合作为一个 Skill，这里仅用于举例说明）。

这仅仅是我的一些拙见，如果你有更高明、更精细的创建过程，欢迎在评论区分享出来。

第一步，发现痛点、明确需求

比如，我们日常生活中会和很多人聊天，对象很广泛，包括家人、伴侣、朋友、同学、同事和老板等等。

因为我本身不太擅长交流，所以可以创建一个 Skill，来帮助我与这些不同的人群沟通。

第二步，构思 Skill 的功能

也就是思考它如何解决你的痛点，它应该具备哪些功能，以及如何实现这些功能等等。

例如，面对不同的人群应该说什么话，也就是针对不同的对象（如老师、朋友等）如何进行沟通：哪些话该说，哪些话不该说。

此外，还需要考虑如何回应别人的话，以及如何表达自己。

针对别人的话，应对方式可以分为以下几种：对别人的话做一个总结；根据对方的内容，分享自己类似的观点和经历等等其他应对方式。

以上都属于功能性的构思。

在构思这个 Skill 的阶段，你可以先与 AI 反复讨论你的需求。
通过交流，逐步明确这个 Skill 的具体用途，然后让 AI 帮你生成一个元提示词。

就拿这个“聊天 Skill”来说，我可以这样和 AI 沟通（元提示词）：

我们日常生活中会和很多人聊天，对象很广泛，包括家人、伴侣、朋友、同学、同事，甚至老板等等。因为我本身不太擅长交流，所以可以创建一个 Skill，来帮助我与这些不同的人群沟通。

然后，你需要和我反复的交流，来确定这个 Skill 的功能，在最后确定这个 Skill 的功能的时候，帮我输出一份详细的结构化的提示词，用于我直接交给 AI 让其生成这个 Skill

第三步，讨论 Skill 的结构

这一步对于那些比较简单的 Skill 可能并不需要

结构方面主要讨论两点：

• Skill 的目录文件结构。
• Skill 文档的具体结构。

例如，为了防止 SKILL.md 文档过于臃肿，可以将其拆分为多个文件，将一些子功能下放到其他文件中。

你还可以对各个文件进行更精细化的操作。

比如，我可以去网上调研一些关于沟通技巧的对话、书籍、文档或网页，将这些内容作为这个 Skill 的后备知识库，存在一些 md 文件中。

如果你创建的 Skill 对话过程比较长，或者生成的内容比较多，我可能会让 AI 提前生成一个plan 文档或 spec 文档，让 AI 在执行任务的时候反复记录和查看当前的状态，以防止 AI 发生记忆漂移。

你可以这样和 AI 说：

在调用这个 skill 执行任务的时候，可能会生成非常多的信息，也有可能会有很多轮的会话。所以在与 AI 沟通时间过长的时候，可能会发生一些记忆的漂移或遗忘。

为了解决这个问题，我建议你在该 skill 中添加一些防止发生记忆漂移的机制：

1. 使用索引
2. 在执行任务的时候，创建一些 plan 文档或者 spec 文档

这个 Skill 的存储也有一点讲究，你可以规定 Skill 的每次执行过程，将一些关键信息存储到对应的文件中。

关于文件的格式，我们可以从两个维度来考虑：

格式1
指的是文件应该输出什么固定格式的内容，或者是对输入的内容如何做一些格式化的处理等等

格式2
指的是 Skill 中各种文件本身的类型，很多重要信息最后要存储在什么类型的文件中，比如TXT、Markdown、JSON、Excel 还是 CSV 等。

第三步这些操作，我比较喜欢叫它们：“模块化”和“精细化”处理

第四步，Skill 的创建和安全检测

4.1 Skill 的创建

借助创建 Skill 的工具，比如 Anthropic 官方出了一个专门用于创建 Skill 的工具叫 skill-creator。

用于创建 skill 的 skill-creator 获取地址：
https://github.com/anthropics/skills/tree/main/skills/skill-creatoror

我们可以用它，根据刚才讨论的需求和功能，把这个 Skill 创建出来。

你可以这样和 AI 说：

调用 skill-creator 这个 skill 帮我创建一个 Skill，Skill 的具体要求如下：
【然后此处把第二步末尾生成的那个提示词复制过来】

4.2 Skill 的安全检测

其实这一步不做也可以，因为你自己做的 Skill 一般不会植入什么危险的东西。

不过，养成做安全检测的习惯还是挺好的，

安全检测主要是针对外来的、来路不明的 Skill，这是非常有必要做的。

对自己制作的 Skill 进行安全检测，也是一个很好的习惯。

用于安全检测的 Vetter skill 获取地址：
https://clawhub.ai/spclaudehome/skill-vetter

另外需要说明的是，如果你的 Skill 经过了反复的修改和完善，可以在 Skill 最后定稿的时候统一做安全检测，无需反复做

第五步，细节修补

5.1 Skill 的互相引用

如果这个 Skill 需要网络调研功能，就可以在 Skill 中说明，在调用网络功能时，可以引用系统中某个专门的 Skill 来协助完成网络调研。

再比如，如果这个 Skill 有读写 PDF 或 Word 文档的需求，就可以在原有说明中加入：如果需要操作这类文件，可以调用系统中专门处理这些文件格式的 Skill 来协助完成任务。

这一步的核心就是：不要让 Skill 变得过于臃肿。如果这个 Skill 在执行任务过程中需要一些其他的功能，那就调用有这个功能的 Skill 去辅助执行任务。

5.2 Skill 的多轮审核

如果还有下一步，我会把这个 Skill 交给其他 AI 进行审核，让它看看有哪些缺点和不足。

因为刚做出来的 Skill 并不完美，肯定存在各种问题。

比如，我会让 ChatGPT 帮忙审视当前的 Skill，列出需要完善的清单，明确指出缺点、不足以及改进方向。

你可以这样和 AI 说：

这是我做的一个 Skill，你帮我全面深入的审核一下，看看这个 Skill 有哪些明显的漏洞、不足，或者其他需要改进的点，然后以清单的形式列给我，最好是按照严重程度给这些漏洞进行分类，清单需要写到一个 md 文件中。注意：只提意见，不要对 Skill 做任何的修改

然后，我会把这个清单文件再交给 AI，让它按照清单文件继续完善。

这里需要注意几点：
完善的轮次通常会很多，我一般至少会完善三次，也就是修改三次。

流程是：修改一次，就交给 AI 审核一次，根据反馈意见再修改，如此反复循环至少三次。

5.3 准备发布

接下来，可以为这个 Skill 编写一些说明文档：

README 文件：包括中文版、英文版，或其他语言的版本。

配置文件：用于适配不同的 AI 平台和 AI Agent。

具体来说，就是把 Skill 的安装教程、使用教程以及功能亮点等大致写出来，让别人能快速了解它的用途和价值。

然后，可以直接将 Skill 打包上传到 GitHub、Gitee 或 ClawHub 等平台，以便管理它的版本迭代。

以上过程都可以交给 AI 来完成即可。

第六步，人工检测和试用

因为一个 Skill 的实际效果好不好用，最终还得靠人来测试。

在试用过程中，你会发现各种各样的问题。

具体的流程如下：

• 记录在试用过程中发现的所有问题。
• 将问题提交给 AI，根据出现的问题，进一步完成完善和修改。
• 然后再将 Skill 的修改提交到 Github 等平台

第七步，按需拓展

通过制作和使用这个 Skill 的过程，你应该已经对它有了全面且深入的了解。

接下来，根据实际使用情况，可以考虑向两个方向拓展：

7.1 削减功能

这个 Skill 是你与 AI 反复研讨后生成的，内容比较充实。

但在实际使用中，你可能发现只需要其中几个功能。

既然需求不多，可以考虑削减冗余功能，甚至弃用这个 Skill，退而求其次，转向一个比较实用的 Prompt 提示词。每次想用类似功能时，直接使用这个提示词也可以。

我举一个很现实的例子：比如我之前写的文章（包括此文），它是中英文混合的，中文当中混杂了很多英语单词，这时候需要在中英文之间插入空格，以确保文章的“呼吸感”和可读性。

这个工作我当然可以交给 AI 去做，但 AI 给文章加空格的过程会非常繁琐：

1. 它需要先找到并阅读文章
2. 逐一加上空格
3. 进行审核确认
4. 最后可能还会有遗漏

但如果我写成一个 Python 脚本，不到一秒就能把所有的空格都加对地方，所以这类事情就没必要用 AI。

这一步的核心就是：追求简单化和稳定性

之前有人写过一篇文章，标题叫《能用 Skill 就不要用 Agent》，我也写过类似的文章，【能用 Skill 就别做项目，这是我做了两天 web 项目得到的真相】

这些文章的核心观点都一样：同样一件事，能用最简单的方法，就不要把它复杂化。

7.2 扩充 Skill

不仅仅是完善 Skill 本身，你可以把它当成一个真正的产品来做，将其扩充并升级为一个网站、一个 App 或一个小程序，成为一个真正上线落地的产品。

当然，这个过程注定会很繁琐、很漫长，新手还可能会不断的碰壁，但如果你觉得这个 Skill 非常有用、有价值，那么这些付出也是值得的。

你可以这样和 AI 说：

这个 Skill 你先去网络上帮我调研一下有没有类似的产品。如果有的话，请帮我列出它们的功能和现状，以及它们有哪些不足的地方。

然后请帮我评估一下，如果我想把我这个 Skill 做成一个可以落地的产品，适合做成网站、App 还是小程序？请帮我提个建议。最后的建议写成一个报告书的形式，然后以 Markdown 的形式呈现给我。

然后你可以根据 AI 给你的建议，再继续与 AI 深入交流。

比如，如果 AI 建议你先做成网站，你就可以和 AI 商量具体怎么做，包括：

1. 需要注意哪些事项
2. 技术栈采用什么样的技术栈

如果 AI 建议你做成 App，你就继续和 AI 商讨后续的 App 事项等等。

第八步，给 Skill 打好“预防针”

8.1 防呆机制

对于能力较弱的 AI，比如有些 AI，即使你给了它一个 Skill 让它照着做，它还是会出现各种问题，要么执行不好，要么不按步骤来，给人一种很笨的感觉。

这种情况下，你一定要把里面的很多东西都说明白、写明白，在 Skill 中写清楚。

这一步其实可以在第二步生成元提示词的时候做一些处理，你可以这样和 AI 说：

我用的 AI Agent 大模型能力比较弱，所以我需要你把很多功能做一些强制化或细致化的操作。

很多步骤要说得明明白白、清清楚楚，不要让 AI 去猜。同时，很多情况也要考虑到，因为这个 AI 可能真的有点笨。

8.2 画好红线

你还可以在 Skill 的规则中，明确列出一些禁忌内容，划定 Skill 不能触碰的红线。

例如，我在制作 HTML 演示文稿时，就清楚 AI 在生成这类网页时有一些通病，比如：

文字总是左对齐，而且过于靠左，甚至不留边距，导致页面看起来不美观，有些内容位置太靠上，使得页面下方留下大片空白，文字溢出页面，造成内容被截断等等。

你可以把这些已知的常见问题告诉 AI，让它主动规避。

更进一步，你甚至可以提供一个问题库，里面不仅列出可能遇到的问题，还附上相应的解决方案。

这些内容主要是给能力相对较弱的 AI 准备的。如果你使用的 AI 本身能力就很强，可能不需要把 Skill 设计得过于复杂，它也能很好地执行任务。

第九步，学习建议

学习别人的skill，这方面其实有两个方向：

9.1 方向一

在做自己的 Skill 时（即你有开发 Skill 的需求时），可以让 AI 去网络上调研是否有类似的 Skill，看看别人在写这类 Skill 时是怎么构思的（说不定可以直接拿过来用）。

(a) 比如刚才提到的聊天 Skill，你可以让 AI 去调研一下 GitHub 或者其他平台上是否有类似案例。
(b) 了解一下这些已有的 Skill 都实现了什么样的功能。

然后关于参考的时机，我是这样做的：

(a) 我个人一般不喜欢直接去看别人的 Skill
(b) 如果非要参考，我通常会先把自己想做的 Skill 做完，然后再去对比别人的作品，看看有没有值得借鉴的地方。

9.2 方向二

在日常使用 AI 的过程中，去 GitHub 上看一些 Star 数比较多的优秀 Skill。

比如：

1. Anthropic 的 Skill 库

   https://github.com/affaan-m/everything-claude-code

2. gstack

   https://github.com/garrytan/gstack

3. everything-claude-code

   https://github.com/anthropics/skills

你可以看看这些优秀的案例，学习他们是如何构思一个 Skill 的，多积累做 Skill 的经验