Meetily 深度拆解：开源隐私优先的 AI 会议助手，本地 Whisper/Parakeet 实时转写 + 多模型总结

Meetily 把会议录音 → 实时转写 → AI 总结三条链路全部下沉到本地。它不是 Otter.ai 的开源替代品，而是用 Rust+Next.js 重新搭了一套"数据不出本机"的会议智能栈。

市面上同时挂着"AI 会议助手"招牌的项目非常多（Otter、Fireflies、Granola、Krisp、Read AI 等），但几乎全部默认把音频流上传到云端做转写。Meetily 的差异点从一开始就被钉死在 README 标题里：Privacy-First AI Meeting Assistant——转写在本地（Whisper/Parakeet），总结可以选本地（Ollama）或第三方 API，录音文件保存在用户机器的 SQLite 里。对律师、医疗、企业合规团队这几个对会议内容最敏感的人群来说，这种"本地优先 + 可选云端"的折中，比纯云端 SaaS 更可用。

本文从架构、引擎选择、构建链路和适用边界四个角度，把 Meetily 拆成可验证的事实。

目录

• 一、它到底解决什么问题
• 二、技术架构：Tauri + Rust + Next.js 的取舍
• 三、引擎选型：Whisper vs Parakeet 的差异
• 四、构建链路与平台支持
• 五、AI 提供方与本地模型集成
• 六、适用边界与限制
• 七、Meetily PRO 与社区版的边界

一、它到底解决什么问题

Meetily 的 README 把痛点拆成三条：

1. 数据隐私：IBM 2024 报告平均单次数据泄露成本 440 万美元，加州 2025 年已发生 400+ 非法录音诉讼
2. 成本控制：云端转写按分钟计费，重度用户月支出可达 50–200 美元
3. 厂商锁定：主流 SaaS 把数据存在自己服务器，用户对存储位置和保留期限没有话语权

针对这三条，Meetily 给出三层解法：

• 本地转写：Whisper.cpp / Parakeet ONNX 都在用户机器上跑，音频不离开设备
• 开源模型：转写侧无 API 调用费，只剩电费
• 自托管：录音、转写、总结结果都存到本地 SQLite，无云端副本

它的"杀手锏"是把上述三条塞进一个原生桌面应用（macOS / Windows），不需要用户自己跑 Docker、配 GPU 服务。

二、技术架构：Tauri + Rust + Next.js 的取舍

Meetily 是一个单进程自包含应用，技术栈组合：

这种"Web 前端 + 原生后端"的拆分在 2025–2026 年的开源桌面项目里很常见（比如 Zed、Cursor 早期版本、Outline），优势是渲染层可以借用 React 生态，后端又保留 Rust 的性能和系统调用能力。Meetily README 在 System Architecture 章节把这套结构总结为一句话：“Single, self-contained application built with Tauri”。

音频采集层用的是 portable-pty 风格的 native 方案（README 提到的 transcribe-rs 借用了 Whisper.cpp 部分代码），同时支持：

• 麦克风单声道捕获
• 系统音频回采（macOS / Windows 都支持）
• 麦克风 + 系统音频混合 + ducking（避免扬声器反馈）

GPU 加速按平台自动启用：

• macOS：Apple Silicon（Metal）+ CoreML
• Windows / Linux：NVIDIA（CUDA）、AMD / Intel（Vulkan）

不需要用户在 UI 里手动选择——构建脚本 build-gpu.sh 在编译期检测硬件并打开对应 backend flag。

三、引擎选型：Whisper vs Parakeet 的差异

Meetily 提供两套转写引擎，README 明确说明支持两者但定位不同：

实际使用上有三个细节值得注意：

1. 模型下载内置：两个引擎的 .bin（Whisper）和 ONNX（Parakeet）文件可以直接在应用里下载，不用手动去 Hugging Face 翻仓库
2. Parakeet ONNX 来源：仓库 Acknowledgments 明确标注使用的是 istupakov/parakeet-tdt-0.6b-v3-onnx 转换版本，对应 NVIDIA TDT-0.6B 模型
3. 导入 + 重新转写：把历史录音拖进应用，可以换模型重跑转写（README 把它叫 “Import & Enhance”），这点对模型升级或多语种切换特别实用

四、构建链路与平台支持

4.1 桌面端安装

• Windows：从 Releases 下载 x64-setup.exe 图形安装包
• macOS：从 Releases 下载 meetily_0.4.0_aarch64.dmg（目前只提供 Apple Silicon 版本，Intel 需自编译）
• Linux：官方未提供预编译包，需要从源码构建

4.2 源码构建（Linux / 自定义）

仓库根目录是 meeting-minutes（注意：仓库名是 meetily，但代码库目录是 meeting-minutes，这是历史遗留）。构建命令：

git clone https://github.com/Zackriya-Solutions/meeting-minutes
cd meeting-minutes/frontend
pnpm install
./build-gpu.sh

构建依赖：

• Rust 工具链（cargo）
• Node.js ≥ 18
• pnpm
• 平台特定：cmake（Linux Whisper.cpp 编译）、Apple CommandLineTools（macOS）

4.3 模型存储

模型文件不会随包分发，首次启动应用会自动下载默认模型到应用数据目录的 models/ 子目录。

五、AI 提供方与本地模型集成

转写是本地，但总结这一步可以选本地也可以选云端：

实际使用上，Meetily 把"自定义 OpenAI 兼容端点"作为单独配置项开放（README 截图 custom.png），这意味着用户可以接入公司内部的 vLLM、TGI、LM Studio、LocalAI 等部署，不需要改 Meetily 代码。

总结的产物结构在 summary.png 截图里能看到：议程要点、行动项、决策记录、参会人列表——这套 schema 是 Meetily 后端硬编码的 prompt template，不依赖特定模型，但模型越强（Claude Sonnet/Opus、GPT-4o）输出的结构化程度越好。

六、适用边界与限制

依据 README 描述，可以推断出以下边界：

“说话人分离（speaker diarization）“是社区版呼声最高的功能——当前社区版只能输出连续文本，无法标记"哪句话是谁说的”。README 的 Contribution TODO 列表里没列这项，但 PRO 路线图提到。

七、Meetily PRO 与社区版的边界

Meetily 团队用双轨制开源 + 商业模型：

• 社区版（MIT 协议）：永久免费 + 开源，包含本地转写、AI 总结（任意 provider）、基础导出
• PRO 版：闭源独立代码库，提供更高准确度的转写模型、PDF/DOCX 导出、自定义摘要模板、自动入会、说话人分离（即将上线）

PRO 模式不取代社区版，社区版持续维护。两者关系更像是"团队版 vs 个人版”——一个人用社区版完全够，一个 10 人合规团队用 PRO 才能满足审计需求。

PRO 营销材料里强调的"不同代码库"意味着 PRO 不是社区版的功能扩展，而是完全重写的姊妹项目。如果未来 PRO 加入了关键功能（比如说话人分离），社区版不会自动同步。

总结

Meetily 的真正价值不是"又一个 AI 会议助手"，而是把会议数据完全留在本地这件事压到了一键安装的桌面应用形态。它适合三类用户：

1. 律师 / 医生 / 顾问：客户对话必须本地处理
2. 企业合规团队：会议内容需要审计但不能上公网
3. 重度会议用户：月度过百小时会议 + 不想被云端 SaaS 计费

不适合：

• 需要说话人分离的实时多人会议（PRO 路线图中）
• 需要移动端录音（只有桌面端）
• Linux 用户嫌编译麻烦（无预编译包）

如果你的场景是"会议内容敏感 + 数据要本地 + 不需要会议平台自动接入"，Meetily 是当前开源生态里最成熟的选择。PRO 版的说话人分离一旦上线，会进一步压缩 Otter.ai 这类 SaaS 的市场空间。

参考资料

• 仓库地址：https://github.com/Zackriya-Solutions/meetily
• 官网：https://meetily.ai
• 架构文档：docs/architecture.md（仓库内）
• 构建文档：docs/BUILDING.md、docs/building_in_linux.md（仓库内）
• 相关项目：Whisper.cpp、Screenpipe、transcribe-rs、Parakeet ONNX