Conversationaly 是一款隐私优先的 AI 会议助手桌面应用，支持 macOS、Windows 和 Linux。它能够录制麦克风和系统音频，实时转写会议内容，并自动生成会议摘要——所有处理默认都在本地完成，无需账户、无需云端、无遥测。
该项目是 Meetily 的一个分支，基于 transcribe.cpp 和 llama.cpp 重构而成。完全免费，无付费层级、无许可证密钥、无任何遥测。
Conversationaly 是一个 Tauri 应用，由 Rust 核心（音频采集、转写、存储、摘要编排）和 Next.js 前端组成，两者通过 Tauri 命令和事件通信——无需额外运行服务器
核心功能
️ 本地转写（STT）
- 支持 85 种模型，涵盖 16 个模型家族（Whisper、Parakeet、Nemotron、Canary、Qwen3-ASR、SenseVoice 等），按需下载
- 默认模型为 parakeet-tdt-0.6b-v3-q8（1.94% WER，支持 25 种欧洲语言）
- nemotron-3.5-asr-streaming-0.6b-q8 支持 32 种语言的逐词实时转写
- 支持实时流式转写；批量模型通过语音活动检测（VAD）分段后同样可实时工作
- 内置 llama-helper 服务，本地运行 Gemma 4 模型生成摘要
- 也支持自带 LLM：Ollama、Claude、Groq、OpenRouter、OpenAI，或任何 OpenAI 兼容端点
- 云端 STT：Deepgram、ElevenLabs、Groq、OpenAI
- 云端摘要：同上，仅当用户主动配置密钥时才会离开本地机器
- 专业音频混音：麦克风与系统音频同时录制，带 RMS 音量避让和防削波功能
- 导入与增强（Beta）：可转写已有音频文件，或使用不同模型/语言重新转写历史会议
- 摘要模板：可自定义摘要结构，摘要语言可与口语语言不同
- GPU 加速：支持 Apple Silicon（Metal）、NVIDIA（CUDA）、AMD/Intel（Vulkan）、AMD on Linux（ROCm）
- 本地存储：会议记录、转写内容和模型均保存在本地 SQLite 数据库和模型目录中
工作原理
首次启动时，引导程序会下载一个转写模型和一个 Gemma 4 模型。之后的工作流程如下：
- 音频采集：同时捕获麦克风和系统音频，混音后写入录音文件
- 实时转写：混音后的音频重采样至 16kHz，送入转写引擎，会议进行中实时输出转写文本
- 按需摘要：用户请求摘要时，转写文本被发送给配置的 LLM 提供方（默认为本地 sidecar）
介绍
你的会议内容凭什么默认交给别人？这款开源工具把所有数据锁在你电脑上
开会的时候你在说话，另一个“人”在替你记笔记——但那个“人”的老板可能不是你。
会议录音上传云端、AI转写按分钟计费、敏感数据不知道被谁拿去训练模型——这套流程你已经默认接受了多久？一个叫Conversationaly的开源桌面应用正在做一件反常识的事：把你的会议录音、实时转写和AI摘要，全部锁在你自己的电脑上。不注册账号、不联网、不上传任何数据，除非你主动打开某个云端开关。而这件事最诡异的地方在于——它居然是从一个需要付费解锁功能的商业项目分支出来的。
一个分支，两种命运：免费和付费之间隔着一行代码
Conversationaly的前身叫Meetily。Meetily本身是开源的，但它的Pro版本把说话人识别（Speaker Diarization）等功能锁在了付费墙后面。于是有人做了个分支叫Meetily-ActuallyFree，把付费墙拆了。Conversationaly是另一个分支——它不满足于拆墙，而是把整个底层重写了。
Meetily用Whisper做转写，Conversationaly换成了transcribe.cpp——这是一个基于ggml的C/C++语音识别推理库，由Mozilla.ai的Builders in Residence项目孵化。transcribe.cpp支持16个模型家族、超过60种模型，而Conversationaly在此基础上又扩充到了85个模型、16个模型家族。从Whisper到Parakeet、Nemotron、Canary、Qwen3-ASR、SenseVoice，全都能跑。
这就怪了。一个开源项目，不仅免费，还在底层技术上比它的商业前身更激进——这不符合“免费=阉割版”的常识。
本地跑大模型，不是你想的那样
很多人听到“本地AI”，第一反应是Ollama。Conversationaly确实支持Ollama做摘要，但它默认根本不用Ollama。它自己带了一个llama-helper服务，本地运行Gemma 4来生成会议摘要。也就是说，你下载安装完，打开软件，它自己就能跑摘要——不需要你另外装Ollama、不需要配置API密钥、不需要联网下载额外的东西。
Gemma 4是Google开源的大语言模型，在MMLU测试中达到85.3%。一个会议摘要任务，用这个级别的模型本地跑——够用，而且数据不出门。
但这里有个陷阱：首次启动时，引导程序会下载一个转写模型和一个Gemma 4模型。模型文件多大？从GGUF格式的规模来看，几百MB到几个GB不等。下载是必须的，但只有这一次。之后所有推理都在本地完成。
事情没那么简单。本地跑模型意味着你的CPU或GPU要干活。Conversationaly支持四种GPU加速后端：Apple Silicon的Metal、NVIDIA的CUDA、AMD/Intel的Vulkan、AMD on Linux的ROCm。没有GPU？CPU也能跑，但实时转写可能需要等待——这是本地处理的代价。
85个模型，默认的那个凭什么赢
Conversationaly默认用的转写模型是parakeet-tdt-0.6b-v3-q8，词错误率1.94%，支持25种欧洲语言。另一个推荐模型nemotron-3.5-asr-streaming-0.6b-q8支持32种语言的逐词实时转写。
这两个数字——1.94%的WER和32种语言——放在任何云端转录服务面前都不算差。OpenAI的Whisper在英文上的WER大约在2%到5%之间，取决于音频质量。1.94%意味着Conversationaly的默认模型在准确率上可以跟云端服务掰手腕。
但有个问题：这些模型是GGUF格式的，通过transcribe.cpp加载。GGUF是ggerganov（llama.cpp的作者）定义的格式，主要优势是量化后体积小、加载快。量化的代价是精度损失，但q8（8-bit量化）在质量和体积之间取得了不错的平衡。
所以默认模型的选择逻辑是：用8-bit量化把模型压小，用transcribe.cpp把推理加速，用1.94%的WER保证准确率——三个条件同时满足，才能让“本地运行”这件事变得实际可用。
麦克风和系统音频一起录，怎么做到的
Conversationaly同时录制麦克风和系统音频。这意味着它能捕捉你说话的声音，也能捕捉电脑里播放的声音——比如Zoom里其他人的讲话、YouTube视频的音频、系统通知音。
这个功能在技术上有两个难点。第一，macOS上抓系统音频需要屏幕录制权限（ScreenCaptureKit），macOS 13以上才行。Windows上用WASAPI的回环采集。Linux呢？文档里没细说，但既然支持Linux，应该用的是PulseAudio或PipeWire的回环。
第二，两个音源混在一起，音量可能打架。Conversationaly做了RMS-based ducking和防削波——简单说就是：系统音频太响的时候自动把麦克风音量压低，防止爆音。这个细节说明开发者是真的用过会议软件、被杂音折磨过的人。
云端是选项，不是默认
Conversationaly的核心理念是“默认本地，云端可选”。云端STT支持Deepgram、ElevenLabs、Groq、OpenAI。云端摘要支持Ollama、Claude、Groq、OpenRouter、OpenAI，以及任何OpenAI兼容的端点。
但这些都是opt-in——你必须主动配置API密钥，数据才会离开你的机器。
这个设计有意思的地方在于：它不强迫你选边站。你可以用本地的transcribe.cpp做转写，然后用云端Claude做摘要——或者反过来，用云端Deepgram做转写，用本地Gemma 4做摘要。每个功能独立开关。
这跟Otter.ai、Fireflies.ai那种“所有数据默认上传”的模式形成了鲜明对比。那些服务按分钟收费，数据存在别人的服务器上，你永远不知道谁在看你说了什么。
安装、权限、以及那些让你抓狂的细节
Conversationaly提供预编译安装包：macOS的.dmg、Windows的.exe、Linux的.deb/.rpm/.AppImage。也支持Homebrew和Scoop。
但有个坑：所有构建都没有代码签名。macOS和Windows首次启动时会阻止运行，你需要手动放行。macOS上要右键打开、或者在系统设置里允许来自未识别开发者的应用。Windows上要点击“更多信息”然后“仍要运行”。
权限方面：macOS需要麦克风权限和屏幕录制权限（用于抓系统音频）。Windows只需要麦克风权限。Linux呢？文档没单独说，但音频采集在Linux上通常需要PulseAudio或PipeWire的权限。
这些权限要求不是Conversationaly的问题——任何录制麦克风和系统音频的软件都需要。但“屏幕录制权限”这个说法可能会让一些用户紧张：一个会议记录工具为什么要录我的屏幕？答案是它不录屏幕，它只用ScreenCaptureKit的音频通道来抓系统声音。这个区别需要在首次启动时解释清楚，否则用户可能直接拒绝权限然后抱怨软件不能用。
一个未解的细节
Conversationaly的GitHub仓库里有一个docs/architecture.md。里面描述了Tauri的Rust核心和Next.js前端如何通过Tauri命令和事件通信。Rust处理音频采集、转写、存储和摘要编排。Next.js负责界面。
这套架构本身不稀奇——Tauri应用都长这样。但有个细节值得注意：Rust核心和前端之间“无需额外运行服务器”。这意味着整个应用是一个独立的桌面进程，没有后台服务、没有localhost端口、没有偷偷跑起来的守护进程。
这听起来是好事。但问题是：llama-helper作为一个独立的sidecar进程，它算不算“额外服务”？它确实是一个独立进程，但它由Conversationaly主进程启动和管理，用户不需要手动操作。从用户视角看，它仍然是“一个应用”。
真正有意思的问题在这里：llama-helper运行Gemma 4，Gemma 4的推理需要显存。如果你的显卡只有4GB显存，Gemma 4跑不跑得动？文档里没有说。如果跑不动，会不会fallback到CPU？如果CPU也跑不动，摘要功能是不是就废了？这些边界条件在README里找不到答案。
也许你装了Conversationaly，第一次点“生成摘要”，等了五分钟还没出结果——然后你发现自己的笔记本根本没独显。这时候你会怎么做？卸载？换云端？还是去GitHub提issue？