我做了个免费插件，以后看视频可以边看边提问！

一、全文速览图

张咋啦在 8 月开源了一个叫「YouTube Digest」的插件：视频旁边会出现一个侧边栏，可以读取逐字稿、生成中文或双语翻译、解释选中的术语、提取章节和金句，也可以做带时间戳的笔记。

启发我动手的，是视频后半段的一句话：

GitHub 开源项目不仅是给你用的，更是给你二创的。

她还给了两条很具体的路径。即使没有编程经验，也可以把 GitHub 链接发给 Codex 或豆包，让 Agent 帮忙安装和修改；导出的逐字稿也可以继续交给自己的 Agent，加工成博客或其他内容。

我后来几乎原样照做了。

先把仓库链接发给 Codex，请它看懂项目、完成安装；再从自己的使用习惯出发，一点点改字幕来源、AI 接口、笔记和内容交接。

甚至这次补写文章时，我又用改造后的 Video Digest 导出了张咋啦原视频的完整字幕，再把它作为原始材料交回内容创作流程。

新的二创项目现已开源： https://github.com/Alex-cloud0413/video-digest.git，实现的功能有：

1. 提取字幕并生成翻译字幕、中英双语对照字幕
2. 链接本地的 Codex 或 TraeWork 来生成章节、重点引用、解释、翻译和笔记
3. 针对任意字幕片段、概览内容或已有笔记直接提问，并可把任一服务的回答保存回笔记
4. 保存时间戳笔记，并跳回视频对应位置
5. 在创作页面组合视频来源、概览、笔记与个人反思，生成创作草稿直接发送到本地「创作空间」

整个过程有点像一个闭环：一条介绍开源项目的视频，变成一个被二创的工具；这个工具又把原视频重新变成了可以继续写作的材料。

不过，闭环不是从一次成功开始的。

插件第一次真正运行时，我看到的是一张报错截图。

当时我看的是 3Blue1Brown 那期讲神经网络的视频。播放器里的英文字幕一行一行正常出现，左边的插件却告诉我：YouTube 返回了一条空字幕。

点几次 重试，还是一样。

这张图后来反而成了整个项目最准确的开头。Video Digest 不是我先想清楚一份完整 PRD，再让 Codex 一次写完的。它是我每次真的打开一个视频、遇到一个具体问题，再把那个问题变成下一条产品边界，最后一点点长出来的。

二、刚开始，我只是不想再维护两把 API Key

张咋啦开源 YouTube Digest 的时候设计得很清楚，整个项目需要两个 API Key：Supadata 负责获取字幕，DeepSeek 负责翻译、概览、解释和笔记润色。

这已经比很多把数据藏在服务端的产品透明得多。她在视频里也算过成本：Supadata 有免费额度（一个月 100 个视频），DeepSeek 处理一段常见长度的视频并不贵。

但对我自己的使用方式来说，还是有一个很实际的问题：我已经在用 Codex，为什么还要为一个浏览器侧边栏再创建两个服务账号，维护两把 API Key，再分别关心额度和充值？

所以我当时问得非常直接：

我不想另外去付费。这个获取字幕和翻译、概览解释、笔记润色的功能，可以直接连接给你吗？

这里其实拆成了两个完全不同的问题。

第一个问题是字幕。字幕不一定需要 AI，更不应该默认先购买第三方转录服务。如果 YouTube 或 Bilibili 已经向播放器提供人工字幕、自动字幕或页面字幕，插件应该优先读取平台正在使用的数据。

第二个问题是 AI。Chrome 扩展不能直接「调用正在聊天的这个 Codex」，但可以在电脑上启动一个只监听本机回环地址的 helper，让扩展把有限的请求交给已经登录的 Codex CLI。

最终形成的路径是：

YouTube / Bilibili 字幕 → Chrome 侧边栏 → 127.0.0.1 本地 bridge → 已登录的 Codex CLI → 概览 / 翻译 / 解释 / 笔记

我特意保留「本地 bridge」这几个字，因为这里很容易写得过头。它不是完全离线 AI。扩展不再保存 Supadata、DeepSeek 或 OpenAI API Key，浏览器也只连接本机端口，但 Codex CLI 仍然使用已经登录的 ChatGPT/Codex 账户和对应额度。

换句话说，我去掉的是额外的服务商密钥、账户和直接计费路径，不是凭空创造了免费算力。

这里的 127.0.0.1 不是公网 IP，而是每台电脑都用来指向「本机」的标准回环地址。外部设备不能借这个地址直接连进来，公开它也不会暴露我的真实公网 IP、地理位置或运营商。真正需要保护的是安装时随机生成的 capability，文章和公开配置都不会记录这段凭证。为了不让这个本地接口变成另一个随便暴露的洞，bridge 只监听 127.0.0.1:43110；每次安装生成一段随机 capability，也就是一份仅保存在本机配置里的安装级凭证；带 Origin 的请求只允许 Chrome 扩展来源，真正执行功能的请求还必须携带 capability；AI 命令以临时、只读、禁用工具的方式处理请求；请求体、返回体、时长和队列也都有限制。

这些东西平时看不见，但它们决定了这个插件到底是我电脑上的个人工具，还是一个不小心开放出来的本地服务。

三、架构跑通，不代表真实视频能用

第一版改造完成以后，测试可以通过，bridge 也能响应，偏偏 3Blue1Brown 的真实视频拿不到字幕。

YouTube 的字幕不是永远以同一种格式、同一条路径暴露给页面。插件需要先识别当前视频 ID，选择可用字幕轨道，优先人工字幕和合适语言，再在页面上下文里获取 JSON3 或旧 XML 字幕；如果直接字幕文件仍然为空，还要退回 YouTube 自己的字幕面板读取可点击的字幕行。

迭代到 v1.7.1 的时候，这条 fallback 又补上了 YouTube 当前使用的 transcript-segment-view-model 结构。也就是说，有些视频虽然没有传统意义上的 CC 轨道，只要页面本身能打开字幕，Video Digest 仍然可以读取。

到这个时候，「读取 YouTube 字幕」已经不再是一次固定 API 调用，而是一组要随着真实页面变化不断校准的路径。

修完以后，同一个视频终于出现了字幕，概览也能生成章节和重点引用。

这一刻很容易让人误以为项目已经完成了。字幕能看，中文和双语能切，概览能生成，笔记也能保存，似乎已经覆盖了原项目的主要功能。

但我用着用着，又遇到一个更重要的问题：看完视频以后呢？

很多 AI 总结工具的终点就是「读完了一份总结」。信息在侧边栏里显得很完整，关掉视频以后还是没有进入任何后续工作。下一次写文章时，仍然要重新找链接、找引用、翻笔记，再重新解释这段材料为什么重要。

我真正想要的不是更快地消费视频，而是让一次学习留下可继续加工的资产。

四、从概览和笔记，再走一步

于是侧边栏里多了一个「创作」页面。

这几类材料被整理成一个「学习包」，发送到电脑上预先配置好的创作空间收件箱。浏览器不能自己指定任意目录，本机 helper 也拒绝请求里夹带目标路径；每次交接只会写入固定创作空间下的新文件夹。

它不负责自动写文章，而是把一个视频的学习结果收拢起来：原始来源、视频元数据、概览、带时间戳的笔记、我自己的反思，以及一个还不成熟的可能的核心观点。

更重要的是，学习包的状态被严格限定为：

1. state = learning_complete
2. articleIntent = false
3. 不包含全文字幕
4. 不自动创建文章
5. 不触发图文、视频或发布

我很喜欢这个边界。因为「我学完了」≠「这里值得写成一篇文章」；一堆字幕和 AI Summary ≠ 已经形成了自己的判断。

内容 pipeline 如果没有这一步，很快就会退化成另一种批量制造：每看一个视频就自动生成一篇稿子，最后得到一堆来源相似、立场空洞、自己也不会再看的内容。

Video Digest 只负责把学习现场封装好，并且把来源和限制一起带过去。是否启动文章，仍然要等一个真正属于自己的判断出现。

为了让这个判断长出来，我又加了一个很小、但实际很常用的功能：在字幕、概览或某条笔记上直接提问。

比如我不理解视频中的一句话，不需要把整份字幕复制到另一个聊天窗口。侧边栏会把选中的片段、附近上下文、视频身份和我的问题一起交给本地 AI 服务；回答仍然显示在侧边栏里。如果回答有用，可以连同原片段和时间戳保存回笔记。

这时，笔记才不再只是摘抄。它开始同时保存：视频说了什么，我追问了什么，我最后理解成什么。

这也接住了张咋啦原来设计里最重要的一部分：工具不是替我看完视频，而是尽量不打断观看，让理解和记录发生在同一个现场。我的改动只是把这个现场继续向后延长，直到它能进入创作。

五、把 Video Digest 搬到 B 站，绝对不是把红色换成粉色

YouTube 跑通以后，我自然想到：既然这个项目本来就是在 B 站被我发现的，为什么同一套学习流程不能直接留在 B 站？毕竟谁上学的时候还没上过 B 站大学。

表面上看，这个需求很简单：识别 bilibili.com/video，把按钮插到播放器旁边，再把侧边栏主题色从 YouTube 红切成 Bilibili 粉。

第一版上线以后，我打开一个 B 站视频，得到的是下面这张图。

这一次，问题不在有没有字幕。插件已经能发现 Bilibili 的字幕元数据，却不能沿用页面里的普通请求方式下载字幕文件。

修复方式是把字幕文件下载移动到扩展自己的 worker，并且只允许 B 站已知的字幕 CDN host 和 subtitle path。这样既绕开页面请求环境的限制，也没有顺手把 host permission 放大成任意网络访问。

修完以后，字幕确实显示出来了。

然后我发现，它显示的是另一个视频的字幕。

这个 bug 比 请求失败 更危险。

「请求失败」至少会明确告诉我系统没工作；陈旧字幕却拥有完整时间戳、段落和按钮，看起来像一次成功。只要没有认真对照视频内容，后续概览、提问和笔记都会建立在错误来源上。

B 站的视频身份不能只靠页面上某个可能没有及时刷新的全局变量。一个真实片段需要同时绑定当前 BV 号、分 P 和 CID，也就是 B 站给具体分 P 对应视频流使用的内部内容 ID；插件还要确认请求来自当前标签页，字幕 metadata 对应当前 CID，并在视频切换时丢弃旧请求和旧缓存。

所以，为了让 Video Digest 真正在 B 站可用，最后连续出现了三个提交：先接入平台，再修字幕下载，最后修当前视频绑定。

配色从红色变成粉色，反而是其中最简单的一部分。

六、Codex 真正完成的，不只是帮我写代码

回头看 Video Digest 的 GitHub 项目历史，真正改变产品边界的有九个节点：

如果只看结果，很容易把它概括成一句「我让 Codex 帮我做了一个浏览器插件」。

实际发生的事情更具体：Codex 先读上游代码和许可证，安装本地扩展，替换数据路径，生成测试；我打开真实视频，把失败截图和现象交回来；Codex 再定位字幕轨道、页面上下文、worker、缓存键和视频身份；修完以后重新跑测试、同步本机安装目录、提交 GitHub，再从远端全新下载一份验证。

而且，迭代不总是只向前加功能。1.8.0 尝试引入更大的多 provider 工作区后（我直说了：豆包工作），真实使用变得不稳定。最后的选择不是继续给不稳定结构打补丁，而是把 main 回滚到已经验证过的 1.7.0，再只把确实需要的播放跟随和 YouTube 兼容修复做成 1.7.1。

这一步很重要。AI coding 最容易制造一种错觉：改动越多，版本越高，项目就越进步。真实使用给出的答案恰好相反。能把不稳定的复杂度拿掉，让稳定主线重新成为默认，也是一种产品能力。

Codex 帮我压缩的，是每一次返工的沟通和工程成本。以前个人开发最容易停在这里：需求说得出来，但不知道问题在哪个文件；改完一个地方，又不知道有没有破坏别的功能；本机能跑，也不知道公开仓库能不能干净安装。

现在这个循环可以连续跑：

我在真实视频里发现问题 → 截图并描述现象 → Codex 找到机制 → 修改代码和测试 → 我再次实测 → 形成新的产品边界。

截至当前稳定版 v1.7.1，仓库有 70 项自动测试；公开 Release、GitHub Actions、全新 clone 的安装检查，以及 YouTube 和 Bilibili 的真实播放都已经验证通过。

70 项测试当然不代表所有视频都会成功。它只代表那些已经付过失败成本的边界，不会轻易在下一次修改里消失。

七、现在的 Video Digest，已经不只是 YouTube 摘要器

最初的名字是 YouTube Digest + Codex。

当它开始支持 Bilibili，再继续叫 YouTube Digest 已经不准确；当创作、学习包和创作空间出现以后，Digest 也不再只表示摘要，而是一次视频学习留下的结构化资产。

现在 GitHub 上的稳定版是 Video Digest 1.7.1。它可以在 YouTube 和 Bilibili 旁边提供：

1. 读取当前视频可用的字幕或页面字幕，并按时间戳展示；
2. 当前字幕随视频播放自动高亮和滚动；如果主动下滑阅读，自动跟随会暂停，也可以点 跟随播放 恢复；
3. 原文、简体中文与双语视图；
4. 章节、重点引用、翻译、解释和概览；
5. 对字幕片段、概览项或已有笔记的针对性提问，并把有用回答保存回笔记；
6. 带来源和时间戳的笔记，以及返回对应视频片段的跳转；
7. 状态严格限定为 learning_complete 的学习包，以及限定目录的创作空间本地交接；
8. 汇总来源、概览、笔记、个人反思和可能的核心观点的创作页面；
9. 英文、中文、德语三语界面（是的，它还支持德语），浏览器浅深色适配，以及随 YouTube / Bilibili 切换的红色和粉色主题。

我自己的版本通过 Codex CLI 完成 AI 操作。公开项目现在也允许在设置里选择 TraeWork，走本机已登录的 Trae CLI 2.0。两条路径都不要求把服务商 API Key 填进扩展，但都会消耗所登录账户的额度。

安装仍然保持了开源项目的方式：下载或 clone 仓库，生成仅保存在本机的 bridge 配置，启动本地 helper，再在 Chrome 的开发者模式里「加载已解压的扩展程序」。真正开始前，需要本机已经安装并登录至少一个受支持的 AI CLI。

对外品牌换成了 Video Digest，内部目录名、缓存 key 和本机端口却没有跟着全部大改。这不是偷懒，而是兼容性选择。用户已经保存的笔记、缓存和创作空间配置，不应该因为改名一起丢失。

八、Video Digest 能做什么，也明确不能做什么

Video Digest 不做音频转录。YouTube 至少要向页面提供原生或自动字幕，或者可打开的字幕数据；Bilibili 需要暴露 CC / AI 字幕轨道，某些视频还取决于登录状态。只烧录在画面里的字幕不是可直接读取的数据。

本地 bridge 需要保持运行。Codex 或 TraeWork 请求会消耗已登录账户的额度。它不是云端 SaaS，也不是自动发布器。

这些限制没有让产品显得更弱，反而让我更愿意把它接进自己的内容流程。因为一条 pipeline 只有在边界清楚时才值得信任。

我现在使用的视频内容路径是：

视频 → 字幕 → 概览 → 片段追问 → 笔记 → 个人反思 → 学习包 → 文章候选 → 图文 / 视频衍生

其中每一个箭头都不是自动发布许可。学习材料可以进入创作项目，但文章仍要经过选题、证据、判断和确认；图文和视频也应该从确认后的文章衍生，而不是把字幕重新排列一遍。

这篇文章本身，刚好成了这条路径最直接的一次验证。

张咋啦在原视频里说，导出的逐字稿可以继续交给自己的 Agent，加工成博客；她也希望别人不要只安装，而是把开源项目改成适合自己的样子。

我先照着她的视频把项目装了起来，再和 Codex 一起把它改成 Video Digest。现在，我又用 Video Digest 导出那条原视频的字幕，重新补齐这篇文章的起点、来源和项目说明。

它没有证明 AI 可以一次把软件做对。恰恰相反，整个过程反复证明：真实使用会不停推翻第一版答案，版本号也可能需要后退。

但现在，推翻不再意味着项目停在那里。每次失败都可以进入代码、测试和下一轮使用；每次学习也可以带着来源进入下一轮创作。

从一条 B 站视频，到一个开源仓库，再到一条属于自己的内容生产线——这才是我最后真正想从一个 Digest 插件里得到的东西。