我们最早只是想做一个顺手的网页录音页：打开浏览器，允许麦克风，然后一边说一边看到文字。真正开始使用以后，事情很快变复杂了。录音能不能暂停，结束后能不能接着录，临时识别结果为什么会反复变化，两小时的会议会不会把浏览器或 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 当实时字幕用。
如果说 Discourse 更像公开议事厅，ChatBlog 更像阶段性文章，MkDocs 更像项目手册，那么 Mattermost 更接近 ChatArch 目前缺的那一块：一个可以自托管、频道化、支持线程、适合人和 Agent 同处一室的实时工作间。
这篇文章回答三个问题：
这次把问题重新收窄：目标不是先找一个“会议笔记大平台”，而是要确认能不能稳定搭出这一条链路：
网页录音按钮 -> ASR 实时/准实时转文字 -> AI 纠错/摘要/会议纪要
这里的关键不是 UI 有多复杂，而是 ASR 是否足够成熟：中文识别、实时 partial/final、低延迟、长录音稳定性、标点断句、说话人、成本、以及能否安全接到浏览器。
本文只回答一个更具体的问题：如果要做“一个网页，点录音，实时出字，最后自动生成 AI 笔记”，应该先选哪个 ASR 路线？有没有现成项目已经打通整个流程？
录音转写看起来像一个单点能力：给一段音频，返回文字。真的要自建时，它会很快拆成几个完全不同的问题：谁负责录音或进会？是实时字幕还是会后处理？要不要说话人？要不要摘要、行动项和问答？要不要 API、权限、队列和搜索？
如果不先把这些产品形态分开，就很容易把 openai/whisper、faster-whisper、WhisperX、一个 Gradio WebUI、一个会议 bot、一个媒体库平台放进同一张表里比较，最后得到一堆“都能转写”的无效结论。
这篇只做静态调研，关注 GitHub 上可自建、可部署或可封装的项目，重点场景是录音转写、会议笔记和后续 ChatArch/Agent 工作流集成。
Discourse AI 不是“给论坛套一个聊天机器人”这么简单。更准确地说，它是一组嵌在 Discourse 里的 AI 能力：写作助手、AI Bot、语义搜索、相关话题、总结、垃圾信息检测、AI triage 和自动化报告。它适合增强 topic/comment 型社区，而不是替代 Mattermost、Discord 或 Slack 这类实时聊天入口。
这篇文章回答三个问题：Discourse AI 到底有什么功能？普通用户和管理员怎么用？我们在 ChatArch 这台自托管 Discourse 上实测到了什么？
“文件分享”至少有三种完全不同的产品：一种把 目录/文件名 直接变成 URL；一种上传后生成高熵临时链接；还有一种提供 S3 bucket/object API，接近七牛、MinIO 和对象存储。
如果不先把这三类分开，很容易一边比较极简文件服务器，一边又把完整 Web 产品和分布式对象存储拉进来，最后得到一个没有决策价值的功能总表。
这篇围绕 ChatShare 的第一阶段目标做静态调研：一个共享 Key、上传/下载 API、文件名或 object key 与 URL 明确关联、尽量轻量、不把账号体系和存储集群提前塞进来。
在上一篇 自托管 Dashboard 选型 里，我们把 Glance 归类为“信息聚合型 dashboard”：它既能放服务入口，也能看服务状态、服务器资源、RSS、天气、GitHub release、视频和社区信息。
但选中 Glance 之后，真正的问题才开始：它到底怎么加东西？一个服务应该用哪个 widget？RSS 能不能订阅多个来源？除了官方示例里的天气和 Hacker News，它还能放什么？
这篇就从实际配置出发回答这些问题。
当自托管服务从两三个变成十几个以后，最先失控的通常不是 Docker，而是入口：服务 URL 记不住、端口散落在书签里、手机上找不到常用页面、某个容器挂了也没有直观提醒。这类问题不一定需要上 Grafana，很多时候一个 startpage / homepage / dashboard 就够了。
这篇从 awesome-selfhosted 的 Personal Dashboards 分类里挑了五个最值得优先看的项目：Homepage by gethomepage、Homarr、Dashy、Homer 和 Glance。它们都能自托管，但解决的问题不完全一样。
这篇文章回答一个很容易混淆的问题：Discord 能不能像 Discourse 一样自建？如果不能，我们刚刚部署的 Revolt / Stoat 又是什么？
结论先说：官方 Discord 不能自建。它是 Discord 公司运营的 SaaS。我们能自建的是 Discord-like 替代品，例如 Stoat / Revolt、Mattermost、Rocket.Chat、Zulip、Matrix / Element 等。为了直观看一下 Discord-like 产品形态，我们在 ChatArch 服务器上部署了一个 Stoat / Revolt demo。