我们最早只是想做一个顺手的网页录音页：打开浏览器，允许麦克风，然后一边说一边看到文字。真正开始使用以后，事情很快变复杂了。录音能不能暂停，结束后能不能接着录，临时识别结果为什么会反复变化，两小时的会议会不会把浏览器或 GPU 撑满，这些都比“接一个语音模型”更接近真实问题。
现在这套网站放在 speakr.public.wzhecnu.cn。页面中文名仍是“声笺”，代码来自我们持续改造的 Qwen Audio Demo 仓库。它目前有三个相互独立的工作区：会议记录、声音工作室和实时对话。
这里的 Speakr 指 ChatArch 当前部署的这套语音工作台，并不是把同名开源项目原样部署后换了一个页面。
前两篇文章先做了大地图：录音转写与会议笔记自建选型 负责区分会议 bot、录音文件后台、字幕工具和 ASR 底座；网页录音到 AI 纪要 负责把需求拆成网页录音、成熟 ASR 和 AI 后处理三层。
这篇只补一个实操问题：如果先部署 Speakr，用户录完音以后，文字和 AI 纪要到底在哪里？
结论先说清楚：Speakr 不是“边说边实时出字”的字幕工具。它更像一个自托管的录音/上传后台：
录音 / 上传音频
-> 点击上传进入后台任务
-> ASR 生成 Transcription
-> LLM 基于 transcript 生成 Summary / Minutes
-> 在 recording detail 里查看和导出
如果你期待的是打开网页、点录音、一边说一边看到 partial transcript，那应该换 Deepgram、AssemblyAI、Azure Speech、OpenAI Realtime、FunASR streaming、sherpa-onnx streaming、WhisperLive 这类实时 ASR 路线，而不是继续把 Speakr 当实时字幕用。
这次把问题重新收窄：目标不是先找一个“会议笔记大平台”，而是要确认能不能稳定搭出这一条链路：
网页录音按钮 -> ASR 实时/准实时转文字 -> AI 纠错/摘要/会议纪要
这里的关键不是 UI 有多复杂，而是 ASR 是否足够成熟：中文识别、实时 partial/final、低延迟、长录音稳定性、标点断句、说话人、成本、以及能否安全接到浏览器。
本文只回答一个更具体的问题：如果要做“一个网页，点录音，实时出字，最后自动生成 AI 笔记”，应该先选哪个 ASR 路线？有没有现成项目已经打通整个流程？
录音转写看起来像一个单点能力：给一段音频，返回文字。真的要自建时，它会很快拆成几个完全不同的问题：谁负责录音或进会？是实时字幕还是会后处理？要不要说话人？要不要摘要、行动项和问答？要不要 API、权限、队列和搜索？
如果不先把这些产品形态分开，就很容易把 openai/whisper、faster-whisper、WhisperX、一个 Gradio WebUI、一个会议 bot、一个媒体库平台放进同一张表里比较，最后得到一堆“都能转写”的无效结论。
这篇只做静态调研，关注 GitHub 上可自建、可部署或可封装的项目，重点场景是录音转写、会议笔记和后续 ChatArch/Agent 工作流集成。