Decentralization? We're still early!
課 7 的 8
In Progress

第七课 主权个人专属的音视频转文章AI流水线

Brave 2026-03-09

请大家务必注意,限于篇幅,本文只介绍Brave基地的Trilium AI子插件Trilium Content Processor的实现方式。

关于youtube字幕、音视频获取的技术实现,还必须参考基地讨论《WP插件开发实战课:如何从零构建 YouTube 智能转录系统》,Trilium Content Processor插件需要相关技术作为后端。

同时,本节课程并未涉及,Brave唯二推荐的必装语音转文字应用分别是Handy和Buzz,Stacher7也是不错的yt-dlp开源前端。本教程的纯手工平替方案是基地讨论《如何用 Stacher、Buzz 和顶级 AI 将音视频精炼成深度长文》,更多宝藏可参考基地”收藏夹-利器“栏目,以及其他基地讨论。

第一部分:开发篇——理解这款插件的技术基底与设计智慧

一、为什么需要Trilium Content Processor:从信息到知识的最后一公里

此前,信息的「输入端」一直存在一个痛点:海量的音视频内容——播客、YouTube教程、会议录音、课堂讲座、个人语音备忘——它们承载着大量高密度的知识,却因为其非文本的本质,始终游离在Trilium知识库的结构化管理之外。

你可以用Miniflux聚合RSS文章,用Web Clipper裁剪网页内容,用Trilium WP将笔记发布为WordPress文章,用TriliumAI Chat进行AI对话并自动沉淀——但面对一段30分钟的YouTube视频或一份会议录音,你只能手动记笔记。这不仅效率低下,更违背了「让知识自动流动」的核心理念。

Trilium Content Processor(以下简称「处理器」)正是为解决这个问题而生。它的定位可以用一句话概括:将音视频内容自动转化为结构化文本,经AI智能整理后沉淀到Trilium知识库中。 它补全了Brave基地知识生产流水线中「音视频→文本→知识」这一关键缺失环节。

从技术栈的角度看,处理器的位置如下:

🎙️ 语音输入(录音/音频文件/YouTube视频)
        ↓
🔧 Trilium Content Processor(本插件)
   ├→ Speaches API(语音转文字)
   ├→ YouTube字幕提取 + 智能降级
   └→ TriliumAI(AI内容整理)
        ↓
📝 结构化文本笔记
        ↓
💾 自动保存至 Trilium Notes
        ↓
🧠 被 TriliumAI Chat 上下文功能调用

这意味着:你今天通过处理器转录并保存的一段YouTube视频内容,明天在TriliumAI Chat中开启上下文功能时,AI就能「记起」并引用这段内容。信息在你的个人知识生态中,实现了从音视频到可检索、可引用、可AI增强的结构化知识的完整闭环。


二、开发这样一款插件需要掌握哪些知识

如果你是一位开发者,想要理解这款插件的技术全貌,或者想要构建类似的系统,以下是你需要掌握的知识图谱。每一块知识的讲解不会止步于「是什么」,更重要的是帮你理解它在整个系统中「为什么被需要」以及「如何协同运作」。

1. WordPress插件开发基础 ⚙️

WordPress并非只是一个博客系统。在Brave基地的架构中,它被重新定义为「知识工作流编排平台」和「安全中间件」。开发处理器插件,你需要理解以下WordPress核心机制:

钩子系统(Hooks) 📎 是WordPress插件开发的基石。处理器通过 add_actionadd_filter 将自身的功能注入WordPress的生命周期。例如:

  • 通过 wp_enqueue_scripts 钩子在前端注入CSS和JavaScript资源
  • 通过 wp_ajax_* 钩子注册后端AJAX处理端点
  • 通过 admin_menu 钩子在后台添加设置页面

这种机制的精妙之处在于「松耦合」——插件不需要修改WordPress核心代码的一行,就能在恰当的时机执行自己的逻辑。这也是为什么处理器能够与Trilium WP主插件、TriliumAI Chat等兄弟插件和谐共存的原因。

Settings API ⚙️ 提供了一套标准化的方式来创建后台配置页面。处理器的设置页面涵盖了音频转录配置、YouTube处理配置、AI整理配置、Trilium保存配置等多个分区,每个配置项都通过WordPress的 register_settingadd_settings_sectionadd_settings_field 三级结构来声明和渲染。理解Settings API意味着你能快速构建出符合WordPress规范的、用户友好的配置界面。

AJAX通信机制 📡 是前后端交互的核心通道。由于音频转录、YouTube处理等操作耗时较长(几秒到几十秒不等),传统的表单提交-页面刷新模式完全无法满足需求。处理器通过WordPress的AJAX系统实现了:

  • 异步文件上传与逐个处理(多文件不阻塞)
  • 实时进度反馈(批量处理时尤为关键)
  • 语音录音的双模式异步提交
  • YouTube频道视频列表的动态获取

每一个AJAX端点都必须经过WordPress的 wp_verify_nonce 安全验证——这是防止跨站请求伪造(CSRF)攻击的第一道防线。同时,所有端点都检查用户权限(current_user_can('edit_posts')),确保只有有权限的用户才能触发处理操作。

短代码系统(Shortcodes) 📋 提供了一种将插件功能嵌入页面内容的方式。处理器注册了 [trilium_processor] 短代码,管理员只需在任意WordPress页面或文章中插入这一行标签,完整的内容处理界面就会自动渲染。相比Gutenberg编辑器块,短代码的优势在于兼容性——它适用于所有WordPress版本和编辑器(包括经典编辑器)。

2. PHP服务端编程与API集成 🔧

插件的PHP后端承担着系统最核心、最复杂的职责。它不仅是前端请求的路由器,更是一个连接多个外部服务的集成层。以下是你需要掌握的关键领域:

面向对象的模块化架构 🏗️ 处理器采用了清晰的类分离设计,每个PHP类承担独立的职责域:

  • class-frontend.php:负责所有前端界面的服务端渲染——选项卡导航、表单构建、状态栏渲染、语音录制区域、文件上传区域、YouTube处理区域、批量处理区域、以及结果展示。这个类的代码量最大,因为它需要生成丰富且响应式的HTML结构。
  • class-api-handler.php:封装了所有外部API的调用逻辑——Speaches语音转文字API、YouTube字幕提取API、YouTube音频下载、AI内容整理、Trilium ETAPI保存操作。每个方法都包含完善的错误处理和日志记录。
  • class-ajax-handler.php:处理所有前端AJAX请求的接收、验证和分发。它是前端JavaScript与后端处理逻辑之间的桥梁。
  • class-processor.php:核心处理引擎,编排了完整的处理流水线——从接收原始输入到最终保存结果的全过程。这个类体现了处理器最重要的架构决策。
  • class-settings.php:后台设置页面的完整实现,包括字段注册、渲染和验证。

这种分离的价值在于:你可以修改API调用逻辑(比如换一个语音识别服务)而不影响前端界面;也可以重新设计前端而不触及后端处理逻辑。对于一个需要长期维护和迭代的插件来说,这种架构选择是至关重要的。

HTTP客户端与API通信 🌐 处理器需要与多个外部服务进行HTTP通信。WordPress提供了 wp_remote_postwp_remote_get 作为HTTP客户端,但在大文件传输和流式下载场景下,插件做了额外的适配工作:

  • 音频文件上传到Speaches API时,使用 multipart/form-data 编码和 CURLFile 对象直接操作cURL句柄,以支持大文件的高效传输
  • YouTube音频下载采用流式写入——音频数据不会一次性加载到内存中,而是边下载边写入临时文件,这对处理长时间视频至关重要

文件系统操作与安全 📁 音频处理天然涉及大量文件I/O。处理器在这方面的实现体现了对安全和健壮性的关注:

  • 上传文件的MIME类型验证:不仅检查文件扩展名,还通过PHP的 finfo_file 进行内容检测
  • 临时文件的生命周期管理:处理完成后自动清理,避免服务器磁盘空间被逐渐消耗
  • 文件大小限制的动态检测:自动读取PHP配置中的 upload_max_filesizepost_max_size,取较小值作为实际限制,并在前端界面明确展示

错误处理与日志 📋 生产级插件与原型最大的区别往往体现在错误处理上。处理器的每一个API调用都被 try-catch 包裹,每一个可能失败的操作都有对应的降级策略和用户友好的错误提示。日志系统通过WordPress的 error_log 记录详细的调试信息,帮助排查线上问题。

3. JavaScript前端开发——让复杂流程变得简单 💻

处理器的前端面临一个独特的挑战:它需要在一个页面内编排多种完全不同的用户交互流程(音频上传、语音录制、YouTube单个处理、YouTube批量处理),每种流程都包含异步操作、状态变化和实时反馈。以下是关键的前端技术:

基于jQuery的事件驱动架构 🎯 处理器选择了jQuery作为前端基础库,这是一个务实的选择——WordPress本身就捆绑了jQuery,使用它不会引入额外的依赖。前端代码采用了立即执行函数表达式(IIFE)模式,所有逻辑封装在一个闭包中,避免全局命名空间污染。

核心交互逻辑包括:

  • 选项卡切换(音频上传 / YouTube转录 / YouTube批量处理)
  • 文件选择、验证、预览和多文件逐个上传
  • YouTube URL格式校验和动态按钮状态管理
  • 表单提交拦截和AJAX替代

MediaRecorder API——浏览器内录音 🎙️ 这是处理器最具技术含量的前端功能之一。voice-recorder.js 封装了一个完整的 TriliumVoiceRecorder 类,实现了:

  • 麦克风权限请求和兼容性检测
  • 基于 MediaRecorder API 的录音控制(开始、暂停、恢复、停止)
  • 实时录音时长计时器(感知暂停状态,暂停期间不计时)
  • 录音数据的 Blob 组装和文件创建
  • 录音完成后的双模式选择机制

这里有一个值得注意的设计细节:录音完成后,用户面前会弹出一个选择面板——「发送到AI聊天」还是「整理并保存到Trilium」。前者通过 window.TriliumAIChatAPI 将转录文本发送到TriliumAI Chat的聊天窗口,实现「语音提问AI」的流畅体验;后者则走标准的音频处理流程(转录 → AI整理 → 保存)。这种「一次录音,双路径选择」的设计,体现了对用户实际使用场景的细致洞察。

异步状态管理 ⏳ 在批量处理YouTube视频时,前端需要管理复杂的异步状态:获取视频列表 → 用户勾选 → 逐个处理 → 实时更新进度条 → 标记成功/失败/降级状态。处理器通过精心设计的DOM操作和CSS类切换来实现这一切——每个视频项目都有独立的状态标记,总体进度条实时反映处理百分比,当前处理的视频会高亮显示。

4. Speaches API集成——自托管语音识别的枢纽 🗣️

Speaches(原名 faster-whisper-server)是Brave基地语音技术栈的核心组件。理解它对于理解处理器的工作原理至关重要。

Speaches是什么? Speaches是一个兼容OpenAI Whisper API格式的自托管语音识别服务器。它的底层使用 faster-whisper(一个基于CTranslate2的高性能Whisper推理引擎),提供了与OpenAI Whisper API相同的接口格式,但完全运行在你自己的硬件上。

这意味着:

  • 所有语音数据都在本地处理,不会发送到任何第三方云服务 🔒
  • 没有按调用次数计费的成本压力 💰
  • 即使在没有互联网的环境下也能使用 📶
  • 可以选择不同规模的Whisper模型(tiny / base / small / medium / large)来平衡速度和准确性

API调用实现 🔗 处理器调用Speaches API的方式很直接——通过HTTP POST将音频文件以 multipart/form-data 格式发送到 Speaches 的 /v1/audio/transcriptions 端点,指定模型名称和响应格式。服务器返回转录后的纯文本。

在插件的具体实现中,调用逻辑被封装在 call_whisper_api 方法中,该方法处理了:

  • 构建正确的multipart请求体
  • 根据配置选择合适的Whisper模型
  • 设置合理的超时时间(音频转录可能耗时较长)
  • 解析并返回纯文本格式的转录结果
  • 完善的错误处理与状态码校验

模型选择策略 🧠 Speaches支持多种Whisper模型,处理器在设置页面提供了模型ID的配置项(默认为 Systran/faster-whisper-medium)。不同模型的权衡如下:

模型参数量速度准确性推荐场景
tiny39M极快 ⚡一般快速预览、测试
base74M很快尚可简短语音、清晰录音
small244M良好日常使用的平衡选择
medium769M中等优秀多语言、口音较重的内容
large-v31.5B较慢最佳 🏆专业级转录、噪声环境

5. YouTube内容获取——字幕提取与音频转录的双轨策略 📺

处理YouTube视频是处理器最复杂的功能模块,因为它需要处理多种不确定性:视频可能有字幕也可能没有,字幕可能是机器生成的也可能是人工上传的,音频可能很长也可能很短。

字幕提取(优先路径) 📝 当处理器收到一个YouTube URL时,它首先尝试通过专门的字幕提取API获取视频的文字内容。这是最快速、最经济的路径——字幕通常已经是现成的文本,无需耗费GPU资源进行语音识别。处理器支持用户指定语言偏好(中文 / 英文 / 自动检测),系统会优先寻找匹配的字幕轨道。

音频转录(降级路径) 🔄 当字幕提取失败时(视频无字幕、字幕不可用、API异常等),处理器不会简单地报错,而是启动「智能降级」机制:

  1. 自动下载视频的音频轨道
  2. 将音频发送到Speaches API进行转录
  3. 用转录结果替代字幕

这个降级过程对用户完全透明——界面上会显示一个温暖的黄色提示框,告知用户「字幕提取失败,已自动转为音频转录」,并附上降级原因和各阶段耗时统计。

这种「先快后准」的双轨策略是处理器架构设计中的一个亮点。它确保了:无论视频是否有字幕,用户最终都能得到文字内容。这在实际使用中极为重要——很多高质量的技术讲座、播客访谈恰恰是没有字幕的。

批量处理——YouTube频道级别的知识获取 📊 处理器还支持批量处理整个YouTube频道的视频。用户输入频道URL后,系统通过API获取视频列表(支持限制数量和日期过滤),以可勾选列表的形式展示。用户选择需要处理的视频后,点击「开始批量处理」,系统逐个处理每个视频,每完成一个就立即保存到Trilium,同时实时更新总体进度。

这个功能的价值在于:你可以一次性将一个教育频道或技术博主的数十个视频全部转化为Trilium笔记——想象一下,一个下午的自动处理就能把一年的视频内容变成你的结构化知识资产。

6. AI内容整理——从原始转录到知识条目 🤖

原始的语音转录文本往往杂乱无章——没有段落划分、充斥着口语化表达、缺乏结构化组织。如果直接保存到Trilium,它的检索和引用价值将大打折扣。

处理器在这里集成了AI整理功能(需要TriliumAI Chat插件的AI能力支持)。当管理员在后台开启「AI处理」选项后,转录完成的文本会先被发送到配置好的AI模型进行格式化整理,然后再保存到Trilium。

这个整理过程由 ai_process_content 方法实现,它构建了一个精心设计的系统提示词,指导AI将散乱的转录文本重组为结构清晰、段落分明、要点突出的笔记内容。整理后的文本保留了原始信息的完整性,但大幅提升了可读性和可检索性。

与TriliumAI Chat中的「智能格式化」功能类似,这里的AI整理任务也建议使用低成本的本地模型(如通过Ollama运行的小型LLM)来执行——这是纯粹的文本整理工作,不需要顶级推理能力,用本地模型可以将成本控制为零。

7. Trilium ETAPI集成——知识的最终归宿 💾

处理器的最终输出是Trilium Notes中的结构化笔记。它通过Trilium WP主插件提供的 trilium_api_request 函数(该函数封装了对Trilium ETAPI的调用)来创建笔记。

保存逻辑经过精心设计,体现了对知识管理实践的深入理解:

智能标题生成 🏷️ 笔记标题不是简单的文件名或时间戳。处理器会根据内容类型生成有意义的标题:

  • 音频文件:使用原始文件名(去除扩展名)
  • YouTube视频:使用视频原始标题
  • 语音录音:使用「语音录音 - 日期时间」格式

日期子文件夹归类 📅 当管理员配置了日期子文件夹功能时,笔记会自动保存到以当天日期命名的子文件夹中。这意味着你可以按时间线回溯——「上个月我转录了哪些内容?」一目了然。

内容格式构建 📝 保存到Trilium的笔记不仅包含转录/整理后的文本,还携带了丰富的元信息:

  • 来源类型(音频文件 / YouTube视频 / 语音录音)
  • 原始来源信息(文件名或YouTube URL和视频标题)
  • 处理时间和处理方式(字幕提取 / 音频转录 / 智能降级)
  • 使用的Whisper模型
  • 是否经过AI整理

这些元信息的价值在长期使用中会逐渐显现——当你积累了数百条转录笔记后,元信息能帮你快速定位来源、评估质量、分析使用模式。

8. 响应式前端设计——适配所有设备 📱

处理器的CSS文件(frontend.css)超过2000行,这个体量本身就说明了前端设计的复杂性。它需要:

  • 在桌面端提供完整的多选项卡界面,充分利用屏幕空间
  • 在平板端保持布局合理性,适当调整间距和字号
  • 在手机端重新组织布局(选项卡变为纵向排列、信息卡片变为单列、按钮变为全宽)

CSS使用了 @media 断点在 768px、480px 和 360px 三个阈值处进行自适应调整。配色方案采用了渐变背景和柔和的阴影来营造现代感,同时通过 @media (prefers-color-scheme: dark) 支持暗色模式。

一个特别值得注意的设计细节是「语音处理模态框」(voice-modal)——当用户停止录音后弹出的双模式选择界面。这个模态框在手机上会自动调整为全宽布局,选项按钮变为纵向堆叠,确保在小屏幕上也能轻松操作。


三、核心设计决策深度解析

前面的知识地图描绘了「需要什么技术」。这一节我们将深入几个关键的设计决策,理解开发者在面临多种选择时「为什么这样做」。

1. 智能降级:为什么不直接全部用音频转录? 🤔

一个自然的疑问是:既然Speaches API可以转录任何音频,为什么还要费力做字幕提取?直接全部走音频转录不是更简单吗?

答案涉及三个维度:

效率。 字幕提取通常在1-3秒内完成——它只是获取YouTube已有的文本数据。而音频转录需要先下载音频(可能几十MB),再进行语音识别(消耗GPU资源),一个30分钟的视频可能需要几分钟。对于有字幕的视频,走字幕提取路径意味着10倍以上的速度提升。

准确性。 人工上传的字幕通常比机器转录更准确,特别是在专业术语、人名、品牌名等方面。字幕提取能直接获取这些高质量文本。

资源消耗。 音频转录需要占用Speaches服务器的GPU资源。在批量处理场景下(比如一次处理50个视频),如果全部走音频转录,GPU将长时间满负载运行。智能降级确保只有真正需要的视频才消耗GPU资源,大幅提升了批量处理的整体效率。

但同时,开发者也深知——没有字幕的视频同样有价值。因此设计了无缝的降级机制,确保在效率优先的同时不牺牲覆盖范围。这种「先快后准,绝不放弃」的策略,是工程实践中经典的权衡智慧。

2. 录音的双模式选择:为什么要区分「聊天」和「整理」? 🎙️

语音录音完成后的双模式选择(发送到AI聊天 vs. 整理保存到Trilium)看似只是一个UI选项,实际上它对应着两种完全不同的使用意图:

聊天模式 适用于:你想用语音快速向AI提问。这时你需要的是将语音转为文本后直接发送到TriliumAI Chat的聊天窗口——速度是第一位的,文本不需要持久保存(AI的回复会被聊天系统管理)。实现上,这个模式通过 window.TriliumAIChatAPI.sendMessageToChat(text) 将转录文本直接推送到聊天输入框并自动发送。

整理模式 适用于:你在做会议记录、课堂笔记、或个人语音日记。这时你需要的是将语音转为文本后经AI整理、形成结构化笔记、保存到Trilium。速度可以稍慢,但产出质量更重要。实现上,这个模式将录音文件通过标准AJAX流程提交到后端,走完整的「转录 → AI整理 → 保存」流水线。

这两条路径共享相同的录音和转录基础设施,但在转录之后分道扬镳。这种设计避免了「一个功能试图满足所有场景」的常见陷阱,让每种使用意图都得到最佳的体验。

3. 系统资源监控与性能调优 📊

处理器的核心处理类 (class-processor.php) 中内置了一个 check_system_resources 方法,在处理大批量任务前自动检查系统资源状况。这是一个生产环境中不可或缺但经常被原型级项目忽略的功能。

处理器在设置页面还提供了性能优化建议区域,帮助管理员了解当前服务器配置是否能满足处理需求,并给出针对性的调优方向。


四、开发者的技术视野扩展

理解了处理器的技术全貌后,作为一个有追求的开发者,你还应该关注以下方向:

从Speaches到WhisperLiveKit——实时转录的未来 ⚡

处理器目前采用的是「录制→上传→转录」的离线模式。而Brave基地同时也在探索WhisperLiveKit——一个基于WebSocket的实时语音转录方案,能实现近乎实时的「说了就看到文字」的体验。

WhisperLiveKit的核心价值在于:

  • 超低延迟(通过Voice Activity Detection + 流式识别实现亚秒级响应)
  • 实时反馈(用户边说边看到转录文本,可以即时纠正和调整)
  • 长时间录制(基于分段处理,理论上没有时间限制)

在未来的版本中,处理器有可能从离线模式进化为离线+实时双模式——离线模式处理已有的音频文件和YouTube视频,实时模式支持会议直播转录和语音笔记。

从单插件到插件生态——WordPress的组合力量 🧩

处理器并不孤立存在。它与Trilium WP主插件、TriliumAI Chat、TriliumAI Agent形成了一个协同工作的插件生态:

  • 处理器产出的Trilium笔记 → 可被TriliumAI Chat的上下文功能调用
  • TriliumAI Agent的 /trilium search 命令 → 可搜索处理器保存的转录笔记
  • TriliumAI Chat的聊天记录 → 和处理器的转录记录 → 共同沉淀在Trilium的统一知识库中

这种插件间的协同是通过WordPress的钩子系统实现的——每个插件只关注自己的职责,通过标准接口与其他插件交换数据。如果你想在这个生态上扩展新功能(比如一个PDF文档处理器),你需要做的是:遵循相同的接口约定,输出到Trilium Notes的相同格式结构。

MCP(Model Context Protocol)的整合前景 🔮

AI领域正在兴起一个重要的标准——Model Context Protocol(MCP),它定义了AI模型与外部工具交互的标准化方式。未来,Speaches服务可以通过MCP被AI Agent直接调用——AI不仅能「思考」和「写作」,还能「听」和「说」。处理器作为语音处理的基础设施,在MCP生态中有着天然的位置。


第二部分:使用篇——从安装到构建你的内容处理流水线

五、准备工作与环境要求

1. 你需要准备什么 📋

必需基础设施:

  • 一个运行WordPress 5.0+的网站(推荐5.8+以获得最佳兼容性),PHP 7.0+
  • 一个自托管的Speaches服务实例——这是语音转文字功能的核心依赖。Speaches可以部署在与WordPress相同的服务器上,也可以部署在局域网内的独立GPU服务器上
  • Trilium WP主插件(已安装并启用)——处理器通过它提供的API函数将内容保存到Trilium Notes
  • 一个自托管的Trilium Notes实例(通过Trilium WP主插件配置好连接)

强烈推荐(解锁完整能力):

  • TriliumAI Chat插件——处理器的AI内容整理功能依赖它提供的AI能力(调用配置好的AI提供者)。没有它,转录文本将以原始形式保存,不经AI整理
  • 至少一个AI服务(Google Gemini / OpenAI兼容接口 / Ollama本地模型)——用于AI内容整理

推荐的服务器配置:

组件最低要求推荐配置
WordPress服务器1核/1GB2核/4GB
Speaches服务器CPU模式可用,但很慢NVIDIA GPU(至少6GB显存)
Trilium Notes1核/512MB2核/2GB
Ollama(可选)8GB内存16GB内存 + GPU

💡 如果你使用VPS部署,可以将所有服务运行在同一台服务器上。一台配备NVIDIA 3060(12GB显存)的服务器就能同时运行WordPress + Speaches + Trilium + Ollama的全栈环境。

2. Speaches服务的安装与配置 🔧

Speaches的部署非常简单,官方提供了Docker镜像,一行命令即可启动:

docker run -d \
  --name speaches \
  --gpus all \
  -p 8000:8000 \
  ghcr.io/speaches-ai/speaches:latest

启动后,Speaches服务会在 http://localhost:8000 提供OpenAI兼容的API接口。你可以通过访问 http://your-server:8000/docs 查看完整的API文档和Swagger UI。

如果没有GPU,Speaches也支持CPU模式运行,只是转录速度会显著下降。对于测试和轻度使用场景,CPU模式是可以接受的。

3. 安装Trilium Content Processor插件 📥

安装过程与标准WordPress插件完全相同:

  1. 确保Trilium WP主插件已安装并正常连接到Trilium Notes ✅
  2. 登录WordPress后台 → 「插件」 → 「安装插件」 → 「上传插件」
  3. 选择 trilium-speaches-3.9.4.zip 文件,点击「现在安装」
  4. 安装完成后点击「启用插件」

启用后,你会在后台「设置」菜单下看到一个新的「Trilium内容处理器」配置页面。同时,你可以在任意WordPress页面或文章中使用 [trilium_processor] 短代码来嵌入处理器界面。


六、后台配置详解

进入「设置」→「Trilium内容处理器」(或后台菜单中的对应入口),你会看到一个分区清晰的配置页面。

1. 音频转录设置 🎵

配置项说明推荐设置
Speaches API地址Speaches服务的完整URLhttp://your-server:8000(如在同一服务器则为 http://localhost:8000
Whisper模型ID使用哪个模型进行转录Systran/faster-whisper-medium(中等模型,平衡速度与准确性)
超时时间API调用的最大等待时间120秒(长音频需要更多时间)

💡 配置完成后,可以上传一个短小的测试音频来验证连通性。如果一切正常,你将在几秒内看到转录结果。

2. YouTube处理设置 📺

配置项说明推荐设置
YouTube字幕API地址字幕提取服务的URL根据你部署的字幕服务地址配置
默认字幕语言优先获取哪种语言的字幕zh(中文)或 auto(自动检测)
启用智能降级字幕失败时自动转为音频转录开启 ✅(强烈建议)

3. AI处理设置 🤖

配置项说明推荐设置
启用AI处理是否在保存前进行AI内容整理开启 ✅
AI处理服务使用哪个AI服务进行整理建议使用Ollama本地模型(零成本)

当AI处理开启后,每段转录文本在保存到Trilium之前,都会先经过AI的智能整理——分段、去除口语化表达、提取要点、添加结构。这一步骤能将「原始语音转录」的可用性提升一个量级。

4. Trilium保存设置 💾

配置项说明推荐设置
目标文件夹ID保存到Trilium的哪个文件夹在Trilium中创建专门的「内容转录」文件夹,复制其笔记ID
日期子文件夹按日期自动归类开启 ✅
包含元数据是否在笔记中记录来源信息开启 ✅

💡 建议在Trilium中创建如下文件夹结构来组织处理器的输出:

📁 内容转录
   ├── 📁 音频文件
   ├── 📁 YouTube视频
   └── 📁 语音笔记

5. 状态栏——一目了然的系统健康状态 ✅

配置页面底部有一个状态栏,实时展示各个依赖服务的连接状态:

  • Trilium保存:✓ 连接正常 / ✗ 连接失败
  • AI整理:✓ 已启用 / ✗ 未启用或不可用
  • 当前模型:显示正在使用的Whisper模型名称
  • 文件大小限制:显示服务器允许的最大上传文件大小

如果某项显示为 ✗,点击旁边的「设置」链接可以直接跳转到对应的配置区域进行排查。


七、日常使用:三大核心功能详解

[trilium_processor] 短代码插入到一个WordPress页面后发布,访问该页面你会看到处理器的完整界面。顶部是三个选项卡——「音频转录」「YouTube转录」「YouTube批量处理」。

1. 音频转录——让录音变成知识 🎵

在线语音录制 🎙️

页面顶部是一个醒目的录音区域,蓝色渐变背景配以麦克风图标。操作流程:

  1. 点击「开始录音」按钮——浏览器会请求麦克风权限(首次使用时),授权后按钮变为红色「停止录音」状态
  2. 录音过程中,你会看到一个脉冲动画的红色指示器和实时计时器
  3. 长按可暂停录音(按钮变为黄色「继续录音」状态),暂停期间计时器暂停
  4. 点击「停止录音」——弹出双模式选择面板:
    • 🗣️ 「发送到AI聊天」——录音被转录为文本后直接发送到TriliumAI Chat聊天窗口,你可以立即开始基于语音内容的AI对话
    • 📝 「整理并保存」——录音经完整处理流水线(转录 → AI整理 → 保存到Trilium),最终成为一条结构化笔记

💡 录音支持任意时长,不受时间限制。但建议单次录音控制在合理范围内(如30分钟以内),以确保转录质量和处理速度。

💡 如果转录过程中出现错误,处理器会自动提供录音文件的下载链接,确保你的录音不会丢失。

文件上传 📂

录音区域下方是文件上传区域(两者之间有「或」分隔线)。支持多文件同时选择:

  1. 点击文件选择框,选择一个或多个音频文件
  2. 支持的格式:WAV、MP3、M4A、FLAC、OGG、AAC、WMA、WebM
  3. 选择后会显示文件预览列表(文件名和大小)
  4. 点击「开始转录」按钮

如果选择了多个文件,处理器会逐个处理——每完成一个文件,立即显示该文件的结果(包括转录文本预览和处理耗时),然后自动开始下一个。这种「边处理边保存」的设计意味着:即使第5个文件处理失败,前4个文件的结果已经安全地保存在Trilium中了。

2. YouTube单视频转录——一键获取视频精华 📺

切换到「YouTube转录」选项卡:

  1. 在输入框中粘贴YouTube视频链接(支持标准URL和短链接格式)
  2. 选择字幕语言偏好:
    • 🇨🇳 中文——优先获取中文字幕
    • 🇬🇧 English——优先获取英文字幕
    • 🌍 自动检测——系统自动选择可用的字幕
  3. 点击「开始智能转录」

处理过程透明可见:

  • 首先尝试字幕提取(状态提示:「正在获取字幕...」)
  • 如果成功 → 直接显示结果,附上「处理方式:✅ 字幕提取成功」和字幕语言信息
  • 如果失败 → 自动启动音频转录降级,状态提示切换为「字幕提取失败,正在下载音频...」→「正在转录音频...」

最终结果会显示:

  • 视频标题和来源链接
  • 处理方式和各阶段耗时统计(字幕尝试时间 / 音频下载时间 / 音频转录时间 / AI整理时间)
  • 转录/整理后的文本内容预览
  • 保存状态:✅ 已保存到Trilium

3. YouTube批量处理——频道级知识获取 📊

切换到「YouTube批量处理」选项卡:

  1. 输入YouTube频道URL(格式如 https://www.youtube.com/@username
  2. 设置筛选条件:
    • 视频数量上限:10 / 20 / 50 / 100
    • 日期过滤(可选):只处理某个日期之后的视频
  3. 点击「获取视频列表」

系统会加载频道信息和视频列表。每个视频以卡片形式展示,包含标题、发布时间和一个勾选框。你可以:

  • 点击「全选」一次勾选所有视频 ✅
  • 点击「取消全选」清除所有勾选 ❌
  • 手动勾选/取消勾选个别视频

选择完成后,点击「开始批量处理」。系统进入批量处理模式:

  • 顶部显示总体进度条和统计面板(总计 / 成功 / 降级 / 失败 / 待处理)
  • 当前正在处理的视频高亮显示
  • 每完成一个视频,实时更新统计和进度
  • 每个视频的处理结果(成功/降级/失败)即时标记

💡 批量处理的每个视频都独立执行——一个视频的失败不会影响其他视频的处理。

💡 批量处理可能需要较长时间(取决于视频数量和字幕可用性)。建议在非高峰时段执行大批量处理,以避免占用过多服务器资源。


八、进阶使用技巧与最佳实践

1. 建立你的内容转录工作流 📋

研究者的工作流

  1. 发现有价值的YouTube讲座或播客 → 使用单视频转录获取文字
  2. 开启AI整理,让转录内容变成结构化研究笔记
  3. 在TriliumAI Chat中开启上下文,引用转录笔记进行深度分析
  4. /trilium research 命令综合多条转录笔记,生成主题报告

教育者的工作流

  1. 录制课堂讲解(使用在线录音功能)→ 选择「整理并保存」
  2. AI自动将口语化讲解整理为书面化课程笔记
  3. 通过Trilium WP将整理后的笔记发布为WordPress课程页面
  4. 学生可以通过网页访问课程文字版(替代/补充视频)

内容创作者的工作流

  1. 批量转录目标领域的YouTube频道(获取素材)
  2. 在TriliumAI Chat中用上下文功能综合这些素材
  3. 通过Gutenberg提示词块编排「素材→提炼→成文」的工作流
  4. 产出的文章自动保存到Trilium,形成内容资产

2. 模型选择策略 🧠

使用场景推荐Whisper模型理由
大量短音频快速转录tiny 或 base速度优先 ⚡
日常使用(中英混合)medium最佳平衡点
专业讲座、学术内容large-v3准确性优先 🎯
批量YouTube处理medium兼顾速度和质量
有口音或噪声环境large-v3更强的鲁棒性

3. 性能优化建议 ⚡

  • 如果Speaches和WordPress部署在同一台服务器上,使用 localhost 地址可以避免网络延迟
  • 批量处理YouTube频道时,优先选择有字幕的频道——可以大幅减少GPU占用
  • 定期检查Trilium中转录笔记的文件夹大小,避免笔记数量过多影响Trilium的搜索性能
  • 如果GPU资源有限,可以在Speaches中配置请求队列,避免多个转录任务同时争抢GPU

4. 与Trilium AI生态的深度整合 🔗

处理器真正的威力在于它不是一个孤立的转录工具,而是Trilium AI知识生产流水线的有机组成部分:

转录 → 上下文循环 🔄 你今天转录的一段技术讲座,明天就能在TriliumAI Chat的上下文中被AI引用。随着转录笔记的积累,AI对你所关注领域的「理解」越来越深——这是一个知识增值的正反馈循环。

转录 → 研究综合 🔬 通过 /trilium research 命令,AI可以综合你转录的多个不同来源的内容,发现跨视频、跨讲者的共通观点和差异——这是手动做笔记时很难实现的。

转录 → Gutenberg工作流 🏗️ 你可以创建一个Gutenberg提示词块:「请基于以下转录内容提炼三个核心观点,并给出你的批判性分析:{转录内容}」。配合处理器的输出,这构成了一条从「听」到「分析」的自动化流水线。


九、故障排查

常见问题速查 🛠️

现象可能原因解决方案
转录结果为空Speaches服务未启动 / 模型未加载检查Speaches服务状态 → 确认模型已下载
上传失败「文件太大」PHP的upload_max_filesize限制修改php.ini中的 upload_max_filesizepost_max_size
YouTube字幕获取失败字幕API不可达 / 视频无字幕检查API地址 → 系统会自动降级到音频转录
音频转录极慢Speaches在CPU模式运行 / 使用了过大的模型确认GPU被正确识别 → 降级到smaller模型
保存到Trilium失败Trilium WP未配置 / Token过期 / 文件夹ID错误检查Trilium WP主插件设置 → 验证ETAPI Token
录音无法开始浏览器未授权麦克风 / HTTPS未配置检查浏览器权限设置 → 确保网站使用HTTPS
AI整理功能无效TriliumAI Chat未安装 / AI提供者未配置安装TriliumAI Chat → 配置至少一个AI服务
批量处理中途停止PHP执行时间超限 / 内存不足增大 max_execution_time → 减少单批处理数量

💡 处理器在处理过程中会输出详细的日志信息。启用WordPress的 WP_DEBUG 模式(在 wp-config.php 中设置 define('WP_DEBUG', true))可以查看完整的调试日志,帮助定位问题。


十、更大的图景与进阶路径

1. 处理器在主权个人技术栈中的位置 🌍

把处理器放到Brave基地正在构建的完整生态中来看:

📡 信息输入层
   ├── RSS聚合(Miniflux)→ 文章类内容
   ├── Web Clipper → 网页内容
   ├── 手动笔记 → 个人思考
   └── 🔊 Trilium Content Processor → 音视频内容 ← 你在这里
           ↓
📦 知识存储层:Trilium Notes(统一存储,ETAPI开放接口)
           ↓
🔗 知识连接层:Trilium WP(WordPress ↔ Trilium 双向通道)
           ↓
🧠 智能处理层
   ├── TriliumAI Chat(AI对话、上下文、工作流编排)
   └── TriliumAI Agent(笔记搜索、分析、综合研究)
           ↓
📤 知识输出层:WordPress发布 → Gutenberg工作流 → 社区分享
           ↓
🔄 自动化层:n8n(连接所有环节,实现自动化管道)

处理器填补了信息输入层最后一个关键空白——音视频内容的自动化获取与转化。有了它,你的Trilium知识库真正成为了一个「全媒体知识容器」,不再有任何类型的内容被遗漏在外。

2. 从使用者到构建者的进阶 🚀

使用者的进阶

  • 建立定期转录的习惯——每周将本周接触的重要音视频内容集中转录到Trilium
  • 利用批量处理功能,系统性地归档你关注的YouTube频道
  • 在TriliumAI Chat中实践「转录 → 上下文引用 → 深度分析」的完整工作流
  • 创建专门的Gutenberg提示词块,设计「转录内容分析」工作流模板

开发者的进阶

  • 研究处理器的源码架构——特别关注API Handler层的设计模式和Frontend类的服务端渲染策略
  • 尝试扩展处理器的能力:比如添加PDF文档处理、网页正文提取等新的内容类型
  • 探索将WhisperLiveKit实时转录功能集成到处理器中,实现离线+实时双模式
  • 研究如何通过WordPress的Filter Hook为处理器添加自定义的后处理管道

知识工作者的进阶

  • 将处理器纳入你的HEAT × PDCA操作系统——在「Habit」层面建立定期转录和整理的习惯
  • 关注Brave基地关于「主权个人」的系列课程和讨论——理解音视频转录在知识自治中的位置
  • 探索n8n与处理器的联动——比如监控特定YouTube频道的新视频,自动触发转录流水线

结语:让每一段声音都成为知识的种子

在信息过载的时代,真正的稀缺不是信息本身,而是将信息转化为个人知识的能力。播客里那段精彩的行业分析、YouTube上那个深度的技术讲座、会议中那些灵光一现的讨论——如果不能被捕获、结构化、纳入你的知识体系,它们就只是「听过就忘」的噪音。

Trilium Content Processor做的事情看似简单——把声音变成文字。但当这个过程被嵌入到Brave基地的完整知识生产流水线中,它的价值发生了质变:

  • 声音不再是转瞬即逝的波形,而是可检索、可引用的文本笔记 📝
  • 笔记不再是孤立的记录,而是AI可以理解和综合分析的知识原料 🧠
  • 知识不再是被动的存储,而是在「人→笔记→AI→人」的循环中不断增值的活资产 🔄

正如Brave基地所践行的「主权个人掌控AI」理念——处理器确保了这一切都发生在你自己控制的基础设施上:Speaches运行在你的服务器上,Trilium Notes存储在你的磁盘上,AI整理使用你自己部署的模型。没有任何第三方可以访问你转录的内容,你的知识资产始终归你所有。

这款插件是通向「让每一段有价值的声音都成为知识种子」这一愿景的一块扎实的基石。


参考资料:

回复