一台 2021 款 M1 Max MacBook Pro，64GB 内存，本地跑 Gemma 4 31B Q4，给一年视频素材做语义索引。

这件事有意思的地方，不在于“旧电脑还能跑大模型”。真正反常的是：AI 视频工具已经很会剪、会配字幕、会做分发，但很多创作者最基础的问题还没解决——素材根本找不到。

一个文件名叫 IMG_4821.mov，另一个叫 DJI_0037.mp4。它们可能拍的是金色时刻的山坡、大象、车窗外的尘土，也可能只是无用空镜。没有描述、没有转录、没有地点信息，后面的智能剪辑就像闭眼摸箱子。

这次实验更像是在问一个很实际的问题：本地多模态模型，能不能先把私人硬盘里的视频资产变成“可搜索”的东西？

问题不在剪辑工具，而在素材没有被看见

原作者长期拍摄肯尼亚马赛马拉旅行影像，素材来自 iPhone、DJI、无人机、Nikon Z8 和 Ray-Ban Meta 等设备。设备越多，归档越乱。视频越真实，越不能随便用生成式镜头补空。

他原本看过一套 SaaS 工具链：Eddie AI 做剪辑，Higgsfield MCP 做生成式 B-roll，Submagic 做字幕，Buffer 做分发，月费约 140 美元。

这些工具并非没价值。问题是，它们大多默认你已经知道素材里有什么，或者至少已有标签、转录、粗剪线索。可现实里的素材库，经常只是几块硬盘加一堆默认文件名。

DaVinci Resolve Studio 21 也有 IntelliSearch、Smart Bins 和 Voice to Subtitle。它能帮你在编辑环境里整理素材。但对跨硬盘、跨设备、长时间积累的原始归档来说，上游索引仍然缺一层。

路线适合解决什么卡在哪里更现实的位置
Eddie AI、Submagic 等云端工具剪辑、字幕、发布辅助默认素材已有一定结构第二层工作流
DaVinci Resolve 21时间线内检索、智能素材管理难覆盖全部原始归档编辑层
本地 Markdown sidecar给原始视频补语义描述速度、模型质量、硬件压力受限第一层索引

我更在意的是第三层：sidecar 索引。

对摄影师、小型旅行品牌、独立视频团队来说，最该延后的可能不是“买不买 AI 剪辑工具”，而是先别急着把更多钱花在剪辑末端。更具体的动作是：抽一批老素材，先建立统一的描述 schema，看看自然语言检索能不能把找片时间降下来。

如果素材还没被描述，自动剪辑只是在更快地处理混乱。

本地 sidecar：把视频变成可查询文件

这套工作流没有把所有东西塞进一个中央数据库，而是在每个视频旁边生成一个 .description.md 文件。

这个设计很土，也很稳。视频搬到别的硬盘，描述文件可以一起走；索引系统坏了，Markdown 仍能被普通编辑器、grep、脚本或别的工具读取。

单个视频的处理链条大致是这样：

环节工具或模型产出
读取文件信息ffprobe时长、编码、分辨率等基础元数据
提取拍摄信息exiftoolEXIF、GPS 等信息
地点补全GPS 反查 / Nominatim可读地点名称
抽取画面ffmpeg均匀抽取 5 帧 1920px 图片
音频转文本WhisperX转录、时间戳、说话人分离
人脸检测insightface人脸信息、512 维 ArcFace embedding
语义描述视觉模型YAML frontmatter 与自然语言描述
保存索引Markdown sidecar可搜索、可迁移的描述文件

这里的关键不是某个工具多先进，而是它们合在一起补齐了素材的“身份证”。

一个好的 sidecar 不只写“有几个人、在哪里”。它还要写光线、时间、色彩、场景、人物、声音质量、可能用途、是否需要复核。结构化 schema 很重要，因为它决定了以后能不能搜索“清晨、暖色、无人机、动物、可做开场”的片段。

这对创作者的影响很直接。

如果你有几 TB 素材，不一定要立刻迁移到新的媒体资产管理系统。更轻的做法是：先给最近一年或最常用项目生成 sidecar；字段不要贪多，先保留地点、人物、画面描述、转录、用途建议和复核标记；确认有用后，再扩大到老硬盘。

开发者也能从这里看到一个小机会：不要只做“更聪明的剪辑按钮”。很多人需要的是能接住本地文件、sidecar、转录、人脸嵌入和 NLE 软件的胶水层。工具未必华丽，但离真实痛点更近。

31B 本地模型能做初筛，但别把 50GB swap 当配置单

硬件部分最容易被误读。

这次实验用的是 2021 款 16 英寸 M1 Max MacBook Pro，64GB 内存，在 LM Studio 中运行 Gemma 4 31B Q4。模型约 28.4GB。批量处理时，机器峰值 swap 到约 50GB，风扇高速运转，内存压力进入黄色区间。

这说明它能跑，也能完成任务。但这不等于高吞吐，不等于低成本，更不等于建议大家照着买或长期这么压机器。

原文更接近一次短期极限运行：本地 31B 模型已经够做一层批量索引，但它不是替代所有云模型的答案。

更稳的分层策略是：本地模型负责大批量初筛，把每条视频先写出可检索描述；云端模型只处理本地标记为 review 的疑难片段，或复核高价值素材。

这样做有两个现实好处。

一个是成本。大量视频上传云端，本身就有时间、带宽和调用费用。素材越多，越不适合把每一帧都交给云端模型判断。

另一个是隐私。私人影像、客户素材、未发布品牌内容，不一定适合传到第三方平台。特别是人脸、GPS、旅行路线、客户活动这些信息，留在本地更可控。

但限制也要说清楚。

目前看不清的是处理速度、不同场景误判率、schema 在 Resolve 等主流软件里的衔接程度，以及人脸 embedding、GPS、转录文本如何长期管理。尤其是人脸和地点数据，一旦生成，就不只是“素材标签”，也属于敏感索引。

所以，最适合行动的人群其实很窄：有大量未标注视频、又不愿全量上传云端的摄影师、创作者和小团队。

他们可以先做三件事：

  • 选一块项目硬盘试跑，不要一上来处理全部归档。
  • 固定 sidecar schema，避免每次换模型都重写一套描述。
  • 把云模型留给复核，不要把它当成全量索引入口。

这件事的主线很清楚：AI 视频编辑器解决的是“怎么剪”，本地多模态索引解决的是“从哪里剪”。前者更显眼，后者更基础。

如果素材库还停在默认文件名时代，再多自动化都容易卡在第一步。