最近这个圈子有个很有意思的现象很多人对 Claude Code 的印象还停留在“用它写代码、改 bug、跑测试”但真正把它用到极致的人早就不满足于这一亩三分地了。我这次专门花了两天时间把 GitHub 上开源的 Claude Code Skill 生态翻了一遍差不多 180 个能用的项目分类整理完之后有个特别直观的感受这个工具的能力边界完全是被 Skill 体系撑开的。更有意思的是这 180 个项目里我数了下超过一半大概 107 个Star 数都不到 50但很多低星项目解决的可都是特别具体、特别能落地的痛点。这篇文章我就拿其中一个最惊艳的场景来聊——怎么让 Claude Code 学会做视频。不是那种“我给你写个脚本你自己去剪”的空话而是真的让它去拆脚本、排分镜、拼素材、生成字幕、渲染成片整个过程里到底需要哪些 Skill 配合哪些冷门项目值得你花时间去挖以及在实操中会遇到哪些坑、怎么排。不管你是刚把 Claude Code 装好、想知道它还能干嘛的新手还是已经玩了一阵子 Agent、想给自己的工作流再加一条视频生产线的老手这篇文章应该都能给你一些参考。1. Skill 机制拆解Claude Code 的能力边界是怎么被撑开的1.1 Skill 到底是什么给模型一本“操作手册”很多人的第一反应是Skill 是不是就是插件严格来说不完全对。Skill 本质上是一套结构化的“操作手册”告诉模型在特定场景下应该怎么思考、按什么步骤执行、调用哪些工具、输出什么格式。我在实测中理解到的机制是这样的每个 Skill 通常是一个文件夹里面放一个核心的 SKILL.md 文件文件头部有 YAML 格式的元信息写着这个 Skill 的名字和适用场景描述。Claude Code 在启动时会把所有可用的 Skill 的“简介”加载出来构建成一个技能菜单。当你的任务描述命中某个 Skill 的适用场景时模型才会把那个 SKILL.md 里的完整指令加载进上下文。这个设计相当聪明它不会一上来就把几百个 Skill 的全部细节塞进上下文里而是像查目录一样按需加载。打个比方你的团队里有一堆老师傅Skill 就是每个老师傅手里的工作手册。你平时不用把手册全文背下来但接到对应活的时候翻到那一页照着做就行。所以 Skill 解决的本质问题是让模型在复杂任务里“知道该按什么套路走”而不是每次都靠大模型临场发挥。不过这里要注意一个关键点Skill 本身只是“知识”不是“工具”。它告诉模型可以用什么工具、按什么顺序调用但真正干活的是外部程序比如 ffmpeg、图像生成接口、语音合成服务。所以你拿到一个 Skill千万别以为它自带渲染能力它带的是一套编排指令。1.2 Skill 和 MCP、子代理各管哪一段聊 Skill 的时候一定会绕不开另一个词MCP。我经常在评论区看到有人把这两个概念搞混。我用一个朴素的方式来区分MCP 是给模型接“器官”的它让模型能操控外部工具和数据源比如连上数据库、调用文件系统、操作浏览器。它解决的是“能不能碰到”的问题。Skill 是给模型“装经验”的它让模型知道在某个场景下该怎么干活比如先做分镜还是先写台词、生成视频时参数按什么标准来。它解决的是“会不会干”的问题。子代理则是“分身”你可以派一个子代理去独立完成一个子任务它有自己的上下文窗口。Skill 可以被子代理引用两者可以配合使用。在实际的视频生产链路里我通常这样分工主 Claude 负责整体调度用视频脚本类 Skill 产出分镜方案子代理去执行独立的渲染任务MCP 负责把素材文件或者 API 接进来。三者各有各的位置缺一不可。1.3 180 个开源 Skill 的分类盘点逻辑我这次盘点的范围是 GitHub 上公开的、以 Claude Code Skill 形式组织的项目。所谓“能用的 180 个”我是按这几个标准筛的结构完整有 SKILL.md、描述清晰、有可复现的输入输出示例并且不是纯 README 文档或者只有 issue 没有代码的占位仓库。把这些项目按功能域划分下来八个大类基本能覆盖编码辅助类、文档与知识管理类、数据处理与自动化类、多媒体与视频类、设计与创意类、效率工具类、运维与部署类、Agent 工作流增强类。这 180 个不是均匀分布编码辅助依然是大头但视频相关的项目正在肉眼可见地变多。我说“让 Claude Code 学会做视频”是这次盘点里最有感觉的一个横切面是因为它不只是某一个 Skill 的事它是把脚本类、素材类、剪辑类、字幕类、封面类这几个不同分组的 Skill 串成一条流水线。这也是分类盘点最核心的价值它不是让你一个一个项目去逛而是帮你按“我要产出一个什么结果”来组队。2. 视频场景的完整技能栈从脚本到发布的五段链路如果只是让 Claude Code 写一段“你好欢迎观看本期视频”的文案那根本不需要 Skill。真正的“做视频”至少是五段链路选题与脚本、素材获取与预处理、剪辑与合成、字幕与音频、封面与发布。每一段都有对应的 Skill 场景我一个个拆开讲。2.1 选题与脚本阶段这个阶段其实是 Claude 最擅长的因为它是纯语言任务。但普通问答和带 Skill 的区别在哪带 Skill 之后模型会按照固定的结构来输出先做关键词分析再列内容大纲然后把大纲拆成可执行的口播逐字稿最后配上分镜表。这里有个我踩过的坑如果你直接说“帮我写个视频脚本”模型给出来的大概率是普通文章结构不是脚本结构。你需要的是一个包含明确输出格式的 Skill让它意识到自己是“视频编导”而不是“文案小编”。一个合格的分镜脚本 Skill 应该输出类似这样的结构序号、时间段、画面内容、景别、台词文本、字幕文本、转场方式。每一行都可以直接被后面的剪辑环节使用。没有这个结构后续的自动化全是空谈。2.2 素材获取与预处理阶段这个阶段有两个分支一个是处理你自己上传的原始素材另一个是让模型根据脚本去寻找可用的素材。后面这个分支相对敏感我不展开讲具体怎么拉流我要说的是本地素材的组织方式。实际做视频最痛苦的不是剪辑而是素材混乱。拍了一堆视频素材文件名全是“_DSC0001.mp4”鬼才知道哪段是第几个镜头。我见过一个冷门 Skill 的思路很有意思它会让 Claude 读取一段素材的首尾帧和关键画面信息自动生成一段带场景描述的索引文件再按内容重新组织目录结构。这套逻辑本质上是在给素材建立“档案”让后续的剪辑任务有据可查。剪辑工具方面最常被 Skill 调用的依然是 ffmpeg。它能裁剪、拼接、转码、变速、加字幕几乎无所不能但命令太复杂了普通人根本记不住那一大串参数。Skill 的价值就是把“我想把这两段拼一起中间加个淡入淡出”翻译成准确的 ffmpeg 命令。2.3 剪辑与合成阶段这个阶段是整个链路的核心。说实话Claude Code 并不会像剪映那样渲染画面它是通过生成指令来驱动外部工具完成渲染。所以视频剪辑类 Skill 的价值在于它能根据分镜表自动生成一整套剪辑脚本。我实测下来一个设计得好的剪辑 Skill 应该具备以下能力自动读取分镜表里每个镜头的时间长度和素材文件名把它们整理成一个 concat 列表文件为每个镜头生成对应的裁剪参数根据转场要求生成过滤图最后输出一条完整的 ffmpeg 命令。这里有个特别实用的细节用 concat 方式拼接视频时如果素材编码参数不一致拼接完会出现音画不同步。好的 Skill 会在生成命令前先提示你统一素材编码格式或者直接用转码参数规避这个问题。这种细节是纯靠提示词很难想到的因为模型没有实战痛感但把它写进 Skill 里的作者大概率是真剪过视频的。2.4 字幕、音频与封面字幕这块现在主流做法是把语音转成文字再烧录进画面。Skill 在这个环节通常做三件事把分镜脚本里的台词部分导出为字幕文件的通用格式调用语音识别接口生成带时间轴的文本把字幕文件嵌入到渲染命令里。我之前遇到一个很有意思的分工方式让主 Agent 生成字幕文本让子代理调用识别服务去做时间轴对齐。字幕是嘴炮时间轴才是体力活。拆出去之后主线程不会被长音频卡住整个流程顺畅很多。音频和封面更偏向调用外部服务Skill 在这里主要负责协议对接。它会帮你准备好提示词模板、参数格式以及最重要的错误重试逻辑。我从一个低星项目里学到的一个技巧是在 Skill 里明确写出“如果 API 返回超时不要重复发相同请求退避等待 10 秒再重试”就这么一句话让整个批量生成封面的成功率从六成提升到了九成以上。2.5 发布与数据复盘很多人做到渲染出片就觉得完事了但真正的内容工作流里发布和数据回收才是闭环。发布类 Skill 的作用是把视频的标题、简介、标签甚至首图自动生成成一套待发布的文案包。比较好用的 Skill 会去读取视频脚本里的核心关键词再根据发布平台的调性生成不同风格的标题版本。数据复盘类 Skill 我去翻的时候还比较少这算是一个小蓝海。受欢迎的账号往往会定期拉数据、看哪些选题跑得好再反哺到下一轮选题脚本里。如果你自己会写 Skill这个环节非常值得动手补上。我的看法是未来十二个月里面能打通“数据→选题→脚本→成片→数据”这个循环的 Skill 组合会是很稀缺的能力。我把这一段做成一张速查表方便你对照自己的场景视频生产环节需要 Skill 提供的能力对应产出物典型工具依赖选题与脚本关键词分析、大纲生成、逐字稿、分镜表结构化分镜文稿无素材预处理素材盘点、场景描述、目录归档素材索引文件文件读取、视频抽帧剪辑与合成拼接命令生成、转场处理、编码统一可执行渲染命令ffmpeg字幕与音频字幕文本导出、时间轴对齐、TTS 调用字幕文件、配音文件语音识别、TTS 服务封面与发布封面图生成、标题文案生成、标签整理发布文案包图像生成服务数据复盘播放数据读取、选题分析、下一期建议复盘报告数据接口2.6 视频 Skill 和传统剪辑工作流的区别最后补一句这套逻辑不是要把剪映这类工具取代掉它更适合流水线化的内容生产。你给团队做了一套 Skill 之后实习生只需要丢一个选题进来就能拿到一条粗剪成片和对应的发布文案。这种“把方法固化下来”的能力恰恰是 Skill 体系最迷人的地方。现在多花点时间把流程打磨好后面每一期视频都是躺赚的效率提升。3. 低星宝藏识别指南107 个不到 50 星的 Skill 为什么值得挖3.1 低星 Skill 是怎么被埋没的我在盘点的时候180 个项目里大部分107 个Star 数都不到 50比例相当高。一开始我也怀疑这么多低星是不是大多数都是垃圾翻完一圈之后我得说低星的原因非常复杂常常和实力无关。最典型的一种情况是发布渠道问题。很多项目作者先是发在个人博客、知识星球或者某个社群里GitHub 仓库只是“配套存放地”根本不宣传。那这仓库星数当然低但内容质量可能特别高尤其那种一看就是作者自己用了很久、把细节踩坑都写进文档里的项目。另一种情况是发布时间短。我翻的时候看到好几个仓库创建才一个月代码完整、说明清晰就是因为没有养起来星数停留在个位数。这种项目反而有优势它们往往适配的是当前最新版的 Claude Code 接口不会像一些老牌项目那样长时间没更新指令格式已经和现在对不上了。还有一种是被名字耽误的。有一个做得很好的字幕工作流 Skill仓库名起得非常抽象如果不点进去看 README根本猜不到它是干嘛的。而 Star 数和项目的“一眼可理解程度”强相关名字没法让人立即判断用途传播就会吃亏。3.2 我筛选冷门 Skill 的五个坐标所以后来我给自己定了一套评估标准也分享给你。不要因为星数低就跳过你就按下面这五个维度来判断第一看提交活跃度。一个项目星数低但最近三个月还有代码提交大概率作者还在用这是最强的“活”信号。第二看 SKILL.md 的结构完整性。一个合格的项目应该包含清晰的 YAML frontmatter、工作流程说明、输入参数的描述、输出格式的示例。如果一个项目只有几十个星但文档完整到这个程度那是金子在蒙尘。第三看依赖复杂度。优先选依赖少的。如果一个 Skill 需要配置五六个外部服务才能跑起来哪怕再牛你上手成本也太高了。真正好用的低星项目往往只依赖一两个常见工具开箱即用程度很高。第四看是否有 dry-run 模式。设计得好的 Skill 会提供一个“演练模式”让你在没有真实素材的情况下先看一遍它会输出什么命令。这个特性在低星项目里居然很常见反而很多几万星的大项目没有因为他们默认你有技术基础。第五看 issue 区作者的态度。项目可以没人关注但只要作者愿意回应问题哪怕只回应两三次都说明这个人会持续维护。一个“无人维护但有价值”的仓库你也依然可以用但要做好自己维护的准备。3.3 几类最有代表性的冷门宝藏在所有 107 个低星项目里有几类让我印象特别深刻展开聊聊希望能给你一些判断参考。第一类是“单点专精型”的 Skill。它只解决一个问题比如“批量给视频文件重新统一编码”。这种项目你让它去做别的事它不会但在视频工作流里是必不可少的一环。它的价值在于稳定行为可预测。我自己的经验是流水线里最重要的不是那些高谈阔论的全能型 Skill而是这些不起眼但不会出错的螺丝钉型工具。第二类是“本地优先型”的 Skill。它鼓励你用本地工具完成音频转写、图片处理等工作避免把内容上传到第三方服务。这类项目一方面解决数据隐私问题另一方面也减少对网络服务的依赖。如果你做视频涉及未发布的商业素材本地优先型 Skill 几乎是必需品。这类项目的代码通常也不复杂刚好适合你去看懂之后自己改一版。第三类是“工作流整合型”的 Skill。它本身不直接干活而是把若干个工具、若干个步骤串成一个流程。比如说“从脚本到粗剪”这一个 Skill它内部会先调用文本生成脚本再生成 ffmpeg 命令再调用字幕工具最后输出一条完整的处理方案。这种整合型 Skill 的标题往往平平无奇但点开之后会看到一张清晰的流程图这种项目我会重点收藏。第四类是“模板型”的 Skill。它提供了一套内容模板比如视频口播脚本模板、分镜表模板、封面配文模板。这类项目单看代码价值不大但它的文本里往往藏着作者对行业理解的经验。你把它拿过来改一改措辞就能形成自己的方法论。能提高生产力的是模板背后的思路不只是那段文字本身。当然也不是所有低星都值得挖。我拉黑过几种README 写得天花乱坠但核心逻辑只有一句“调用另一个库”用了大量私有模型能力但没有备选方案以及那种一个文件里塞了两千行、完全没法改的。不是所有低星都是宝藏擦亮眼睛才是关键。4. 实操让 Claude Code 接上视频 Skill 的完整流程理论说够了直接上能跑通的流程。我拿“从口播文案生成一份可以直接执行的分镜表”这个最典型的场景带你走一遍完整过程。4.1 规划 skills 目录与命名规范第一步不是写代码是规划目录。Claude Code 读 Skill 有两个层级用户级目录放在你的用户主目录下所有项目都能用和项目级目录放在当前项目的 .claude/skills 下只有当前项目能用。做视频这种通用能力我建议放用户级专门为某个账号定制的内容风格放项目级。目录命名有讲究必须全小写用连字符分隔不能带空格和特殊符号。比如 video-director、caption-flow 这种。每个 Skill 文件夹里必须有个 SKILL.md 作为入口没有这个文件Claude Code 就不认。目录名不用和技能名一致但最好能让人一眼看出来是干嘛的。我自己的目录布局是这样把“脚本生成”“素材处理”“剪辑指令”“字幕生成”“封面生产”这些都平铺在 skills 目录下。不要搞多层嵌套Claude Code 默认只扫描一层。4.2 自己写一个视频分镜 Skill第二步就是写核心的 SKILL.md 文件。这里给一个非常简化的、可以直接用的模板你复制以后按需修改。注意这个模板是用于说明整个结构的示意你完全可以根据自己的场景改成别的内容。--- name: video-director description: 根据一段口播文案生成带时间轴、画面描述、台词、字幕和转场方式的分镜表用于后续视频剪辑。当用户提到“分镜”“视频脚本”“口播视频”时触发。 --- # 视频分镜导演 你是一名视频编导。你的任务是把用户提供的口播文案改写成可供剪辑师直接使用的分镜表。 ## 输入格式 用户输入可以是纯文本文案也可以是一个包含“主题、时长、风格”的对象。 ## 执行步骤 1. 通读文案按语义切分段落每一段对应一个镜头。 2. 估算每个镜头的时长按每分钟 240 到 260 字的语速用台词字数反推时长。 3. 为每个镜头补充画面设计包括景别、画面内容和运动方式。 4. 为每个镜头标注字幕文本字幕需做适当断句单条不超过 8 个字。 5. 为相邻镜头设定转场方式。 ## 输出格式 用 Markdown 表格输出列包括序号、时间轴、画面内容、景别、台词、字幕、转场。 整张表输出完后附一段给剪辑工具的提示说明哪些镜头可以合并渲染。 ## 验收标准 - 每个镜头时间轴连续总时长误差在正负 5 秒以内。 - 台词无错别字和文案逻辑一致。 - 转场方式与画面内容匹配。这段模板的核心有两个地方需要拎出来讲一是输入格式写清楚了但给了容错可以是纯文本也可以是结构化对象这在实际使用里至关重要二是验收标准这一步它能让模型在输出完表格之后自查一遍明显提升结果稳定性。写完之后把整个文件夹放到 skills 目录里重启 Claude Code 或者新开一个会话才能被识别。然后再测试这句触发词“我现在有一段 90 秒的口播文案帮我把分镜表排出来。”如果命中 description 里的“分镜”关键词它就会按步骤执行。4.3 用现有 Skill 组合出一条视频生产流水线单个 Skill 能跑通之后下一步是把多个 Skill 串起来。我这里说的“串”不是让 Claude Code 自己写代码去调用而是通过一个更高层的编排 Skill把已有的 Skill 当成步骤来调用。编排 Skill 的 SKILL.md 不用把每个子 Skill 的逻辑重复写一遍它只需要写调度顺序第一步调用脚本生成第二步调用分镜生成第三步调用素材索引第四步调用剪辑命令生成第五步调用字幕生成。前面每一步的输出自动成为下一步的输入。这里有一个实测下来的关键经验一定要让每一步的输出都保存成文件而不是只留在上下文里。因为上下文的容量是有限的如果你所有的中间结果都堆在对话里到第五步的时候前面的工具调用早就被挤掉了。我一般的做法是建立一个工作目录比如 output/然后把分镜表存成 md、素材索引存成 json、渲染命令存成 sh、字幕文件存成 srt。每一步都是读文件、写文件这样链路非常稳。组合完之后的原理是调度层负责“知道下一步做什么”子 Skill 负责“把这一步做好”外部工具负责“把命令变成真实文件”。这套分工是我用过最舒服的模式强烈建议你照这个思路来搭。4.4 参数调优与效果验证最后一个实操阶段就是反复调。我自己第一版跑出来总时长比预期多了 20%后来发现是语速参数设得太保守。240 字/分钟在口播里确实偏慢改成 260 之后误差就进去了。还有素材的路径问题如果你在分镜表里写死素材文件名但实际素材在另一个目录渲染的时候就会报错。解决办法是在剪辑 Skill 里加一步先扫描素材目录生成一份实际可用的素材清单再用清单去匹配分镜表里的逻辑镜头。宁可自动匹配不上让你手动指一下也不能让分镜表里的名字和真实文件对不上。效果验证这一环我总是先跑一个小片段而不是整片。拿前两条分镜先渲染出一个 5 秒的测试片段确认画面比例、字幕位置、转场效果都符合预期之后再放全长。这个习惯帮我省下了大把返工时间。5. 常见问题与排查技巧实录实战中一定会踩坑我把几个出现频率最高的问题和对应的排查思路列出来都是基于我自己的实操记录希望能帮你少走弯路。5.1 Skill 压根没被识别怎么办这是最常见的翻车点。你明明把 SKILL.md 放进目录了但触发关键词之后模型完全没有反应还是用默认的通用能力在回答。90% 的原因是文件路径不对、目录名不规范或者 SKILL.md 里的 YAML frontmatter 写错了比如少了结尾的---。我发现一个比较有效的排查顺序先检查是不是放在了一级子目录下Claude Code 不会递归扫描深层的目录结构再检查 SKILL.md 文件名的首字母大小写敏感的环境里写成 skill.md 就是会不认最后检查 frontmatter 的 name 字段和目录名是否匹配。有时候 description 写得和你的触发词偏差太大也命中不了那就改描述不要死磕。5.2 上下文超限导致指令丢失Skill 是把完整指令加载进上下文才工作的如果你的 Skill 文件写得特别长或者对话过程中中间产物太多模型就可能在执行到一半时“忘掉”前面步骤的指令。这个问题的根本解法是“让 Skill 瘦身”。把长篇幅的样例数据拿到单独的文件里SKILL.md 里只写指令摘要并明确告诉模型“需要样例时先读 examples.md”。我刚才提到过一定要让每一步中间结果落盘。落盘之后即使上下文被截断模型也能通过读取文件把状态找回来。5.3 外部工具调不动Skill 本身不是工具它只是指导模型调用工具。如果你发现模型生成的 ffmpeg 命令在终端里可以直接跑通但在 Claude Code 环境里报权限错误那就是默认情况下 shell 工具需要用户确认执行。你可以选择在配置里允许特定目录下的命令免确认或者临时手动确认但千万不要直接全局放开 shell 权限安全红线不能碰。还有一种情况是你本地根本没有装对应工具。Skill 好就好在它会告诉你需要装什么依赖但如果你跳过依赖检查直接硬跑就会出现报错。我现在的习惯是拿到一个新 Skill先看它文档里写的依赖项逐个检查版本再开始第一个测试用例。5.4 生成结果不稳定同一个 Skill昨天跑出来的分镜表很好今天换了一段输入就拉胯了。这种情况多半不是模型变笨了而是你的输入格式触发了 Skill 指令里的“未定义分支”。比如模板里要求输入包含“时长”字段但你只说了一句“帮我做分镜”它就不得不自己脑补时长。给 Skill 增加一个前置步骤很管用接收到用户输入后先做参数提取检查必填字段是否齐全缺失就直接跟用户确认而不是盲目执行。这相当于给工作流加了一道质检闸门会明显提升稳定性。症状可能原因快速排查/解决Skill 不触发目录层级太深、frontmatter 格式错检查路径、目录命名、YAML 完整性执行到一半丢指令SKILL.md 太长、上下文过载精简指令、外部引用样例、中间结果落盘工具命令报错依赖缺失、权限策略限制核对依赖清单、确认 shell 权限边界结果时好时坏输入参数缺字段、指令有歧义增加参数校验和前置确认步骤这四条来自我自己的踩坑记录不一定覆盖你遇到的所有问题但如果你严格按照上面的流程来做八成的问题在前面几步就会被拦下来了。真正边界模糊的场景我现在的兜底策略是把出错的输入和期望输出整理成一个 case直接放进 SKILL.md 里的“示例”部分。这个 Skill 就会越用越懂你越用越稳。6. 给想抄作业的人三条经验6.1 不要迷信星数要看“能不能当场跑通”我这次盘点之后最大的认知变化就是把这个观念钉死了星数高的小项目很可能因为长期没更新而失效星数低的小项目则可能刚好适配你当前的场景。给我留下好印象的很多低星项目都有个共同特点作者是在真实项目里打磨过的所以你拿来就能用。我现在的评判顺序是先看更新时间然后克隆下来跑一个最小用例最后才看 README 和星数。如果最小用例能跑通哪怕仓库没一个星它对我来说也是好工具。真的遇到了能直接解决你问题的项目星数完全不影响你使用。保持自己的判断力永远是第一位的。6.2 自己写一个 Skill 比想象中便宜很多你不需要写完整代码才能做一个 Skill。它本质上就是一个 Markdown 文件你只需要会描述步骤、定义输入输出格式就能获得一个很实用的工具。我的第一个视频相关 Skill 只花了大概二十分钟写完之后它就把我一直手动排的分镜流程自动化了。写的时候记住“输入、步骤、输出、验收标准”这四段式基本上不会出错。一开始不用追求大而全就把你每天重复做的那件事写下来让它变成技能这种增量积累的方法最有效。先把常用的三五个流程固化成 Skill坚持一个月后你就能攒出属于自己的一套工作流。6.3 从视频 Skill 延伸出去的更大玩法视频 Skill 只是整个 Skill 生态的一个缩影。当你理解了这套机制之后你会发现文档生成、数据分析、运营复盘这些场景全部可以套用同一个逻辑把你的工作方法整理成一个 SKILL.md让 Claude Code 按你的方法来干活。我现在在尝试的一个方向是把视频 Skill 和知识库管理结合起来用视频脚本 Skill 批量产出某个主题的口播稿再让它自动归档成内容库下一轮选题时直接从库里召回历史高赞内容作为参考。再往下走你甚至可以给团队里不同的账号定制不同的风格 Skill同一个选题产出两个风格完全不同的脚本。我自己最大的体会是Skill 体系真正改变了人和 AI 的协作方式。以前是每次都在重新教它现在是把经验沉淀下来让它一次比一次稳定。这个思路一旦打开能做的事会越来越多。最后再分享一个小技巧当你给一个项目做分类盘点的时候别只看它写了什么一定要把它放到你自己的生产链路里跑一遍。一个 Skill 好不好用在目录里看不出来只有放进流水线才知道。你花几个小时去做这件事收获的是一整套可以一直在生产环境里运转的内容基础设施。