开源发现

做竖屏 motion graphics（MG）动画时，常见路径是：先写口播稿、导出字幕，再人工拆镜头、找参考与素材、在 Remotion或 HTML动画工程里逐镜调 timing，最后导出竖屏成片。环节一多，就容易出现「字幕总时长对不上画面」「某一镜返工拖垮整条时间线」「多人对同一会话并行改文件」等问题。auto-motion（GitHub：`vibe-motion/auto-motion`）把这条链路收成一份可克隆的工作流模板——你主要准备根目录下的 `transcription.srt`，然后让 Codex CLI 读取并执行 `PROMPT.md` 里的任务说明；Codex会按字幕语义拆成连续镜头，为每镜建独立目录，再顺序调用 Claude Code 生成单镜头动画，最后用 FFmpeg 拼接出 `final.mp4`。仓库简介写的是 Automated SRT-to-motion workflow with Codex cli + Claude Code with any LLM；本文核对实时 API时，公开星标约 432、fork约 57；界面主语言字段为 HTML；`license` 字段为 null（暂无 SPDX许可信息，使用与二次分发前请自行阅读仓库说明）。中文 README为默认入口，另附 `README.en.md`。权威地址：https://github.com/vibe-motion/auto-motion 。

需要先划清边界：auto-motion 不是又一个「一键成片」闭源 App，也不是单独的渲染引擎；它是「调度层 + 单镜执行模板 + HyperFrames相关技能 + 拼接与验收脚本」的组合。动画落地依赖 `exampleFolder/.claude/skills/` 中的 HyperFrames 技能包（本站若已单独介绍过 HyperFrames，那是依赖名；本文只讲 auto-motion这条 SRT→多镜 MG工作流，请勿与已覆盖的 Motion Prompt／`showheyohtaki/motion-prompt` 混淆）。成片规格在官方说明里约定为 1080×1440、约 30fps、静音且无音轨 的竖屏 MP4，适合短视频信息流画幅。

图片来源：GitHub Open Graph for vibe-motion/auto-motion

它解决什么问题

口播解说、产品演示、技术科普类竖屏内容，往往先有时间轴清晰的字幕，再需要「看起来像设计过的 MG」而不是干巴巴的静态字幕卡。手工流程里，拆镜人要保证镜头首尾相接、总时长等于字幕总时长；执行人要在每个镜头里写动画、下素材、渲 MP4；集成人再用剪辑或 FFmpeg对齐。任意一环返工，前面的语义切割就可能失效。

auto-motion把这些约定写进可执行的 Agent剧本：`PROMPT.md` 规定如何读 SRT、如何建 `scenes/scene-00N`、如何从 `exampleFolder` 复制模板与技能、如何串行调用 Claude Code、如何检查规格并拼接。对已经在本机登录 Codex 与 Claude Code 的开发者来说，等于多了一条「用编码 Agent调度另一编码 Agent做多媒体流水线」的可复用样板，而不是从零写 shell与 prompt。

官方演示截取自成片约 `00:00:03,000` 到 `00:00:13,000`：左侧是输入给流水线的 SRT片段（`readme-assets/auto-motion-demo.srt`），右侧是自动生成并烧回字幕的动画（`readme-assets/auto-motion-demo.gif`）。另一张「运行证据」图（`readme-assets/evidence.png`）来自真实长跑：多镜头任务已连续运行约 1小时36分钟，Codex仍在等待后续镜头的代码实现与渲染——说明作者按长任务、单路顺序执行来设计，而不是演示用的假短链路。

图片来源：官方仓库 readme-assets/evidence.png

架构：四层怎么配合

1. 调度层——Codex + PROMPT.md

`PROMPT.md` 是整条自动化的任务说明。按 README，调度层会：读取当前工作目录的 `transcription.srt`；按语义把字幕拆成连续且完整覆盖总时长的镜头；为每个镜头创建独立目录（如 `scenes/scene-001`）；从 `exampleFolder` 复制运行模板和 HyperFrames相关技能；顺序调用 Claude Code生成每镜动画 MP4；检查镜头时长与产物规格，再用 FFmpeg拼成根目录 `final.mp4`。把「业务规则」放在可版本管理的 Markdown里，比散落在聊天记录中的口头约定更容易复现与审阅。

2. 执行层——Claude Code + run-claude-ai.sh

`exampleFolder/run-claude-ai.sh` 是单镜头执行模板。Codex为每镜填好例如：`SCENE_ID`、`SCENE_DURATION_SECONDS`、`SCENE_TEXT`、`OUTPUT_FILE`、`FULL_TRANSCRIPT_PATH`。脚本通过 `claude -p` 非交互调用 Claude Code，并要求模型输出固定阶段进度消息，便于后续自动校验。原始流式日志、错误日志与用户可读进度分别写入镜头目录中的 `claude-<scene>.stream.jsonl`、`claude-<scene>.stderr.log`、`claude-<scene>.user.log`。某一镜失败时，优先打开这三类文件，而不是整仓重跑。

3. 动画层——HyperFrames技能

Claude Code基于 `exampleFolder/.claude/skills/` 里的 HyperFrames相关技能编写 HTML动画项目，并渲染约定的竖屏 MP4。技能解决的是「单镜如何写成可渲工程」；调度层解决的是「何时开哪一镜、如何拼回来」。若单镜规格不一致，官方提醒应先统一转码再拼接，避免 concat花屏或时长漂移。

4. 验收层——auto-test

`auto-test/run.sh` 提供端到端入口：创建临时工作区，复制测试字幕与模板，调用 Codex跑完整流程，再用 `auto-test/validate.sh` 检查——Claude Code阶段消息是否完整；单镜 MP4与 `final.mp4` 是否存在；是否约为1080×1440、约30fps；时长是否接近字幕总时长；是否没有音轨。测试产物落在 `auto-test/.tmp/`（已被 `.gitignore` 忽略），适合作为回归与演示环境。

图片来源：官方仓库 readme-assets/auto-motion-demo.gif 帧截取

它能做什么（能力清单）

• SRT驱动的多镜 MG成片：输入根目录 `transcription.srt`，输出每镜 `scenes/scene-*/scene-*.mp4` 以及最终 `final.mp4`。
• 可版本化的 Agent剧本：用 Codex执行 `PROMPT.md`（官方示例命令含 `--cd .`、`--sandbox danger-full-access`、`--ask-for-approval never` 等；权限面很大，只应在你信任的本机与仓库上使用，并按团队安全策略收紧）。
• 单镜可观测与可重试：独立目录 + 三类日志；文档明确同一时间只运行一个 Claude Code调用，不并行渲染多镜，降低会话与素材冲突。
• 镜头必须盖满时间轴：每个镜头完整覆盖字幕时间轴，镜头时长总和应等于字幕总时长——这是语义拆镜的硬约束，也是验收脚本关注点。
• 内置端到端测试：`bash auto-test/run.sh` 可在干净临时区验证流水线是否仍能跑通。
• 双语文档：中文为主、`README.en.md` 同步英文说明，方便跨语团队对照。

前提条件方面，请先确保本机已安装并登录 Codex CLI、Claude Code，以及 Node.js 22+、FFmpeg／FFprobe、jq，并处于可联网环境（Claude Code可能搜素材、装依赖或下载品牌视觉资产）。可用各工具的版本命令做基础体检，再开始长跑。

图片来源：官方仓库 readme-assets/auto-motion-demo.gif 帧截取

快速开始与目录心智模型

准备阶段：把你的字幕复制为仓库根目录的 `transcription.srt`。执行阶段：在仓库根目录按官方 README调用 `codex exec … - < PROMPT.md`。查看阶段：打开根目录 `final.mp4`；若某一镜失败，进入对应 `scenes/scene-00N/` 阅读 stderr／stream／user日志。目录骨架可理解为：`PROMPT.md` 管总流程；`exampleFolder/` 提供单镜脚本与 `.claude/skills/`；`auto-test/` 管回归；生成后的 `scenes/` 与 `final.mp4` 是交付物。把心智模型记成「剧本在上、模板在中、产物在下」，后续改拆镜策略时优先改 `PROMPT.md`，改单镜渲染习惯时优先改 skills与 `run-claude-ai.sh`。若你是第一次跑，建议先用仓库自带的测试字幕走一遍 `auto-test`，确认本机 Codex／Claude Code／FFmpeg链路通畅，再换成业务字幕；这样可以把「环境问题」和「文案／拆镜问题」分开排查，少浪费长跑额度。

图片来源：X amplify_video_thumb 预览图（帖 2116840826391421061 相关）

有什么好处，又有哪些代价

好处一：时间轴与画面同源。 从 SRT出发拆镜，天然对齐口播节奏，减少「画面讲完了字幕还在滚」的后期硬剪。好处二：职责分离。 Codex负责编排与目录约定，Claude Code负责单镜创意与代码实现，FFmpeg负责无损拼接，日志落盘可回放——比把一切塞进一次超长聊天更可维护。好处三：规格可机器验收。 分辨率、帧率、静音、时长接近度都有脚本可检，适合作为团队内部竖屏 MG模板的起点。好处四：依赖面相对清晰。 不强制绑定某一家闭源成片 SaaS；技能层可替换或演进，调度层剧本仍可复用。

代价也很实在。 长任务可能跑到小时级，吃满本机 Agent配额与网络；必须同时维护 Codex与 Claude Code的登录与版本；官方示例沙箱偏「全自动」，误用可能在本机执行高权限操作；GitHub API当前 未标注 license，商用与二次分发前务必自行确认授权；素材搜索与品牌资产下载还涉及版权与商标合规，流水线不会替你做法务判断。

和相邻项目怎么区分

开源圈子里，「Motion」字样的仓库不少，读者容易串台。本站此前若已介绍过 Motion Prompt（例如 `showheyohtaki/motion-prompt`），那是偏提示词／创意引导的路线；HyperFrames 则更接近本仓库单镜渲染所依赖的技能与动画基座名称。auto-motion 的独特卖点在于：用 SRT时间轴 驱动、用 Codex调度 + Claude Code逐镜实现 + FFmpeg拼接 形成可测试的闭环模板。选型时建议先问三句：我有没有稳定的字幕文件？我能不能接受本机长跑双 Agent？我是否需要竖屏静音 MG而不是带原声剪辑？三者都偏「是」，再克隆本仓库试 `auto-test`；否则先手工做一镜验证审美，再决定是否自动化。

与 X上作者演示帖对照时，可以把帖内视频预览缩略图当作「成片气质」的旁证，但仍以仓库内 `readme-assets` 的 GIF与 evidence截图为准——后者可复现、可引用、也不依赖第三方 CDN短期失效。把官方资产上传到站点媒体库后，用文中的「外部配图」占位依次对应封面、证据、演示静帧与相关预览，阅读体验会更接近「看见流水线」而不是只读概念名词。

适合谁，不适合谁

适合已经在用 Codex + Claude Code、希望把口播／解说类 SRT 批量变成竖屏 MG的创作者、工程师与小团队；适合想研究「编码 Agent调度另一 Agent做多媒体 ETL」的平台同学；也适合已有 HyperFrames／HTML动画技能、想把分镜自动化嵌进自有管线的工作室。

若你只需要偶尔手搓一条 Remotion工程、或主要兴趣是提示词方案（例如已报道过的 Motion Prompt），不必强行上这套双 Agent长跑。若目标网页 DOM自动化或桌面 Computer Use，也请另选对应工具。本文只做开源发现介绍，不替代官方 README、安全说明与许可证文本；权威来源始终是 https://github.com/vibe-motion/auto-motion 。运行前请自行评估沙箱参数、审批策略、素材版权，以及当前仓库仍为空的 license字段对你业务的影响。