【Meetily 开源 AI 会议助手】本地会议录音、Whisper/Parakeet 实时转写与 AI 摘要实现解析

Meetily 本地 AI 会议助手技术全景

• 一、项目定位与效果展示：会议数据留在谁手里
• • 1.1 从录音到纪要的一体化桌面工作流
  • 1.2 Community 版真正包含哪些能力
• 二、系统架构与核心数据流：Next.js 界面如何驱动 Rust 音频引擎
• • 2.1 技术分层与源码目录
  • 2.2 一次会议在系统中的完整流转
• 三、音频采集与转写管线：从双路声音到有序文本
• • 3.1 混音、重采样与 VAD 为什么必须分层
  • 3.2 Whisper 与 Parakeet 如何实现统一的 `TranscriptionProvider` 接口
  • 3.3 设备、模型与性能如何选择
• 四、AI 摘要实现：提供商适配、长文本分层压缩与模板输出
• • 4.1 本地模型与云端 API 如何接入统一的摘要请求适配层
  • 4.2 长会议为什么要做分层摘要
  • 4.3 模板把“自由生成”约束为可复用报告
• 五、本地存储、隐私与可靠性：Local-first 不等于没有安全工作
• • 5.1 SQLite 与会议文件如何共同保存和恢复会议状态
  • 5.2 隐私边界必须按实际数据流判断
  • 5.3 当前实现的真实能力边界
• 六、安装、源码构建与上手实践
• • 6.1 普通用户优先使用发布包
  • 6.2 从源码启动桌面应用
  • 6.3 建立可复现的会议质量检查
• 七、适用场景与总结
• 参考资料

Meetily 是面向“不希望会议机器人加入通话，也不希望录音先上传云端”场景下的开源 AI 会议助手。它在本机捕获麦克风和系统播放声音，在桌面端完成 VAD 分段、Whisper/Parakeet 转写、录音回放、LLM会议摘要和笔记管理。它并不绑定 Zoom、Teams 或某个会议平台，而是在操作系统音频层工作，因此也能用于线下访谈、课程录音、播客素材以及已经存在的音频文件。本文基于 Community 0.4.0 源码，拆解 Tauri 桌面架构、音频与转写管线、长文本摘要、本地存储及隐私边界，并给出安装与源码构建方法。

GitHub仓库：https://github.com/cmyk-labs/meetily.git

（如果这个仓库对你有帮助，欢迎在 GitHub 上点一个 Star ⭐ 支持一下。）

官方GitHub仓库：https://github.com/Zackriya-Solutions/meetily

官方文档：https://docs.meetily.ai/

一、项目定位与效果展示：会议数据留在谁手里

1.1 从录音到纪要的一体化桌面工作流

Meetily 的核心使用链路可以压缩为六步：

选择麦克风与系统音频设备 → 开始录音并实时显示转写 → 停止时冲刷剩余音频与转写队列 → 在本地保存录音、逐段文本和时间戳 → 选择本地或云端 LLM 生成结构化摘要 → 校订文字、回放定位并复制会议结果

录音、转写段落和播放时间被关联后，用户可以从文本跳回对应音频；摘要层再从逐字稿提取结论、决定和行动项。对于需要保留原始证据的记录，时间轴比脱离录音的纯文本更有用。

录音首页与实时转写入口	带时间信息的会议转写
结构化 AI 会议摘要	摘要查看与富文本编辑
麦克风与系统音频设备配置	转写模型与本地存储设置

Meetily 还支持导入音频和重新转写：用户可以为历史录音更换模型或语言。原始音频可保留、转写与摘要可重做，比一次性输出更适合长期整理。

1.2 Community 版真正包含哪些能力

在当前固定提交中，可以从桌面端源码确认的主要能力包括：

能力	当前实现
音频采集	麦克风和系统音频设备选择、开始/暂停/恢复/停止录音、设备断开监测
本地转写	Whisper 与 Parakeet 两类引擎，模型下载、装载、VAD 语音分段和实时事件输出
音频文件处理	导入已有音频、解码、重新转写、转写恢复
摘要生成	OpenAI、Claude、Groq、OpenRouter、Ollama、自定义 OpenAI 兼容端点和内置本地 AI
会议管理	SQLite 元数据、分页加载转写、摘要状态、会议笔记、文本搜索和录音回放
桌面集成	Tauri 托盘、单实例、通知、文件选择、自动更新和跨平台安装包配置

需要特别区分的是“本地转写”和“本地摘要”。Whisper/Parakeet 的转写链路运行在本机；摘要是否离线取决于所选提供商。选择内置 AI 或本机 Ollama 时，逐字稿可以不发给云端；选择 OpenAI、Claude、Groq、OpenRouter 或外部兼容端点时，摘要请求会把提示词和会议文本发送到相应服务。隐私优先是一种可实现的部署方式，不是忽略配置后的绝对承诺。

二、系统架构与核心数据流：Next.js 界面如何驱动 Rust 音频引擎

2.1 技术分层与源码目录

Meetily Community 0.4.0 是一个自包含的 Tauri 2 桌面应用。frontend/src使用 Next.js、React、TypeScript 与 BlockNote 等组件构建录音、设置、会议详情和编辑界面；frontend/src-tauri/src是 Rust 核心，负责音频设备、文件系统、SQLite、模型生命周期和系统托盘。两者不通过公开 HTTP 服务通信，而是通过 Tauri Command 和事件通道协作。

项目固定提交中的官方架构说明给出了前端、Tauri、数据库和 AI 服务的高层关系；下面按当前活动代码进一步拆开桌面桥接、音频转写与摘要 Sidecar：

Next.js / React UI ├─ invoke("start_recording", 参数) ───────────────┐ ├─ listen("transcript-update", 回调) <───────────┤ └─ invoke("api_process_transcript", 参数) ───────┤ ↓ Tauri Command 路由（lib.rs） ├─ RecordingManager / AudioPipeline ├─ WhisperEngine / ParakeetEngine ├─ SummaryService / llama-helper Sidecar ├─ SQLx + SQLite Repository └─ 文件、托盘、通知、更新器等原生插件

实时音频不必调用单独的 Python 服务，模型和录音可以使用本机路径并由 Rust 管理资源；前端则保留 Web 技术的开发效率。

层次	主要实现	关键职责
UI 层	Next.js、React、TypeScript、BlockNote	录音控制、设备/模型配置、实时逐字稿、会议编辑与回放
桌面桥接层	Tauri Command、事件、lib.rs	管理前后端调用、共享状态、托盘、通知和原生插件
音频与转写层	CPAL、AudioPipeline、Silero VAD、Whisper、Parakeet	采集双路音频、混音重采样、语音分段和 ASR
摘要层	SummaryService、云端适配器、llama-helperSidecar	统一提供商请求、长文本分层压缩和模板输出
持久化层	SQLx/SQLite、会议目录、JSON、音频检查点	保存会议元数据、逐字稿、录音和崩溃恢复状态

源码目录可以按职责理解：

meetily/ ├── frontend/ │ ├── src/ # Next.js 页面、组件、状态与 Tauri 调用 │ └── src-tauri/ │ └── src/ │ ├── lib.rs # Tauri 初始化、状态注册与命令路由 │ ├── api/ # 暴露给前端的业务 Command │ ├── audio/ │ │ ├── pipeline.rs # 双路混音、VAD 与音频分流 │ │ ├── transcription/ # 转写 Provider 与 Worker │ │ └── incremental_saver.rs # 分段音频检查点 │ ├── whisper_engine/ # whisper-rs 模型管理与推理 │ ├── parakeet_engine/ # ONNX Runtime Parakeet 推理 │ ├── summary/ # 摘要适配、分层压缩与模板 │ └── database/ # SQLite、模型与 Repository ├── llama-helper/ │ └── src/main.rs # 本地 GGUF 摘要 Sidecar ├── docs/ │ └── architecture.md # 官方高层架构说明 └── backend/ # 已归档的旧 Python/FastAPI 实现

backend/仍保留在仓库中容易造成误判。固定提交的backend/README.md将旧 Python/FastAPI 后端、Docker 配置和独立 whisper-server 标为归档实现，frontend/README.md也说明当前桌面应用不再需要这些独立服务；当前推荐运行形态是 Windows/macOS 桌面应用，Linux 可从源码构建。因此不应再把docker-compose.yml画进当前主架构，也不应要求普通用户同时启动 8178 和 5167 端口。

2.2 一次会议在系统中的完整流转

点击“开始录音”后，前端调用 Tauri Command。Rust 先读取转写配置并验证模型是否下载、能否加载，再解析用户选择的麦克风和系统音频设备。RecordingManager建立三条协作链：音频流把原始采样送入 Pipeline，Pipeline 把混合结果送给录音保存器，同时把 VAD 检出的语音段送给转写任务。

麦克风采样 ─┐ ├─> AudioPipeline 混合与 VAD ─┬─> RecordingSaver ─> audio.mp4 系统音频采样 ┘ └─> Transcription Task │ Whisper / Parakeet │ transcript-update 事件 ┌─────┴─────┐ ↓ ↓ React 实时界面 RecordingManager │ │ └─────┬─────┘ ↓ transcripts.json + SQLite ↓ SummaryService + LLM

停止录音不是简单关闭设备。当前实现先停止产生新 Chunk，强制冲刷 Pipeline，再等待转写队列、卸载模型、合并录音检查点并发送recording-stopped。前端收到剩余转写后再保存数据库记录，以减少最后几段尚未到达便提前落库的竞态。

不过，源码中的“保证零丢失”属于日志目标，不应理解为形式化保证：等待转写任务存在 10 分钟超时，文件保存也有 5 分钟超时；超时、模型错误、磁盘不足或进程崩溃都可能产生不完整结果。工程上真正降低风险的是强制冲刷、分段检查点、原子写 JSON 和恢复入口的组合。

三、音频采集与转写管线：从双路声音到有序文本

3.1 混音、重采样与 VAD 为什么必须分层

麦克风与系统音频常有不同的采样率、声道数、缓冲大小和时钟抖动，直接逐样本相加会造成漂移、爆音或一侧声音消失。Meetily 的活动链路先通过 CPAL 和平台适配层取得设备数据，再把音频归一为单声道、重采样到 Pipeline 的 48 kHz 工作采样率。麦克风侧还包含高通、降噪和响度处理相关组件。

AudioPipeline使用两个环形缓冲区对齐麦克风和系统流。固定提交中的实际混音窗口变量为 600 ms，缓冲上限是 8 个窗口；某一路数据不足时以零补齐，超出上限时丢弃最旧样本。混音器将两路相加，绝对值超过 1.0 时按比例缩放回有效范围，避免硬削波。

这里有一个值得源码阅读者注意的边界：当前活动pipeline.rs明确写着“不使用 aggressive ducking”，它执行的是简单求和与比例缩放。仓库另有audio_v2/mixer.rs的 ducking/crossfade 实验实现，但RecordingManager当前连接的是audio/pipeline.rs。因此可以说项目在处理双路混音和削波风险，不能把“智能 Ducking”描述成这个提交中已经接入主链路的默认行为。

混合后的 48 kHz 音频分成两路：原采样率数据进入录音保存器；转写侧先交给 Silero VAD。VAD 内部把音频转换为 16 kHz，按 30 ms、480 个采样点处理，使用0.50正阈值、0.35负阈值、300 ms 前置补偿、400 ms 后置补偿和 250 ms 最短语音时间。Pipeline 传入的停顿赎回时间是 400 ms，用来把自然停顿两侧的语音尽量保持在同一段。

48 kHz 混合音频 → 转 16 kHz → 每 30 ms 运行 Silero VAD → SpeechStart 后累计采样 → SpeechEnd 形成带起止时间的 SpeechSegment → 过滤过短片段 → 送入 ASR

VAD 不是为了生成最终文字，而是减少静音和背景噪声进入 ASR，降低无效推理与静音幻觉。阈值过严会漏掉小声发言，停顿时间过短会把一句话切碎，过长又会增加实时等待。因此嘈杂会议中出现漏字时，应先检查输入电平、设备与 VAD 分段，再盲目更换大模型。

3.2 Whisper 与 Parakeet 如何实现统一的TranscriptionProvider接口

Meetily 为转写定义了TranscriptionProviderTrait：输入是 16 kHz 单声道Vec<f32>和可选语言，输出统一为文本、可选置信度与 partial 标记。当前TranscriptionEngine仍保留 Whisper 和 Parakeet 的直接变体，同时提供 Trait 对象变体，便于未来增加其他实现。

引擎	当前代码路径	主要特点
Whisper	whisper-rs加载本地 GGML.bin模型	支持语言偏好并返回置信度和 partial 状态；低于 0.3 的结果会被过滤
Parakeet	ONNX Runtime 加载 Parakeet 模型	当前结果不提供置信度，转写 Worker 接受非空结果；默认配置倾向 Parakeet

开始录音前，系统按数据库中的provider选择localWhisper或parakeet，校验目标模型状态并尝试加载。如果所选 Whisper 模型不存在但本地有其他可用模型，初始化逻辑会退回到第一个可用模型；若没有任何模型，则阻止开始录音并提示下载。这样可以把“录了很久才发现没有模型”的失败提前到入口。

模型推理后，Worker 生成递增的sequence_id，保存audio_start_time、audio_end_time和duration，再发出transcript-update。前端实时显示，Rust 侧同时把段落加入 RecordingManager，以支持刷新恢复和最终 JSON 输出。

值得注意的是，文件和日志中多次出现“parallel workers”“3 workers”等旧描述，但固定提交的实际常量为：

constNUM_WORKERS:usize=1;// Serial processing ensures transcripts emit in chronological order

所以当前transcription/worker.rs中的实时转写是异步任务加单 Worker 顺序推理，不是三 Worker 并行 ASR。单 Worker 牺牲部分吞吐换取事件天然有序，避免较短的后续语音先完成、较长的前序语音后完成。长会议结束时若队列积压，停止操作可能继续等待剩余转写；这正是界面显示关闭进度和设置最长等待时间的原因。

3.3 设备、模型与性能如何选择

选择转写方案时，应同时考虑语言、口音、输入质量、CPU/GPU、实时性和允许的会后处理时间：

• 轻量模型适合普通笔记本和长时间实时会议，但专有名词准确率可能有限；
• 较大 Whisper 模型需要更多内存和推理时间，适合准确率优先或会后重转写；
• Parakeet 基于 ONNX Runtime，当前链路不提供可用于过滤的置信度，应更依赖 VAD 和人工校订；
• Windows/Linux 可按构建 Feature 使用 CUDA、Vulkan、HIPBlas 或 OpenBLAS，macOS 使用 Metal/CoreML；实际速度仍取决于模型和驱动；
• 蓝牙设备可能在系统音频、麦克风配置和采样率切换时表现不稳定，源码专门加入设备断开监测，macOS 默认设备路径还会规避部分蓝牙采集组合。

对重要会议，建议保留audio.mp4并在结束后抽查专有名词、数字、否定词和行动项。ASR 输出是机器推断结果，不能替代录音证据；重新转写功能的意义，正是允许之后使用更合适的模型和语言重新生成文本。

四、AI 摘要实现：提供商适配、长文本分层压缩与模板输出

4.1 本地模型与云端 API 如何接入统一的摘要请求适配层

转写完成后，SummaryService 从 SQLite 读取会议逐字稿、摘要模型配置和模板，构造一次可取消的摘要任务。LLMProvider枚举覆盖 OpenAI、Claude、Groq、Ollama、OpenRouter、BuiltInAI 与 CustomOpenAI。除 Claude 使用自己的 Messages 请求结构外，OpenAI、Groq、OpenRouter、Ollama 和自定义端点复用 OpenAI 风格的 Chat Completions 数据结构。

图片来源：项目 GitHub 仓库固定提交中的docs/custom.png。

选择不同提供商时，数据流向明显不同：

摘要方式	数据流向	适合场景
BuiltInAI	Tauri 通过标准输入输出调用打包的llama-helper，模型和文本留在本机	不希望安装独立推理服务，希望开箱离线摘要
Ollama	请求默认发往http://localhost:11434/v1/chat/completions，也可配置其他地址	已经管理本地 Ollama 模型，或使用内网推理节点
CustomOpenAI	请求发往用户填写的兼容/chat/completions端点	企业内部网关、自建 vLLM 等兼容服务
OpenAI/Claude/Groq/OpenRouter	逐字稿和提示词发往相应公网 API	更看重模型质量、速度和即用性，并允许数据出网

内置 AI 不是把一个 HTTP 服务常驻在后台。Tauri 管理llama-helperSidecar，Sidecar 基于llama_cpp_2加载本地 GGUF，接收逐行 JSON 请求并返回结果。固定提交登记了 Qwen 3.5 2B/4B 与 Gemma 3 1B/4B 等模型，每个模型携带文件、下载地址、上下文大小、层数和采样参数；空闲默认 5 分钟后进程退出，从而回收模型占用。

4.2 长会议为什么要做分层摘要

本地模型的上下文和内存通常小于云端模型，一次把数小时逐字稿塞进 Prompt 容易超限。Meetily 先用字符数粗估 Token：

rough_tokens = ceil(Unicode 字符数 × 0.35)

这不是精确 tokenizer，只是成本很低的容量估计。对于 Ollama 或 BuiltInAI，当估算长度超过当前模型阈值时，系统采用分层摘要：

完整逐字稿 → 按阈值减去 300 Token 提示开销 → 使用约 100 Token 重叠切为多个字符窗口 → 依次生成每个窗口摘要 → 合并所有局部摘要为连贯中间摘要 → 按会议模板生成最终 Markdown 报告 → 如目标语言不是英语，再保持 Markdown 结构翻译

切分函数为了兼容中文等 Unicode 文本先按char建索引，再转换回字节区间；窗口末尾优先寻找英文句号加空格，其次寻找空格，否则按字符边界切开。重叠可以减少边界处事实被完全拆散，但它也可能让同一个决定在相邻摘要中重复出现。后续合并步骤负责去重和组织，不代表一定不会遗漏。

云端提供商和 CustomOpenAI 在当前实现中被视为大上下文，Service 将阈值设置为近似 100000 Token，并通常走单次最终报告请求。这是一项代码策略，不是对每个模型上下文都做了运行时强校验；如果自定义端点背后的模型上下文更小，仍可能返回超长请求错误。部署自定义模型时，应让配置、模型实际上下文和会议长度一致。

4.3 模板把“自由生成”约束为可复用报告

Meetily 的会议模板是 JSON 结构，每个 Section 定义标题、生成说明、格式以及可选表格骨架。标准会议模板包含 Summary、Key Decisions、Action Items 和 Discussion Highlights；行动项还要求模型生成负责人、任务、截止时间和原转写参考。最终系统提示词要求只使用源文本、不确定时省略、无信息时明确说明，并只输出完成的 Markdown。

模板让不同会议保持相同格式，也约束模型“该提取什么”。但 LLM 仍可能错配负责人、日期或转写片段；高风险会议应回查带时间戳的原文。

多语言摘要在 0.4.0 中采用“先生成规范英语底稿，再按目标语言翻译 Markdown”的路径。翻译提示词要求保留标题、列表、表格、代码围栏、URL 和反引号内容；如果已经缓存英语摘要，切换目标语言时可以复用第一阶段结果，避免重新总结整场会议。它提升的是格式一致性，不等同于逐句忠实翻译，专有名词仍需要人工检查。

五、本地存储、隐私与可靠性：Local-first 不等于没有安全工作

5.1 SQLite 与会议文件如何共同保存和恢复会议状态

Meetily 使用 SQLx 管理本地 SQLite，数据库位于 Tauri 应用数据目录下的meeting_minutes.sqlite。迁移表主要保存会议、逐段转写、摘要处理状态、模型设置、转写设置和会议笔记：

meetings 会议 ID、标题、创建/更新时间、录音文件夹 transcripts 文本、显示时间、音频起止时间和时长 summary_processes 摘要状态、结果、错误、耗时、备份与 Chunk 数 transcript_chunks 用于摘要的合并逐字稿及模型、分块参数 settings 摘要提供商、模型、端点和各类 API Key transcript_settings 转写提供商、模型和相关 Key meeting_notes 用户编辑的 Markdown / JSON 笔记

录音文件又保存到独立会议目录。默认目录在 Windows 的 Music、macOS 的 Movies、Linux 的 Documents 下，名称为meetily-recordings；用户设置包含保存目录，但固定提交的RecordingSaver::initialize_meeting_folder()实际调用默认目录函数，定制目录是否在所有路径生效应以运行结果为准。一个完成的会议目录通常包含：

<meeting-folder>/ ├── audio.mp4 ├── transcripts.json └── metadata.json

启用自动保存时，IncrementalAudioSaver 每累计约 30 秒音频就在隐藏的.checkpoints/中写一个audio_chunk_NNN.mp4。正常结束后用 FFmpeg concat 合并为audio.mp4并清理检查点；异常退出时，恢复命令可以扫描这些文件重新合并。metadata.json和transcripts.json使用临时文件加重命名的原子写法，降低写到一半留下截断 JSON 的概率。

数据库保存查询与界面状态，会议目录保留音频和 JSON。备份时不能只复制 SQLite 或 MP4，应同时覆盖应用数据目录与录音目录，并实际验证恢复。

5.2 隐私边界必须按实际数据流判断

Community 0.4.0 的转写在本机运行，录音和 SQLite 也默认落在本机；使用 BuiltInAI 或本地 Ollama 时，可以形成完整离线处理链。使用云摘要提供商或把 Ollama/CustomOpenAI 指向远程地址后，逐字稿会离开设备。因而判断“会议是否出网”应检查四类出口：

1. 摘要 Provider 及其真实 Endpoint；
2. 模型下载和应用自动更新；
3. 用户主动开启的使用分析；
4. 操作系统、备份软件或企业终端管理对录音目录的同步。

0.4.0 的 Analytics 默认关闭，前端本地 Store 的analyticsOptedIn默认值为false；用户选择启用后，Rust 客户端会向 PostHog 发送经过清理的产品与性能事件。源码有属性过滤和不采集会议正文的设计，但对严格离线环境，最清楚的策略仍是保持关闭并在网络层限制非必要域名。

“数据保存在本机”也不等于“应用自己加密了数据库”。当前 SQLite Schema 中摘要与转写 API Key 是普通文本列，会议音频、JSON 和数据库没有看到项目级字段加密层；隐私策略提到的 at-rest 保护主要依赖设备安全能力。因此生产使用还需要：

• 开启 BitLocker、FileVault 或等价的全盘加密；
• 使用独立系统账号并锁屏，不让共享账号读取录音目录；
• 对备份介质加密并限制云盘自动同步；
• 选择公网摘要服务前确认数据处理条款与保留策略；
• 定期轮换 API Key，设备遗失时及时撤销；
• 录音前遵守所在地区的告知与同意要求。

5.3 当前实现的真实能力边界

源码分析还揭示出几个容易被产品文案或旧文件混淆的边界：

• 说话人分离：桌面迁移中存在speaker字段，旧归档 whisper-server 也残留 diarization 参数，但固定提交的活动桌面转写结果没有说话人字段，主 Pipeline 先混合麦克风和系统声音再识别；Community 0.4.0 不能据此宣称已完成“谁说了什么”。官方 Speaker Diarization 产品页则明确把它列为 Meetily Pro 能力。
• 并行转写：类名和日志保留“Parallel”，实际 Worker 常量是 1；不能据此给出多核吞吐或实时倍速承诺。
• 高并发：Community 是单用户桌面应用，不是多租户会议服务。SQLite、进程内状态和本地模型生命周期都是面向单机体验的设计，不存在需要对外宣称的 QPS、水平扩容或集群高可用能力。
• 自托管含义：当前推荐形态是“在自己的桌面设备上运行”，不是用仓库旧 Docker Compose 部署一个团队 Web 服务。团队级服务器能力、权限与审计应单独核对 Pro/Enterprise，而不是从归档目录推断。
• 自动准确：VAD、ASR 和 LLM 都可能出错；代码中的阈值和超时是工程折中，不是医学、法律或财务会议记录的准确性保证。

六、安装、源码构建与上手实践

6.1 普通用户优先使用发布包

官方当前为 Windows 和 Apple Silicon macOS 提供 Community 安装包。Windows 下载 Release 中的x64-setup.exe并运行；macOS 下载对应.dmg，拖入 Applications。首次启动通常需要完成以下配置：

1. 授予麦克风权限，并按平台提示授予系统音频/屏幕录制权限；
2. 下载 Parakeet 或 Whisper 转写模型，等待状态变为可用；
3. 选择摘要方式：内置 AI、本机 Ollama或自带 API Key；
4. 用一段 30～60 秒测试会议校验两路音频、电平、语言和转写；
5. 停止后检查audio.mp4、逐字稿时间轴与摘要，再用于正式会议。

第一次测试的成功判据应覆盖整条链路：输入电平同时反映麦克风与系统音频；界面持续收到带时间信息的转写；停止后audio.mp4、逐字稿时间轴和摘要均可读取；回放短录音时，时间定位与对应文字基本一致。只有摘要生成成功，并不能证明双路采集、实时事件、停止冲刷和录音保存都正常。

Linux 在 0.4.0 官方发布说明中仍以源码构建为主，官网没有把它描述成与 Windows/macOS 相同的现成安装体验。不要从仓库 README 的“Multi-Platform”直接推断所有平台都有同样成熟的签名安装包和系统音频采集行为。

6.2 从源码启动桌面应用

源码构建需要 Git、Node.js 18+、pnpm 8+、Rust 工具链以及平台原生构建依赖。根 Cargo Workspace 指定的最低 Rust 版本为1.77，但项目依赖更新较快，使用当前 stable 更省事；Windows 需要 Visual Studio C++ Build Tools，macOS 需要 Xcode Command Line Tools，Linux 还需发行版对应的 WebKitGTK、音频和打包依赖。

gitclone https://github.com/Zackriya-Solutions/meetily.gitcdmeetily/frontendpnpminstall

先以 CPU 模式启动最容易排除 GPU 工具链问题：

pnpmrun tauri:dev:cpu

生成 CPU 安装包：

pnpmrun tauri:build:cpu

pnpm run dev只启动 Next.js 页面，无法完整验证 Tauri Command、音频设备和本地数据库。调试录音必须使用tauri:dev:*或项目脚本启动整个桌面应用。构建结果位于frontend/src-tauri/target/release/bundle/下的平台子目录。

项目提供自动检测脚本：

# Linux / macOS./dev-gpu.sh ./build-gpu.sh

# Windows PowerShell.\dev-gpu.ps1.\build-gpu.ps1

tauri-auto.js先读取TAURI_GPU_FEATURE，未指定时再检查平台和工具链：macOS 选择 Metal/CoreML，Windows/Linux 检查 CUDA，Linux 还检查 ROCm，之后检查 Vulkan、OpenBLAS，均不可用时退回 CPU。可以显式覆盖：

TAURI_GPU_FEATURE=vulkan ./build-gpu.shTAURI_GPU_FEATURE=cuda ./build-gpu.sh

Feature 只决定编译哪些推理后端，不能替代驱动与开发 SDK。电脑有 NVIDIA 显卡但没有nvcc，自动检测会退回 CPU；Vulkan 路径还检查VULKAN_SDK和BLAS_INCLUDE_DIRS。排障时先用 CPU 构建证明项目本身可编译，再逐步加入 GPU 依赖。

6.3 建立可复现的会议质量检查

第一次使用不要直接录一小时正式会议。准备一段包含静音、交叠说话、专有名词、数字和系统播放声音的短测试，检查：

• 麦克风与系统音频是否都进入最终 MP4；
• VAD 是否漏掉小声开头、把长句切得过碎；
• Whisper/Parakeet 对目标语言和专有名词的错误类型；
• 停止后是否仍有队列处理，最后几句是否出现；
• 文本时间戳能否定位到正确音频；
• 本地摘要耗时、内存占用以及行动项是否能回到原文；
• 关闭网络后，所选本地配置是否仍能完成转写和摘要。

升级应用或更换模型后复用同一段音频做对比，比凭印象判断“新模型更准”可靠。若实时模式积压明显，可保留录音并在会后重新转写；若摘要遗漏，应先检查逐字稿是否完整，再判断是文本分块、模板还是 LLM 的问题。

七、适用场景与总结

Meetily 适合个人工作会议、访谈、咨询、课程与内部讨论，尤其适合不方便让云端 Bot 加入会议、希望掌握录音保留策略的用户。它的技术亮点不是简单包一层 Whisper UI，而是把跨平台音频采集、双路混音、Silero VAD、两类本地 ASR、时间轴、检查点恢复、SQLite、可选本地摘要和 Tauri 桌面集成连成一条完整链路。

它也有清晰的适用边界。Community 0.4.0 更像单机会议工作台，不是面向全公司的多用户会议服务器；固定提交没有从活动链路证明 Community 说话人分离，也没有集群权限和高并发架构。云端摘要会改变数据边界，本地文件则需要操作系统加密、备份和访问控制配合。

推荐的落地顺序是：先用发布包和小模型打通本地转写，确认双路音频与时间轴；再按隐私要求选择 BuiltInAI、Ollama 或外部 LLM；最后建立短音频回归样本、录音同意规范与备份策略。这样使用 Meetily，获得的不只是一份自动生成的摘要，而是一套可验证、可校订、可恢复的本地会议记录流程。

参考资料

1. Meetily GitHub 仓库：https://github.com/cmyk-labs/meetily
2. Meetily 官方 GitHub 仓库：https://github.com/Zackriya-Solutions/meetily
3. Meetily 官方文档：https://docs.meetily.ai/
4. Meetily 官方网站：https://meetily.ai/