Skills从0到1，如何设计一个商用级Skill【万字长文】

这篇文章，我会从Skill的基本概念、设计方法、迭代升级这些维度展开。并且会结合之前那套Codex自动化剪辑工作流，尽量用大白话把Skill讲清楚，确保大家看完就能上手用。

这次之所以想聊Skill，是因为上一篇文章发出去后，收到了不少朋友的提问，也有朋友遗憾没有拿到可以直接用的Skill。

前面说过，我的剪辑Skill里有很多内部信息，确实不太方便直接分享。另外就是，Skill里那些文案修改规则、素材筛选匹配逻辑，都是针对特定产品专门设计的，就算给到你，可能也用不上。拿去修改的功夫，还不如重新创作一个新的Skill来得有效。

所以换了个思路：与其给一个现成的Skill，不如分享一下我是怎么做出一个商用级Skill的。理解了方法，你就可以根据自己的真实问题，去打造一套属于自己的Skill。

这里面也会分享一些我在做自动化剪辑Skill时遇到的卡点和解决方案。如果你在跟着前一篇文章跑工作流，这篇可以好好看看。

理解Skill的基本概念

先来理解一下Skill这个概念。（已经了解的朋友，可以跳过这部分。）

可以把AI想象成一个刚入职的新同事——它很聪明，但完全不懂你的业务流程。这时候，你需要给它发一份工作说明书，也就是Skill。

这份工作说明书里，会有一个Skill.md的文档，告诉AI应该做什么、怎么做、有哪些注意事项，以及做到什么程度才算完成。

除了Skill.md，这份说明书里还会有references/、scripts/、assets/这些文件夹，分别用来存放参考资料、工具脚本、案例模板之类。

每一个Skill，都会有一个Skill.md文档。然后根据Skill的复杂程度，再决定是否需要references/、scripts/和assets/文件夹。

那么，Skill和我们常说的Prompt（提示词）有什么区别呢？

Prompt是你在对话框里临时给AI的指令，每次都需要重新输入。但Skill是一个完整的能力包，里面不只有文字指令，还可以包含代码脚本、参考文档、模板素材这些东西。

所以，

你做好的Skill，会被放到一个专门的文件夹里（支持Skill的主流AI模型，都有类似的文件夹）。以后每次遇到类似的任务，你只要输入斜杠命令，就可以直接调用它。

举个例子，我的文章配图Skill，连提示词都不需要。输入斜杠找到Skill，输入@找到写好的文章，AI就会自动帮我配图并插入到文章里。

设计Skill的两种方法

理解了Skill的概念，接下来要怎样去设计一个Skill呢？

经验表明，

其他的，比如用什么工具、有什么规则，这些东西都可以慢慢补充。但一定要先理清楚，做好这件事，整个流程是什么样的。

比如上一篇文章提到的Codex自动化剪辑工作流：

分析参考视频 → 拆分片段/提取文案 → 修改/校对文案 → 配音 → 匹配素材 → 自动化剪辑 → 导入剪映草稿

在正式开始剪辑之前，这个Skill其实还有很多前置步骤。要先分析参考视频，分析以后还要拆分片段、提取文案；文案提取后，要判断哪些地方可以照搬，哪些地方需要改成自己的产品表达；然后才是配音、素材筛选、镜头匹配、字幕处理，最后再导入到剪映草稿里。

把流程理清楚，就可以开始设计Skill了。

做Skill，一般有两种方法。

第一种方法：先跑通流程，再沉淀Skill

简单来说，就是先手动把整个工作流跑一遍。从第一步开始，遇到问题就让AI帮你解决，解决完继续下一步。等整个流程都跑通了，再跟AI说：把这个工作流程沉淀成Skill。

这种方法的好处是，生成的Skill基本上可以直接使用。因为整个流程是自己跑过一遍的，每个环节都验证过，基本不会有太大的问题。

但这个方法实际上只适合一些轻量的Skill，比如文章写作Skill、标题创作Skill。一旦涉及到流程相对复杂的Skill，就会出现很多问题。

因为在跑流程的过程中，会经历很多轮对话，而且可能反复修改。一旦超过AI的读取上限，AI打包成Skill的时候就很容易漏掉一些部分，最后只出来一个半成品。

第二种方法：直接调用Skill-Creator

第二种方法，和第一种正好相反，

一般AI工具里面，都会有一个专门用来设计Skill的工具（其实也是一个Skill）。比如Codex和Claude里面，都叫Skill-Creator。

这个工具怎么使用呢？你可以通过斜杠把它调出来，也可以直接告诉Codex你想设计一个Skill。只要触发了关键词，Codex就会自动调用（用第一个方法沉淀Skill，实际调用的也是Skill-Creator）。

调用以后，直接把你的需求告诉AI就行。如果不知道怎么表达需求，可以按照这个模板填写：

## 任务
帮我创建一个Skill，Skill的名字叫【Skill名】，它主要用来【具体想要Skill做的事情】。

## 触发
这个Skill，一般在我提到【关键词1】、【关键词2】，或【关键词3】时触发。

## 流程
从开始到完成，大概这几步：
1.【第一步做什么】
2.【第二步做什么】
3.【第三步做什么】
......

## 要求
【必须遵守的规则、需要用到的工具，都可以写在这里，不需要特意分类或遵循什么顺序。】

## 输出
【固定的输出格式，比方说要输出Markdown，还是输出HTML，结构是怎样的】

## 补充
以上是我目前能想到的信息。
请你先分析一下：
1. 根据这个任务的性质，我提供的信息是否充分？
2. 如果有关键信息缺失或不够明确，请通过向我提问的方式让我补充
3. 确认信息充分且无误以后，再帮我生成Skill

这个部分的核心，就是告诉AI你想做一个什么样的Skill、这个Skill有哪些流程步骤、你希望拿到一个怎样的结果。

这种方法的好处是能很快拿到一个Skill框架，整个流程和方法论都在里面。当然，刚设计出来的Skill大部分都是不可用的。这时候，就需要再打开一个对话框，调用这个Skill做测试。每个环节都要测试，看看哪里有问题，反馈给AI，让它修改。

这个过程需要多轮迭代，Skill才能变成一个真正稳定、可用的东西。

迭代Skill的核心技巧

通过前面两个方法，你已经可以获得一个还算不错的Skill了。但你会发现，好像还是不够好用！

别人的Skill，能抓数据、能剪视频，甚至还能自动排版、上传发布。你的Skill做完后面忘记前面，或者只会说一句：“对不起，做不到。”

为了让Skill变得更好用，还有两个技巧可以用得上。

第一，善用GitHub

GitHub大家应该都知道，全球最大的开源项目网站。在设计Skill时需要用到的特殊能力，基本上都能在上面找到成熟的解决方案。

比如处理参考视频用的工具FFmpeg，就是AI在GitHub上帮我找到的。还有网页抓取、字幕提取、格式转换、PDF处理这些，GitHub上都有大量成熟项目。

所以当你发现Skill在某个环节不OK的时候，可以直接告诉AI：

但要注意，不要盲目复制整个项目。让AI分析别人是怎么解决问题的，然后把适合的部分工具或方法接进我们的Skill。如果一个GitHub项目里只有一小部分是用得上的，那就只用那一部分就好。

具体怎么让AI去GitHub找？可以用这个提示词填空：

目前Skill存在的问题是【你在哪个环节，遇到了什么问题】。帮我去GitHub上找成熟的解决方案，找到后告诉我：
1）这个工具叫什么、怎么用；
2）哪部分代码或逻辑可以借鉴来优化我的Skill；
3）如果需要安装依赖或配置环境，具体步骤是什么。
注意，不要直接复制整个项目，只提取我需要的部分。

第二，内容分层

在迭代Skill的时候，可能会遇到一个问题，就是Skill越迭代，反而越不好用。

出现这种情况，大概率是因为AI会默认把所有改进加进Skill.md里。所以你迭代越多，Skill.md里堆积的核心流程、历史规则、新规则补丁就会越多，甚至还可能出现前后矛盾的情况。

比较好的解决方法，就是把Skill内容分层。

比如你发现某个环节需要参考案例，可以让AI在Skill里创建一个references/案例库.md，把案例单独放进去。或者发现某个部分规则有很多细节，就创建references/详细规则.md。如果有模板、素材、配色方案，就放进assets/文件夹。

这样，你的Skill.md就能始终保持简洁，AI每次读取的时候不会被一堆细节淹没。需要的时候，它会自己去读对应的参考文档。

这里也准备了一个提示词，迭代Skill的时候直接填空就行：

帮我优化这个Skill，具体要求：

## 需要改进的问题
【描述你遇到的具体问题，比如“触发不准”、“某个步骤经常出错”、“输出格式不稳定”】

## 改进方向
【说明你希望怎么改，比如“增加边界检查”、“优化触发条件”、“补充参考案例”】

## 重要规则
1. 如果需要新增内容，判断它应该放在哪里：
- 核心流程和不变的规则 → 留在SKILL.md
- 参考案例、详细规则、历史记录 → 创建references/目录下的新文档
- 模板、素材、配色方案 → 创建assets/目录下的文件

2. 如果需要修改规则：
- 直接替换旧规则，不要写“不要使用旧规则X”这种表述
- 旧规则直接删除，不要保留任何痕迹
- 新规则写清楚就够了

3. 保持SKILL.md简洁：
- 主文件控制在200行以内
- 如果某个规则需要很多解释，拆到references/里
- 如果需要举例，也放进references/

请先告诉我：
1. 你建议修改哪些地方
2. 哪些内容需要拆出去放进references/或assets/
3. 修改完成后的SKILL.md大概多少行

确认后再帮我修改。

用好这两点，做的Skill基本就可以达到商用水准。

其实在设计Skill时还有很多技巧，比如如何管理上下文、如何审校、如何测试、如何做循环迭代。这些又涉及更复杂的功能和概念，在之后的内容里再慢慢分享。

商业级Skill实例

前面讲的都是方法论，可能有些朋友还是觉得有点抽象，所以特意加了实例部分。

这个部分，会直接拿之前Codex自动化剪辑的工作流来举例，详细拆解设计Skill时使用的工具、遇到的问题，以及解决问题的方法。

如果你在跑工作流的时候有遇到卡点，这个部分应该会有些帮助。

第一步：拆解参考视频

一开始是直接让AI去拆解视频，结果发现它能提取出文案，但怎么都解决不了画面问题。没办法只能自己手动拆解——把参考视频导入剪映，一帧一帧地看，哪里是一个镜头的开始，哪里是结束，手动剪成片段。

后来是怎么解决自动拆解的呢？就是前面说的

。同时用Codex、Google和Perplexity，把问题丢给它们，让AI去找合适的开源项目，然后从里面挑出了FFmpeg。

有了FFmpeg以后，问题也不是马上就解决了。因为FFmpeg虽然能拆解，但并不精准。有时候一个镜头它会拆成两段，有时候两个镜头它又拆成一段。

这时候就需要一个个去找到问题，然后解决问题。比如拆解画面不准确，有些画面只是稍微晃动了一下，或者光线变化了一点，FFmpeg就认为这是一个新镜头，结果一个完整的镜头被切成好几段。后来把检测阈值调高了，从默认的0.3调到0.5左右，这样它就不会对轻微变化那么敏感了。

还有就是会出现一些零碎小片段，有些画面可能就闪现了0.5秒，FFmpeg也会把它切成一个独立片段。但实际上这种超短的片段没什么用，反而会干扰后面的素材匹配。所以加了一个规则：镜头时长至少要1.5秒以上，才算一个有效片段。

有些转场画面，比如淡入淡出、擦除这些，FFmpeg也会误判成镜头切换。这个问题怎么解决？让AI在拆分以后，再检查一遍相邻片段的画面相似度。如果两个片段的画面内容很像，只是中间有个转场效果，那就把它们合并成一个片段。

第二步：匹配素材

拆完片段以后，就要匹配素材。这一步其实就是告诉AI，参考视频的每个片段，应该用准备的哪些素材。

最初的方案是直接根据文案匹配，但效果不太OK。它经常会选一些完全不相关的素材，或者同一个素材用好几次。这些就需要给到AI更明确的规则。比如要看文案的语义，不只是看关键词。

还有如果使用的是竞品素材，那素材的视角、景别、动作这些都要做对比，像素级筛选。参考视频用的是45度斜拍的视角，那素材也选择类似的斜拍视角。画面内容可以不一样，但角度和场景要对得上。

另外还有个问题，就是素材的时长。有些素材太短，画面刚出来就切走了；有些太长，一个画面停好几秒。让AI做了一个处理：如果素材不够长，可以降低播放速度；如果太长，就选择最合适的那一段剪掉多余的。

第三步：生成配音

配音这一步是折腾最久的。

最开始用的是Codex推荐的Edge TTS，就是微软的文字转语音工具。但生成出来的配音特别机械，而且能选择的音色只有几个。

后来请教了一些大佬，他们推荐用VoxCPM，说效果会好很多。试了一下，确实比Edge好。但VoxCPM有一个问题：声音不稳定，有时候说着说着就变调了，或者突然冒出一些“呵呵”这种奇怪的声音。

起初是想找到一个免费的配音解决方案，但试了几个工具都不太行。后来发现，豆包语音的性价比反而是最高的。虽然说需要一定的API费用，但成本很低，新账号注册也有送token，关键是效果稳定，想要的音色基本都能找得到。

用豆包以后，确实好用了很多。但又发现新的问题：每句话之间的间隔太长，听起来一顿一顿的，调了几次都没办法解决。后来检查发现，豆包语音生成的时候，会按标点符号来设计停顿。于是加了一个音频处理的环节：不要使用标点符号设计停顿，而是识别每句话之间的空白，保留0.5-1秒的自然停顿。

这样，过长停顿的问题解决了，配音的流畅度又能很好保留。

还有一开始经常会出现配音、画面和字幕无法精准匹配的问题。最简单的方法，就是先生成配音，记录每句话的时长，然后根据配音时长来计算字幕的显示时间和素材的长度。当然，这个也是和Codex聊了好几种方案，最终测出来的。

第四步：导入剪映草稿

前面都搞定以后，就需要把视频导入剪映草稿，去做最后的审核和修改。

自动化剪辑Skill一开始的方案，是想让Codex直接操作剪映去剪辑，但剪映文件是加密的，根本没有办法操作。那怎么办呢？

后来想想，完全没必要使用剪映啊，Codex直接就可以用脚本完成剪辑。Codex剪完以后，再把成品丢进剪映，那就搞定了。

能导入剪映以后，又遇到一个新的问题：修改视频的时候，只要开着剪映就无法导入新草稿。因为剪映会锁定草稿文件，你没办法覆盖它。

这种问题其实用Codex也很好解决，只要再加一个脚本。让AI在修改完视频以后，自动关闭剪映，然后导入新草稿。导入以后再重新打开，然后再去做审校和细节处理。

写在最后

以上就是全部内容了。

看完以后，应该能感觉到，一个好用的Skill其实是经过了非常多次迭代才成型的。不是一开始就能把所有问题都想清楚，而是在真实使用中，不断发现问题，不断解决问题，Skill才会慢慢变得好用。

但这个过程是值得的。就好比自动化剪辑Skill，虽然过程中遇到的问题非常多，但解决以后带来的收益也非常大。不仅产出效率提升了很多，前两天又跑出一条新的爆款视频，就非常香。