企业官网建设流程全解析

1. 先聊清楚一件事：Claude Code 里的 Skill 到底是怎么工作的

我大概花了三周时间，把 GitHub 上能翻到的 Claude Code 相关 Skill 仓库翻了一遍。从结果来看，标题里的“180 个开源 Skill”不是夸张说法，我本地 clone 下来做分类的就有 183 个，其中有 107 个项目的 star 数不到 50。这本身是个很有意思的现象，后面我会专门讲。

但开始盘点之前，得先把一个概念掰清楚：Claude Code 的 Skill 到底是什么。因为我发现很多人把它和插件、MCP 服务、Prompt 模板混为一谈，这样后面看什么都乱。

Skill 本质上是一个非常朴素的目录结构。一个 Skill 就是一个文件夹，里面通常包含一份SKILL.md文件作为能力说明书，再加上若干脚本、参考文档和模板。这个目录被放到 Claude Code 的 skills 目录里之后，模型会在会话中根据用户需求去匹配对应的 Skill，调出它的说明文档，然后按文档里的步骤调用本机脚本、解析文件、生成结果。

它和插件不一样。插件通常要挂到一个运行时框架上，有自己的生命周期和事件钩子；Skill 更像是“给模型看的一份带操作手册的脚本包”，模型负责读手册、做决策、调工具，脚本负责干那些模型不擅长的精确计算，比如解析 SRT 时间轴、调用 ffmpeg 批量转码、读取视频元数据。

它也比 MCP 轻得多。MCP 是走协议、起服务、暴露工具接口的一套完整链路，适合需要长期运行、多端复用的场景；而 Skill 就是本地文件，不需要部署服务端，clone 下来放进目录就能用。打个不恰当的比方，MCP 像是装修公司给你装好的厨房，Skill 更像是路边摊师傅揣在兜里的一套刀具——看着不起眼，但真正动手干活全靠它。

理解了这层关系，后面所有关于“哪个 Skill 好用、怎么装、为什么会有 180 个这么多”的讨论才有地基。

2. 180 个开源 Skill 的整体盘面：我按什么逻辑分成了九类

先说结论：这 180 多个项目，真正值得下载下来试的，我筛完大概只剩 60 个左右。剩下的大部分是重复造轮子、文档没写完、依赖太重，或者干脆就是把一段提示词裹了一层文件夹就发上来的水项目。

但水项目多不代表生态差。恰恰相反，正因为门槛足够低，这个生态里出现了很多非常垂直、非常刁钻的解决思路，这是那些成熟插件体系里永远见不到的。为了把 183 个项目理出头绪，我按“场景”而不是按“技术栈”做了分类，因为 Skill 这种形态，用户关心的是它能帮我完成什么任务，而不是它用了什么语言写的。

分类情况大概是这样的：

视频与多媒体占了 19 个，不算最多，但它是“Claude Code 能做视频”这件事的核心支撑，实际串联起来覆盖的链路非常完整，我下面单独拆。

说回筛选逻辑。我淘汰一个 Skill 的原因，排在前三位的分别是：

第一，SKILL.md写得模棱两可。有的项目只有一百多字的 description，没有明确的触发条件、没有输出来例、没有边界说明。这种 Skill 装进去以后，模型经常在用户提无关问题时也把它调出来，对话上下文被无意义内容占掉一大截。

第二，重度依赖外部服务。有些 Skill 表面上做视频处理，实际要调用付费的 API 或在线服务，本地脚本只是薄薄一层封装。不是说不能用，但把它当“本地技能包”就不太诚实了，上传到公开仓库多少有点引流的意思。

第三，没有 examples 目录。一个 Skill 如果作者自己都没跑通过，起码在仓库里放两个输入输出的例子，否则我根本无法判断它文档里写的命令是真是假。

我不是说 star 数不重要，而是要把 star 数放到正确的位置。对 Skill 这种形态的项目来说，star 数只能证明“有多少人收藏了它”，不能证明“它跑起来好用”。真正让一个 Skill 有价值的，是它的 description 是否写清楚了触发边界，它的脚本是否自带容错，以及它是否覆盖了官方内置能力之外的空白点。这方面，那些不到 50 星的小项目里反而藏了不少好东西。

3. 做视频这条主线：从脚本分镜到成片交付，Skill 到底覆盖了哪几环

“让 Claude Code 学会做视频”听起来像句玩笑话，毕竟 Claude Code 平时是蹲在终端里写代码的，跟视频制作八竿子打不着。但把 19 个视频相关的 Skill 排开以后，我发现这条链路竟然是完整的。

我按视频制作的真实流程把它们摆到了六个环节上：

选题与脚本。这个环节的 Skill 主要做两件事：一是根据一个短语扩展成完整的视频脚本，包括开场钩子、段落节奏、结尾引导；二是把长文章改写成口播稿。说实话这类 Skill 良莠不齐，很多就是拿提示词套了个壳，做得好的会内置“用表格输出每一段的时长预估”这类结构化要求，让模型输出的东西可以直接进分镜环节。

分镜与镜头语言。这里开始有含金量了。有个 Skill 的输入是一段脚本文本，输出是一个 Markdown 表格，每一行包含镜号、画面描述、景别、运镜方式、建议时长、对应台词。它工作的核心是一份内置的“镜头语言参考表”，模型会按照参考表里的景别和运镜术语去拆解脚本。这个思路很聪明，等于给了模型一套固定的表达词汇表，而不是让它自由发挥。

素材准备。这类 Skill 解决的问题很现实：视频剪到一半发现缺背景素材。有的 Skill 会扫描本地素材库，按关键词匹配可用片段并输出清单；有的会生成 AI 绘画工具的提示词清单，专门给空镜头补画面。它们都不直接产素材，而是帮你把“缺什么、去哪找、提示词怎么写”理清楚。

字幕处理。这是视频类 Skill 里数量最多的一组，大概占三分之一。最基础的负责把音频转成带时间轴的 SRT 文件；进阶一点的能做字幕翻译、双语对照、根据视频帧率重新对齐时间轴；还有专门做“字幕压进画面”的，直接封装了一条 ffmpeg 命令。我试过其中一个字幕重对齐的脚本，它处理的是那种“演讲稿和录音不同步”的场景，实现方式是检测音频中的静音段位置，再把字幕时间轴整体映射过去，思路相当漂亮。

剪辑与合成。这个环节的 Skill 大多是 ffmpeg 的封装。有做横版转竖版的，自动检测画面主体区域然后裁剪；有做批量拼接的，把目录下所有片段统一转成相同编码、相同分辨率和帧率，再用 concat 协议合并；还有做关键帧抽取的，输入一个长视频，输出若干张关键帧图片，方便快速浏览内容。它们解决的问题极其单一，但每个都足够痛：很多人第一次写 ffmpeg 命令都是查了半天文档还报错，这类 Skill 把正确命令缓存成了静态规则。

成片交付。最后这一环对应的是各平台适配：按不同平台比例批量导出封面、生成视频标题和标签建议、把长视频拆成一个短视频系列并给每个片段配标题。

这套链路走完，我的真实感受是：你不能指望 Claude Code 一键生成一条完整视频，但你可以把它当成一个“超级监理”，它会读脚本、拆镜头、生成字幕命令、调好 ffmpeg 参数，并在每一步给你一个可执行的结果。它把过去需要两三个人配合的流程，压缩成了一条人机协作的生产线。

举一个我实际跑通的例子：我拿一篇三千多字的文章当输入，先让脚本改写 Skill 生成口播稿，再由分镜 Skill 拆成 14 个镜头建议，字幕 Skill 产出一份 SRT 文件，合成 Skill 里挑了一条字幕压制命令跑完 render。整个过程我只手工介入了一次，就是剪掉第二个镜头里拖沓的那五秒废话。对，视频是人配的，Claude Code 和它的 Skill 不是替代你剪片的人，而是把你的每一步操作都加快了。

4. 107 个不到 50 星的冷门项目，为什么反而值得先动手

标题里提到的那 107 个低星项目，可能是这篇文章里最值得展开讲的部分。我的观点是：对 Skill 这种形态的开源项目来说，低星不等于低质量，反而有一类宝藏只会在低星区出现。

先说低星 Skill 的好处。高 star 的 Skill 往往有一个通病：为了照顾大多数人的使用场景，不得不把能力做得通用。通用能力必然带来复杂的输入参数、冗长的配置说明和一堆用不上的开关，最后你为了跑通一个简单需求，得先读完一份两万字的 README。而低星项目恰恰相反，很多是作者为了解决自己在实际项目中碰到的一个具体问题写的，场景极其垂直，三四句话就能说清怎么用。

举几个我印象深刻的例子。有一个不到 30 星的 Skill，专门解决“从 B 站视频页面提取标题、简介和章节信息”的问题，输入一个分享链接，输出结构化的 Markdown 表格。另一个项目做的是本地视频文件名整理，识别“某剧第X集”这类命名模式，统一改写成规范格式，顺带把对应的字幕文件同步改名。还有一个方向很刁钻的项目，专门处理“访谈类视频的字幕说话人标注”，通过内置的规则去猜测当前台词是受访者还是主持人说的。

它们的共同点是：都踩在了大项目不愿做的细缝里。大项目追求普适性，不会为单个视频网站做专属解析；大项目追求稳定性，不会去碰“猜测说话人”这种容易翻车的模糊活；大项目追求可持续维护，不会把自己的工具绑在某个平台的页面结构上。可这些事情恰恰是真实工作流里最磨人的部分，我自己下载第三方解析工具得到的结果又经常广告满天飞。所以这些小而偏的 Skill，成了最优解。

怎么从低星区里挑到好东西？我的判断标准有五条，按重要程度排列：

1. 目录结构干净。至少要有SKILL.md、scripts和references中的两样，如果只有一个孤零零的 Markdown，基本就是提示词套壳。
2. 有 examples。作者贴过真实输入输出，说明他至少跑通过一次。
3. description 里写了触发条件和边界。比如“只处理 SRT 格式，不处理 ASS”，这种话看着扫兴，但能避免模型误调用。
4. 最近一次 commit 不算太老。超过一年的要谨慎看依赖。
5. 依赖数量少，最好是纯 Python 标准库或单条 ffmpeg 命令就能跑。

这些条件筛下来，107 个里我实际敢装的也就二十来个。但就是这二十来个，帮我把很多重复劳动消掉了——与其骂这些小项目不成熟，不如把它当作代码片段来用，反正 Skill 本身就是一包脚本，不满意自己改两行就成自己的了。

还有一点，这些冷门项目的维护者往往特别好说话。我试过给一个中文视频字幕对齐的 Skill 提了一个 issue，当天就收到了回复，作者还顺手改进了一版兼容性。这种互动体验在高星项目里几乎不可能遇到。

5. 从 GitHub 到本机：安装、配置与组合 Skill 的完整步骤

盘点归盘点，真正上手才能体会到 Skill 这套机制的妙处。安装一个 Skill 的流程比我预想中简单太多，全程不需要编译、不需要下载依赖、不需要起服务。

先说目录。Claude Code 读取 Skill 的默认路径是用户目录下的~/.claude/skills，每个 Skill 一个子目录。装的过程就是 clone 或下载压缩包，解压以后把整个文件夹放进去。以我本机为例，一个典型的 Skill 目录结构长这样：

~/.claude/skills/ ├── video-script-split/ │ ├── SKILL.md │ ├── scripts/ │ │ └── split_script.py │ └── references/ │ └── shot_glossary.md ├── srt-align/ │ ├── SKILL.md │ ├── scripts/ │ │ └── align_srt.py │ └── examples/ │ ├── input.srt │ └── output.srt └── ffmpeg-merge/ ├── SKILL.md └── scripts/ └── merge_clips.sh

放进目录只是第一步。关键在于SKILL.md文件头部的 frontmatter，也就是用---包起来的那几行。我见过不同项目写法略有差异，但核心字段就三个：

--- name: video-script-split description: 仅当用户需要将视频脚本拆分为分镜表格时使用。根据脚本内容输出包含镜号、景别、运镜、时长的 Markdown 表格。 ---

name是能力包的名字，description是模型判断“什么时候该用这个 Skill”的依据。这段描述写得清不清楚，直接决定模型会不会乱调用。写得宽泛，比如“处理视频相关的所有任务”，那模型碰到任何带“视频”两个字的话题都会先把这个 Skill 拉出来，白白浪费上下文空间。这点后面还会细说。

装完以后，建议先跑一遍项目自带的 examples。很多 Skill 的 examples 里就是一份现成的输入文件，放到对应目录里跑一次，确认输出是否正常。我的习惯是每次装完新 Skill，先在一个专门的测试目录里试，不会直接放到工作目录里跑，避免脚本误操作覆盖掉真实文件。

组合使用才是真正提升效率的地方。Skill 之间是可以串成流水线的。我最近处理一条长视频时，实际跑的顺序是：

# 第一步：从文章生成口播脚本，输出到 script.md claude "用 video-script-split 处理 script.md，输出分镜表" # 第二步：根据分镜表逐条生成画面描述，存为 shot_list.md claude "读取 shot_list.md，用 video-prompt-gen 为每个镜头生成绘画提示词" # 第三步：为配音音频生成字幕文件 claude "用 srt-generator 处理 audio.mp3，输出 subtitles.srt" # 第四步：按分镜表拼接所有片段并压入字幕 claude "用 ffmpeg-merge 合并 ./clips/*.mp4，字幕文件用 subtitles.srt"

你能看到，这里面模型干的是“调度”的活，每个 Skill 干的是“执行”的活。串起来以后，我不需要记住每个脚本的参数用法，只要在会话里用自然语言说明要哪一步就行。这在以前是不可想象的。

最后提醒一句：凡是带scripts目录的 Skill，装完以后记得检查一下脚本权限。我从 GitHub 上 clone 下来的项目，经常遇到.sh文件没有执行权限的情况，跑的时候会报 Permission denied。解决方式很简单：

chmod +x ~/.claude/skills/*/scripts/*.sh

这也是我吃了两次亏才记住的。

6. 试跑一圈之后，真正要警惕的是版本、上下文与执行权限

用 Skill 做视频这件事，流程跑通以后确实爽，但踩坑的密度也不低。我集中试跑那 20 多个低星项目的时候，几乎每天都要对付一类新问题。挑三个最典型的说。

第一，上下文窗口被悄悄吃掉。刚才提到SKILL.md里的 description 是模型判断触发条件的依据。问题出在：不少 Skill 的作者为了“提高曝光”，在 description 里塞了大量模糊触发词。结果就是用户随便说一句跟视频沾边的话、甚至只是提到“剪辑”两个字，模型就会把对应 Skill 的完整文档加载进来。一次两次无所谓，装到十几个 Skill 以后，一个会话里经常有两三个 Skill 的文档被同时加载，占掉几千 token。解决思路是装完 Skill 以后自己动手改 description，删掉那些模棱两可的触发词，只留最精确的场景。

第二，版本适配比想象中频繁。Skill 的加载机制在不同版本的 Claude Code 里有过调整，有些老项目的SKILL.md用的 frontmatter 字段名已经不完全兼容。我遇到过一次：一个写得很好的字幕对齐 Skill，在新版本下模型始终不认识它，反复提示“未找到该能力”，检查半天发现是 frontmatter 里少了一个必填字段。这种问题没有快速解决办法，只能逐个检查SKILL.md的头部声明，缺什么补什么。从那以后我养成了一个习惯，clone 完任何 Skill 先打开SKILL.md把头部读完，再决定装不装。

第三，执行权限和外部依赖的暗坑。除了前面说的chmod +x，更隐蔽的问题是脚本里硬编码的外部工具路径。比如有个转码 Skill 用的是ffmpeg，但它默认读取的系统路径和我机器上实际安装的版本不一致，导致跑起来静默失败，什么都不输出。排查了半天，最后发现是ffmpeg的版本把某个参数从-vcodec改成了-c:v。这种问题定位起来最耗时间，因为脚本本身没报错，只是行为和预期不符。我的经验是：装任何处理音视频的 Skill 之前，先在终端里跑一遍ffmpeg -version，确认版本和 Skill 文档里假设的一致。不一致的话，要么换 Skill，要么自己改脚本里的命令。

踩了这些坑以后，我的用法变得保守了很多。现在我的原则是：同时只保留五六个常用的 Skill 在默认目录里，其他不常用的单独放在一个备份目录，要用的时候再软链过去。宁可每次配置多花两分钟，也不想让十几个 Skill 在会话里抢上下文。这也是我翻了 180 个项目以后最想分享的一条实操经验——Skill 的价值不在装了多少，而在每个被用到的时候，它都能稳定地出活儿。