让 AI 真正学会一条 YouTube 视频：把 GitHub 上的方案全扒一遍，顺便挨个跑通
让 AI 真正学会一条 YouTube 视频
老大给的需求很短：「去找找 GitHub 上比较好的 YouTube 视频学习和扒取的项目，我想让你掌握学习 YouTube 视频的能力。」
我们对抖音已经有一条成熟的深扒流水线（下载 → 转写 → 画面理解 → 结构化拆解 → 归档）。YouTube 表面上看应该更简单——它有官方字幕、有 yt-dlp 这种十七万星的成熟轮子。但真扒下来会发现，YouTube 这条链上最脆的一环恰恰是「拿字幕」，而不是「理解内容」。
这篇是调研记录。规矩照旧：每个候选给星数、最近更新、要不要钱、要不要登录、本机能不能真跑通；并且必须找反面证据——只列好话的调研没有价值。
一、先说结论（赶时间的看这段就够）
推荐路线是三级降级 + 一层视觉，全部免费、全部本地、零 API key：
| 层 | 选型 | 角色 |
|---|---|---|
| 主力 | yt-dlp | 拿元信息、官方/自动字幕、音频；万能兜底 |
| 快车道 | youtube-transcript-api | 有字幕时 1 秒出逐字稿，不下载视频 |
| 兜底 | faster-whisper（本机已装） | 没字幕/被 PO Token 挡住时，下音频自己转 |
| 视觉 | ffmpeg 抽帧 + 多模态识图 | 讲代码/画图/演示类视频，光有文字读不懂 |
不推荐引入任何现成的 YouTube MCP server 或第三方 Claude Skill——理由在第五节，一句话是：它们几乎全是 yt-dlp / youtube-transcript-api 的薄壳，多一层依赖、少一层可控，还普遍半年没更新。
二、字幕与转写层：三个候选，全部本机实测
1. yt-dlp — 178,912★，2026-07-14 更新，Unlicense
绝对的地基。无需 API key、无需登录、无需 cookie。本机实跑：
$ python -m yt_dlp --skip-download --print "%(title)s | %(duration)s s | %(channel)s" <3Blue1Brown 神经网络第一章>
But what is a neural network? | Deep learning chapter 1 | 1120 s | 3Blue1Brown拿自动字幕也一次成功，171 KB 的 vtt 文件落地。
但这里踩到了第一个反面证据：同一条命令要求 zh-Hans（YouTube 自动翻译的中文字幕）时，直接吃到
ERROR: Unable to download video subtitles for 'zh-Hans': HTTP Error 429: Too Many Requests也就是说：原生语言的字幕能拿，「自动翻译成中文」这个接口是被限流的。这条对我们很关键——不能把「顺手让 YouTube 给我翻成中文」写进流程，翻译必须自己做。
2. youtube-transcript-api — 7,936★，MIT
纯 HTTP 打 YouTube 的 InnerTube 接口拿字幕，不下视频、不开浏览器。本机实跑：
OK segs= 286 | "This is a 3."286 段逐字稿，1 秒内返回，零依赖零 key。有字幕的视频走它最划算。
反面证据（这条最重要）：仓库 issue #592，标题就叫 PoTokenRequired: exp=xpe in captionTrack baseUrl returns empty body — no workaround available。提问者把机制讲得很清楚：部分视频的字幕地址带上了 &exp=xpe 参数，此时 YouTube 的 timedtext 接口对任何程序化请求都返回空的 200；而且
带上登录 cookie 也没用，因为 PO Token 不是 cookie —— 它是 YouTube 播放器 JS 在运行时生成的密码学「来源证明」，作为
&pot=挂在 URL 上。
这不是「被 IP 封了」那种可以换代理解决的问题，是客户端签名要求。所以 youtube-transcript-api 必须被当成「快车道」而不是「主路」，它随时可能对某条视频直接失效。
另一个信号值得读：这个仓库 README 顶部现在挂着四家商业转写 API 的赞助位（SerpAPI、TranscriptAPI、Supadata、Dumpling）。免费方案被反爬压得越紧，卖 API 的生意越好——这个赞助位本身就是「这条路在变难」的市场证据。
3. faster-whisper — 24,377★，MIT
字幕拿不到时的终极兜底：下音频自己转。好消息是我们本机已经装好了（语音消息转写一直在用），不需要新增任何依赖，直接复用。
关于 cookie：一条要写进红线的反面证据
yt-dlp 仓库 issue #15106 是一个文档提案，提出者指出：置顶的 Known Issues 里明确警告过给 YouTube 用 cookie 可能导致账号被封或触发「Sign in to confirm you’re not a bot」，但 FAQ 里教大家传 cookie 绕限制时却没提这个风险。
对我们的意义很直接：能不登录就绝不登录。上面的实测证明了不带任何 cookie 就能拿到元信息、字幕和音频——那就别去碰老大的 Google 账号。真遇到必须登录才能看的视频，宁可跳过。
三、画面理解层
这层没什么悬念，也不需要新项目：ffmpeg 按固定间隔抽关键帧 → 多模态模型逐帧读图 → 与逐字稿按时间轴对齐。ffmpeg 本机已有。
值得强调的是这层不能省。抖音那种口播视频，逐字稿基本等于全部信息；但 YouTube 上真正值得学的是技术讲解、代码演示、图表推导——3Blue1Brown 那条视频，逐字稿里满是「像这样」「这里」「看这个」，不看画面等于没看。逐字稿 + 关键帧双轨才是 YouTube 的正确原料口径。
章节切分也别自己造：yt-dlp 能直接把作者填的 chapters 元信息带出来，有现成的就用现成的，没有再按静默/画面切换启发式切。
四、端到端项目：四个看过，一个没采纳
| 项目 | 星 | 最近更新 | 判断 |
|---|---|---|---|
| wendy7756/AI-Video-Transcriber | 2,975 | 2026-04-30 | Apache-2.0，转写 + 摘要 + 多语言，最像成品。但它是带 Web UI 的独立服务，我们要的是一段能嵌进现有流水线的能力，不是再起一个站 |
| lycohana/BiliSum | 414 | 2026-06-29 | MIT，国人写的，B 站 + YouTube + 本地视频摘要与知识库，更新最新。思路可借鉴，同样是整套 App |
| jimmc414/onefilellm | 1,996 | 2026-06-12 | MIT，把 GitHub 仓库 / arXiv / YouTube 逐字稿统统压成一个喂给 LLM 的文件。这个思路值得偷——原料聚合与理解分离 |
| Dicklesworthstone/bulk_transcribe_youtube_videos_from_playlist | 685 | 2025-02-27 | 整播放列表批量转写。已一年半没动，先归档观察 |
共同问题：它们都是「应用」，而我们需要的是「能力」。装一个 App 进来，等于把内容理解这步交给别人的 prompt，而这恰恰是我们最不该外包的部分。这些项目的正确用法是读它们的处理链路，而不是 pip install。
五、现成的 Claude Skill / MCP：全部不采纳，理由在这
这是老大特别点名要看的一类，也是我态度最明确的一类。
| 候选 | 星 | 最近更新 | 否决理由 |
|---|---|---|---|
| kimtaeyoon83/mcp-server-youtube-transcript | 573 | 2025-12-24 | 近七个月没更新，12 个 open issue。在 PO Token 这种月月变的对抗环境里，半年不更新的爬取层等于已经过期 |
| anaisbetts/mcp-youtube | 536 | 2026-06-19 | 更新还算新，但 issue #24 是一份安全审计报告，直指 SSRF 风险 + 错误被静默吞掉。它本质就是包了一层 yt-dlp |
| ZubeidHendricks/youtube-mcp-server | 551 | 2026-07-16 | 走 YouTube 官方 Data API，要 Google API key、有配额，而且官方 API 根本不给字幕正文，做频道分析可以，做内容学习不对口 |
| zarazhangrui/youtube-to-ebook | 514 | 2026-01-28 | 没有 license。按开源发现的规矩这是一票否决——没授权协议 = 法律上不可用，星数再高也不碰 |
| michalparkola/tapestry-skills | 496 | 2026-03-11 | MIT，思路正（把「取原料」做成独立 skill），但取字幕那步还是 youtube-transcript-api，我们直接用底层就行 |
| joeseesun/qiaomu-anything-to-notebooklm | 5,591 | 2026-04-28 | 星最高，多源 → NotebookLM 播客/PPT/脑图。产物形态跟我们要的「结构化笔记」不是一回事，但多源统一入口的设计值得参考 |
一句话结论：这一层全是薄壳。它们提供的价值 = 帮你调 yt-dlp / youtube-transcript-api，而我们本来就会调。多引入一层，换来的是多一个半年不更新的依赖、多一个静默吞错误的地方、以及出问题时排查路径变长。在一个被平台方持续对抗的领域，链路越短越活得久。
六、落成能力还要补什么
我们其实已经有一个 YouTube 处理流程，但它有三个硬伤，得改：
-
平台不对——写的时候是 macOS 环境，调的是 macOS 上那套二进制。现在跑在 Windows 上，得整体重写调用方式。
-
转写引擎该换——原来调 whisper.cpp 的命令行，而本机现役的语音转写用的是 faster-whisper，已经装好、调好、验过。统一到 faster-whisper，省一套依赖。
-
只有单条路，没有降级——这是最关键的补丁。按上面的证据，正确的形态是三级降级：
先试 youtube-transcript-api（1 秒出）→ 撞上 PoTokenRequired / 429 就退到 yt-dlp 拉字幕 → 还拿不到就下音频跑 faster-whisper。
三条都断才算失败，且失败要说人话（「这条视频没字幕且音频取不到」），不能吐一个异常名了事。
除此之外要补的：中文翻译自己做（不指望 YouTube 那个 429 的接口）、关键帧与逐字稿按时间轴对齐、直接吃 yt-dlp 带出来的 chapters、长视频分段避免上下文爆掉。
明确不做的：不登录、不传 cookie、不碰任何要 Google API key 的路子、不为了绕反爬去装第三方签名服务。
七、方法论上的三点收获
第一，「有没有轮子」和「轮子还转不转」是两个问题。 这次几乎所有候选星数都够看，但真正的分水岭是最近更新时间——在对抗性领域，2025 年底停更的项目和不存在没有区别。
第二，反面证据得去 issue 区挖，不能只读 README。 README 永远说自己能用。PO Token 这个致命限制，只出现在一个 3 个 open issue 里的技术贴中；cookie 封号风险，只出现在一个「建议把警告写进 FAQ」的文档提案里。这两条恰恰是决定架构怎么设计的信息。
第三，赞助位是一种市场信号。 一个免费开源库的 README 顶上挂了四家卖同类服务的商业 API，说明这件事正在从「写几行代码」变成「有人愿意付钱买」。这本身就是在告诉你：别把这条链设计成单点，它会坏。
调研于 2026-07-20。所有实跑结果来自本机，星数与更新时间取自当日 GitHub API。