过去我们谈 AI 视频剪辑，往往容易把注意力集中在“能不能自动剪”上：上传一段视频，AI 找到废话，自动删除，再导出一个成片。

但真正做过口播视频的人会发现，“剪掉什么”远比“怎么剪掉”困难。

一句话到底是口误、重复、正常停顿，还是为了强调而故意重复？一个英文单词说了一半又重新说，应该删掉前半段还是保留？AI 听错了一个专业名词，是应该直接修改字幕，还是重新判断这句话是否需要删除？

这些问题决定了一个 AI 剪辑工具究竟是“自动化玩具”，还是一个真正可以进入生产流程的工具。

chengfeng-videocut-skills 的思路很有意思：不让 AI 直接拿剪刀，而是让 AI 负责判断，让确定性的 Runtime 负责执行，让用户在关键节点进行审核。

GitHub 项目：chengfeng-videocut-skills

一、它到底是什么？

chengfeng-videocut-skills 是一个面向 Codex 的中文口播视频剪辑 Marketplace Plugin。

它并不是一个独立的视频编辑器，也不是把 FFmpeg 包起来做一个简单的“自动剪辑脚本”，而是把视频剪辑拆成了一组可以被 Agent 调用的业务 Skill。

项目目前围绕几个核心环节展开：

• 剪口播：识别口误、重复、残句、英文卡壳、口头禅等内容，并形成删词账本。
• 字幕：围绕剪辑结果生成和处理字幕。
• 画面：处理视频中的视觉内容和动画。
• 导出：把审核后的编辑结果真正变成最终视频。
• 上报 Bug：把问题整理成经过脱敏和确认的 GitHub Issue。
• 检查更新：检查 Plugin 和 Runtime 是否处于匹配、可信的版本状态。

这里最重要的一点是：

Skill 并不等于剪辑引擎。

Skill 主要负责语义判断和流程编排；真正涉及项目状态、Cuts、EDL、媒体处理和导出的工作，则交给 chengfeng-videocut Runtime。

这种架构实际上非常符合 Agent 产品的发展方向：LLM 做判断，确定性系统做执行。

---

二、为什么“不让 AI 直接剪”？

这是整个项目最值得关注的设计之一。

传统的 AI Agent 很容易犯一个错误：

“我知道用户想把这句话删掉，所以我直接修改视频。”

问题在于，视频文件一旦被物理修改，错误的成本就很高。

因此项目把“语义决策”和“物理执行”分开。

在“剪口播”这个 Skill 中，最终产出的核心东西不是一个 MP4，而是一份：

人工复核过的删词账本（Cuts + EDL）。

也就是说，AI 首先回答的是：

哪些词应该删？

而不是：

我现在就把视频剪掉。

这看似只是流程上的区别，实际上是一个非常重要的工程边界。

因为一份删词账本可以反复修改、审核、比较；而一次已经完成的媒体剪切则可能意味着不可逆的文件变化。

因此项目明确规定：

“剪口播”阶段不切媒体。

AI 在这一阶段只做判断和记录，直到用户审核通过，后续的导出 Skill 才进入真正的执行阶段。

这让整个系统具备了一个很重要的特征：

可审计、可回退、可复核。

---

三、一次“剪口播”究竟发生什么？

项目把剪口播设计成一条非常明确的流水线。

大致可以理解为：

真实视频
   ↓
逐词转录
   ↓
建立项目
   ↓
修正专业词
   ↓
五轮扫描口误
   ↓
生成删词表
   ↓
人工审核
   ↓
形成最终 Cuts + EDL
   ↓
交给后续导出流程

其中最值得展开的是中间的三个步骤：

修字、删词、审核。

---

四、第一道闸：先把“听错的字”修正确

很多自动剪辑系统有一个潜在问题：

它把 ASR 转录结果直接当成事实。

但对于中文口播来说，ASR 经常会出现专业名词、产品名称、英文单词识别错误。

例如：

用户真正说的是：

Grok

ASR 可能得到：

grock

如果后面的 AI 直接基于错误文本做判断，就可能出现连锁错误。

所以这个项目把“修字”放到了“删词”之前。

它有一套 AI Term Dictionary，同时支持用户自己的词典。

流程大致是：

原始 Transcript
      ↓
通用词典
      ↓
用户词典
      ↓
修字表
      ↓
进入删词分析

而且这里有一个很重要的原则：

修字只能改变文字表达，不能改变时间、词数和 wordId。

这意味着：

错误词 → 正确词

可以修改；

但：

错误词 → 修改时间戳
错误词 → 修改词序
错误词 → 添加不存在的词

则不应该发生。

这种约束非常关键，因为后续视频编辑依赖逐词时间轴。如果文字和时间轴脱节，后面的剪辑结果就可能失真。

---

五、第二道闸：五轮扫描，而不是“一次性让 AI 找废话”

这是项目另一个非常值得借鉴的设计。

很多人第一次设计 AI 剪辑 Agent，可能会直接给模型一个任务：

“请帮我找出所有口误、重复和废话。”

看起来很自然，但问题是：

一次让模型判断太多类型，会让判断标准互相污染。

这个项目采取了完全不同的方式：

五轮扫描

第一轮：

重复

第二轮：

残句与改口

第三轮：

口误重说

第四轮：

英文卡壳

第五轮：

口头禅与语气词

也就是说，每一轮只负责一种判断。

例如第一轮只问：

这里有没有重复？

而不会同时问：

这里是不是口头禅？是不是残句？是不是应该考虑停顿？

这样做的好处是显而易见的。

每一轮都变成一个更小、更明确的问题。

---

六、为什么“重复”要和“口头禅”分开？

因为它们的客观程度完全不同。

例如：

“这个功能呢……这个功能呢……其实很好用。”

这种重复通常比较容易判断。

但是：

“其实我觉得，这个东西吧，它还是挺好用的。”

这里的“其实”“吧”“还是”到底应该不应该删？

答案并不完全客观。

它和用户的个人表达习惯有关。

有人喜欢干净利落的口播：

“这个功能很好用。”

也有人认为：

“其实我觉得这个功能吧，还是挺好用的。”

更接近自然说话。

所以项目把用户偏好放到了语义判断体系中。

其优先级大致是：

用户偏好
   >
用户判例
   >
通用判例

这意味着 AI 剪辑不是简单追求“语言最短”，而是在逐渐学习：

这个用户喜欢什么样的口播。

---

七、从“一次性 AI 决策”变成“可审核的删词账本”

项目并没有让 AI 输出一句：

“建议删除 37 处。”

而是要求形成结构化的删词汇总表。

例如：

#	时间	类型	删除	剩下读作	风险	依据
1	00:12	重复	这个功能呢	这个功能它其实	低	判例 R2
2	02:31	改口	比如我就让他跟踪	比如我让 Grok 跟踪	高	判例 R5

这件事情非常重要。

因为 AI 的判断从：

“我觉得这里应该删。”

变成了：

“我认为这里属于某一种类型，根据某条规则，因此建议删除这些词，风险等级为高。”

后者才真正具备审核价值。

用户不需要重新看完整个视频来理解 AI 在做什么，而是可以针对删词表进行检查。

---

八、为什么还需要“重复句子表”？

这是一个很细节、但非常实用的设计。

逐词删词表只能告诉用户：

哪几个词被删除。

但如果用户真正录了一句话三遍，问题就不一样了。

例如：

第一遍：因为今天有什么……
第二遍：因为今天有什么……
第三遍：因为今天有什么……

真正需要审核的问题可能是：

三遍到底保留哪一遍？

所以项目额外设计了“重复句子表”。

例如：

句子	说了几遍	保留哪遍	删除哪几遍	风险
因为今天有什么……	3	第 3 遍	第 1、2 遍	低

这说明项目并不是简单地把剪辑理解成：

删除一些词。

而是把口播剪辑理解成：

重建一条更自然的语言表达路径。

---

九、用户什么时候介入？

一个好的 Agent 并不是让用户“什么都不管”，也不是让用户“每一步都确认”。

项目实际上对用户介入点进行了限制。

用户主要在三个关键位置说话：

1. 同源项目选择

如果这个视频以前已经剪过，需要用户选择：

继续上次的项目，还是重新开始？

2. Studio 审核

AI 完成提案之后，把结果交给用户在 Studio 中检查。

3. 完成确认

用户确认之后，才进入后续执行流程。

这是一种很典型的：

低频、高价值人工介入。

Agent 自己完成大量机械流程，但把真正影响最终结果的节点留给人。

---

十、Studio 不是 AI 自己“造一个审核页面”

项目还有一个很容易被忽视的安全边界：

如果 Runtime 没有安装好，Agent 不允许自己临时手搓一个“审片台”替代产品。

这条规则非常重要。

因为从 Agent 的角度看，最容易出现这样的行为：

Runtime 不存在
      ↓
Agent 想办法
      ↓
自己写一个 HTML
      ↓
做一个假的审核界面
      ↓
继续完成任务

表面上看，这叫“智能”。

实际上却可能导致整个产品合同失效。

项目因此明确要求：

Runtime 缺失时应该停下来，而不是自己制造一个不兼容的替代产品。

这其实体现了一种很成熟的 Agent 工程理念：

Agent 的能力边界必须服从产品契约。

不是“只要能完成任务就行”。

---

十一、Runtime 与 Skill 的分层

整个架构可以简化成：

             Codex
               │
       ┌───────┴────────┐
       │                │
     Skills          Plugin UI
       │
       ↓
业务判断 / 流程编排
       │
       ↓
chengfeng-videocut Runtime
       │
 ┌─────┼──────────────┐
 │     │              │
项目   Cuts / EDL     Studio
 │
 ↓
媒体处理 / Render / Verify

这种分层的核心思想是：

LLM 不应该成为整个系统唯一的状态管理器。

项目状态、revision、EDL、媒体文件、服务状态等，都由 Runtime 管理。

Agent 只负责：

理解用户
↓
调用能力
↓
读取结果
↓
做判断
↓
组织下一步

而不是自己偷偷维护一套“虚假的项目状态”。

---

十二、为什么项目特别强调 Revision 和 CAS？

如果仔细看项目设计，会发现它非常重视：

• projectId
• workflow stage
• Project revision
• Cuts revision
• EditList revision
• CAS

这些概念说明开发者考虑的不只是“单次运行成功”，而是：

Agent 在一个真实项目上反复操作时，如何避免状态被错误覆盖？

例如：

Agent A
读取 revision = 12

用户同时修改项目

revision = 13

Agent A
尝试基于 revision 12 写入

如果系统没有版本控制，Agent A 很可能把用户的新修改覆盖掉。

因此 revision/CAS 可以让系统知道：

“你现在操作的已经不是刚才看到的那个版本了。”

这对于 Agent 产品非常重要。

因为传统 GUI 软件通常有明确的状态和用户操作边界，而 Agent 是一个异步、可重试、可能反复调用工具的自动化主体。

没有状态版本控制，Agent 很容易把旧状态写回新项目。

---

十三、安装设计也体现了“确定性优先”

这个项目并没有简单地告诉用户：

npm install xxx

然后结束。

它对 Runtime 的安装也做了严格限制。

例如固定 Runtime 版本：

Plugin 0.10.8
        ↓
Runtime v0.4.8

而不是：

latest

为什么？

因为 latest 会漂移。

今天安装的 Runtime 和明天安装的 Runtime 可能已经不是同一个东西。

对于一个依赖严格产品合同的 Agent Plugin，这非常危险。

因此项目强调：

固定版本 + Release + SHA-256 校验 + doctor 检查。

可以理解为：

发现 Runtime
   ↓
检查版本
   ↓
确认 Release
   ↓
下载
   ↓
SHA-256 校验
   ↓
安装
   ↓
doctor
   ↓
确认服务健康

只有整个链路成立，Skill 才继续工作。

---

十四、为什么服务不能随便 nohup？

项目还特别规定，Plugin 不应该直接使用：

launchctl
nohup
foreground server

去偷偷管理产品服务。

Runtime 自己负责服务生命周期。

在 macOS 上使用用户级 LaunchAgent，在 Windows 上使用 Windows Task。

这意味着：

Codex 当前终端不是产品服务的生命周期所有者。

否则很容易出现：

终端关闭
   ↓
服务消失

Codex 重启
   ↓
又启动一个服务

第二个服务
   ↓
端口冲突

最终整个 Agent 工作流变得非常不稳定。

所以项目采用的是：

声明式 ensure-running。

Agent 只需要告诉产品：

确保服务处于可用状态。

至于服务怎么启动、怎么常驻、怎么恢复，由 Runtime 自己管理。

---

十五、Windows 支持意味着什么？

这个项目并不是单纯针对 macOS 的脚本。

README 明确说明，Runtime 从 v0.4.2 开始正式支持 Windows，并进行了安装、常驻服务、崩溃自愈、重启自启、建档和导出的链路验证。

这背后的意义是：

它开始从“开发者工具”向“真正的跨平台 Agent 产品”演进。

尤其是视频处理这种任务，涉及：

• FFmpeg
• FFprobe
• Bun
• Node.js
• Chrome
• 本地文件
• 后台服务
• 浏览器渲染

任何一个环节跨平台处理不当，最终都会让 Agent 的行为变得不可预测。

因此把这些依赖纳入 Runtime 的受管目录，而不是让 Plugin 到处寻找系统环境，是一种更可靠的产品化思路。

---

十六、这个项目真正有价值的地方，不是“AI 会剪视频”

如果只看表面，这似乎只是一个：

“AI 自动剪中文口播视频”

的项目。

但如果从工程角度看，它真正有价值的地方其实是另外三个关键词：

1. 判断与执行分离

AI：

决定删什么

Runtime：

决定怎么安全地执行

---

2. AI 建议与人工确认分离

AI：

提出删词方案

用户：

确认删什么

系统：

执行最终版本

---

3. 自然语言与确定性状态分离

Agent：

理解“帮我继续剪上一版”

Runtime：

projectId = xxx
revision = 17
cuts = ...
EDL = ...

这三层分离，实际上比“用了什么模型”更值得关注。

---

十七、它也代表了一种新的 AI 工具设计方式

传统软件通常是：

用户
 ↓
按钮
 ↓
程序
 ↓
结果

Agent 软件更接近：

用户自然语言
 ↓
Agent
 ↓
Skill
 ↓
工具/API
 ↓
确定性 Runtime
 ↓
结果

问题也随之改变。

传统软件最重要的是：

UI 有没有设计好？

Agent 软件更重要的问题变成：

Agent 有没有遵守正确的操作边界？

例如：

• 没有真实视频时能不能瞎编一个？
• Runtime 不存在时能不能自己造替代品？
• 旧 revision 能不能覆盖新 revision？
• 用户没有确认时能不能直接剪？
• 更新是不是偷偷切换到了未知版本？
• ASR 错了能不能直接猜？
• 失败之后会不会偷偷换端口启动另一个服务？

这些其实都是 Agent 产品的“安全边界”。

而 chengfeng-videocut-skills 的很多设计，恰恰是在回答这些问题。

---

十八、从这个项目可以看到什么未来？

如果把“AI 视频剪辑”再往前推一步，未来真正成熟的产品可能不会是：

“AI 帮你自动剪完视频。”

而更可能是：

“AI 理解你的剪辑习惯，提出一份可解释、可审核、可回溯的编辑方案，然后由确定性的编辑引擎执行。”

用户甚至不需要每次都告诉 AI：

“口头禅少一点。”

系统可以从历史确认中逐渐形成：

用户偏好
+
用户判例
+
通用规则

最终形成个人化的剪辑风格。

于是“AI 剪辑”就从一次性的自动化功能，变成了：

一个越来越懂你的剪辑 Agent。

---

结语：真正成熟的 AI，不是“替你做完”，而是“知道什么时候该停下来问你”

chengfeng-videocut-skills 最值得研究的，并不是它拥有多少个 Skill，也不是它能调用 FFmpeg、ASR 或 Studio。

真正值得注意的是它建立了一套非常清晰的边界：

AI 负责理解和判断。

Runtime 负责确定性执行。

版本系统负责保护状态。

用户负责关键决策。

审核结果成为下一轮 AI 判断的经验。

这套设计让视频剪辑从一个“让 AI 随便操作媒体文件”的任务，变成了一条可追踪、可审核、可回滚、可持续学习的生产流水线。

对于正在探索 Agent + 专业软件结合的人来说，这个项目提供了一个很好的范例：

不要让 Agent 取代整个产品。

让 Agent 成为产品之上的智能编排层。

而这可能才是未来 AI 原生专业工具最值得探索的方向。