Show HN：使用视觉和语音的开源 macOS AI 副驾

整体反响

• 许多评论者觉得这个应用“很酷”，是很好的“Show HN”式 MVP，尤其适合更快学习复杂软件（例如 Ableton Live）。
• 也有人对其实用性持怀疑态度，指出一些演示看起来很泛泛，类似 Eliza，响应较慢，而且似乎对内容的理解有限。
• 也有不少人称赞“LLM 作为界面”的概念，并预见语音/视觉助手会在各种设备和操作系统上变得普遍。

技术栈（Electron vs 原生）

• 有人批评在一个 macOS 专用工具中使用 Electron，认为这会带来性能和系统集成方面的顾虑。
• 另一些人则认为，Electron 对于首个项目和快速做 MVP 来说是务实选择；技术栈选择相比于先把产品做出来并从中学习而言是次要的。
• 建议包括 Swift/SwiftUI、AppKit，或像 Tauri 这样更小、更有原生感的应用方案。
• 还有人提到，Windows 支持可能只需相对较少的代码改动就能实现。

隐私、安全与企业使用

• 多条评论警告说，把任意截图发送到第三方云端（OpenAI Vision API）在许多企业或受监管环境中是不可接受的。
• 也有人反驳称：
  • 这种风险与基于云的屏幕共享工具类似。
  • 能配置 API key 的用户应该明白离站数据风险和企业政策。
  • OpenAI 声称 API 数据不会用于训练，不过人们对这一说法的信任程度不一。
• 有人提到，部分项目通过实现 PII 清理作为缓解策略。

对 OpenAI 的依赖 vs 本地模型

• 许多评论者不喜欢依赖 OpenAI 和远程视觉模型，希望：
  • 一个完全本地、离线的版本，使用开源模型（例如 LLaVA、Whisper、本地多模态方案）。
  • 一个兼容 OpenAI 的本地 API，这样应用只需指向 localhost 即可。
• 有人指出，由于该项目是开源的，原则上可以把对 OpenAI 的调用替换为自托管模型，不过对于视觉部分来说这并不简单。

功能、UX 与扩展

• 受欢迎的功能请求包括：
  • 除语音外或同时支持文本输入/输出（适用于安静环境或没有麦克风的设备）。
  • 流式文本回复，而不仅仅是 TTS。
  • 更好的窗口行为（自动隐藏、可配置性）。
  • 由于 Vision API 的定价和速率限制，需要成本/提示词估算器。
• 作者在收到反馈后增加了文本输入模式。
• 还提出但（尚）未实现的想法包括：
  • 集成 macOS 辅助功能 API 来读取文本或执行操作。
  • 让代理通过驱动程序直接点击/输入并操控 UI。
  • 基于当前应用、终端历史或 OCR 的上下文感知提示词。
  • 将其作为车载/现实世界助手的模型，把地图、音频和视觉结合起来。

比较与相关工具

• 评论者提到的类似工具包括：
  • 面向终端的命令行 AI 助手。
  • 本地语音/视觉助手。
  • macOS GPT 客户端和基于 Web 的封装。
• 有些人认为这个项目是操作系统级副驾的原型，未来大厂很可能会推出类似产品。