帧序 FrameCue：把 AI 剪辑做成一套能持续积累的工作流

做完一支视频，能留下什么

我希望 AI 参与视频制作之后，留下的不只有一段成片，还包括下一次可以继续使用的素材、动画和制作方法。标题换一行字、同一内容改成横版、下一场活动沿用某个效果，这些都应该有明确的继续方式。

因此，在搭建帧序 FrameCue 时，我把几件事放进了同一个问题里考虑：每支视频怎样独立管理，做过的特效怎样积累，软件怎样安装和复用，以及隔一段时间重新打开工程时，还能不能找到原来的素材与修改依据。

FrameCue 由此形成了一套工作区、Skill 和工具入口。它让 Codex 协调已有剪辑工具，也把制作过程中容易散落的信息保存下来。

把不同的工作交给合适的工具

FrameCue 的入口是 $framecue。用户用自然语言描述要做什么，Agent 先判断目标项目与当前阶段，再调用对应工具。

组成	负责的工作	这样划分的原因
FrameCue Skill	项目选择、需求整理、工具调度和交付记录	让不同任务遵循同一套制作规则
ChatCut Desktop	素材导入、主时间线、预览和本地导出	在可视化编辑器里检查剪辑结果
HyperFrames	标题、姓名条、信息卡和片尾动画	保留 HTML、CSS、JavaScript 源码，方便调整和复用
FFmpeg / ffprobe	转码、抽帧、媒体探测和解码检查	用实际文件检查支撑导出结果

这套分工也决定了第一步该验证什么。Skill 文档可以先写得很完整，但真正限制流程的是编辑器能不能连接、能不能读取工程、能不能写入时间线和导出视频。因此，接入与短样片要尽早验证，后续再扩大制作范围。

软件装一次，每支视频各自管理

我考虑过一个很具体的问题：下一支视频开始时，是否又要装一遍依赖、找一遍 FFmpeg、重新下载浏览器？如果每个项目都重复做，磁盘和环境维护会很快成为负担。

FrameCue 把工具集中在工作区的 tools/ 中。Node、FFmpeg、HyperFrames、浏览器和 ChatCut 分开存放，由配置文件记录路径，再通过统一启动器调用。已经配置好的工具供不同视频项目复用。

这里也区分了软件、应用数据和缓存。软件是运行依赖；应用数据包含编辑器的持久状态；下载包、抽帧和临时渲染是可重建内容。清理空间时，不能把这三类东西混在一起处理。

这是一种本地工具组织方式，还不是完整的便携应用。移动整个目录后，宿主连接配置、快捷方式和剪辑器媒体引用仍可能需要更新。公开仓库也只提供源码和依赖清单，新电脑需要自行配置工具。

一支视频一个项目，但一次改稿不是一个新项目

项目隔离首先是为了让上下文明确。用户说“继续改这支视频”时，Agent 应该能找到它的简报、素材、剪辑方案和当前版本，不需要从上一段聊天里重新猜测。

新项目有独立 ID，目录包含日期、名称和随机标识。同名视频也不会覆盖。执行前还要核对 ChatCut 实际打开的工程，不能因为某个文件夹刚刚修改过，就默认它是本次目标。

但项目也不能切得太碎。同一条视频修改字幕、调整节奏、导出横竖版或者增加语言版，都继续使用原项目。另一场活动、另一条独立叙事，才需要新建项目。

以一支校园活动回顾为例，横版展示和竖版发布可以共用素材与叙事，但各自保留尺寸、帧率、语言和交付标识。这样既能复用内容，也不会把两个版本的输出要求混在一起。

每个项目内还会分开保存原件、缓存、动画源码、编辑器关联、快照和成片。大文件可以登记真实外部路径，不要求每建一支视频就复制一整批原片；相应地，交接时必须核对这些外部引用是否仍然可用。

复用的是素材，也是做法

我希望公共库能够积累的不只有视频和图片，还包括已经做过的动画、特效、处理配方和常用功能。某个标题效果经过一次调整后，下一次应当能换参数继续使用。

这也是为什么动画不能只留下渲染后的视频。源码、文字参数、字体、素材引用和工具版本共同决定了能否重做。一个滤镜或转场，也需要保存处理配方，而不只是“看起来像这样”的预览。

复用可以分成三种情况：

情况	可以复用什么	仍需要做什么
使用同一段素材	已有文件	核对来源、规格和使用范围
同一动画换文字或颜色	模板代码和设计	更新参数，重新渲染受影响的片段
输入、参数和输出规格完全一致	已检查过的成品	核对字体、工具版本等依赖是否也一致

所以，“可以复用”并不自动意味着“不用渲染”。跳过渲染需要有依据，相同文件名也不能证明两份内容一致。目前自动缓存命中尚未实现，执行者仍需逐项核对。

公共库还采用固定版本。已经被项目使用的模板不直接覆盖；更新后增加新版本，旧项目继续引用旧版本。否则，一次看似无关的模板升级，就可能改变之前视频重新渲染的结果。

可复用的技术内容与可公开使用的素材也需要分开判断。音乐、字体、Logo 和活动照片要记录来源与使用范围。某个文件能被下一支视频读取，不代表它就适用于所有公开作品。

用自然语言提出需求，让 Agent 维护结构

有了这些记录，很容易把工作流做成一套需要用户不断填表的系统。但我希望日常使用仍然是“用上次的片尾”“把这句标题改一下”“继续这支视频”。

因此，目录、素材清单、库项版本和使用记录由执行者维护。用户已经提供的信息应该先整理进去，只有影响制作方向的关键内容缺失时才继续确认。

这个原则也适用于工具选择。已有动画先查库，已有功能先查 tools/；通用处理逻辑不为每支视频重新写一遍，项目专属的人名、日期和文案则留在项目参数里。

改稿需要能定位，交付需要能重做

如果反馈只有“第十二秒不对”，而草稿已经有几个版本，很容易改错位置。FrameCue 把反馈绑定到具体修订号和成片时间码，草稿版本递增保存，已经审阅的文件不直接覆盖。

局部修改也应当尽量局部处理。普通字幕优先保留可编辑文字轨，复杂动画才渲染为视频。如果动画已经以视频形式导入编辑器，改字就需要回到源码重新渲染，不能假定成片中的文字仍然可以逐字编辑。

透明动画则是需要单独检查的兼容环节。动画文件支持透明，不代表经过编辑器预览和最终导出后仍然正确。必要时可以将动画与目标镜头局部预合成，同时保留源文件，以便之后修改。

交付因此需要一个清单：成片、需要的字幕与封面、动画源码、素材版本、编辑器关联和恢复说明。只留下 MP4，会失去许多继续编辑的条件。

归档、备份和本地运行，都要落实到实际行为

把项目移进 archive/ 能帮助整理目录，但同一块硬盘上的另一个文件夹不能承担独立备份的作用。目录移动还可能让编辑器找不到原来的媒体，因此有时原地标记归档更合适；真正迁移后，需要实际重开工程核对。

缓存也有类似边界。自动识别生成的转录可以重建，但人工逐字修正后的字幕可能已经成为唯一有效版本，应移到保留目录。判断能不能删除，取决于内容能否恢复，而不只取决于它最初由哪个工具产生。

我也把本地制作、账号联网和可选云功能分别考虑。FrameCue 优先使用本地媒体处理和渲染路径，费用记录则区分宿主推理、编辑与可选托管生成。不能仅凭“文件最后保存在电脑里”，就承诺整个过程完全离线或免费。

本次公开也遵循同样的区分：GitHub 发布工作流、Skill、脚本和空模板；实际视频、音频、图片素材、登录数据和剪辑工程留在本地。博客介绍设计与进展，不展示或托管这些媒体。

当前进展，以及后面要补的环节

截至 2026 年 9 月 12 日，开发工作区已经有独立项目创建检查、2 秒中文动画本地渲染记录、ChatCut 工具发现和时间线编辑记录。一支约 15 秒的竖版宣传片已通过 ChatCut 本地导出，输出包含 1080×1920 视频和音轨。

开发工作区也开始登记竖屏动效模板、原创电子配乐和 AI 插画。公开版本保留空库结构与登记规则，实际项目内容没有上传。

环节	当前状态
独立项目目录、模板与 Skill	已建立；项目创建和隔离有检查结果
本地动画、剪辑连接与样片导出	在开发环境中已有实际执行证据
素材入库、版本引用、简报和状态回写	由执行者按规则维护
自动去重、自动缓存命中、自动修订号	尚未实现
完整备份、原生工程恢复、更多复杂剪辑场景	仍需实现或实际验收

后续值得优先补的是制作记录与实际工程的一致性，以及局部修改和重开恢复的验证。在此基础上，再增加自动入库和缓存复用，才能让积累下来的内容真正减少下一次制作的工作量。

源码和配置说明已放在 FrameCue GitHub 仓库。只创建工程目录可以使用已有 Node.js：

node tools/new-project.mjs "校园活动回顾"

完整媒体工作流目前面向 Windows，需要按仓库说明配置工具，再检查当前环境的可调用性与 Skill 发现状态。仓库当前未指定开放源码许可证，第三方工具遵循各自的许可与服务条款。