干这行这些年一直有个执念让 AI 替我干活而且是从头到尾独立干完一条而不是做点智能推荐、加个滤镜这种“半自动”花活。AI Agent 这个概念喊了两年从 Copilot 到 Agent从辅助到自主工具链确实成熟了不少。最近我拿到一个名为 OpenMontage 的项目它恰好踩在这波趋势上——本地部署大模型配合自动化剪辑直接端到端产出视频。我这周花了不少时间实测今天把整个过程、参数、碰到的问题一五一十摊开讲。先说结论如果你想让 AI Agent 独立生成一条完整视频从素材导入到粗剪再到导出成品OpenMontage 是目前实测下来少数能真正“跑通全流程”的落地框架。它不需要你把视频素材上传到云端大模型和个人数据都留在本地隐私是可控的。下面我会从环境准备、核心逻辑、实测过程到问题排查整套拆开讲清楚。1. 项目认知OpenMontage 到底解决什么问题1.1 AI Agent、LLM、AI 模型这三个概念别再混了很多人刚接触这块的时候经常把“AI Agent”和“大模型LLM”当成一回事其实这是两头不同的东西。打个比方大模型相当于一个人的大脑负责“想”比如 DeepSeek、MiniMax、Qwen 这些开源模型它们的强项是理解和生成文本而 Agent 是一个完整的“人体”除了大脑还有眼睛、手、脚它要通过调用外部工具比如读取视频文件、调用剪辑脚本、执行命令行去完成一个具体任务。OpenMontage 的核心设计就是“多智能体协作”它不依赖单个大模型完成所有事情而是把任务拆成若干子任务分配给不同的角色Agent比如素材分析 Agent、剪辑决策 Agent、渲染执行 Agent。每个 Agent 调用本地部署的大模型做决策再驱动剪辑引擎执行。这种“大脑分工、四肢协作”的思路才是它敢于声称“全自动剪辑”的底气。最近大家应该也看到不少热词比如 Dify 本地部署教程、Ollama 本地部署大模型哪个模型最佳还有 AI Agent 部署、AI Agent 有哪些产品。这些讨论背后其实藏着同一个痛点大模型推理能力再强如果不接上“工具”和“工作流”它就是一本会说话的百科全书干不了实事。OpenMontage 恰好把这件事补全了。1.2 本地部署的价值隐私、成本、可定制为什么非要强调本地部署用云 API 不香吗说实话如果只是测试几条视频云 API 确实省事你不需要管显卡、不需要管显存、不需要调模型加载参数。但我实测下来有三个问题逼着你回到本地方案第一是隐私。视频素材往往包含人脸、场景、声音直接传第三方 API相当于把自己的原始素材交给了别人。医疗器械行业的朋友可能更敏感我之前查过一份直播切片软件测评报告里面专门提到数据合规是工业企业选型的第一红线。本地部署至少从数据流角度把隐私留在了自己手里。第二是成本。API 按 token 计费一条十分钟的素材语音转文字可能就要消耗几十万 token再加上分析画面、做剪辑决策如果跑几十个项目费用非常可观。而本地部署只要你有一块像样的显卡电费远低于 API 费用。第三是可定制性。云 API 是黑盒你不能改提示词模板不能调整 Agent 的行为逻辑也不能把剪辑规则硬编码进去。本地部署之后所有 Prompt、Python 脚本、底层模型参数都是你的想怎么折腾就怎么折腾。1.3 OpenMontage 适合谁用如果你有以下需求这个框架值得重点关注做自媒体矩阵需要批量产出横版/竖版视频但又不想养一个庞大的剪辑团队公司内部有大量培训视频、操作录像需要快速切片提取关键片段想研究 AI Agent 应用开发需要一套完整的“大模型工具调用自动化流程”参考实现直播切片、长视频二次剪辑这类工作需求量大、内容重复正好适合用 Agent 自动化。当然它不适合完全零基础想“一键生成爆款视频”的人——你至少得能看懂命令行和 Python 报错。它也不是 Adobe Premiere 的替代品更准确地说它是你的“剪辑助手”帮你完成初剪、粗选、时间线搭建这些脏活累活。2. 部署前必须想清楚的事模型选择与硬件配置2.1 大模型选型DeepSeek、MiniMax、Qwen 到底怎么选OpenMontage 本身不内置模型它通过 Ollama 或者 vLLM 调用本地模型。所以你的核心工作之一是选一个大模型来当 Agent 的“决策大脑”。实测下来我建议按显存大小分三档来选显存推荐模型参数量说明8GBQwen2.5-7B-Instruct7B轻量决策够用剪辑标签提取能力可以12-16GBDeepSeek-R1-Distill-Qwen-14B14B推理能力明显增强适合复杂决策24GB以上MiniMax-M1-80B量化版或 Qwen2.5-72B72B-80B最强决策能力但对显存和内存压力大我自己测试用的是 DeepSeek-R1-Distill-Qwen-14B配合 Ollama 部署。为什么不直接上 70B因为我手里那张显卡只有 16GB 显存70B 模型即使量化到 Q4也需要至少 40GB 显存强行跑会导致频繁换入换出决策速度慢到没法看。如果你有 24GB 显存可以试试 MiniMax-M1 的量化版本它在“理解复杂指令”上确实比 14B 强一截尤其在多步骤剪辑规则判断上。还有一个关键点OpenMontage 默认支持 Ollama API 格式/api/chat所以不管底层用哪个模型只要你在 Ollama 里 pull 下来配置一下模型名就行切换成本很低。2.2 显卡之外的配置清单硬件方面显卡是第一优先级但也不能只看显存。以我的实测环境为例CPUIntel i5-13600KF内存64GB DDR5注意内存不能小加载 14B 模型时光权重就占约 10GB还得留出系统缓存显卡NVIDIA RTX 4080 16GB硬盘NVMe SSD 1TB视频素材读写频繁机械硬盘会拖累实测速度系统Ubuntu 22.04 Windows 11 双系统OpenMontage 在 Linux 下更稳Windows 用 WSL2 也行这套配置大概是“中等偏上”的起点。如果你只有 8GB 显存选 7B 模型也能跑只是剪辑决策的准确率会下降一些后面我会讲怎么通过调整 Prompt 来弥补。2.3 部署详细步骤从零开始拉代码到跑通接口我把部署过程整理成可直接抄作业的步骤基于我这次的实操记录安装基础环境# Ubuntu 22.04 下执行 sudo apt update sudo apt install -y git ffmpeg python3-pip拉取 OpenMontage 代码git clone https://github.com/OpenMontage/OpenMontage.git cd OpenMontage pip install -r requirements.txt安装 Ollama 并拉取模型curl -fsSL https://ollama.com/install.sh | sh ollama pull deepseek-r1-distill-qwen-14b启动 Ollama 服务ollama serve # 验证接口 curl http://localhost:11434/api/tags编辑 OpenMontage 的配置文件config.yaml关键参数如下llm: provider: ollama model: deepseek-r1-distill-qwen-14b base_url: http://localhost:11434 temperature: 0.2 # 剪辑决策尽量低温度避免随机性 video: input_dir: ./input output_dir: ./output min_segment_duration: 5 # 最短切片时长秒 max_segment_duration: 60 # 最长切片时长秒 scene_threshold: 0.35 # 场景切换阈值启动 Web 管理界面python app.py # 浏览器访问 http://localhost:5000整个部署链路写下来好像不长但第一次踩坑点挺多的。最常见的是 ffmpeg 没装成功导致视频解码失败以及 Ollama 的模型没下完整导致接口返回 404。后面我在“问题排查”里会详细列。3. 核心机制拆解OpenMontage 是怎么“看懂”视频的3.1 素材理解的三个层次音频转写、场景检测、语义分析OpenMontage 处理一条视频不是像剪映那样靠人眼手动拖时间轴也不是简单按固定间隔切一刀而是走了一套“三层理解”的流程。第一层叫语音识别层。它调用本地 Whisper 模型把视频里的对白转成带时间戳的文字稿这相当于给视频建立了一个“文字索引”。为什么这层重要因为大多数视频里叙事主线是藏在台词里的。AI 要判断“这一段讲的是核心观点还是过场废话”首先得知道这一段说了什么。第二层叫画面分析层。OpenMontage 用帧采样技术每隔一定帧数抓取一帧画面对比颜色直方图计算场景切换强度。如果相邻帧之间差异超过你设定的 scene_threshold就认为这里发生了一次镜头切换。这个数据的价值在于它帮 Agent 理解视觉节奏在后期的“去冗余”阶段能识别出长时间静止画面、黑场、重复镜头。第三层叫语义分析层。这才是 Agent 发挥真正作用的地方。上面两层输出的文字稿、场景切割点、时间戳会被送入本地大模型。模型会根据你的初始提示词比如“提取完整表达观点的片段去掉磕巴和停顿”在时间线上标注出“保留片段”和“删除片段”还能给每段内容打上主题标签。到这里素材已经被 AI “消化”成一张带语义标注的时间轴地图。这三个层次的关系很好理解Whisper 负责“听”帧采样负责“看”大模型负责“想”最后剪辑引擎负责“动手”。OpenMontage 的聪明之处是它把这三层拆成了独立的模块每一个模块都能单独替换升级。比如你把 Whisper 换成更强的 SenseVoice或者把大模型从 DeepSeek 换成 MiniMax不需要动其他部分。3.2 自动剪辑决策Agent 是根据什么规则下判断的很多人以为自动剪辑就是 AI 随便挑几段拼一下其实不是。OpenMontage 里配置了“剪辑策略”可以理解为给 Agent 的一套编导手册。实测中我调整过这几个核心参数影响非常明显min_segment_duration最短保留时长。如果一段有效内容只有 3 秒它要不要保留设得太短视频会很碎设得太长又会留下太多冗余。实测下来口播类内容设 8 秒比较舒服。max_segment_duration最长片段时长。这个参数控制一条视频的节奏感。比如做抖音竖屏短视频超过 30 秒的片段就应该拆开。keep_ratio目标保留比例。比如视频原始素材有 30 分钟你希望最终成品控制在 5 分钟以内那么把 keep_ratio 设成 0.17 左右Agent 会优先保留语义价值最高的片段。除了这些硬性参数Agent 还会读取你的“风格指令”。举个例子我在实测中设置了一个 Prompt你是一个短视频剪辑师。请基于时间轴标注筛选出信息密度最高、能独立表达完整观点的片段。优先保留包含结论、方法、案例的段落删除问候语、重复表达、与主题无关的闲聊。如果两段内容意思相近保留表达更精炼的一段。这个 Prompt 看起来简单但它决定了模型在时间轴标注上的倾向。如果你把“优先保留冲突点、悬念”写进去它就会变成另一种风格的剪辑逻辑。这一层的自由度是传统剪辑软件完全给不了的。3.3 多智能体协作的管线设计OpenMontage 里最值得展开讲的是它的“管线式多智能体”架构。它不是单一 AI 一把梭到底而是像一条工厂流水线素材接入 Agent负责扫描输入目录、校验视频格式、生成代理文件低分辨率副本方便后续快速分析。分析 Agent调 Whisper 和帧采样输出时间轴元数据。决策 Agent把元数据组合成大模型可读的 Prompt生成剪辑决策 JSON。执行 Agent读取决策 JSON调用 ffmpeg 执行剪切、拼接、合并。质检 Agent成品导出后再次抽帧检查有没有黑场、音画不同步、爆音等问题。我特意看了执行日志发现 OpenMontage 在决策阶段和质检阶段都允许人工介入。比如决策 Agent 生成 JSON 后系统会把它保存下来你可以手动改几个片段的起点终点再继续执行。这个设计非常实用它把“人的审美”和“AI 的效率”结合起来了不是完全黑盒的“一键生成”。4. 完整实测过程从原始素材到成片全流程4.1 实测素材与应用场景我这次选取的测试素材是一段 42 分钟的直播录像回放技术分享类主讲人对着屏幕演示操作期间有较长沉默代码操作的部分另外还加了三条短视频素材合计 6 分钟用于测试多素材拼接能力。测试场景设定为把这段 42 分钟的直播回放自动剪辑成一条 5-8 分钟的“精选摘要视频”去除代码操作过程中的长时间静默和重复讲解。4.2 实测操作步骤与参数设置第 1 步素材预处理我把三段视频素材放进了./input目录并用 ffprobe 检查了它们的编码格式。注意OpenMontage 只认 H.264/H.265 编码的 MP4 文件如果你的素材是 MKV 或者其他编码格式得先转码ffmpeg -i input.mkv -c:v libx264 -c:a aac -movflags faststart output.mp4这一步很多人会忽略结果程序报错“unknown video codec”后一脸懵。第 2 步运行分析管线在 Web 管理界面点击“启动任务”然后选择“完整流水线”。后台会自动执行以下操作调用 ffmpeg 抽取音频轨道调用 Whisper 生成带时间戳的转写文本每 0.5 秒抽帧一次计算场景切变强度把上述信息打包发送给大模型。这一步耗时最长42 分钟的素材大约用了 18 分钟大头全在 Whisper 转写上。如果用的是 4080 显卡16GBWhisper large-v3 的处理速度大概是素材时长的 0.4 倍左右也就是说 10 分钟素材转写大约要 4 分钟。如果你赶时间可以把 Whisper 模型从 large-v3 换成 medium速度快近一倍只是识别准确率略降。第 3 步人工审阅剪辑决策分析管线跑完后浏览器页面会展示一个时间轴列表每一行包括开始时间、结束时间语义标签/标题来自大模型的保留/删除标记置信度这里我建议一定要人工扫一眼。实测发现AI 对“有效内容”的判断整体靠谱但偶尔会把“主讲人说了一个笑话”当成重点保留反而把真正关键的参数讲解略过了。改起来也很方便直接选中某一段把 Recommended Action 从 Keep 改成 Remove 就行。我这次把 42 分钟的直播素材AI 初筛后保留了 18 分钟的“高价值片段”我在人工审阅阶段又手动删掉了约 6 分钟的赘余内容最后确定保留 12 分钟再在输出阶段按 2 倍速压缩到约 6 分半钟。第 4 步执行渲染点击“执行剪辑”后OpenMontage 会调用 ffmpeg 完成实际剪切拼接。这里有一个参数值得注意是否启用“转场平滑”。如果你在多段素材拼接处需要加入转场效果可以开启该选项但会增加渲染时间。我这次测的是纯硬切风格所以未开启。实测结果42 分钟素材最终产出 6 分 28 秒的成片整个渲染耗时 3 分 40 秒。最终文件大小 182MB1080p码率约 3.8Mbps。4.3 实测结果哪些环节表现优秀哪些环节翻车了先说表现优秀的部分第一语音转写准确率很高。Whisper large-v3 对中文口播的识别在我这段素材上几乎没有错字专业术语“RAG”“向量化”“Attention”也都正确识别。第二语义筛选能力强。AI 自动剔除的段落绝大多数是“客套开场白”“代码操作时长达 20 秒的沉默”“重复解释上一段内容的琐碎表达”。这个能力说实话比很多刚入行的剪辑助理判断力还准。第三多素材拼接顺畅。三分钟短视频素材 42 分钟直播素材OpenMontage 自动把短视频作为“片头引入”直播内容统一做主段落拼接完成后时间线逻辑通顺。再说翻车的地方翻车第一大点是“画面分析层对无人声但信息密度高的画面判断力差”。比如主讲人共享屏幕展示一张复杂架构图整整沉默 15 秒AI 因为没检测到人声把这 15 秒判定为“静默无效片段”删掉了。但对观看者来说这个画面恰恰是全场最需要停下来仔细看的地方。第二个翻车点在“AI 对视频结构的理解偏文本化”。它能听懂每句话但“幽默段子”和“关键信息”的权重把握不准。一处主讲人用来调节气氛的“开个玩笑别当真”AI 给了很高的保留优先级导致成片里出现了一处与主线无关的插科打诨。第三个翻车点两个视频中间会出现解码纹理异常。原因是我那段直播素材原始编码是 variable frame rate (VFR)在剪切拼接时 ffmpeg 没有重写时间戳导致音画轻微不同步。解决办法是预处理阶段加入-vsync cfr强制转成恒定帧率。整体的感受是OpenMontage 做“粗剪”已经相当可用它能帮你节省 70% 的看素材时间但“精剪”层面还离不开人工把关。你把它定位成“智能助理”而不是“全自动编辑”体验会好很多。5. 常见问题与避坑指南5.1 本地部署中的典型踩坑记录我这次实测踩了不少坑整理成速查表方便后面入坑的朋友直接对照问题现象原因分析解决方案Ollama 接口返回 404模型没 pull 完整或服务没启动执行ollama pull后确认模型 ID用curl /api/tags验证ffmpeg 解码失败视频编码不合规或缺少 H.264 解码器确认编码格式必要时重装 ffmpeg 并确保包含 libx264中文路径导致脚本中断OpenMontage 内部调用的某些 Python 库不兼容中文路径所有目录路径避免使用中文用video1.mp4而不用测试视频.mp4显存不够导致 OOM模型加载占满显存没有给画面分析留余量换更小的模型或调整OLLAMA_NUM_PARALLEL和OLLAMA_MAX_LOADED_MODELS参数剪辑完成后音画不同步VFR 视频在时间戳处理上有缺陷预处理时加-vsync cfr强制恒定帧率Web 页面刷新后进度丢失任务队列存在内存中非持久化长任务建议在终端前台运行避免浏览器关闭导致中断5.2 剪辑质量优化的几条实操经验这里说几个我调参总结的经验直接给结论第一temperature一定要调低。大模型的 temperature 默认是 0.7这个参数控制输出的随机性。但剪辑决策是一件需要“稳定输出”的事情我把它调到 0.2 后同一个素材连续跑两次生成的剪辑 JSON 基本一致。如果你用默认值AI 每次给你的剪辑决策可能都不同非常影响复现。第二Prompt 要写具体不要写“帮我剪好视频”这种空话。“剪好”的标准是什么语义完整、信息密度高、节奏轻快在没有明确定义前模型只会按自己的默认偏好来。我在 Prompt 里明确写出“删除磕巴、重复、静默超过3秒的段落”模型立刻就能判断了。第三素材预处理阶段多做一步“去除黑边和底色”。有些屏幕录制视频四周有黑色边框这会干扰画面分析层对场景切换的判定。用 ffmpeg 做一次 crop 再去跑分析管线结果会准很多。5.3 MiniMax、Diffy 等相关工具应该如何配合使用OpenMontage 定位是“自动剪辑”但它不是孤立存在的实测中我发现它和另外几个工具组合使用效率还能再上一个台阶Dify用来做 Agent 工作流编排。如果你手头的项目除了剪辑还需要“自动生成标题、简介、封面文案”可以让 OpenMontage 的决策 JSON 直接作为 Dify 工作流的输入自动生成配套的发布文案。MiniMax如果你对“画面美观度”有更高要求可以在 OpenMontage 精剪完成后用 MiniMax 的视频生成模型做局部增强处理比如补帧、超分。注意这一步对显存要求很高我这个 16GB 的显卡跑 MiniMax 的 2K 超分比较吃力。Ollama DeepSeek这个组合是目前性价比最高的“决策大脑”。如果你有 24GB 显存可以试一下 DeepSeek-R1-Distill-Qwen-32B它比 14B 在复杂剪辑规则理解上提升明显。说到底这套方案的核心价值不是某一个模型有多强而是把“大模型决策能力”和“ffmpeg 执行能力”通过 Agent 粘合在一起形成一条可复用的自动化流水线。6. 本地部署 AI 大模型选型参考结合 OpenMontage6.1 不同显卡下的模型选择建议最近在这个话题下面有不少人问“Ollama 本地部署大模型哪个模型最佳”。这个问题其实没有标准答案关键要看你的硬件。如果只是 8GB 显存Qwen2.5-7B 是很好的起点VRAM 占用约 6GB可以留出 2GB 给 OpenMontage 的画面分析模块。如果是 12GB-16GB 显存DeepSeek-R1-Distill-Qwen-14B 是均衡之选既能跑剪辑决策又有余力跑 Whisper large-v3。如果是 24GB 显存MiniMax-M1-80B4bit 量化可以尝试但注意要预留足够多的内存建议 64GB 以上否则模型交换会非常慢。从实测来看剪辑决策对模型的“常识判断力”要求高于“数学推理能力”。也就是说一个参数量 14B 的通用模型效果往往好过一个 7B 的专用模型。因为你给 AI 的指令本质上都是生活常识——“这段内容是不是在说重点”“这句话是不是客套话”等等。不需要它做复杂推理需要的是对语义有足够广度的理解。6.2 模型部署的显存控制技巧用 Ollama 部署模型时最重要的一个参数是num_ctx上下文窗口大小。OpenMontage 会把一整段视频的元数据塞给模型如果上下文窗口太小模型只会看到删除片段完全看不到保留片段导致判断失真。我实测后的建议把num_ctx设为 8192 或 16384。注意这个参数和显存消耗成正比设置过大反而会导致显存溢出。具体调参命令ollama run deepseek-r1-distill-qwen-14b /set parameter num_ctx 8192 /save deepseek-r1-distill-qwen-14b还有一个技巧如果你的 Ollama 和 OpenMontage 跑在同一台机器上建议把 Ollama 的并发参数调低避免模型推理和视频转码抢显卡资源。在启动 Ollama 服务时设置OLLAMA_NUM_PARALLEL1 OLLAMA_MAX_LOADED_MODELS1 ollama serve这样能保证剪辑任务执行时显卡资源主要分配在 ffmpeg 转码上速度更快。6.3 一个避坑提醒千万别盲目追求大模型很多人一上来就追求 70B、80B 的“大”模型但实测下来在 OpenMontage 这个场景里14B 和 72B 的剪辑决策质量差距远没有想象中那么大。原因在于剪辑决策更多依赖“结构化标签”而不是深层推理。14B 模型完全能读懂“这段是寒暄”和“这段是干货”的区别。反而 72B 模型加载慢、推理慢还容易把显卡显存占满导致画面分析跑不起来。我的建议是如果硬件没有达到 24GB 显存以上的水准别盲目迷信大模型。把精力花在调 Prompt、调剪辑策略参数上收益会更大。7. 从 OpenMontage 看 AI Agent 的未来方向7.1 Agent 与 LLM 的关系不是替代而是分层协作最近一直有朋友问我Agent 和大模型到底什么关系OpenMontage 这个项目就是最直观的答案。LLM 是大脑负责理解和生成Agent 是主体负责感知、决策、执行。在 OpenMontage 里大模型做语义判断但真正执行剪辑动作的是 ffmpeg。没有 Agent 这一层大模型永远只能输出“建议你删除 00:12 到 00:35 的片段”这样的文本无法变成实际动作。而 Agent 的价值就是把“建议”变成“执行”。这就像一个餐厅里LLM 是行政主厨负责设计菜谱Agent 是后厨团队负责把菜谱变成一道道能端上桌的菜。你不能指望主厨自己去洗菜切菜炒菜他需要的是贴配菜、炒锅、装盘师傅各司其职。7.2 实测中最触动我的一个瞬间Agent 真的在“做事”跑完整条流水线后我打开 OpenMontage 的执行日志翻到决策 Agent 那一段看到它在 JSON 里写了一行注释“这段 12 分钟的长讲解中主讲人在 03:25 提到了一个与主线无关的软件安装细节建议删除但保留 03:35 的总结句以维持逻辑完整。”这行注释给我的冲击还挺大的。它不是从数据库里匹配到的规则而是大模型真正“读”懂了这段视频的内容并且基于语义理解做了一个合理的编辑决策。那一刻我开始意识到所谓的 AI Agent不只是“聊天机器人接上了工具”而是它真的在尝试理解内容、执行任务、并对自己的决策负责。7.3 后续还能怎么扩展如果你已经部署好 OpenMontage并且跑通了第一条视频可以继续尝试这几个扩展方向第一个方向是接入更丰富的输入源。OpenMontage 目前主要处理本地文件但你完全可以写一个监控脚本定时扫描某个网盘目录或者录屏软件的输出目录新文件一出现就自动启动剪辑流水线。这就实现了“无人值守的自媒体切片工作站”。第二个方向是结合“直播切片自动剪辑软件”的需求做直播实时处理。实测中 OpenMontage 处理的是录制好的直播回放如果你对流式处理有需求可以把它的分析模块拆出来按固定时间窗口滑动分析直播流。但这里要提醒的是实时处理对硬件要求更高至少需要两张显卡一张跑模型一张跑编码。第三个方向是“AI Agent 应用开发”本身的参考价值。OpenMontage 源码里的 Agent 定义、工具调用、任务队列设计可以作为你学习 Agent 开发的入门教材。它的代码写得清晰模块耦合度低非常适合拿来做二次开发。说到底AI Agent 的能力边界不是固定的它取决于你肯花多少时间去调教它、扩展它。OpenMontage 的意义是给了我们一个开箱即用的起点——剩下的路得靠自己去走。我在整个实测过程中最大的体会是AI Agent 最可能接管的是那些“重复、琐碎、需要耐心但不太需要创造性”的工作。剪辑恰恰就是这样的工作——看素材、找亮点、去冗余这些事既不性感也不轻松但恰恰是 AI 最擅长干的事。别指望它一夜之间成为奥斯卡级剪辑师但让它当你手下那个任劳任怨的剪辑助理它完全够格。