180个开源Claude Code Skill：让AI视频创作全流程自动化

最近一段时间，我的工作流踩进了一个挺有意思的坑里：Claude Code 不只是能写代码，它还能通过一套叫 Skill 的扩展机制，去干视频创作这种看起来和编程八竿子打不着的活。我在开源社区翻了一圈，发现相关的 Skill 已经有 180 个左右，里面 107 个项目的 star 数甚至不到 50。这些数字背后藏着一个很有趣的现象——真正好用的东西，往往不是热榜上那些。

这篇文章我想以视频创作为主线，把这 180 个开源 Skill 的底细拆给大家看：从哪里找、怎么分类、哪些最值得装、哪些冷门货能解决大问题。如果你正在让 AI 帮你写脚本、做分镜、配字幕、出封面，这套生态大概率能帮你省掉不少重复劳动。

1. 先搞清楚底层逻辑：Skill 机制到底是什么

1.1 Skill 和普通提示词的本质区别

很多人第一次听到 Skill 这个概念，第一反应是“这不就是一段 Prompt 吗”。这么说也不算错，但只对了一半。普通 Prompt 是一次性的，你在对话框里说“帮我写个视频脚本”，模型基于上下文临时发挥，用完即焚，下一次还要重新组织语言。Skill 则是一份结构化的操作手册，它告诉你“我面对的是一个有明确流程的任务，请你按这个方法来”。

以 Claude Code 的 Skill 为例，它的核心是一个 markdown 文件，通常叫 SKILL.md。文件里有 front matter，包含 name 和 description 字段。name 是这个技能的 ID，description 则写清楚“什么场景下该触发这个技能”。正文部分就是具体的步骤、规则和示例。当你和 Claude Code 对话时，它会根据你当前的意图去匹配这些描述，匹配上了就把整份手册作为上下文加载进来，然后按手册里定义的流程干活。

这个机制最大的价值在于复用和沉淀。你把一套好的工作流固化成一个 SKILL.md，下次直接喊一声就能启动，不用重新调教。而且文件是纯文本，可以放进 Git 仓库，可以给别人 fork，可以发到社区里共享。这也就是为什么 GitHub 上会出现 180 多个视频相关 Skill 的原因——门槛太低，产出太快，人人都在沉淀自己的方法。

1.2 为什么视频制作特别适合用 Skill 来封装

视频制作和写代码有一个共同的底层特征：环节多、流程长、每个环节有相对固定的套路。你不可能把“做一个视频”这件事扔给 AI 一句话完成，但你可以把“写脚本”拆成“定选题、列大纲、写逐字稿、做分镜”，把“后期”拆成“识别字幕、生成封面、写标题”，每一个子任务都有稳定的执行方式。

Skill 天然就是干这个的。你可以为每个环节分别装一个 Skill：有的负责把一句话扩展成完整的分镜脚本，有的负责把文字描述翻译成文生图的 Prompt，有的负责从原始素材里整理时间轴标记。Claude Code 本身有很强的工具调用能力，它可以在执行 Skill 的过程中去读文件、跑命令，甚至调用外部程序。这意味着 Skill 不只是“给你提建议”，它可以直接帮你操作项目文件。比如我见过一个 Skill，它的工作流是：读取一个剪辑项目的时间线数据，分析每段素材的内容标签，然后输出一份排版好的字幕文件。

此外，视频创作的“失败成本”比写代码更低，更适合试错。写错代码会报错，但脚本写得不好、Prompt 不够精确，大不了重新生成几次。这种场景下，用 Skill 反复迭代一套流程，边际收益会越来越高。

2. 180 个开源 Skill 的完整分类地图

2.1 一级分类与占比

我在整理这批 Skill 的时候，按功能把它们分成了六大类。这个分类不完全按技术难度，更多是按视频创作的实际环节来划分，方便每个人都能找到自己需要的那一块。

合起来数量正好是 180 个。需要注意的是，这些数字不是一潭死水，开源社区每天都有新 Skill 冒出来，也有旧项目被更新或归档。我统计的时候是以“具备完整 SKILL.md 结构、能独立加载运行”作为筛选标准，很多只有 idea 没有落地的项目没有算进去。

从占比可以看出，脚本与分镜类数量最多。原因很简单：这是视频创作里最适合 AI 发挥的部分，也是纯文字任务，最容易用 Skill 固化。而像素材管理这种偏工程的类型，虽然数量少，但实际使用频率和收益往往更高，属于闷声发大财的类别。

2.2 视频创作链路中的 Skill 拼图

把 180 个 Skill 放回真实创作流程里看，你会发现有两条明显的主线。第一条是内容生产链：创意→脚本→分镜→画面→音频→字幕→封面。沿着这条链路走，你会发现每个节点都有对应的 Skill 可以插入。

第二条主线是效率优化链：批处理、数据整理、格式转换、跨工具搬运。这类型的 Skill 不会直接产出一条视频，但它能让你的工作流节省大量时间。举个例子，有个 Skill 专门负责把 Excel 表格里的选题库批量转成带格式的脚本草稿，输入一列关键词，输出一整套文件目录，每个选题自动建好文件夹并生成初稿。这一类工具型的 Skill 在热榜上往往不显眼，但在生产环境里价值极高。

还有一条隐线值得注意：跨平台适配。国内外的视频平台生态差异很大，很多 Skill 是专门针对某一类平台设计的，比如竖屏短视频、中长视频、直播切片。使用的时候要看好它的目标平台，不然做出来的内容格式会对不上。

3. 视频创作场景的 Skill 深度拆解

3.1 脚本与分镜：让 AI 先当好编剧

脚本类的 Skill 是所有视频创作者最该优先接触的一批。这类 Skill 的通用逻辑是：给定一个主题或一句核心观点，通过结构化的问题引导模型逐步输出选题分析、受众画像、大纲框架，最后生成完整的分镜脚本。

我在用的时候发现一个关键点：好的脚本 Skill 一定会带有“视角约束”和“格式锁定”。视角约束是指它会要求 AI 站在某个身份上输出，比如“一个 3 年经验的旅行博主”或“一位严谨的科普作者”。格式锁定则是规定好表格字段，比如序号、时长、画面描述、旁白文案、备注。这样生成的脚本不管是给人看还是给 AI 后续生成画面，都能直接落地。

分镜类 Skill 对细节的要求更高。一个合格的分镜 Skill 会明确要求镜头类型（远景、中景、特写）、转场方式、画面内容、台词、音效建议。我见过一个写得很好的项目，它把分镜的每一列都做了详细的填写示例，还在 SKILL.md 里写了“禁止输出抽象描述，每个画面必须是可拍摄的实体内容”这样的规则。这种细节约束才是 Skill 的价值所在——它不是在生成文本，而是在生成可执行的拍摄方案。

3.2 素材生成：文生图、文生视频的 Prompt 工程

图像和视频生成的 Skill 数量不如脚本类多，但它们的“可复制性”更强。原因在于 Prompt 工程已经积累了大量的实践经验，而 Skill 可以把这些经验直接固化下来。

这类 Skill 的核心能力是“Prompt 翻译”。你把一句白话需求告诉 Claude Code，它按照 Skill 内部的规则把这句话转成结构化的生成提示词。比如需求是“一个赛博朋克风格的城市街道，雨天，霓虹灯”，经过好的 Skill 处理后，它会补充光线方向、镜头焦距、画面构图、色彩基调、细节质感等描述，最终生成一段可以直接粘贴到图像生成工具的 Prompt。

更进阶的 Skill 会涉及负面 Prompt 管理。很多人忽略负面提示词的作用，但有过生成经验的人都知道，一个写得好、覆盖面广的负面 Prompt 能避免大量废图。有些 Skill 会把常见的失败案例（模糊、畸形、多余手指、水印）预置进去，生成时自动拼接在末尾。

这里我想给一个实操建议：如果你同时使用多款图像生成工具，尽量找那种“输出格式可配置”的 Skill，或者在 SKILL.md 里手动加一个参数位来切换平台语法。因为不同工具的 Prompt 解析风格差别很大，同一套描述在一个工具里能出好图，换一个工具结果可能就是灾难。

3.3 后期与封面：从粗剪到包装

后期环节的 Skill 往往被低估，但它们恰恰是最能节省时间的地方。字幕类的 Skill 通常可以自动将转录文本按时间轴切分，并输出特定格式的字幕文件。有些还支持多语言翻译和术语统一，调用之后直接产出带样式的字幕稿。

封面类的 Skill 则更偏向 Prompt 工程和文案生成。它会根据你的视频主题和风格标签，生成一组封面设计方案，包含主标题、副标题、视觉风格、构图建议。这类 Skill 的输出可以作为图像生成工具的输入，也可以直接当成给设计师的参考。

标题与标签优化是后期类 Skill 里技术含量最高的。好的标题优化 Skill 不只是罗列几个标题选项，它会分析目标平台的推荐机制，按平台调性拆解关键词密度、时长要求、情绪引导等要素。比如同样是“三分钟学会做咖啡”，竖屏短视频平台喜欢的写法和中长视频平台完全不同。这类 Skill 的目标就是确保你产出的标题不只“看起来不错”，而是真的符合分发场景。

4. 107 个冷门宝藏：star 少不等于不好用

4.1 低星项目的价值洼地是怎么形成的

开源项目的 star 数有时候和真实质量完全不成正比。我盘点了这批不到 50 星的 Skill，发现它们的处境大致有四种。

第一类是领域过于垂直，目标用户太少。比如某个专门为“口播类知识视频”设计的脚本框架，它对口播内容创作者来说几乎能直接套用，但这个领域的人群本身就有限，自然难有高 star。第二类是作者不擅长包装。有些项目的 SKILL.md 写得非常扎实，步骤清晰、示例丰富，但是 README 只有一句话，没有任何预览图或效果展示，在信息流里完全无法吸引点击。

第三类是发布时间太短，还没来得及被社区发现。这 107 个里面有相当一部分是最近一两个月才提交的，本身功能完整，只是曝光量还不够。第四类是被技能描述“坑”了。有些 Skill 明明非常实用，但 description 字段写得过于笼统，导致 Claude Code 在匹配场景时经常漏掉它，作者自己可能都没发现这个问题。

低 star 不意味着低质，反而可能意味着这个几经打磨的冷门工具恰好是别人没发现的需求解药。找这些宝藏的过程很像早年淘 App，不是看下载量，而是看开发者是不是真的在解决自己的痛点。

4.2 冷门宝藏的挖掘方法与实用代表作

挖掘这些冷门 Skill 的方法，我总结成四个字：交叉检索。GitHub 的搜索页用不同的关键词组合去查，比如“claude skill video”“claude skill subtitle”“claude skill storyboard”。同一个功能换三四种说法去搜，你会发现底层的项目池完全不一样。

翻 Skill 内容的时候，别只看 README，要直接看 SKILL.md 里 body 部分。很多宝藏项目的干货都藏在正文里，里面有大量的示例对话、边界情况处理和写作约束。判断一个 Skill 是否值得装，只需要看三点：描述是否具体到能触发、步骤是否可执行、示例是否接地气。

我印象比较深的一个冷门项目是个字幕双语对照 Skill，它不生成内容，而是把已有字幕文件按句对齐，生成了中英对照的文本供后续校对。这个功能听起来简单，但它把时间轴对齐、断句规则、术语表维护都做进了 Skill 里，处理几百条字幕几乎零错误。这个项目在 GitHub 上只有 20 多个 star，但它解决的是我实际剪辑时最头疼的环节。

此外还有一类值得关注的冷门项目是“本地素材库助手”。它扫描指定文件夹，把所有视频和图片素材的名字、大小、分辨率、拍摄日期提取出来，生成索引文档，方便后续检索和选用。很多人的素材库动辄上百 G，缺的正是这种让 AI 接管元数据管理的小工具。

5. 实操：从零到一配置一套视频创作 Skill 工作流

5.1 安装 Skill 的正确姿势

Skill 的安装方式取决于你使用的 Claude Code 版本。最通用的一种是把项目 clone 下来，找到其中的 skill 目录，将对应的文件夹复制到本机的 Claude Skills 目录里。不同系统路径不一样，macOS 和 Linux 通常在~/.claude/skills/下，Windows 则可能有单独的环境变量配置。

复制完成后，建议立即验证一下技能能否被正常识别。最直接的办法是新建一个会话，输入一段与你配置的 Skill 描述相关的任务，观察 Claude Code 是否调用它。它会在日志里打印加载了哪个 Skill，以及在哪个步骤触发的。看到这个信息就说明安装成功，如果没看到，多半是路径问题或者描述和触发词对不上。

SKILL.md 的基本结构我建议这样写：

--- name: video-script-writer description: 当用户需要写视频脚本、分镜脚本或口播文案时使用。适合用于知识类、生活类短视频内容策划。 --- # 视频脚本生成流程 1. 询问视频主题和时长要求 2. 按“钩子—铺垫—正文—结尾引导”四段结构拆分 3. 输出分镜表格，包含序号、时长、景别、画面描述、旁白文案 4. 检查文案是否口语化，禁止书面腔表达

这段配置的核心在 description，它直接决定了技能的触发率。写得越具体，匹配越准。比如“长视频”“口播”“Vlog”这种词能多大程度覆盖你实际的使用场景，需要你自己在真实对话里试几次再调整。

5.2 组合多个 Skill：一条完整的视频工作流

单装一个 Skill 不难，难的是把多个 Skill 串成一条能跑通的工作流。我这里给出一套我常用的组合方式，覆盖从选题到封面全流程。

首先是选题策划阶段，加载一个“选题拓展”类 Skill。你输入一个模糊的方向，比如“城市独居生活”，它会输出 10 个具体选题，每个选题附带受众分析和视角建议。然后你选其中一个，接着切换“分镜脚本”类 Skill，输入大纲和想突出的重点，生成表格形式的分镜文稿。

到画面生成阶段，把分镜表格里的画面描述直接喂给“Prompt 优化”类 Skill，它会输出一组多平台兼容的图像生成提示词。用这些提示词去图像工具里出图，选定后再用“封面包装”类 Skill 生成标题方案。最后剪辑时，用字幕类 Skill 处理转录文本，生成字幕文件。

这个流程看起来长，但如果每个 Skill 都能稳定跑通，你从想法到成片的效率会非常可观。贵在小步快跑，不要一开始就追求全自动，先手动跑两遍，把每一步的输出格式确认好，再去研究自动化串联。

5.3 调参与质量验证的一点心得

调 Skill 的过程很像做实验，每一次修改都要可观测。我习惯在 SKILL.md 里给每个输出环节加“必须输出 xxx 格式”的硬约束，然后跑一个标准测试样本，检查输出是否符合预期。如果某一步的结果经常出错，就回到那一步仔细看规则里的描述，往往是约束条件写得不够明确。

这里有个技巧：好的 SKILL.md 不只是定义步骤，还要定义“什么不能做”。比如分镜类 Skill 可以加一条“不要输出无法拍摄的抽象描述，比如‘氛围感’、‘文艺范’，必须写具体动作和场景”。负面约束往往是质量和效果的分水岭。因为模型生成的默认行为里面不会自带这种取舍，你不限它是不会主动收敛的。

6. 常见问题与排查技巧实录

6.1 Skill 完全不触发怎么办

Skill 不触发，九成以上是 description 写得太泛。比如你写“用于视频制作”，这个描述会被匹配到各种乱七八糟的场景，真正的视频任务反而不一定能精确命中。解决方法是把触发场景写得密一些，多列同义动作，比如“写脚本”“出分镜”“做字幕”“生成口播稿”都写进 description 里。

第二个常见原因是目录层级不对。很多 Skill 项目本身是一个仓库，仓库根目录下才是 SKILL.md，复制的时候容易把整个仓库文件夹当成技能目录。Claude Code 会去指定目录下逐个找 SKILL.md，如果你把仓库套了一层目录，它会吃不到。

第三个原因是会话上下文里已有其他指令干扰。如果前面的对话里明确指定了某种行为模式，模型倾向于沿用已有约定，新 Skill 即使存在也不会触发。这时候开一个新会话再测试会比较干净。

6.2 上下文爆炸与输出质量下降

Skill 加载的本质是向上下文注入一长段指令。一次加载还好，如果同时加载多个大型 Skill，或者 Skill 正文里嵌了大量示例，上下文很容易被撑爆。上下文一长，模型的行为会飘，输出逻辑开始不连贯，甚至把不同 Skill 的规则混在一起用。

我的对策是把 Skill 分成“轻量版”和“完整版”。轻量版只保留核心步骤和关键约束，适合日常复用；完整版包含全部参考资料和边界示例，只在需要深加工的时候手动切换加载。另外，SKILL.md 里的示例不要贪多，放两到三个有代表性的就够，更多细节用链接或引用外部文件的方式提供。

6.3 选型与维护的避坑建议

最后分享几个选型和维护上的教训。第一，不要只看 star 数，但也不要完全无视维护状态。判断一个 Skill 是否值得用，看它的最近 commit 时间比看 star 更可靠。一个一年没更新的项目，大概率已经和当前工具版本脱节了。

第二，尽量选择“输出格式标准化”的项目。如果某个 Skill 的输出格式可以稳定嵌入到你的现有流程里，哪怕描述写得不完美，你也能通过修改 SKILL.md 把它改成顺手的样子。反之，如果它的输出依赖特定平台的习惯，改起来会很痛苦。

第三，自己动手维护一份“常用 Skill 清单”。开源社区的东西更新快、变动大，今天好用不代表明天还兼容。定期检查已装 Skill 的运行状态，把不常用的移除，把运行不稳定的修复或替换。这个习惯会让你的工作流始终保持干净高效。

按我个人的经验，与其花大量时间逛热榜，不如花一个下午把冷门项目翻一遍，挑出三五个顺手的好好调熟。这套生态真正的红利期还在早期，趁现在工具少、竞争不多，早点把属于自己的工作流跑通，比什么都划算。