1. 463个AI视频拆成Skill和提示语模版这件事到底在解决什么问题先说说我为什么要干这件事。过去大半年我几乎每天都在跟AI视频生成工具打交道——文生视频、图生视频、视频风格迁移、人物替换、超分修复各种工具轮着用。用得多了就发现一个很要命的问题每次生成一条满意的视频背后往往要反复调十几遍提示语。今天调好了一个电影感慢镜头雨夜街头的提示语明天想复用翻聊天记录翻半天找到了发现参数对不上又得重新试。更麻烦的是AI视频生成不像写代码那样有明确的函数签名。你给同一个提示语换个模型、换个分辨率、换个时长出来的效果可能天差地别。这就导致一个尴尬的局面经验很难沉淀。你踩过的坑、试出来的好参数散落在各种笔记、截图、聊天记录里过两周自己都找不回来。所以我做了一个决定把手头积累的463个AI视频案例全部拆解成结构化的Skill和提示语模版并且开源出来。这里的Skill不是某个特定平台的专有概念你可以把它理解成一套可复用的能力封装——每个Skill包含一段明确的适用场景描述、一组经过验证的提示语模版、推荐参数区间、以及常见失败情况的处理建议。提示语模版则是Skill的弹药是具体可粘贴、可微调的文字片段。这件事的核心价值在于三点。第一把隐性的调参经验变成显性的结构化资产。以前你脑子里知道雨夜街头要加反射、要压低饱和度、要给慢快门现在这些变成了一个叫cinematic-rainy-street的Skill打开就能用。第二降低复用门槛。不管你是用哪家的AI视频工具只要支持文本提示就能把这套模版拿过去改。第三让协作成为可能。开源之后别人可以提交新的Skill、修正参数、补充失败案例整个库会越用越厚。适合谁来参考如果你是做短视频内容的创作者这套东西能帮你把出片效率提上去如果你是做AI应用开发的工程师这套Skill的结构设计可以直接借鉴到自己的Agent或工作流里如果你只是刚接触AI视频生成那这463个案例拆出来的模版能帮你跳过大量瞎试的阶段。下面我会从Skill的结构设计、提示语模版的拆解方法、463个案例的分类逻辑、开源仓库的组织方式、以及实际使用中踩过的坑这几个角度把这件事完整讲清楚。2. Skill的结构设计为什么不是简单的提示语合集2.1 一个Skill应该包含哪些字段很多人一听把提示语整理成模版第一反应就是建个表格左边场景右边提示语完事。我一开始也这么干过结果整理到第50个案例就发现不行了——因为光有提示语你根本不知道怎么用。举个具体的例子。我有一条提示语是这么写的A lone figure walking through a neon-lit alley, rain pouring down, reflections on wet asphalt, shallow depth of field, slow motion, cinematic color grading, 24fps, anamorphic lens flare如果你直接拿去用可能会发现有的工具对anamorphic lens flare支持不好出来一团糊有的工具slow motion需要单独在参数里设写在提示语里没用还有的工具对24fps这种帧率描述完全不感冒。所以提示语本身只是Skill的一部分不是全部。我最终定下来的Skill结构包含这几个字段字段名作用是否必填skill_id唯一标识用短横线命名是skill_name中文可读名称是category所属大类如场景氛围人物动作转场效果是applicable_tools验证过可用的工具列表是prompt_template核心提示语模版含占位符是negative_prompt负面提示语排除不想要的效果否recommended_params推荐参数区间如时长、分辨率、运动强度是failure_cases已知失败情况和规避方法是example_output示例输出描述或链接否contributor贡献者标识否这个结构里我认为最有价值的是failure_cases字段。因为提示语模版网上到处都是但这个模版在什么情况下会翻车这件事只有真正大量跑过的人才知道。比如上面那个雨夜街头的Skill我在failure_cases里写了三条一是当画面中人物占比超过三分之一时慢动作会导致人物边缘出现明显拖影二是部分工具对neon-lit的理解偏向高饱和需要手动在负面提示里加oversaturated三是anamorphic lens flare在竖屏比例下容易裁切异常建议横屏使用。2.2 为什么用占位符而不是固定值提示语模版里我大量使用了占位符比如{subject}、{location}、{time_of_day}、{mood}。这么做的好处是一个Skill能覆盖一类场景而不是一个死场景。还是拿雨夜街头举例模版写成这样A {subject} walking through a {location}, rain pouring down, reflections on wet asphalt, {mood} atmosphere, shallow depth of field, slow motion, cinematic color grading这样{subject}可以填lone figurecoupledetective{location}可以填neon-lit alleyempty streetbridge{mood}可以填melancholictenseromantic。一个Skill就变成了一个可参数化的生成器而不是一条死提示语。但这里有个坑要提醒占位符不是越多越好。我一开始贪心一个模版里塞了七八个占位符结果发现组合爆炸根本没法验证哪些组合是好的。后来我定了个规矩每个Skill的占位符不超过4个且每个占位符的候选值不超过5个。这样单个Skill的验证组合控制在合理范围内同时又能保证灵活性。2.3 Skill的粒度怎么把握这是我在整理过程中反复调整的一个点。太粗了一个Skill包打天下用起来还是不知道从哪下手太细了每个Skill只能干一件事数量爆炸找起来费劲。我最后的判断标准是一个Skill应该对应一个可独立描述的视觉意图。什么叫可独立描述的视觉意图就是你能用一句话说清楚我要的是什么样的画面而且这句话不需要再拆。比如雨夜街头慢镜头是一个Skill霓虹灯反射特写是另一个Skill人物在雨中回头又是另一个。这三个可以组合使用但各自独立成立。而电影感就不是一个合格的Skill因为它太模糊没法对应具体的提示语和参数。按这个标准463个案例最终拆成了187个Skill平均每个Skill覆盖2到3个原始案例。这个比例我觉得比较健康——既没有粗到没法用也没有细到找不着。3. 提示语模版的拆解方法从一条好视频倒推可复用结构3.1 先分类再拆解不要反过来我见过不少人整理提示语的方式是打开一个文档看到一条记一条记完再想办法分类。这个顺序是反的会导致后期分类极其痛苦而且容易漏掉重要维度。我的做法是先定分类框架再往里填。分类框架怎么定不是拍脑袋想而是从你实际生成视频的工作流里提取。我回顾了自己过去半年的操作记录发现我调提示语时脑子里其实一直在按这几个维度做决策画面主体是什么人、物、景、抽象概念主体在做什么静止、移动、交互、变形环境氛围是什么时间、天气、光线、色彩基调镜头怎么运动推拉摇移、固定、跟随、环绕想要什么风格写实、动画、胶片、赛博、水墨这五个维度就成了我的一级分类。每个维度下面再细分比如环境氛围下面分时间天气光线色彩。这样463个案例往里填的时候每个案例天然就带上了多维标签后期检索和组合都方便。3.2 从成品视频倒推提示语结构拆解一条已经生成好的视频时我不会只看它当时的提示语而是会做一件事把视频拆成必须有的元素和锦上添花的元素。举个例子我有一条很满意的视频一个穿风衣的人在雾蒙蒙的码头走动远处有船灯整体偏冷色调镜头缓慢横移。当时的提示语写得很长很乱我把它拆解成必须有的元素主体穿风衣的人动作走动环境雾蒙蒙的码头光线冷色调、远处船灯镜头缓慢横移锦上添花的元素风衣下摆飘动地面湿润反光远处有汽笛声暗示虽然视频没声音但提示语里写了能影响画面氛围拆完之后我把必须有的元素做成模版的骨架锦上添花的元素做成可选附加项。这样这个Skill就变成了一个核心稳定、可选灵活的结构。别人用的时候可以先只用骨架跑一版满意了再加附加项。3.3 负面提示语的整理同样重要很多人整理提示语只整理正向的负面提示语随手写或者不写。但我在463个案例里发现负面提示语对成品质量的影响有时候比正向还大。比如生成人物特写时如果不加负面提示很多工具会默认给人物加一些奇怪的细节——手指数量不对、牙齿糊成一团、眼睛反光异常。这些不是正向提示能解决的必须靠负面提示排除。我整理负面提示语的方法是按翻车类型归类而不是按工具归类。常见的翻车类型有结构类多余肢体、比例失调、面部扭曲质感类过度锐化、塑料感、噪点过多风格类意外水印、文字乱入、风格漂移运动类拖影、闪烁、跳帧每个Skill的negative_prompt字段我会从这几类里挑相关的填进去。比如人物类Skill一定会带结构类的负面提示运动类Skill一定会带运动类的负面提示。这样整理下来负面提示语也变成了一套可复用的资产而不是每次现想。4. 463个案例的分类逻辑与Skill映射关系4.1 按生成难度分层而不是按主题平铺463个案例如果只是按主题平铺找起来会很累。我加了一个难度分层的维度把所有案例分成三层基础层单主体、单动作、环境简单提示语短参数容错高进阶层多主体或主体与环境有交互提示语中等长度参数需要调挑战层复杂运动、多元素协同、风格强约束提示语长参数敏感这个分层的好处是新手可以从基础层开始逐步往上走而不是一上来就被挑战层的复杂提示语劝退。同时每个Skill也会标注它主要覆盖哪个难度层方便按需检索。我统计了一下463个案例里基础层大约占45%进阶层占35%挑战层占20%。这个分布也比较符合实际——大部分日常需求用基础层和进阶层就够了挑战层是偶尔需要出精品时才动用。4.2 案例到Skill的映射不是一对一的前面提到187个Skill覆盖463个案例平均一个Skill对应2到3个案例。但实际映射关系比这个复杂有几种情况一对多一个Skill对应多个案例。比如城市夜景延时这个Skill对应了7个不同城市、不同角度的案例。这些案例共享同一套提示语骨架只是占位符填的值不同。多对一多个Skill协同完成一个案例。比如一条复杂的视频可能同时用到了人物行走雨夜氛围镜头横移三个Skill每个Skill贡献一部分提示语最后拼起来。一对零有些案例拆完之后发现没有形成可复用的Skill因为太特殊了只适用于那一次。这类案例我单独放在一个特殊案例目录里不作为Skill发布但保留作为参考。这种灵活的映射关系比强行一对一要实用得多。因为实际创作中你很少是从零写一条完整提示语更多是从几个Skill里各取一部分拼起来。4.3 分类标签要能支持组合检索为了让这187个Skill真正好用我给每个Skill打了一组标签标签体系是这样的主体标签person, animal, object, landscape, abstract动作标签static, walk, run, fly, transform, interact氛围标签day, night, rain, fog, snow, indoor, outdoor风格标签realistic, cinematic, anime, ink, cyberpunk, vintage镜头标签static_cam, pan, tilt, zoom, tracking, orbit这样检索的时候你可以按任意标签组合筛选。比如night rain person walk cinematic就能快速定位到雨夜人物行走的电影感Skill。这比翻目录快得多也更符合实际创作时的思考方式——你脑子里想的往往就是几个关键词的组合。5. 开源仓库的组织方式与协作机制5.1 目录结构怎么设计才不乱开源一个包含187个Skill的仓库目录结构如果设计不好很快就会变成一团乱麻。我最终采用的是一种按分类分目录、按Skill分文件的结构/skills /scene-atmosphere /cinematic-rainy-street skill.md prompt-template.txt negative-prompt.txt params.json examples/ /foggy-dock-morning ... /character-action ... /camera-movement ... /style-transfer ... /special-cases /docs contributing.md skill-spec.md每个Skill一个独立文件夹里面放这个Skill的所有相关文件。skill.md是主文档包含前面说的所有字段prompt-template.txt是纯提示语模版方便直接复制params.json是推荐参数的结构化版本examples/放示例输出。这种结构的好处是每个Skill自包含别人想用某个Skill直接进那个文件夹就行不用在多个文件之间跳来跳去。同时分类目录又保证了整体有序不会因为Skill数量增长而失控。5.2 贡献流程要足够简单开源项目最怕的就是贡献门槛太高。如果别人想提交一个新Skill还要先读一大堆规范、填一堆表格大概率就放弃了。所以我把贡献流程压到了最简Fork仓库在对应分类目录下新建Skill文件夹按照skill-spec.md里的模版填写文件提交Pull Requestskill-spec.md里我写了一个最小可用Skill示例只有必填字段别人照着改就行。同时我也提供了完整Skill示例包含所有可选字段供想提交更详细内容的人参考。审核方面我主要看三点提示语是否经过实际验证要求提交者附上至少一次成功生成的说明、失败案例是否真实不接受编造的失败情况、是否与已有Skill重复重复的会建议合并而不是新增。这三点保证了仓库的质量同时也不会因为审核太严把贡献者吓跑。5.3 版本管理要能追溯提示语的变化提示语模版这东西改一个词可能效果就变了。所以版本管理很重要。我的做法是每个Skill文件夹里的文件都纳入Git管理同时skill.md里维护一个简短的变更记录记录每次修改改了什么、为什么改。比如某个Skill的提示语从slow motion改成了gentle slow motion变更记录里会写原slow motion在部分工具下导致运动过快改为gentle slow motion后运动更自然已在三个工具上验证。这样别人看到这个Skill时能知道它经历过什么调整用起来更有底。6. 实际使用中踩过的坑与规避经验6.1 提示语模版不是跨工具通用的这是我最开始踩的最大的坑。我以为把提示语整理成模版就能在所有AI视频工具里通用。实际跑下来发现不同工具对同一段提示语的理解差异非常大。举个具体的例子。同一个雨夜街头模版在工具A里出来的是偏写实的冷色调在工具B里出来的是偏动画的高饱和在工具C里干脆把anamorphic lens flare理解成了画面上的光斑贴图。这不是模版的问题是工具底层模型和提示语解析逻辑的差异。所以后来我在每个Skill的applicable_tools字段里明确标注了这个模版在哪些工具上验证过、效果如何。同时对于差异特别大的情况我会在failure_cases里写清楚在工具X上需要把某段提示语替换成什么。提示不要假设一个提示语模版能通吃所有工具。拿到一个新工具先用基础层Skill跑几条摸清它的脾气再决定要不要用进阶层和挑战层的模版。6.2 参数比提示语更容易被忽略很多人把注意力全放在提示语上觉得提示语写好了就行。但我在463个案例里发现参数对成品的影响至少占四成。同样的提示语时长设3秒和设8秒出来的运动幅度完全不一样运动强度设低和设高画面稳定性差很多。所以我在每个Skill里都放了recommended_params而且不是给一个固定值是给一个区间。比如时长4-6秒运动强度0.3-0.5分辨率1080p起。给区间的原因是不同工具的参数刻度不一样给固定值反而不好用。给区间使用者可以根据自己工具的情况在区间内调。同时我会在failure_cases里写清楚参数超出区间会怎样。比如时长超过8秒时慢动作Skill会出现明显的画面重复运动强度超过0.7时人物边缘开始出现拖影。这些信息比单纯给一个推荐值有用得多。6.3 组合Skill时要注意冲突前面说了复杂视频往往是多个Skill组合出来的。但组合不是简单拼接有些Skill放一起会打架。我遇到过最典型的一个冲突是一个Skill要求浅景深另一个Skill要求全景清晰。这两个放一起工具会无所适从出来的画面要么景深乱掉要么全景糊成一片。类似的冲突还有高饱和和低饱和、快速运动和稳定镜头等等。我的处理方式是在skill.md里加了一个兼容性说明段落列出这个Skill和哪些类型的Skill容易冲突以及冲突时建议保留哪个、舍弃哪个。比如浅景深Skill的兼容性说明里会写与全景清晰类Skill冲突时建议保留浅景深因为全景清晰可以通过后期调整弥补而景深效果很难后期加。6.4 不要迷信模版该手调还得手调最后说一个心态上的坑。整理出187个Skill之后我有段时间变得特别依赖模版什么视频都想从模版里套。结果发现有些创意就是模版覆盖不到的硬套反而限制了发挥。后来我调整了心态模版是起点不是终点。用模版快速跑出一个基础版本然后在这个版本上手调加一些模版里没有的元素往往能出更好的效果。模版的价值在于帮你跳过从零开始的阶段而不是替代你的创作判断。7. 这套Skill体系后续还能怎么扩展目前这187个Skill主要覆盖的是单镜头、短时长的AI视频生成场景。但实际创作中很多需求是多镜头拼接的——比如一个30秒的短片可能由5到6个镜头组成每个镜头用不同的Skill生成最后剪辑在一起。所以我接下来想做的扩展方向是镜头序列Skill。就是把多个单镜头Skill按顺序组合起来形成一个分镜脚本级别的模版。比如雨夜追逐这个序列Skill可能包含远景街道建立镜头中景人物奔跑特写脚步溅水近景面部表情四个子Skill每个子Skill有自己的提示语和参数组合起来就是一个完整的分镜方案。另一个方向是风格一致性Skill。多镜头拼接时最大的问题是不同镜头之间的风格不统一——这个镜头偏冷那个镜头偏暖这个镜头写实那个镜头偏动画。风格一致性Skill的作用是提供一组风格锚点提示语在每个子Skill生成时都带上保证整体风格统一。这两个方向我还在整理中等成熟了会继续开源出来。如果你也在做类似的事情欢迎一起交流这种资产越多人贡献越厚对所有人都好。