本文由 辛梓煜@词元2号站（www.ciyuanerhao.com）撰写，转载请注明出处。

快速摘要

一句话结论：大模型天生会读文字、会看代码、会翻网页，唯独不会"看视频"。一个叫 claude-video 的开源项目给 Claude Code 补上了这块短板——它加了一个 /watch 命令，把视频拆成三样模型真正能吃进去的材料：按时间戳对齐的字幕（听觉）、抽取出来的关键画面帧（视觉）、以及贯穿两者的时间线，再一并丢给 Claude。于是模型回答的时候，不再是"看着标题瞎猜"，而是"画面我看过、声音我听过"，答得像一个真的把视频从头看到尾的人。

它的技术栈很朴素：yt-dlp 负责下载、ffmpeg 负责抽帧、字幕优先走视频自带的免费字幕、没字幕才退回 Whisper 语音转文字，最后由 Claude 的多模态能力把画面和文字揉在一起做判断。整个项目 MIT 协议开源，写作本文时已经收获了数千 Star，安装几乎零配置。

如果你经常要拆解爆款视频、看录屏排查 bug、把长视频压成学习笔记——这套东西能帮你省下大量"手动拖进度条"的时间。更妙的是,它安装几乎零门槛,常见视频还免费(有字幕就不花转写的钱),等于是用极低的成本,给你的 AI 补上了一只一直缺席的"眼睛"。想看完整拆解（含安装、六步流水线、帧预算省钱技巧、参数边界和可迁移的设计思路），往下翻。

一、结论先行：AI 到底能不能"看"视频

先把话说透。现在的大模型，处理"文字类"输入已经相当成熟：给它一段网页、一份文档、一整个代码仓库，它都能读进去、理解、再输出。但视频这个输入，一直是个尴尬的缺口。

你把一个视频链接丢给它，多数情况下它能拿到的东西非常有限：一个标题、一段简介，运气好的话再加一份字幕。可问题在于——视频里最值钱的信息，往往根本不在字幕里。

我第一次真切意识到这个缺口，是有回想偷懒：把一条十几分钟的技术演示视频链接直接甩给 AI，让它帮我总结。结果它回了一大段听着很顺、实则全是套话的东西——因为它压根没看过画面，只能顺着标题和简介往下编。那一刻我才明白：在"看视频"这件事上，AI 之前的表现更像是"读了个封面就来跟你聊剧情"。 顺，但空。而 /watch 要补的，正是这块从"封面"到"内容"的鸿沟。

举个我自己常遇到的例子。一个技术演示视频，博主嘴上说"点这里、再点那里，结果就出来了"，字幕里全是"这里""那里"这种指代词，脱离画面就是一堆废话。再比如一段录屏 bug 复现，真正的报错信息是一闪而过地出现在屏幕右下角的，字幕里一个字都不会提。这类内容，画面和声音必须一起看，缺一样都读不懂。

所以"AI 能不能看视频"这个问题，答案得拆成两层：

• 如果"看"只是"读字幕再总结一下",那大部分工具早就能做,但天花板很低;
• 如果"看"是指同时理解画面里发生了什么 + 声音里说了什么 + 两者在时间轴上怎么对应,那绝大多数现成方案都做不到。

claude-video 这个开源项目,解决的正是第二层。它给 Claude Code 挂上一个 /watch 能力,让你可以像丢网页链接一样丢一个视频过去,然后正常提问。辛梓煜@词元2号站实测下来,它最大的价值不是"又多了个视频总结器",而是把"视频"这种模型原本吃不动的输入,翻译成了模型能读懂的材料。这个思路,后面第九节我会专门展开,因为它其实是一套能迁移到很多地方的通用套路。

二、为什么"只读字幕"远远不够

市面上打着"AI 看视频""视频总结神器"旗号的工具不少,但你稍微深挖一下就会发现,它们里面相当一部分本质上只是"视频转文字"。也就是先把音频转成字幕,再让模型基于这段文字做总结。

这条路有它的好处:快、便宜。对于播客、访谈、脱口秀这种"一个人对着镜头讲"的内容,音频里几乎承载了全部信息,只读字幕确实够用。

但一旦内容的重心跑到画面上,纯字幕方案就会露馅。我给你列几类典型的"字幕读不懂"的视频:

• 产品演示 / 软件教程:关键在于"界面长什么样、点了哪个按钮、弹出了什么",字幕里往往只有"点这个""看这里"。
• 录屏排 bug:报错、异常状态、UI 错位,都是纯视觉信息,音频里可能只字未提。
• PPT 课程 / 知识讲解:核心信息全印在幻灯片上,讲师嘴里说的只是补充。
• 爆款短视频拆解:开头三秒的钩子(hook)、画面节奏、字幕特效、镜头切换——这些"为什么会火"的密码,统统藏在画面里。
• 数据可视化 / 图表讲解:一张图胜过千言,而字幕描述不了那张图。

说到底,这是多模态(multimodal,指模型能同时处理文字、图像等多种信息形态)本身的要求。既然 Claude 这类模型本来就能"看图"+"读字",那正确的喂法就应该是画面和字幕一起端上桌,让它综合判断,而不是只递一份文字稿让它硬猜画面。

claude-video 的玩法恰好卡在这个点上:它不满足于把视频变成一段文字,而是把视频拆成"带时间戳的字幕 + 一批关键画面帧",两样材料一起交给模型。差别就在这——一个是"我读了别人的会议纪要",另一个是"我亲自参加了会议"。

2.1 拿一个具体例子感受差距

假设有条一分钟的产品短视频,画面里一个人在演示某款笔记软件的"一键归档"功能,嘴里只说了一句"看,这样就整理好了"。

• 纯字幕工具读到的是:"看,这样就整理好了。"——它能告诉你"这段在讲整理功能",但归档按钮长什么样、点完之后界面怎么变、归档到哪去了,它一无所知。
• 画面 + 字幕一起看的做法:模型不仅读到那句话,还看到了"鼠标点击右上角的归档图标→列表里的条目滑入侧边栏的归档夹→顶部弹出一个'已归档 12 项'的提示"。于是它能给你复原出完整的操作步骤,而不是一句正确的废话。

这就是"读会议纪要"和"亲自参会"的区别,落到一分钟视频上的样子。

2.2 两类方案的能力边界对照

我把"纯转写方案"和"画面+字幕方案"的差别列成一张表,方便你判断手上的活儿该用哪种:

看完这张表,选型思路其实很清晰:信息主要在嘴上,就用便宜的转写;信息主要在屏幕上,就得让它"看画面"。 claude-video 的价值,就是把后者做得又顺手又克制。

2.3 为什么这件事对做内容的人尤其重要

我想额外提醒一类人:靠内容吃饭的创作者、研究者、产品经理。 对你们来说,"看懂别人的视频"不是消遣,而是刚需——你得知道爆款为什么爆、竞品怎么演示、某个手法为什么好使。而这些"为什么",十有八九藏在画面的节奏、字幕的特效、镜头的切换里,恰恰是纯字幕最读不出来的部分。

过去这活儿只能靠人肉逐帧拉片:一遍遍拖进度条、暂停、记笔记,效率极低。有了能"看画面 + 读字幕"的工具,你等于把"逐帧拉片"这件苦差事外包给了 AI,自己专注在"从复盘里提炼可复用的方法"上。辛梓煜@词元2号站做内容这些年,最大的体会就是:能把机械的拉片环节自动化,省下的时间才是真正能拉开差距的地方。

三、这个 /watch 能力到底是什么

把背景铺完,我们来看主角本身。

claude-video 是开发者 Brad Bonanno 做的一个开源项目,采用 MIT 协议(意味着你可以自由使用、修改甚至商用,只要保留许可声明)。它的核心产物,是给支持 Agent Skills 的工具挂上一个叫 /watch 的斜杠命令。写作本文时,这个项目在 GitHub 上已经积累了数千 Star,热度不低。

它的用法简单到几乎不用学。你给它一个网络视频链接,或者一个本地视频文件路径,再顺手把你的问题跟在后面就行。比如:

# 问某个时间点画面里发生了什么
/watch https://youtu.be/xxxx 视频里 30 秒的地方发生了什么?

# 让它总结一整段视频
/watch https://www.tiktok.com/@someone/video/123 帮我总结这个视频

# 对着本地录屏定位问题
/watch ~/Movies/screen-recording.mp4 界面是在哪一步崩掉的?

有几个点值得单独强调:

• 输入不挑来源。因为底层用的是 yt-dlp(后面会解释,一个支持上千个网站的命令行下载器),所以 YouTube、TikTok、X(推特)、Instagram、Vimeo、Loom 等一大堆平台的公开视频它都能吃;本地文件则支持 .mp4、.mov、.mkv、.webm 等常见格式。
• 它不是单纯的下载器,也不是单纯的转写器。下载和转写只是中间步骤,它真正干的事是"把画面帧和字幕一起塞给 Claude,让模型基于真实看到的内容作答"。
• 它明确不碰需要登录的私有内容。这个 Skill 不会帮你登录任何账号,只处理公开链接和本地文件——这既是能力边界,也是一条合规底线。

一句话概括:/watch 把"看视频"这件原本得靠你亲自坐在屏幕前干的事,变成了一条可以交给 AI 的命令。

3.1 顺便解释几个新手容易懵的名词

为了让完全没接触过这类工具的读者也能跟上,我把上面出现的几个词用大白话过一遍:

• Skill(技能包):可以理解成给 AI Agent 装的一个"插件",装上之后它就多了一项本领。claude-video 装上,Claude Code 就多了"看视频"这项本领。
• 斜杠命令(slash command):就是以 / 开头、你在对话框里直接敲的快捷指令,像 /watch 这样。它其实是从这个 Skill 的配置文件(SKILL.md)里自动派生出来的,你不用手动再定义一遍。
• MIT 协议:一种非常宽松的开源许可证。通俗说就是:随便用、随便改、能商用,唯一的义务是保留原作者的许可声明。对使用者非常友好。
• yt-dlp 的覆盖面:它号称支持上千个视频站点,所以你别以为它只认 YouTube。国内外常见的平台、大量小众站点,乃至很多网页里内嵌的视频,它多半都能抓下来。

3.2 它不是"又一个下载器"

我特别想强调一遍这点,因为很多人第一眼会把它误当成下载工具。下载和转写在这里都只是手段,不是目的。目的是"让 Claude 基于真实看到、听到的内容作答"。下载器把视频存到你硬盘上就结束了,而 /watch 干完下载才刚开了个头——后面还有抽帧、转写、喂给模型、综合作答一整套。判断一个视频类工具值不值得用,就看它止步于"转成文字",还是走到了"让模型真正理解"。

四、五分钟上手:安装与第一次运行

这一节偏实操。整体安装体验属于"零配置起步"那一类,第一次跑的时候它会自己检查环境、缺什么给你补什么。

4.1 挑一种安装方式

它支持好几种宿主环境,你按自己用的工具对号入座即可。下面这张表把主流方式整理清楚:

如果你嫌上面这些命令记不住,还有个更省事的偷懒法:直接把项目地址丢给你的 Claude Code,让它自己装。比如发一句:

帮我安装这个 skill:https://github.com/bradautomates/claude-video

它会自己去读文档、按你的系统执行对应步骤。

有一个容易被漏掉的前提:在 claude.ai 网页版里,你得先在 Capabilities 里把 "Code execution and file creation"(代码执行与文件创建) 打开。因为这个 Skill 干活时要在后台调用 ffmpeg 和 yt-dlp 这两个命令行工具,不开这个开关,它根本跑不起来。

4.2 第一次运行:它会替你检查环境

你第一次敲 /watch 的时候,Skill 会先跑一段自检脚本(setup.py --check),看你机器上该有的东西齐不齐,主要是两样命令行工具:

• ffmpeg:多媒体处理界的瑞士军刀,负责从视频里抽画面帧、切音频。
• yt-dlp:一个功能强大的命令行视频下载器(老牌 youtube-dl 的活跃分支),支持上千个站点。

如果这两样不在你的 PATH 里,自检脚本会按你的操作系统给出对应的补救方案:

• macOS:直接自动帮你跑 brew install ffmpeg yt-dlp(brew 是 mac 上常用的包管理器);
• Linux:打印出精确的 apt / dnf / pipx 安装命令,你复制执行即可;
• Windows:打印 winget / pip 命令。

装好之后,后续再用就是"静默通过",自检是个毫秒级的小动作,不会拖慢你。

4.3 没字幕怎么办:配一把 Whisper 钥匙

大多数公开视频自带字幕(手动上传的或平台自动生成的),这种情况完全免费,也最快。但总有一些视频压根没有字幕——常见于本地录屏、部分 TikTok、少数 Vimeo,以及个别没配字幕的 YouTube 上传。

遇到这种情况,Skill 会退回到 Whisper(OpenAI 开源的语音识别模型,能把音频转成文字)。它需要你配一个 API Key,自检脚本会在 ~/.config/watch/.env 这个配置文件里给你留好带注释的占位符(文件权限还贴心地设成了 0600,只有你自己能读写):

• 优先支持 Groq 的 whisper-large-v3(更便宜也更快,官方推荐);
• 也支持 OpenAI 的 whisper-1;
• 如果你压根不想转写,加个 --no-whisper 参数,让它只抽画面帧就行。

顺带解释下为什么默认推荐 Groq。Whisper 是模型本身,而"跑这个模型的地方"可以有很多家。Groq 以极快的推理速度著称,跑同一个 whisper-large-v3,它往往又快又便宜;OpenAI 官方的 whisper-1 则是更标准的选择。对绝大多数人来说,优先 Groq、把 OpenAI 当备胎是个稳妥的默认。真正要记住的重点其实只有一句:只要视频有字幕,这整块转写成本你根本不会碰到。 转写只是"没字幕时的兜底",不是常态开销。

4.4 一个真实的小例子

说个我自己跑过的场景。我手里有一个六分钟的、讲"某开源去马赛克项目"的介绍视频,我想把它整理成一份图文并茂的学习笔记。命令大概长这样:

/watch 介绍某开源项目的视频.mp4 请基于这个视频整理成一份图文笔记

它会先反过来问我两个澄清问题:帧密度要多高、要不要一并分析字幕。确认之后,它读了几十帧画面 + 音频字幕,对视频讲了啥有了整体把握,最后产出的笔记内容逻辑就顺畅很多——因为它是真"看"过,而不是对着标题编。辛梓煜@词元2号站的体会是:这一步"先问帧密度和字幕"的设计很关键,它把 token 花在哪、精细到什么程度的决定权交回给了你。

4.5 几个常见的坑,提前给你避掉

第一次装、第一次跑,难免磕磕绊绊。把我和身边人踩过的坑归拢一下:

• 忘了开"代码执行"开关。 网页版最常见的翻车点。没开这个,/watch 调不动 ffmpeg/yt-dlp,直接罢工。装完先检查这个开关。
• Windows 上 python3 找不到。 有些 Windows 环境里 python3 是个空壳(Microsoft Store 的占位程序),跑不了脚本,得改用 python 或 py,并确保装的是正规 Python。
• 明明有网却下载失败。 有可能是本机网络策略挡住了对应站点。这种情况先确认你的网络设置允许访问该资源,再重试。
• 视频没字幕又没配 Whisper Key。 结果就是只有画面、没有文字。要么给它配上 Groq/OpenAI 的 Key,要么明确用 --no-whisper 告诉它"我就只要画面"。
• 长视频转写超限。 Whisper 单次上传有 25 MB 上限(约 50 分钟音频),更长的要靠自带字幕,或者用 --start/--end 切小段。

一个通用心法:它的自检脚本很懂事,报错时通常会直接把该敲的命令打给你,照着复制执行,大概率就好了。

五、完整流水线:六步拆解

这一节讲原理。它的实现思路其实不复杂,但每一步的组合都挺讲究——核心逻辑是能省则省,该细则细。先上一张整体流程图,建立一个直观印象:

flowchart TD
    A["你: 视频(URL/本地) + 问题"] --> B{"是网络链接吗?"}
    B -- 是 --> C["yt-dlp 下载到临时目录"]
    B -- 本地文件 --> D["就地探测, 不下载"]
    C --> E["ffmpeg 按时长自动抽帧"]
    D --> E
    E --> F{"视频自带字幕?"}
    F -- 有 --> G["直接取字幕(免费/最快)"]
    F -- 没有 --> H["切 16kHz 单声道音频 → Whisper 转写"]
    G --> I["画面帧 + 带时间戳字幕"]
    H --> I
    I --> J["交给 Claude: 逐帧 Read 成图像 + 读字幕"]
    J --> K["基于真实画面与声音作答"]
    K --> L["打印工作目录, 不追问就清理"]

拆开来说,一共六步。

第一步,你抛出视频和问题。 输入可以是任意 yt-dlp 支持的网络链接,也可以是本地路径。命令的形态就是 /watch <视频> <你的问题>。

第二步,yt-dlp 负责取源。 如果是网络链接,它会把视频下载到一个临时工作目录;如果是本地文件,那就不下载了,直接就地探测。这一步决定了它"支持哪些平台"——只要 yt-dlp 覆盖的站点,它基本都能处理。

第三步,ffmpeg 按时长自动抽帧。 这是整套流程里最见功力的地方。它不是傻乎乎地每隔几秒截一张,而是根据视频长度动态决定抽多少帧(auto-fps 逻辑)。默认抽出来的是 512 像素宽的 JPEG 图;如果你要让模型看清屏幕上的小字(幻灯片、终端、代码),可以用 --resolution 1024 把分辨率拉高。抽帧的具体预算策略,值得单开一节讲,放在第六节。

第四步,拿字幕,两条路。 优先走第一条:让 yt-dlp 直接从视频源里扒下原生字幕(不管是人工字幕还是自动生成的),这条路免费、瞬时、准确度也够用。只有当视频确实没有字幕时,才走第二条:切出一段 16kHz 单声道音频,送去 Whisper 转写(Groq 的 whisper-large-v3 优先,OpenAI 的 whisper-1 备选)。

第五步,把画面帧 + 字幕一起交给 Claude。 脚本会打印出每一帧的路径,并标上 t=MM:SS 这样的时间戳标记,字幕也带着时间戳。Claude 会并行地把每一帧 Read 成图像喂进上下文(JPEG 直接当图片渲染),再配上字幕文字。到这一步,模型手里就同时握着"这一秒画面长什么样"和"这一秒说了什么"。

第六步,作答并清理。 Claude 基于真实看到、听到的内容回答你——不是"根据简介",也不是"根据标题"。脚本最后会打印出工作目录;如果你不打算继续追问,它会把临时文件清理掉,不留垃圾。

5.1 再抠两个关键细节

上面六步是主干,有两个地方值得单独抠一下,因为它们决定了体验好不好。

一个是"自动帧率"(auto-fps)到底在算什么。 简单说,它先探测视频总时长,再对照一张预设的"时长→帧数"预算表(下一节会详列),反推出"每秒该抽几帧"。短视频每秒可以抽满,长视频则自动稀释——目标是让总帧数落在预算内,而不是机械地按固定间隔截图。这一步是整套设计"既够用又省钱"的核心。

另一个是"逐帧 Read 成图像"是并行的。 抽完帧之后,脚本会把每一帧的路径连同 t=MM:SS 时间戳一起列出来,Claude 会并行地把这些 JPEG 读进上下文当图片处理。也就是说,它不是一张张慢慢看,而是几十张画面同时进脑子,再叠上带时间戳的字幕。这样它在回答"1 分 20 秒时画面在干嘛"这类问题时,才能把"那一秒的画面"和"那一秒的话"精准对上。

5.2 用一段伪代码把主干串起来

如果你习惯看代码,下面这段极简伪代码能帮你把整条链路一眼看穿:

def watch(video, question, start=None, end=None):
    src = yt_dlp_fetch(video)                 # 网络链接则下载, 本地文件就地探测
    frames = ffmpeg_extract(                  # 按时长自动定帧率
        src, auto_fps=True, cap_fps=2, cap_frames=100,
        window=(start, end), width=512,
    )
    frames = dedupe(frames)                   # 去掉近似重复的画面
    transcript = native_captions(src)         # 优先: 免费自带字幕
    if transcript is None:                    # 兜底: 没字幕才转写
        transcript = whisper(extract_audio(src, mono=True, hz=16000))
    return claude_read(frames, transcript, question)   # 画面+字幕一起交给模型

真实脚本当然比这复杂得多(错误处理、清理、参数覆盖等等),但骨架就是这么回事:取源 → 抽帧 → 去重 → 拿字幕(自带优先、转写兜底)→ 交给模型。

5.3 关于"工作目录"和善后

有个容易被忽略但很贴心的细节:整个过程产生的临时文件(下载下来的视频、抽出来的一堆帧图、切出来的音频等等)都会落在一个临时工作目录里,脚本跑完会把这个目录路径打印出来。

它的善后逻辑是这样的:如果你还打算就这个视频继续追问,它会把工作目录留着(这样追问时不用重新下载、重新抽帧,省时省钱);如果你不再追问了,它会主动把这些临时文件清理掉,不给你的硬盘留垃圾。你也可以用 --out-dir 指定一个固定目录,方便你自己事后翻看那些帧图。

这个"用完即走、需要就留"的设计,虽然不起眼,却体现了作者对使用体验的用心——好工具不光要能干活,还得懂得收拾自己的摊子。 尤其是处理隐私相关的私人录屏时,这种自动清理能让你少操不少心。

你会发现,这套流程读起来像"绕了一大圈":下载、抽帧、转写、再喂给模型。但它非常契合当下 AI 工具的现实——模型不一定原生支持你随手丢进去的任意视频,可你完全能把视频拆成模型消化得了的图片、文字和时间线。 绕的这一圈,恰恰是把不可能变成可能的那一圈。

六、最容易被忽略的一环:帧预算与 token 成本

如果说前面五节讲的是"怎么让它能干活",这一节讲的就是"怎么让它别把你的钱包干爆"。而这恰恰是很多人第一次用视频类 AI 工具时最容易踩的坑。

6.1 为什么帧数直接等于成本

先说个反直觉的事实:在这套流程里,真正吃 token 的大头不是字幕,而是画面帧。原因很简单——每一帧都是一张图片,而图片转成 token 的消耗,比同等信息量的文字高得多,而且堆起来非常快。

想象一下:一段 30 秒的短视频,你截几十帧,还好;可要是你丢一个 50 分钟的长视频进去,再每隔几秒截一张,那图片 token 会像滚雪球一样堆到你怀疑人生。所以帧预算(frame budget)不是可有可无的优化项,而是决定这工具能不能实用的命门。

6.2 按时长自动分配帧预算

claude-video 的做法是:视频越短,给的帧越密;视频越长,自动抽得越稀。 它把这套策略固化成了一张时长与帧数的对照关系:

同时它设了两条硬上限:最高 2 fps(每秒最多 2 帧)、总帧数最多 100 帧。哪怕自动算法算出来"应该抽更多",脚本也会强行卡在这两条线以内。说白了,这是替你的钱包踩了脚刹车。

6.3 去重:别为几乎一样的画面重复付钱

光控制总量还不够。像录屏、PPT 课程这种视频,经常一个画面能停很久——讲师对着一页幻灯片讲三分钟。如果你老老实实每隔几秒截一张,截出来的十几帧其实几乎长得一模一样,为这些重复画面付 token 纯属浪费。

所以它还加了一轮帧去重。做法很巧:把每一帧缩成一张极小的灰度缩略图,比较相邻帧之间的亮度差异,把那些近似重复的画面直接丢掉。这样一来,有限的帧预算就能尽量花在真正发生了变化的画面上。用一段伪代码表达这个思路大概是这样:

prev = None
kept_frames = []
for frame in all_frames:
    thumb = to_grayscale_thumbnail(frame)      # 缩成极小灰度图
    if prev is None or brightness_diff(thumb, prev) > 阈值:
        kept_frames.append(frame)              # 有明显变化才留下
        prev = thumb
    # 否则视为近似重复, 丢弃

6.4 聚焦模式:只看你真正关心的那一段

对于长视频,与其对全片来一次稀疏扫描,不如告诉它"我只关心某一段"。当你在问题里点名了某个时刻——"2 分 30 秒左右""最后 30 秒""从 0:45 到 1:00"——就可以用 --start / --end 参数框定范围。

聚焦模式下,它会在这一小段里给出更密的每秒帧预算(依然不超过 2 fps 的硬顶)。 效果往往比"整片扫一遍"有用得多,token 还花得更少。这也是辛梓煜@词元2号站最推荐的用法:别让它盲扫全片,精确制导地问。

6.5 抽帧不止一种"抽法"

除了"抽多少帧",还有"怎么挑这些帧"的问题,而这直接决定了你抽到的画面有没有信息量。它提供了几种不同的抽帧策略(detail 模式),各有取舍:

• efficient(高效):走更快的关键帧提取路线。速度快、成本低,适合"我只想快速扫一眼、了解个大概"的场景。
• balanced(均衡)/ token-burner(不惜 token):更偏向场景变化帧——也就是靠检测"画面何时发生明显变化"来决定在哪抽帧。这样抽出来的帧更能踩在"剧情/画面转折点"上,信息密度更高,代价是更费 token。
• 兜底的均匀采样:当上面两种都不适用时,退回到"按固定间隔均匀截图"的最朴素方式。

一个直觉:内容平淡、变化少的视频,efficient 就够;画面切换频繁、你又不想漏掉关键转折的,才值得上 balanced 或 token-burner。 挑对模式,比盲目加帧数更划算。要提醒的是,即便是最"舍得花"的模式,前面说的 2 fps、100 帧硬顶依然管着它,不会真的失控。

6.6 分辨率:清晰度和成本的又一道权衡

帧数之外,每帧的分辨率也是一个影响成本的旋钮。默认抽出来的帧是 512 像素宽的 JPEG——对于"看清大致画面、人物动作、场景切换"已经足够,而且省。但如果视频里有你需要模型读出来的小字——幻灯片正文、终端里的命令、代码行——512 宽可能就糊了,这时候用 --resolution 1024 把宽度翻倍,模型才认得清。

这里的取舍逻辑很朴素:分辨率越高,单帧信息越清晰,但单帧 token 也越贵。 所以别一上来就拉满,按需抬。看剧情、看动作,512 够;要抠屏幕文字,才上 1024。

6.7 一个直观的量级感受

给个不严谨但能建立直觉的对比。假设你有个 40 分钟的讲座录屏:

• 图省事整片盲扫:100 帧封顶,还大概率触发"稀疏扫描"警告,平均下来每 24 秒才一帧,很多关键页会被跳过,钱花了效果还打折。
• 聚焦到你真正想看的 5 分钟:在这 5 分钟里帧密度直接拉满,关键幻灯片一页不落,总帧数可能还没盲扫多,token 反而更省。

看懂这个对比,你就理解了这套帧预算设计的全部用心:它不是在"抠门",而是在逼你把有限的预算,花在真正有信息量的画面上。

七、它和"视频大模型"到底不一样在哪

聊到"AI 看视频",很容易和另外两类东西混为一谈:一类是"视频理解大模型",一类是"视频生成模型"。它们和 claude-video 根本不是一回事,这里替你厘清,免得选错工具。

和"视频生成模型"的区别最好分。 后者是"给一段文字,