最近几个月我一直在折腾 AI 视频剪辑的自动化流程。从最早直接用对话窗口丢提示词到后来尝试各种 Agent 串联最终让我真正觉得“能稳定复现、能交到项目里用”的反而是很多人忽略的 Skill 机制。这篇文章不是来介绍某个新产品的而是想把我已经反复跑通的 3 个自动化剪辑 Skill 拆开讲清楚它们解决什么问题、目录结构长什么样、每一步怎么执行、以及实际运行时最容易卡在哪儿。先给一个明确判断AI 自动化剪辑的关键不在于大模型多聪明而在于你有没有把剪辑经验固化成一套可复用的 Skill。如果你还在靠每次写一大段提示词让 AI“自由发挥”那结果不稳定是必然的。Skill 的本质是把剪辑师的工作流程、判断标准、输出格式全部封装成结构化指令让 AI 每次都在同一套规则下干活。这篇文章适合这几类读者已经在用 AI 辅助剪辑但觉得结果不稳定、每次都要反复调提示词的人。想把素材筛选、脚本分镜、时间线生成这些重复劳动交给自动化但不知道从哪下手的人。刚接触 Skill 概念想知道它和普通提示词到底有什么区别的人。我会从基础概念讲起然后逐个拆解我跑通的 3 个 Skill最后给出完整目录结构和代码示例。你可以直接把我的目录结构拿走改不用从零开始。先说明一点下面所有配置都基于 Skill 机制的通用水位具体工具版本以你手头的实际环境为准但核心思路是通用的。1. 先搞清楚Skill 和普通提示词到底差在哪很多人以为 Skill 就是“把提示词写长一点”这是一个很大的误解。普通提示词是一次性的对话上下文你给 AI 一段文字它基于这段文字生成回复聊完就结束了。Skill 则是一套可复用的执行规范它不只是告诉 AI“做什么”还规定了“按什么流程做”“每个步骤输出什么格式”“遇到异常怎么处理”。打个比方你让一个实习生帮你剪辑普通提示词相当于口头交代一句“把这些素材剪成一条片子”实习生可能理解成各种样子。Skill 则相当于你给他一份《剪辑操作手册》里面写了素材筛选标准、脚本拆解规则、时间线结构要求、导出参数甚至包括常见的错误处理方式。实习生只要按手册执行结果就稳定得多。在当前的 AI 工具生态里Skill 一般以目录的形式存在核心入口是一个SKILL.md文件。这个文件用结构化 Markdown 描述技能的目标、适用场景、执行步骤、输入输出格式。工具加载 Skill 后会把里面的指令作为系统级的上下文注入让模型在固定规则下完成工作。有的实现还支持配套脚本比如用 Python 读取视频元数据、调用 FFmpeg 完成转码这些脚本可以放在 Skill 目录下的scripts/文件夹中。更关键的一点是Skill 可以被多个 Agent 或工作流重复加载。你今天让 AI 做一条带货视频明天做一条科普视频只要剪辑的底层流程一致就复用同一套 Skill。改动一次规则所有后续任务都生效。这种“一次封装、处处复用”的特性才是 Skill 真正降低剪辑成本的原因。2. 我跑通的 3 个 Skill 分别是什么我做的这 3 个 Skill是一条完整的自动化剪辑流水线覆盖了从拿到原始素材到生成粗剪时间线的核心环节。第一个是素材筛选 Skill我把它命名为ShotFilter。它的工作是面对几十上百条原始视频片段自动判断哪些片段是有效素材哪些是废镜头。所谓有效不只是“画面不黑、声音不杂”还包括构图有没有明显问题、镜头有没有大幅抖动、主体是否完整入画。这个 Skill 会调用视频分析脚本从时长、分辨率、帧率、音轨信息入手再结合模型对抽帧画面的视觉判断给出“可用/疑似可用/不可用”的标签并附上理由。第二个是脚本拆解 Skill命名为ScriptToStoryboard。输入是一段视频文案脚本输出是一个结构化的分镜表。它会把文案按语义拆成多个镜头每个镜头分配景别、时长、画面描述、字幕文案和备注。这个 Skill 解决的核心痛点是剪辑师拿到文案后往往要花大量时间把文字转成镜头语言而这个转换过程恰恰是最能体现经验的地方。我把判断标准写进 Skill 规则里比如一段话超过多少字就该拆成两个镜头、什么位置的停顿适合切特写、什么语境下适合用空镜过渡。第三个是时间线生成 Skill命名为TimelineBuilder。它接收分镜表作为输入生成一个可以直接导入剪辑软件的 XML 或 EDL 文件同时生成对应的剪辑指令清单。这个 Skill 不需要 AI 自己去渲染视频而是把分镜表中的每个镜头和素材筛选结果做匹配在时间线上排好顺序、设定好每段片段的入点出点并标注需要添加转场或特效的位置。粗剪的效率提升主要靠这一步。这三个 Skill 的依赖关系是这样的原素材先经过 ShotFilter 筛选得到可用素材清单文案脚本经过 ScriptToStoryboard 拆解得到分镜表最后 TimelineBuilder 把素材清单和分镜表做匹配产出可直接用的时间线文件。我实际跑通后的感受是最难的并不是让 AI 生成某个具体片段而是让这三个环节之间的数据格式能对齐。所以我在每个 Skill 里都严格定义了输出格式这一步非常重要。3. Skill 目录结构与输入输出约定在动手写规则之前先把目录规范定下来。下面是我常用的 Skill 组织方式skills/ ├── shot-filter/ │ ├── SKILL.md │ ├── scripts/ │ │ ├── probe_video.py │ │ └── check_frame.py │ └── assets/ │ └── criteria.md ├── script-to-storyboard/ │ ├── SKILL.md │ └── assets/ │ └── shot_types.md └── timeline-builder/ ├── SKILL.md └── scripts/ └── build_edl.py每个 Skill 目录下的SKILL.md是入口文件里面用name、description、when_to_use、instructions等字段来描述这个技能。scripts/目录存放可执行的辅助脚本比如用 FFprobe 探测视频基本信息、用 Python 处理 EDL 文本。assets/目录存放被引用的规则文档比如判断素材好坏的详细标准、景别定义表。关于输入输出我会为每个 Skill 定义一个明确的契约也就是输入是什么格式、输出是什么格式。以 ShotFilter 为例输入一个目录路径里面是要分析的视频文件也可以是一个 CSV 清单包含文件名和路径。输出一个 JSON 文件每条素材包含file_name、duration、resolution、has_audio_track、verdict、reason字段。把输入输出格式定死的好处是后续可以在多个 Skill 之间传递数据组合成更长的自动化流水线。AI 在处理时不需要猜测该输出什么直接按模板填充即可。这在工程上非常关键因为自动化的价值不是某个环节单点变快而是整个链路能稳定打通。4. 环境准备我用了哪些工具和依赖先把环境说清楚。我的运行环境是 macOS终端使用 zshPython 版本为系统自带的 Python 3额外安装了以下 Python 包openai用于调用大模型接口做画面分析和文本分析。ffmpeg-python封装 FFmpeg 命令用于视频抽帧和元数据读取。pydantic做输出数据的结构校验避免模型返回的 JSON 字段缺失。如果你需要调用视觉模型来分析视频帧还需要准备一个可用的模型 API Key。注意不要把 Key 写死在 Skill 脚本里建议通过环境变量传入比如export LLM_API_KEYxxxx。这里也提醒一下你的 Key 要妥善保管不要提交到公开仓库。FFmpeg 本身也需要安装。如果你用的是 macOS 且装了 Homebrew可以直接执行brew install ffmpeg测试 FFmpeg 是否安装成功ffmpeg -version如果输出中包含版本信息说明安装正常。另外视频分析脚本会调用 FFprobe 获取视频流信息。FFmpeg 安装后 FFprobe 一般会同时可用可以通过下面命令确认ffprobe -version关于 AI 工具的选择我使用的是支持 Skill 机制的 CLI 编程工具比如 Claude Code、Codex CLI 这类工具都开始支持类似机制。不同工具对 Skill 的加载方式略有差异有的通过技能名的语法引用有的通过自动扫描目录加载。具体以你使用的工具文档为准。下面我示例中会采用通用的 Markdown 指令格式任何支持结构化技能注入的工具都可以参考。5. 第一个 Skill 的完整实现素材筛选5.1 构建 SKILL.md 规则文件我创建skills/shot-filter/SKILL.md内容如下--- name: shot-filter description: 批量分析视频素材判断画面是否可用输出带 verdict 标签的 JSON 清单。 when_to_use: 当用户提供一批原始视频素材需要筛选出有效片段时使用。 --- # Shot Filter 你的任务是对输入目录中的视频素材逐条分析输出标准 JSON。 ## 分析步骤 1. 遍历输入目录下的所有视频文件支持 mp4、mov、mkv。 2. 使用 scripts/probe_video.py 获取每个视频的时长、分辨率、帧率、音轨信息。 3. 对每个视频在时间轴中段抽取 3 帧画面调用视觉模型判断画面质量。 4. 结合元数据和画面判断给出 verdict。 ## 判断标准 - verdict 为 usable 的要求时长不少于 3 秒画面无明显抖动主体完整入画。 - verdict 为 needs_review 的要求画面基本清晰但存在轻微晃动、光线不均或遮挡。 - 不属于以上情况的标记为 rejected并写明原因。 ## 输出格式 只输出 JSON 数组不要输出额外说明。示例 [ { file_name: take_01.mp4, duration: 12.3, resolution: 1920x1080, has_audio_track: true, verdict: usable, reason: 构图完整画面稳定音轨正常 } ]这里我将 AI 的判断标准显式写入进 SKILL.md这样模型不会再凭自己的感觉随意评价。特别要注意最后一句“只输出 JSON 数组”避免模型在输出里夹杂解释性文字导致下游脚本解析失败。5.2 编写视频探测脚本接下来创建skills/shot-filter/scripts/probe_video.py用 FFprobe 获取视频的基础信息#!/usr/bin/env python3 import json import sys import subprocess def probe_video(file_path: str) - dict: cmd [ ffprobe, -v, quiet, -print_format, json, -show_format, -show_streams, file_path ] result subprocess.run(cmd, capture_outputTrue, textTrue) if result.returncode ! 0: return {error: result.stderr.strip()} data json.loads(result.stdout) video_stream None audio_stream None for stream in data.get(streams, []): if stream.get(codec_type) video and video_stream is None: video_stream stream elif stream.get(codec_type) audio and audio_stream is None: audio_stream stream duration float(data.get(format, {}).get(duration, 0)) return { file_name: file_path.split(/)[-1], duration: round(duration, 2), resolution: f{video_stream.get(width, 0)}x{video_stream.get(height, 0)}, has_audio_track: audio_stream is not None } if __name__ __main__: for path in sys.argv[1:]: print(json.dumps(probe_video(path), ensure_asciiFalse))这个脚本本身不复杂但它把“获取视频元信息”这一步从模型能力中抽离出来变成确定性执行避免模型对时长和分辨率产生幻觉。在实际项目中我更推荐这种混合方式能用脚本确定性算出来的就不要让模型用视觉去猜。5.3 调用方式与运行验证当 Skill 被加载后你可以在支持的 CLI 工具中这样调用shot-filter /path/to/raw_materials工具会分析/path/to/raw_materials目录下的视频文件并返回 JSON 格式的筛选清单。如果希望在单条命令中看到结果可以直接让工具读取脚本输出并生成最终 JSON。我实际运行时的预期输出大致如下[ { file_name: take_01.mp4, duration: 12.3, resolution: 1920x1080, has_audio_track: true, verdict: usable, reason: 构图完整画面稳定音轨正常 }, { file_name: take_02.mp4, duration: 2.1, resolution: 1280x720, has_audio_track: false, verdict: rejected, reason: 时长不足3秒且缺少音轨 } ]判断这个 Skill 是否真正生效不是看它有没有输出 JSON而是看两个点第一对于明显不合格的素材比如时长过短、没有音轨它是否稳定给出rejected第二对于画面质量相近的素材它给出的 verdict 是否一致。如果你发现同一个素材不同次调用结果不同说明判断标准没有写清楚需要回到SKILL.md里补充更细的规则。6. 第二个 Skill 的完整实现脚本拆分为分镜6.1 分镜表的结构设计分镜表是连接“文案”和“成片”的中间产物。在自动化剪辑里分镜表必须能够被下游程序直接解析所以不能用自由文本而要用结构化格式。我定义的分镜表是一个 JSON 数组每个元素代表一个镜头[ { shot_id: 1, narration: 大家好今天我们来聊聊如何提高视频剪辑效率。, visual: 主播正面中景背景为工作台, shot_type: medium, duration: 5.0, subtitle: 今天我们来聊聊如何提高视频剪辑效率, notes: 开场镜头背景干净光线充足 } ]字段说明shot_id镜头序号从 1 开始递增。narration这个镜头对应的解说词原文。visual画面内容描述方便素材匹配。shot_type景别如close-up、medium、wide、cutaway。duration预计时长单位为秒。subtitle用于渲染字幕的文本一般比解说词更精简。notes剪辑备注比如是否需要转场、是否需要背景音乐切入点。为什么要用 JSON 而不是直接输出表格因为后续 TimelineBuilder 需要读取分镜表来生成时间线JSON 可以直接被 Python 解析而表格还需要额外转换。一句话自动化流水线里数据格式统一比人类阅读友好更重要。6.2 SKILL.md 中的拆解规则下面是skills/script-to-storyboard/SKILL.md的关键内容--- name: script-to-storyboard description: 将视频文案脚本转换为结构化的分镜表 JSON。 when_to_use: 用户提供文案脚本需要生成剪辑分镜时使用。 --- # Script to Storyboard 将输入文案按语义拆分为多个镜头并输出分镜表 JSON。 ## 拆解规则 1. 每段语义完整的话对应一个镜头通常一段话的字数不超过 80 字超过则拆分为多个镜头。 2. 文案中的“首先/然后/最后”等逻辑词通常是切换镜头的信号。 3. 如果文案描述了具体动作比如“点击按钮”“打开软件”优先使用特写或近景。 4. 如果文案是背景介绍或总结可以使用中景或全景。 5. 每个镜头时长建议在 3 至 8 秒之间根据解说词长度估算语速按每分钟 220 字计算。 ## 输出格式 只输出 JSON 数组每个元素包含 shot_id、narration、visual、shot_type、duration、subtitle、notes 字段。这里我把“语速按每分钟 220 字计算”作为一个可复用的经验值写进规则。虽然不同主播语速不同但剪辑时有一个基准值就能自动估算时长后续再人工微调比从零开始快很多。你也可以根据自己的内容类型调整比如知识口播类可以稍快教程操作类往往需要留出操作演示的时间。6.3 运行示例输入文案示例大家好欢迎来到本期教程。今天我们要讲的是如何使用 AI 工具优化剪辑流程。首先我们需要准备一批素材。其次用脚本对素材进行批量分析。最后把生成的结果导入剪辑软件。预期输出节选[ { shot_id: 1, narration: 大家好欢迎来到本期教程。, visual: 主播正面中景背景为工作台, shot_type: medium, duration: 3.0, subtitle: 欢迎来到本期教程, notes: 开场镜头 }, { shot_id: 2, narration: 今天我们要讲的是如何使用 AI 工具优化剪辑流程。, visual: 主播近景语气强调 AI 工具, shot_type: close-up, duration: 4.0, subtitle: 使用 AI 工具优化剪辑流程, notes: 可以配一个 AI 工具界面截图 } ]这里有个值得注意的点模型的输出并不总是完全符合预期有时会遇到shot_type取值不在预设列表内、duration明显不合理之类的情况。为了不让脏数据进入下游我会在接收分镜表后加一个简单校验比如用 Python 检查字段是否齐全、时长是否为数字。只要校验不通过就重新调用 Skill 生成一次直到通过为止。这个做法在工程上叫做“防御式处理”在 AI 流程里尤其重要因为你永远要假设模型的输出可能不符合规范。7. 第三个 Skill 的完整实现从分镜表到时间线文件7.1 EDL 格式简介时间线生成 Skill 的最终产物是一个 EDLEdit Decision List剪辑决策列表文件。EDL 是一种纯文本格式剪辑软件可以导入并重建时间线。一个最简单的 EDL 片段长这样TITLE: AUTO_CUT_PROJECT FCM: NON-DROP FRAME 001 AX 00:00:01:00 00:00:05:00 00:00:00:00 00:00:04:00逐行解释一下TITLE项目名称。FCM时间码制式NON-DROP FRAME表示无丢帧时间码。001剪辑序号。AX源素材卷号这里用AX表示来自自动匹配的素材。00:00:01:00 00:00:05:00源素材的入点和出点。00:00:00:00 00:00:04:00时间线上的入点和出点。EDL 的历史非常悠久几乎所有专业剪辑软件都支持导入是一种很稳妥的交换格式。如果你用的剪辑软件对 EDL 支持不太好也可以让 Skill 输出 CSV 或 JSON 格式的剪辑指令清单人工在软件里快速照着排。这里我以 EDL 为例因为它的自动化程度最高。7.2 TimelineBuilder 的 SKILL.mdskills/timeline-builder/SKILL.md核心内容--- name: timeline-builder description: 根据分镜表和素材清单生成 EDL 时间线文件。 when_to_use: 已有素材筛选结果和分镜表需要生成时间线时使用。 --- # Timeline Builder 你的任务是将分镜表和可用的素材片段进行匹配生成 EDL 文件。 ## 执行步骤 1. 读取素材筛选结果 JSON只使用 verdict 为 usable 或 needs_review 的素材。 2. 读取分镜表 JSON。 3. 根据 visual 描述和素材文件名中的关键词如 take_01、scene_02进行匹配。 4. 按 shot_id 顺序排列设置入点出点。 5. 输出 EDL 文本直接写入到输出文件。 ## 匹配规则 - 如果分镜表的 visual 包含“特写”或“近景”优先匹配画面里有主体面部或手部特写的素材。 - 如果分镜表指定为“空镜”或“cutaway”优先匹配风景、城市空镜头素材。 - 如果无法找到完全匹配的素材用 resources 中 notes 为“可替代”的片段填充并在输出的 EDL 文件名上添加 _with_placeholder 后缀。7.3 生成 EDL 的 Python 脚本下面是一个简化版的 EDL 生成脚本#!/usr/bin/env python3 import json import sys def time_to_edl(seconds: float) - str: hours int(seconds // 3600) minutes int((seconds % 3600) // 60) secs int(seconds % 60) frames int((seconds - int(seconds)) * 25) return f{hours:02d}:{minutes:02d}:{secs:02d}:{frames:02d} def build_edl(shots, output_path): lines [TITLE: AUTO_CUT_PROJECT, FCM: NON-DROP FRAME, ] total_time 0.0 for idx, shot in enumerate(shots, start1): src_in shot.get(source_in, 0) src_out src_in shot[duration] tl_in total_time tl_out total_time shot[duration] lines.append( f{idx:03d} AX {time_to_edl(src_in)} {time_to_edl(src_out)} f{time_to_edl(tl_in)} {time_to_edl(tl_out)} ) lines.append(fM2 VIDEO {shot.get(shot_type, cut)}) lines.append() total_time tl_out with open(output_path, w, encodingutf-8) as f: f.write(\n.join(lines)) return output_path if __name__ __main__: shots_path sys.argv[1] output_path sys.argv[2] with open(shots_path, r, encodingutf-8) as f: shots json.load(f) result build_edl(shots, output_path) print(fEDL written to {result})将分镜表保存为storyboard.json后运行python3 scripts/build_edl.py storyboard.json output.edl如果一切正常你会得到output.edl可以用支持 EDL 导入的剪辑软件打开。如果你手头没有这类软件也可以用文本编辑器打开检查时间码是否连续。这个 Skill 跑通后从“分镜表”到“粗剪时间线”的转换就不再需要手动操作了。8. 把 3 个 Skill 串成一条自动化流水线前面 3 个 Skill 是独立的但它们真正的威力在于串联。在实际项目中我通常用下面这样的 Shell 脚本把它们串起来#!/bin/bash set -e RAW_DIR/path/to/raw_materials SCRIPT_TEXT/path/to/script.txt WORK_DIR/tmp/auto_cut mkdir -p $WORK_DIR # Step 1: 素材筛选 shot-filter $RAW_DIR $WORK_DIR/shot_filter.json # Step 2: 脚本拆解为分镜 cat $SCRIPT_TEXT | script-to-storyboard $WORK_DIR/storyboard.json # Step 3: 生成时间线 timeline-builder $WORK_DIR/storyboard.json $WORK_DIR/shot_filter.json --output $WORK_DIR/project.edl echo 所有步骤已完成时间线文件在: $WORK_DIR/project.edl这段脚本的作用是把三个 Skill 按顺序串起来。这里我用技能名的语法来表示调用对应 Skill如果你使用的工具不是这种语法只要按文档改成对应的加载方式即可。关键点在于每个步骤的输出都保存在WORK_DIR下后续步骤通过文件路径读取这样即使中间某一步失败你也可以从断点继续不需要从头再跑。对于较长的视频项目这个能力很实用。把这个脚本保存为auto_cut_pipeline.sh然后执行chmod x auto_cut_pipeline.sh ./auto_cut_pipeline.sh当最后出现EDL written to /tmp/auto_cut/project.edl时说明流水线已经完整跑通。9. 常见问题与排查方法我在实际跑这几个 Skill 时遇到过不少问题下面列出的几个最有代表性问题现象可能原因排查方式解决方案素材筛选时视频全部被标记为 rejected视频路径错误或文件损坏FFprobe 返回异常手动执行ffprobe -v quiet -print_format json -show_format -show_streams 文件路径查看返回内容修正路径或替换正常视频文件模型输出的 JSON 格式不合法输出包含多余说明文字或 JSON 字段缺失将模型回复保存在文件中用python3 -m json.tool校验在 SKILL.md 中强调“只输出 JSON”并增加输出样例分镜表时长和实际文案长度不匹配语速假设与实际情况差异较大使用已知文稿和成片时长反推实际语速调整 SKILL.md 中的语速参数或者增加事后时长校准生成的 EDL 在剪辑软件中打不开时间码帧率与项目设置不一致查看剪辑软件的时间和项目设置在 build_edl.py 中根据项目帧率调整 frames 计算逻辑同一个素材两次筛选结果不同判断标准不够具体模型自由度太大对比两次输出找出不稳定字段在 SKILL.md 中细化判断标准增加更多示例这里最值得强调的一点是模型的输出要当作“不稳定数据”来处理。每两个 Skill 之间的数据交换都应该有校验环节。你可以用 pydantic 定义输出模型也可以简单写一个validate.py脚本检查关键字段。不要假设模型每次都输出正确这是所有 AI 自动化流程里最重要的工程思维。10. 最佳实践与工程建议在这个项目里我总结了几条可以复用的经验供大家参考。第一Skill 的粒度不要太大。我见过有人试图写一个“超级 Skill”来完成所有剪辑工作结果规则太多模型执行时经常前后矛盾。更好的做法是像我这 3 个 Skill 一样每个只负责一个单一职责筛选、拆解、生成时间线。单个 Skill 的规则控制在 10 条以内效果最稳定。第二把确定性计算和模型判断分开。能用脚本计算出来的信息比如视频时长、分辨率、帧率不要依赖模型通过视觉去估算。模型的不确定性应该只用在真正的判断环节上比如“画面构图是否完整”“这段文案适合什么景别”。这种混合架构既提高了准确性也降低了 token 消耗和延迟。第三输出格式必须严格定义。每个 Skill 的输出都要有清晰的 schema最好是 JSON并且字段名、类型、取值范围都写清楚。你可以在 SKILL.md 里直接给一个完整的输出样例模型通常会照着样例复刻格式比单纯文字描述更可靠。第四给每个 Skill 都写 assets 文档。assets/shot_types.md、assets/criteria.md这些文档可以承载更详细的背景知识避免 SKILL.md 过长。模型在需要时可以从目录中读取这些附件不需要时不会浪费上下文窗口。对长文本场景尤其有用。第五版本管理一定要做。Skill 的规则可能经常调整建议把整个skills/目录放进 Git 仓库。每次改动都提交一次整理后可以比较不同版本对最终剪辑结果的影响。我踩过的一个坑是改了一次判断标准后素材筛选结果变化很大但没有版本记录根本不知道改了什么导致差异。11. 这 3 个 Skill 目前的天花板和优化方向说说我对这套方案局限性的判断。当前最大的瓶颈不是模型能力而是素材匹配的准确度。TimelineBuilder 在匹配“分镜描述”和“实际素材”时依赖的是文件名关键词和 visual 描述的文本相似度但在真实项目中拍摄素材的文件名往往没有任何语义信息比如00123.MP4。这种情况下匹配准确率会明显下降。要解决这个问题需要在 ShotFilter 阶段让视觉模型给每个素材打上内容标签比如“人物中景-看镜头”“手部特写-操作键盘”“空镜-街道夜景”然后在匹配阶段用标签去检索。这也是我下一步打算优化的方向。另一个优化方向是增加音频分析。目前的 3 个 Skill 只看画面和文案没有分析原素材中的音频质量。比如某个片段画面很好但背景噪音很大或者说话声音爆音了这需要音频分析脚本介入。可以在 ShotFilter 里增加一个analyze_audio.py使用 FFmpeg 提取音频响度数据或者直接调用音频模型做声音质量评分。这样筛选结果会更有参考价值。12. 收起说明我写这篇文章不是为了告诉你“AI 已经完全取代剪辑师”而是想提供一个可落地的思路把剪辑经验拆成有边界的、可复用的 Skill让 AI 在固定规则里帮你完成重复度较高的工作。素材初筛、文案分镜、时间线生成这三个环节恰恰是剪辑流程中最适合自动化的部分也是我目前跑通后收益最大的三个环节。如果你想动手试我建议不要贪多先只做一个最痛点的 Skill。比如你发现自己每天都在重复做“把一堆素材挑出可用的”那就先抄 ShotFilter 这个目录把判断标准改成你自己的习惯跑通一天后自然就能感受到 Skill 的价值。之后再扩展到分镜和时间线。每个 Skill 目录下的代码和规则建议都保存到自己的代码仓库里。自动化剪辑这条路后面拼的不是谁的提示词写得更华丽而是谁把自己的工作方法沉淀得更系统。