开源Sponsor Skip：用Jev跳过YouTube赞助片段
内容提要
Sponsor Skip 使用 Jev 决策模型跳过 YouTube 赞助片段。Jev 只回答“哪一行”“是否”“多确定”，时间戳由代码计算，避免模型生成错误时间。它不依赖 SponsorBlock 众包标记，提供转录、Smart、Listen 三种模式，成本从每小时不到一美分到约 0.46 美元不等。转录模式受 YouTube 限制，需家庭网络；音频模式在浏览器 offscreen 文档捕获，密钥本地保存。
延伸解读
众包标记的激励困境
SponsorBlock 依赖用户标记和投票加权，但激励结构导致热门视频的误标容易被修正，冷门视频的坏标记几乎无人处理。文章引用 Firefox 商店差评指出，标记机制被滥用，甚至出现全视频被标为赞助的情况。这提醒我们，众包系统的质量与内容流行度正相关，评估时需关注长尾表现。
Jev 的职责边界与确定性
Jev 模型不生成时间戳，只回答“哪一行”“是否”“多确定”，所有时间计算由代码完成。这种分工消除了模型生成错误时间的可能，但准确性完全依赖转录质量和 Jev 判断力，没有社区纠偏缓冲。一个转录错误或误判会直接导致错误跳过，这是确定性与容错之间的权衡。
三种模式的成本与可用性
Transcript 模式成本不到一美分每小时，但受 YouTube 限制，需家庭网络；Smart 模式约 0.05 美元每小时，依赖转录和片段音频确认，有 12 秒回退风险；Listen 模式约 0.46 美元每小时，不依赖字幕但成本最高。用户需根据网络环境、视频类型和预算选择，云端部署可能因数据中心 IP 被屏蔽而失效。
隐私与权限设计
音频从视频元素捕获，不经过标签页捕获 API，也不请求麦克风权限，避免了环境噪音录入。API 密钥保存在 chrome.storage.local，不暴露给页面 JavaScript，降低了 XSS 攻击风险。这种设计在 MV3 下利用 offscreen 文档处理音频，兼顾功能与隐私，但用户仍需信任 Deepgram 等第三方服务。
Q&A
Sponsor Skip 和 SponsorBlock 在跳过 YouTube 赞助片段的方式上有什么根本区别？
SponsorBlock 依赖社区众包标记，用户提交赞助片段的起止时间，其他人跟着跳过；Sponsor Skip 不依赖任何人的标记，而是通过分析视频的转录文本或音频流，用 Jev 模型判断赞助片段的位置，时间戳由代码计算。
Jev 模型在 Sponsor Skip 中具体负责什么？它为什么不直接生成时间戳？
Jev 只回答“哪一行”“是否”“多确定”这类原子判断，比如“哪一行首先提到了赞助商”。所有时间戳都由代码计算，Jev 只输出行号（如 L037），代码将行号映射回秒数。这样避免了模型生成错误时间戳的可能。
Sponsor Skip 的 Transcript、Smart、Listen 三种模式分别适用于什么场景？成本差多少？
Transcript 模式仅用转录，成本不到一美分每小时，但依赖 YouTube 字幕，受数据中心 IP 限制；Smart 模式结合转录和片段周围音频，成本约 0.05 美元每小时，可靠性受转录质量影响；Listen 模式全程流式音频，成本约 0.46 美元每小时，不依赖字幕，适合无字幕视频。
为什么 Sponsor Skip 的转录模式在云服务器上可能无法工作？
因为 YouTube 从 2024 年开始收紧 PoToken 策略，字幕轨道对数据中心 IP 隐藏，服务端请求需要执行混淆 JavaScript 生成 Proof of Origin Token。Sponsor Skip 文档指出转录获取需要家庭网络连接，云服务器上字幕可能拿不到。
Sponsor Skip 的音频捕获是如何实现的？需要麦克风权限吗？
音频从视频元素本身捕获，通过 Manifest V3 的 offscreen 文档机制，不需要麦克风权限。offscreen.js 持有语音 socket，pcm-worklet.js 从视频元素抓取 PCM 数据，音频只在 offscreen 文档和 Deepgram 服务器之间流转。
Sponsor Skip 的 API 密钥存储在哪里？安全吗？
TypeSafe 和 Deepgram 的 API key 保存在 chrome.storage.local 中，文档明确说“永远不会到达页面”。密钥不经过 YouTube 页面的 JavaScript 上下文，因此恶意脚本或 XSS 攻击拿不到这些 key。
