跳到主要内容

网页录音到 AI 纪要：先选成熟 ASR，再看现成产品

· 阅读需 14 分钟

这次把问题重新收窄：目标不是先找一个“会议笔记大平台”，而是要确认能不能稳定搭出这一条链路：

网页录音按钮 -> ASR 实时/准实时转文字 -> AI 纠错/摘要/会议纪要

这里的关键不是 UI 有多复杂，而是 ASR 是否足够成熟：中文识别、实时 partial/final、低延迟、长录音稳定性、标点断句、说话人、成本、以及能否安全接到浏览器。

同主题前情

本文只回答一个更具体的问题：如果要做“一个网页，点录音，实时出字，最后自动生成 AI 笔记”，应该先选哪个 ASR 路线？有没有现成项目已经打通整个流程？

一句话结论

先不要从论文列表或低星 demo 开始。第一轮应该同时看两条线：

  1. 成熟 ASR 线：最快试 Deepgram / AssemblyAI / Azure Speech / OpenAI Realtime / 国内云 ASR；如果要自托管，再测 FunASR、sherpa-onnx、WhisperLive、faster-whisper / whisper.cpp。
  2. 现成产品线：优先看 Speakr，它最接近“自托管网页录音 + 可插拔 ASR + 自动总结/聊天/导出”；Scriberr 次之；Meetily / Minutes / Muesli / Natively 更像桌面会议助手，不是网页按钮产品。
证据口径

快照时间为 2026-08-09 CST。本文参考 GitHub repo 元信息、README 自述和官方 starter/sample；stars 只作为“是否值得纳入第一轮”的热度信号，不等于质量结论。像 awesome-speech-recognition-speech-synthesis-papers 这类列表是论文/技术路线地图，不是可直接部署的工程清单。

网页录音到 AI 纪要主流架构

原创架构图：一颗网页录音按钮先进入成熟 ASR，再把 transcript 交给 AI 做实时纠错、术语修正、总结和纪要。

先把 ASR 和“完整产品”分开​

ASR 是 Automatic Speech Recognition，也就是“语音转文字”。它只负责把音频变成 transcript：

音频 -> ASR -> 文本

AI 纪要是下一层：

文本 -> LLM -> 摘要 / 行动项 / 会议纪要 / 纠错 / 术语统一

所以这件事应该分两路推进：

路线要回答的问题代表候选
ASR 主线哪个 ASR 最成熟、效果最好、最适合网页实时输入？Deepgram、AssemblyAI、Azure Speech、OpenAI Realtime、FunASR、sherpa-onnx、WhisperLive、faster-whisper、whisper.cpp
成品项目线有没有已经把录音、转写、总结、搜索/导出串起来的项目？Speakr、Scriberr、Meetily、Minutes、Muesli、Natively、call.md

如果成品项目已经足够接近需求，就优先改成品；如果成品项目都偏桌面、偏上传、偏 meeting bot，再回到 ASR 主线，自己包一个薄网页。

你发的 Awesome ASR 列表怎么用​

zzw922cn/awesome-speech-recognition-speech-synthesis-papers 我拉下来读了：它大约 681 行，结构是 Text to Audio、Automatic Speech Recognition、Speaker Verification、Voice Conversion、Speech Synthesis 等论文入口。

它的价值在于帮我们理解 ASR 的上游技术路线，比如：

  • CTC；
  • neural transducer / online transducer；
  • wav2vec；
  • Conformer；
  • Whisper 论文；
  • online / streaming ASR 相关论文。

但它不是工程选型清单。比如它不会系统列出今天真正要部署的工程项目：FunASR、sherpa-onnx、WhisperLive、faster-whisper、Deepgram starter、AssemblyAI browser example、Azure Speech JS SDK 等。

因此正确用法是：

Awesome papers
  -> 理解 ASR 技术路线
  -> 顺着模型/论文找 runtime/toolkit/provider
  -> 再看它能不能接网页实时音频

不能停在 papers；落地要看 SDK、WebSocket、runtime、服务化能力和中文效果。

路线一：成熟 ASR API，最快做出网页实时字幕​

如果目标是快速验证产品体验，第一阶段最现实的是：

自建网页
  -> 后端签发临时 token / session
  -> 浏览器把麦克风音频送到 ASR provider
  -> 页面显示 partial / final transcript
  -> 停止后把 final transcript 给 LLM 总结

主候选如下：

优先级方案为什么放第一轮适合场景注意点
1Deepgram Next.js Live Transcription官方 Next.js live transcription starter；就是网页实时转写形态最快做 MVP：网页按钮、实时字幕、后续 AI notes绑定 Deepgram；需要测中文、费用、稳定性；生产不能暴露 API key
2AssemblyAI realtime browser JS example官方浏览器 JavaScript WebSocket 示例；最小流程直观看清 browser microphone -> WebSocket -> transcript 的代码长期 key 不能放前端；要做 backend broker / 临时 token
3Azure Speech SDK Samples + JS SDK企业云 SDK 成熟，浏览器 JS 支持完整中文、多语言、企业稳定性、云厂商 SLA示例不是产品；要后端签发 token，不能前端放 subscription key
4OpenAI Realtime Console官方 Realtime API 调试/构建 React app；容易把语音和 LLM 统一如果实时转写、实时纠错、AI 反馈都想走 OpenAI 生态它不是传统纯 ASR；需要裁剪成单按钮录音页
5Amazon / Google / Gladia / Speechmatics / 国内云 ASR多数都有 streaming STT 或实时语音识别能力当合规、地域、中文价格、企业账号是关键约束GitHub starter 不一定强；要自己写 provider adapter

这一条线的优点是：ASR 成熟度高，网页层很薄，能最快验证真实体验。

它的代价是：会依赖外部 provider，必须认真处理费用、key 安全、网络延迟、数据合规和 provider lock-in。

路线二：自托管 ASR，自己掌握模型和数据​

如果不想把音频发给外部 ASR provider，就走自托管 ASR。这个方向要看 runtime/toolkit，而不是只看论文。

优先级项目工程定位为什么值得看注意点
1modelscope/FunASR开源 ASR toolkit；README 明确覆盖 offline、streaming、edge、VAD、punctuation、speaker pipelines、OpenAI-compatible serving中文场景优先级最高之一；转写、VAD、标点、说话人链路比较完整需要实际部署测试模型、GPU/CPU、并发、中文会议噪声
2k2-fsa/sherpa-onnxONNX runtime ASR/TTS/diarization/VAD；支持 streaming/non-streaming、WebSocket、Android/iOS/嵌入式/服务器适合离线、端侧、内网、自托管和多平台工程能力强但产品壳要自己做；模型选择和效果要测
3collabora/WhisperLivenearly-live Whisper 应用；支持 microphone、pre-recorded audio、WebSocket/clients比裸 Whisper 更接近实时服务Whisper 系做实时 partial 需要权衡延迟和准确率
4SYSTRAN/faster-whisperCTranslate2 版 Whisper 推理；README 自述比 openai/whisper 更快、更省内存适合做高效批量/准实时 Whisper 服务底座本身不是完整网页实时产品；服务化和 streaming 要自己封装
5ggml-org/whisper.cppC/C++ Whisper runtime；CPU/端侧友好，有实时麦克风示例轻量、部署面广、本地/边缘设备友好官方实时示例较朴素；生产 Web 服务仍要自建
6alphacep/vosk-api、wenet-e2e/wenet、espnet/espnet、kaldi-asr/kaldi、NVIDIA NeMo、SpeechBrainASR toolkit / research / production base适合深入工程或研究评估对“先做网页按钮产品”来说不是最快路径

自托管 ASR 的优势是数据和成本可控；缺点是你要自己维护模型、资源、GPU/CPU、并发、实时性和服务稳定性。

如果中文是第一优先，我会先测 FunASR 和 sherpa-onnx；如果要沿 Whisper 生态走，再测 WhisperLive / faster-whisper / whisper.cpp。

路线三：现成产品项目，先看有没有已经打通​

除了 ASR 本身，还要看有没有项目已经做了这条产品链：

录音 / 上传 -> ASR -> speaker / transcript -> summary / chat / export

这一轮最值得认真看的不是低星 PWA demo，而是这些：

优先级项目它打通了什么和当前需求的差距
1Speakr自托管网页应用；README 明确说 in-app recordings 会在录制中 stream 到服务器，支持自托管 WhisperX、OpenAI、Mistral/Voxtral、AssemblyAI 或 custom ASR；有 summaries、event extraction、per-recording chat、exports最接近“自建网页录音 + ASR + AI 笔记”。需要确认 live subtitle UI 是否满足需求；否则可作为后端/产品壳改造
2Scriberr自托管 AI audio transcription；有内置 audio recorder、speaker diarization、Chat with your Audio、summaries，支持 Ollama / OpenAI-compatible provider更偏录音/上传后的管理与聊天，不一定是实时字幕优先
3Meetily高星自托管/本地会议助手；描述包含 Parakeet/Whisper live transcription、speaker diarization、Ollama summarization更偏 macOS/Windows 桌面会议助手，不是手机网页按钮入口
4Minutes本地 conversation memory；录音、Whisper、本地 Markdown、AI 客户端/MCP 工作流很适合“会议记忆层”，但不是普通网页/PWA 产品
5MueslimacOS 本地 dictation + meeting transcription；live transcript、meeting export、summary强桌面路线；不解决手机网页入口
6Natively、call.md实时会议助手、录音、转写、AI 建议/总结更偏桌面/会议中助手或 agent loop，和“网页录音按钮”不同
对照Vexa、screenpipe、WhishperVexa 是 meeting bot；screenpipe 是桌面全天候记录；Whishper 主要是上传文件转写，浏览器录音仍在 TODO都不是第一版网页按钮方案

这里的初步判断是：

如果要先试“现成产品”，Speakr 最值得第一优先实测。它不是纯实时字幕 demo，但它已经把自托管网页、长录音、可插拔 ASR、总结、聊天、导出这些产品能力串起来了。

如果 Speakr 的实时字幕体验不足，再把它降级为产品壳参考，回到 Deepgram / AssemblyAI / Azure / FunASR / sherpa-onnx 的 ASR 主线自己搭前端。

AI 可以在实时转文字过程中做什么​

AI 不一定只在录音结束后总结。更好的链路是两层 AI：

实时层：partial transcript -> 轻量纠错 / 术语替换 / 标点补全 / 段落提示
结束层：final transcript -> 摘要 / 纪要 / 行动项 / 待办 / 标签 / 搜索索引

但要注意：实时层不能随意改 ASR 原文。产品里最好同时保留：

  1. ASR 原始 transcript；
  2. AI 修订后的 readable transcript；
  3. AI notes / summary；
  4. 每段 transcript 的时间戳和来源 provider。

这样后面可以回放、纠错、审计，也方便替换 ASR provider。

推荐的验证顺序​

我会按下面顺序推进，而不是再泛泛搜“录音转写项目”：

第一步：实测成品线​

先看 Speakr：

  • 能不能一条命令或 Docker 跑起来；
  • 浏览器里能不能录音；
  • 录音是否边录边上传到服务器；
  • ASR backend 能否切到 OpenAI / AssemblyAI / custom；
  • 是否自动生成 summary / chat / export；
  • 是否能加 live transcript UI。

如果 Speakr 不合适，再看 Scriberr；如果两者都不满足实时网页入口，就不再纠结成品壳。

第二步：实测外部 ASR provider​

并行做一个极薄 demo：

网页 Start 按钮
  -> Deepgram 或 AssemblyAI realtime
  -> partial/final transcript
  -> stop 后 OpenAI / Claude / Qwen 总结

这个 demo 不是最终产品，而是用来测：中文、延迟、断句、标点、噪声、成本和移动端浏览器兼容性。

第三步：实测自托管 ASR​

如果外部 API 的成本/隐私/合规不满意，再测：

  1. FunASR：中文和全链路能力；
  2. sherpa-onnx：离线/端侧/内网/实时；
  3. WhisperLive：Whisper 近实时服务；
  4. faster-whisper / whisper.cpp：自建 Whisper 底座。

第四步：统一产品接口​

无论选哪个 ASR，产品里都统一成一个事件协议：

type TranscriptEvent =
  | { type: 'partial'; text: string; startMs?: number; endMs?: number; provider: string }
  | { type: 'final'; text: string; startMs?: number; endMs?: number; provider: string }
  | { type: 'correction'; original: string; revised: string; reason?: string }
  | { type: 'error'; message: string; provider?: string }

这样后面可以替换 Deepgram、AssemblyAI、Azure、FunASR 或 sherpa-onnx，而不用重写 UI 和笔记层。

最终判断​

这次的主线应该是：

先确认成熟 ASR，再看有没有现成产品能复用；如果成品项目不满足实时网页入口，就自己做一层薄网页。

我现在的排序是：

  1. 先实测 Speakr：它最接近“网页录音 + 可插拔 ASR + AI 总结/聊天/导出”的成品路线。
  2. 并行实测 Deepgram / AssemblyAI：它们最适合验证“网页按钮实时字幕”的 ASR 路线。
  3. 中文/自托管重点测 FunASR 和 sherpa-onnx：如果要把 ASR 掌握在自己服务器或内网，这两个比单纯看 Whisper 更值得优先试。
  4. WhisperLive / faster-whisper / whisper.cpp 作为 Whisper 自托管路线：适合长期底座，不一定是第一版最快方案。
  5. Meetily / Minutes / Muesli / Natively 作为桌面会议助手参考：它们证明“录音转写 + AI 纪要”很成熟，但不直接满足手机/网页按钮入口。

所以不是“没有成熟项目”，而是成熟能力分布在两层：

ASR 成熟能力：Deepgram / AssemblyAI / Azure / FunASR / sherpa-onnx / Whisper 系
产品成品能力：Speakr / Scriberr / Meetily / Minutes 等

最稳的落地方式，是先用这些成熟 ASR 和成品项目做实测筛选，再决定是改 Speakr，还是自己搭一个薄网页产品。

资料入口​

ASR 论文/技术路线​

外部 ASR / 官方网页实时示例​

自托管 ASR runtime / toolkit​

已串起录音转写和 AI 笔记的项目​