LocalClicky

当LocalClicky决定需要“看屏幕”时，在实践中你如何确保其可靠和安全——有哪些护栏机制来防止误点击或破坏性操作，以及在实际工作流中如何处理确认/重试？

嘿PH！我构建了LocalClicky，因为我试过的每个语音助手都做了同样的取舍：你获得便利，他们获取你的数据。音频上传，截图发送到服务器，命令被记录。

LocalClicky颠覆了这点。整个栈都是本地的：Whisper用于转录，Ollama（qwen3 + gemma4）用于推理和视觉，macOS say用于响应。没有任何东西回传。你的语音、屏幕、命令都不会出去。

会话模型让它感觉很自然——你说一次“Computer”，它就会保持待命（就像Siri的加强版）。你可以链式命令、追问后续问题，说“bye”结束。VAD在你停止说话时立即停止录音，所以没有固定超时的尴尬。

它是开源的，还很早期。当前首要贡献者优先任务是替换Google Speech Recognition唤醒词，用完全离线的方案。GitHub链接在评论里，欢迎任何问题。

试试看！！！

我把它改成了Jarvis语音（openwakeord + whipser + piper）。

唤醒词——最薄弱的环节。讽刺的是，一个“离线”应用居然要打电话给Google来听唤醒词（需要联网，而且不精确）。我会换成Picovoice Porcupine——100%离线运行，非常准确，而且它直接内置了一个现成的“Jarvis”关键词。（免费替代：openWakeWord，你可以训练它。）这一项改动就解决了可靠性，并有了一个真正的Jarvis触发器。

语音——为了真正的电影感Jarvis。Daniel（已完成）是免费的快速方案。更高级别：Piper（本地，免费，比say自然得多）或ElevenLabs（云服务，付费——那里的英式男性声音听起来真像电影里那样）。取舍：Piper完全离线；ElevenLabs音效最好但云端。

点击——使用视觉模型猜测像素坐标（这就是为什么“点击X”有时准有时不准）。更稳健的设计是通过macOS的Accessibility API读取实际屏幕上的按钮。

很喜欢这种本地优先的方法。会话模型也感觉是语音控制的正确UX，比单次命令更接近真实对话。

好奇你在点击或破坏性操作之前的安全层是如何考虑的，特别是因为一切都能在本地看到/控制Mac。计划是为某些操作类型添加确认，还是保持轻量并依赖重试/反馈？

完全本地的Whisper + Ollama栈使得Google唤醒词成了最后一个回传组件——有趣的是链中最小的模型反而是最难切断连接的。实际阻碍离线替换的原因是什么？

完全本地化的技术栈这点特别打动我。我做的正是居家养老场景下的语音AI，每次跟家属沟通几乎都会提到隐私问题——因为涉及的数据（健康、日常作息、谁来过）实在太敏感了。像你们这样把Whisper和LLM都放在设备本地运行，就能彻底消除一大块顾虑。不过我很好奇：在较旧或性能较低的Mac上，从语音结束到本地模型给出语音回复，实际延迟大概是多少？哪些模型尺寸还能保持可用？这个延迟通常决定了本地语音交互是让人感觉像真实对话，还是开始让人觉得不自然。