Pluely v1 评测：一个宣称「隐形」的 AI 会议助手，但源码已关闭
The Open Source Alternative to Cluely - A lightning-fast, privacy-first AI assistant that works seamlessly during meetings, interviews, and conversations without anyone knowing. Built with Tauri for native performance, just 10MB. Completely undetectable in video calls, screen shares, and recordings.
秒懂
- 它是什么？
- Pluely 是一个基于 Tauri 的桌面 AI 助手，主打会议、面试中的隐蔽问答与实时转写。v1 版本已从开源转为闭源分发，本文基于仓库与文档信息分析其机制、限制与适用人群。
- 适合谁用？
- Pluely v1 适合那些频繁参与远程会议、面试或销售通话，且需要即时、隐蔽的 AI 辅助的个人用户。它不适合需要完全自主可控、或希望基于源码二次开发的企业团队，因为 v1 已闭源，且 GPL-3.0 许可仅覆盖历史版本。
- 能商用吗？
- 可以，但有条件。GPL-3.0 是 copyleft 许可证：如果你分发包含它的软件，就必须以同一许可证公开该软件的源代码。只在内部运行、不对外分发，则不会触发这项义务。
- 还在维护吗？
- 在维护。仓库最近一次提交在 63 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
一个解决「切标签页就会冷场」问题的桌面工具
Pluely 针对的场景非常具体：在面试、销售通话、站会或现场调试中，你无法切换到浏览器去问 AI，因为那会打断对话节奏，甚至暴露你在用助手。它以一个浮动覆盖层的形式存在于桌面，声称在屏幕共享和录屏中不可见。目标用户是知识工作者，尤其是需要实时应答的远程会议参与者。与常见的会议机器人不同，它不加入会议，不产生参与者，因此没有「机器人被踢出」或「对方看到 bot 加入」的问题。这个定位切中了一个真实痛点，但 README 中强调的「隐形」能力需要操作系统层面的支持，这将在后文分析。
Ask 与 Listen 两种模式背后的数据流
Pluely v1 提供两种核心模式。Ask 模式允许你输入问题、用按键说话，或让应用捕获屏幕截图，你可以拖选区域或附加文件。文档提到文档会经过内置 OCR，并且上下文会保留给后续问题。Listen 模式则实时转录麦克风和系统音频，带有说话人标签和语言选择，并能在暂停或提问时自动生成建议回答。整个数据流是：音频或屏幕图像被捕获，经过本地或远程的语音转文字与 LLM 处理，结果以 Markdown 流式显示在覆盖层上。所有聊天、会议记录和文件保存在本地 SQLite 数据库中。这里的关键设计是「本地优先」，但 LLM 推理本身可能发生在远程，取决于你使用的模型或 API。
10MB 安装包与 Tauri 的选择：轻量但有代价
项目使用 Tauri 框架，Rust 后端加 Web 前端，安装包大小为 9 到 16 MB，相比 Electron 应用确实小很多。README 声称启动时间低于 100 毫秒，但这没有提供基准数据。Tauri 的轻量来自调用系统 WebView，而不是打包 Chromium，这减少了内存占用，但也意味着渲染行为依赖操作系统版本。对于需要屏幕捕获排除的功能，Tauri 需要调用原生 API，这在不同平台上的实现复杂度不同。轻量是真实优势，但「低于 100ms」这类数字在没有测试环境的情况下只能视为宣传语，不能当作工程指标。
「隐形」机制的实际边界：屏幕共享与录屏的排除
Pluely 宣称「从屏幕共享和录屏中隐藏」，这依赖于操作系统提供的窗口捕获排除机制。在 macOS 上，可以通过 NSWindow 的 setSharingType 实现；在 Windows 上，使用 SetWindowDisplayAffinity；Linux 则更复杂，取决于窗口管理器。README 提到可以隐藏 Dock 或任务栏图标，这进一步减少了视觉痕迹。但一个关键限制是：这种排除仅对遵守系统 API 的捕获软件有效。如果用户使用第三方录屏工具或某些会议软件的非标准捕获方式，覆盖层可能仍然可见。文档没有列出已验证的会议软件列表，因此「完全不可检测」的承诺需要用户自行测试。
从开源到闭源：许可与仓库现状的错位
仓库描述称这是「Cluely 的开源替代品」，但 README 明确说明 v1 之后源码转为闭源，原因是代码被反复打包出售。当前仓库的默认分支为 master，最近一次推送是 2026 年 7 月，发布了 v1.0.0。仓库仍标记为 GPL-3.0，但该许可仅适用于闭源前的历史版本。新版本以签名二进制形式分发，这意味着你无法从源码审计 v1 的隐身实现或数据上传行为。对于开源软件评估者来说，这是一个根本性变化：项目名义上是开源的，但实际交付物是专有软件。如果你依赖开源许可来保证可审计性，Pluely v1 不满足这个条件。
运行方式：自带密钥或托管模型，但配置需要看文档
根据 README，Pluely 允许你连接自己的 LLM 或语音转文字提供商，方式是使用 curl 模板，或接入已有的 AI CLI，如 Claude Code、Gemini CLI、Codex、Qwen Code 和 Ollama。这意味着你不必使用内置的托管模型。Pro 计划则提供 200 多个托管模型，无需管理 API 密钥。要开始使用，你需要从 pluely.com/download 下载对应系统的安装包，格式包括 .dmg、.msi、.deb 等。文档站点 docs.pluely.com 提供了 5 分钟快速入门指南。但仓库中没有提供从源码构建的指令，因为 v1 已闭源，所以你无法自行编译。配置自定义提供商时，你需要参考文档中的 curl 模板，这比直接填写 API 密钥更灵活，但也更复杂。
维护与升级成本：自动更新与闭源带来的依赖
README 提到更新会自动推送，这降低了手动升级的维护成本，但也意味着你无法控制何时升级，以及新版本是否改变了行为。由于没有源码，你无法自行修补 bug 或添加功能。GPL-3.0 许可仅适用于旧版本，如果你使用历史开源版本，需要遵守该许可的条款，包括分发衍生作品时提供源码。但如果你使用 v1 闭源版本，则受商业条款约束，即使产品「核心免费」。长期维护依赖单一维护者，从仓库历史看，发布频率不稳定，v0.1.8 到 v0.1.9 间隔约两个月，v0.1.9 到 v1.0.0 间隔六个月。升级到 v1 是一个重写，这意味着旧版插件或配置可能不兼容。
替代方案与差异：本地优先的 AI 助手还有哪些选择
与 Pluely 最接近的替代品是闭源的 Cluely 本身，但 Pluely 的差异化在于本地存储和可自带 API 密钥。另一个方向是使用开源的语音助手框架，例如 Whisper 加 Ollama 的组合，你可以用脚本实现类似转录和问答，但不会有覆盖层或屏幕捕获排除。更直接的对比是 Electron 类的 AI 助手，如一些笔记应用内置的 AI 功能，但它们的体积和内存占用更大。Pluely 的独特之处在于「隐形」覆盖层设计，而替代方案通常没有这种系统级集成。如果你不需要隐身，一个简单的浏览器标签页加 Whisper 转录可能就够用。如果你需要隐身，Pluely 是目前少数明确实现这一点的产品，但代价是闭源。
编辑结论
Pluely v1 适合那些频繁参与远程会议、面试或销售通话，且需要即时、隐蔽的 AI 辅助的个人用户。它不适合需要完全自主可控、或希望基于源码二次开发的企业团队，因为 v1 已闭源，且 GPL-3.0 许可仅覆盖历史版本。在采用前，应验证三件事：第一，确认你的操作系统（macOS、Windows 或 Linux）是否支持其屏幕捕获排除功能，尤其是 Linux 下的 Wayland 会话；第二，检查「自动响应」功能在会议软件中的实际触发延迟，因为文档未提供可量化的性能数据；第三，阅读 pluely.com 上的隐私政策，确认本地 SQLite 存储与云端同步（如有）的边界。最终判断是：Pluely 的「隐形」设计在技术上有创新，但闭源决策使其更像一个商业产品而非开源项目，若你依赖可审计性，它可能不是正确选择。
社区笔记