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 figure""couple""detective"，{location}可以填"neon-lit alley""empty street""bridge"，{mood}可以填"melancholic""tense""romantic"。一个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 Request
skill-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生成时都带上，保证整体风格统一。
这两个方向我还在整理中，等成熟了会继续开源出来。如果你也在做类似的事情，欢迎一起交流，这种资产越多人贡献越厚，对所有人都好。
