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

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 是：

1
2
3
4


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：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


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 名称或目录名不一致时，以当前仓库和官方站点为准。

在 NAS 上部署本地会议记录助手

AI 会议记录助手最适合本地部署的场景，是团队有大量会议录音、访谈音频、课程录屏或客户沟通记录，又不希望所有音频都上传到第三方云服务。NAS 刚好适合做这件事：它长期在线、有硬盘空间、可以跑 Docker，也方便把录音文件集中存放。

这篇按“教程 + 排障 + FAQ”整理，目标是帮你在 NAS 上搭一个本地 AI 会议记录流程：音频上传到 NAS，服务转成文字，再用本地或私有 LLM 生成摘要、行动项和待办清单。

先确认你要部署哪一类助手

本地 AI 会议记录大致有三种路线：

路线	特点	适合人群
纯转写工具	只把音频转成文字	只需要字幕和逐字稿
转写 + 摘要	先 STT，再用 LLM 总结	需要会议纪要、行动项
完整会议平台	上传、搜索、权限、团队空间都有	小团队长期使用

NAS 上建议先从“转写 + 摘要”开始。完整平台功能更全，但部署复杂度、数据库、权限、备份和升级成本也更高。

NAS 部署前的硬件判断

先看 NAS 能不能扛住转写和摘要。

最低建议：

4GB 内存可以做轻量测试。
8GB 内存更适合长期运行。
x86 NAS 比 ARM NAS 兼容性更好。
有核显或 GPU 会更快，但不是必须。
硬盘空间要预留音频、转写文本和模型缓存。

如果你的 NAS 性能较弱，可以采用“NAS 存储 + 另一台电脑推理”的方式。NAS 负责保存录音和结果，转写服务跑在迷你主机、台式机或 GPU 机器上。

准备目录

先在 NAS 上准备几个目录：

1
2
3
4
5
6


/volume1/docker/meeting-ai/
├── config/
├── input/
├── output/
├── models/
└── logs/

用途：

input：放待处理音频。
output：放逐字稿、字幕、摘要。
models：放 Whisper 或其他模型缓存。
config：放配置文件。
logs：放运行日志。

目录先规划好，后面排障会简单很多。

Docker Compose 示例

不同会议助手项目的镜像和参数不一样，但思路类似。下面是一个通用结构示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


services:
  meeting-ai:
    image: your-meeting-assistant-image:latest
    container_name: meeting-ai
    restart: unless-stopped
    ports:
      - "7860:7860"
    volumes:
      - /volume1/docker/meeting-ai/input:/app/input
      - /volume1/docker/meeting-ai/output:/app/output
      - /volume1/docker/meeting-ai/models:/app/models
      - /volume1/docker/meeting-ai/config:/app/config
    environment:
      - TZ=Asia/Shanghai
      - WHISPER_MODEL=small
      - LLM_BASE_URL=http://ollama:11434
      - LLM_MODEL=qwen2.5:7b

如果你的 NAS 使用群晖 Container Manager、飞牛 Docker、TrueNAS Apps 或 Portainer，核心也是一样：镜像、端口、目录挂载、环境变量。

Ollama 要不要也部署在 NAS 上

如果 NAS 性能足够，可以把 Ollama 也部署在 NAS 上；如果性能弱，建议把 Ollama 放到更强的机器。

NAS 本机部署的优点：

数据都在内网。
配置简单。
长期在线。

缺点：

大模型推理慢。
内存容易吃紧。
转写和摘要同时跑会卡。

更稳的方案是：

1
2


NAS：存储、Web UI、任务队列
迷你主机或台式机：Ollama / GPU 推理

然后在配置里把 LLM_BASE_URL 指向那台机器的内网地址。

音频格式怎么处理

会议录音常见格式有 mp3、m4a、wav、mp4。为了减少问题，建议统一转成 wav 或标准 mp3。

可以用 ffmpeg 预处理：

1

ffmpeg -i meeting.m4a -ar 16000 -ac 1 meeting.wav

含义：

-ar 16000：采样率转 16k。
-ac 1：转单声道。
meeting.wav：输出给转写模型使用。

如果原文件是视频，也可以只提取音频：

1

ffmpeg -i meeting.mp4 -vn -ar 16000 -ac 1 meeting.wav

转写模型怎么选

常见选择是 Whisper 或 faster-whisper。模型越大，准确率通常越好，但速度和内存占用也更高。

模型	速度	准确率	NAS 适配
tiny	很快	较低	适合测试
base	快	一般	低配 NAS 可试
small	中等	较好	推荐起步
medium	慢	更好	需要更强机器
large	很慢	高	不建议低配 NAS

中文会议建议从 small 开始。如果转写质量不够，再尝试 medium。不要一上来用最大模型，否则排障时很难判断是模型慢、CPU 慢还是服务卡住。

摘要提示词建议

转写完成后，可以让 LLM 生成结构化纪要。提示词可以固定成模板：

1
2
3
4
5
6
7
8


请根据下面的会议逐字稿生成中文会议纪要。

要求：
1. 提炼会议主题。
2. 用要点列出关键讨论。
3. 单独列出行动项，包括负责人、事项、截止时间；如果没有明确负责人或时间，写“未明确”。
4. 保留重要数字、项目名和风险。
5. 不要编造逐字稿里没有的信息。

对本地模型来说，逐字稿太长时要分段摘要，再汇总。不要一次把几个小时的会议完整塞进去。

常见报错：容器启动失败

典型表现：

1
2
3


container exited
permission denied
exec format error

常见原因：

镜像架构不支持你的 NAS CPU。
挂载目录权限不足。
环境变量缺失。
端口被占用。
配置文件路径写错。

排查顺序：

看容器日志。
确认镜像支持 amd64 或 arm64。
检查目录权限。
换一个未占用端口。
先用最小配置启动，再逐步加模型和 LLM。

exec format error 很可能是镜像架构不匹配。

常见报错：上传音频后没有反应

可能原因：

上传目录没有挂载到容器内部。
服务只扫描特定后缀。
文件还没写完就被任务扫描。
文件名包含特殊字符。
后台任务队列卡住。

建议先用简单文件名测试：

1

meeting-test.mp3

不要一开始就用包含空格、中文括号、特殊符号的长文件名。跑通后再测试真实文件。

常见报错：转写很慢

NAS 上转写慢很常见，不一定是部署错了。

优化方法：

换小一点的 Whisper 模型。
先把音频转成 16k 单声道。
把长会议切成多个片段。
避免转写和 LLM 摘要同时占满 CPU。
把转写任务放到更强机器，NAS 只做存储。

如果一小时会议要转几十分钟，在低功耗 NAS 上并不奇怪。关键是要能稳定跑完。

常见报错：转写乱码或语言识别错

可能原因：

自动语言检测失败。
音频噪声太大。
采样率或声道异常。
模型太小。
中英混合场景太复杂。

处理方法：

显式指定语言为中文。
先用 ffmpeg 统一音频格式。
换 small 或 medium 模型。
对多人会议尽量提高录音质量。
对重要会议保留原始音频，方便复查。

常见报错：Ollama 连接失败

典型表现：

1
2
3


connection refused
failed to connect to Ollama
model not found

排查：

Ollama 是否正在运行。
LLM_BASE_URL 是否写对。
容器里访问的 localhost 是否指向自己，而不是 NAS 或主机。
模型是否已经 ollama pull。
NAS 防火墙是否允许内网访问。

如果会议助手在容器里，http://localhost:11434 通常指容器自己。Ollama 在宿主机或另一台机器时，要写对应内网 IP。

常见报错：摘要质量差

摘要质量差通常不是部署问题，而是输入和模型的问题。

常见原因：

逐字稿错字太多。
会议太长，一次输入超出上下文。
本地模型太小。
提示词没有约束输出格式。
行动项在原文里没有明确说清楚。

改进方法：

先按 10 到 20 分钟分段摘要。
最后再做总摘要。
要求模型标注“不确定”。
对行动项使用固定字段。
对重要会议人工复核。

本地模型可以节省成本，但不要期待它自动补全会议里没有说过的信息。

常见问题：NAS 内存不够

如果 NAS 内存小，建议：

转写模型选 base 或 small。
不在 NAS 上跑大 LLM。
限制并发任务为 1。
关闭不必要的容器。
把模型缓存放到空间充足的卷。

如果经常 OOM，说明这台 NAS 更适合做存储，不适合做主要推理机器。

隐私和权限要注意什么

会议录音通常包含敏感信息，本地部署也不能忽视权限。

建议：

给 input/output 目录设置访问权限。
不要把 Web UI 直接暴露到公网。
外网访问走 VPN 或反向代理鉴权。
定期清理临时音频和中间文件。
重要会议结果保留人工复核流程。
如果接入云端 LLM，要明确哪些文本会上传。

“部署在 NAS 上”不自动等于安全，权限和网络边界仍然要自己管。

FAQ

NAS 上能完全本地离线转写吗？

可以，但前提是转写模型、摘要模型和所有依赖都在本地。如果摘要调用云端 LLM，就不是完全离线。建议在配置里明确区分 STT 和 LLM 的来源。

群晖、飞牛、TrueNAS 都能部署吗？

只要能运行 Docker 或类似容器服务，理论上都可以。差别主要在路径、权限、端口映射和 CPU 架构。

ARM NAS 适合跑吗？

可以跑轻量转写，但镜像兼容和性能要提前确认。很多 AI 镜像默认优先支持 amd64，ARM 设备容易遇到架构不匹配。

会议记录助手一定要 GPU 吗？

不一定。CPU 也能转写，只是慢。短音频和低频使用可以接受；大量会议或长视频建议用 GPU 机器。

输出应该保存成什么格式？

建议至少保存 txt 或 md 逐字稿、srt 字幕和 md 摘要。Markdown 最适合后续搜索、归档和人工编辑。

能不能自动识别不同说话人？

这取决于你用的工具是否支持 speaker diarization。它比普通转写更复杂，也更耗资源。重要会议建议把“说话人识别”当成增强功能，不要作为第一版必需功能。

可以直接把会议录音文件夹做自动监控吗？

可以，但要注意文件写入完成再处理。否则录音还没上传完，任务就开始转写，容易失败。可以用临时目录加完成后移动的方式。

本地模型摘要可以直接当正式纪要吗？

不建议。AI 摘要适合作为初稿，尤其是行动项和责任人需要人工复核。对客户会议、法务会议和重要决策会议更要谨慎。

总结

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

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