针对：从用户的操作录屏中提取关键帧 → 交给 AI 识别 · 评估所提议的 PySceneDetect 方案 · 2026-05-23
OpenAI 的模型不能直接读视频，只能读图片。所以「先把视频拆成几张关键帧图片，再发给 AI」这个大方向是正确的 —— 业界（包括 OpenAI 官方示例）都是这么做的。
真正的难点只有一个：到底该从录屏里挑哪几张图？ 您提议用 PySceneDetect 来挑。问题恰恰出在这里。
PySceneDetect 的判断方式是：把整张画面前后两帧做对比，算出「整屏平均变化了多少」，超过一个阈值（默认 27）才算「发生了一次变化」。
但在教程里，关键操作——点一个按钮、开一个开关、打个勾、输入一个字——只占屏幕极小的一块（通常不到 1%）。摊到整屏平均一算，变化几乎等于 0：
| 操作 | 占屏幕比例 | 实测变化值 | vs 阈值 27 |
|---|---|---|---|
| 打开一个开关 | 约 0.35% | ≈ 0.5 | 差约 54 倍 |
| 出现一个对勾 ✓ | 约 0.11% | ≈ 0.17 | 差约 160 倍 |
| 按钮点击高亮 | 约 1.7% | ≈ 2.6 | 差约 10 倍 |
| 输入一个文字 | 约 0.03% | ≈ 0.04 | 差约 600 倍 |
要让它「触发」，画面得有 约 18% 的面积同时改变才行。所以这些关键步骤会被直接漏掉、完全检测不到。
有人会想：那把阈值调低一点不就行了？不行。因为屏幕上一直有各种「噪音」在变化：
光标在闪、状态栏的时钟在跳、视频压缩本身的噪点、手指点击的水波纹……这些「无意义的变化」和真正的操作变化一样大（甚至更大）。
结果就是：阈值调到能抓住「打勾」，就会被光标闪烁、时钟跳动触发到几乎每一帧都报「有变化」，等于没筛选；而滚动页面、切换页面、App 里自动播放的视频又会产生一大堆假的「变化点」。两头都不讨好。
这是最关键的一点。「场景切换检测」天生是用来找「画面正在剧烈变化的瞬间」的（电影转场用）。
但教程需要的，恰恰相反 —— 是操作做完、画面稳定下来的那一屏（也就是用户真正会去截图的那一屏）。
菜单滑动到一半
动画没播完、画面还糊着
过渡中的残缺画面
菜单已经完全弹出
开关已经稳定停在「开」
清晰、完整的最终画面
所以哪怕参数调到完美，它挑出来的也是「错误的那一帧」 —— 这是原理上的方向相反，不是调参能解决的。
| 检测方式 | 它擅长找什么 | 能识别 UI 细微操作吗？ |
|---|---|---|
| 内容检测（默认/阈值法） | 整屏大幅变化、转场 | 不能（差 1~2 个数量级） |
| 自适应检测 | 过滤镜头移动 | 不能（有 15 的硬下限，直接卡死） |
| 亮度阈值检测 | 渐黑 / 渐亮 | 无关（开关不改变整屏亮度） |
| 感知哈希检测 | 整体画面相似度 | 更差（设计上就忽略小细节） |
| 直方图检测 | 整体色彩分布 | 不能（小区域几乎不影响分布） |
这个库里的每一种检测器，原理都是「看整屏的统计变化」，所以对「小区域的关键操作」全都不敏感。
✅ 「拆成关键帧发给 AI」的大方向没错。
❌ 但用您发的这个库（PySceneDetect 的阈值 / 场景检测）来挑帧，无法可靠识别出 UI 教程里的关键操作步骤 —— 它会漏掉真正重要的步骤，同时又挑出一堆没用的画面。这是方法原理决定的，不是 bug、也不是调参问题。
那能不能做？ 能，但要换一套完全不同的思路：不是去找「画面在变的那一刻」，而是去找「画面稳定下来的那一刻」（再加上去重、文字变化检测等）。这套方案在技术上可行，但同时还要解决处理成本（一段视频要发好多张图给 AI，费用会成倍增加）和架构改造（视频处理慢，不能让用户在聊天里干等，要改成后台异步处理 + 处理完再推送）。所以它是一个需要专门立项的工程，不是「接上这个库就能用」的小功能。
本说明为技术评估的简要版（面向客户沟通）。完整技术报告（含逐项代码定位、成本测算与集成方案）见 docs/video-support-keyframe-extraction-feasibility.html。日期：2026-05-23。