基于MCP的macOS录屏智能剪辑：Swift实现与ScreenCaptureKit实践

1. 从一个真实痛点说起：为什么录屏演示的后期剪辑这么折磨人

做技术分享、产品演示或者教学视频的人，大概都有过这种体验：一段十分钟的录屏，真正能用的可能只有三四分钟。中间夹杂着输错命令重来的片段、等待编译的空白时间、鼠标乱晃找不到按钮的尴尬瞬间，还有那些"呃……这个我再试一次"的口误。把这些废料剪掉，听起来是个简单的活儿，但实际操作起来，剪辑软件的时间线操作、逐帧对齐、音频波形匹配，一套流程下来，花在剪辑上的时间往往比录制本身还长。

我自己做开发教程视频有几年了，最开始用的是传统非线性剪辑软件，拖时间线、切刀、删片段，一个二十分钟的视频能剪掉我两个小时的晚上。后来我就在想，录屏这个东西有个特点——它的内容结构其实高度可预测。演示类录屏无非就是"打开某个界面→执行某个操作→展示某个结果"这样的循环，而操作之间的停顿、失误、重复，在时间轴上是有明显特征的。既然结构可预测，那能不能让机器来帮我做粗剪？

这就是我折腾Screen Records这个项目的出发点。它是一个跑在 macOS 上的录屏工具，核心卖点不是录制本身——macOS 自带的录屏、QuickTime、OBS 都能录——而是它把录制和"基于 MCP 的智能编辑"绑在了一起。MCP 在这里指的是 Model Context Protocol，一种让 AI 模型能够调用外部工具、访问外部上下文的标准协议。简单说，Screen Records 录完屏之后，不是丢给你一个巨大的视频文件让你自己剪，而是把录制过程中的元数据（时间戳、操作事件、窗口切换等）整理成结构化的上下文，通过 MCP 暴露给 AI 助手，让 AI 来帮你决定"哪段该留、哪段该删、哪里该加速"。

关键词里出现了 Mac、macOS、Swift，说明这个项目是原生 macOS 应用，用 Swift 写的。这一点很关键，因为录屏涉及系统级的屏幕捕获 API、窗口管理、性能优化，用 Swift 调 macOS 的原生框架（比如 ScreenCaptureKit、AVFoundation）能拿到最好的性能和最细的控制粒度。如果你是个 macOS 开发者，或者经常需要产出演示视频的技术人，这个项目的思路值得仔细拆一拆。

这篇文章我会从几个层面展开：先讲清楚录屏编辑这件事的本质难点在哪，再拆解 MCP 在这个场景里到底扮演什么角色、为什么选它而不是别的方案，然后给出一个可复现的实现思路和关键代码结构，最后分享我在实际折腾过程中踩过的坑和总结出来的经验。不管你是想自己做一个类似工具，还是只想理解 MCP 这类协议怎么落地到具体产品里，应该都能拿到点东西。

2. 录屏编辑的本质难点：不是剪辑技术，是"意图识别"

2.1 传统剪辑流程为什么在录屏场景下低效

要理解 Screen Records 的价值，得先搞清楚传统剪辑在录屏场景下到底卡在哪。我用一个具体的例子来说明。假设你录一段"如何在 macOS 上配置某个开发环境"的教程，录制过程大概是这样：

1. 打开终端，敲第一条命令，回车，等待执行
2. 发现命令敲错了，Ctrl+C 中断，重新敲
3. 命令执行成功，输出一堆日志，你等它跑完
4. 打开编辑器改配置文件，中间找文件找了半天
5. 保存，回到终端验证，成功
6. 打开浏览器查了个文档，又切回来

这段录制里，第2步是纯废料，第3步的等待时间需要加速，第4步的"找文件"过程需要大幅压缩或者直接剪掉，第6步的浏览器切换如果和主题无关也该删。一个熟练的剪辑师能凭经验判断这些，但判断的依据是什么？是"这段画面里有没有有效信息"。

传统剪辑软件给你的工具是时间线、切刀、速度曲线，它不知道画面里发生了什么，它只认时间。所以你必须自己盯着画面，一段一段判断，手动下刀。这就是低效的根源——工具只提供了操作能力，没有提供判断能力。

2.2 录屏内容的可结构化特征

但录屏和拍电影不一样。电影的画面是连续的、语义模糊的，而录屏的画面本质上是"屏幕状态的离散变化"。你的鼠标点击、键盘输入、窗口切换，这些都是有明确事件边界的。macOS 的系统 API 能让你捕获到这些事件：什么时候发生了鼠标点击、点击在哪个坐标、哪个窗口获得了焦点、什么时候有键盘输入。

这意味着录屏内容可以被结构化描述。一段录屏可以拆解成事件序列：

有了这张表，剪辑决策就从"看画面凭感觉"变成了"对事件序列做规则判断"。而规则判断这件事，恰好是 AI 擅长的。这就是 MCP 介入的切入点。

2.3 为什么"意图识别"是核心难点

不过这里有个陷阱。事件序列能告诉你"发生了什么"，但不能直接告诉你"该不该删"。同样是等待 15 秒，如果是命令在执行，加速就好；如果是程序卡死了，那这段可能整个要删掉重录。同样是窗口切换，切到文档查资料可能是必要的上下文，切到聊天软件就是纯干扰。

判断"该不该删"需要理解意图——这段录屏想表达什么，观众需要看到什么。而意图这个东西，光靠事件序列是推不出来的，它需要结合录屏的标题、描述、甚至录制者的口述。这就是为什么单纯写个规则引擎做自动剪辑效果很差，因为规则覆盖不了意图的多样性。

MCP 的价值就在这里：它让 AI 模型能够同时访问"事件序列"（结构化上下文）和"录屏意图"（自然语言描述），然后综合判断。你可以告诉 AI"这是一段教人配置 Python 环境的教程，重点是把命令敲对和看到成功输出"，AI 就能据此决定哪些片段是核心、哪些是噪音。这比写死规则灵活得多，也比纯人工剪辑快得多。

3. MCP 在录屏编辑里到底干了什么：协议层的角色拆解

3.1 MCP 是什么，为什么不是简单的 API 调用

先给不熟悉的朋友补个课。MCP（Model Context Protocol）本质上是一套标准化的"AI 模型与外部工具/数据源通信"的协议。你可以把它理解成 AI 世界的 USB 接口——以前每个 AI 应用要接一个外部工具，都得自己写一套对接代码，工具 A 的接口和工具 B 的接口完全不兼容。MCP 定义了一套统一的描述方式，让工具能声明"我能做什么、需要什么参数"，AI 模型能按这套标准去调用。

那为什么不直接在应用里调 OpenAI 或者别的模型的 API 呢？区别在于解耦和可组合。如果 Screen Records 直接把剪辑逻辑和某个特定模型的 API 绑死，那模型一升级、接口一变动，整个应用就得改。而通过 MCP，Screen Records 只需要暴露几个标准的"工具"（比如"获取录屏事件序列""应用剪辑决策""导出视频"），至于背后是哪个 AI 模型来调用这些工具、怎么调用，应用本身不关心。

这个设计对录屏编辑场景特别合适，因为剪辑决策这件事，不同用户可能有不同的偏好。有人喜欢激进剪辑，把所有停顿都删掉；有人喜欢保留一点节奏感。通过 MCP，这些偏好可以作为上下文传给 AI，而不需要改应用代码。

3.2 Screen Records 暴露的三个核心 MCP 工具

基于我对这类工具的理解，一个录屏编辑应用通过 MCP 暴露的工具大概会是这样几个（这是基于常见实践的合理设计，不是照搬某个具体实现）：

工具一：get_recording_events

输入是录屏文件的标识，输出是结构化的事件序列。这个工具背后要做的事情是把录制时采集的原始事件数据（鼠标、键盘、窗口焦点变化）整理成带时间戳的 JSON。关键设计点是时间戳的精度和事件的粒度——太粗了 AI 判断不准，太细了上下文爆炸。

{ "recording_id": "demo-001", "duration_ms": 720000, "events": [ {"t": 0, "type": "window_focus", "app": "Terminal"}, {"t": 15000, "type": "key_input", "text": "pip install requests"}, {"t": 22000, "type": "key_input", "text": "pip install requsts", "note": "typo"}, {"t": 25000, "type": "key_input", "text": "backspace x7"}, {"t": 40000, "type": "idle", "duration_ms": 15000} ] }

工具二：propose_edit_plan

这个工具接收事件序列和用户的意图描述，返回一个剪辑方案。剪辑方案不是直接操作视频，而是一组"编辑指令"——保留哪些区间、删除哪些区间、哪些区间加速多少倍。这样设计的好处是编辑方案可以被审查、被修改，而不是 AI 一锤定音。

工具三：apply_edit_plan

把剪辑方案真正应用到视频文件上，输出成品。这一步是纯工程活，用 AVFoundation 做时间线重组和导出。

这三个工具的分工很清晰：第一个负责"看懂录屏"，第二个负责"做决策"，第三个负责"执行"。MCP 在这里的作用是让第二个工具背后的决策逻辑可以由外部 AI 提供，而不是硬编码在应用里。

3.3 为什么决策和执行要分开

这里有个设计上的关键取舍值得说。很多自动剪辑工具是"一步到位"的——你给它视频，它直接吐成品。但 Screen Records 这种把决策和执行分开的设计，在实际使用中体验好很多。

原因很简单：AI 的决策不可能 100% 准确。如果它直接执行了，你发现某段不该删，就得重新来一遍。而如果它先给你一个编辑方案，你可以在方案上微调——"这段别删""这个加速改成 2x"——然后再执行。这就像 Git 的暂存区，AI 帮你把改动都准备好了，但最终提交前你还能 review。

从工程角度看，这种分离也让系统更容易调试。当剪辑结果不对时，你能快速定位是"事件采集错了"还是"决策逻辑错了"还是"执行环节错了"，而不是面对一个黑盒。

4. 用 Swift 在 macOS 上落地：从屏幕捕获到 MCP 服务

4.1 屏幕捕获：为什么选 ScreenCaptureKit

macOS 上做屏幕录制，历史上经历过几代 API。最早是 CGDisplayStream，后来有 AVCaptureScreenInput，现在苹果主推的是 ScreenCaptureKit（macOS 12.3 引入）。Screen Records 用 Swift 写，选 ScreenCaptureKit 是顺理成章的，但具体理由值得说清楚。

ScreenCaptureKit 相比老 API 的优势在于：它能以更细的粒度控制捕获内容（可以指定捕获某个窗口而不是整个屏幕），性能更好（底层用了更现代的图形管线），而且能同时拿到视频流和音频流。对于录屏编辑场景，"捕获特定窗口"这个能力特别重要——因为窗口切换事件本身就是剪辑决策的重要依据，如果你录的是全屏，窗口切换只能靠画面识别，而如果按窗口捕获，切换事件是天然带上的。

一个简化的捕获配置大概长这样：

import ScreenCaptureKit let content = try await SCShareableContent.excludingDesktopWindows(false, onScreenWindowsOnly: true) guard let display = content.displays.first else { return } let config = SCStreamConfiguration() config.width = Int(display.width) * 2 // Retina 2x config.height = Int(display.height) * 2 config.minimumFrameInterval = CMTime(value: 1, timescale: 30) // 30fps config.capturesAudio = true let filter = SCContentFilter(display: display, excludingWindows: []) let stream = SCStream(filter: filter, configuration: config, delegate: self) try stream.addStreamOutput(self, type: .screen, sampleHandlerQueue: .global()) try await stream.startCapture()

这里有个细节：minimumFrameInterval设成 30fps 而不是 60fps。录屏演示不需要 60fps，30fps 足够流畅，而且文件体积小一半，后期处理也快。这是我在实际录制中总结的经验——除非你录的是游戏或者高动态内容，否则 30fps 是性价比最高的选择。

4.2 事件采集：把"操作"变成"数据"

光录画面不够，Screen Records 的核心竞争力在于它同时采集操作事件。macOS 上采集全局输入事件需要用 CGEventTap，这是个底层 API，能监听键盘和鼠标事件。但要注意，从 macOS 10.15 开始，监听全局输入需要用户授权"辅助功能"权限，这个授权流程必须在应用里处理好，否则用户会一脸懵地发现录了半天啥事件都没采到。

事件采集的关键是降噪。原始事件流非常密集——鼠标移动每秒能产生几十个事件，如果全存下来，上下文会爆炸。我的做法是只保留有语义的事件：

• 鼠标点击（区分左右键、单击双击）
• 键盘输入（聚合成"输入了什么文本"，而不是逐键记录）
• 窗口焦点变化
• 明显的空闲区间（超过 2 秒无输入）

鼠标移动轨迹只在"拖拽"场景下保留，普通移动直接丢弃。这样处理后，一段十分钟的录屏，事件序列通常只有几百条，完全在 AI 上下文的承受范围内。

4.3 MCP 服务的实现骨架

MCP 服务在 Swift 里实现，核心是起一个本地服务，按 MCP 协议响应请求。MCP 基于 JSON-RPC，所以本质上就是处理 JSON 消息。一个最小的工具注册大概是这样：

struct GetRecordingEventsTool: MCPTool { let name = "get_recording_events" let description = "获取指定录屏的结构化事件序列" let inputSchema: [String: Any] = [ "type": "object", "properties": [ "recording_id": ["type": "string", "description": "录屏文件标识"] ], "required": ["recording_id"] ] func execute(params: [String: Any]) async throws -> [String: Any] { guard let id = params["recording_id"] as? String else { throw MCPError.invalidParams } let events = try await EventStore.shared.loadEvents(for: id) return ["events": events.map { $0.toJSON() }] } }

这里有个工程上的坑：MCP 服务是本地进程，而录屏应用可能是 GUI 应用，两者之间的通信要处理好生命周期。我的做法是把 MCP 服务做成应用内的一个组件，用本地 socket 或者直接进程内调用，避免跨进程通信带来的复杂性和延迟。

4.4 剪辑执行：AVFoundation 的时间线重组

拿到编辑方案后，真正剪视频用 AVFoundation 的 AVMutableComposition。核心逻辑是把原视频按编辑方案切成若干段，删除的段跳过，加速的段用 scaleTimeRange 处理，然后拼起来导出。

let composition = AVMutableComposition() let asset = AVAsset(url: sourceURL) guard let sourceTrack = asset.tracks(withMediaType: .video).first, let compTrack = composition.addMutableTrack(withMediaType: .video, preferredTrackID: kCMPersistentTrackID_Invalid) else { return } var cursor = CMTime.zero for segment in editPlan.segments { let range = CMTimeRange(start: segment.start, duration: segment.duration) try compTrack.insertTimeRange(range, of: sourceTrack, at: cursor) if segment.speed != 1.0 { let insertedRange = CMTimeRange(start: cursor, duration: segment.duration) compTrack.scaleTimeRange(insertedRange, toDuration: CMTimeMultiplyByFloat64(segment.duration, multiplier: 1.0 / segment.speed)) cursor = cursor + CMTimeMultiplyByFloat64(segment.duration, multiplier: 1.0 / segment.speed) } else { cursor = cursor + segment.duration } }

这段代码有个容易忽略的点：加速之后，后续片段的时间戳要相应前移，否则会出现黑帧或者音画不同步。我第一版就是忘了更新 cursor，结果加速段之后的所有内容都错位了，排查了半天才发现是时间计算的问题。

5. 实测中踩过的坑和几条硬核经验

5.1 权限问题：辅助功能授权不是一次性的

macOS 的隐私保护越来越严，辅助功能权限（用于监听输入事件）和屏幕录制权限（用于捕获画面）都需要用户手动授权。坑在于：这两个权限的授权状态在应用更新后可能会重置，尤其是当你改了应用的签名或者 bundle ID 时。我遇到过好几次"昨天还好好的，今天录出来全是黑屏"的情况，最后发现是权限被系统回收了。

应对办法是在应用启动时主动检查权限状态，如果缺失就引导用户去系统设置里开。检查屏幕录制权限可以用CGPreflightScreenCaptureAccess()，辅助功能权限用AXIsProcessTrusted()。别等到用户点了录制才发现没权限，那时候体验就很差了。

5.2 事件时间戳和视频时间戳对不齐

这是最隐蔽的坑。视频帧的时间戳来自 ScreenCaptureKit 的采样时钟，而输入事件的时间戳来自 CGEventTap 的系统时钟，两者虽然都是基于 mach absolute time，但在实际运行中会有几十毫秒的漂移。如果直接拿事件时间戳去切视频，剪辑点会偏。

我的解决方案是在录制开始时记录一个基准时间戳，之后所有事件时间戳都转换成相对于基准的偏移量，同时视频帧也做同样的转换。这样两者就在同一个时间坐标系里了。实测下来对齐精度能控制在 1 帧以内，肉眼看不出来。

5.3 别让 AI 直接决定"删不删"，给它"打分"更好

一开始我设计的 MCP 工具是让 AI 直接输出"保留/删除"的二元决策，结果发现效果不稳定——同样的片段，AI 有时候说删有时候说留，边界很模糊。后来改成让 AI 给每个片段打一个"重要度分数"（0-100），然后应用侧根据分数阈值来决定。这样不仅更稳定，而且用户还能调整阈值来改变剪辑的激进程度。

这个改动看起来小，但体验提升很大。因为"打分"比"决策"更符合 AI 的能力特点——AI 擅长做相对判断（这段比那段重要），不擅长做绝对判断（这段到底该不该留）。

5.4 长录屏要分段处理，别一次性喂给 AI

MCP 的上下文是有长度限制的。一段一小时的录屏，事件序列可能有几千条，一次性塞给 AI 会超限，而且 AI 对超长上下文的注意力也会下降。我的做法是按"操作单元"分段——把连续的相关操作聚成一个单元（比如"配置环境"是一个单元，"运行测试"是另一个单元），每个单元单独处理，最后合并编辑方案。

分段还有个额外好处：可以并行处理，速度更快。一段一小时的录屏，分成十个单元并行处理，总耗时可能只有串行的三分之一。

5.5 导出格式和编码的选择

最后一步导出，格式选择也有讲究。如果成品是给网页或者社交平台用的，H.264 编码的 MP4 兼容性最好。如果是本地存档或者后续还要再编辑，用 ProRes 保留更多细节。Screen Records 默认导出 H.264，但保留了切换编码的选项。

编码参数上，我建议码率不要设太高。录屏内容和实拍视频不一样，它大部分画面是静态的（文字、界面），H.264 对静态画面的压缩效率极高，8-10 Mbps 就能有很好的画质。设太高只会让文件变大，画质提升肉眼几乎看不出来。

6. 这套思路还能怎么扩展

把 MCP 引入录屏编辑，本质上解决的是"让 AI 理解录屏内容并辅助决策"这个问题。这个思路其实可以往外延伸不少。

比如自动生成字幕和章节。既然事件序列里已经知道"什么时候打开了什么窗口、执行了什么操作"，那 AI 完全可以据此生成章节标题——"00:00 环境准备""02:30 安装依赖""05:15 验证配置"。这比让 AI 纯看画面猜要准得多。

再比如自动生成配套文档。录屏里敲的命令、改的配置，事件序列里都有记录，AI 可以据此生成一份文字版的步骤说明，和视频配套发布。对于做教程的人来说，这个能省掉大量重复劳动。

还有一个方向是"录制时实时建议"。现在的流程是录完再剪，但如果事件采集是实时的，AI 可以在录制过程中就提示"这段可能重复了""这里停顿有点长"，让录制者当场调整。不过这需要更低的延迟和更强的实时推理能力，目前还不太成熟，但值得关注。

我自己用这套流程做教程视频，粗剪环节的时间大概从原来的两小时压缩到了二十分钟左右——AI 出方案，我 review 微调，然后导出。省下来的时间可以花在内容打磨上，这才是真正有价值的地方。工具的意义从来不是替代人，而是把人从重复劳动里解放出来，去做那些真正需要判断力和创造力的事。