这篇文章，我会从AI Skill 的基础概念、设计方法、迭代升级这几个维度展开，并结合我之前那套 Codex 自动化剪辑工作流，用通俗易懂的大白话把 Skill 讲清楚，确保大家看完就能直接上手使用。

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

前面提到过，我的剪辑 Skill 里包含大量内部业务信息，确实不太方便直接分享。另外，Skill 中的文案修改规则、素材筛选匹配逻辑，都是针对特定产品专门设计的，即便给到你，可能也用不上。与其花时间去修改，还不如重新创作一个新的 Skill 来得高效。

所以，我换了一个思路：与其直接给一个现成的 Skill，不如分享一下我是如何设计出一个商用级 AI Skill 的。理解了背后的方法，你就可以根据自己的实际需求，去打造一套专属的 Skill 工作流。

这里面也会分享一些我在做自动化剪辑 Skill 时遇到的卡点和具体的解决方案。如果你正在跟着前一篇文章跑工作流，这篇内容值得仔细看看。

理解 AI 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，输入 @ 找到写好的文章，AI 就会自动帮我配图并插入到文章里。

设计 AI Skill 的两种方法

理解了 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 才能变成一个真正稳定、可用的工具。

迭代 AI 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 时还有很多技巧，比如如何管理上下文、如何审校、如何测试、如何做循环迭代。这些又涉及更复杂的功能和概念，在之后的内容里再慢慢分享。

商业级 AI Skill 实例拆解

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

这个部分，会直接拿之前 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 聊了好几种方案，最终测出来的。

第四步：导入剪映草稿

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

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

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

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

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

写在最后

以上就是全部内容了。

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

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