把长视频链接一键剪成多平台短视频（AutoClip）

把一期两小时的播客拆成十条竖屏短视频，人工流程大致是：完整听一遍音频找高光、记下时间点、逐段切出来、重新构图、压字幕、做封面、再补一段发布文案。这些环节里真正需要判断的只有第一件，剩下的基本是重复操作。

AutoClip 是用 Python 写的开源 AI 视频剪辑工具，输入一条长视频链接，输出适配抖音、小红书、TikTok 等平台的短视频成片与封面文案。

剪辑和渲染在你的电脑上完成，软件本身免费，调用云端模型时按量计费。仓库地址是 https://github.com/zhouxiaoka/autoclip，采用 MIT 许可证，主要语言为 Python，占代码量的 77.0%。

它同时提供桌面应用、命令行与 MCP 三种入口，桌面版分 macOS 与 Windows 安装包，也支持用 Docker 在本地起服务。运行环境上，后端是 Python，前端有 TypeScript 与少量 JavaScript、CSS，仓库里带着 .taurignore 与 src-tauri 目录，说明桌面壳用的是 Tauri。这套形态决定了它更适合长期坐在电脑前做内容的人，而不是想在手机上随手剪一条的普通用户。

它解决的是什么问题

长视频转短视频的瓶颈不在剪辑技术，在于从大段素材里挑出能单独成立的一两分钟。一期访谈可能有几十个可用的段落，人工听完再判断，一小时素材往往要花几个小时。挑完之后还有一层体力活：把横屏改成竖屏并决定主体人物放在画面哪一侧、给口语内容配上分页字幕、从视频里截一张能当封面的帧、再写一段带话题的发布简介。

AutoClip 把这些步骤串成一条流水线。你给它一个视频链接，它先拿到音视频与字幕轨，用模型判断哪些片段有传播价值，再按选的平台比例出片，字幕、封面和文案一并生成。需要人工介入的部分被压缩到「选哪几段、发到哪个平台」这一类判断上，其余交给流程。

典型使用场景

• 做播客或访谈节目的内容运营：一期节目上线后要同步铺到抖音、小红书、TikTok 和 YouTube Shorts，同一批素材得按不同平台的画幅和时长各出一版，人工重复度很高。
• 把课程、直播回放、长测评视频做二次分发：手里有大量已成片的长内容，想让它们重新进入短视频流量池，但缺少人手逐条剪。
• 做出海内容：同一期素材要同时出中文字幕与英文字幕版本，README 的案例展示里两种语言都有，字幕语言跟随成片设置。
• 需要批量处理而不是精修的场景：一次导入多条长视频排队出片，接受自动结果，只在个别片段上做人工调整。

几个常见疑问

必须自己配云端模型的 API Key 吗？

软件免费，云端模型按调用量计费，这是官方 README 的说明。仓库的 Issue 里有多条与模型配置相关的反馈，包括「添加模型时报网络错误」和「配置了模型卡在不出片」，都标记为已解决，前者涉及 settings.json 里 API_KEY 的填写。转写环节存在本地路径，v1.5.5 的发布说明提到「云端转写失败时保留云端原因和配置提示，不再误报本地 Whisper 未安装」，说明本地 Whisper 是可选方案之一。仓库里没有给出不配任何模型就能完整出片的说明。

任务卡在进度条不动是怎么回事？

Issue 里有「下载到 5% 就停了」和「项目进度始终卡在 20%，且任务状态无法同步」两类反馈，均标记为已解决。另有版本发布说明提到，项目状态文件持续无法写入时，部分制作任务可能一直显示等待或进行中。如果你遇到类似情况，先把任务状态文件和日志目录的写入权限确认一遍，仓库的 ROADMAP.md 与 CHANGELOG.md 里记录了各版本对这类问题的修复进度。

自动出片的结果不满意还能改吗？

README 写明「需要调整时可进入编辑器」，也就是说自动流程产出的片段可以在编辑器里做人工修改，而不是只能重跑一遍。切片后的预览是否正常曾是 Issue 里的问题，反馈是「点开后是黑屏」，该条已标记解决。

主要功能

• 一键出片：贴入视频链接、选定目标平台后，一次性生成成片、封面与发布文案。README 列出的适配平台包括抖音、小红书、TikTok、Reels、YouTube Shorts、B 站与 YouTube。
• 多种成片版式：官方案例分了「竖版 · 访谈式」「竖版 · 满屏播客式」和「横版 · 保留原画幅」三类，横版用于保留原有画幅，竖版侧重重构图与人物取景。
• 人物取景：v1.5.0 的发布说明把「人物检测」列为 Windows 正式包的验收项之一，同时提到「内置后端启动、人物取景、中文字体和片尾出片检查」，说明竖屏裁切时会先定位人物再决定构图。
• 字幕与字幕分页：CHANGELOG 提到字幕分页。v1.5.3 修复了访谈式竖屏成片裁掉引用卡、幻灯片两侧文字的问题，另有一条行为是「关闭画面识别后，自动封面选帧和硬字幕语言判断不再向视觉服务发送素材画面」。
• 视觉高光分析：支持接入带画面分析能力的视觉模型（v1.5.3 提到百炼视觉模型），也兼容模型直接返回事件列表的格式，保留选段边界与错误格式校验。不想发送素材画面时可以在设置中关闭画面识别。
• 封面生成：支持自动封面选帧。v1.5.5 修了一个收尾问题——最后一张卡片的封面生成后未自动显示；可选封面失败或服务重启时，已生成的视频会保留。
• 发布文案：随成片一起产出发布简介。v1.5.5 加了一条约束：简介里出现 CEO、CTO、CFO、COO 或「公司负责人」这类任职说法、但原字幕里没有依据时，保留标题与话题并省略简介，不额外增加模型请求。
• 三种调用入口：v1.5.0 的说明是「桌面、CLI 与 MCP 同步更新」，仓库 Topics 里也带 mcp，说明除图形界面外还有命令行与 MCP 两种接入方式。

安装与最短示例

最省事的是装桌面版：从 https://github.com/zhouxiaoka/autoclip/releases/latest 下载对应平台的安装包。macOS（Apple Silicon）的包未公证，首次打开需要右键点击应用，再选「打开」。下载表里给出了 .dmg 文件名，例如 1.5.2 对应的 AutoClip.Desktop_1.5.2_aarch64.dmg。

想用 Docker 在本地起服务，仓库顶层提供了 docker-compose.yml、docker-compose.dev.yml、Dockerfile 和两个启动脚本。开发模式的启动命令在 Issue 反馈中原样出现过：

./docker-start.sh dev
./docker-status.sh

Windows 用户的反馈里还提到过环境依赖的补法，例如在 requirements.txt 中补上 pytz、dashscope、openai、google-generativeai 这几个库，以及给 simple_progress.py 加上 import os 解决 Redis 连接失败。这些是用户当时的处理方式，仓库里没有把它们写成标准安装步骤。

从源码构建的完整流程写在 BUILD_GUIDE.md 与 STARTUP_GUIDE.md 里，仓库首页没有展开。Docker 相关的说明另见 DOCKER.md，开发容器的入口脚本是 docker-dev-entrypoint.sh。

关键参数

模型配置是绕不开的一项。设置页负责配置模型连接，配置落在 settings.json，通常需要填 API_KEY。Issue 里有用户遇到「settings.json 里的 API_KEY 也加好了，添加模型仍报网络错误」的情况，该条已解决。v1.5.1 还修过两个相关问题：旧封面配置无效时单独提示修正并保留原配置；损坏的 AI 配置可在设置页修复，保存时会备份损坏文件。

平台选择决定输出画幅与时长，可选范围见 README 的适配列表。画面识别开关决定是否把素材画面发送给视觉服务，关掉之后自动封面选帧和硬字幕语言判断的行为会相应改变。转写走云端还是本地 Whisper 属于另一组配置，v1.5.5 明确会保留云端转写的失败原因与配置提示。

Docker 部署的环境变量通过 env.example 转成 .env，Dockerfile 里对应一行 COPY env.example .env。数据库的清理脚本是根目录下的 clean_database.py。除这些之外，配置项的完整清单仓库里没有集中说明。

结果在哪里看

桌面版把制作过程放在进度页，一键出片启动后会停在制作进度页，成片与封面以卡片形式回填到界面，这一点从 v1.5.1 和 v1.5.5 的修复记录里能看出来。发布简介与成片一并产出。仓库里没有说明默认的输出目录路径，顶层虽然存在 artifacts/ 目录，但文档没有把它写成结果存放位置，这里不做推测。

实际使用中的坑

• 依赖与运行环境缺失：有用户反馈在 Windows（WSL）下需要自行补 pytz、dashscope、openai、google-generativeai 等库，Redis 连接失败是因为 simple_progress.py 没有引入 os 模块，日志里还出现过缩略图生成失败。状态：已解决。
• 切片预览黑屏：有反馈说切片后的视频点开是黑屏，同一条反馈还提到使用 deepseek flash 时消耗过多，分析一个两小时视频加一个一小时视频的成本偏高。状态：已解决。
• 进度卡住：下载到 5% 停止、进度始终停在 20% 且任务状态不同步，都在 Issue 里出现过并标记为解决。另有一条版本说明指出，状态文件持续无法写入时任务可能一直显示等待或进行中，对应修复当时仍在验收。
• Docker 一键启动失败：macOS 下报 COPY docker-entrypoint.sh 相关错误，另有用户遇到构建镜像时编译 frontend 失败。状态：已解决。

和同类的差别在哪

aphelion-editor 和 Text_To_Subtitles-Python 与本项目只解决部分相同的问题，重合在「视频编辑」和「字幕生成」两块，不重合在自动选题与一键出片这条主线上。如果一条片子需要你逐帧控制节奏、或者手里只有文稿没有视频，AutoClip 的自动化流程帮不上忙，后面两个项目在各自的窄场景里更直接。AutoClip 的优势在批量与省人力，代价是把内容判断交给模型，并且依赖外部模型服务的可用性和计费。

合规前提

这个工具会把链接指向的视频拉取到本地再做二创，因此素材来源必须是自己拍摄、自己拥有版权，或已经拿到权利人授权的内容。下载他人平台的视频、剪辑后重新发布，可能侵犯著作权，也会违反各平台对搬运和二次创作的具体规则，账号侧的风险由使用者承担。翻唱、影视片段、付费课程这类素材在多数平台上属于高风险对象。

另外，云端模型按调用量计费，长时间视频的分析成本会随素材时长上升，Issue 里已经有人反馈过单次分析两个长视频消耗偏高。批量跑之前建议先用一条短视频试通链路与费用，再决定要不要放量。仓库本身是 MIT 许可证，代码可以自由使用与修改，但许可证不覆盖你处理的内容素材。

适合谁：手上长期有播客、访谈、课程、直播回放的创作者和内容运营，需要把同一批素材铺到多个平台，能接受在电脑上装软件、配好模型 API，并且愿意为模型调用付费。不适合谁：只想剪一条片子并精确控制每个镜头的人，或者只想把一段文字转成字幕文件的人，这两类需求用专门的编辑器或字幕脚本更省事。也不适合习惯在手机上完成全部剪辑、不愿在桌面端配置环境的用户。

焚评：这个项目的量化评分

本项目的选题来自 焚.com（一个按公开公式给 GitHub 项目打分的站）。焚评当前总分 9.3 分（满分 10）。下表是各维度的得分：

评分口径、权重与计算方式见焚.com 的评分方法页；数据随 GitHub 指标刷新，具体数值以焚.com 当前页面为准。本文正文为诀.com 独立撰写，评分数据由焚.com 授权引用。