AI 读 YouTube 字幕建错向量，根源在视频信息损耗

上个月，我使用的一个 Agent 读取了一个教程的自动生成字幕——"embedding dimension 136"——结果把向量建成了错误的维度。所有下游调用全部失败。而屏幕上（如果有人看过的话）写的是 1536。

这就是那个最终催生出 tuto 的 bug：https://github.com/dingmon1019/YoutubeAnalyzer

字幕是对语音的有损转录，而不是对屏幕上内容的记录。教程、仪表盘和幻灯片往往把关键数值放在屏幕上，这些数值常常从未被口述说出。一个只读字幕的 Agent，相当于只看了视频的一半。

那就多采一些帧呗。但这很快就会变得很贵，而且并没有解决真正的问题：你仍然需要知道哪些帧是重要的，以及这个视频到底需不需要帧。一段 28 分钟的音乐播放列表，用价值 5 美元的视觉调用来处理，屏幕上零信息价值。

有效的架构

一个"屏幕价值门控"（screen-value gate）先读取字幕，判断是高价值还是低价值，然后再决定在视觉上花多少钱。低价值就停下并提问——这里的错误判断代价是一个问题，而不是一次浪费掉的运行。

帧的选择依据信号强度（YouTube 热力图、章节边界、活动峰值、字幕提示词如"click here"），而不是均匀采样。

一个 Agent、一个上下文，自始至终看完每一帧，并在同一上下文中综合知识——如果把这个过程拆成独立的"读取"和"综合"两个 Agent，实测费用会增加 36%。

每个结论都附带其证据来源（帧或字幕）。当二者不一致时，以帧为准，且这种不一致会被保留为数据，而不是被静默解决。

在一个 54 分钟的高密度屏幕教程上：171 个知识条目，其中 69 个可追溯到真实像素，费用 4.76 美元，墙上时间 14.6 分钟，785 个测试通过。

如果重来做会不同的地方

决定一个屏幕是否值得读取的门控，本身就是一个 LLM 的判断，而该项目自己的测量显示这个判断是有噪声的——所以我刻意把它放在"输了也便宜"的地方（一个问题），而不是"输了很贵"的地方（一次浪费掉的 15 分钟运行）。

这是一个 Claude Code 插件，MIT 许可：https://github.com/dingmon1019/YoutubeAnalyzer

如果你在自己的 Agent 流水线中也遇到过字幕 vs 屏幕的问题，我很想知道。