如果你做过视频剪辑大概率有过这种体验素材越攒越多剪辑时间却越来越长。我最近把整个剪辑流程拆成了 AI 自动化剪辑场景下的 3 个 Skill跑通之后最明显的变化不是“不用剪了”而是我终于可以把重活交给工具把决策留给自己。这篇文章不聊概念只聊我实际跑通 3 个 Skill 的过程每个 Skill 解决什么问题、目录怎么设计、脚本怎么写、又在哪里最容易翻车。先说结论AI 自动化剪辑的难点从来不是工具不会转码、不会分割而是“剪辑决策”一直没有被结构化。Skill 恰好是把人的判断过程变成模型可执行的流程再用脚本承接精确操作。跑通之后你会发现真正麻烦的不是单个功能而是输入约定、时间码对齐、输出校验以及异常时的恢复路径。1. 先搞清楚 Skill 到底是什么它对自动化剪辑意味着什么现在很多 AI 编码工具里都在讲 Skill但这个词在不同语境下含义不太一样。我第一次接触时也以为它是一种更高级的提示词模板跑完几个流程之后才理解它更像是一个“技能包”。1.1 不是插件不是工作流而是一个技能包在常见的 AI Agent 使用方式里Skill 通常是一个独立目录里面至少有一个SKILL.md文件描述这个技能什么时候用、输入要求是什么、执行步骤是什么、输出格式是什么。旁边可以放脚本、模板、示例资源甚至可以放一个小型校验工具。它和普通提示词的区别在于提示词是一次性对话中的上下文而 Skill 是能被保存、复用、按需加载的完整工作说明书。它也不只是 “工作流”因为工作流往往强调固定节点而 Skill 更强调“模型 脚本 模板”的组合模型负责理解意图脚本负责精确计算模板负责统一输出。对剪辑场景来说这非常关键。因为视频剪辑里有很多操作需要精确到秒、精确到文件路径、精确到编码参数。你让大模型写一句“帮我剪掉开头 5 秒”它可能给一个大概命令但如果你给它一个 Skill里面有约定好的时间码格式、素材命名规则、输出目录结构再配一个解析脚本它就能稳定执行而不是每次从零开始猜。1.2 为什么过去自动化剪辑很难过去要实现剪辑自动化最不缺的就是工具。FFmpeg 能切割、能拼接、能转码whisper这类语音转文字工具能生成字幕ProRes、H.264、H.265 的转换也都有成熟方案。但“工具会操作”和“系统会自动剪辑”是两回事。真正的瓶颈在于“剪辑决策”没有被数字化。什么叫剪辑决策就是这一段留不留下一句接哪里停顿要不要剪掉画面信息不够时是不是要切到另一个机位字幕放在哪个时间点出现。传统脚本可以根据时间码批量执行操作但它不知道这些时间码为什么是合理的。所以过去的自动化更多停留在“批处理”层面把固定位置的片头片尾切掉、把音量统一、把字幕压进画面。一旦素材内容是变化的结构是不同的剪辑判断就无法靠一条命令完成。1.3 Skill 拆掉了“从想法到动作”之间的翻译层Skill 真正改变的不是剪辑工具而是大模型和精确执行之间的协作方式。它能把你脑中“我这里应该留一段停顿然后接一句总结”的模糊想法转成“从第 12.5 秒到第 25 秒保留原声画面对应主播正面特写”的结构化描述再进一步生成剪辑命令。这个翻译层正是过去自动化剪辑最难做的地方。机器擅长处理确定规则但剪辑过程中有大量经验判断。Skill 不是一个万能魔法它只是把这些经验判断拆成了模型可以遵循的分支和步骤。也就是说你不需要让模型凭空理解“这个段落节奏太拖”而是可以在 Skill 里定义如果一段语音后停顿超过 1.5 秒就生成一个候选剪切点。这类规则当然有些粗糙但它把不可计算的“感觉”变成了可以验证的“条件”。这是我认为 Skill 对自动化剪辑最有价值的贡献。2. 跑通第一个 Skill把素材变成可复用的结构化分镜我做的第一个 Skill 不负责剪任何画面只负责把素材变成结构化的分镜表。因为后续所有流程都要基于一个可靠的输入如果这一步不做干净后面每一步都会连锁出错。2.1 先做的是给 AI 一份输入约定这里最忌讳的是把一堆素材丢给模型然后问“你看着剪吧”。模型会被大量无结构信息淹没输出也不会稳定。所以我把输入分成三类转写文本录音或视频里的口播内容我提前用语音转文字工具生成好。素材清单每个素材的文件名、时长、内容简介、可用片段范围。项目配置视频比例、字幕模板、输出分辨率、目标平台。这些信息不一定都要放在同一份文件里但 Skill 必须在开头有一个明确的“输入检查”步骤。我通常会让脚本先读素材清单检查是否存在缺失文件再让模型逐段阅读转写文本最后才生成分镜。实际测试时输入格式花了大量时间也是第一个翻车点。如果素材清单里文件名有中文空格或者扩展名大小写不一致后续匹配素材时就会出现找不到文件的错。前期在输入约定阶段多做校验比后期在脚本里做字符串清洗省事得多。2.2 输出强格式比多做几个提示词更重要第一个 Skill 的核心输出是一份分镜表。我一开始让模型输出 Markdown 表格后面发现解析起来很痛苦。后来改为输出 JSON每条分镜包含以下字段{ scene_id: 2, start: 12.5, end: 25.0, visual: 主播正面特写镜头推近, subtitle: 所以我们需要先解决输入问题, source: episode_03_take1.mp4 }start和end统一用秒避免模型里出现00:01:30和90并存的情况。source字段关联到原始素材文件后续脚本才能知道这一段该从哪里截取。输出强格式的意义不只是方便解析更重要的是逼着模型把模糊判断固定在可验证的结构里。如果模型自己都说不清这一段是从哪一秒到哪一秒那它后面生成剪辑命令时也一定会出错。与其事后反复追问不如一开始就让它按 JSON 模板填充。2.3 目录结构一个 SKILL.md 加一个脚本我设计的第一个 Skill 长得像一个最小的软件工程目录clip-skill/ ├── SKILL.md ├── scripts/ │ ├── check_inputs.py │ └── build_shotlist.py └── assets/ └── output_template.jsonSKILL.md里写清楚这个 Skill 的定位然后用一段类似伪代码的结构描述执行流程name: 视频分镜表生成 description: 根据转写文本和素材清单生成结构化分镜表 when: 用户提供素材目录和转写文档 input: - transcript.txt - materials.csv - project.json output: - shotlist.json steps: 1. 读取 materials.csv检查素材是否存在 2. 读取 transcript.txt按段落拆分 3. 逐段生成 start/end/visual/subtitle 4. 输出 shotlist.json刚开始不用把这个文件写得很复杂关键是执行步骤要能复现。模型不一定会严格遵守每一条但有了这个框架它的自由发挥空间会被压缩很多。2.4 为什么一定要先小批量验证这个 Skill 写完后我第一件事不是让它处理一整期节目而是拿了一段 10 分钟的素材试跑。验证点有三个生成的分镜数量是不是和转写段落基本一致。每一条的start和end是否落在素材总时长内。JSON 文件能不能被下一个脚本正常读取。小批量验证的核心目的是尽早发现结构性问题。如果模型把时间码写成了字符串或者素材名拼错了在 10 分钟素材里很容易定位等到跑 2 小时素材时错误会被淹没在海量输出里你再回头找根因会非常痛苦。这也是我后来总结的一个判断标准任何 Skill 上线前都先跑一个最小样例。如果最小样例都不能稳定通过就别指望它能在更长、更乱、更复杂的真实场景里表现良好。3. 跑通第二个 Skill从分镜表到可执行剪辑命令第一个 Skill 解决的是“剪什么”第二个 Skill 解决的是“怎么剪”。这也是从结构化数据走向真实文件操作的关键一层。3.1 让 AI 写命令不如让 AI 生成脚本参数一开始我尝试过让模型直接输出 ffmpeg 命令。结果发现命令确实能生成但一旦素材路径有空格、参数顺序不对、滤镜链写错命令行就会中断。更麻烦的是模型可能会把-ss放在-i后面导致 seek 行为完全不同最终输出片段时间错乱。所以我调整了思路不要让 AI 直接拼命令而是让 AI 读懂分镜表然后用 Python 脚本批量生成命令。AI 负责的是“决策层”脚本负责“执行层”。这样即使 AI 在决策上有点偏差脚本里的参数模板也能保证格式正确。比如一个裁切片段的最小函数可以写成这样import subprocess def cut_clip(src, start, duration, out): cmd [ ffmpeg, -y, -ss, str(start), -i, src, -t, str(duration), -c, copy, out ] subprocess.run(cmd, checkTrue)这只是一个示例结构真正落地时还需要考虑文件转义、目录创建、错误重试等问题。但思路是确定的把命令拼装放在代码里而不是交给模型临场发挥。3.2 一个解析分镜表并输出命令的示例流程第二个 Skill 的执行流程通常是这样读取shotlist.json按source字段分组。检查每个source对应的素材文件是否存在。对每条分镜用start和end计算时长生成裁切命令。把所有裁切后的片段按scene_id顺序拼接生成 concat 列表。输出一个run_edit.sh或edit_commands.json由人工确认后执行。这里有个容易忽略的点如果你用的是一段完整录像时间码在源文件内是连续递增的那可以直接用-ss和-to定位。但如果你要拼接多个独立素材就需要用 concat demuxerffmpeg -f concat -safe 0 -i list.txt -c copy output.mp4使用 concat 时要特别小心多个片段如果分辨率、帧率、音频采样率不一致-c copy拼接后很可能会出现不同步或黑帧。这时不能盲目复制流而是先统一编码参数或者让 Skill 判断是否需要走重编码分支。3.3 最容易踩坑的三个地方第一个坑是路径和文件名。中文文件名、空格、特殊字符都会让命令行解析出问题。通用做法是脚本里使用shlex.quote或在 Python 里直接用数组传参避免经过 shell 展开。第二个坑是时间码格式不统一。有的素材元数据里有起始时间偏移比如不是从 0 开始。如果你直接用转写结果里的相对时间定位会切错位置。我的经验是在输入阶段就统一成秒并且让脚本输出每一段的真实起止时间方便人工核对。第三个坑是静默片段和字幕绑定。口播视频里经常会有停顿如果你按文本段落切分切出来的片段可能正好卡在停顿上。解决方式不是一次性写完所有规则而是在 Skill 里加入一个后处理步骤检测每段音频的静音区间如果静音超过一定阈值就把剪切点吸附到最近的静音边界。这个后处理不能依赖模型拍脑袋而是要写进脚本里。用 FFmpeg 的silencedetect滤镜可以先跑一遍再把结果生成一份剪切点候选表。让模型在这张表的基础上做选择而不是让它凭空猜测。3.4 参数边界这层 Skill 并不适合做什么这个 Skill 跑通后我一度以为它可以处理所有剪辑需求后来发现要冷静区分边界。它适合做语言类口播视频的粗剪固定机位、单一主播、素材清晰、时间线以说话内容为主。它并不适合做需要复杂调色、动态转场、多机位实时切换、或者强情绪叙事结构的剪辑。那些场景里的决策高度依赖内容语义和审美判断不是靠几组参数能覆盖的。另外如果你的素材本身就是一堆碎片没有清晰命名也没有对应的转写文本这个 Skill 的效果会大打折扣。它擅长的是“把已经整理过的素材按分镜表执行”而不是“从混乱素材里自动发现剪辑点”。4. 跑通第三个 Skill成片质检与自动修复剪完之后很多人的习惯是直接预览播放凭眼睛看有没有问题。单条视频这样没问题但如果要做成批量生产流程就必须让机器先做一遍自动化体检。4.1 剪辑完最该检查的不是画面而是输出文件本身画面内容是否正确模型很难完全判断但文件参数是否合格是非常适合自动化的。成片时长、分辨率、帧率、音轨是否存在、音量是否过载、是否包含字幕流这些都能靠脚本快速读取并给出结论。我做的第三个 Skill 就是一个“质检员”。它不负责欣赏画面只负责确认技术参数是否符合发布标准。这样人在检查时就不用再反复看时间线、拉进度条只需要针对脚本报告里的问题做处理。4.2 用 ffprobe 做体检最常用的工具是ffprobe它可以输出视频文件的详细参数。一条最常见的命令是ffprobe -v quiet -print_format json -show_format -show_streams output.mp4返回的 JSON 里会包含每个流的编码格式、宽度、高度、采样率、时长、码率等信息。接下来可以写一个 Python 脚本提取这些字段并和设定阈值比较import json import subprocess result subprocess.run( [ffprobe, -v, quiet, -print_format, json, -show_format, -show_streams, output.mp4], capture_outputTrue, textTrue, checkTrue ) data json.loads(result.stdout) video_streams [s for s in data[streams] if s[codec_type] video] audio_streams [s for s in data[streams] if s[codec_type] audio] if not video_streams: raise Exception(缺少视频流) if not audio_streams: raise Exception(缺少音频流)这个脚本只是起点但已经能过滤掉大量低级错误。你还可以进一步检查宽高是否和目标平台一致、帧率是否稳定、音轨采样率是否达标、音量响度是否在合理区间。4.3 把“检查-发现-修复-复查”做成循环光有检查还不够最后要形成一个闭环。发现音量过低就自动触发一次响度规整发现字幕没烧录就调用字幕压制脚本发现分辨率不对就重新缩放并转码。我现在用的流程是先用 ffprobe 做一轮体检输出check_report.json。脚本根据规则判断是否通过。如果有问题调用对应的修复脚本。修复完成后再跑一次 ffprobe生成新的报告。只有第二次报告通过才进入人工确认。这套“检查-发现-修复-复查”的循环本质上和软件测试里的持续集成很像。视频剪辑不是一个单次渲染的动作而是一个需要多次校验的生产流程。把校验步骤自动化能大幅减少“导出完才发现音量有问题”的返工率。在音量处理上我通常会做比较保守的设置。以响度标准为例可以先用loudnorm做一次分析再决定增益值。不要直接盲目压低或提高否则会让整段声音变得不自然。不同平台对响度要求不一样需要按自己的发布场景设定参数。4.4 这个 Skill 的适用边界质检 Skill 的规则一旦写死就只适合固定风格的栏目。如果你的视频有时是竖屏、有时是横屏有时有字幕、有时没有有时是多人访谈、有时是单人口播那统一规则就会误报一堆问题。所以我建议把它设计成“预设配置”模式不同栏目加载不同的检查规则。比如口播号检查音量、字幕、时长混剪号检查码率、分辨率、关键帧间隔课程视频检查是否存在音轨、章节是否完整。让 Skill 能识别当前项目类型并加载对应配置比写一个万能检查器可靠得多。5. 从 3 个 Skill 里提炼出的方法论怎么设计自己的 Skill跑通 3 个 Skill 之后我最大的收获不是那一套剪辑流程而是一套可以复用的 Skill 设计方法。无论你是做音频、文档、图片还是视频自动化下面的思路都适用。5.1 一个 Skill 的完整结构我后来把所有 Skill 都按一套结构整理避免越写越乱。核心组件包括名称一眼能看出它做什么。描述说明适用场景和不适用场景。触发条件用户提供什么信息时模型应该加载这个 Skill。输入约定文件格式、字段定义、路径规则。执行步骤从读取输入到产出的完整流程。输出约定结果文件的格式和字段。失败处理如果某一步出错该重试、该跳过、还是该终止并提示人工。其中最容易忽略的是“失败处理”。很多 Skill 只写了顺利路径没想到脚本会报错、文件会缺失、模型会输出不规范数据。一个健壮的 Skill必须在每一步都想清楚“如果这里出问题了系统要怎么办”。5.2 三步法先人工做一遍再拆步骤再包裹想写一个有用的 Skill不需要一开始就设计得很宏大。更推荐这个三步法第一步先完全人工做一遍任务。把自己描述“我拿到一批素材我先看转写文本再找对应片段然后决定哪里剪开”尽量写下来。第二步拆步骤。把上面的描述变成可执行清单比如“按句号拆分文本段落”“每段文本匹配素材文件”“计算段落时间范围”。重点是把模糊判断写成条件判断。第三步把清单装进 Skill 外壳并配合脚本实现。让模型负责执行前两步脚本负责精确计算和文件操作最后再用一个校验脚本把输出检查一遍。我最早跑通的第一个 Skill 其实是反过来的一开始就想着要一个完美目录结果写完很久还在改。反而是先人工做一遍再拆步骤最后才形成完整目录。5.3 怎么判断一个任务该不该写成 Skill不是所有任务都值得做成 Skill。我也试过把一个偶尔才做一次的图片压缩流程做成 Skill结果维护成本比手动操作还高。我的判断标准有四条这个任务是不是高频重复做的输入和输出能不能用文件或结构化文本描述任务里的规则是不是比创意判断更多结果有没有办法自动校验如果四个答案都是“是”那写成 Skill 会很划算。如果只有两三个“是”那更可能只需要写一段提示词或者一个独立脚本。如果全是否那最好还是保持人工处理。做 Skill 不是目的让重复工作可控、可复用才是目的。5.4 长期使用前要补的工程化能力跑通 3 个 Skill 后你可能很快就会遇到新的问题Skill 改坏了怎么办、脚本运行出错怎么排查、文件被误删怎么找回。这些不是 Skill 本身的问题而是工程化能力不足。我会建议长期使用前至少补上四件事一是日志。每个脚本都要记录运行时间、输入文件、输出文件、失败原因。不要等到出错才想起来没有日志。二是版本管理。Skill 目录用 Git 管理每次修改都留下记录。这样改了某条规则导致效果变差可以快速回滚到上一版。三是权限控制。如果 Skill 里包含删除、移动、覆盖文件的操作一定要限定在指定工作目录内。不要把工作目录写死成系统临时目录否则一旦脚本出错影响范围可能超出预期。四是人审节点。AI 自动化流程里最理想的不是“全自动无人值守”而是在几个关键节点保留人工确认。比如裁剪命令生成后先看一眼分镜表再让脚本执行成片质检通过后再人工预览一遍。这样既能享受自动化效率又能避免不可控错误。6. 回到底层Skill 不会取代剪辑师但会改变剪辑工作的分工最后一个问题如果 AI 自动化剪辑已经能跑通分镜、粗剪、质检那剪辑师以后会不会失业我的判断是真正被自动化掉的不是创意而是重复判断。6.1 被自动化掉的不是创意而是重复判断当你在一期视频里反复做“去掉停顿”“统一音量”“切到对应画面”这些操作时你的大脑在高速重复计算。这些计算完全可以交给 Skill 去做。但那些“为什么这句话要保留”“这里的叙事节奏是不是太快”“这个镜头有没有更好的选择”之类的判断依然需要人的审美和经验。Skill 最合适的位置是把人从重复劳动里解放出来而不是替人做创作决策。自动化剪辑越深入人的角色反而越重要因为你需要定义规则、校验输出、处理边界案例。6.2 下一步让多个 Skill 被 Agent 串起来现在我是逐个 Skill 手动触发但已经有越来越多的 AI Agent 支持让模型根据任务描述自动加载多个 Skill。也就是说我可以给 Agent 一个输入“把第三期原始录像剪成 5 分钟口播版”它自己会先加载分镜生成 Skill再加载命令生成 Skill最后加载质检 Skill。这个方向一旦跑通自动化剪辑就不再是“三条脚本链”而是一个完整的生产系统。素材进去成片出来中间没有太多人为干预。但要真正稳定还是得回到每一个 Skill 本身的输入输出约定是否足够清晰。否则 Agent 串起来的不是效率而是一连串错误。6.3 我的建议如果你想尝试 AI 自动化剪辑先从最小的场景开始不要试图一次性覆盖所有视频类型。选一个你最常做的栏目人工做一遍记录步骤然后拆出一个最小的 Skill。先让它在 10 分钟素材上稳定跑通再慢慢扩展。我跑通 3 个 Skill 之后最深的体感是这套流程的价值不在于“省掉了点鼠标的时间”而在于把剪辑经验变成了可以迭代、可以复用、可以交给工具稳定执行的生产资料。你不再需要每次从零开始记住所有参数和坑因为 Skill 已经替你承载了这部分记忆。对你来说真正的门槛不是 Prompt 写得不够好也不是模型不够强而是有没有耐心把自己的工作方式拆解成一套可执行的流程。这是 AI 时代里比学会某个工具更值得长期投入的能力。