对话式视频剪辑全解析：从文本化剪辑到 MCP 插件，AI Agent 是怎么接管粗剪流水线的

本文由 辛梓煜@词元2号站（www.ciyuanerhao.com）撰写，转载请注明出处。

快速摘要

先给结论，省得你翻半天：所谓"用一句话剪视频"，技术上并不是一个黑箱模型直接吐出成片，而是把剪辑拆成了四个可被程序调用的步骤——语音转录、文本与时间码的映射、时间线操作、导出交付。ChatCut 干的事情，就是把这四步封装成标准接口，再通过一个托管的 MCP Server 暴露给 AI Agent。它的官方 Codex 插件（仓库 ChatCut-Inc/agent-plugin）拆开看只有三样东西：一份 plugin.json 清单、一份 .mcp.json 远程服务配置、一组 skills/ 工作流文件。真正值得学的不是"能用嘴剪片"这个噱头，而是"SaaS 产品如何把自身能力开放给 Agent 生态"的这套范式。

它适合的人群很明确：手里已经有拍好的对谈类、口播类、访谈类素材，只想快点出一版粗剪的人。它不适合的场景也很明确：靠精细调色、复杂合成、逐帧动效吃饭的活儿，它替代不了你的时间线。

这篇文章我会把整条链路从头拆到尾：文本化剪辑的底层数据结构长什么样、MCP 协议在中间扮演什么角色、Codex 插件的目录结构和清单文件怎么写、skills 工作流为什么能省掉 Agent 的重复推理、以及我自己折腾一圈之后踩到的那些坑（素材上传、额度消耗、XML 互通、转录错字）。

想看完整拆解，往下翻。

一、先把问题摆清楚：剪辑里真正耗时间的到底是什么

1.1 粗剪和精剪，是两种完全不同的劳动

聊 AI 剪辑之前，得先把"剪辑"这个词拆开。它至少包含两类性质完全不同的工作。

一类是结构性决策：这段访谈四十分钟，哪三分钟是有效信息？嘉宾说了三遍同一个观点，留哪一遍？开场的寒暄要不要砍掉？这类工作考验的是判断力，需要你听懂内容、理解叙事逻辑。

另一类是机械性执行：把素材拖进项目、在波形图上找到那个"嗯……"然后切一刀、把二十个片段按顺序排到轨道上、生成字幕再逐条对时间、导出的时候选一堆参数。这类工作不需要任何创意，纯粹是手上功夫。

传统剪辑软件的问题在于，它把这两类工作强行捆绑在了同一套交互里。你想做一个结构性决策，得先完成一堆机械性执行才能看到结果。四十分钟的访谈，光是听一遍找出可用片段就要一个多小时，真正动脑子的时间可能只有十分钟。

我自己剪过几期长对谈，最崩溃的不是不知道该剪什么，而是知道该剪什么，但要花两小时把它剪出来。

1.2 对话类素材的特殊性

这里有个关键前提：对话类素材的信息主要承载在语音里。

一段风光片，画面是全部；一段访谈，画面几乎只有一张会动的脸，真正的内容在音轨上。这就意味着，如果我们能把音轨可靠地转成文字，那么"剪这段视频"这个动作，在信息层面等价于"删这段文字"。

这是文本化剪辑成立的全部逻辑起点。也解释了为什么这类工具永远优先服务播客、访谈、口播、纪录片、会议记录这些场景——因为只有在这些场景里，文本和视频的信息是同构的。

1.3 从"改文字"到"下指令"的两级跳

理解了这一点，后面的演进就很自然了：

• 第一级跳：把视频转成文字，让你像改 Word 一样改视频。删掉文档里的一句话，时间线上对应的画面跟着消失。这条路 Adobe 早就在走，Premiere Pro 的"基于文本的编辑"就是这个思路。
• 第二级跳：既然编辑动作已经变成了对文本的操作，那这些操作能不能交给会读文本的 AI 来做？你不用亲自删，你只要说"把所有语气词删掉""按主题分段""找出最有信息量的三分钟"，剩下的让模型执行。

ChatCut 站的位置是第二级跳，而且它还多走了半步——它把这些能力做成了标准接口，让外部的 AI Agent（比如 Codex）也能远程调用。

这半步，就是本文后半程要重点拆的东西。

二、对话式剪辑的三个技术底座

很多人把"AI 剪辑"想象成一个大模型看完视频直接输出成片，那是误解。真正让它跑起来的，是三块非常朴素的技术底座。

2.1 底座一：高精度语音转录（ASR）

术语先解释清楚：ASR 是 Automatic Speech Recognition 的缩写，中文叫自动语音识别，说白了就是"把声音变成文字"。你手机里的语音输入法用的就是这个技术。

但剪辑场景对 ASR 的要求，比语音输入法苛刻得多。它不光要认出说了什么字，还得同时给出三样东西：

其中时间码的精度是生死线。如果时间码只精确到"秒"，那你删掉一个词，画面可能会多留半秒的嘴型或者少半秒的收音，剪出来一听就是坏的。所以这类工具都会强调"帧级时间码"——按帧对齐，25fps 的片子，每一帧是 40 毫秒，误差控制在这个量级，人耳基本听不出破绽。

说话人分离（业内叫 speaker diarization）也是个硬功夫。它要在没有任何先验信息的情况下，判断出音轨里一共有几个人、每一段属于谁。做得好的系统能把双人对谈分得干干净净，做得差的会在两人抢话的地方来回横跳。

2.2 底座二：文本与时间线的双向映射

这是整个文本化剪辑最核心、也最容易被忽略的一层。

转录完成后，系统内部维护的并不是一篇"文章"，而是一张带时间戳的词表。可以粗略理解成这样一个结构：

{
  "media_id": "clip_001",
  "fps": 25,
  "segments": [
    {
      "speaker": "SPK_A",
      "start_frame": 1250,
      "end_frame": 1310,
      "text": "我们今天聊的第一个话题",
      "words": [
        { "w": "我们", "s": 1250, "e": 1262 },
        { "w": "今天", "s": 1263, "e": 1275 },
        { "w": "聊的", "s": 1276, "e": 1288 },
        { "w": "第一个", "s": 1289, "e": 1301 },
        { "w": "话题", "s": 1302, "e": 1310 }
      ]
    }
  ]
}

有了这张表，"删文字"这个动作就有了严格定义：

你删掉文本里的第 3 到第 5 个词 → 系统查表得到帧区间 [1276, 1310] → 在时间线上生成一个"跳过 1276~1310 帧"的剪辑点。

反过来也成立：你在时间线上手动切了一刀，系统查表反推出对应的文字位置，文本视图里那段文字就会标灰。这就是双向映射——文本视图和时间线视图是同一份数据的两种呈现，改哪边另一边都跟着动。

这里必须点破一个认知误区：文本化剪辑并没有"重新渲染"视频。它只是在生成一份"哪段用、哪段不用"的清单。这份清单在行业里有个老名字，叫 EDL（Edit Decision List，剪辑决策表）。八十年代的线性剪辑机就在用这个概念，只不过那时候是人手工敲进去的。

所以严格说，AI 剪辑并不是新发明了什么，它只是让机器来填这张表。想明白这一点，你对它的能力边界就会有一个非常清醒的预期——它擅长的是"决定用哪一段"，不是"凭空造出一段"。

2.3 底座三：可编辑的真实时间线

第三个底座，也是 ChatCut 区别于大部分"AI 一键成片"工具的关键。

市面上很多 AI 视频工具的输出是不可编辑的：你给它素材和提示词，它吐给你一个 MP4，你觉得第 8 秒那一刀切早了？对不起，重新生成，运气好的话下次能对。

这种设计在专业工作流里是灾难。因为剪辑本质上是一个迭代收敛的过程，没有人能一次说清楚自己要什么。

ChatCut 的做法是：每一次编辑，返回的都是一条真实的、可继续编辑的时间线。你可以接着用自然语言让它调整，也可以直接切到时间线视图，手动把那一刀往后挪三帧。AI 只是一个"助理剪辑"，方向盘还在你手上。

这个设计取舍，在我看来是它能被专业剪辑师接受的最重要原因。辛梓煜@词元2号站 在体验这类工具时有个粗暴的判断标准：看它的输出能不能被改。不能改的，都只是玩具。

flowchart LR
    A[原始素材<br/>视频/音频] --> B[ASR 转录引擎]
    B --> C[带时间码的词表<br/>+ 说话人标签]
    C --> D[文本视图]
    C --> E[时间线视图]
    D <-->|双向映射| E
    D --> F[AI Agent<br/>读文本 / 下指令]
    F --> G[生成 EDL<br/>剪辑决策表]
    G --> E
    E --> H[导出<br/>MP4 / XML / SRT]

2.4 时间码这件小事，坑比你想的多

上面这套映射听起来天衣无缝，但真正做过后期的人都知道，时间码是整个链路里最容易出问题的一环。这里插一段偏硬核的内容，因为它直接决定了你导出的东西能不能用。

先解释术语：时间码（Timecode）是给视频每一帧编的号，标准格式是 时:分:秒:帧，比如 01:23:45:12 表示第 1 小时 23 分 45 秒的第 12 帧。它是所有后期软件对齐素材的唯一坐标系。

问题出在帧率上。

如果你的片子是标准的 25fps 或 30fps，一秒钟正好 25 帧或 30 帧，时间码和真实时间严格对应，一切太平。但现实里有一类恶心的帧率叫 29.97fps（还有 23.976、59.94），它们是从早年彩色电视的技术妥协里留下来的历史遗产，一秒钟并不是整数帧。

这就导致一个诡异的现象：时间码走的时间，和墙上钟表走的时间，会慢慢对不上。 一小时的素材，累积误差能达到三秒多。为了解决这个问题，行业发明了"丢帧时间码"（Drop Frame）——不是真的丢画面，而是在计数的时候周期性跳过几个编号，让时间码追上真实时间。

丢帧时间码的写法用分号分隔：01:23:45;12，非丢帧用冒号：01:23:45:12。一个符号的差别，导入的时候可能就整体错位。

最后一行是重灾区。手机和屏幕录制软件出的视频经常是变帧率（VFR）的——为了省空间，画面不动的时候少存几帧。这种文件丢进任何剪辑系统都会出问题：转录的时间码对得上，但导入 NLE 之后音画就开始慢慢飘。

我的处理办法是上传之前先统一转成定帧率：

# 把变帧率素材转成定帧率的 25fps，音频重采样保证同步
ffmpeg -i input.mp4 -r 25 -vsync cfr -c:v libx264 -crf 20 \
       -c:a aac -ar 48000 output_cfr.mp4

这一步只要三十秒，但能省掉你后面几个小时的对轨噩梦。素材进任何自动化流程之前先规范化，是我这些年最有价值的经验之一。

顺便说一句，这也解释了为什么这类工具会强调"帧级时间码"——不是为了炫技，是因为一旦精度掉到秒级，所有后续的导出和互通都会崩。

三、ChatCut 的产品形态拆解：它做什么，更重要的是它不做什么

3.1 基础能力盘点

把官方文档和实际体验对齐之后，它的能力大致是这么一张表：

术语补充：NLE 是 Non-Linear Editing 的缩写，非线性编辑系统，就是 Premiere、达芬奇、Final Cut 这类软件的统称。B-roll 指的是穿插在主画面之外的辅助镜头，比如你在讲一个产品，画面切到产品特写，那个特写就是 B-roll。

3.2 它明确不做的事

我特别欣赏它在定位上的克制，这几件事它是主动不做的：

不做炫技式的从零生成。它的目标用户是"素材已经拍好了，只想快点出片"的人。你没素材，它帮不上大忙。

不做多轨复杂合成。单轨时间线，就意味着它放弃了画中画、复杂叠层、多机位切换这些场景。这不是能力不足，是刻意划的界。

不做黑箱。前面说过了，每次编辑都返回可编辑的时间线，它宁可少一点"魔法感"，也要保住可控性。

一个产品的价值，往往体现在它拒绝做什么上面。这句话放在 AI 工具泛滥的今天，越来越准。

3.3 典型使用场景

结合它的能力边界，真正适合的场景我总结了四类：

• 长内容抽短：一期五十分钟的对谈，让 Agent 找出最有信息量的一段，切成竖屏短片。
• 口播清理：一条自拍口播，去掉停顿、重复、口头禅，加上字幕，直接发布。
• 粗剪交付：专业剪辑师用它跑一版粗剪，导出 XML 拿回 Premiere 或达芬奇精修。
• 多语言字幕：转录 + 字幕生成 + 导出 SRT，省掉外包听译的环节。

3.4 横向定位：它和身边这些工具是什么关系

很多人的第一反应是"这不就是某某某吗"。我把这几类工具的定位摆在一起对比，你会看得更清楚。

和传统 NLE（Premiere、达芬奇、Final Cut）的关系：不是替代，是前置。传统 NLE 是"全能但重"，它能干的事情多一个数量级，但你为了剪掉一句废话得先学会三个面板。ChatCut 是"专一但轻"，它只处理粗剪这一段，然后把结果交出去。两者的正确关系是接力，不是竞争。

和 Premiere 自带的"基于文本的编辑"的关系：思路一样，形态不同。Premiere 的文本编辑是软件里的一个面板，你还是得在 Premiere 里操作；ChatCut 是独立的、可被 Agent 调用的服务。前者是功能，后者是接口。这个差别听起来抽象，但它决定了自动化的天花板——你没法让一个 AI Agent 去点 Premiere 的按钮，但你可以让它调用一个 MCP 接口。

和"一键成片"类工具的关系：这是最大的分野。一键成片类工具的产出是不可编辑的结果，它把你的可控性换成了便捷性。ChatCut 明确拒绝了这个交易，它的每一次输出都还给你一条能改的时间线。

我把这个对比整理成一张表：

看完这张表，你应该能判断出它在你的工作流里该放在哪个位置了。

一个提醒：如果你的内容是纯剪辑驱动的（比如卡点混剪、纯画面叙事），这类工具对你帮助有限，因为你的信息不在音轨上。工具的适用性永远取决于素材的性质，这个前提别忘了。

四、把剪辑器接进 Agent：MCP 到底是怎么一回事

到这里，产品层面的东西讲完了。接下来是这篇文章真正的干货部分——它是怎么被 AI Agent 调用的。

4.1 白话解释 MCP

MCP 全称 Model Context Protocol，模型上下文协议。这是个开放标准，你可以把它理解成"AI 世界的 USB-C 接口"。

在没有 MCP 之前，每个 AI 应用想接一个外部工具，都得单独写一遍对接代码。接 Slack 写一套，接 Figma 写一套，接你家的剪辑软件再写一套。工具方也一样，想被十个 AI 客户端调用，就得适配十次。这是典型的 N×M 复杂度问题。

MCP 干的事情，就是在中间插一层标准协议：工具方按协议实现一次 Server，任何支持协议的 AI 客户端都能直接连上。

它的角色划分是这样的：

ChatCut 的 MCP 端点地址是公开的：

https://api.chatcut.io/api/external-mcp/mcp

注意这是一个 HTTP 远程端点，不是跑在你本机的进程。这意味着你不需要在本地部署任何服务，插件里那份 .mcp.json 只是告诉 Codex"去这个地址找它"。

4.2 远程 MCP 的授权是怎么做的

一提到"云端服务 + 第三方客户端"，安全问题就绕不过去了。凭什么 Codex 可以代表你去操作你的 ChatCut 项目？

答案是 OAuth 2.1。MCP 规范里明确规定，基于 HTTP 传输的服务端应当作为 OAuth 2.1 的资源服务器，客户端作为 OAuth 2.1 客户端，通过授权服务器颁发的访问令牌来完成鉴权。

这套机制的好处，用一句话概括就是：插件全程碰不到你的密码，也碰不到长期密钥。

流程大致是这样：

sequenceDiagram
    participant U as 你
    participant C as Codex（MCP 客户端）
    participant S as ChatCut MCP Server
    participant A as 授权服务器

    C->>S: 首次请求（无令牌）
    S-->>C: 401 未授权 + 授权服务器地址
    C->>A: 发起授权请求（带 PKCE）
    A-->>U: 弹出登录界面
    U->>A: 完成登录并同意授权
    A-->>C: 返回授权码
    C->>A: 用授权码换取访问令牌
    A-->>C: 颁发访问令牌
    C->>S: 携带令牌重新请求
    S-->>C: 校验通过，返回工具列表

几个值得注意的设计点：

第一，401 响应里带线索。 服务端在拒绝时会通过 WWW-Authenticate 响应头告诉客户端"去哪里找授权服务器"，客户端不需要硬编码任何地址。

第二，PKCE 是强制的。 PKCE（读作 "pixie"）是防止授权码被中途劫持的机制。OAuth 2.1 相比 2.0 的一个重要收紧，就是要求所有流程都用 PKCE，不再区分公开客户端和机密客户端。这对桌面端 AI 应用尤其重要，因为它们运行在用户本机，威胁模型和服务器上跑的 Web 应用完全不同。

第三，令牌不能放在 URL 里。 每一次 HTTP 请求都必须在请求头里带令牌，哪怕是同一个逻辑会话内的连续请求。

对普通用户来说，这一整套东西的体感就是：装插件的时候弹一个登录页，点一下"同意"，完事。 但底下这套设计，决定了你的账号安全边界在哪里——它是我认为这个插件做得最扎实的一块。

五、Codex 插件的工程结构：三个文件撑起一个生态

5.1 先搞清楚 Codex Plugin 是什么

它不是浏览器插件，也不是 IDE 扩展。 Codex 的插件系统更接近一个"AI 工作流的包管理器"——把 Skills（技能）、MCP Servers（工具连接）、Apps（应用集成）三类配置打包成一个可安装、可版本化、可分发的单元。

类比一下：如果说 npm 包分发的是代码，那 Codex Plugin 分发的是能力。

它的标准目录结构长这样：

my-plugin/
├── .codex-plugin/
│   └── plugin.json      # 必需：插件清单，唯一的入口文件
├── skills/              # 可选：技能目录
│   └── my-skill/
│       └── SKILL.md
├── .mcp.json            # 可选：MCP 服务器配置
├── .app.json            # 可选：应用集成配置
└── assets/              # 可选：图标、品牌素材
    ├── icon.png
    └── logo.png

官方规则很明确：只有 .codex-plugin/plugin.json 是必需的，其余按需添加。

5.2 对照 ChatCut 插件的实际结构

打开 ChatCut-Inc/agent-plugin 这个仓库，你会发现它老老实实就是按这套规范来的：

agent-plugin/
├── .agents/plugins/
├── chatcut/
│   ├── .codex-plugin/
│   │   └── plugin.json      # 插件元数据
│   ├── .mcp.json            # 指向托管的 MCP 端点
│   ├── skills/              # 一组剪辑工作流
│   └── assets/              # 图标与品牌资源
└── README.md

整个仓库没有一行业务逻辑代码。 所有真正的剪辑能力都在云端的 MCP Server 上，插件本身只是一份"配置 + 说明书"。

这个设计取舍非常关键，我把它总结成一句话：插件是薄的，能力是厚的，中间靠协议连接。

好处显而易见：

• 服务端升级能力，用户不用更新插件；
• 插件仓库可以开源，因为里面没有任何核心资产；
• 任何支持 MCP 的 Agent 都能复用同一套服务端，不用为每个客户端重写一遍。

5.3 清单文件写了什么

plugin.json 的结构大致是这个样子（下面是按官方规范整理的示意，不是原文件的逐字复制）：

{
  "name": "chatcut",
  "version": "0.1.0",
  "description": "在 Codex 里直接编辑 ChatCut 视频项目",
  "skills": "./skills/",
  "mcpServers": "./.mcp.json",
  "interface": {
    "displayName": "ChatCut",
    "category": "media",
    "brandColor": "#000000"
  }
}

字段分三类：

而 .mcp.json 更简单，核心就是把远程端点填进去：

{
  "mcpServers": {
    "chatcut": {
      "type": "http",
      "url": "https://api.chatcut.io/api/external-mcp/mcp"
    }
  }
}

就这么几行，Codex 就知道该去哪里拿工具了。

5.4 安装机制：marketplace 不是应用商店

这里有个普遍的误解需要澄清。Codex 的 marketplace 不是一个中心化的应用商店，而是一套基于 Git 仓库的分发机制。

你用命令行把某个 Git 仓库注册成一个 marketplace 源，Codex 就会去这个仓库里扫描插件清单，然后把插件源码拉到本地缓存目录（通常在 ~/.codex/plugins/ 下面），并把启用状态写进配置文件。

所以"安装 ChatCut 插件"这个动作，本质上是：

注册仓库为插件源 → 拉取插件目录 → 写入本地配置 → 首次调用时触发 OAuth 授权

理解了这一点，你就明白为什么装插件的前置依赖里会有 Git——因为它压根就是用 Git 在分发。也就明白了为什么有些人在 Windows 上装不上：不是插件的问题，是终端里的 PATH 里找不到 Git。

5.5 什么时候该用本地 skill，什么时候该打包成插件

这是个很实际的工程决策问题，顺便讲清楚。

如果你只是想让 Agent 在自己的项目里按某个流程干活，其实根本不需要做插件。直接在项目里建一个技能目录，把 SKILL.md 放进去，Agent 会自动发现它：

my-repo/
└── .agents/
    └── skills/
        └── my-workflow/
            └── SKILL.md

不用注册，不用清单文件，改完立刻生效。适合个人工作流、实验性流程、还没定型的原型。

什么时候该升级成插件？ 三个信号：

ChatCut 三条全中，所以它做成了插件。而且它必须做成插件——因为它的 skills 是依赖 MCP 服务端能力的，光给 skills 没有工具连接，Agent 读完文档也无从执行。这两样东西必须捆在一起交付，这正是插件这个封装单元存在的理由。

反过来说，如果你只是想让 Agent 按你团队的规范写提交信息，那写个本地 skill 就够了，别过度工程。

5.6 一个容易被忽略的细节：插件是"信任边界"

装一个插件，等于给 Agent 开了一扇通往外部服务的门。这里有几件事值得多想一层：

你授权的是什么范围？ OAuth 的授权页面上通常会列出申请的权限。剪辑类插件申请"读写你的项目"是合理的，但如果它申请了和功能明显无关的权限，那就该警惕。养成看授权页的习惯，别一路点同意。

插件里的 skills 是会被 Agent 当作指令读取的。 这意味着，如果你安装了一个来源不明的插件，它 SKILL.md 里写的任何内容，都可能影响 Agent 的行为。这是一个真实存在的攻击面。只装官方仓库或你信得过的来源的插件，这条建议不夸张。

远程 MCP 服务端能看到什么？ 你调用工具时传过去的参数、上传的文件，服务端全都能看到。这不是漏洞，是设计使然，但你得心里有数。

辛梓煜@词元2号站 的原则很简单：能力越大的插件，来源审得越严。 一个只会格式化 JSON 的插件，你随便装；一个能读你本地文件、上传到云端的插件，你得知道它是谁做的。

六、Skills 工作流：把剪辑知识封装成可复用的能力

6.1 为什么需要 Skills 这一层

假设没有 Skills 层，只有一个 MCP Server 暴露了三十个原子工具（导入媒体、切分片段、插入转场、生成字幕……）。会发生什么？

Agent 每次都得从零推理："用户说要把这段访谈剪成三分钟精华版，我应该先转录还是先导入？转录完之后我要怎么判断哪段是精华？切完之后要不要重新对字幕？"

这个推理过程既慢又不稳定。同样一个需求，今天推理出的步骤和明天可能不一样，结果自然也不一样。

Skills 解决的就是这个问题。它把领域知识固化成了标准流程，Agent 不需要自己发明方法论，直接照着做就行。

这本质上是把"剪辑师的经验"写成了文档。

6.2 Skills 的组织形式

一个 skill 就是一个目录，里面放一份 SKILL.md。这份 Markdown 文件的开头是一段 YAML 元数据，描述这个技能是干什么的、什么时候该被触发；下面的正文是具体的操作步骤。

结构大概是这样：

---
name: add-captions
description: 为项目中的视频生成并添加同步字幕。当用户提到"加字幕"
             "字幕""caption""subtitle"等意图时触发。
---

# 添加字幕工作流

## 前置检查
- 确认目标媒体已完成转录，若未转录，先调用转录工具
- 确认项目时间线已存在

## 执行步骤
1. 读取转录结果，获取带时间码的词表
2. 按标点与停顿切分字幕行，单行不超过设定字数
3. 调用字幕生成工具，写入时间线
4. 回读时间线，校验字幕时间码与语音是否对齐

## 完成标准
- 时间线上存在字幕轨
- 抽样检查三处，字幕出入点与语音误差在两帧以内

这里有个很妙的设计叫"渐进式披露"：Agent 一开始并不会把所有 skill 的正文都读进上下文，它只看 description 那一行。等判断出"这次任务需要加字幕"，才去把对应的 SKILL.md 正文读进来。这样既省上下文，又保证需要的时候细节完整。

这个思路我觉得对任何做 Agent 工程的人都有借鉴意义——不要一次性把所有知识塞给模型，让它按需检索。

6.3 ChatCut 封装了哪些工作流

按官方说明，插件覆盖的工作流大致可以归成七类：

6.4 最有意思的一环：验证机制

这是我认为整个插件设计里最值得偷师的部分。

大部分 Agent 工具的调用是"发出去就不管了"——调了工具，返回一个成功状态码，然后就当作做完了。但实际情况是，接口返回 200 不代表用户看到的结果是对的。

ChatCut 的 skills 里明确包含了回读验证的环节：Agent 执行完改动之后，会反过来去查询编辑器的当前状态，确认这些改动真的生效了——时间线上的剪辑点在不在该在的位置、字幕有没有和语音对齐、音频轨是不是正常。

用伪代码表示，这个模式是：

def execute_edit(instruction):
    # 1. 执行操作
    result = mcp_call("modify_timeline", instruction)

    # 2. 回读当前状态（关键的一步）
    state = mcp_call("get_timeline_state")

    # 3. 断言预期
    if not verify(state, expected=instruction.expectation):
        # 4. 不符合预期就修正，而不是直接返回成功
        return repair(state, instruction)

    return result

"执行—回读—断言—修正" 这个闭环，是让 Agent 从"能调用工具"进化到"能真正干成活"的分水岭。少了它，Agent 就是个只会发指令、不看结果的甩手掌柜。

七、上手实操：两条路径怎么走

7.1 路径一：直接用网页版

这是最轻的路子，不需要装任何东西，浏览器打开就能用。

流程是：

1. 访问 chatcut.io 官网，注册