让任意大模型真正"看"视频，这个开源工具省了九成token也挨了骂
哈喽，我是飞飞。
这两天 Hacker News 上一个叫 claude-real-video 的开源项目炸出几百条评论，吵的是一件你可能从没细想过的事：你把视频丢给 AI，它到底有没有在看画面？
答案有点反常识。ChatGPT 读的是字幕文本，压根不看画面。Claude 干脆不接受视频文件。只有 Gemini 真正读画面，但它按每秒一帧的固定间隔截图，再把视频传到谷歌云端。换句话说，大部分时候你以为 AI 在看视频，它其实在读字幕，或者在看定时截图。claude-real-video 想把这件事做对，做法是在本地按场景切换提取关键帧、去重、转录音频，再喂给任意一个能读图的大模型。它确实省了九成 token，但说实话，社区骂得也不轻。
大模型其实没在看视频
先把现状摊开。Gemini 官方文档写得很老实，视觉信息按 1 帧/秒采样，文档自己承认”可能会遗漏快速运动或快速场景切换视频中的细节”。一段 10 分钟的演示，按每秒一帧算就是 600 张图，其中大半是几乎一样的幻灯片，模型要为这些重复画面付满 token。
claude-real-video 的作者 cortexosmain 在 HN 给了组对比数字：同样 10 分钟演示，固定间隔采样出约 600 帧，他的工具压到 5 到 15 帧，token 省掉九成以上，理解效果反而更好。
差距来自采样逻辑。固定间隔按时间切片，不管内容变没变；claude-real-video 按场景变化切片，镜头切一次才取一帧，再用滑动窗口去掉重复镜头。一段 10 分钟的静态幻灯片，固定采样给出 600 张近重复图，场景感知只留 1 张。一段快速剪辑，固定采样会漏掉采样间隔之间的画面，场景感知每次视觉变化都接得住。
说白了，这条差别决定了它跟固定采样根本不是一个量级。
按场景切换而非按秒取帧
技术细节其实不复杂。工具用 ffmpeg 检测场景切换点，再保证每秒至少一帧兜底，覆盖慢速录屏。去重不靠感知哈希。作者在 README 里特意解释，哈希在纯色和等亮度色相变化时会失效。所以改用降采样到 16x16 的真实像素差异，跟最近保留的几帧对比。A-B-A 剪辑里模型已经看过的镜头切回来，不会重复发送。
音频这条线也接上了。视频若自带字幕就直接用，没有才回退到 Whisper 转录，支持语言检测。加个 –keep-audio 参数还能把完整音轨存下来，让 Gemini、GPT-4o 这类能听声音的模型真正听到音乐和语调。
这套”本地预处理加通用模型”的解耦思路，其实跟我每天在用的那条写作流水线是同源的。你现在读的这篇，资料是 brave-search 那个 MCP 一条条搜回来的，封面等会儿会让 banana 那个 MCP 出，脏活累活前置到本地工具，大模型只管读图读文本做推理。我那条流水线挂了十几个 skill，从拉资讯、查重、配图到发公众号，每个环节都把难啃的活儿留在本地做扎实，最后才交给模型做它擅长的那一段。这种分工我跑了半年多，体感很直接：本地这一层做得越厚，换模型时心里越有底。claude-real-video 干的是同一件事，只不过它前置的是视频拆帧，我前置的是搜索和配图。
学术研究也站这条路
claude-real-video 不是孤例。今年 CVPR 2025 有一篇论文叫 M-LLM Based Video Frame Selection，结论跟这个工具的思路几乎一样：自适应选帧，用更少的帧拿到更好的理解。
论文里有个关键判断：判断一帧重不重要，不需要像回答问题那样多的视觉 token，粗略轮廓就够了。他们把每帧从 144 个 token 压到 9 个，让一个 1.5B 的小模型先扫 128 帧打分，再挑几帧喂给大模型。实验结果很硬：选 4 帧的效果超过均匀采样 8 帧，推理还更快。
说人话就是，”固定采样不够聪明”已经是学界共识，claude-real-video 把这个共识做成了能 pip install 的工具。
关键帧真的等于视频吗
这是 HN 吵得最凶的一层。
用户 octember 那句批评被反复引用：关键帧不是视频，运动、物体持久性这些东西，Claude 没法从一组图片里推断出来。有人拿 DOS 游戏精灵图做测试，15 到 16 个精灵里只定位对 1 到 2 个。也有人试过用关键帧推断动画时序，最后还是靠手动描述才讲明白。
这话得公平讲。帧提取路线对静态内容多的视频效果好，演示、讲座、幻灯片这类，场景感知加去重几乎是降维打击。但运动密集的内容，体育、舞蹈、动画，关键帧本质上是把一段连续动作拍扁成几张静图，丢掉的就是运动本身。这是结构性的，调参救不回来。
还有个被点名的细节：工具宣称”视频留在本地”，但提取出来的帧最后还是要发给 Anthropic 或者 OpenAI 的服务器，模型才能看。本地完成的只有预处理那一步，推理还是要把帧发给云端模型。
省钱其实不是它的重点
成本这层争议最实在。用户 achatham 算了笔账：Gemini 3.1 Flash Lite 处理 1 小时视频，API 费用 0.24 美元，还有 lower resolution 选项进一步压价。Claude 的 token 单价本来就贵，即便帧数砍掉九成，算下来未必比 Gemini 原生方案便宜。fzysingularity 直接说这是”terribly expensive”的看视频方式。
所以这个工具真正的分量，不在帮 Claude 省钱，在让那些不能用 Gemini 的场景也能让大模型看视频。
哪类场景不能用 Gemini？隐私敏感的内部会议录像、医疗影像、法律证据视频，这些不敢传谷歌云端。还有模型自由，你不必绑死在一家身上，任何能读图加读文本的模型都能用同一份 manifest 文件夹。
模型自由这条我深有体会。我写文章的流水线挂着十几个 skill，全是照着某一家模型认 frontmatter、调 hook 的脾气一点点磨出来的。真要把底座换到别家，光是把那些工具调用的格式校回来就得搭进去好几个晚上。claude-real-video 这种把脏活留在本地、manifest 谁都能读的搞法，等于把换模型的成本摁到了最低。
超长视频也沾边，Gemini 默认分辨率最多撑 1 小时，低分辨率 3 小时封顶，本地工具没有这个天花板。
命名这层吵得最热闹但最不重要。一群人建议把项目名里的 Claude 去掉，叫 llm-real-video 或者 llmrv，因为这工具跟具体模型无关，本质是个预处理器。作者没改。
我会继续盯着两件事
claude-real-video 代表的是”预处理加通用 LLM”的解耦打法，把视频理解的难点前置到本地，让大模型只做它擅长的读图推理。这条路能不能补上运动信息的短板，是我想看的第一件事。光流、运动热图、时序编码这些手段有没有人接进来，决定了它是停在”静态内容神器”还是能往运动密集场景走。
第二件事是大厂会不会把这层能力收编进原生模型。Gemini 已经在往自适应采样靠，论文也在推，开源工具的窗口期有多长不好说。但本地隐私和模型无关性这两条，大厂原生方案天然给不了，所以这类工具大概率不会消失，只会分化成两条不同的路。
你更在意让 AI 看懂视频的哪一头，是它看得准不准，还是它别把你的视频传上云端？
参考资料
- [[claude-real-video-github]]
- [[claude-real-video-hackernews]]
- [[mllm-video-frame-selection-cvpr2025]]
- [[gemini-video-understanding-docs]]
相关洞察
- [[claude-real-video-llm-video]]