【万字干货】实战拆解如何从 0 到 1 手搓商用级 AI Skill

本来想先写个人知识库和内容创作工作流的，写了两天发现那个话题太散，不如先把 Skill 这事说清楚。

全文都是这几个月踩过的坑，网上搜不到第二份。如果你正在折腾 AI 工作流，这篇文章能帮你省掉至少两周的摸索时间。

为什么要专门写一篇讲 Skill

Skill 里面混了我不少内部数据和业务规则，文案怎么改、素材怎么筛、镜头怎么配，全是针对特定产品定制的。就算我把文件丢给你，你大概率也用不上——改到能用的时间，够你从头写三个新的了。

所以我想，不如换个思路：把做 Skill 的方法论拆给你看。你理解底层逻辑以后，对着自己的真实问题去搭，比抄我的作业靠谱得多。

Skill 到底是什么

先花两分钟对齐一个概念。已经懂的朋友可以跳过这一段。

你把 Skill 想成一份岗位说明书就行。

AI 本质上是个刚入职的名校生——聪明，反应快，但对你公司的业务一无所知。你得给它一份写得明明白白的文档，告诉它：每天几点干什么、用什么工具、做到什么程度算及格、什么情况该停下来问我。

这份文档就是 Skill。

具体来说，一个完整的 Skill 长这样：

my-skill/ ├── Skill.md # 核心说明书（必须有） ├── references/ # 参考资料、案例库、详细规则 ├── scripts/ # 工具脚本、自动化代码 └── assets/ # 模板、素材、配色方案

Skill.md 是必须的，其他三个文件夹看任务复杂度决定要不要。

这里有人可能会问：Skill 和 Prompt 有什么区别？

Prompt 是你每次对话时临时打的字，用完就丢。Skill 是一个打包好的能力单元，里面有指令、有脚本、有参考文档、有模板。你做好一个 Skill 放到文件夹里，下次遇到同类任务，斜杠一调就能用。

举个真实的例子：我的文章配图 Skill，连提示词都不用写。输入 /配图，@ 一下草稿，AI 自己找图、裁图、插到文章对应位置。全程我不说一句话。

设计 Skill 的两条路

理解概念以后，下一个问题是：怎么从零开始搭一个 Skill？

我自己的经验就两条路，看任务复杂度选。

路线 A：先跑通流程，再沉淀成 Skill

这条路适合轻量级任务——写文章、起标题、做日报这类。

具体操作就是：你手动把整个流程走一遍。第一步卡住了就问 AI，解决完继续下一步。全部跑通了，你跟 AI 说一句“把这个流程沉淀成 Skill”，它就能帮你打包出来。

好处是成品基本能直接用，因为每个环节你都亲手验证过。

但这条路走不远。

一旦流程超过五六个步骤，对话轮数一多，AI 的上下文窗口就开始吃紧了。打包 Skill 的时候它经常漏掉关键细节，给你一个半成品——看着像那么回事，一跑就崩。

我一开始用这个方法做剪辑 Skill，折腾了一个下午，最后出来的东西连我自己都看不懂。

路线 B：直接用 Skill-Creator 搭框架，再迭代

这条路适合复杂流程，也是我后来主要用的方法。

几乎所有主流 AI 工具里都内置了一个叫 Skill-Creator 的工具（它本身也是个 Skill）。Codex 里有，Claude 里有，触发方式一般是斜杠命令或者直接说“我要设计一个 Skill”。

调用以后，你把自己的需求按这个模板填进去：

## 任务 帮我创建一个 Skill，名字叫【Skill 名】，主要用来【具体想做的事】。 ## 触发 在我提到【关键词 1】、【关键词 2】时自动触发。 ## 流程 1. 【第一步做什么】 2. 【第二步做什么】 3. 【第三步做什么】 ... ## 要求 【必须遵守的规则、需要用到的工具，不用分类，想到什么写什么】 ## 输出 【固定格式：Markdown / HTML / JSON，结构长什么样】 ## 补充 以上是目前能想到的所有信息。 请你先分析： 1. 这些信息够用吗？ 2. 如果不够，问我哪些具体问题？ 3. 确认无误后再生成 Skill。

这套模板的好处是，你能在十分钟内拿到一个完整的框架。方法论、流程、边界条件都在里面。

但别高兴太早——刚出来的 Skill 几乎一定是不能用的。

接下来才是重头戏：开一个新对话，调这个 Skill 跑真实任务。每个环节都要测，哪个环节出问题，就把报错信息甩回去让 AI 改。这个迭代过程短则三五轮，长则几十轮。

我那个剪辑 Skill，迭代了大概 12 版才算稳定。

让 Skill 真正好用的两个狠招

按上面两条路走完，你手里会有一个“看起来还行”的 Skill。但跑两天你会发现，它跟网上那些能抓数据、能剪视频、能自动发布的商用 Skill 比起来，差得不是一点半点。

你的 Skill 要么做到一半忘了前面说了什么，要么冷不丁来一句“抱歉，我无法完成这个任务”。

这时候就需要上两个狠招。

狠招一：去 GitHub 抄作业

GitHub 是个宝藏库，你在做 Skill 时遇到的几乎所有“非标”问题，上面都有现成的开源方案。

我做剪辑 Skill 的时候，最头疼的是把参考视频自动拆成一个个镜头。试了十几种方案都不行，最后让 AI 去 GitHub 扒，扒到了 FFmpeg 的一个场景检测脚本。

但这里有个坑：千万别让 AI 把整个项目塞进你的 Skill。

GitHub 上一个项目动辄几千行代码，你全塞进去，Skill 会直接卡死。正确做法是让 AI 分析这个项目里哪一小块能解决你的问题，把那部分单独抽出来接进去。

我当时用的提示词长这样：

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

用这个模板，我陆续给 Skill 加上了网页抓取、字幕提取、格式转换、PDF 解析这些能力。每一个都不是我自己写的，全是从 GitHub 上挑出来的最小可用单元。

狠招二：给 Skill 做“文件瘦身”

这条是我踩过最大的坑，没有之一。

Skill 迭代到第十版左右的时候，你会发现它突然变笨了。之前能跑通的流程，现在老是出错；之前记得住的规则，现在开始遗忘。

我一开始以为是 AI 模型的问题，换了几个模型都一样。后来排查才发现，问题出在 Skill.md 这个文件上。

AI 每次改 Skill，都默认把新规则、新补丁、新案例往 Skill.md 里面堆。迭代到十版以后，这个文件已经 800 多行了，里面既有核心流程，又有历史规则，又有“某某情况下不要用旧规则 X”这种补丁说明。AI 读到一半就懵了，前后规则开始打架。

解决方法特别朴素：把 Skill.md 拆薄，其他东西扔到子目录里。

具体来说：

• Skill.md 只放核心流程和永远不变的硬规则，控制在 200 行以内

• 案例、详细规则、历史记录，全部塞进 references/ 子目录

• 模板、素材、配色方案，扔进 assets/ 子目录

AI 每次执行任务时，只读 Skill.md 这个薄文件。需要查案例的时候，它自己会去 references/ 里翻。

我后来专门写了一个提示词做这事：

帮我优化这个 Skill，具体要求： ## 需要改进的问题 【描述具体问题，比如"触发不准""某步骤老出错""输出格式乱"】 ## 改进方向 【你希望怎么改，比如"加边界检查""优化触发""补案例"】 ## 重要规则 1. 新增内容要判断归属： - 核心流程和硬规则 → 留在 SKILL.md - 案例、详细规则、历史记录 → 创建 references/ 下的新文档 - 模板、素材、配色 → 创建 assets/ 下的文件 2. 修改规则时： - 直接替换旧规则，别写"不要用旧规则 X"这种补丁句式 - 旧规则直接删掉，不留痕迹 - 新规则写清楚就行 3. 保持 SKILL.md 简洁： - 主文件控制在 200 行以内 - 需要很多解释的规则，拆到 references/ - 需要举例的，也放进 references/ 请先告诉我： 1. 你建议改哪些地方 2. 哪些内容需要拆出去 3. 改完以后 SKILL.md 大概多少行 确认后再动手改。

用好这两个狠招，你做的 Skill 基本就能达到商用水平了。

当然还有更深的东西——上下文管理、自动审校、回归测试、循环迭代这些。篇幅原因这篇不展开，后面单独写。

一个真实的商用 Skill 是怎么搭出来的

光讲方法论太抽象。下面我把之前那个自动化剪辑 Skill 的搭建过程完整拆一遍，包括每一步用了什么工具、卡在什么地方、怎么爬出来的。

如果你上次跟着那篇文章跑工作流卡住了，这一段应该能救你。

第一关：把参考视频拆成一个个镜头

一开始我想得很简单，让 AI 直接分析视频文件。结果它能提取出文案，但对画面完全没辙。

被逼无奈，我自己把参考视频拖进剪映，一帧一帧地看，手动把每个镜头切开。一个五分钟的短视频，我切了整整一下午。

切到第三个视频的时候我实在受不了了，开始同时用 Codex、Google、Perplexity 去扒解决方案。最后扒到了 FFmpeg 的场景检测功能。

但 FFmpeg 也不是开箱即用。

它默认对画面变化太敏感了。摄像机稍微晃一下，或者光线变了一点，它就认为这是个新镜头，把一个完整镜头切成三四段。我后来把检测阈值从默认的 0.3 调到 0.5 左右，才把这个问题压住。

还有另一个毛病：它会切出大量零点几秒的碎片片段。这种超短镜头对剪辑毫无用处，反而会干扰后面的素材匹配。我又加了一条硬规则——时长低于 1.5 秒的片段直接丢弃。

最烦的是转场误判。淡入淡出、擦除这些效果，FFmpeg 会当成镜头切换。解决方法是让 AI 在切完之后，再扫一遍相邻片段的画面相似度——如果两段内容很像，只是中间有个转场，就合并回去。

这几个问题来回调了三天。调完以后我盯着屏幕，有一种当年调 CSS 垂直居中的恍惚感。

第二关：给每个镜头配对的素材

拆完镜头，下一步是告诉 AI：参考视频的每个镜头，应该用我素材库里的哪个素材来替换。

最初的方案是按文案关键词匹配。结果惨不忍睹——AI 选出来的素材经常八竿子打不着，同一个素材还能被它用上七八次。

后来我把规则改细了：

• 不要只看关键词，要看整段文案的语义

• 如果是竞品素材，必须做像素级筛选——参考视频是 45 度斜拍，我的素材也得是斜拍；画面内容可以不一样，但角度和场景必须对得上

还有一个时长问题。有的素材太短，画面刚出来就被切走；有的太长，一个画面能停四五秒。

我让 AI 自己处理这事：素材不够长就降速播放，太长就挑最精华的一段裁掉多余的。

这一步没遇到什么惊天大坑，就是细活，得一条一条规则喂给 AI。

第三关：生成能听的人声

配音是整条链路里折腾最久的一环，前后换了三套方案。

第一套是 Codex 推荐的 Edge TTS，微软的文字转语音。出来的声音特别机械，能选的音色就那么几个，一听就是 AI 在念稿。

后来请教了几个做视频的朋友，他们推荐 VoxCPM。我试了一下，确实比 Edge 自然很多。但 VoxCPM 有个诡异的毛病——声音不稳定，说着说着突然变调，有时候还会蹦出“呵呵”这种莫名其妙的杂音。

我本来想找个免费的方案，试了四五个都不行。最后妥协用了豆包语音。虽然要付 API 费用，但成本很低，新号还送 token，关键是效果稳定，想要的音色基本都能找到。

用了豆包以后，配音质量上来了，但又出了新问题：每句话之间的停顿特别长，听起来一顿一顿的，调了好几次都不行。

排查了一圈才发现，豆包语音默认按标点符号设计停顿——逗号停一下，句号停一下，顿号还停一下。我加了一个后处理环节：不用标点符号控制停顿，改成识别句子之间的空白，统一保留 0.5 到 1 秒的自然间隔。

改完以后流畅度一下子就好了。

还有一个配套问题：配音、画面、字幕三者怎么对齐。

最简单的做法是以配音为基准——先生成配音，记录每句话的时长，再根据配音时长反推字幕显示时间和素材长度。这个方案是和 Codex 聊了好几种以后测出来的，目前跑得最稳。

第四关：导入剪映做最后审校

前面三关都过了，最后要把成品导入剪映草稿，做人工审核和微调。

一开始的方案是让 Codex 直接操作剪映。但剪映的草稿文件是加密的，根本没法外部写入。

我愣了半小时，突然反应过来：我干嘛一定要用剪映来剪呢？

Codex 自己就能用脚本完成剪辑。它剪完以后生成一个成品视频，我直接把成品丢进剪映做最后的审校，不就行了吗？

思路一转，问题就没了。

但导入剪映以后又遇到一个小坑：只要剪映开着，你就没法覆盖草稿文件，因为它会把文件锁住。

这种问题加个脚本就解决了：让 AI 在修改完视频以后，先自动关闭剪映，导入新草稿，再重新打开剪映。我进去接着审校就行。

整个链路打通的那一刻，我盯着自动跑完的视频，愣了大概十秒钟。然后打开外卖软件，点了份烧烤。

说点掏心窝的话

写到这里大概一万多字了。

回过头看，一个真正好用的 Skill，从来不是一次设计出来的。它是你在真实使用里，被同一个坑绊倒三次以后，骂骂咧咧地爬起来加上一条规则；是半夜两点发现某个步骤老是失败，爬起来查日志查到凌晨四点；是第 12 版迭代跑通的时候，你看着屏幕，突然有点想哭。

没有谁一开始就能把所有问题都想清楚。

你能做的，就是先动手搭一个粗糙的框架，然后在真实场景里反复折磨它。它每崩一次，你就离一个稳定的商用 Skill 更近一步。

作者提示含AI生成内容。作者声明本文无利益相关，欢迎值友理性交流，和谐讨论～