meetily
Zackriya-Solutions/meetily加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
图1：Meetily 桌面端主界面（macOS/Windows 双平台支持）
想象一下：你在一家中型科技公司担任项目经理，每天要参加 3-4 场会议。会后需要整理录音、写纪要、分发任务，一套流程下来 2 小时不见了。更要命的是，会议涉及敏感的商业策略、客户报价——把录音上传到第三方云服务简直是噩梦。
Meetily 正是为解决这个痛点而生的。它是全球排名第一的开源自托管 AI 会议记录工具，主打"隐私优先、100% 本地处理"，用户无需将任何音频数据发送到云端。
Meetily 由印度开发者 Zackriya Solutions 打造，背后站着的是独立开发者 Sujith S。项目最初于 2022 年启动，最初版本只是简单的语音转文字工具。2024 年，随着 Whisper.cpp 的成熟和 Ollama 的普及，团队将产品升级为完整的"录音 → 转录 → 说话人分离 → AI 摘要"一站式解决方案，并在 GitHub 上迅速积累了超过 12,000 颗星。
值得注意的是，该项目在 Trendshift 上的增长趋势非常强劲，反映出市场对本地化 AI 会议工具的强烈需求——尤其是在企业数据合规要求日益严格的背景下。
从技术架构看，Meetily 采用了一套精心设计的四层架构：
第一层：Rust 桌面端（Tauri 2.x + Next.js） 桌面客户端使用 Tauri 2.x 框架构建，底层是 Rust 语言（负责窗口管理、系统集成、FFmpeg 音频处理），上层是 Next.js 14 + React 18（负责 UI 渲染）。Rust 的零成本抽象和高性能音频处理能力，确保了即使在录音过程中也不会出现卡顿或音频丢失。
值得注意的是，Tauri 相比 Electron 有显著优势：打包体积小（~10MB vs ~150MB）、内存占用低、安全性更强。对于一款需要长期后台运行的会议工具来说，这些优势直接影响用户体验。
第二层：音频采集与实时流处理
Meetily 使用 Rust 的 cpal 库直接访问系统音频流，配合专业的音频混合算法，实现多路音频的同步采集。录音数据通过专业缓冲管理（MAX_AUDIO_QUEUE_SIZE=10）避免丢包，即便在资源紧张的情况下也会在日志中提示"Dropped old audio chunk"——而非静默丢失。
第三层：Whisper.cpp 本地转录 转录引擎基于 Whisper.cpp（OpenAI Whisper 的 C/C++ 实现），支持 GGML 量化模型。系统提供 GPU 加速版本（CUDA 12.3+）和 CPU 版本，用户可根据硬件条件选择。Whisper 模型涵盖 tiny ~ large 多个规格，英文场景推荐 base.en 或 small.en（精度与速度的平衡点）。
Whisper 的说话人分离（Diarization）功能可以自动识别"谁在什么时候说了什么"，这对于多人会议的纪要有巨大价值。
第四层：FastAPI 后端 + 多 LLM 摘要引擎 后端使用 FastAPI + SQLite（aiosqlite 异步驱动），提供 RESTful API 管理会议记录和摘要生成。LLM 摘要引擎支持多种接入方式：
这种"可插拔"的 LLM 架构是项目最聪明的设计之一：技术能力强的用户可以用 Ollama 实现完全离线，技术能力有限或追求精度的用户可以接入 Claude，灵活切换，无需改动代码。
Meetily 的部署设计堪称教科书级别。backend 目录下提供了完整的 Docker 生态：
Dockerfile.server-gpu：CUDA 加速版，基于 nvidia/cuda 镜像，多阶段构建Dockerfile.server-cpu：纯 CPU 版，基于 Ubuntu 22.04，兼容最广Dockerfile.server-macos：macOS 专用优化版Dockerfile.app：FastAPI 应用容器docker-compose.yml：一键编排所有服务对于有 NVIDIA 显卡的用户，一条 ./build-docker.sh gpu && ./run-docker.sh start 即可完成部署；对于纯 CPU 机器，./build-docker.sh cpu 同样友好。docker-compose.yml 中对内存要求做了明确提示（8GB+ 最低），并提供了详细的音频队列溢出排查指南——这是大多数开源项目忽略的运维细节。
桌面端则提供 macOS 和 Windows 原生安装包，安装包本身也通过了 GitHub Actions 多平台 CI 验证。
图2：Meetily 实时转录演示（GIF 动画）
Meetily 的功能矩阵覆盖了会议全流程：
| 功能模块 | 具体能力 |
|---|---|
| 音频采集 | 系统音频流捕获、多设备选择、FFmpeg 预处理 |
| 实时转录 | Whisper 本地推理、4 倍速处理（相对实时）、说话人分离 |
| 会议管理 | 会议列表、详情查看、笔记编辑、导出 |
| AI 摘要 | 多 LLM 引擎、可配置摘要风格、本地 Ollama 或云端 API |
| 隐私保护 | 100% 本地处理、仅收集匿名使用统计（功能/错误/性能） |
| 跨平台 | macOS、Windows 原生 App |
图3：Meetily 转录面板 — 实时显示说话人与对应文本
图4：会议纪要编辑器 — 可手动校正 AI 转录内容
没有任何项目是完美的，Meetily 也有几个值得关注的局限：
1. 多语言支持仍有提升空间 Whisper.cpp 对非英语语言的支持在 large-v3 模型以下有明显差距。如果你的团队需要高频处理中文、日文或小语种会议，当前版本可能需要额外调优或换用 larger 模型（内存占用翻倍）。
2. 实时转录 vs 事后处理的取舍 Meetily 的"实时转录"基于 Parakeet（4x 加速） + Whisper 的混合架构，但在实测中，网络不稳或硬件资源不足时可能出现音频队列溢出（已在日志中有提示）。对于追求极致稳定性的企业用户，建议在部署前做一次完整的压力测试。
3. 完全本地化的代价 LLM 摘要的"本地 Ollama"选项虽然隐私性极佳，但 Ollama 本身对硬件要求较高（Llama 3 70B 需要 ~140GB 内存）。大多数个人用户最终还是会选择接入云端 API，项目宣称的"100% 本地"在实践中并非无代价。
4. 文档语言的局限 虽然项目 README 提供了多语言说明，但核心开发文档（CLAUDE.md）和 API 文档仍以英文为主，对中文用户有一定门槛。
在 AI 工具普遍"数据上云"的今天，Meetily 代表了一股重要的反向力量——它用 Rust 的性能、Whisper 的精度和 Ollama 的灵活性，证明了"隐私优先"与"功能强大"完全可以兼得。
GitHub Stars 超过 12,000 且持续增长的趋势，说明市场正在用脚投票。2024 年欧盟 AI 法案（EU AI Act）和各国数据本地化法规的出台，让企业级"本地 AI 会议助手"从"加分项"变成了"必选项"。Meetily 的出现恰逢其时。
对于开发者而言，Meetily 也是一个极佳的学习样本：Tauri + Next.js 的现代桌面开发、Rust + Python 的混合架构、Docker 多阶段构建、Whisper.cpp 的工程化集成——每一个模块都值得深入研究。
图5：Meetily 官方标志 — 隐私之盾 + AI 智慧