浏览器内分析录屏，推断手机点击位置

手机录屏能看到页面跳转，却看不到手指点了哪里。Shotcat 的作者尝试从画面变化反推触控：浏览器先用像素计算找到操作发生的时间、区分点击和滑动，再把需要判断的点击交给视觉模型定位。

这套方案值得看的是任务拆分。完整视频留在本机，模型每次只看前后两张小图。不过，它恢复的是有画面证据的操作，无法还原完整的触摸记录。

先找页面何时响应，再判断发生了什么

作者用 mediabunny 配合 WebCodecs，在浏览器里把视频解码成每秒 12 帧、宽 72 px 的灰度图。第一轮只比较相邻帧，筛出画面变化的时段。

下面的函数计算指定纵向区域内，变化像素所占的比例：

function changedShare(a: Float32Array, b: Float32Array, w: number, y0: number, y1: number) {
    let n = 0;
    for (let y = y0; y < y1; y++)
        for (let x = 0; x < w; x++)
            if (Math.abs(a[y * w + x] - b[y * w + x]) > PIXEL_DELTA) n++;
    return n / ((y1 - y0) * w);
}

要看的是 PIXEL_DELTA 那一行：灰度差超过 18，也就是 255 级灰度中的 18，才算像素变化。变化像素超过 0.4%，才算这一帧有反应。顶部 7% 和底部 3% 不参与比较，避免时钟、底部指示条自行变化造成干扰。

连续变化的帧组成一个片段。作者最初把时间接近的变化直接合并，结果漏掉了滚动后紧接着发生的点击。修正办法是：前一轮变化正在减弱时，如果变化量突然上升，就重新切出一个片段。

这里的经验很具体：时间靠近的两次变化，未必属于同一次操作。

滑动和点击，要看位移也要看先后顺序

12 fps 足够粗筛，却不适合分析快速滑动。作者观察到，快速甩动时，内容在相邻帧之间可能移动超过四分之一屏。因此，每个候选片段会再以 48 fps 解码。

判断运动的方法是移动其中一帧，寻找最能抵消两帧差异的偏移量。纵向在全屏范围比较，用来识别滚动和面板移动；横向只比较发生变化的条带，避免轮播图只动一行，却被整屏静止内容淹没。

如果平移能消除至少 40% 的差异，就把这一步判为运动。随后结合时间顺序判断：滑动通常立刻带动内容，并持续向同一方向移动；点击则通常先改变界面，再出现动画。

滑动后半秒内的移动被视为惯性或回弹，跳过处理。滑动位置直接依据运动估计，不调用模型；绘制轨迹时还要限制长度，因为惯性滚动距离可能远大于手指实际移动距离。

这些判断依赖界面响应方式。点击触发整页平移动画时，能否稳定区分，原文没有给出覆盖不同应用的验证。

模型只回答「刚才点了哪个控件」

最先变化的区域，只是定位线索，不能直接当成点击位置。

例如，点中列表某一行后，整页可能滑走。变化面积很大，真正被点的控件却很小。

作者为每次候选点击发送一对 768 px JPEG，分别展示响应前后画面，再附上最早变化区域的边界框。小框可能是按钮按下时亮起，大框则可能代表页面导航。提示词要求模型判断：BEFORE 中哪个控件会导向 AFTER，同时允许返回 tap=false，排除计时器、加载指示和视频播放。

每个时刻单独请求，并行执行。返回控件框后，将手指标在框中心；时间放在画面响应前 0.15 s，用来补偿作者认为存在的交互响应延迟。这个偏移是固定近似，原文没有说明如何适配不同应用。

作者只测试了一段真实的 8 秒录屏，其中有 5 次点击。测试关闭 Thinking，temperature 为 0.1，每次点击约消耗 2.4k tokens；按测试时价格，10 次点击约 $0.02。原文没有给出模型名称、逐次识别结果或准确率，这些数字只能作为成本线索。

键盘输入会产生密集的小变化，模型被要求跳过。点击后画面完全不变的操作，则无法被发现。

我的判断

我认同它把确定性计算排在模型前面的做法。像素比较负责缩小候选范围，视觉模型负责理解控件与页面变化之间的关系，问题更集中，也方便分别排查错误。

但「比整段视频交给模型更好」仍是作者的经验判断。没有相同录屏、相同评价标准下的成本、耗时和准确率对照，不能据此认定方案普遍更优。

隐私边界也要讲准确：完整录屏留在本机，点击前后的截图仍会发送给模型。截图里的聊天、账号或业务内容同样可能敏感。

如果能够控制被录制的应用，直接记录触摸或点击事件可以提供实际坐标；从像素反推更适合只有现成录屏的情况。尤其滑动起点来自启发式规则，轨迹只能作为演示标注，不能当作真实触摸数据。

能拿来做什么

• 给现有产品录屏补点击提示时，可以先实现低分辨率帧差检测，验证它能否覆盖目标应用的主要操作，再接入视觉模型定位。
• 做浏览器端视频工具时，可以参考两轮解码：用 12 fps 找候选片段，再用 48 fps 分析局部运动，把精细计算集中在需要的位置。
• 为前端演示自动加手指标记时，应检查滚动后点击、键盘输入、无反馈点击和转场动画，并允许人工修正。原文已经表明，这些场景存在漏检或估计误差。
• 接入模型前，应明确截图发送范围；评估效果时同时记录漏检、误报和定位偏差，不能只凭演示看起来顺畅就判断可用。