Meetily：本地优先的开源 AI 会议记录助手

Mon, 06 Jul 2026 07:32:15 +0800

Meetily 是一个强调隐私和本地处理的 AI 会议记录助手。它可以在本机捕获会议音频，实时转写，再用 AI 生成会议摘要。项目的定位很清楚：会议录音、转写文本和摘要尽量留在自己的设备或基础设施里，而不是默认交给云端会议机器人。

这类工具的需求挺现实。很多会议内容涉及客户、代码、财务、医疗、法律或内部决策，直接把音频和文字交给第三方云服务并不总是合适。Meetily 选择用本地转写、本地数据库和可选的本地 LLM 摘要，把控制权交还给使用者。

Meetily 是什么

官方描述里，Meetily 是一个 privacy-first AI meeting assistant，支持实时转写、会议摘要、本地处理和自托管。仓库目前是 MIT License，主语言是 Rust，同时使用 Tauri 和 Next.js 组成桌面应用。

从功能上看，它主要解决四件事：

捕获会议中的麦克风和系统音频；
使用 Whisper 或 Parakeet 等模型做本地语音转文字；
保存会议元数据、转写和摘要；
使用 Ollama、本地模型或其他 LLM provider 生成会议纪要。

它支持 macOS、Windows 和 Linux。官方 README 里还保留了一些旧仓库名 meeting-minutes 的 release 链接，实际项目页已经迁移到 Zackriya-Solutions/meetily，下载时最好以当前 GitHub 页面和官方站点为准。

适合谁用

Meetily 更适合这些场景：

不希望会议录音和转写文本离开本机；
想用开源工具替代云端会议记录机器人；
公司或团队有数据合规、客户保密或内部审计要求；
希望会议摘要走 Ollama 或自建 OpenAI-compatible endpoint；
想研究一个 Tauri + Rust + Next.js 的本地 AI 桌面应用。

如果你只是偶尔开会，且完全不在意数据是否上传到云端，现成 SaaS 会议助手会更省事。Meetily 的优势在于控制权，而不是免配置。

主要功能

本地优先

Meetily 的核心卖点是 local-first。转写模型、录音、转写文本和会议摘要都可以保存在本机。对企业或专业用户来说，这比“云端自动生成纪要”更容易解释数据边界。

实时转写

项目支持会议进行时实时生成 transcript。官方 README 提到使用 Whisper 或 Parakeet 模型做转写，并强调不需要云端。

Parakeet 是 NVIDIA 的语音识别模型路线之一，适合追求更快转写速度的场景；Whisper 则生态更成熟，兼容性和资料更多。实际选择要看系统、显卡、语言和准确率要求。

AI 摘要

Meetily 可以把转写内容交给 LLM 生成会议摘要。官方列出的 provider 包括：

Ollama，本地优先；
Claude；
Groq；
OpenRouter；
OpenAI；
自定义 OpenAI-compatible endpoint。

如果目标是尽量本地化，优先考虑 Ollama。如果组织已经有自己的模型网关，可以使用 OpenAI-compatible endpoint 接入内部服务。

音频混合

官方 README 提到 Meetily 能同时捕获麦克风和系统音频，并做 audio mixing、ducking 和 clipping prevention。这一点对会议记录很关键，因为只录麦克风经常会漏掉对方声音，只录系统音频又可能丢掉自己的发言。

导入和重新转写

README 里还提到 Import & Enhance 功能，可以导入已有音频文件生成 transcript，也可以用不同模型或语言重新转写已有会议。这适合把旧录音补成文字，或者对重要会议换一个更准确的模型重跑。

架构大致长什么样

Meetily 是一个 Tauri 桌面应用：

前端：Next.js，负责会议管理、转写展示和设置界面；
后端：Rust Core，通过 Tauri commands 暴露能力给前端；
Audio Engine：捕获麦克风和系统音频；
Transcription Engine：调用本地 speech-to-text 模型；
Database：本地 SQLite，保存会议元数据、转写和摘要；
Summary Engine：调用 Ollama 或其他 LLM provider 生成摘要。

这个架构的好处是桌面端比较轻，核心音频和模型调用放在 Rust 侧，界面则用 Web 技术快速迭代。代价是构建链路会比普通 Web 项目复杂，需要同时处理 Node.js、Rust、Tauri、系统音频权限、模型依赖和 GPU 加速。

安装方式

官方 README 给出的普通用户安装方式是下载 release 包。

Windows

Windows 用户下载最新的 x64-setup.exe，然后运行安装器。

README 中的链接仍指向：

`1`	`https://github.com/Zackriya-Solutions/meeting-minutes/releases/latest`

如果链接后续调整，建议优先从 Meetily 当前仓库和官网进入下载页：

1
2

https://github.com/Zackriya-Solutions/meetily
https://meetily.ai

macOS

macOS 用户下载 .dmg 文件，例如 README 中提到的：

`1`	`meetily_0.4.0_aarch64.dmg`

安装方式和普通 macOS 应用一样：

打开下载的 .dmg；
把 Meetily 拖到 Applications；
从 Applications 启动 Meetily。

Apple Silicon 设备通常更适合这类本地 AI 应用，因为统一内存和 Metal 加速对本地模型体验比较友好。

Linux

Linux 主要走源码构建。README 给的 quick start 是：

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

这里同样要注意旧仓库名。当前仓库页面是：

`1`	`git clone https://github.com/Zackriya-Solutions/meetily`

如果你按 README 的旧命令遇到跳转或目录名不一致，先确认当前仓库里的构建脚本位置，再进入对应目录执行。

从源码构建

官方 docs/BUILDING.md 对 Linux、macOS 和 Windows 都给了说明。

Linux 依赖

Ubuntu/Debian：

1
2

sudo apt update
sudo apt install build-essential cmake git

Fedora/RHEL：

`1`	`sudo dnf install gcc-c++ cmake git`

Arch Linux：

`1`	`sudo pacman -S base-devel cmake git`

开发模式和生产构建：

1
2

./dev-gpu.sh
./build-gpu.sh

构建脚本会自动检测硬件，并尝试选择合适的加速方式。

macOS 构建

macOS 上需要 Homebrew、CMake、Node 和 pnpm：

`1`	`brew install cmake node pnpm`

然后运行：

1
2

pnpm tauri:dev
pnpm tauri:build

官方文档说明 macOS 会默认使用 Metal GPU acceleration。

Windows 构建

Windows 需要这些依赖：

Node.js；
Rust；
Visual Studio Build Tools，并安装 Desktop development with C++ workload；
CMake。

构建命令：

1
2

pnpm tauri:dev
pnpm tauri:build

官方文档说明 Windows 默认是 CPU-only processing。如果要启用 GPU acceleration，需要参考 docs/GPU_ACCELERATION.md。

GPU 加速怎么理解

Meetily 的 Linux 构建脚本会尝试自动检测 GPU。文档里的优先级大致是：

硬件或环境	检查内容	构建特性
NVIDIA CUDA	`nvidia-smi`、`CUDA_PATH` 或 `nvcc`	`--features cuda`
AMD ROCm	`rocm-smi`、`ROCM_PATH` 或 `hipcc`	`--features hipblas`
Vulkan	`vulkaninfo`、`VULKAN_SDK`、`BLAS_INCLUDE_DIRS`	`--features vulkan`
OpenBLAS	`BLAS_INCLUDE_DIRS`	`--features openblas`
无 GPU SDK	无	CPU-only

有显卡驱动不等于能启用加速。比如 NVIDIA 机器只有驱动但没有 CUDA toolkit，脚本可能仍会走 CPU-only。要让构建脚本识别 CUDA，至少要能跑：

1
2

nvidia-smi
nvcc --version

如果想强制指定加速方式，可以用 TAURI_GPU_FEATURE：

TAURI_GPU_FEATURE=cuda ./dev-gpu.sh
TAURI_GPU_FEATURE=cuda ./build-gpu.sh

TAURI_GPU_FEATURE=vulkan ./dev-gpu.sh
TAURI_GPU_FEATURE=vulkan ./build-gpu.sh

TAURI_GPU_FEATURE=hipblas ./dev-gpu.sh
TAURI_GPU_FEATURE=hipblas ./build-gpu.sh

TAURI_GPU_FEATURE="" ./dev-gpu.sh
TAURI_GPU_FEATURE="" ./build-gpu.sh

这类本地 AI 应用的体验很吃硬件。会议实时转写尤其看 CPU/GPU、内存、模型大小和音频长度。第一次尝试时，不要直接拿几小时的会议压测，先用短会议或录音片段确认转写延迟和摘要质量。

摘要模型怎么选

Meetily 的转写和摘要是两件事。

转写关注的是 speech-to-text，重点是准确率、语言支持和速度。摘要关注的是 LLM，重点是能不能把长 transcript 压成有用的会议纪要、行动项和决策记录。

如果你追求隐私优先，可以这样搭：

转写：本地 Whisper 或 Parakeet；
摘要：Ollama 本地模型；
存储：本地 SQLite；
网络：尽量不配置云端 provider。

如果你更看重摘要质量，可以把转写留在本地，但摘要接 Claude、OpenRouter、Groq、OpenAI 或内部 OpenAI-compatible endpoint。这样隐私边界会发生变化：音频可能仍留在本机，但转写文本会发送给摘要模型服务。是否可接受，要看会议内容和组织要求。

Community Edition 和 PRO 的区别

README 里明确说 Meetily Community Edition 会保持免费开源。Meetily PRO 则是另一个面向专业用户和团队的方案，强调更高转写准确率、自定义摘要模板、高级导出、自动会议检测、自托管部署和团队功能。

简单理解：

Community Edition：适合个人、本地优先、开源使用和二次开发；
PRO：适合团队、专业工作流、增强准确率、高级导出和部署管理。

如果你只是想本地记录会议，先从 Community Edition 开始更合理。如果团队有合规、共享、导出模板和部署要求，再看 PRO 或 Enterprise。

使用时要注意什么

第一，会议记录涉及法律和组织规范。很多地区对录音有告知或同意要求，不是工具能录就一定应该录。正式使用前最好确认公司政策和当地法规。

第二，本地优先不等于零风险。录音、transcript 和摘要保存在本机后，也要考虑磁盘加密、备份、访问权限和设备丢失问题。

第三，模型摘要不能当成会议原文。AI 可能遗漏细节、误判语气或把未确认事项写成结论。重要会议最好保留原始 transcript，并人工检查最终纪要。

第四，README 里的部分链接还带旧仓库名 meeting-minutes。这不是功能问题，但读者安装时容易困惑。遇到链接跳转、release 名称或目录名不一致时，以当前仓库和官方站点为准。

总结

Meetily 的价值不在于“又一个会议纪要工具”，而在于它把会议 AI 的关键流程尽量放回本地：音频捕获、本地转写、本地存储、可选本地摘要。对重视隐私、合规和数据主权的团队来说，这比方便但不透明的云端机器人更可控。

它也不是零门槛工具。桌面端安装还好，如果要源码构建、GPU 加速或接入内部模型服务，就需要一定工程能力。更务实的路线是：先用 release 包验证转写和摘要质量，再决定是否投入时间自建、调模型或改代码。

AI会议助手 on KnightLi的博客