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

这篇文章，我会从我对Skill的理解、设计Skill的方法、怎么升级和迭代Skill这些维度展开。并且会结合之前的Codex自动化剪辑工作流，尽可能用简单和直白的语言，把Skill讲清楚，确保朋友们看完就能用得上。

放心阅读，全是一手经验，网络上没有的那一种。

Hi，朋友们，我又来交稿啦～

这次为什么想分享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，会被放到一个专门的文件夹里 （支持Skill的主流AI模型，都有类似的文件夹）。以后每次遇到类似的任务，你只要输入斜杠命令，就可以直接调用Skill。

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

设计Skill的两种方法

OK，理解Skill的概念以后，我们要怎样去设计一个Skill呢？

我的经验是，先总结你的SOP，也就是工作流程。

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

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

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

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

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

我自己做Skill，一般有两种方法。

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

简单来说，就是你先手动把整个工作流跑一遍。从第一步开始，遇到问题就让AI帮你解决，解决完继续下一步。

等整个流程都跑通了，你再跟AI说：

把这个工作流程沉淀成Skill。

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

但这个方法它实际上只适合一些轻量的Skill，比方说文章写作Skill、标题创作Skill。

一旦涉及到流程相对复杂的Skill，就会出现很多问题。

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

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

第二种方法，和第一种正好相反，即先做Skill，再迭代。

一般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：去GitHub找解决方案。

但要注意，不要盲目复制整个项目。

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

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

目前Skill存在的问题是【你在哪个环节，遇到了什么问题】。帮我去GitHub上找成熟的解决方案，找到后告诉我：

1）这个工具叫什么、怎么用；

2）哪部分代码或逻辑可以借鉴来优化我的Skill；

3）如果需要安装依赖或配置环境，具体步骤是什么。

注意，不要直接复制整个项目，只提取我需要的部分。

第二，内容分层。

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

出现这种情况的原因，大概率是因为AI会默认把所有改进加进了 Skill.md 里。

所以你迭代越多，Skill.md里堆积的核心流程、历史规则、新规则补丁就会越多，甚至还可能出现前后矛盾的情况。

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

Skill.md里面，只放核心流程和不变的规则，其他全部拆分。

比方说你发现某个环节需要参考案例，可以让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实例

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

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

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

第一步：拆解参考视频

一开始我是直接让AI去拆解视频，结果发现它能提取出文案，但怎么都解决不了画面问题。

没办法只能自己手动拆解。就是把参考视频导入剪映，然后一帧一帧地看，哪里是一个镜头的开始，哪里是结束，手动剪成片段。

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

我是同时用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聊了好几种方案，最终测出来的。

**第四步：导入剪映草稿

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

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

那怎么办呢？

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

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

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

写在最后

以上就是全部啦。

看完以后，朋友们应该能感觉到，一个好用的Skill其实是经过了非常多次迭代才成型的。

不是说你一开始就能把所有问题都想清楚，而是在真实使用中，不断发现问题，不断解决问题，Skill才会慢慢变得好用。

但这个过程是值得的。

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

文章来自于"周行今天AI了吗"，作者 "周行"。