Hey-Jarvis on Armstrong Yan

Hey Jarvis 的未来：当 AI 需要自己的入口

Thu, 13 Aug 2026 14:13:57 +0800

在这个系列的第一篇里，我写到 Hey Jarvis 来自一个很小的需求：我和老婆晚上睡觉前聊天，遇到想知道的问题时，希望不用拿起手机，直接问一句就能得到答案。

后来我做出了 Pipeline、Realtime 和 Mac App，也处理了语音交互与 Mac 产品化中的一系列问题。

做到这里以后，我反而越来越清楚地看到一个限制：

AI 可以越来越聪明，但如果它没有一个自然、稳定并且值得信任的入口，它仍然只是一个需要被主动打开的应用。

我最初很容易把这个问题归结为一句更情绪化的话：Siri 阻碍了 AI 助手的发展。

现在我觉得，这句话只说对了一半。

Siri 既是助手，也是系统入口链接到标题

从使用者的角度看，Siri 最特别的能力不一定是回答得有多聪明，而是它已经存在于系统里。

它拥有唤醒词、锁屏入口、麦克风权限、系统界面和设备之间的身份。使用者不需要先找到一个应用，也不需要理解哪个后台进程正在运行。说出一句话，入口就在那里。

第三方 AI 应用即使拥有更好的模型，也很难获得完全相同的位置。

Apple 并非完全关闭第三方能力。通过 App Intents，应用可以把自己的动作和内容以结构化方式提供给 Siri、Apple Intelligence、Spotlight 和 Shortcuts。2026 年的更新还继续增加了长时间后台任务、可取消任务、跨设备实体以及敏感操作确认等能力。Apple 也已经公布新一代 Siri AI，强调个人上下文、屏幕理解、网络知识和跨应用操作。

但这里有一个重要区别：

把应用的能力提供给系统助手
≠
让应用自己成为系统助手

第三方可以把一个动作交给 Siri 调用，却不等于可以拥有自己的系统级唤醒词、在所有状态下持续等待，或者无摩擦地取代默认语音入口。

一个很具体的例子是，Apple 目前确实允许第三方 conversational app 通过 iPhone 侧键启动，但官方的 assistant activation 能力只面向日本，需要专门的 Side Button Access entitlement，并受地区与设备条件限制。

这说明 Apple 不是不知道第三方语音助手需要硬件入口。恰恰相反，这个入口重要到必须被平台单独定义、授权和限制。

Hey Jarvis 的困难 II：从 Demo 到 Mac 产品

Thu, 13 Aug 2026 14:08:41 +0800

在上一篇里，我写了 Hey Jarvis 怎样处理确认音、回声、打断和麦克风交接。

当这些能力在终端和浏览器里跑通时，我一度觉得产品最困难的部分已经完成了。

后来我才意识到，那只是证明了一条语音流程可以工作。

一个 Demo 只需要在我准备好的环境里成功一次。一个产品则必须面对第一次安装、权限拒绝、窗口切换、电脑锁屏、系统睡眠、子进程崩溃和应用退出。它不但要成功，还要在无法成功时停在一个安全、诚实、可以恢复的状态。

Demo 证明一件事能发生。产品必须决定其他所有事情发生时怎么办。

产品化不是给 Python 加一个窗口链接到标题

最早的 Hey Jarvis 由 Python 启动。Realtime 模式还需要打开一个 Chrome 页面，让浏览器负责 WebRTC 的麦克风和语音播放。

这个结构适合开发，因为每一层都可以单独观察和调试。但如果把它直接包装成一个窗口，很多只存在于我电脑里的前提仍然没有消失：

系统里已经安装了正确版本的 Python 和依赖；
项目目录和 .env 文件位于预期位置；
Chrome 页面没有被重复打开；
API Key 可以由开发环境读取；
进程异常时，我知道应该去哪里看日志和怎样重新启动。

这些都不是产品应该交给使用者理解的事情。

在正式搭建 Mac App 之前，我先做了一个完全隔离的 Tauri 实验。它只回答一个问题：WKWebView 能不能在真实的 Apple Silicon Mac 上完成麦克风授权、Realtime 播放、自然打断、媒体释放，以及把麦克风还给 Python？

实验成功以后，我没有继续在这份实验代码上追加功能，而是重新建立产品自己的应用外壳。

这个选择看起来多走了一步，却帮我区分了两个很不一样的问题：

实验：这条技术路线可不可行？
产品：它能否保护秘密、正确失败、恢复运行，并在另一台电脑上重现？

三种运行环境，三种责任链接到标题

最终的 Hey Jarvis Mac App 分成三部分：

Hey Jarvis 的困难 I：让语音交互真正成立

Thu, 13 Aug 2026 13:59:31 +0800

在上一篇里，我写到，Hey Jarvis 的第一个 Pipeline（串行语音处理流程）其实很快就实现了最初的需求。

我说一句 “Hey Jarvis”，它录下问题，交给 AI 回答，再把答案读出来。

如果只看流程图，这个语音助手已经完成了。

但真正用起来以后，我发现语音交互里最困难的部分，往往不在“识别了什么”或者“回答了什么”，而在一些更基础的问题：它什么时候开始听？什么时候停止听？它能不能分清我的声音和自己的声音？一段对话结束以后，麦克风到底回到了谁手里？

这些问题没有解决时，模型再聪明，使用者也会很快失去耐心。

Pipeline 的第一个问题：它会听见自己链接到标题

为了让我知道唤醒成功，Hey Jarvis 会先播放一句简短的确认音。

最早是“在呢”，后来实时语音会话（Realtime）版本使用的是“嗯，我在，请说”。它听起来只是一个很小的体验细节，却引出了整个项目最早、也最反复的一类问题。

Mac 的扬声器播放确认音时，旁边的麦克风也会收到这段声音。如果程序在确认音结束后才开始读取麦克风，那么音频缓冲区里可能还留着刚才的回声。对程序来说，这些数据和用户刚刚说出的话并没有天然区别。

结果可能是这样的：

我说 “Hey Jarvis”
→ Jarvis 回答“在呢”
→ 麦克风重新收到“在呢”
→ Jarvis 以为用户已经开口
→ 录下一段错误的问题

最直接的办法，是播放确认音时完全忽略麦克风。

但这又制造了相反的问题。我听见“在呢”以后，可能会很自然地立刻开始说话，甚至在确认音的最后一个字还没有完全结束时就已经开口。如果这段时间的音频全部被丢掉，我的问题开头也会一起消失。

比如我说“明天新加坡会下雨吗”，系统收到的可能只剩“新加坡会下雨吗”。这次看起来还能理解；换一个问题，少掉前几个字就可能完全改变意思。

所以最终的处理不是简单地“听”或者“不听”，而是把确认音前后分成几个不同区域：

确认音播放期间持续读取麦克风，避免旧声音堆积在缓冲区；
明显属于扬声器回声、削波或溢出的片段不能成为“用户已经开口”的证据；
靠近播放结束的一小段安全音频暂时保留，作为问题开头的候选；
只有确认音结束后仍然观察到真实说话的迹象，候选音频才会进入正式录音；
如果后面没有人继续说话，就安静地回到唤醒状态，不请求 AI。

这套逻辑还需要估计环境底噪，并在最近的一组音频片段里确认持续的人声，而不是因为某一个突然变大的声音就开始录音。开始录音时，它还会把前面大约半秒的音频一起带上，尽量不丢掉第一个字。

一个原本只有两个状态的问题——“在听”或“没在听”——最后变成了对回声、底噪、连续语音和录音前缓冲的共同判断。

“我在”应该是一句承诺链接到标题

Pipeline 里的确认音主要表示唤醒词已经被识别。

到了实时语音模式，它的含义必须更加严格。

唤醒之后，Hey Jarvis 需要释放本地唤醒使用的麦克风，建立网络连接，完成实时对话配置，准备好播放远端声音，再开放麦克风输入。如果确认音放得太早，我听见“我在”就开始说话，但实时对话可能还没准备好，我说出的内容会直接消失。

所以我后来给这句确认音定义了一个产品层面的含义：

当“嗯，我在，请说”播放完，Hey Jarvis 才应该真正准备好听我说话。

实现这句话，需要等待两个条件：

实时对话已经配置完成
 ＋
确认音已经播放完成
 ↓
开放麦克风输入

这两个过程可以同时进行，但任何一个没有完成，用户输入都不能开放。

我做了一个 Hey Jarvis：从睡前的一个问题开始

Thu, 13 Aug 2026 13:55:06 +0800

我和老婆晚上睡觉前经常会聊天。

有时候聊的是一天里发生的事情，有时候会从一件小事跳到历史、科技、健康或者某个我们突然想到的知识点。聊着聊着，总会遇到一些我们都不知道、但又很想马上知道答案的问题。

这时候，最自然的动作本来应该是直接问一句。

但现实里的动作通常是：伸手去找手机，解锁，打开一个应用，点进输入框，再把刚才的问题重新组织一遍。等答案出现时，原来的聊天已经被打断了。

语音助手本来应该最适合这个场景。可我真正想问的问题，Siri 经常回答不了；而更聪明的 AI，又往往住在一个需要主动打开的窗口里。

我想要的其实很简单：

躺在床上说一句 “Hey Jarvis”，它就能加入我们的对话，回答刚才的问题。

于是我开始做 Hey Jarvis。

功能演示：中文版：让 Siri 级别的唤醒接上 ChatGPT

项目与下载：

第一个版本，其实很快就能工作链接到标题

Hey Jarvis 的第一版是一条很直接的 Pipeline，也就是一条串行语音处理流程：

本地等待 “Hey Jarvis”
→ 播放一句确认音
→ 录下问题
→ 把语音转成文字
→ 让模型生成答案
→ 把答案转成语音并播放
→ 回到唤醒状态

从功能定义上说，做到这里已经实现了最初的需求。

我不需要拿起手机。只要说出唤醒词，再问一个问题，它就会把答案讲出来。为了避免所有声音一直上传，唤醒词检测在本地完成；只有被唤醒之后录下的问题，才会进入后面的 AI 流程。

我还给它加了一些确定性的工具。时间和计算可以在本地完成；天气、汇率和股票价格由明确的数据提供方返回。对于这些会随时间变化的问题，我不希望模型凭记忆猜一个听起来很像真的答案。

如果目标只是做一段功能演示，项目大概已经可以停在这里。

但当我真的开始使用它，我发现：能够用语音问 AI，与拥有一个语音助手，并不是同一件事。

Pipeline 能回答问题，但它还不会对话链接到标题

第一版更像一个由语音启动的命令行程序。

我问完一个问题，它录音、思考、播放答案，然后整段交互结束。想继续追问，就要再说一次 “Hey Jarvis”。如果回答说得太长，我不能像人与人聊天一样插话；我只能等它讲完。

人与人对话时，我们很少意识到自己在做这些事情：

听到对方回应后，知道他已经准备好听了；
在对方说话时插入一句，对方会停下来；
用“那明天呢”继续追问，而不必重新交代上下文；
聊完说一句“再见”，双方都知道对话结束了。

这些在人类交流中近乎本能的行为，到了软件里都会变成明确的状态、事件和边界。

Hey-Jarvis on Armstrong Yan

Hey Jarvis 的未来：当 AI 需要自己的入口

Siri 既是助手，也是系统入口 链接到标题

Hey Jarvis 的困难 II：从 Demo 到 Mac 产品

产品化不是给 Python 加一个窗口 链接到标题

三种运行环境，三种责任 链接到标题

Hey Jarvis 的困难 I：让语音交互真正成立

Pipeline 的第一个问题：它会听见自己 链接到标题

“我在”应该是一句承诺 链接到标题