我做了一个 Chrome 扩展,把 YouTube 播放列表批量变成 AI 可读的本地 Markdown

作者:嘉琪coder日期:2026/9/12

现在的 AI 已经很擅长总结、分类和问答,但在真正使用它整理知识时,我经常卡在更前面的一步:

怎样把散落在视频里的内容,变成 AI 可以稳定读取的资料?

我平时会在 YouTube 上看课程、访谈和播客。看完时觉得收获很多,过一段时间想找其中一个观点,却只能重新打开视频、拖动进度条。

如果是一套几十集的课程或一个持续更新的频道,逐个打开视频、复制字幕、创建文件,光是准备资料就足以让人放弃。

所以我做了 Transcriptly

它是一款免费、开源的 Chrome 扩展,可以把 YouTube 视频、播放列表和频道中的字幕批量保存为本地 Markdown。

它解决的不是“下载字幕”

单独下载一条字幕并不难,真正麻烦的是把大量视频转化成可以长期保存、检索和复用的资料。

Transcriptly 的工作流很简单:

1YouTube 视频 / 播放列表 / 频道
2              
3       选择需要的视频
4              
5   批量保存为本地 Markdown
6              
7 Obsidian / VS Code / Git / AI
8

在播放列表或频道中勾选视频,再选择一个本地文件夹,Transcriptly 会依次处理这些视频。

每个视频都会生成一份独立的 Markdown 文件。它们不依赖某个平台,可以被编辑、搜索、备份,也可以直接交给支持本地文件的 AI 工具处理。

为什么选择 Markdown?

因为 Markdown 同时适合人和 AI 阅读。

对人来说,它是普通文本文件,可以放进 Obsidian、VS Code 或任何文本编辑器,也可以通过 Git 管理版本。

对 AI 来说,它没有复杂排版和多余页面元素,标题、段落和时间戳都比较清晰,可以直接用作总结、搜索和知识整理的原始材料。

例如,我可以把一套课程字幕保存到同一个目录,然后让 AI:

  • 按章节总结整套课程
  • 提取反复出现的概念
  • 对比不同视频中的观点
  • 查找作者在哪一期提到过某个问题
  • 根据原始内容生成学习笔记
  • 整理成相互关联的知识库页面

这里需要特别说明:

Transcriptly 本身不是另一个 AI 知识库产品,也不绑定任何大模型。

它更像知识工作流中的“资料入口”:先把 YouTube 内容转换成开放、干净的本地文件,再由你选择 Obsidian、Claude、ChatGPT、Cursor、Codex或其他工具继续处理。

两种 Markdown 格式

不同使用场景需要不同的字幕结构,因此 Transcriptly 提供了两种格式。

Timeline

Timeline 会保留每一段字幕对应的时间戳。

点击时间可以返回视频的相应位置,适合查找原话、核对上下文或引用视频来源。

1[03:18] The important thing is not the tool itself...
2
3[03:24] It is how the tool changes the way we work.
4

Article

Article 会减少时间线带来的阅读干扰,把字幕整理成更接近普通文章的形式。

这种格式更适合连续阅读,也更方便直接交给 AI 总结、提取观点或整理笔记。

为什么坚持本地优先?

我希望保存下来的字幕首先属于用户,而不是被锁在另一个在线服务里。

只使用本地保存功能时,不需要注册账号。扩展通过浏览器能力把 Markdown 直接写入你选择的文件夹,字幕不需要经过 Transcriptly 的服务器。

这意味着你可以自由决定:

  • 文件放在哪里
  • 使用什么编辑器
  • 是否用 Git 备份
  • 交给哪个 AI 工具
  • 将来是否迁移到其他知识库

即使有一天不再使用 Transcriptly,这些 Markdown 文件依然可以正常打开和使用。

批量处理是怎么工作的?

单个视频可以直接保存。进入 YouTube 播放列表或频道后,也可以一次选择多个视频。

扩展会依次打开视频页面、读取可用字幕并保存文件,同时支持暂停、继续和失败重试。

处理数量没有人为设置的固定上限。不过,批量获取仍然会受到网络速度、视频数量以及 YouTube 页面加载速度的影响。

这套机制没有调用需要用户配置密钥的 YouTube Data API,而是尽量在用户正常浏览 YouTube 的环境中完成处理。

可选的公共字幕库

除了本地保存,我还在尝试做一个公开的字幕知识库:

transcriptly.libmap.cn/transcripts

用户可以选择把字幕贡献到公共字幕库,其他人便可以在线搜索、阅读,并返回对应的 YouTube 原视频。

公开贡献不是默认行为。它需要用户主动选择,本地保存和公开分享是两件相互独立的事情。

我希望它未来不只是字幕展示页面,也能成为一个可搜索、可引用的公开视频文字资料库。

安装与使用

Transcriptly 已经上架 Chrome 应用商店:

安装 Transcriptly

安装后打开一个带字幕的 YouTube 视频,点击浏览器工具栏中的 Transcriptly 图标,即可预览并保存字幕。

如果在播放列表或频道页面使用,还可以进入批量选择模式,一次保存多个视频。

项目采用 MIT 协议开源,源代码在 GitHub:

github.com/liujiaqi222…

最后

做 Transcriptly 的起点,并不是“再做一个字幕下载器”。

我真正想解决的问题是:

怎样把长期观看的视频,从稍纵即逝的内容,变成自己可以保存、搜索,并持续交给 AI 整理的知识资产?

现在它还处于早期阶段。如果你平时也会用 AI 整理课程、访谈或播客,欢迎试用并告诉我你的工作流。

也欢迎在 GitHub 提 Issue、参与开发,或者给项目一个 Star。


我做了一个 Chrome 扩展,把 YouTube 播放列表批量变成 AI 可读的本地 Markdown》 是转载文章,点击查看原文


相关推荐


流程图上没画人,单子却走对了:工作流引擎内置处理人解析器
mldong2026/9/4

一、流程图上没画人,单子却走对了 用流程设计器画一张最简单的请假审批流:开始 → 部门领导审批 → 结束,三个节点两条线。 画完之后你检查一遍这张图:节点上没有任何人的名字。没有"张三",没有"李四",连"审批人"三个字都是你自己写的节点显示名。从图上看,这张流程不知道该把单子交给谁。 然后你发起了一笔请假。几秒后,你部门领导的待办列表里,多了这条单子。 它怎么知道该去找领导的? 你可能会说:节点名不是写着"部门领导审批"吗——但节点显示名只是个标签,引擎不会拿它去组织架构里搜人;就算你把节点改


Next.js 全栈笔记系统实战:RSC 组件架构、Redis 数据层与规范驱动开发
浮生望2026/8/27

摘要 以Next.js笔记系统为例,深入RSC异步组件直接查询Redis、Server/Client组件边界、BEM命名规范、路径别名及组件驱动开发流程,展示从需求分析到技术方案到组件拆分的全栈落地路径。 一个笔记系统的需求并不复杂:左侧笔记列表,右侧 Markdown 编辑预览,支持 CRUD 和搜索。但用 Next.js 全栈实现它,涉及的技术决策覆盖了 RSC 组件边界、数据层选型、组件拆分策略和项目结构规范——这些正是 Next.js 工程化的核心议题。 技术选型:为什么是 Redis


JavaScript实战技巧总结
阿橙的百宝箱2026/8/19

JavaScript实战技巧总结* 引言 JavaScript作为现代Web开发的基石,其灵活性和强大的功能使其成为开发者必备的技能之一。然而,随着ECMAScript标准的不断演进和前端生态的日益复杂,如何高效、优雅地编写JavaScript代码成为开发者面临的重要课题。本文将从实际出发,总结一系列经过实战检验的JavaScript技巧,涵盖性能优化、代码简洁性、异步处理、模块化等多个关键领域,帮助开发者提升代码质量和开发效率。 一、性能优化技巧 1. 减少DOM操作 DOM操作是Java


篇2-bitsandbytes-具体观-算法与实现剖析
happyprince2026/8/4

三部曲之二 · 看懂:潜入水下的技术细节 本篇承接整体观建立的认知地图,潜入水下逐一审视 bitsandbytes 的核心技术实现——LLM.int8()、QLoRA/NF4、8-bit 优化器,以及支撑它们的极致工程。每个技术点遵循"原理(论文)→ 代码 → 例子"三段式剖析,让读者真正"看懂"代码背后的学术根源与工程取舍。 一、总述:三大算法支柱 + 一条工程脊梁 bitsandbytes 的技术内核可拆成三大算法支柱 + 一条工程脊梁。三大算法支柱是:① LLM.int


把随身WiFi改成网盘聚合器:中兴F50挂载本地存储+夸克网盘实战
羑悻的小杀马特.2026/7/27

文章目录 前言1 什么是OpenList?2 中兴F50上安装OpenList服务3 挂载本地存储和网盘存储3.1 挂载本地F50自带的20G存储3.2 挂载夸克网盘 4 穿透OpenList以支持公网访问4.1 如何用?4.2 在F50上安装4.3 配置OpenList的http隧道 5 固定二级子域名(升级任意套餐)总结 前言 中兴F50放在包里时,很多人只把它当作一台提供热点的随身WiFi。需要传文件、打开网盘资料或临时分享内容时,仍然要依赖手机、电脑和多个客户端


【数据库】CRUD-- 增删改
哦虎!2026/7/19

第二章 增删改 文章目录 第二章 增删改前言一、命名二、增1. 新增2. 指定列插入3. 多行插入4. 插入查询结果5. 查询的指定列插入6.注意 三、改1.修改数据2.组内修改 四、删除1. 删除数据2.drop和delete的区别 五、截断表总结 前言 本期主要讲增 删 改, 会稍微使用到查 , 也就是select , 遇到会稍做讲解 , 详细讲解会放到下期~ 一、命名 创建表时,命名有两种 驼峰命名(studentName)蛇形命名(stud


C++内存管理
孬甭_2026/7/11

目录 1 · C / C++ 内存分布 2 · C++内存管理方式 2 - 1 · new / delete 操作内置类型 2 - 2 · new / delete 操作自定义类型 3 · operator new 和 operator delete 函数 4 · new 和 delete 的实现原理 4 - 1 · 内置类型 4 - 2 · 自定义类型 5 · 定位new 6 · new / delete 与 malloc / free 的区别 1 · C / C


EventBus → SharedFlow
plainGeek2026/7/3

EventBus → SharedFlow 老写法(Java + EventBus) // 事件定义 public class LoginEvent { private long userId; public LoginEvent(long userId) { this.userId = userId; } public long getUserId() { return userId; } } // 发送 EventBus.getDefault().post(new


【Linux基础】初始Linux
键盘敲碎了雾霭2026/6/25

🎬 博主名称:键盘敲碎了雾霭 🔥 个人专栏: 《C语言》《数据结构》 《C++》 《Matlab》 《Python》 《Linux》 ⛺️指尖敲代码,雾霭皆可破 文章目录 一、Linux发展史1.1 UNIX发展历史1.2 Linux发展历史 二、开源三、应用现状四、发行版本五、os概念六、使用XShell远程登录Linux6.1 会话方式登录6.2 命令行登录6.3 多用户使用 文章结语 一、Linux发展史 要说Linux,还


【Java基础】链表的七十二变——从LRU缓存到手写浏览器前进后退
zzz_23682026/6/16

链表的七十二变——从LRU缓存到手写浏览器前进后退 写在前面的目录 一、真实面试真题引入 二、链表的底层解构——不止是 next 指针   2.1 单向链表:最简单的链式结构   2.2 双向链表:前后眼的设计哲学   2.3 链表反转四步拆解   2.4 哨兵节点——让边界消失   2.5 跳表——给链表加个索引 三、"纯手工、零依赖"原创案例实战   3.1 浏览器前进后退——双向链表实现标签页导航   3.2 LRU 缓存淘汰——HashMap + 双向链表的 O(1) 魔法 四、

首页编辑器站点地图

本站内容在 CC BY-SA 4.0 协议下发布

Copyright © 2026 聚合阅读