尧图网站建设 
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 服务的高层关系下面按当前活动代码进一步拆开桌面桥接、音频转写与摘要 SidecarNext.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建立三条协作链音频流把原始采样送入 PipelinePipeline 把混合结果送给录音保存器同时把 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 → 过滤过短片段 → 送入 ASRVAD 不是为了生成最终文字而是减少静音和背景噪声进入 ASR降低无效推理与静音幻觉。阈值过严会漏掉小声发言停顿时间过短会把一句话切碎过长又会增加实时等待。因此嘈杂会议中出现漏字时应先检查输入电平、设备与 VAD 分段再盲目更换大模型。3.2 Whisper 与 Parakeet 如何实现统一的TranscriptionProvider接口Meetily 为转写定义了TranscriptionProviderTrait输入是 16 kHz 单声道Vecf32和可选语言输出统一为文本、可选置信度与 partial 标记。当前TranscriptionEngine仍保留 Whisper 和 Parakeet 的直接变体同时提供 Trait 对象变体便于未来增加其他实现。引擎当前代码路径主要特点Whisperwhisper-rs加载本地 GGML.bin模型支持语言偏好并返回置信度和 partial 状态低于 0.3 的结果会被过滤ParakeetONNX 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:usize1;// 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 或 OpenBLASmacOS 使用 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。选择不同提供商时数据流向明显不同摘要方式数据流向适合场景BuiltInAITauri 通过标准输入输出调用打包的llama-helper模型和文本留在本机不希望安装独立推理服务希望开箱离线摘要Ollama请求默认发往http://localhost:11434/v1/chat/completions也可配置其他地址已经管理本地 Ollama 模型或使用内网推理节点CustomOpenAI请求发往用户填写的兼容/chat/completions端点企业内部网关、自建 vLLM 等兼容服务OpenAI/Claude/Groq/OpenRouter逐字稿和提示词发往相应公网 API更看重模型质量、速度和即用性并允许数据出网内置 AI 不是把一个 HTTP 服务常驻在后台。Tauri 管理llama-helperSidecarSidecar 基于llama_cpp_2加载本地 GGUF接收逐行 JSON 请求并返回结果。固定提交登记了 Qwen 3.5 2B/4B 与 Gemma 3 1B/4B 等模型每个模型携带文件、下载地址、上下文大小、层数和采样参数空闲默认 5 分钟后进程退出从而回收模型占用。4.2 长会议为什么要做分层摘要本地模型的上下文和内存通常小于云端模型一次把数小时逐字稿塞进 Prompt 容易超限。Meetily 先用字符数粗估 Tokenrough_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 指向远程地址后逐字稿会离开设备。因而判断“会议是否出网”应检查四类出口摘要 Provider 及其真实 Endpoint模型下载和应用自动更新用户主动开启的使用分析操作系统、备份软件或企业终端管理对录音目录的同步。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。首次启动通常需要完成以下配置授予麦克风权限并按平台提示授予系统音频/屏幕录制权限下载 Parakeet 或 Whisper 转写模型等待状态变为可用选择摘要方式内置 AI、本机 Ollama或自带 API Key用一段 3060 秒测试会议校验两路音频、电平、语言和转写停止后检查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 ToolsmacOS 需要 Xcode Command Line ToolsLinux 还需发行版对应的 WebKitGTK、音频和打包依赖。gitclone https://github.com/Zackriya-Solutions/meetily.gitcdmeetily/frontendpnpminstall先以 CPU 模式启动最容易排除 GPU 工具链问题pnpmrun tauri:dev:cpu生成 CPU 安装包pnpmrun tauri:build:cpupnpm 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.ps1tauri-auto.js先读取TAURI_GPU_FEATURE未指定时再检查平台和工具链macOS 选择 Metal/CoreMLWindows/Linux 检查 CUDALinux 还检查 ROCm之后检查 Vulkan、OpenBLAS均不可用时退回 CPU。可以显式覆盖TAURI_GPU_FEATUREvulkan ./build-gpu.shTAURI_GPU_FEATUREcuda ./build-gpu.shFeature 只决定编译哪些推理后端不能替代驱动与开发 SDK。电脑有 NVIDIA 显卡但没有nvcc自动检测会退回 CPUVulkan 路径还检查VULKAN_SDK和BLAS_INCLUDE_DIRS。排障时先用 CPU 构建证明项目本身可编译再逐步加入 GPU 依赖。6.3 建立可复现的会议质量检查第一次使用不要直接录一小时正式会议。准备一段包含静音、交叠说话、专有名词、数字和系统播放声音的短测试检查麦克风与系统音频是否都进入最终 MP4VAD 是否漏掉小声开头、把长句切得过碎Whisper/Parakeet 对目标语言和专有名词的错误类型停止后是否仍有队列处理最后几句是否出现文本时间戳能否定位到正确音频本地摘要耗时、内存占用以及行动项是否能回到原文关闭网络后所选本地配置是否仍能完成转写和摘要。升级应用或更换模型后复用同一段音频做对比比凭印象判断“新模型更准”可靠。若实时模式积压明显可保留录音并在会后重新转写若摘要遗漏应先检查逐字稿是否完整再判断是文本分块、模板还是 LLM 的问题。七、适用场景与总结Meetily 适合个人工作会议、访谈、咨询、课程与内部讨论尤其适合不方便让云端 Bot 加入会议、希望掌握录音保留策略的用户。它的技术亮点不是简单包一层 Whisper UI而是把跨平台音频采集、双路混音、Silero VAD、两类本地 ASR、时间轴、检查点恢复、SQLite、可选本地摘要和 Tauri 桌面集成连成一条完整链路。它也有清晰的适用边界。Community 0.4.0 更像单机会议工作台不是面向全公司的多用户会议服务器固定提交没有从活动链路证明 Community 说话人分离也没有集群权限和高并发架构。云端摘要会改变数据边界本地文件则需要操作系统加密、备份和访问控制配合。推荐的落地顺序是先用发布包和小模型打通本地转写确认双路音频与时间轴再按隐私要求选择 BuiltInAI、Ollama 或外部 LLM最后建立短音频回归样本、录音同意规范与备份策略。这样使用 Meetily获得的不只是一份自动生成的摘要而是一套可验证、可校订、可恢复的本地会议记录流程。参考资料Meetily GitHub 仓库https://github.com/cmyk-labs/meetilyMeetily 官方 GitHub 仓库https://github.com/Zackriya-Solutions/meetilyMeetily 官方文档https://docs.meetily.ai/Meetily 官方网站https://meetily.ai/ 【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 服务的高层关系下面按当前活动代码进一步拆开桌面桥接、音频转写与摘要 SidecarNext.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建立三条协作链音频流把原始采样送入 PipelinePipeline 把混合结果送给录音保存器同时把 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 → 过滤过短片段 → 送入 ASRVAD 不是为了生成最终文字而是减少静音和背景噪声进入 ASR降低无效推理与静音幻觉。阈值过严会漏掉小声发言停顿时间过短会把一句话切碎过长又会增加实时等待。因此嘈杂会议中出现漏字时应先检查输入电平、设备与 VAD 分段再盲目更换大模型。3.2 Whisper 与 Parakeet 如何实现统一的TranscriptionProvider接口Meetily 为转写定义了TranscriptionProviderTrait输入是 16 kHz 单声道Vecf32和可选语言输出统一为文本、可选置信度与 partial 标记。当前TranscriptionEngine仍保留 Whisper 和 Parakeet 的直接变体同时提供 Trait 对象变体便于未来增加其他实现。引擎当前代码路径主要特点Whisperwhisper-rs加载本地 GGML.bin模型支持语言偏好并返回置信度和 partial 状态低于 0.3 的结果会被过滤ParakeetONNX 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:usize1;// 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 或 OpenBLASmacOS 使用 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。选择不同提供商时数据流向明显不同摘要方式数据流向适合场景BuiltInAITauri 通过标准输入输出调用打包的llama-helper模型和文本留在本机不希望安装独立推理服务希望开箱离线摘要Ollama请求默认发往http://localhost:11434/v1/chat/completions也可配置其他地址已经管理本地 Ollama 模型或使用内网推理节点CustomOpenAI请求发往用户填写的兼容/chat/completions端点企业内部网关、自建 vLLM 等兼容服务OpenAI/Claude/Groq/OpenRouter逐字稿和提示词发往相应公网 API更看重模型质量、速度和即用性并允许数据出网内置 AI 不是把一个 HTTP 服务常驻在后台。Tauri 管理llama-helperSidecarSidecar 基于llama_cpp_2加载本地 GGUF接收逐行 JSON 请求并返回结果。固定提交登记了 Qwen 3.5 2B/4B 与 Gemma 3 1B/4B 等模型每个模型携带文件、下载地址、上下文大小、层数和采样参数空闲默认 5 分钟后进程退出从而回收模型占用。4.2 长会议为什么要做分层摘要本地模型的上下文和内存通常小于云端模型一次把数小时逐字稿塞进 Prompt 容易超限。Meetily 先用字符数粗估 Tokenrough_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 指向远程地址后逐字稿会离开设备。因而判断“会议是否出网”应检查四类出口摘要 Provider 及其真实 Endpoint模型下载和应用自动更新用户主动开启的使用分析操作系统、备份软件或企业终端管理对录音目录的同步。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。首次启动通常需要完成以下配置授予麦克风权限并按平台提示授予系统音频/屏幕录制权限下载 Parakeet 或 Whisper 转写模型等待状态变为可用选择摘要方式内置 AI、本机 Ollama或自带 API Key用一段 3060 秒测试会议校验两路音频、电平、语言和转写停止后检查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 ToolsmacOS 需要 Xcode Command Line ToolsLinux 还需发行版对应的 WebKitGTK、音频和打包依赖。gitclone https://github.com/Zackriya-Solutions/meetily.gitcdmeetily/frontendpnpminstall先以 CPU 模式启动最容易排除 GPU 工具链问题pnpmrun tauri:dev:cpu生成 CPU 安装包pnpmrun tauri:build:cpupnpm 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.ps1tauri-auto.js先读取TAURI_GPU_FEATURE未指定时再检查平台和工具链macOS 选择 Metal/CoreMLWindows/Linux 检查 CUDALinux 还检查 ROCm之后检查 Vulkan、OpenBLAS均不可用时退回 CPU。可以显式覆盖TAURI_GPU_FEATUREvulkan ./build-gpu.shTAURI_GPU_FEATUREcuda ./build-gpu.shFeature 只决定编译哪些推理后端不能替代驱动与开发 SDK。电脑有 NVIDIA 显卡但没有nvcc自动检测会退回 CPUVulkan 路径还检查VULKAN_SDK和BLAS_INCLUDE_DIRS。排障时先用 CPU 构建证明项目本身可编译再逐步加入 GPU 依赖。6.3 建立可复现的会议质量检查第一次使用不要直接录一小时正式会议。准备一段包含静音、交叠说话、专有名词、数字和系统播放声音的短测试检查麦克风与系统音频是否都进入最终 MP4VAD 是否漏掉小声开头、把长句切得过碎Whisper/Parakeet 对目标语言和专有名词的错误类型停止后是否仍有队列处理最后几句是否出现文本时间戳能否定位到正确音频本地摘要耗时、内存占用以及行动项是否能回到原文关闭网络后所选本地配置是否仍能完成转写和摘要。升级应用或更换模型后复用同一段音频做对比比凭印象判断“新模型更准”可靠。若实时模式积压明显可保留录音并在会后重新转写若摘要遗漏应先检查逐字稿是否完整再判断是文本分块、模板还是 LLM 的问题。七、适用场景与总结Meetily 适合个人工作会议、访谈、咨询、课程与内部讨论尤其适合不方便让云端 Bot 加入会议、希望掌握录音保留策略的用户。它的技术亮点不是简单包一层 Whisper UI而是把跨平台音频采集、双路混音、Silero VAD、两类本地 ASR、时间轴、检查点恢复、SQLite、可选本地摘要和 Tauri 桌面集成连成一条完整链路。它也有清晰的适用边界。Community 0.4.0 更像单机会议工作台不是面向全公司的多用户会议服务器固定提交没有从活动链路证明 Community 说话人分离也没有集群权限和高并发架构。云端摘要会改变数据边界本地文件则需要操作系统加密、备份和访问控制配合。推荐的落地顺序是先用发布包和小模型打通本地转写确认双路音频与时间轴再按隐私要求选择 BuiltInAI、Ollama 或外部 LLM最后建立短音频回归样本、录音同意规范与备份策略。这样使用 Meetily获得的不只是一份自动生成的摘要而是一套可验证、可校订、可恢复的本地会议记录流程。参考资料Meetily GitHub 仓库https://github.com/cmyk-labs/meetilyMeetily 官方 GitHub 仓库https://github.com/Zackriya-Solutions/meetilyMeetily 官方文档https://docs.meetily.ai/Meetily 官方网站https://meetily.ai/