基于Rust与Tauri构建本地AI会议助手：开源、免费、隐私优先

1. 项目缘起：从“订阅疲劳”到“本地优先”的觉醒

不知道从什么时候开始，生产力软件从你“购买”的东西，变成了你“租用”的东西。你需要一个AI会议记录员？每月18美元。你还希望它能生成行动项？升级到专业版。需要它在多个设备上同步？那是另一个付费层级。哦，对了——如果你哪天取消了订阅，你的笔记理论上还“在我们的云端”，但想再访问它们？祝你好运。

这种模式让我感到厌倦。不是轻微的不快，而是真正意义上的、彻底的厌倦。我的工作充斥着背靠背的会议，一个AI会议助手对我来说确实有用。但我无法接受为一项我的笔记本电脑自身就能完成的功能，持续支付一笔订阅费。于是，我决定自己动手，构建了Oats AI——一个免费、本地运行、开源的AI会议助手。没有订阅，没有云端依赖，没有付费墙。

这背后的核心驱动力，是一种对“所有权”的回归渴望。我们使用的工具，正在越来越多地控制我们的数据和工作流。当服务中断、价格调整，或者你决定离开时，你创造的内容和形成的习惯就可能面临风险。Oats AI的诞生，正是对这种趋势的一次具体回应：将控制权交还给用户，让强大的AI能力在本地、私密、一次性的环境中为你服务。

2. 核心设计哲学：极简、本地与实用主义

Oats AI的设计遵循一套清晰的原则，我称之为“禅意极简主义”工作流。这不是一个功能臃肿的瑞士军刀，而是一把精心打磨的专用刻刀。

2.1 “禅意极简主义”界面设计

整个应用只有两个核心面板，布局清晰，毫无干扰。左侧是手动笔记区，保留了最传统的记录方式，让你在听会时能快速记下灵感或关键词。右侧是实时转录区，文字随着会议发言逐行滚动呈现。两个面板并置的设计，源于一个简单的洞察：人在处理信息时，需要“输入”和“输出”的并置参照。手动笔记是你的主动思考，AI转录是客观记录，两者对照，能最大程度避免信息遗漏。

在界面角落，有一个微小的、规律脉动的视觉指示器，我们称之为“麦浪脉冲”。它的唯一作用就是告诉你：“我正在聆听。”没有闪烁的广告，没有烦人的通知，没有复杂的仪表盘。当会议结束，你点击“总结”按钮，AI开始工作，生成关键要点和行动项。整个体验的目标是：让你捕获所需，然后继续你的一天。就像它的名字“燕麦”所寓意的一样——不华丽，但提供你真正需要的营养。

2.2 坚定不移的“本地优先”架构

这是Oats AI与市面上绝大多数同类工具的根本区别。大多数AI会议工具的工作流程是：录制你的会议音频 -> 上传到他们的服务器 -> 在云端进行语音识别和自然语言处理 -> 将结果返回给你。这套流程能提供更“顺滑”的体验，也构成了他们收取月费的理由——云服务器和算力不是免费的。

Oats AI彻底颠覆了这个模式。所有处理都在你的设备上完成：

1. 音频捕获：直接调用操作系统底层的音频API。在Windows上使用WASAPI环回接口，在macOS上使用ScreenCaptureKit。这意味着应用可以直接捕获系统播放的音频流，无需安装虚拟音频驱动，也无需管理员权限。你的会议声音从未离开过你的声卡。
2. 语音转录：使用whisper.cpp，这是一个高度优化的C++移植版，它让OpenAI强大的Whisper语音识别模型能够高效地在你的CPU或GPU上运行，完全不需要网络连接。无论是英特尔芯片还是苹果硅，它都能利用本地算力完成繁重的识别任务。
3. 数据存储：所有的转录文本、笔记和生成的摘要，都存储在一个本地SQLite数据库中，这个数据库文件就放在应用目录旁。没有账户体系，没有云同步开关，也没有任何服务商能在理论上接触到你的会议录音。对于日常涉及敏感商业对话的企业环境来说，这种隐私保障的价值，远超过大多数工具愿意承认的程度。

注意：选择whisper.cpp而非原版PyTorch实现的Whisper，是出于性能和部署便利性的权衡。原版模型对Python环境和GPU内存有较高要求，而whisper.cpp将模型转换为GGML格式，大幅降低了内存占用，并提供了纯C++的推理实现，使得将其打包进一个独立的Rust桌面应用变得可行。虽然识别精度在极端口音或嘈杂环境下可能略有损失，但对于清晰的会议语音，其准确性已完全满足商用要求。

2.3 关于“免费”的重新定义

在今天SaaS（软件即服务）的世界里，“免费”这个词已经变得面目全非。Oats AI试图回归这个词的本意：

• 没有14天试用期：下载即用，功能完整。
• 没有“免费版”功能限制：实时转录、总结、本地存储，所有核心功能一视同仁。
• 没有“个人免费，团队收费”的套路：无论你是独自使用还是团队共享（通过分享应用本身），它都是免费的。
• 永远不需要信用卡：从下载到使用的全生命周期，你不会被要求绑定任何支付方式。

应用的代码完全开源，托管在GitHub上。任何人都可以审查代码、参与贡献，或者基于此构建自己的版本。这种开放性，是信任的基石。

3. 技术栈深度解析：为什么是Rust和Tauri？

构建一个本地优先、高性能的桌面应用，技术选型至关重要。Oats AI选择了Rust + Tauri的组合，这是一次深思熟虑的“现代原生应用”实践。

3.1 选择Rust：性能、安全与可控性

Rust语言是项目的基石，它带来了几个决定性的优势：

• 零成本抽象与极致性能：会议音频的实时处理是计算密集型任务。Rust允许我们编写高性能的音频处理和数据推理代码，而无需像C/C++那样手动管理内存，也避免了Python等解释型语言在循环和数值计算上的性能开销。whisper.cpp本身是C++库，通过Rust的FFI（外部函数接口）可以高效、安全地调用，形成强大的本地算力引擎。
• 内存安全与线程安全：音频流处理、AI模型推理、用户界面响应需要多线程协作。Rust的所有权系统和生命周期检查器在编译期就杜绝了数据竞争和内存泄漏这类在C++中常见的棘手问题，这对于需要长时间稳定运行的后台服务型应用至关重要。
• 强大的生态系统与打包：Rust的cargo构建工具和包管理器使得管理复杂依赖（如音频库、数据库驱动、模型推理库）变得异常清晰。最终，我们可以将所有依赖和模型文件编译链接成一个独立的、静态的可执行文件，实现真正的“单一二进制文件”分发。

3.2 选择Tauri：轻量级窗口与系统集成

Tauri是一个构建小型、快速桌面应用的框架。与Electron等基于Chromium的方案相比，它的优势非常明显：

• 极小的体积与内存占用：Tauri使用操作系统自带的WebView（在Windows上是WebView2，在macOS上是WKWebView，在Linux上是WebKitGTK）来渲染界面。这意味着应用本体可以非常小（Oats AI的安装包在20MB左右），并且运行时内存占用极低，不会像Electron应用那样动辄占用数百MB内存。
• 强大的系统原生API调用能力：Tauri提供了一套优雅的机制，让前端JavaScript可以安全地调用后端Rust编写的系统级功能。这正是Oats AI所需要的：前端界面监听按钮点击，后端Rust代码处理音频捕获、调用Whisper模型、读写SQLite数据库。这种前后端分离但紧密结合的模型，既保证了界面的灵活性（使用HTML/CSS/JS任意前端框架），又确保了核心业务的性能和安全性。
• 无缝的打包与分发：Tauri能轻松地为Windows、macOS和Linux生成安装包，并处理应用图标、菜单、系统托盘等原生功能，大大降低了跨平台桌面开发的复杂度。

实操心得：Rust与Tauri的集成要点在实际开发中，将whisper.cpp这样的本地C++库集成进Rust+Tauri项目，需要一些技巧。通常的步骤是：

1. 将whisper.cpp的源码作为子模块引入，并编写一个build.rs脚本，指导Cargo如何编译这些C++代码。
2. 创建Rust的unsafe外部函数声明（extern "C"），来映射whisper.cpp暴露的核心C API。
3. 在这些unsafe包装器之上，构建一层安全的、符合Rust习惯的API，供Tauri的后端命令调用。
4. 在Tauri的tauri.conf.json中，正确声明这些需要调用的后端命令，并配置前端绑定的权限。

这个过程虽然初期有学习成本，但一旦打通，你就获得了一个兼具原生性能、安全性和现代开发体验的坚实基础。

4. 核心功能实现细节与实操指南

4.1 实时音频捕获：绕过虚拟驱动的系统级方案

大多数录音软件需要你安装一个虚拟音频电缆驱动，将系统声音重定向到虚拟输入设备，然后才能录制。Oats AI避开了这个繁琐且需要权限的步骤。

在Windows上的实现（WASAPI Loopback）： Windows Audio Session API (WASAPI) 的环回模式允许应用程序捕获正在由音频端点设备（如扬声器或耳机）渲染的音频流。关键步骤如下：

// 伪代码，展示核心逻辑 use windows::Media::Audio; // 1. 获取默认的音频渲染设备（扬声器） let render_device = AudioDevice::GetDefaultRenderDevice(); // 2. 激活该设备上的音频客户端，并指定为环回模式 let audio_client = render_device.Activate::<IAudioClient>(LOOPBACK, CLIENT_EVENTS); // 3. 初始化音频客户端，设置格式（通常为44.1kHz/48kHz, 16-bit stereo） audio_client.Initialize(SHARED, STREAMFLAGS_LOOPBACK, buffer_duration); // 4. 获取捕获客户端，开始捕获数据 let capture_client = audio_client.GetService::<IAudioCaptureClient>(); let packet = capture_client.GetBuffer(); // 这里得到的就是系统播放的原始PCM数据

获取到的PCM数据会被送入一个缓冲区，等待whisper.cpp进行处理。这种方法的优势是零配置，对用户完全透明。

在macOS上的实现（ScreenCaptureKit）： 从macOS 12.3开始，ScreenCaptureKit API提供了强大的屏幕、窗口和音频捕获能力。用于捕获系统音频时：

// 伪代码，Swift示意 import ScreenCaptureKit // 1. 创建一个音频内容过滤器，指定捕获系统音频 let audioFilter = SCContentFilter(audio: .system) // 2. 创建流配置 let streamConfig = SCStreamConfiguration() streamConfig.capturesAudio = true // 3. 创建流并开始捕获 let stream = SCStream(filter: audioFilter, configuration: streamConfig, delegate: self) try stream.addStreamOutput(self, type: .audio, sampleHandlerQueue: audioQueue) try stream.startCapture()

在委托的回调中，你会收到包含音频样本缓冲区的CMSampleBuffer，可以将其提取并转换为whisper.cpp所需的格式。

重要提示：在macOS上使用ScreenCaptureKit需要用户在系统设置-隐私与安全性-屏幕录制中授权该应用。这是操作系统级别的安全限制，应用首次尝试捕获时会自动触发系统弹窗引导用户授权。这是保障用户隐私的必要步骤。

4.2 本地语音识别：Whisper.cpp的集成与优化

whisper.cpp是项目的核心引擎。集成它不仅仅是调用一个函数那么简单，需要考虑实时性、资源占用和准确性之间的平衡。

模型选择与加载：whisper.cpp支持多种规模的Whisper模型（tiny, base, small, medium, large）。对于实时会议转录，我们通常选择small或base模型。

• tiny和base模型：速度极快，内存占用小（小于150MB），适合配置较低的机器，但复杂句子或专业术语的识别准确率会下降。
• small模型：在速度和准确率之间取得了很好的平衡，是大多数场景的推荐选择。内存占用约500MB。
• medium和large模型：准确率最高，但推理速度慢，内存占用大（>1GB），不适合实时场景，更适合事后处理录音文件。

Oats AI在首次启动时，会从开源镜像下载选定的模型文件（.bin格式）到本地用户目录。之后每次启动直接加载，无需网络。

实时流式处理策略： 纯粹的Whisper模型是为整段音频设计的。为了实现“实时”感，我们需要采用流式处理：

1. 音频缓冲与分块：将持续捕获的音频数据（如每500毫秒）填充到一个环形缓冲区。
2. 语音活动检测（VAD）辅助：简单的能量检测或使用专门的VAD库（如webrtc-vad）来判断当前缓冲区是否包含有效语音。只在有语音时才送入模型，可以节省大量算力。
3. 上下文窗口：将当前语音块与前几秒的音频上下文一起送入模型进行识别，可以提高识别连贯性，尤其是处理句子中间被切分的情况。
4. 结果聚合与去重：模型会输出带时间戳的文本片段。需要将连续片段的文本拼接起来，并处理可能出现的重复识别（当一句话跨越两个音频块时，模型可能会在边界处重复输出部分词语）。

GPU加速（如果可用）：whisper.cpp支持通过CUDA（NVIDIA）或Metal（Apple Silicon）进行GPU加速。在应用设置中，可以提供一个选项让用户选择推理后端（CPU、CUDA、Metal）。启用GPU后，转录速度会有显著提升，同时降低CPU占用，让电脑在开会时仍能流畅运行其他程序。

4.3 AI总结与行动项提取：本地与云端双引擎保障

会议结束后的总结功能，是Oats AI超越单纯转录器的关键。这里设计了一个优雅的降级策略：优先使用免费的云端大模型API，如果不可用，则自动降级到本地轻量模型。

首选方案：OpenRouter免费APIOpenRouter是一个聚合了多家AI模型提供商（如Anthropic、Google、Mistral AI）的平台，它提供一个统一的API，并且有非常慷慨的免费额度。实现流程如下：

1. 用户自主获取API密钥：用户需要访问OpenRouter网站，用GitHub或Google账号注册，在控制台生成一个免费的API密钥。这个密钥完全属于用户，Oats AI仅在前端本地存储（如使用localStorage）以供调用，不会发送到我们的服务器。
2. 构建提示词（Prompt）：将完整的会议转录文本，连同精心设计的指令，发送给OpenRouter API。指令示例：

   你是一个专业的会议纪要助手。请仔细阅读以下会议转录文本，并生成一份简洁的总结，需包含： 1. 会议核心讨论要点（3-5条）。 2. 明确的行动项（Action Items），每条需包含“负责人”（如可推断）、“具体任务”和“截止时间”（如提及）。 请用清晰的中文（或英文，根据会议语言）输出，格式工整。 转录文本：[此处插入完整的会议转录]

3. 调用与解析：应用使用用户的密钥直接调用OpenRouter API（例如，选择mistralai/mistral-7b-instruct或google/gemma-3-4b-it这类免费的较小模型），接收返回的JSON格式结果，解析并格式化后展示给用户。

降级方案：内置本地总结器考虑到网络问题、API服务不稳定或用户极度注重隐私的情况，Oats AI内置了一个轻量级的本地总结引擎。这个引擎通常基于一个在本地运行的、参数较少的开源语言模型（例如，通过llama.cpp运行的TinyLlama或Phi-2模型）。

• 工作原理：本地模型同样接收转录文本和提示词，但在本地CPU/GPU上进行推理。速度会比云端API慢，且总结质量可能稍逊于更大的云端模型，但保证了绝对的可离线工作和数据隐私。
• 触发条件：当应用检测到网络不通，或调用OpenRouter API超时/失败时，会自动切换至本地模式，并在界面上给出提示。

这种双引擎设计确保了核心功能的鲁棒性：你永远可以拿到一份会议总结，无论是否联网。

4.4 数据持久化：简单可靠的本地存储

所有数据都存储在一个SQLite数据库文件中（例如oats_ai.db），位于应用配置目录下（如macOS的~/Library/Application Support/Oats AI/， Windows的%APPDATA%\Oats AI）。

数据库表结构设计简单高效：

• meetings表：存储每次会议的基本信息（开始时间、结束时间、自定义标题等）。
• transcripts表：存储完整的转录文本，与meetings表关联。
• actions表：存储AI提取或用户手动添加的行动项，包含任务描述、负责人、截止时间、状态等字段。
• notes表：存储用户在手写笔记区输入的内容。

使用SQLite的FTS5（全文搜索）扩展，可以为转录文本和笔记建立全文搜索索引，方便用户日后快速查找某次会议上讨论过的特定话题。所有数据备份，就是复制这个数据库文件。迁移到新电脑，也只需移动这个文件。

5. 构建、分发与社区运营实践

5.1 从源码到可分发二进制文件

为了让用户获得“下载即用”的体验，自动化构建和打包流程至关重要。我们使用GitHub Actions来实现跨平台的持续集成。

GitHub Actions工作流核心步骤：

1. 环境准备：在ubuntu-latest,windows-latest,macos-latest三个runner上分别触发构建。
2. 安装Rust和Node.js：因为Tauri前端可能使用Node.js生态工具（如npm, yarn）。
3. 缓存依赖：缓存Cargo的registry和target目录，以及前端的node_modules，大幅加速后续构建。
4. 前端构建：运行npm install和npm run build，生成前端静态资源。
5. 后端构建与打包：运行cargo tauri build。Tauri CLI会处理所有繁重的工作：编译Rust代码，捆绑前端资源，下载并打包Whisper模型文件，为每个平台生成相应的安装包（Windows的.msi/.exe， macOS的.dmg/.app， Linux的.AppImage/.deb）。
6. 上传制品：将生成的安装包作为构建产物上传，供用户下载。

处理模型文件： Whisper模型文件（几百MB）不能直接放在代码仓库里。我们的解决方案是：

• 在构建脚本中，检查目标平台，然后从稳定的开源镜像（如Hugging Face）下载指定版本的模型文件到临时目录。
• 在Tauri的配置中，将这些模型文件指定为“资源文件”，Tauri在打包时会自动将其包含进应用包内。
• 应用首次运行时，再将这些资源文件解压或复制到用户的可写数据目录中。这样既控制了Git仓库大小，又保证了用户开箱即用。

5.2 开源协作与社区反馈

将项目完全开源在GitHub上，带来了意想不到的积极影响。

• 问题发现与修复更快：开发者同行会提交Issue报告bug，甚至直接提交Pull Request修复问题。一个关于macOS特定版本上音频捕获的棘手问题，就是由社区贡献者发现的解决方案。
• 功能建议的众包：GitHub的Discussion板块成了功能需求的集散地。有人提议增加“说话人分离”功能，有人想要导出为Markdown格式，还有人建议集成日历。这些讨论帮助我们规划路线图，并区分需求的普遍性。
• 安全性与信任：代码公开可审阅，彻底消除了用户对“后门”或数据滥用的担忧。这对于一个处理音频数据的工具来说，是至关重要的信任凭证。

维护一个开源项目的实操心得：

1. 清晰的README：README是项目的门面。必须包含：简洁有力的项目介绍、功能特性列表、清晰的下载安装指南、简明扼要的构建说明、贡献指南以及常见问题解答。
2. 管理Issue模板：设置Bug报告和功能请求的模板，引导用户提供必要信息（如操作系统版本、应用版本、复现步骤），能极大提高沟通效率。
3. 版本发布与更新：使用语义化版本控制。每次发布新版本时，在GitHub Releases页面撰写详细的更新日志，说明新特性、改进和修复的问题。考虑内置一个简单的更新检查机制（例如，启动时请求一个包含最新版本号的JSON文件），提升用户体验。
4. 保持焦点：作为个人或小团队项目，很容易被纷至沓来的功能建议淹没。必须坚持项目的核心哲学（极简、本地、免费），对不符合主线的需求勇敢说“不”，或者将其标记为“未来可能考虑”。

6. 常见问题、故障排查与性能调优

在实际使用和用户反馈中，我们积累了一系列典型问题和解决方案。

6.1 音频捕获相关问题

6.2 总结功能相关问题

6.3 性能与资源调优建议

Oats AI设计为轻量，但在低配电脑或处理超长会议时，仍可进行优化：

• 实时转录模型选择：在设置中优先选择tiny或base模型。对于大多数语音清晰的会议，base模型在速度和精度上已有很好平衡。
• 关闭实时预览：如果不需要边开会边看逐字稿，可以在设置中关闭“实时转录显示”，让应用只后台录音和缓存音频，会后一次性转录。这能显著降低实时渲染文本带来的界面开销。
• 管理历史数据：定期在应用内清理早期的、不再需要的会议记录。可以直接在界面删除，或手动删除数据库文件（位于应用配置目录），以释放磁盘空间。
• GPU加速：如果你的电脑有NVIDIA独立显卡或苹果M系列芯片，务必在设置中启用CUDA或Metal加速。这通常是提升性能最有效的手段。

7. 从WicaraAI到Oats AI：产品思维的演进

有些用户可能知道我们之前的产品WicaraAI，一个本地的音视频文件转录工具。WicaraAI是一个优秀的“单点工具”，它把一件事做到了极致：给你一个文件，还你一份精准的转录稿。

但Oats AI代表了一种产品思维的演进。我们意识到，在真实的会议场景中，一份完整的逐字稿往往不是终点，而是起点。用户真正的痛点是信息过载和行动失焦。他们需要的不是“所有说了什么”，而是“我们决定了什么”以及“接下来要做什么”。

因此，Oats AI没有选择在转录的准确率上无止境地内卷（当然它依然优秀），而是向前迈了一步，聚焦于“理解”和“提取”。它将转录作为基础设施，在此基础上构建了实时性和总结性这两个更贴近会议核心价值的功能。它继承了WicaraAI的所有优点——本地、免费、开源、隐私，并将这些优点应用到了一个更完整、更闭环的用户场景中。

这种演进也反映了我们对工具的看法：最好的工具应该融入工作流，而不是制造新的工作流。Oats AI不要求你改变开会的方式，不要求你安装复杂的插件，不要求你的同事也使用它。它只是一个安静的、高效的倾听者和整理者，在你需要的时候给你支持，在你结束后帮你收尾。

构建Oats AI的过程，是一次对抗软件“租借化”和复杂性膨胀的个人实践。它证明，利用现代开源技术和本地算力，我们完全有能力创造出既强大又尊重用户隐私和所有权的工具。它可能没有SaaS产品那些花哨的“团队协作看板”或“会议效率分析”，但它切实地解决了一个高频、刚需的问题，并且以一种让你感到安心和掌控的方式。

如果你也厌倦了为那些本质上在你自己电脑上运行的功能支付没完没了的订阅费，如果你看重数据的隐私和安全，那么Oats AI或许就是你一直在找的那个“燕麦式”的工具——朴实、营养、管饱。项目的所有代码都在GitHub上，欢迎你来使用、审视，甚至一起让它变得更好。这不仅仅是一个工具，也是关于我们如何与科技共处的一种选择。