如果你现在还觉得 Claude Code 只是个能写代码的终端助手那你大概率错过它最值钱的一层——Skill技能。我花了两周时间把开源社区里冒出来的 Skill 仓库几乎翻了个底朝天最后筛出 180 个值得看的项目按用途分成八大类其中 107 个星标还不到 50。最让我意外的是真正能让 Claude Code“学会做视频”的能力恰恰藏在这批冷门仓库里而不是那些大几千星的网红合集。这篇文章不打算罗列一堆链接我想讲的是完整的盘点思路180 这个数字是怎么筛出来的、八大类各自的水位如何、视频类 Skill 内部到底长什么样、以及我在实测冷门仓库时总结出的判断方法。适合两类人看一是刚接触 Skill 想搭一套自己工作流的新手二是已经装了一堆 Skill、但总觉得“能力配不上热度”的进阶用户。1. Skill 到底是什么Claude Code 从“会聊”到“会干活”的那层皮1.1 一个 Skill 就是一个岗位说明书很多人把 Skill 理解成“插件”这个类比其实不太准。插件通常是打包好的功能模块装完就有新按钮而 Skill 更像是一份给 Claude 看的岗位说明书——它不直接提供功能而是告诉 Claude在什么场景下、按什么步骤、调用哪些现成脚本去完成一类具体任务。一个标准的 Skill 就是目录里的一个文件夹里面最核心的文件叫 SKILL.md。开头有一段 YAML 元信息写着技能的名字、描述、允许调用的工具范围正文则是步骤化的操作手册。整个目录长这样.claude/skills/ └── vertical-video/ ├── SKILL.md ├── scripts/ │ ├── tts_wrapper.py │ ├── make_clip.sh │ └── burn_subtitle.py └── templates/ └── storyboard.mdSKILL.md 里的描述字段是灵魂。Claude Code 每次接到任务会先把当前可用的 Skill 描述扫一遍判断哪个跟当前请求相关再把对应的完整手册塞进上下文里执行。所以描述写得越具体、越像“触发词表”技能被正确调用的概率就越高。这个机制决定了Skill 的能力上限不在代码而在说明书的质量。1.2 视频任务为什么尤其适合用 Skill 解决视频处理是我见过的、跟 Skill 机制契合度最高的领域之一。原因很直接视频的底层操作大多是确定性的、重复的——转码、裁剪、拼接、加字幕、调画幅每一步都有明确参数。这些工作让 Claude 从头“想”着做容易出错但把操作封装成脚本再由 Claude 负责拆解需求、排好顺序、调用脚本就变成了它最擅长的“规划 执行”。更关键的是视频任务天然分阶段。口播稿转成成片中间隔着配音、分镜、字幕、合成好几个环节每个环节都可以独立成一个 Skill 或脚本。Claude 不需要一口气“无中生有”造出一个视频它只需要沿着流水线指挥一个个确定性环节跑完。这种“规划靠模型、执行靠脚本”的搭配容错率比纯靠模型直接生成高出太多。1.3 热门 Skill 解决不了的问题我把市面上那些高星标的 Skill 合集大致翻过一遍发现一个共同点它们几乎都在解决文档处理、代码审查、网页搜索这类“通用办公”问题。覆盖面广但每个技能的深度有限。而视频这种垂直场景恰恰是最需要“深度”而非“广度”的地方。比如一个大几千星的合集仓库里面的视频相关可能只有一两个示例还停留在“调用命令行工具转个格式”的水平。真正能处理“口播稿分镜、字幕时间轴对齐、竖屏画幅适配、批量成片”这些完整流程的技能散落在各种小仓库里作者往往只服务自己的需求没有精力做推广星标自然上不去。这就是我做这次盘点的出发点不看热度只看是否真的能干活。2. 我的盘点方法180 个 Skill 是怎么从托管平台捞出来的2.1 搜索词、去重与筛选条件要复现这次盘点渠道其实就那么几个。我先在主流代码托管平台搜了“claude skill”“claude-code-skills”“agent skills”“SKILL.md”这些关键词按最近更新时间排序然后顺着一些小而精的合集仓库的引用一路“滚雪球”找到更多相关项目。这里有个容易踩的坑很多“合集仓库”只是把别人的 Skill 文档复制过来陈列本身没有维护价值需要单独排除。去重之后我按三个硬条件筛了一遍目录里必须包含 SKILL.md且带完整的 YAML 元信息正文必须有可执行的步骤或脚本而不是纯 Prompt 收集最近一年内有提交记录彻底停更的直接剔除。三条全过的最终留下来 180 个。这个数字不是拍脑袋而是把“能当岗位说明书用”作为底线之后自然收敛的结果。2.2 八大分类的划分口径与数量分布分类我尽量按“产出物”而不是“实现方式”来分。比如同样用命令行工具产出是视频就归媒体类产出是数据报表就归数据类。最终分布如下分类数量50 星以上50 星以下冷门占比视频与媒体处理2271568%文档与知识管理31151652%代码与工程效率35181749%数据抓取与信息整理2681869%设计与创意生成1431179%办公与生活自动化1861267%本地工具链与离线模型1751271%复合工作流与合集1711635%合计1807310759%整体上 107 个冷门占将近六成。最“卷”的是设计和创意生成79% 的 Skill 都不足 50 星说明这个方向大家都在各自为战还没有形成公认的头部方案。2.3 50 星这条线区分“被验证过”与“刚上架”50 星不是一个科学阈值但它背后有个现实逻辑一个仓库能被 50 个人手动点星至少说明它被真实使用过、且没让人立刻失望。低于这个数不代表差只代表“未被广泛验证”。我盘点时把 50 星当作观测水位线而不是筛选线。筛选用的是前面说的三个硬条件水位线只是用来观察到底哪些分类的优质能力最容易被埋没。结果一目了然——视频类和数据抓取类的冷门占比都接近七成说明这两个方向是典型的“高手在民间”。3. 视频类 Skill 的核心拆解Claude Code 是怎么“学会做视频”的3.1 从脚本到成片的四段式流水线把 22 个视频类 Skill 摊开看无论包装多不同底层都在服务同一条四段流水线阶段要解决的问题Skill 通常做的事脚本与分镜把口播稿切成可拍摄的段落按句读或时长拆分生成分镜表素材与画面找画面、生成画面、处理背景检索本地素材库生成色卡或占位图配音与字幕把文字变成语音、对齐字幕调用 TTS 服务生成带时间戳的字幕文件合成与导出拼装所有元素设置画幅、编码参数输出成片一个好用的视频 Skill通常只深耕其中一到两段而不是全包。全包的技能听起来厉害实际用起来往往每段都差口气。3.2 一个短视频 Skill 长什么样我抄一段经过反复打磨后的 SKILL.md 结构你可以直接参考--- name: vertical-video-clip description: 把口播稿制作成带字幕的竖屏短视频。当用户提到口播、短视频、竖屏、字幕、稿件转视频时使用。不适用于横屏长视频。 allowed-tools: Bash, Read, Write --- # 竖屏短视频 ## 输入要求 - 口播稿Markdown 或纯文本按段落区分镜头 - 背景素材可选缺省时使用默认色卡 ## 执行步骤 1. 按每 15-20 秒一个镜头拆分口播稿 2. 调用 tts_wrapper.py 生成配音输出每句时间戳 3. 使用命令行视频工具按时间戳合成背景、字幕、配音 4. 输出 1080x1920、H.264、30fps 的 mp4 5. 将成品放入 output/ 目录并命名 yyyymmdd-序号 ## 边界情况 - 脚本少于 30 秒直接单镜头处理 - 口播稿带表情符号先剥离再进 TTS - 输出目录已存在同名文件追加 -v2 后缀不允许覆盖注意看正文里写得最详细的是“边界情况”。Claude 的真正价值不是按部就班跑一遍成功路径而是遇到异常时能不能自己绕过去。边界情况写得越全它绕过去的速度越快。3.3 一次真实调用的完整链路实际调用比很多人想象的无聊但也正是这份无聊保证了稳定。用户说“把这个口播稿做成竖屏视频”Claude Code 内部发生的其实是扫描本目录可用的 Skill 描述匹配到 vertical-video-clip把 SKILL.md 全文读入上下文按步骤先跑 tts_wrapper.py拿到配音文件和每句时间戳再用命令行视频工具把背景、字幕、配音按时间戳合成如果某条命令报错Claude 读 stderr对照“边界情况”里的预案重试最终在 output/ 目录留下成品。整个过程里模型唯一需要“创作”的地方是第一步的意图匹配和第五步的排错决策其余全是脚本在干活。这就是为什么我敢说“让 Claude Code 学会做视频”这件事是真实可行的——它不是靠模型凭空生成画面而是靠一套可重复、可校验的执行链。4. 107 个冷门宝藏的真实成色不到 50 星不等于不能用4.1 冷门的原因往往不在质量我把 107 个冷门仓库逐个看下来发现它们冷的原因高度集中跟质量关系不大作者是“为自己写工具”的个人开发者不做英文宣传README 只有母语用的人少反馈迭代慢看起来像死项目解决的问题太垂直比如“字幕样式转换”“静音片段自动裁剪”一听就知道受众窄。但恰恰是这种“为自己写”的仓库最舍得在细节上较劲。大而全的项目要照顾所有人反而会在边缘场景上偷懒。4.2 我实测下来最惊艳的几个方向我专门挑了一批冷门仓库做了实测有几个方向至今还在用第一个是本地 TTS 封装类 Skill。它只做一件事调用本地的开源语音合成模型输出带词级时间戳的配音。词级时间戳是生成字幕的黄金输入有了它字幕对齐不需要再靠猜测。这个 Skill 不足 50 星但稳定跑了 200 多次没出过岔子。第二个是字幕样式转换。默认生成的 SRT 字幕丑是通病这个 Skill 能把字幕批量转成带模板样式的 ASS 格式支持描边、阴影、字体大小批量调整。对做口播视频的人来说这一步直接决定成品观感。第三个是长视频切片索引。给它一段几小时的原始素材它会先抽完整转录文本再按话题切出时间戳段输出一份“哪个时间点在讲什么”的索引。这相当于把一个素材库变成了可检索的视频库做混剪时极省时间。第四个是静音自动裁剪。成片导出前扫一遍音轨把超过阈值的沉默片段自动截掉。听起来不起眼但对访谈类和口播类内容它能直接把完播率拉高一个档次。4.3 冷门 Skill 的隐患清单值得夸也要泼冷水。冷门仓库的实际风险我在实测里基本都撞过一轮隐患症状应对依赖没写全脚本跑一半报缺包先看 README 的安装命令缺啥补啥再跑硬编码绝对路径换个机器立刻挂到手先全局搜一遍绝对路径改成相对路径中文编码处理不当字幕乱码检查脚本是否指定 UTF-8否则手动加命令行工具版本不符参数失效对照当前工具版本手动改 flag这些隐患都不致命但要求使用者有基本的代码阅读能力。这也是为什么我把冷门仓库当作“需要自己接手维护的开源资产”而不是“开箱即用的免费午餐”。5. 安装与调优实战三种存放位置怎么选5.1 项目级、用户级、插件级怎么分Skill 可以放在三个层级很多人一开始搞不清结果装完了在当前项目里看不到、在另一个项目里又莫名冒出来。项目级放在.claude/skills/跟着仓库走适合固定工作流比如这个项目就是做短视频的就放视频 Skill。用户级放在用户目录下的.claude/skills/对所有项目生效适合放那些你希望任何时候都能调用的通用能力比如文档转 PDF、批量重命名。插件级则是通过插件市场安装的插件自带的 Skill适合团队统一分发好处是版本和配置一起管坏处是依赖插件本体保持更新。我的建议是从项目级开始跑熟了再升到用户级或插件级。“就近原则”能少踩很多脏环境的坑。5.2 description 写不好Skill 等于白装实战里最常见的翻车原因不是脚本有问题而是描述写得让模型“看不见”。一个写“处理视频”的描述跟没写一样一个写“把口播稿按 15-20 秒拆成镜头并生成竖屏成片涉及 TTS、字幕、合成”的描述才值得被模型选中。描述里还要写清“什么时候不要用”这一点很多人忽略。比如在开头的例子里我特意写了“不适用于横屏长视频”就是为了防止模型在错误场景下强行套用。技能装好后拿几句真实任务去试看它命中不命中不命中就先改描述这比改代码重要得多。5.3 用 allowed-tools 和参数模板提高命中率SKILL.md 里的 allowed-tools 字段是安全绳。视频 Skill 基本只需要 Bash、Read、Write 三个权限就不该给它联网搜索的权限免得到处扒素材。权限收窄还有个好处模型的行为空间更小出错路径更少。参数模板则是另一种提效手段。很多冷门脚本的参数脆得很模型如果靠“猜”来拼命令行十次能错三次。解决办法是把常用命令的完整模板写进 SKILL.md例如“合成命令固定为make_clip.sh --bg color --sub style --fps 30”模型只需要套模板不用理解每个 flag 的含义。实测下来加了参数模板之后视频类任务的首次成功率能提升一大截。6. 把一套视频 Skill 组合起来从单点功能到完整生产链路6.1 我搭的一套“口播短视频”流水线盘点归盘点真正让我觉得这套玩法成立的是组合使用。我现在每周固定产出一批口播短视频流程是这样的先写一批口播稿每篇 300-500 字按段落切好Claude Code 调用分镜 Skill把每篇稿子拆成镜头表按镜头表批量调 TTS生成配音和词级时间戳素材整理 Skill 从本地素材库按关键词挑背景画面合成 Skill 依次产出成片最后统一跑一遍静音裁剪和字幕样式转换。整个过程我只需要做两件事写稿子、检查成品。中间的分镜、配音、合成、剪辑、字幕全部由 Skill 组合完成。6.2 失败三次之后才确定的调用顺序这套流水线不是一次跑通的我踩过三个大坑。第一版我先把字幕生成了再去做 TTS结果字幕时间轴和配音完全对不上只能返工。第二次我图省事让 Claude 自己给成品文件命名结果跑批时两个任务互相覆盖丢了一整批素材。第三次最大的教训是贪多一次把十篇稿子丢进同一个会话上下文被几个 SKILL.md 反复占用中途就开始“忘事”。最终确定下来的铁律有三条先出音频再定字幕、文件名一律由脚本按规则生成、单次批量不超过三篇稿子。这三条看着简单每一条都是真金白银换来的。6.3 成本与节奏一次批量生成的经验Skill 不是免费的。每次调用SKILL.md 全文都会占用上下文空间脚本越多、说明越啰嗦token 烧得越快。我把 SKILL.md 控制在 200 行以内把大量细节下沉到脚本里让模型只读“决策规则”而不是“实现细节”成本明显降下来。节奏上我倾向于把“规划”和“执行”分开先让 Claude 在不加载任何 Skill 的情况下把三篇稿子的分镜方案列出来确认无误后再逐个加载技能执行。这样既省 token又能避免模型在方案阶段被某个 Skill 的描述“带偏”。7. 判断一个冷门 Skill 值不值得用的四个信号7.1 说明书密度是第一指标拿到一个冷门 Skill我第一件事不是跑代码而是打开 SKILL.md 数“边界情况”。一个文档里写了十几条异常处理的技能哪怕只有 20 星也比一个满嘴漂亮话但只有三段万能步骤的千星项目靠谱得多。说明书密度直接反映作者被真实需求毒打过多少回。7.2 依赖体积决定它会不会拖垮工作流视频类 Skill 最容易踩的坑是依赖体积。有的技能一看 README要下一个十几个 G 的模型权重才能跑“一句话转视频”这种我直接放弃。真正可用的冷门宝藏依赖通常克制一个 Python 脚本、一个命令行视频工具、顶多一个轻量 TTS 模型。记住Skill 的价值在于“把确定性操作封装起来”而不是“把整套环境搬过来”。7.3 看维护信号别只看星标星标是结果不是原因。我评估维护状态看三样东西最近一次提交的时间、最近三个月的 issue 有没有人回复、以及作者有没有针对命令行工具版本更新做过兼容调整。一个 200 星但两年没动的仓库实用性往往不如一个 30 星但上周还在更新的仓库。这次盘点的 107 个冷门里有一批正是“低星高活跃”的典型。7.4 最后一步自己给它补一个测试用例决定用之前我会造一个最小输入跑一遍比如用一段 50 字的口播稿走通整条链路。跑通之后再补一个“失败用例”——故意给一个不完整输入看 Skill 有没有预案。我评估一个新 Skill 现在只需要十分钟核心动作就是把 SKILL.md 当代码 Review、把星标当噪音、并把每次实测结果回写进文档。这套习惯帮我筛掉了大量“看起来能干活、实际一跑就碎”的仓库也让我真正把 Claude Code 从“聊天工具”用成了“内容生产流水线”。