从自媒体那边收到的素材，十有八九是直播回放、录屏、会议录像这种“大块头”。真正能发出去的成片，可能只是其中几十秒到几分钟的高光时刻。以前我的做法是老老实实打开剪辑软件，导入、拖时间轴、切一刀、导出，一单素材下来少说五分钟，多则半小时。后来我把常用处理逻辑整理成一套规则，让 AI 编码助手（Cursor/Codex 这类工具）通过调用 ffmpeg 帮我裁切，一句话就是一个成品。这大概就是标题里「ffmpeg-skill」的真实含义：不是某个神奇插件，而是把剪辑师的重复劳动封装成“AI 能读懂的说明书”。这篇文章就围绕这套玩法展开，适合每天和视频素材打交道、又不想被困在时间轴里的自媒体创作者，也适合想给 AI 编程助手扩展实用技能的技术型内容从业者。1. 为什么视频裁切值得做成一个 skill1.1 自媒体剪辑的真实痛点：不是不会剪，而是重复劳动太多刚开始接触视频处理时，我也觉得命令行剪辑特别“反人类”，明明在 Pr 或者剪映里拉两下就能完成的事，凭什么要去背参数。实际做过几轮批量处理后，我才意识到编辑器里那些看似简单的操作，背后藏着一堆隐性成本：软件启动要等、素材导入要缓存、时间轴预览会卡、导出还要重新编码一遍。你要是连续处理十条素材，每条都走这套流程，时间基本就在等待里耗光了。更麻烦的是直接剪辑软件处理长视频。一段两小时的直播回放导入进去，预览就掉帧，拖动时间轴等个半天，裁到一半电脑风扇狂转，导出又花十几分钟。而 ffmpeg 处理同样的任务，很多情况下用的是 stream copy 模式，几乎不重新压缩视频内容，只做“切一刀”这么简单的事，速度可以做到和磁盘读写差不多，秒级完成。这种差异在高分辨率素材上尤其明显：4K 视频重编码意味着要遍历每一帧，而直接裁剪可能只要复制对应字节即可。我理解的自媒体剪辑痛点，其实从来不是说“你不会剪漂亮的转场”或者“你不懂调色曲线”，而是那些极度琐碎、高度重复、又没有创造性的预处理动作：统一去片头、裁掉开头多余的黑屏、掐掉结尾的杂音、把一段长素材切成几段备用。这些活让剪辑软件来做就是杀鸡用牛刀，让 ffmpeg 来做又需要记参数。所以把它们整理成 skill 指令，交给支持工具调用的 AI 助手区执行，是顺手又高效的选择。1.2 从“手动拉时间轴”到“一句话指令”的关键转变促成这个转变的核心，在于 AI 编程助手已经不只是“代码补全器”了。以 Cursor、Codex 为代表的工具，能理解自然语言指令，可以读写终端，可以查看文件系统，甚至可以执行命令并观察输出结果。换句话说，你把需求描述得足够清楚，它就能通过调用命令行工具完成实际任务，而不是只给你一段建议让你自己复制粘贴去跑。这时候 skill 的价值就体现出来了。所谓 skill，本质上是一份结构化的“操作说明书”，告诉 AI 助手：遇到什么场景该怎么做、有哪些固定流程、有哪些容易踩的坑、输出结果应该长什么样。有了 skill，AI 不再需要每次从零推断你的意图，而是直接套用你沉淀好的专业流程。就好比你去餐厅点餐，服务员不需要从“什么是煎蛋”开始理解，厨师拿到菜单就知道整套流程——skill 就是那张写清楚配菜顺序、火候和摆盘要求的“后厨菜谱”。我写这份「ffmpeg-skill」的初衷，就是想让 AI 帮我跳出“每次都要描述一遍需求”的困境。给它一句话：“把 video.mp4 从 2 分 10 秒裁到 5 分 30 秒，保留原始画质”，它就能自动规划出合理命令并执行。如果中途遇到问题，比如输入文件不存在、参数写错、输出路径不可写，它还会回来问我或自行调整。这已经不是“搜索引擎式”的问答，而是“真在干活”的助手。1.3 为什么优先选择 stream copy，而不是重新编码看 ffmpeg 命令时，新手最容易困惑的一个选择就是“要不要加 -c copy”。理解它，才会明白这条裁切链路为什么快。视频文件本质上由多个流组成：视频流、音频流、字幕流，每个流又按照不同的编码格式存储。所谓 stream copy，就是把这些压缩好的数据包原封不动地拿出来，只按需求裁剪时间范围，再封装进新的容器里，全程不解码、不重新编码。打个比方，这就像从一本已经印刷好的书里抽几页出来装订成新书，而不是把每个字重新排版打印一遍。前者速度取决于纸张抽取和装订的速度，后者要重新走一遍排版印刷，工作量完全是两个量级。裁切这种只动时间范围、不动画面内容的操作，stream copy 是绝对的首选。但 stream copy 不是万能的，后面会专门讲它的局限：它只能在关键帧上精确切分、时间精度受“关键帧间隔”限制、某些情况下还要强制重编码。这些坑我会在实操部分一项一项展开，先把结论放在这里：默认走 copy，快速出片；追求逐帧精度时再考虑重编码。这个判断标准，是整个 skill 里最核心的决策逻辑。2. ffmpeg 裁切的基础功：参数与命令模板2.1 吃透 -ss、-t、-to 三个核心参数ffmpeg 的裁切命令绕不开三个参数：-ss指定起点时间，-t指定持续时长，-to指定终点时间。它们之间的关系像闹钟设置：你既可以说“从 N 点开始，响 M 分钟”，对应-ss N -t M；也可以说“从 N 点开始，到 X 点结束”，对应-ss N -to X。两种写法在结果上基本等价，但-to需要额外注意它表示的是“终点在源文件中的绝对时间”，而不是相对起点的时间偏移。命令位置也很讲究。一个常见的命令长这样：ffmpeg -ss 00:02:10 -to 00:05:30 -i input.mp4 -c copy output.mp4这里把-ss和-to放在-i前面，表示“先快速定位到起点，再按时间范围读取数据”。这种写法下，ffmpeg 会先用“快进”模式寻找起点位置，速度非常快。但如果把-ss放到-i后面，处理逻辑就变了：ffmpeg 会先把整个文件解码，再从指定点开始输出，速度慢且消耗资源。所以在 skill 里，我一般固定要求“时间参数放在 -i 之前”，这个细节能省下大量等待时间。-t的用法稍有不同。如果你既想取片段，又拿不准精确终点，用-t更直观：从起点开始往后数固定长度。比如“裁 15 秒竖屏片段”，直接-ss 00:01:00 -t 15就能得到从 1 分钟开始、长度为 15 秒的素材。实际处理直播回放时，我更倾向于用-t，因为“截这段后面有多少秒”通常比“这段截止到哪个时间点”更符合直觉。2.2 精确裁切的两条路线：精准与效率如何取舍前面提到 stream copy 模式下切分只能落在关键帧上，这引出一个经典问题：为什么我明明指定了-ss 00:02:10，得到的视频却不是在精确的那个画面开始的？原因在于视频编码中 I 帧（关键帧）的存在。大多数编码器会每隔固定间隔生成一个关键帧，完整画面只有从关键帧开始才能独立解码，其他 B 帧/P 帧都需要参考前面的帧才能还原。stream copy 不做解码重编码，自然只能从离目标时间最近的关键帧开始输出。需要帧级精度时，就要走重编码路线。典型命令长这样：ffmpeg -ss 00:02:10.500 -to 00:05:30.200 -i input.mp4 -c:v libx264 -c:a aac output.mp4这种做法会把指定时间范围内的所有帧全部解码，再进行精确裁切和重新编码。代价是速度明显变慢、文件体积可能增大、画质会有轻微损失。更友好的折中方案是“先快后准”：先用 stream copy 粗切到大致范围，再在粗切结果上做小范围重编码精确到帧。两步都是秒级到分钟级，比直接对全片做重编码可靠得多。一句话总结长度与精度的取舍：日常发布要求下，关键帧误差一两秒完全能接受；只有你需要在某个运动瞬间切开幕，才值得动用重编码方案。这个判断放到 skill 里，就是 AI 先询问“是要快速粗切还是逐帧精确”，根据用户回答选择不同命令模板。2.3 可以照抄的常用裁切命令模板整理一份可以直接用的命令包。这些模板我测试过很多次，核心路径都验证过，你复制下来把文件名和时间参数换掉就能跑：# 从 2 分 10 秒裁到 5 分 30 秒，流拷贝，保留原始画质 ffmpeg -ss 00:02:10 -to 00:05:30 -i input.mp4 -c copy output.mp4 # 从视频开头裁切 30 秒，作为试看片段 ffmpeg -ss 0 -t 30 -i input.mp4 -c copy preview.mp4 # 精确到帧的裁切，重新编码视频流，音频流保持 AAC ffmpeg -ss 00:02:10.500 -to 00:05:30.200 -i input.mp4 -c:v libx264 -c:a aac output.mp4 # 批量裁掉每个视频的前 10 秒（需要循环处理） for f in *.mp4; do ffmpeg -ss 10 -i "$f" -c copy "trimmed_$f"; done需要提醒的是，第三条命令里的libx264只是最通用的视频编码器，不是性能最优也不是画质最优。实际可以按素材原始编码来选：如果源视频本身就是 H.265，可以用libx265避免反复转码；如果只是想做临时草稿，也可以直接用-c:v copy -c:a copy保留全部原始编码，不同封装格式间转换对纯复制基本没负担。（这句表达不够准确，修正一下：-c copy复制的是原流，不管源是 H.264、H.265 还是其他编码，copy 都直接搬运。）第一、二条命令对不需要重新编码的场景特别稳。用笔记本处理一小时 1080P 回放，通常十几秒就能完成，和剪辑软件的“准备渲染”速度完全不在一个级别。3. skill 怎么设计：让 AI 助手听懂“裁切”需求3.1 什么是 skill，为什么值得为 ffmpeg 专门写一份不少人对 skill 的第一反应是“这不就是提示词工程吗”。其实两者区别挺大。一个强提示词能引导 AI 生成回答，但 skill 通常包含更完整的结构：职责说明、使用规则、内置的命令模板、参数校验方式、常见错误处理办法。AI 助手读取 skill 后，不只是“知道怎么回答”，而是“知道怎么按你的工作流执行”。对 ffmpeg 这种参数敏感、报错五花八门的工具来说，把经验教训固化成 skill 价值很高，因为同样的坑，能让 AI 踩一次就学会，下次不再踩。skill 的载体可以简单到一个 Markdown 文件，也可以带上示例脚本和校验工具。实际操作中，我更推荐以小文件集的形式组织：一个SKILL.md作为主说明，里面写清适用场景、调用方式和核心规则；如果需要复杂逻辑，再附带一个脚本目录，放一些封装好的处理脚本。AI 助手在对话中读取到SKILL.md后，就会按其中约定执行，而不是自由发挥。以 Cursor 这类工具为例，它通常允许你在项目里放.cursor/skills之类的目录，每个 skill 一个独立文件夹，里面包含说明文档和示例。Codex 这类偏命令行、API 方向的助手，则更强调“tools”定义，但思路一致：把你的习惯、规则、模板提前告诉 AI，让它代理执行时更靠谱。3.2 一份能跑的 SKILL.md 长什么样我写 ffmpeg-skill 时，主文件结构大致分成了四块：职责范围、核心决策规则、命令模板、错误处理清单。给你看一个精简过的示例：# ffmpeg 视频裁切 Skill ## 职责 - 为用户提供视频裁切、时间片段提取服务 - 只负责 ffmpeg 命令行操作，不负责视频内容审核 ## 适用场景 - 从长视频截取指定时间段 - 去除视频开头/结尾的冗余内容 - 批量裁切多个文件的相同时间范围 - 提取音频片段（-vn 模式） ## 核心规则 1. 默认使用 stream copy（-c copy），尽量不重编码 2. -ss 放在 -i 之前，使用快速 seek 3. 用户没有明确要求精确到帧时，不做全片重编码 4. 输出文件名加 trimmed_ 前缀，避免覆盖源文件 ## 命令模板 ### 按时间范围裁切 ffmpeg -ss {start} -to {end} -i {input} -c copy {output} ### 裁取固定时长 ffmpeg -ss {start} -t {duration} -i {input} -c copy {output} ## 常见错误 - No such file: 检查输入文件路径 - Invalid data found: 文件可能损坏或格式不支持 - Non-monotonous DTS: 可能是流拷贝时间戳异常，可尝试 -fflags +genpts 修复这个文件没必要写得像论文，重点是“让 AI 看到之后能按你整理的流程干活”。模板里的{start}、{end}这些占位符，AI 会在对话中解析成具体时间参数。你在对话里说“裁 2 分 10 秒到 5 分 30 秒”，它会自动对应模板里的字段。3.3 让 AI 自动整理参数、确认命令再执行skill 写好了，真正使用时还要设计一条“交互路径”。我的经验是，第一句话给足信息，第二句话让 AI 复述方案，第三句话确认执行。举个例子，我通常这样说：“把 2024-06-01_直播回放.mp4 从 00:12:00 裁到 00:18:30，文件名改成高潮片段.mp4，保留原始画质。”然后 AI 助手会结合 skill 输出或将生成的命令展示给我看：ffmpeg -ss 00:12:00 -to 00:18:30 -i "2024-06-01_直播回放.mp4" -c copy "高潮片段.mp4"这里我坚持让 AI“先展示、后执行”，尤其第一次处理大文件或重要素材时，多一道确认能避免灾难性覆盖。等我对它的输出风格足够信任后，才逐步放开，让它直接在终端执行。对 Cursor 这类带终端能力的工具，执行结果会直接反馈在对话里，如果命令报错，AI 还能读取错误信息进行自我修正。这种“自然语言需求→命令生成→命令确认/执行→错误反馈→再修正”的闭环，是 ffmpeg-skill 体验顺畅的关键。顺便说一句：不要把所有希望都寄托在 AI 的自动修正上。有些 ffmpeg 报错信息很模糊，比如 “Invalid data found when processing input”，AI 可能猜错方向。skill 里尽量多写一点已知错误和处理方法，AI 能少走很多弯路。3.4 给 skill 划定边界：哪些事不做skill 设计里最容易被忽略的是“边界声明”。我在 ffmpeg-skill 里明确写了：只做裁切、提取、拼接这类基础处理，不负责内容合规审核，不自动下载网络素材，不处理来源不明的文件。这个边界不是消极防御，而是为了防止 AI 在“我要把这段视频保存下来”这种模糊请求下做出不合适的操作，也防止它把不该传播的内容二次加工。自媒体场景下，内容来源很重要。直播回放、公开课录像、自己录制的素材都属于可处理范围；未经授权的搬运内容，不管谁让你裁，都不应该出现在流程里。“能力可以有，边界必须有”是我做各种 skill 时的一个默认原则。ffmpeg-skill 最大的价值不是让 AI 什么都干，而是让它在明确、合法的范围内做到又快又稳。4. 从一句话到成品的完整实操流程4.1 典型场景：直播回放裁出高潮片段先说我最常做的场景：一场两小时直播回放，要裁出其中一段 8 分钟的高光内容。以前用剪辑软件，从导入到导出怎么也得五六分钟，其中大半时间在等待。现在流程简化成三步。第一步，向 AI 助手描述需求：“把 live_replay.mp4 从 00:45:00 裁到 00:53:00，输出 highlight.mp4”。第二步，AI 结合 skill 生成上述命令并执行。如果终端反馈正常，直接产出结果。第三步，我用播放器快速检查一遍输出文件，确认首尾画面正确、时长正确，收工。整个流程下来，耗时基本取决于磁盘速度。有一次处理 4K 素材，输入文件 8GB，裁出 1.2GB 片段，全程只花了不到 20 秒。这还是 I/O 受限的结果，不是 ffmpeg 在做重活。而这种体验，剪辑软件给不了。4.2 批量裁切：一次性去掉所有片头片尾自媒体创作者遇到最多的第二类需求，是批量处理。比如每个月底，我会拿到一堆录屏教程，每个视频开头都有 5 秒黑屏和结尾 3 秒工作人员闲聊，必须清理。一条条在剪辑软件里操作会崩溃，用 skill 就简单了。把需求告诉 AI：“把当前目录下所有 mp4 文件的开头 5 秒和结尾 3 秒去掉，覆盖保存到 trimmed 子目录”。AI 会根据 skill 里的批量处理模板生成一段循环命令：mkdir -p trimmed for f in *.mp4; do duration=$(ffprobe -v error -show_entries format=duration -of default=noprint_wrappers=1:nokey=1 "$f") trimmed_duration=$(echo "$duration - 3" | bc) ffmpeg -ss 5 -t "$trimmed_duration" -i "$f" -c copy "trimmed/$f" done这里有个细节很多人会踩：计算时长时，最好用ffprobe读取源文件真实时长，而不是凭文件名猜测。有些录制设备生成的时长信息和容器元数据不一致，手动硬减可能把结尾不该砍的也砍了。skill 里写明“批量场景先 probe 再裁”，能省掉一整轮返工。4.3 精确裁切：波形对齐和帧级微调现在聊一个更偏专业的操作：精确到帧的裁切。自媒体内容里，有些时候需要卡着音频波形切，比如播客片段要裁在“语气停顿结束”那一帧，或者口播视频要留出自然的剪辑点。stream copy 做不到这种精细控制，必须重编码。实际操作时，我会先让 AI 用 ffmpeg 提取片段的波形或预览图，帮我判断出精确的入点出点。这里用到的命令也很简单：# 导出片段的音频波形图，用于目视定位剪辑点 ffmpeg -i input.mp4 -ss 00:10:00 -t 30 -filter_complex "showwavespic=s=1280x240" -frames:v 1 waveform.png然后基于波形图确认时间点，再用重编码命令做最终裁切。这种“先快速看波形、再精确重编码”的分步操作，比直接盲调时间参数高效得多。毕竟人眼对“哪个点是最佳剪辑点”的判断，很难用数字一次说清，需要视觉辅助。4.4 应对巨型视频的进阶处理建议自媒体素材越攒越大，动不动十几个 GB 的 4K 录屏、现场多机位素材，处理过程中容易踩资源瓶颈。我在实际中验证过三个有效策略：第一，先做“信号探测”。用 ffprobe 查看文件编码、分辨率、时长、关键帧间隔，判断能不能走 stream copy，还是必须重编码。这一步能提前避开很多未知报错。第二，分两段处理复杂任务。比如一个 3 小时的视频要裁好几个片段，不要分别对原文件用-ss定位多次，这会反复扫描文件。更好的做法是先裁出一个大范围的中转文件，再基于中转文件细分，减少源文件被读取的次数。第三，给临时文件留够磁盘空间。ffmpeg 处理大型视频时，输出文件会逐渐写满磁盘。如果目标分区空间不足，任务会中途失败。skill 里建议 AI 在执行前检查磁盘剩余空间，这属于“看起来多余但能救人一命”的规则。5. 坑与排查：我踩过的那些雷5.1 参数顺序不对，黑屏、卡顿、时间轴漂移ffmpeg 对参数位置确实不挑，同一个参数放前面和放后面，效果可能完全不同，但新手不容易察觉。最典型的就是-ss。放在-i之前是“输入定位”，ffmpeg 先跳转再读取，速度快但关键帧精度一般；放在-i之后是“输出定位”，ffmpeg 解码全部帧后再丢掉起点之前的内容，精度高但极慢。多年前第一次处理大视频时，我把-ss放在-i后面，足足等了十分钟才完成，还以为是正常现象。后来才知道，两小时视频如果能秒开，说明走的是输入定位。区分方法很简单：看命令里-ss是写在-i input.mp4前面还是后面。skill 里我强制要求 AI 默认把-ss放在-i前，除非用户明确说需要帧级精度。这个规则能避免大多数“为什么这么慢”“为什么切偏了”的问题。5.2 切出来的视频开头对不上，问题多半出在关键帧用 stream copy 裁切时，输出文件的时间戳仍按源文件原始时间轴记录。比如你只裁了 00:02:10 到 00:05:30 这段，输出文件很可能开头是 00:02:05 之类的非整点时间，因为 00:02:10 不是关键帧位置，只能就近选择。很多播放器能正常播放，但导出的视频时间轴显示异常。遇到这种问题，skill 里提供两个方向：一是重新编码，精确到帧，最稳但慢；二是用-avoid_negative_ts make_zero重置时间戳，让输出从 0 开始。后者在很多场景下能解决常见的时间轴错乱问题：ffmpeg -ss 2 -i input.mp4 -c copy -avoid_negative_ts make_zero output.mp4看起来只是加了一个参数，实际上清理了源时间线段里的“负偏移”。如果你发现裁出来的视频在播放器里进度条跳来跳去，或者最后几秒黑屏，多半需要这个参数。5.3 音频视频不同步，别急着怪素材如果裁完的视频出现画音不同步，最先要排查的不是 ffmpeg，而是源素材的封装结构。有些录屏软件把视频流和音频流分开记录，结束后才统一打包，这会导致流之间的起始时间戳不完全对齐。ffmpeg stream copy 时，如果只是简单的数据搬运，就会把这种错位也复制到输出里。常用的修复方式是指定编码参数或重置时间戳。我遇到比较多的是录音和画面起始有几百毫秒偏差，此时用-af "aresample=async=1:first_pts=0"在裁剪同时重新对齐音频流，或者直接把视频流导出后重新 media 处理。最笨但有效的方法是重编码音频流，让 ffmpeg 自动根据时间轴对齐：ffmpeg -ss 10 -t 30 -i input.mp4 -c:v copy -c:a aac -b:a 192k output.mp4这里“只重编码音频、保留视频流拷贝”的组合，速度依然很快，又能在一定程度上修复音画时间基准不一致的问题。5.4 编码器参数不匹配导致的播放兼容性问题ffmpeg 默认输出的编码格式不一定适合所有平台。有些自媒体平台对 H.265 视频兼容性差，对 H.264 却普遍友好。如果你的源素材是 H.265 编码，直接 stream copy 出来的文件，可能在老手机上打不开。skill 里加一条规则：如果最终输出要发布到平台，优先转成 H.264 + AAC 的组合。实际处理中，我用这样的命令做“平台兼容性转码”：ffmpeg -ss 0 -t 60 -i input.mp4 -c:v libx264 -preset fast -crf 23 -c:a aac -b:a 128k output_h264.mp4-preset fast是转码速度和压缩率之间的一个平衡点，-crf 23是 H.264 的常见质量参数，数值越小画质越好、文件越大。自媒体平台发布的话，一般建议-crf 18到-crf 23之间，兼顾体积和观感。这里唯一要注意的是，不要把-crf设成 0 或负数，很多人会栽在这里。5.5 一份快速查错清单把日常碰到的 ffmpeg 报错整理成了一张速查表，放到 skill 的COMMON_ERRORS.md里很有用：报错/现象常见原因处理方向No such file or directory输入路径不对、文件名含特殊字符检查路径，必要时加引号Invalid data found when processing input输入文件损坏、格式不被支持、容器缺失用 ffprobe 验证，考虑重新下载/录制Non-monotonous DTS in output stream流拷贝导致时间戳异常加-fflags +genpts，或重置时间戳Codec not supported / Unknown encoder当前 ffmpeg 编译版本缺编解码器查编译配置，换可用编码器参数Requested output format is not a suitable output format输出文件名后缀和封装格式不匹配统一扩展名，必要时指定-f进度条卡住不动磁盘空间不足、输入文件是网络流检查磁盘、改用本地文件这张表不是穷尽所有错误，但覆盖了 80% 的日常问题。skill 的价值就在于：AI 遇到表内问题，可以直接执行修复策略，不用每次都回来问你。6. 给 skill 划边界与进阶玩法6.1 哪些任务不适合交给 AI 一键处理习惯了“一句话裁切”的便利后，很容易把所有视频处理需求都丢给 AI，但有些场景我坚持人工介入。比如涉及内容审核判断的视频加工，不该让 AI 自动处理；来源不明的素材，也不该在没确认版权和授权的情况下批量处理。ffmpeg 只是个工具，真正决定“能不能用、该不该发”的永远是人的判断。自媒体创作者尤其要留心：直播回放虽然是你自己录制的内容，但嘉宾的形象权、背景音乐版权、合作方提供的素材授权，这些都不是命令行能帮你“裁掉”的。skill 里写得最清楚的规则就是：只做格式和时间层面的处理，不做内容合规层面的判断。这句话听起来有点“免责声明”味道，但确实避免了很多不必要的麻烦。6.2 进阶方向：把裁切拼进更大工作流ffmpeg-skill 只是起点。很快你会遇到更复杂的组合需求，比如“把多个裁剪片段拼接在一起，统一转成竖屏，加一个淡入淡出”。这种任务就不是一个命令能解决的了，需要多个命令串成流水线。我的做法是在 skill 里增加一个“复杂任务拆解”规则：AI 先把需求拆成“裁切→拼接→转码→调色”等多个阶段，每个阶段生成对应命令，按顺序执行。中间文件就用tmp_*.mp4来命名，最后再清理临时产物。这是 ffmpeg 日常使用的进阶玩法，也是从“会用”到“会用得好”的分水岭。拼接时比较常用的命令是把几个已裁好的视频片段按顺序合并：ffmpeg -f concat -safe 0 -i list.txt -c copy merged.mp4其中list.txt是需要拼接的文件清单，每行一个file 'xxx.mp4'。不要小看这个文件清单的顺序要求，文件名里的特殊字符很容易让 concat 解析失败，所以 skill 里要提醒 AI：生成 list 时给路径加引号。6.3 我个人的实操体会折腾出这套 ffmpeg-skill 之后，最大的改变不是“命令记得更熟了”，而是终于有了一套可以反复复用的做事方式。素材刚拿到手，我可以先让 AI 做快速探测和粗裁，等确认了要保留的范围，再去做精确处理；最终出片前跑一个平台兼容性转换。同样的流程用在几十个文件上，效率提升是肉眼可见的。不过也要劝想完全“放手”的朋友一句：skill 写得再完善，也没法覆盖真实世界所有奇怪的素材情况。有些视频文件来自奇怪的工具，时间戳错乱、编码器非常规、声道映射诡异，AI 可能会连续失败。这个时候我通常会让它把源码信息打印出来，再对照着调整命令。没有一步到位的万能规则，但把 fix 过程记录回 skill，下一次同类问题就能快速命中。如果想少踩点坑，一开始可以把 skill 设计成“只输出命令、不直接执行”的模式，等对 AI 的处理风格足够信赖后，再逐步放开执行权限。我现在已经可以在一些耗时操作上完全放手，让它跑完整个批处理流程，但每轮结束后还是会抽查输出文件的时长和首尾内容。工具的目的是把时间还给你，而不是把判断力也一起带走。
从自媒体那边收到的素材，十有八九是直播回放、录屏、会议录像这种“大块头”。真正能发出去的成片，可能只是其中几十秒到几分钟的高光时刻。以前我的做法是老老实实打开剪辑软件，导入、拖时间轴、切一刀、导出，一单素材下来少说五分钟，多则半小时。后来我把常用处理逻辑整理成一套规则，让 AI 编码助手（Cursor/Codex 这类工具）通过调用 ffmpeg 帮我裁切，一句话就是一个成品。这大概就是标题里「ffmpeg-skill」的真实含义：不是某个神奇插件，而是把剪辑师的重复劳动封装成“AI 能读懂的说明书”。这篇文章就围绕这套玩法展开，适合每天和视频素材打交道、又不想被困在时间轴里的自媒体创作者，也适合想给 AI 编程助手扩展实用技能的技术型内容从业者。1. 为什么视频裁切值得做成一个 skill1.1 自媒体剪辑的真实痛点：不是不会剪，而是重复劳动太多刚开始接触视频处理时，我也觉得命令行剪辑特别“反人类”，明明在 Pr 或者剪映里拉两下就能完成的事，凭什么要去背参数。实际做过几轮批量处理后，我才意识到编辑器里那些看似简单的操作，背后藏着一堆隐性成本：软件启动要等、素材导入要缓存、时间轴预览会卡、导出还要重新编码一遍。你要是连续处理十条素材，每条都走这套流程，时间基本就在等待里耗光了。更麻烦的是直接剪辑软件处理长视频。一段两小时的直播回放导入进去，预览就掉帧，拖动时间轴等个半天，裁到一半电脑风扇狂转，导出又花十几分钟。而 ffmpeg 处理同样的任务，很多情况下用的是 stream copy 模式，几乎不重新压缩视频内容，只做“切一刀”这么简单的事，速度可以做到和磁盘读写差不多，秒级完成。这种差异在高分辨率素材上尤其明显：4K 视频重编码意味着要遍历每一帧，而直接裁剪可能只要复制对应字节即可。我理解的自媒体剪辑痛点，其实从来不是说“你不会剪漂亮的转场”或者“你不懂调色曲线”，而是那些极度琐碎、高度重复、又没有创造性的预处理动作：统一去片头、裁掉开头多余的黑屏、掐掉结尾的杂音、把一段长素材切成几段备用。这些活让剪辑软件来做就是杀鸡用牛刀，让 ffmpeg 来做又需要记参数。所以把它们整理成 skill 指令，交给支持工具调用的 AI 助手区执行，是顺手又高效的选择。1.2 从“手动拉时间轴”到“一句话指令”的关键转变促成这个转变的核心，在于 AI 编程助手已经不只是“代码补全器”了。以 Cursor、Codex 为代表的工具，能理解自然语言指令，可以读写终端，可以查看文件系统，甚至可以执行命令并观察输出结果。换句话说，你把需求描述得足够清楚，它就能通过调用命令行工具完成实际任务，而不是只给你一段建议让你自己复制粘贴去跑。这时候 skill 的价值就体现出来了。所谓 skill，本质上是一份结构化的“操作说明书”，告诉 AI 助手：遇到什么场景该怎么做、有哪些固定流程、有哪些容易踩的坑、输出结果应该长什么样。有了 skill，AI 不再需要每次从零推断你的意图，而是直接套用你沉淀好的专业流程。就好比你去餐厅点餐，服务员不需要从“什么是煎蛋”开始理解，厨师拿到菜单就知道整套流程——skill 就是那张写清楚配菜顺序、火候和摆盘要求的“后厨菜谱”。我写这份「ffmpeg-skill」的初衷，就是想让 AI 帮我跳出“每次都要描述一遍需求”的困境。给它一句话：“把 video.mp4 从 2 分 10 秒裁到 5 分 30 秒，保留原始画质”，它就能自动规划出合理命令并执行。如果中途遇到问题，比如输入文件不存在、参数写错、输出路径不可写，它还会回来问我或自行调整。这已经不是“搜索引擎式”的问答，而是“真在干活”的助手。1.3 为什么优先选择 stream copy，而不是重新编码看 ffmpeg 命令时，新手最容易困惑的一个选择就是“要不要加 -c copy”。理解它，才会明白这条裁切链路为什么快。视频文件本质上由多个流组成：视频流、音频流、字幕流，每个流又按照不同的编码格式存储。所谓 stream copy，就是把这些压缩好的数据包原封不动地拿出来，只按需求裁剪时间范围，再封装进新的容器里，全程不解码、不重新编码。打个比方，这就像从一本已经印刷好的书里抽几页出来装订成新书，而不是把每个字重新排版打印一遍。前者速度取决于纸张抽取和装订的速度，后者要重新走一遍排版印刷，工作量完全是两个量级。裁切这种只动时间范围、不动画面内容的操作，stream copy 是绝对的首选。但 stream copy 不是万能的，后面会专门讲它的局限：它只能在关键帧上精确切分、时间精度受“关键帧间隔”限制、某些情况下还要强制重编码。这些坑我会在实操部分一项一项展开，先把结论放在这里：默认走 copy，快速出片；追求逐帧精度时再考虑重编码。这个判断标准，是整个 skill 里最核心的决策逻辑。2. ffmpeg 裁切的基础功：参数与命令模板2.1 吃透 -ss、-t、-to 三个核心参数ffmpeg 的裁切命令绕不开三个参数：-ss指定起点时间，-t指定持续时长，-to指定终点时间。它们之间的关系像闹钟设置：你既可以说“从 N 点开始，响 M 分钟”，对应-ss N -t M；也可以说“从 N 点开始，到 X 点结束”，对应-ss N -to X。两种写法在结果上基本等价，但-to需要额外注意它表示的是“终点在源文件中的绝对时间”，而不是相对起点的时间偏移。命令位置也很讲究。一个常见的命令长这样：ffmpeg -ss 00:02:10 -to 00:05:30 -i input.mp4 -c copy output.mp4这里把-ss和-to放在-i前面，表示“先快速定位到起点，再按时间范围读取数据”。这种写法下，ffmpeg 会先用“快进”模式寻找起点位置，速度非常快。但如果把-ss放到-i后面，处理逻辑就变了：ffmpeg 会先把整个文件解码，再从指定点开始输出，速度慢且消耗资源。所以在 skill 里，我一般固定要求“时间参数放在 -i 之前”，这个细节能省下大量等待时间。-t的用法稍有不同。如果你既想取片段，又拿不准精确终点，用-t更直观：从起点开始往后数固定长度。比如“裁 15 秒竖屏片段”，直接-ss 00:01:00 -t 15就能得到从 1 分钟开始、长度为 15 秒的素材。实际处理直播回放时，我更倾向于用-t，因为“截这段后面有多少秒”通常比“这段截止到哪个时间点”更符合直觉。2.2 精确裁切的两条路线：精准与效率如何取舍前面提到 stream copy 模式下切分只能落在关键帧上，这引出一个经典问题：为什么我明明指定了-ss 00:02:10，得到的视频却不是在精确的那个画面开始的？原因在于视频编码中 I 帧（关键帧）的存在。大多数编码器会每隔固定间隔生成一个关键帧，完整画面只有从关键帧开始才能独立解码，其他 B 帧/P 帧都需要参考前面的帧才能还原。stream copy 不做解码重编码，自然只能从离目标时间最近的关键帧开始输出。需要帧级精度时，就要走重编码路线。典型命令长这样：ffmpeg -ss 00:02:10.500 -to 00:05:30.200 -i input.mp4 -c:v libx264 -c:a aac output.mp4这种做法会把指定时间范围内的所有帧全部解码，再进行精确裁切和重新编码。代价是速度明显变慢、文件体积可能增大、画质会有轻微损失。更友好的折中方案是“先快后准”：先用 stream copy 粗切到大致范围，再在粗切结果上做小范围重编码精确到帧。两步都是秒级到分钟级，比直接对全片做重编码可靠得多。一句话总结长度与精度的取舍：日常发布要求下，关键帧误差一两秒完全能接受；只有你需要在某个运动瞬间切开幕，才值得动用重编码方案。这个判断放到 skill 里，就是 AI 先询问“是要快速粗切还是逐帧精确”，根据用户回答选择不同命令模板。2.3 可以照抄的常用裁切命令模板整理一份可以直接用的命令包。这些模板我测试过很多次，核心路径都验证过，你复制下来把文件名和时间参数换掉就能跑：# 从 2 分 10 秒裁到 5 分 30 秒，流拷贝，保留原始画质 ffmpeg -ss 00:02:10 -to 00:05:30 -i input.mp4 -c copy output.mp4 # 从视频开头裁切 30 秒，作为试看片段 ffmpeg -ss 0 -t 30 -i input.mp4 -c copy preview.mp4 # 精确到帧的裁切，重新编码视频流，音频流保持 AAC ffmpeg -ss 00:02:10.500 -to 00:05:30.200 -i input.mp4 -c:v libx264 -c:a aac output.mp4 # 批量裁掉每个视频的前 10 秒（需要循环处理） for f in *.mp4; do ffmpeg -ss 10 -i "$f" -c copy "trimmed_$f"; done需要提醒的是，第三条命令里的libx264只是最通用的视频编码器，不是性能最优也不是画质最优。实际可以按素材原始编码来选：如果源视频本身就是 H.265，可以用libx265避免反复转码；如果只是想做临时草稿，也可以直接用-c:v copy -c:a copy保留全部原始编码，不同封装格式间转换对纯复制基本没负担。（这句表达不够准确，修正一下：-c copy复制的是原流，不管源是 H.264、H.265 还是其他编码，copy 都直接搬运。）第一、二条命令对不需要重新编码的场景特别稳。用笔记本处理一小时 1080P 回放，通常十几秒就能完成，和剪辑软件的“准备渲染”速度完全不在一个级别。3. skill 怎么设计：让 AI 助手听懂“裁切”需求3.1 什么是 skill，为什么值得为 ffmpeg 专门写一份不少人对 skill 的第一反应是“这不就是提示词工程吗”。其实两者区别挺大。一个强提示词能引导 AI 生成回答，但 skill 通常包含更完整的结构：职责说明、使用规则、内置的命令模板、参数校验方式、常见错误处理办法。AI 助手读取 skill 后，不只是“知道怎么回答”，而是“知道怎么按你的工作流执行”。对 ffmpeg 这种参数敏感、报错五花八门的工具来说，把经验教训固化成 skill 价值很高，因为同样的坑，能让 AI 踩一次就学会，下次不再踩。skill 的载体可以简单到一个 Markdown 文件，也可以带上示例脚本和校验工具。实际操作中，我更推荐以小文件集的形式组织：一个SKILL.md作为主说明，里面写清适用场景、调用方式和核心规则；如果需要复杂逻辑，再附带一个脚本目录，放一些封装好的处理脚本。AI 助手在对话中读取到SKILL.md后，就会按其中约定执行，而不是自由发挥。以 Cursor 这类工具为例，它通常允许你在项目里放.cursor/skills之类的目录，每个 skill 一个独立文件夹，里面包含说明文档和示例。Codex 这类偏命令行、API 方向的助手，则更强调“tools”定义，但思路一致：把你的习惯、规则、模板提前告诉 AI，让它代理执行时更靠谱。3.2 一份能跑的 SKILL.md 长什么样我写 ffmpeg-skill 时，主文件结构大致分成了四块：职责范围、核心决策规则、命令模板、错误处理清单。给你看一个精简过的示例：# ffmpeg 视频裁切 Skill ## 职责 - 为用户提供视频裁切、时间片段提取服务 - 只负责 ffmpeg 命令行操作，不负责视频内容审核 ## 适用场景 - 从长视频截取指定时间段 - 去除视频开头/结尾的冗余内容 - 批量裁切多个文件的相同时间范围 - 提取音频片段（-vn 模式） ## 核心规则 1. 默认使用 stream copy（-c copy），尽量不重编码 2. -ss 放在 -i 之前，使用快速 seek 3. 用户没有明确要求精确到帧时，不做全片重编码 4. 输出文件名加 trimmed_ 前缀，避免覆盖源文件 ## 命令模板 ### 按时间范围裁切 ffmpeg -ss {start} -to {end} -i {input} -c copy {output} ### 裁取固定时长 ffmpeg -ss {start} -t {duration} -i {input} -c copy {output} ## 常见错误 - No such file: 检查输入文件路径 - Invalid data found: 文件可能损坏或格式不支持 - Non-monotonous DTS: 可能是流拷贝时间戳异常，可尝试 -fflags +genpts 修复这个文件没必要写得像论文，重点是“让 AI 看到之后能按你整理的流程干活”。模板里的{start}、{end}这些占位符，AI 会在对话中解析成具体时间参数。你在对话里说“裁 2 分 10 秒到 5 分 30 秒”，它会自动对应模板里的字段。3.3 让 AI 自动整理参数、确认命令再执行skill 写好了，真正使用时还要设计一条“交互路径”。我的经验是，第一句话给足信息，第二句话让 AI 复述方案，第三句话确认执行。举个例子，我通常这样说：“把 2024-06-01_直播回放.mp4 从 00:12:00 裁到 00:18:30，文件名改成高潮片段.mp4，保留原始画质。”然后 AI 助手会结合 skill 输出或将生成的命令展示给我看：ffmpeg -ss 00:12:00 -to 00:18:30 -i "2024-06-01_直播回放.mp4" -c copy "高潮片段.mp4"这里我坚持让 AI“先展示、后执行”，尤其第一次处理大文件或重要素材时，多一道确认能避免灾难性覆盖。等我对它的输出风格足够信任后，才逐步放开，让它直接在终端执行。对 Cursor 这类带终端能力的工具，执行结果会直接反馈在对话里，如果命令报错，AI 还能读取错误信息进行自我修正。这种“自然语言需求→命令生成→命令确认/执行→错误反馈→再修正”的闭环，是 ffmpeg-skill 体验顺畅的关键。顺便说一句：不要把所有希望都寄托在 AI 的自动修正上。有些 ffmpeg 报错信息很模糊，比如 “Invalid data found when processing input”，AI 可能猜错方向。skill 里尽量多写一点已知错误和处理方法，AI 能少走很多弯路。3.4 给 skill 划定边界：哪些事不做skill 设计里最容易被忽略的是“边界声明”。我在 ffmpeg-skill 里明确写了：只做裁切、提取、拼接这类基础处理，不负责内容合规审核，不自动下载网络素材，不处理来源不明的文件。这个边界不是消极防御，而是为了防止 AI 在“我要把这段视频保存下来”这种模糊请求下做出不合适的操作，也防止它把不该传播的内容二次加工。自媒体场景下，内容来源很重要。直播回放、公开课录像、自己录制的素材都属于可处理范围；未经授权的搬运内容，不管谁让你裁，都不应该出现在流程里。“能力可以有，边界必须有”是我做各种 skill 时的一个默认原则。ffmpeg-skill 最大的价值不是让 AI 什么都干，而是让它在明确、合法的范围内做到又快又稳。4. 从一句话到成品的完整实操流程4.1 典型场景：直播回放裁出高潮片段先说我最常做的场景：一场两小时直播回放，要裁出其中一段 8 分钟的高光内容。以前用剪辑软件，从导入到导出怎么也得五六分钟，其中大半时间在等待。现在流程简化成三步。第一步，向 AI 助手描述需求：“把 live_replay.mp4 从 00:45:00 裁到 00:53:00，输出 highlight.mp4”。第二步，AI 结合 skill 生成上述命令并执行。如果终端反馈正常，直接产出结果。第三步，我用播放器快速检查一遍输出文件，确认首尾画面正确、时长正确，收工。整个流程下来，耗时基本取决于磁盘速度。有一次处理 4K 素材，输入文件 8GB，裁出 1.2GB 片段，全程只花了不到 20 秒。这还是 I/O 受限的结果，不是 ffmpeg 在做重活。而这种体验，剪辑软件给不了。4.2 批量裁切：一次性去掉所有片头片尾自媒体创作者遇到最多的第二类需求，是批量处理。比如每个月底，我会拿到一堆录屏教程，每个视频开头都有 5 秒黑屏和结尾 3 秒工作人员闲聊，必须清理。一条条在剪辑软件里操作会崩溃，用 skill 就简单了。把需求告诉 AI：“把当前目录下所有 mp4 文件的开头 5 秒和结尾 3 秒去掉，覆盖保存到 trimmed 子目录”。AI 会根据 skill 里的批量处理模板生成一段循环命令：mkdir -p trimmed for f in *.mp4; do duration=$(ffprobe -v error -show_entries format=duration -of default=noprint_wrappers=1:nokey=1 "$f") trimmed_duration=$(echo "$duration - 3" | bc) ffmpeg -ss 5 -t "$trimmed_duration" -i "$f" -c copy "trimmed/$f" done这里有个细节很多人会踩：计算时长时，最好用ffprobe读取源文件真实时长，而不是凭文件名猜测。有些录制设备生成的时长信息和容器元数据不一致，手动硬减可能把结尾不该砍的也砍了。skill 里写明“批量场景先 probe 再裁”，能省掉一整轮返工。4.3 精确裁切：波形对齐和帧级微调现在聊一个更偏专业的操作：精确到帧的裁切。自媒体内容里，有些时候需要卡着音频波形切，比如播客片段要裁在“语气停顿结束”那一帧，或者口播视频要留出自然的剪辑点。stream copy 做不到这种精细控制，必须重编码。实际操作时，我会先让 AI 用 ffmpeg 提取片段的波形或预览图，帮我判断出精确的入点出点。这里用到的命令也很简单：# 导出片段的音频波形图，用于目视定位剪辑点 ffmpeg -i input.mp4 -ss 00:10:00 -t 30 -filter_complex "showwavespic=s=1280x240" -frames:v 1 waveform.png然后基于波形图确认时间点，再用重编码命令做最终裁切。这种“先快速看波形、再精确重编码”的分步操作，比直接盲调时间参数高效得多。毕竟人眼对“哪个点是最佳剪辑点”的判断，很难用数字一次说清，需要视觉辅助。4.4 应对巨型视频的进阶处理建议自媒体素材越攒越大，动不动十几个 GB 的 4K 录屏、现场多机位素材，处理过程中容易踩资源瓶颈。我在实际中验证过三个有效策略：第一，先做“信号探测”。用 ffprobe 查看文件编码、分辨率、时长、关键帧间隔，判断能不能走 stream copy，还是必须重编码。这一步能提前避开很多未知报错。第二，分两段处理复杂任务。比如一个 3 小时的视频要裁好几个片段，不要分别对原文件用-ss定位多次，这会反复扫描文件。更好的做法是先裁出一个大范围的中转文件，再基于中转文件细分，减少源文件被读取的次数。第三，给临时文件留够磁盘空间。ffmpeg 处理大型视频时，输出文件会逐渐写满磁盘。如果目标分区空间不足，任务会中途失败。skill 里建议 AI 在执行前检查磁盘剩余空间，这属于“看起来多余但能救人一命”的规则。5. 坑与排查：我踩过的那些雷5.1 参数顺序不对，黑屏、卡顿、时间轴漂移ffmpeg 对参数位置确实不挑，同一个参数放前面和放后面，效果可能完全不同，但新手不容易察觉。最典型的就是-ss。放在-i之前是“输入定位”，ffmpeg 先跳转再读取，速度快但关键帧精度一般；放在-i之后是“输出定位”，ffmpeg 解码全部帧后再丢掉起点之前的内容，精度高但极慢。多年前第一次处理大视频时，我把-ss放在-i后面，足足等了十分钟才完成，还以为是正常现象。后来才知道，两小时视频如果能秒开，说明走的是输入定位。区分方法很简单：看命令里-ss是写在-i input.mp4前面还是后面。skill 里我强制要求 AI 默认把-ss放在-i前，除非用户明确说需要帧级精度。这个规则能避免大多数“为什么这么慢”“为什么切偏了”的问题。5.2 切出来的视频开头对不上，问题多半出在关键帧用 stream copy 裁切时，输出文件的时间戳仍按源文件原始时间轴记录。比如你只裁了 00:02:10 到 00:05:30 这段，输出文件很可能开头是 00:02:05 之类的非整点时间，因为 00:02:10 不是关键帧位置，只能就近选择。很多播放器能正常播放，但导出的视频时间轴显示异常。遇到这种问题，skill 里提供两个方向：一是重新编码，精确到帧，最稳但慢；二是用-avoid_negative_ts make_zero重置时间戳，让输出从 0 开始。后者在很多场景下能解决常见的时间轴错乱问题：ffmpeg -ss 2 -i input.mp4 -c copy -avoid_negative_ts make_zero output.mp4看起来只是加了一个参数，实际上清理了源时间线段里的“负偏移”。如果你发现裁出来的视频在播放器里进度条跳来跳去，或者最后几秒黑屏，多半需要这个参数。5.3 音频视频不同步，别急着怪素材如果裁完的视频出现画音不同步，最先要排查的不是 ffmpeg，而是源素材的封装结构。有些录屏软件把视频流和音频流分开记录，结束后才统一打包，这会导致流之间的起始时间戳不完全对齐。ffmpeg stream copy 时，如果只是简单的数据搬运，就会把这种错位也复制到输出里。常用的修复方式是指定编码参数或重置时间戳。我遇到比较多的是录音和画面起始有几百毫秒偏差，此时用-af "aresample=async=1:first_pts=0"在裁剪同时重新对齐音频流，或者直接把视频流导出后重新 media 处理。最笨但有效的方法是重编码音频流，让 ffmpeg 自动根据时间轴对齐：ffmpeg -ss 10 -t 30 -i input.mp4 -c:v copy -c:a aac -b:a 192k output.mp4这里“只重编码音频、保留视频流拷贝”的组合，速度依然很快，又能在一定程度上修复音画时间基准不一致的问题。5.4 编码器参数不匹配导致的播放兼容性问题ffmpeg 默认输出的编码格式不一定适合所有平台。有些自媒体平台对 H.265 视频兼容性差，对 H.264 却普遍友好。如果你的源素材是 H.265 编码，直接 stream copy 出来的文件，可能在老手机上打不开。skill 里加一条规则：如果最终输出要发布到平台，优先转成 H.264 + AAC 的组合。实际处理中，我用这样的命令做“平台兼容性转码”：ffmpeg -ss 0 -t 60 -i input.mp4 -c:v libx264 -preset fast -crf 23 -c:a aac -b:a 128k output_h264.mp4-preset fast是转码速度和压缩率之间的一个平衡点，-crf 23是 H.264 的常见质量参数，数值越小画质越好、文件越大。自媒体平台发布的话，一般建议-crf 18到-crf 23之间，兼顾体积和观感。这里唯一要注意的是，不要把-crf设成 0 或负数，很多人会栽在这里。5.5 一份快速查错清单把日常碰到的 ffmpeg 报错整理成了一张速查表，放到 skill 的COMMON_ERRORS.md里很有用：报错/现象常见原因处理方向No such file or directory输入路径不对、文件名含特殊字符检查路径，必要时加引号Invalid data found when processing input输入文件损坏、格式不被支持、容器缺失用 ffprobe 验证，考虑重新下载/录制Non-monotonous DTS in output stream流拷贝导致时间戳异常加-fflags +genpts，或重置时间戳Codec not supported / Unknown encoder当前 ffmpeg 编译版本缺编解码器查编译配置，换可用编码器参数Requested output format is not a suitable output format输出文件名后缀和封装格式不匹配统一扩展名，必要时指定-f进度条卡住不动磁盘空间不足、输入文件是网络流检查磁盘、改用本地文件这张表不是穷尽所有错误，但覆盖了 80% 的日常问题。skill 的价值就在于：AI 遇到表内问题，可以直接执行修复策略，不用每次都回来问你。6. 给 skill 划边界与进阶玩法6.1 哪些任务不适合交给 AI 一键处理习惯了“一句话裁切”的便利后，很容易把所有视频处理需求都丢给 AI，但有些场景我坚持人工介入。比如涉及内容审核判断的视频加工，不该让 AI 自动处理；来源不明的素材，也不该在没确认版权和授权的情况下批量处理。ffmpeg 只是个工具，真正决定“能不能用、该不该发”的永远是人的判断。自媒体创作者尤其要留心：直播回放虽然是你自己录制的内容，但嘉宾的形象权、背景音乐版权、合作方提供的素材授权，这些都不是命令行能帮你“裁掉”的。skill 里写得最清楚的规则就是：只做格式和时间层面的处理，不做内容合规层面的判断。这句话听起来有点“免责声明”味道，但确实避免了很多不必要的麻烦。6.2 进阶方向：把裁切拼进更大工作流ffmpeg-skill 只是起点。很快你会遇到更复杂的组合需求，比如“把多个裁剪片段拼接在一起，统一转成竖屏，加一个淡入淡出”。这种任务就不是一个命令能解决的了，需要多个命令串成流水线。我的做法是在 skill 里增加一个“复杂任务拆解”规则：AI 先把需求拆成“裁切→拼接→转码→调色”等多个阶段，每个阶段生成对应命令，按顺序执行。中间文件就用tmp_*.mp4来命名，最后再清理临时产物。这是 ffmpeg 日常使用的进阶玩法，也是从“会用”到“会用得好”的分水岭。拼接时比较常用的命令是把几个已裁好的视频片段按顺序合并：ffmpeg -f concat -safe 0 -i list.txt -c copy merged.mp4其中list.txt是需要拼接的文件清单，每行一个file 'xxx.mp4'。不要小看这个文件清单的顺序要求，文件名里的特殊字符很容易让 concat 解析失败，所以 skill 里要提醒 AI：生成 list 时给路径加引号。6.3 我个人的实操体会折腾出这套 ffmpeg-skill 之后，最大的改变不是“命令记得更熟了”，而是终于有了一套可以反复复用的做事方式。素材刚拿到手，我可以先让 AI 做快速探测和粗裁，等确认了要保留的范围，再去做精确处理；最终出片前跑一个平台兼容性转换。同样的流程用在几十个文件上，效率提升是肉眼可见的。不过也要劝想完全“放手”的朋友一句：skill 写得再完善，也没法覆盖真实世界所有奇怪的素材情况。有些视频文件来自奇怪的工具，时间戳错乱、编码器非常规、声道映射诡异，AI 可能会连续失败。这个时候我通常会让它把源码信息打印出来，再对照着调整命令。没有一步到位的万能规则，但把 fix 过程记录回 skill，下一次同类问题就能快速命中。如果想少踩点坑，一开始可以把 skill 设计成“只输出命令、不直接执行”的模式，等对 AI 的处理风格足够信赖后，再逐步放开执行权限。我现在已经可以在一些耗时操作上完全放手，让它跑完整个批处理流程，但每轮结束后还是会抽查输出文件的时长和首尾内容。工具的目的是把时间还给你，而不是把判断力也一起带走。