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 包验证轉寫和摘要质量，再决定是否投入時间自建、调模型或改程式碼。