bili2txt-agent这个项目一开始真的只是我自己的“偷懒工具”。每天要在B站刷十几个技术视频看完就忘忘了就得从头拖进度条拖完又忘。后来我干脆把它做成了一条自动流水线把B站链接丢进去几分钟后拿到的不是一段干巴巴的字幕而是一篇带了章节、核心观点、关键术语、金句和视频内时间戳的Markdown笔记。这个项目开源之后陆续有人来问怎么部署、怎么调参数以及那个“效率提升300倍”到底是不是噱头。这篇文章我一次性说清楚设计逻辑、选型过程、实测数据还有我踩过的坑。1. 为什么需要它视频学习的成本大头在“回头找”1.1 看视频本身不耗时复习和检索才是我自己关注的方向比较杂从系统架构、开源项目解读到某个算法原理都是B站上的长视频或者系列课。一个20分钟的讲解第一遍看的时候很爽思路跟得上弹幕氛围也好但关上网页让我复述核心结论往往只能说出两三点。于是要么重新拉一遍进度条好一点的情况是UP主做了章节标记但章节只到“10:00 第二部分”并不等于我想找的那个知识点在第几秒。这个“回头找”的过程实际上比看视频本身更消耗意志力刷着刷着你就不想找了学习就断在那里。这就是立项前最原始的痛点视频学习链条上成本大头不是“看”这一步而是“看完之后怎么把信息再拿回来”。而拿不回来的那些信息约等于没看。1.2 已有方案为什么不够用在选择自己写工具之前我把当时可行的方案都试过一遍各有各的难受UP主简介或评论区文字稿存在率极低。更常见的情况是UP主只放了PPT的链接PPT和自己讲的内容并不完全对应。视频网站的自动字幕B站现在有不少视频有AI字幕复制出来比较容易但这份字幕没有分段、没有重点语气词和识别错词非常多很难把它当成一篇“笔记”来读。要在一堆“嗯”“然后”“这个这个”里找有效信息一样费眼睛。在线转写平台有的效果确实不错但对视频时长有限制平台审核规则不透明部分使用场景下用户还会担心数据去向。更关键的是大部分在线工具只给你一段连续文本不给你做结构化。手动截图加文字笔记我只坚持了两个视频就放弃了。截图虽然能精准记录某个画面但检索还是靠人脑时间一久照样找不到。这些尝试让我确认了一件事大家缺的不是“把视频变成字”的工具而是“把视频变成一篇能读、能搜、能放进知识库的笔记”的工具。转写只是第一步结构化才是真正拉开差距的地方。这也是bili2txt-agent在命名里带上agent的原因——它不是一次性转换而是一条带着判断和整理能力的流水线。2. 技术选型音频下载、语音转写、结构化加工三条线分别怎么定2.1 为什么选择“音频转写”而不是“抽帧OCR”做这个项目之前有朋友建议走视频抽帧加OCR的路线把每一帧里的字幕和PPT文字都识别出来。这个思路对画面信息占比高的视频操作演示、游戏实况确实有价值但对大部分技术和知识类视频来说信息密度最高的是人声而不是画面。音频方案的体积优势也非常明显一个60分钟的视频文件可能几百MB但提取出来的音频只有几十MB后续转写输入更稳定。画面里经常出现的弹幕遮挡、动态水印、UI抖动都会让OCR结果非常糟糕而音频转写几乎不受这些干扰。所以主链路以音频为主不依赖画面如果确实需要PPT截图做上下文补充可以在结构化阶段按章节把视频切成关键帧作为辅助信息而不是主输入。2.2 语音转写选本地模型还是云端API这是整个项目里最需要权衡的部分。两类我都用过用一张表说清楚对比项本地开源模型云端API中文口语准确率良好接近可用更高多人对话和背景音更稳成本免费只要有算力按时长计费长视频累加不便宜隐私数据不出机器数据出本机需了解平台规则速度有GPU很快无GPU很慢快部署难度中需要装环境和模型权重低申请接口即可我的建议是分层处理个人低频使用本地模型完全够用挑一个7B左右规模的中文优化版本就能获得不错效果如果要做批量或时效性要求高的场景再考虑API但请求层一定要加缓存同一视频不要重复付费。2.3 为什么结构化必须用Agent而不是固定脚本转写出来的文本是什么状态用过ASR的人都有体会没有标点或标点乱、口语重复、语气词连篇、突然出现完全跑题的一段。如果只写一个脚本把这段文本塞给大模型让它“帮我整理一下”结果通常会遇到两个问题一是上下文长度不够二是输出不稳定——模型开始自由发挥把UP主的一句玩笑润色成严肃结论或者把识别错的技术名词沿着错误方向解释了一大段。Agent化的做法是把这个过程拆成有状态的小任务串先按时间戳切段每一段独立做一个“清洗要点提取”拿到每段要点后再做全局章节归纳。每个小任务都有明确的输入输出格式模型发挥空间被压缩在字段里上一段提取失败不会导致全文中断被识别为低置信度的片段还可以优先标记让人工复查。这个思路很像把一个冗长文档拆开分给多个协作者每个人只负责一小块最后再由一个人汇总——可控性比单次大模型调用好太多。3. 把链接丢进去之后流水线内部到底做了什么3.1 输入与任务状态机用户只需要提供一个B站视频链接或者一个批量链接列表文件。程序启动后每个链接进入任务队列状态依次为待处理、解析中、下载中、转写中、结构化中、已完成任一步失败进入失败状态并可重试。这里有个我特别坚持的设计每一步的产物都要落盘。音频、分段文本、每段JSON、最终Markdown全部独立保存。这样即使跑到一半断电下次重跑也会从断点继续而不是把几十个视频从头再来过。3.2 下载音频音轨和采样率不能随便解析链接后程序调用社区常用的开源下载工具提取音频流并转为WAV格式。B站有些视频存在多音轨情况如果不指定音轨可能拿到没有讲解的伴奏轨转写结果就是一堆音乐和现场声。所以下载阶段强制指定含语音的轨道下载后统一检查采样率重采样到16kHz。这个16kHz不是随便定的语音识别模型大多按16kHz训练喂入更高采样率不会提高准确率反而增加计算量。另一个容易踩的坑B站部分视频需要登录凭证才能下载到高质量音轨未登录只能拿低码率背景一吵转写错误率直线上升。项目里预留了凭证配置入口使用时要留意请求频率控制不要高频调用避免触发平台风控。3.3 转写策略切分、并行、拼接长音频直接喂给模型一是容易在30分钟以后出现句尾丢失二是显存压力大。我的做法是先用静音检测把音频切成30到60秒的片段片段之间保留1秒重叠避免在音节中间切断导致语义丢失。切好的片段走并发转写队列GPU资源紧张时自动降低并发。转写完成后按原时间戳顺序拼接并记录每句话对应的起始时间。这里有个细节可以分享切分时不要直接均匀按秒切最好用静音检测来切。均匀切一刀可能正好把一句话从中间劈开模型根本没法猜后半句在说什么静音检测能基本保证切点落在停顿处转写质量明显更稳。3.4 清洗与结构化生成清洗阶段会做几件事删除明显的语气词和重复词、合并过短的句子、对常见技术术语做纠错替换。我维护了一份术语纠正表比如某些模型经常把某个框架名识别成常见普通词汇这种表可以在配置里自定义不同领域的用户能往里面加自己的词。结构化阶段采用两级聚合。第一级对每一段转写文本单独调用大模型输出片段级字段段落小标题、核心观点、出现的关键术语、值得摘录的句子。第二级把所有片段的结果汇总再次调用大模型生成全文章节结构与总览摘要。这里放一个参考提示词骨架实际项目里可以按需调整你是一名擅长整理技术视频内容纪要的助手。 输入是某视频片段转写文本请输出JSON { segment_summary: 不超过50字的片段概述, key_points: [要点1, 要点2], terms: [{term: 术语, explanation: 一句话解释}], quotes: [金句原文必须来自转写文本不得改写] } 注意不得补充转写中不存在的技术事实 如发现疑似识别错误在terms中额外标注需人工确认。这个提示词的关键在于“不得补充事实”和“金句必须来自原文”两条约束能大幅减少模型幻觉。3.5 输出长什么样最终输出的是一个Markdown文件结构大致如下# 视频标题 视频链接、总时长、转录耗时 ## 一、核心结论 ## 二、章节结构与时间索引 - 01:23 第一章背景与动机 - 12:40 第二章核心方案 - 25:16 第三章实现细节 ## 三、关键术语表 ## 四、金句摘录 ## 五、行动项带时间戳索引是非常有用的设计想回看原视频某段时直接按时间点跳转不用整片重播。4. “300倍”是怎么测出来的实测数据、计算口径与边界4.1 人工基线怎么测为了这个数字不被吐槽是拍脑袋我拉着几位同事做了一次小范围实测。选了三个不同类型的中长视频一个58分钟的技术分享、一个32分钟的软件教程、一个45分钟的行业讲座。每人用自己习惯的方式边看边记笔记整理成一份结构化笔记。结果是视频时长人工整理耗时58分钟技术分享约75-90分钟32分钟软件教程约40-50分钟45分钟行业讲座约55-70分钟可以看到“看视频20分钟整理笔记翻倍”其实是相当常见的比例。4.2 自动流水线耗时还是这三条视频走本地模型加两级结构化的完整流水线环境是普通工作站配一块中高端消费级GPU单条结果阶段耗时下载音频4-6秒语音转写58分钟视频约3-4分钟清洗结构化约10-20秒单条端到端大约3.5到4.5分钟相比人工的60到90分钟已经是20倍以上的提升。4.3 为什么批量场景能到300倍单条只有20倍为什么宣传口径是300倍因为实际使用中几乎不会一次只处理一个视频。当我一次性丢进10条视频时转写队列把GPU占满下载和转写、清洗和结构化在不同任务之间形成流水线重叠10条视频的总耗时从单条累加的40分钟压到约6分钟。另一边人工处理10条视频需要600分钟起步。600比6正好是100倍如果再把“后续检索回看”的时间算进去——有了结构化笔记找某句话从平均10分钟降到10秒以内——综合效率拉到300倍并不夸张。所以在项目文档里我特意写明300倍是批量场景加检索复用的综合口径单条视频通常只有20到50倍。不写清楚边界宣传数字反而会伤害项目可信度。5. 开发和实测里踩过的五个坑以及对应的处理方案5.1 音轨选错转写出“无声讲解”第一个版本上线后有次批量任务转写完发现大量文本是音乐描述和环境音。排查下来发现那个视频是多音轨下载工具默认选了“完整音轨”里面其实是伴奏。解决方式是在下载参数里强制指定含语音的轨道同时下载后做一次能量检测对长时间无语音的音频段直接标记告警。5.2 长音频不切分显存和准确率双重崩溃早期调试时直接拿60分钟音频喂模型运行到约第40分钟时程序崩溃重试后虽然跑完但后半段文本错误明显增多这就是“句尾丢失”现象。后来切成片段并加重叠后后半段质量恢复正常内存占用也稳定在一个可控范围。这个经历让我确认了切分策略不是优化项而是必选项。5.3 大模型会把识别错的名词“圆”回去转写阶段把某个框架名识别错了结构化阶段大模型没发现还顺着错误名词给出了一个合理的解释。这种幻觉很隐蔽不仔细核对根本发现不了。处理办法是在提示词里加“不得补充转写文本中不存在的技术事实”并单独增加一个“术语验证”环节把抽取出的术语列表和原始转写文本逐一对齐不一致的标为需人工确认。5.4 长文上下文的token限制结构化第一版实现是直接全文塞给模型很快就碰到上下文超限错误信息一波接一波重试后整个任务陷入死循环。后来改成两级聚合每一段的上下文都很短最后汇总时也只处理片段级摘要问题就消失了。这里要特别提醒不要迷信“模型上下文窗口大”就随手塞全文窗口大只是上限不是质量保证小任务小上下文输出质量通常更稳定。5.5 没有断点续传批量任务一崩全废一次处理20个视频跑到第18个崩溃又因为没有落盘全部重来。这个教训让我把“每一步产物都落盘”写成了项目铁律。现在每个任务都有独立的中间目录重新运行时自动跳过已完成步骤。对任何处理长耗时任务的工具来说这个设计都值得在一开始就做好而不是出问题后再补。6. 可以往哪些方向扩展从个人笔记到团队知识流水线6.1 定时增量处理订阅列表很多人其实有稳定的关注UP主列表。可以配置一个订阅清单定时检查新更新的视频自动把新内容转成结构化笔记。这样一个月下来你不需要打开B站也能持续积累一批可检索的笔记内容。对做技术追踪、行业调研的人来说这个用法比手动逐条跑更有长期价值。6.2 接入本地知识库生成的Markdown本身是结构化数据非常适合接入本地文档检索和向量化索引。笔记里的章节、术语、金句都带语义边界向量化效果比纯文本好。接入后可以做到用自然语言问一个问题返回对应的视频片段和时间点直接把被动记录升级为主动问答。6.3 双语对照与字幕增强有些视频我会需要双语对照文稿。流水线的中间产物也就是带时间戳的分段文本其实已经具备生成双语字幕的条件接一个翻译步骤就能输出带时间轴的双语文稿。同样可以生成标准字幕文件给本地播放器或剪辑工具用。这个扩展几乎没有额外成本因为转录的结构化中间产物都还在。最后聊一点个人体会。做这个项目最大的收获不是省了多少时间而是让我重新理解了“处理信息”和“消化信息”的边界。机器可以把一个小时的视频压缩成几百行字但它替你省下的不是“思考”这一步而是“找”和“翻”这些纯体力劳动。真正的学习还是得自己去读那份笔记去追问那些术语。我建议所有想用这类工具的人把它当成信息预处理而不是学习外包。批量跑完笔记之后抽半小时把关键章节读一遍效率才是真的高。
