1. 这个实验到底在测什么同一句提示词丢给两个模型让它们各自产出一期测评视频最后成片风格完全不同——这件事听起来像个趣味对比但真正动手跑一遍就会发现它暴露的是多模型协作流水线里最容易被忽略的一环模型不只是写文案的工具它同时决定了脚本结构、镜头节奏、素材取舍、甚至配乐情绪。换句话说你给的不是一句提示词你给的是一整套创作决策权而不同模型对这套决策权的行使方式差异极大。我这次做的事情本质上是搭了一条从提示词到成片的自动化视频生产链路用 Claude Code 作为调度中枢分别驱动 Opus 5.5 和 Sonnet 5.5 完成脚本生成、分镜拆解、素材清单输出再用 ffmpeg 把素材合成、转码、拼接成最终视频。整条链路里模型负责想,ffmpeg 负责做,Claude Code 负责串。三者缺一不可而模型这一环的差异会像涟漪一样扩散到后面每一个环节。这篇文章适合三类人看一是正在用 Claude Code 做自动化内容生产、想搞清楚不同模型该怎么分工的人二是想把 ffmpeg 接进 AI 工作流、但一直卡在命令能跑但不成体系的人三是单纯好奇同一句提示词为什么能产出两种风格、想自己复现一遍的人。不管你之前有没有用过 Claude Code只要你会敲终端命令、能看懂基本的视频参数这篇都能直接抄作业。我会把整条链路拆开讲为什么这么设计、每个环节的关键参数怎么定、ffmpeg 命令为什么这么写、两个模型的产出差异具体体现在哪、以及我踩过的那些坑。全程不藏私参数和命令都是实测能跑的。2. 整体链路设计与模型分工思路2.1 为什么用 Claude Code 做调度而不是直接调 API很多人第一反应是我直接写个 Python 脚本调 API 不就行了为什么要绕一层 Claude Code这个问题我一开始也纠结过实测下来结论很明确——当任务涉及多步骤、多工具、需要根据中间结果动态调整时Claude Code 的 agent 能力比裸调 API 省太多事。裸调 API 的痛点在于你得自己写编排逻辑先调一次生成脚本解析返回再调一次生成分镜再解析再拼 ffmpeg 命令……每一步的异常处理、格式校验、重试逻辑都得自己写。而 Claude Code 本身就是一个能读写文件、能执行终端命令、能根据执行结果决定下一步的 agent。你只要把任务描述清楚它会自己规划步骤、自己调用 ffmpeg、自己检查输出文件是否存在。具体到这次实验我的做法是在项目目录下放一个task.md描述任务然后让 Claude Code 读取它并执行。Opus 5.5 和 Sonnet 5.5 分别跑一遍同样的task.md产出物放在不同目录。这样对比才公平——输入完全一致只有模型不同。提示Claude Code 的安装方式在不同系统上略有差异。macOS 和 Ubuntu 下用官方脚本安装最省心Windows 下建议走 WSL避免路径和权限问题。安装完成后用claude --version确认版本再用claude进入交互模式做一次登录验证。2.2 两个模型的定位差异决定了产出风格在动手之前得先搞清楚 Opus 5.5 和 Sonnet 5.5 的定位。这不是玄学是实打实的取舍维度Opus 5.5Sonnet 5.5定位旗舰追求深度与完整性均衡追求速度与性价比推理深度更强倾向多轮自我审视够用倾向快速给出方案输出风格结构严谨、细节密集简洁直接、节奏明快适合场景复杂脚本、深度测评快速产出、批量生产响应速度相对慢相对快这个差异直接决定了它们做测评视频时的风格走向。Opus 5.5 倾向于把每个技术点都展开讲透脚本会长、分镜会细、素材清单会列得很全Sonnet 5.5 则倾向于抓重点、快节奏脚本更紧凑分镜数量少但每个镜头信息密度高。这不是谁好谁坏的问题是适配场景不同。我的建议是如果你做的是深度技术测评、需要经得起推敲的内容用 Opus 5.5如果你做的是快节奏的产品速览、需要批量出片用 Sonnet 5.5。两者甚至可以组合——用 Opus 出脚本框架用 Sonnet 做批量分镜填充。2.3 ffmpeg 在链路里承担什么角色ffmpeg 是这条链路的手。模型想得再好最终要变成视频文件靠的就是 ffmpeg。它负责的事情包括把图片序列合成视频、给视频加字幕、拼接多个片段、调整码率和分辨率、抽取音频、做转场。为什么选 ffmpeg 而不是别的因为它是命令行工具能被 Claude Code 直接调用不需要图形界面不需要人工干预。这一点在自动化链路里是决定性的。你不可能让 agent 去点鼠标操作剪辑软件但你可以让它执行ffmpeg -i input.mp4 ...。这里有个关键认知ffmpeg 命令的参数设计本身就是一种创作决策。比如-r 30和-r 24出来的视频节奏感完全不同-crf 18和-crf 28出来的画质和体积差异巨大。模型生成的 ffmpeg 命令其实反映了它对什么是好视频的理解。这也是为什么两个模型跑出来的成片风格会不同——它们连 ffmpeg 参数都选得不一样。3. 核心细节解析与实操要点3.1 提示词怎么写才能让模型产出可执行的分镜提示词是整个实验的起点也是最容易翻车的地方。我试过好几版最后稳定下来的结构是这样的你是一名视频测评博主。请针对 [产品名] 制作一期测评视频的完整制作方案。 要求输出 1. 视频脚本含旁白文案按时间轴分段 2. 分镜清单每个镜头的画面描述、时长、素材类型 3. 素材清单需要准备哪些图片/视频/音频 4. ffmpeg 合成命令基于素材清单给出可直接执行的命令 输出格式用 Markdown分镜用表格。这个提示词的关键在于强制结构化输出。如果你只说帮我做个测评视频方案模型会给你一堆散文式的描述你根本没法拿去做自动化。加上分镜用表格给出可直接执行的命令之后输出就变成了机器可解析的格式。实测下来Opus 5.5 会严格按这个结构输出而且分镜表会列到 15-20 个镜头每个镜头都有详细的画面描述和时长Sonnet 5.5 也会按结构输出但分镜通常只有 8-12 个描述更简短ffmpeg 命令也更精简。注意提示词里一定要明确可直接执行否则模型可能给你伪代码或者省略参数的示意命令。我踩过这个坑拿到一条ffmpeg -i input -o output这种缺参数的命令根本跑不起来。3.2 分镜到素材的映射逻辑分镜清单出来后下一步是把它变成实际素材。这一步的难点在于模型描述的画面你得能找到或生成对应的素材。我的处理方式是分三类纯色/渐变背景 文字直接用 ffmpeg 的color滤镜生成不需要外部素材图片素材提前准备好放在assets/目录分镜里用文件名引用视频片段同样放assets/用文件名引用模型在生成分镜时我会要求它明确标注每个镜头的素材来源。比如镜头3产品外观特写素材类型图片文件名product_front.jpg。这样后面拼 ffmpeg 命令时素材路径就是确定的。这里有个经验不要让模型自由发挥素材文件名否则它可能编造一个不存在的文件。我的做法是在提示词里附上assets/目录的实际文件列表让模型从已有文件里选。这样生成的命令一定能跑通。3.3 ffmpeg 关键参数的选择逻辑ffmpeg 参数多如牛毛但真正影响成片风格的就那么几个。我把它们整理成一张表方便对照参数作用常见取值风格影响-r帧率24 / 30 / 6024 电影感30 标准60 流畅-crf画质18-28越小画质越好体积越大-preset编码速度ultrafast-veryslow越慢压缩率越高-pix_fmt像素格式yuv420p兼容性最好-c:a音频编码aac通用-b:a音频码率128k / 192k影响音质-vf视频滤镜scale/fade/subtitles决定画面处理Opus 5.5 生成的命令倾向于用-crf 18 -preset slow追求画质Sonnet 5.5 倾向于-crf 23 -preset medium追求速度和体积平衡。这个差异在成片上是能看出来的——Opus 的片子更细腻Sonnet 的片子文件更小。关于-pix_fmt yuv420p这个参数我一定要单独说如果你不加它生成的视频在某些播放器上会显示异常或者根本无法播放。这是新手最容易踩的坑因为 ffmpeg 默认可能用 yuv444p兼容性差。养成习惯合成命令里永远带上-pix_fmt yuv420p。3.4 字幕处理的关键细节测评视频离不开字幕。ffmpeg 加字幕有硬字幕和软字幕两种方式硬字幕用subtitles滤镜烧进画面兼容性最好但不可关闭软字幕用-c:s mov_text封装进容器可开关但部分播放器不支持自动化链路里我推荐硬字幕因为不依赖播放器。命令大概长这样ffmpeg -i input.mp4 -vf subtitlessub.srt:force_styleFontSize24,PrimaryColourHFFFFFF -c:a copy output.mp4force_style里的参数控制字体大小和颜色。PrimaryColour用的是HAABBGGRR格式注意是 BGR 不是 RGB这个反直觉的点坑过不少人。白色是HFFFFFF黑色是H000000。提示字幕文件建议用 UTF-8 编码保存否则中文可能乱码。如果字幕时间轴和视频对不上先用ffprobe查一下视频的实际时长和帧率再调整 srt 里的时间戳。4. 实操过程与核心环节实现4.1 环境准备与目录结构先把环境搭起来。我用的是一台 Ubuntu 机器Claude Code 和 ffmpeg 都装在系统里。目录结构这样组织video-project/ ├── task.md # 任务描述 ├── assets/ # 素材目录 │ ├── product_front.jpg │ ├── product_side.jpg │ └── bgm.mp3 ├── output-opus/ # Opus 产出 └── output-sonnet/ # Sonnet 产出ffmpeg 的安装Ubuntu 下直接apt install ffmpeg就行。但要注意apt 源里的版本可能比较老某些新滤镜不支持。如果需要最新版去官网下载静态编译的二进制文件解压后把ffmpeg和ffprobe放到/usr/local/bin/下即可。验证安装ffmpeg -version ffprobe -version两个命令都能输出版本信息就说明装好了。ffprobe是 ffmpeg 套件里的分析工具后面查视频信息全靠它。4.2 让 Claude Code 执行任务环境好了之后进入项目目录启动 Claude Codecd video-project claude然后在交互界面里输入请读取 task.md按照里面的要求完成视频制作方案并把产出物写入 output-opus/ 目录。这里有个技巧明确指定输出目录。如果你不说模型可能把文件写到当前目录两个模型的产出会混在一起没法对比。指定目录后Opus 的产出全在output-opus/Sonnet 的全在output-sonnet/清清爽爽。Claude Code 执行过程中会调用 ffmpeg。你可以在它执行时观察终端输出看它实际跑了哪些命令。这一步很重要因为你能直观看到两个模型选的参数差异。4.3 Opus 5.5 的产出实录Opus 5.5 跑完大概花了三分钟。产出的脚本文件有 2000 多字分镜表列了 18 个镜头。我摘几个关键镜头给你看镜头画面描述时长素材1黑屏淡入标题文字居中3s纯色背景文字2产品正面特写缓慢推近5sproduct_front.jpg3产品侧面展示配旁白介绍材质6sproduct_side.jpg............18结尾字幕背景音乐渐弱4s纯色背景文字它生成的 ffmpeg 合成命令是这样的ffmpeg -f lavfi -i colorcblack:s1920x1080:d3 \ -vf drawtexttext产品测评:fontsize72:fontcolorwhite:x(w-text_w)/2:y(h-text_h)/2,fadein:0:30 \ -c:v libx264 -crf 18 -preset slow -pix_fmt yuv420p \ -r 30 -t 3 clip01.mp4注意几个细节-crf 18 -preset slow是画质优先的配置fadein:0:30做了 30 帧的淡入-r 30用了 30 帧率。整个命令结构清晰参数完整直接能跑。4.4 Sonnet 5.5 的产出实录Sonnet 5.5 跑完只花了一分半。脚本 1200 字左右分镜表 10 个镜头。同样摘几个镜头画面描述时长素材1标题快闪2s纯色背景文字2产品正面4sproduct_front.jpg3产品侧面4sproduct_side.jpg............10结尾3s纯色背景文字它的 ffmpeg 命令ffmpeg -f lavfi -i colorcblack:s1920x1080:d2 \ -vf drawtexttext产品测评:fontsize64:fontcolorwhite:x(w-text_w)/2:y(h-text_h)/2 \ -c:v libx264 -crf 23 -preset medium -pix_fmt yuv420p \ -r 30 -t 2 clip01.mp4对比很明显-crf 23 -preset medium是速度优先没有淡入效果字体小一点镜头短一点。整体节奏更快但细节少一些。4.5 拼接与最终合成单个镜头生成后用 ffmpeg 的concat协议拼接。先写一个list.txtfile clip01.mp4 file clip02.mp4 ... file clip18.mp4然后ffmpeg -f concat -safe 0 -i list.txt -c copy final.mp4-c copy表示不重新编码直接复制流速度极快。但前提是所有片段的编码参数一致分辨率、帧率、编码格式都相同。如果参数不一致就得去掉-c copy让它重新编码ffmpeg -f concat -safe 0 -i list.txt -c:v libx264 -crf 20 -pix_fmt yuv420p final.mp4最后加背景音乐ffmpeg -i final.mp4 -i assets/bgm.mp3 -c:v copy -c:a aac -b:a 192k -shortest output.mp4-shortest保证音频在视频结束时截断不会出现视频放完了音乐还在响的情况。5. 常见问题与排查技巧实录5.1 ffmpeg 命令报错速查实操中遇到的报错我整理成一张表方便对照排查报错信息原因解决方法No such file or directory素材路径错误检查相对路径用绝对路径更稳Invalid argument参数格式错误检查滤镜语法特别是引号嵌套Unknown encoder编码器未安装换用 libx264 或重装完整版 ffmpegmoov atom not found文件损坏或未写完重新生成素材height not divisible by 2分辨率奇数用 scale 滤镜调整为偶数Fontconfig error字体未找到指定字体文件路径或用系统已有字体height not divisible by 2这个坑特别常见。H.264 编码要求宽高都是偶数如果你用scale1921:1081就会报错。解决办法是scale1920:1080或者scaletrunc(iw/2)*2:trunc(ih/2)*2。5.2 模型产出不可执行怎么办有时候模型会生成跑不通的命令常见原因有三个素材文件名编造模型不知道你实际有哪些文件瞎编一个。解决办法是在提示词里附上素材列表。滤镜语法错误特别是drawtext里的引号嵌套模型容易写错。解决办法是让它先输出命令你手动验证一遍再执行。参数冲突比如同时指定了-t和-shortest行为不确定。解决办法是精简参数只保留必要的。我的经验是不要盲目信任模型生成的命令尤其是第一次跑的时候。先让它输出命令你复制到终端里手动跑一遍确认没问题再让它批量执行。这样虽然慢一点但能避免批量翻车。5.3 两个模型产出差异的量化对比为了让你更直观地看到差异我把关键指标列出来指标Opus 5.5Sonnet 5.5脚本字数约 2200 字约 1200 字分镜数量18 个10 个总时长约 95 秒约 55 秒平均镜头时长5.3 秒5.5 秒crf 取值1823presetslowmedium成片体积约 45MB约 18MB生成耗时约 3 分钟约 1.5 分钟这个对比说明一个事Opus 5.5 用更多的时间和体积换取了更完整的表达Sonnet 5.5 用更少的资源换取了更快的产出。没有绝对优劣看你的需求。5.4 独家避坑技巧几个我从踩坑里总结出来的经验常规文档里不会写ffmpeg 的-ss和-t位置很关键。放在-i前面是快速定位关键帧级别放在后面是精确裁剪解码级别。做精确剪辑时放后面做快速预览时放前面。drawtext的中文字体问题。默认字体可能不支持中文会显示成方块。解决办法是用fontfile参数指定一个支持中文的字体文件比如fontfile/usr/share/fonts/truetype/wqy/wqy-zenhei.ttc。批量生成时加-y参数。否则 ffmpeg 遇到已存在的输出文件会交互式询问是否覆盖自动化链路会卡住。用ffprobe验证产出。生成完一个片段后用ffprobe -v error -show_entries formatduration -of defaultnoprint_wrappers1:nokey1 clip01.mp4查时长确认符合预期再继续。Claude Code 执行长任务时注意超时。如果单个 ffmpeg 命令跑太久可能会触发超时。解决办法是把长任务拆成多个短命令分步执行。6. 模型选型与工作流优化建议6.1 什么场景用哪个模型基于这次实验我给出一个实用的选型建议深度技术测评、需要经得起推敲的内容用 Opus 5.5。它的脚本更完整分镜更细参数更保守画质优先适合做精品。产品速览、批量内容生产用 Sonnet 5.5。它产出快体积小节奏紧凑适合做量。混合工作流用 Opus 5.5 生成脚本框架和关键分镜用 Sonnet 5.5 填充常规镜头和批量合成。这样兼顾质量和效率。这个建议不是拍脑袋是从实测数据里来的。你可以根据自己的内容定位调整。6.2 把 ffmpeg 封装成可复用脚本每次让模型生成完整 ffmpeg 命令其实有点浪费。更好的做法是把常用操作封装成 shell 脚本模型只需要调用脚本并传参。比如#!/bin/bash # make_clip.sh - 生成单个文字镜头 # 用法: ./make_clip.sh 文字内容 时长 输出文件 TEXT$1 DURATION$2 OUTPUT$3 ffmpeg -y -f lavfi -i colorcblack:s1920x1080:d$DURATION \ -vf drawtexttext$TEXT:fontsize72:fontcolorwhite:x(w-text_w)/2:y(h-text_h)/2,fadein:0:30,fadeout:st$(($DURATION-1)):d1 \ -c:v libx264 -crf 20 -preset medium -pix_fmt yuv420p \ -r 30 -t $DURATION $OUTPUT这样模型只需要生成./make_clip.sh 产品测评 3 clip01.mp4这样的调用出错概率大大降低。而且脚本可以版本控制团队协作时统一标准。6.3 关于 ffmpeg 编码器选择的补充ffmpeg 支持多种 H.264 编码器常见的有libx264、h264_nvencNVIDIA 显卡加速、h264_qsvIntel 核显加速。选择哪个取决于你的硬件没有独显用libx264CPU 编码兼容性最好有 NVIDIA 显卡用h264_nvenc速度快很多但画质略逊于 libx264 同码率有 Intel 核显用h264_qsv速度介于两者之间切换编码器时参数名会变。比如-crf在 nvenc 里对应-cq-preset的取值也不同。这个要注意不能直接照搬。提示如果你在 Ubuntu 上装了 NVIDIA 驱动但 nvenc 用不了先确认 ffmpeg 编译时是否启用了 nvenc 支持。用ffmpeg -encoders | grep nvenc查一下如果没有输出说明当前 ffmpeg 不支持需要换一个编译版本。6.4 后续可以扩展的方向这条链路跑通之后能扩展的地方很多。比如把素材生成也自动化——用图像生成模型产出分镜所需的图片直接喂给 ffmpeg或者接入语音合成把旁白文案变成音频省去录音环节再或者做一个 Web 界面输入产品名就能一键出片。我个人最想试的是把分镜表和 ffmpeg 命令做成模板模型只负责填充内容命令结构固定。这样既能保证可执行性又能保留模型的创作空间。等跑顺了再回来分享。最后分享一个我在实操中的体会模型之间的差异在单次任务里可能只是风格不同但在批量生产里会被放大成数量级的效率差异。选对模型比调优提示词更重要。而 ffmpeg 这条链路一旦跑通一次后面就是复制粘贴的事前期多花点时间把参数和脚本打磨好后面省下的时间远超投入。