企业官网建设流程全解析

做AI视频工具这一年，我最大的感受就是：提示语模版才是真正拉开差距的东西。于是今年我干了一件挺“笨”的事——把散落在各个平台、群里、教程里的463条AI视频逐条拆解，整理成了一套可复用的Skill和提示语模版，并且全部开源。这篇文章把整个拆解过程、编码思路、踩坑经历都写清楚，希望对同样被视频提示词折磨的朋友有点帮助。

做这件事之前，我自己也被“提示词玄学”坑过无数次：同一个Prompt，上午生成丝滑运镜，下午就变成了鬼畜抽搐；换个风格词，结果连主体都变了。后来我意识到，问题不在于AI模型不稳定，而在于我的提示词没有结构。视频生成和图片生成最大的区别，是必须同时控制“空间画面”和“时间运动”，这两条线一旦缠绕在一起，生成结果就完全失控。所以我把463条能跑出好效果的视频，全部拆成了可复用的Skill和结构化提示语模版，开源出来让更多人直接“抄作业”，不用再从头摸索。

我的目标很简单：让一个完全不懂提示词的人，也能通过这套模版生成80分以上的AI视频。接下来我按项目实际推进的顺序，从为什么做、怎么拆、怎么落地，到开源后用户反馈的问题，完整复盘一遍。

1. 项目缘起：为什么把463条AI视频变成Skill

1.1 视频生成提示词是个体力活

先说个反常识的结论：AI视频生成瓶颈，早就不在模型了，而在提示词的组织方式上。你看网上那些炫酷的AI短片，镜头运动、主体动作、环境光影、风格质感全都严丝合缝，背后几乎都有一套精心打磨过的提示词结构。但问题是，大部分人拿到一个视频片段后，只能靠肉眼去猜“它大概用了什么词”，然后自己反复试错。这个过程极其低效，一条35秒的视频，可能背后是30多次抽卡。

我做这个项目的直接导火索，是有一次为了复刻一个“雨夜霓虹街区跟拍”的效果，整整花了两个晚上。同一组描述词，在A工具里能出效果，换到B工具里就完全变味。后来我把那条视频的提示词逐帧拆开，才发现人家不仅写了“雨夜、霓虹灯、潮湿地面”，更重要的是写了“镜头跟随人物从背后缓慢推进、前景有车辆经过产生动态模糊、光线在湿地面形成拉长的反射”。真正决定视频质量的是后面这些运动与时间维度的描述，而大多数初学者只写了前一半。

当时我就在想：如果能把大量成功视频的提示词结构抽出来，做成类似“表情包”一样可以随时调用的Skill和模版，是不是就能让普通人绕开那些坑？于是这个项目就立项了。立项时我给自己定了几条硬规矩：第一，只收真实生成出来且效果可验证的视频，不要那种“看起来很美但完全复现不了”的案例；第二,每条必须拆出可复用的骨架，而不是简单复制原视频的提示词；第三，全部开源，包括中间的拆解表格和脚本，不留独家。

1.2 从散装提示词到结构化Skill

“Skill”这个概念，在Agent开发和大模型应用里已经不新鲜了。你可以把它理解成一个封装好的能力包：里面既有触发条件、执行流程，也有写好的提示词片段和参数规则。我这次做的事情，相当于把传统上只属于文本对话的Skill模式，迁移到了AI视频生成领域。视频Skill和平时大家聊的ChatGPT Prompt最大的区别在于，它必须包含“时间轴”信息。

举个直观的例子：普通提示词写“一只橘猫在窗台上打盹”，视频Skill里我会把它拆成“开场全景交代环境——推进到猫的脸部特写——猫咪耳朵抖动、睁眼、伸懒腰——镜头缓慢后拉回到全景”。同样的主体，加了时间轴和没有时间轴，出来的视频完全是两个物种。所有463条视频至少包含三个维度：主体描述、运动描述、镜头描述，缺一个就只能靠运气。

这套思路成型之后，我立刻意识到不能只做纯文本模板，必须做成机器可读的Skill文件，才能在不同工具之间流转。具体来说，我最终把每个Skill定义成一个YAML文件，里面包含meta信息、适用场景、基础提示词、增强参数、负面提示词，以及不同视频工具对应的改写规则。这个决定在后续的开源传播中起了很大作用，很多人都说“光看提示词就值了，但YAML文件让我能直接喂给脚本用”。

2. 拆解方法论：从视频里挖出可复用的提示语骨架

2.1 数据来源与筛选标准

463条视频不是我从一个地方扒下来的，主要来源有四类：一是公开的AI视频大赛获奖作品和官方精选集；二是创作者主动分享的幕后拆解或“提示词+成片”对照内容；三是我自己过去一年在可灵、即梦、Runway、Pika等工具上跑出来的有效案例；四是各个AI社区里被反复转载的“高赞视频”及其复现讨论。每一条都做了版权和可复现性审查，凡是无法确认来源或明显是纯手工后期硬做的，一律剔除。

筛选标准我定了三个硬指标：可复现性、通用性、启发性。可复现性指三次以上用同一套Skill能在合理参数范围内生成相似视频；通用性指不能只适用于某一个具体工具，至少能在两类视频生成器上平移；启发性则比较主观，就是看完之后能让人“恍然大悟”的那种结构，比如一条视频里用了特殊的转场技巧，或者对光影的运动做了非常细腻的刻画。最终从2000多条候选案例中筛出463条，正好凑够了第一批数据集。

这里要提醒一句：数据筛选千万别只看点赞量。很多高赞视频的提示词其实高度依赖随机种子和后期剪辑，拆出来当模版反而会带偏人。我宁愿选那种“一次生成就很好”的视频，也不要“抽了100次卡选出来1次”的案例，因为后者的提示词本身不具备复用价值，更多是运气。

2.2 核心拆解模型：五层结构

拆解阶段我反复迭代了四版，最终固定成一套“五层结构”拆解法，分别对应：主体层、环境层、镜头层、运动层、风格层。每一层都有独立的提示词字段，这样最后合并成Skill时，可以做到任意替换某一层而不影响其他层。这非常关键，因为实际生成视频时，用户最常做的操作就是“把猫换成狗”或“把白天改成夜晚”，如果所有描述混在一坨文字里，每次改都是一场灾难。

用“赛博朋克城市追车戏”举例。主体层写“银色改装跑车、驾驶座穿黑色风衣的驾驶员”；环境层写“雨夜、潮湿柏油路、霓虹灯牌、高楼缝隙间的雾气”；镜头层写“低角度跟踪镜头，车头前方，镜头随车转弯而倾斜”；运动层写“车轮碾过水洼溅起水花、灯光在车身上流动、背景建筑快速后退产生速度感”；风格层写“电影级调色、高对比度、赛博朋克2077审美、浅景深”。合起来是一个长Prompt，拆开就是五个独立的可变模块。

这套五层结构也直接影响了我后续的Skill编码方式。每个Skill文件里，五层分别用五个字段存储，并额外生成一个“融合提示词”字段，方便直接粘贴到生成工具里。这样做的好处是，你想微调某个维度时，只需要改一个字段；想完全替换主体时，也不会连带把镜头和运动风格全都带偏。我见过太多人为了把“狗追飞盘”改成“小孩追气球”，结果把运镜和光影也全改了，最后出来的东西完全不是想要的。

2.3 如何从一条视频反推成Skill文件

具体到单条视频，我的反推流程分四步。第一步是逐帧看运动轨迹，用播放器逐帧拖拽，找到画面里所有“位移”元素，包括主体移动、镜头移动、环境变化，比如云在飘、灯光在闪也算。第二步是拆镜头语言，记录这个视频是固定镜头、推拉、摇移、跟拍还是航拍，以及是否有变焦或焦点转移。第三步是恢复风格描述，这个最难，因为风格是主观的，我一般会列出所有能想到的风格词，去掉冲突项，再筛出最贴切的3到5个。第四步是写成可替换的伪代码，即先用中文写一套完整提示词，再抽掉具体名词，填上占位符，比如把“猫”变成[主体]。

边界情况我会单独标记。比如有些视频是“镜头不动、主体运动”，有些是“镜头运动、主体静止”，还有一些是“两者都动但方向相反”，这些在Skill里要写清楚运动关系，否则生成时很容易出现物理违和感。常见的是把“镜头绕主体旋转”和“主体自身旋转”混为一谈，效果完全不一样。我自己的经验是，宁可拆慢一点，也不要贪快，一条视频平均拆解时间大约40分钟，遇到复杂的可能要一个半小时。463条不是我一个人拆的，后期有两个朋友加入，并且我们用了共享表格来保证拆解口径一致，这也给开源后的协作打下了基础。

3. 实操过程：如何把463个视频逐一转成规范模板

3.1 工具链与工作流

整个拆解过程不是靠纯手工堆出来的。我的工作流大概长这样：先用本地表格维护所有视频的元数据和五层拆解字段，然后用一个Python脚本把表格批量转成YAML格式的Skill文件，最后再用一个自动化检查脚本校验字段完整性、是否有重复文案、是否有“待补全”占位符。这里向非技术朋友说明一下，YAML就是一种比JSON更易读的配置格式，用缩进表示层级，适合保存这类结构化模版。

Python脚本的核心功能很简单：读取Excel里的Sheet，把每一行映射成一个Skill文件，文件名自动生成为skill-编号-英文短名.yaml。过程中最难的不是写脚本，而是统一表格规范。前100条数据我踩了大坑，因为不同时间去填表，字段名时而用“运动描述”，时而用“镜头运动”，格式化脚本跑出来一堆缺失值。后来我写死了一个表头模板，只用程序校验，凡是字段名不匹配就直接报警，不给任何人手动改表头的机会。

我建议想复刻这个流程的人，千万别一开始就追求自动化，先手工拆20条，把字段定义琢磨清楚了，再写批量脚本。否则你会在拆到80条的时候发现字段设计不合理，比如忘了区分“镜头内部运动”和“主体运动”，回头改表格数据会让你痛不欲生。我们中途就补过一次结构，把运动层拆成“主体动作”“镜头运动”“环境运动”三个子字段，花了整整两天才把历史数据迁移完。

3.2 编码体系：从skill-001到skill-463

开源之后很多人问我的第一个问题是：你的编号是怎么排的？不会是按时间顺序排的吧？确实不是。我设计了一套简单的分类编码，大致分为场景类、风格类、运镜类、特效类、叙事类、组合类六个大类，每个Skill的编号前缀对应分类。比如场景类的编号是scene-开头，风格类是style-开头，运镜类是camera-开头，组合类是mix-开头。这样用户在找模版时，一眼就能判断这个Skill大概解决什么问题。

网上常有人提到“skill编码247”，其实就是我第三大类里的第47条运镜Skill，它的全称是camera-047，内容核心是“低角度环绕+焦点转移”，专门用来解决“围绕静止主体拍一个带情绪感的环绕镜头”这类需求。很多人以为编码是玄学，其实纯粹是分类索引。我之所以不用纯数字，而用带前缀的编号，就是希望文件名本身就携带类别信息，否则外网用户根本分不清skill-123和skill-321有什么差别。

为了让这套体系更好用，我还做了一个README.md，里面放了一张完整的索引表，列明每个Skill的五层摘要和适用工具。这个索引表花了我不少心思，因为它不仅是给人看的，还是给脚本用的。后来有开发者直接在索引表上做关键词搜索小程序，把“下雨”“追逐”“猫”这种自然语言转成对应的Skill编号，等于又往上叠了一层应用。这说明底层数据的结构设计足够清晰时，上层创意就会源源不断。

3.3 模板样例拆解：一个Prompt和一份Skill文件

空谈方法没用，直接看样例。以编号scene-012为例，这个Skill描述的是“雨夜霓虹灯下的孤独人物走过斑马线”，原始视频来自某次官方征集，效果非常稳定。我把它拆成五层后，写出的完整提示词如下：

主体层：一个穿深色大衣的成年男性，低着头，双手插兜，肩膀略微缩起。环境层：城市雨夜，湿润的黑色柏油马路，路面积水映着粉色与蓝色霓虹灯光，两侧商铺招牌闪烁。镜头层：中景侧跟镜头，镜头高度约腰部位置，随人物步伐缓慢向前移动，保持人物在画面三分线右侧。运动层：人物匀速步行，衣摆和头发随风轻微摆动，落地时脚尖溅起细小水花，周围车辆偶尔驶过，形成模糊的灯光拖影。风格层：电影感，冷色调主光，暖色点缀，浅景深，35mm胶片颗粒质感。

这份提示词直接贴到多数视频工具里，基本就能跑出70分的画面。但如果要做成Skill，我会把完整提示词抽成五个字段，并额外补一个“参数建议”区域，包括建议时长、建议分辨率、负面提示词（比如“不要出现字幕、不要卡通化、不要面部特写”）。YAML文件大概是下面这个结构，为了方便展示，我只保留核心字段。

id: scene-012 title: 雨夜霓虹孤独行者 category: 场景类 five_layers: subject: "一个穿深色大衣的成年男性，低着头，双手插兜，肩膀略微缩起" environment: "城市雨夜，湿润的黑色柏油马路，路面积水映着粉色与蓝色霓虹灯光，两侧商铺招牌闪烁" camera: "中景侧跟镜头，镜头高度约腰部位置，随人物步伐缓慢向前移动，保持人物在画面三分线右侧" motion: "人物匀速步行，衣摆和头发随风轻微摆动，落地时脚尖溅起细小水花，周围车辆偶尔驶过，形成模糊的灯光拖影" style: "电影感，冷色调主光，暖色点缀，浅景深，35mm胶片颗粒质感" fusion_prompt: "（上面五层内容按顺序拼接）" negative_prompt: "字幕，卡通化，面部特写，过度曝光" suggested_params: duration: 5s-10s aspect_ratio: "16:9" fps: 24 tools: - 可灵 - Runway - Pika

这里有个关键细节：tools字段并不是指“只能在这些工具里用”，而是指“我已经在这些工具里验证过”。不同AI视频工具对同样的提示词理解差异很大，所以我在开源仓库里单独维护了一份“工具迁移注意事项”，比如Runway对镜头运动的理解更强，但Pika对风格词的敏感度更高；可灵给到更多中文口语化描述时表现更稳，但换成英文提示词反而容易丢失环境细节。这种信息光看模版看不出来，还得配合实际试用记录。

顺带说下负面提示词的写法。很多人写“不要模糊、不要低质量”，我实测下来几乎没有用。反而写“无字幕、无水印、无多余人、无畸形手、无面部扭曲”这类具体到对象和元素的词更有效。我的经验是，负面提示词要写“可感知的内容”，不要写“抽象的质量评价”，AI根本不知道“高质量”是什么鬼，但它知道“字幕”和“水印”是什么东西。

4. 开源成果与使用指南

4.1 开源仓库里到底有什么

整个项目开源后，仓库里的内容分成五个部分：463个Skill文件、一份总索引表、五层拆解流程图、适配脚本、示例成片说明。Skill文件涵盖了最常用的视频生成需求，包括风光大片、情绪人像、动态产品、科幻场景、抽象艺术、叙事短片等。索引表支持按关键词搜索，比如搜“雨夜”会返回所有环境层含雨夜的Skill编号；搜“环绕”会返回所有镜头层含环绕的Skill编号。

适配脚本是我个人比较得意的部分。它可以把一个YAML格式的Skill自动改写成不同工具的提示词风格，比如输出一份适合Runway的长提示词、一份适合Pika的分段式提示词、一份适合可灵的中文结构化提示词。这个脚本不复杂，本质是字符串替换和字段拼接，但它解决了一个真实痛点：你不能把同一个Skill原封不动地用到所有工具上，必须做一层“方言翻译”。

一开始有人问我为什么要开源，而且把脚本和数据全放了。我的想法很简单，这个领域太新了，很多规则还没沉淀下来，如果每个人都从零开始摸索，那AI视频永远只会停留在“抽卡”阶段。开源之后，至少能让大家站在一个还算高的起点上。事实也证明，不少人直接拿我仓库里的Skill去套自己的创意，有人改一个主体就产出了很棒的商业短片，这比我一个人藏着掖着有意义得多。

4.2 三种用法：直接抄、组合用、训练自己的Skill

第一种用法最简单，就是直接抄。打开索引表，找一个你想要的场景，复制Skill里的fusion_prompt字段，粘贴到你的视频生成工具里，微调参数后开跑。这里我要泼一盆冷水：直接抄不等于100%复制原视频，因为每个平台、每个模型版本、甚至每次随机种子都不同，所以“一模一样”是不现实的。但结构和氛围感能复现到八成，对大多数创作者来说已经够用了。

第二种用法是组合，这也是我最推荐的进阶玩法。你完全可以把scene-012的环境和光影，配上camera-033的运镜，再换掉主体层的内容，组装出一个全新的Skill。因为每个文件都是模块化的，你可以从不同文件里各取一层，拼进一个新的YAML里。有人担心这样会出来“缝合怪”，但实际只要各层的风格词不冲突，拼接效果往往比单一模版更出彩。比如一个动漫风人物配上写实环境的组合，反而能制造独特的视觉张力。

第三种用法是训练自己的Skill体系。你可以拿这套仓库当“语料库”，收集一批自己偏好的风格，分析它们的人称视角、镜头词分布、负面提示词写法，然后建立自己的分支模版。已经有几个开发者这么干了，他们在我的五层结构上加了第六层“音频提示词”，专门描述背景音乐的情绪走向。这就是开源的长尾价值：你的结构被更多人扩展后，会演化出你自己都想不到的新玩法。

4.3 如何提交自己的模板参与共建

仓库开了一个contributions目录，接受任何人提交新的Skill文件或改进建议。提交时你需要附上原始视频链接或截图、五层拆解字段、至少一个工具的实测参数，以及一段“跟原版对比效果如何”的文字说明。为了不让仓库变成垃圾堆，我也设定了一个投票机制：每个新提交的Skill如果在一个月内获得10个以上的Star或评论验证，就会被合并到主索引表里。

做开源项目最怕的事情其实是“热情开坑，然后烂尾”。为了应对这个问题，我给所有愿意提交内容的朋友写了一份非常详细的CONTRIBUTING文档，里面把字段规范、命名规范、审核标准全都写清楚了。有朋友觉得我搞得像公司内部流程，但我认为，如果开源仓库的结构一开始就很乱，后面根本没法收拾。现在仓库里新增的Skill有一半来自社区，质量比我自己拆的还要好，因为很多人贡献的是他们吃饭的家伙。

提交时还有个小细节：文件名不允许带空格和特殊符号，统一用小写字母和短横线。这个约束简单，但能避免很多跨平台解压和解析出错。另外，我强烈建议提交者用Google表格共享链接这种方式来和仓库维护者协作，而不是直接把Excel文件传到Git上，因为二进制文件在历史版本管理里非常难diff，很容易造成冲突。

5. 常见问题与避坑实录

5.1 为什么同一个Skill时好时坏

这是被问得最多的问题，也是最难回答的。同一个Skill，上午跑出来质感爆棚，下午跑出来就感觉像没睡醒，很多人第一反应是“模型抽风了”。其实多数情况下，是因为你没有控制好时长和运动强度的平衡。同样的提示词，时长从5秒拉到10秒，运动速度感会完全不一样，AI需要在更多帧里补全运动轨迹，稍不注意就会出现扭曲。

另一个关键因素是采样步数和种子。多数工具的默认参数并不是对这个Skill最优的参数。你在复现一个Skill时，最好先固定种子跑一遍，记录出片效果，再去调整步数和运动强度。我见过太多人上来就改风格词，却完全没动过参数区，那自然会出现“时好时坏”。把参数当成Skill的一部分，而不是只关注Prompt，这是从“能用”进阶到“稳定用”的核心。

如果你换了不同的视频生成工具，那更要接受一个现实：每个工具对同一个Prompt的理解差异非常大。比如Runway会特别关注镜头运动描述，你写“低角度跟拍”它执行得很好；但同样的词喂给一些强调“主体运动”的工具，可能就只给你生成一个固定机位的画面。所以我的每个Skill文件里都带有tools字段和适配脚本，就是为了尽量减少这种跨工具损耗。

5.2 版权与伦理问题要提前想清楚

463个视频里有一部分来自公开比赛和别人的分享，开源这些Skill的前提是：我拆的是提示词结构，不是复制视频内容。提示词本身是文字描述，很难构成版权保护对象；但生成出来的画面如果高度模仿某部电影或某位创作者的招牌风格，依然有侵权风险。所以我在每个Skill文件里增加了一个“灵感来源”字段，如果来源是某部电影或某位作者，会在里面如实标注“致敬”“仿风格”或“原创”，并附上可替代的风格词建议。

伦理这块也要多说一句。开源模版很容易被用来批量生成虚假信息、伪造人物或制造误导性内容。我在仓库的首页就挂了一条声明：禁止用这套Skill生成任何包含真实人物肖像的虚假场景，也禁止用它批量制造欺骗性新闻视频。技术本身没有立场，但开源的人得先立个规矩，不然好心分享的东西一旦被滥用，最后受伤害的还是创作者群体。

我实际遇到过有人拿着scene-xxx去生成知名演员出现在不存在的场景里的视频，这非常危险。后来我在每个Skill文件里额外加了一个ethical_check字段，提醒使用者在生成前确认是否涉及真实人物、是否会被误解为真实事件。希望大家永远不要在这个底线上试探。

5.3 工具版本迭代导致Skill失效怎么办

AI视频工具的更新频率快得惊人，经常是今天跑的好的Skill，明天工具一升级就变成废纸。我自己就经历过三四次，某条在Runway上新版本里反复调都复现不了原来的风格。遇到这种情况我的建议是：先不要急着重写Skill，去看工具的Release Notes，很多失效是因为模型底层架构变了，比如引入新的运动模块或强化了语义解析。这可能导致原来的Prompt顺序不再被充分理解。

更实际的解决方案是：在你的Skill文件里记录“已验证版本号”和“验证日期”。这样即使工具升级，你也可以很快判断出到底是这个Skill本身有问题，还是版本变了导致的影响。我在适配脚本里专门留了一个参数，允许用户填入工具的版本号，脚本会自动给出一段“迁移建议”，比如“如果使用新版本，建议把镜头层描述放到Prompt的开头，并把环境层描述改得更简洁”。

如果你发现某个Skill彻底失效，也别着急删除。可以把它标记为deprecated，并附一条指向替代Skill的链接。这样做有两个好处：一是保留对比案例，方便后人了解工具演进对提示词的影响；二是避免小白用户搜到这个Skill后抱着旧模版死活调不出来，白白浪费时间。

5.4 一点心得：别做“只会抄模版”的人

开源这套东西之后，我心里其实一直很警惕一个问题：如果所有人都直接用模版，那AI视频创作会不会变得千篇一律？后来我想明白了，模版本质上是“语法教科书”，教你的是如何组织描述，而不是“句子本身”。真正厉害的人会用这套模版的五层思维去解读任何一条新视频，然后拆出自己的表达方式。模版不是终点，它是你观察世界的棱镜。

我自己最大的收获，反而是拆解过程中被迫提升的“视频直觉”。以前我看一条AI视频，只会说“好看”；现在我会下意识地思考它的镜头怎么动、主体与环境怎么互动、光影变化的时间点在哪里。这种直觉会在你未来创作时自动涌现，哪怕你早就忘了那些YAML文件的细节。所以我真心建议每一个拿到这463个Skill的人，先别急着生成视频，先挑十条拆解数据认真读三遍，把五层结构刻进脑海中。

最后再分享一个操作上的小技巧：你完全可以把这套开源仓库当成你的“灵感抽奖机”。每次创作前，不要刻意去找某个固定Skill，而是随机从索引表里抽一个场景类和一个运动类的Skill，先看它们的组合效果，再逐步调整。这种“随机组合法”帮我产出了好几个自己平时根本不会想到的片子，也让我彻底摆脱了对着空白提示词框发呆的窘境。希望这套开源模版也能帮你打开新的创作思路，哪怕只被用上一次，这事就没白做。