把 Apple Watch 做成 Mac mini 的随手语音输入：两条失败路线的完整复盘

起点：我不是想录音，我是想“把话打进去”

Mac mini 到手后，一个很小的问题变得很频繁：我想对 AI 说一句话，却不想一直戴着 AirPods，也不想每次都摸手机。

我想要的体验很具体：拿起这块手表，按一下，说完以后，文字出现在当前光标所在的输入框。它可以是 Codex、笔记软件，甚至聊天窗口；文字先放进去，等我自己确认后再发送。

因为这块 Apple Watch 套进了一个带圆形按键的外壳，表冠、屏幕、震动和麦克风都在手边。它看起来几乎就是一个现成的 AI 对讲机。

于是我们决定试一试。

但先把一个关键概念讲清楚：这次不是“四个步骤的同一路线”，而是两条不同的技术路线。

路线 A：自己搭完整链路
Apple Watch 录音 → Mac 接收 → 千问转文字 → 自制输入组件 → 当前输入框

路线 B：借现成输入法的识别能力
Apple Watch 实时音频 → 虚拟麦克风 → 微信输入法 → 当前输入框

路线 A 是“我们自己做识别和输入”；路线 B 是“我们只负责把声音塞进系统，识别交给微信输入法”。它们的难点不同，失败的原因也不同。

路线 A：自己搭“录音—千问转写—自动输入”全链路

这条路线的目标是最彻底的：不依赖某个输入法，自己把 Apple Watch 的声音变成文字，再把文字送进当前应用。

我们实际用到的工具是：

• Xcode
  ：用来做并安装 Apple Watch 小应用；
• watchOS / SwiftUI / AVAudioRecorder
  ：手表端录音；
• 局域网 HTTP 接收服务
  ：Mac mini 接收手表送来的音频；
• 千问 Qwen3-ASR-0.6B
  ：本地中文语音转文字；
• Python
  ：把接收、转写、后续处理串起来；
• macOS InputMethodKit
  ：我们自己做的输入组件，尝试把识别结果写入当前输入框。

技术流程图：路线 A 的实际工具链与断点。图中的工具标识只用于识别；内容基于本次代码和实测复盘绘制，不代表 Apple 官方方案或实时界面。

这不是纸面设想，链路的每个部分都真的做过。也正因为如此，里面有几个非常具体、很值得公开的坑。

第一步：手表录音，不等于手表把录音送到了 Mac

手表应用可以录一段 16kHz、单声道的 m4a 音频；我们也给它做了“准备好了”“正在听”“已发送到 Mac”等状态。

最开始，我们采用的是“说完一整段，再上传音频文件”的方式。后面又加了“边说边把小段声音发出去”的尝试，希望更接近实时麦克风。

这里踩到了这次最典型的坑：界面状态不能代替真实传输结果。

复盘保留下来的代码时，我们发现手表端在停止录音时，会把界面文字改成“已发送到 Mac”，但停止函数并没有真正调用上传音频文件的那段代码。也就是说，手表告诉我们“发了”，并不等于 Mac 收到了。

这也解释了当时反复出现的现象：手表上已经显示“发送到 Mac”，Mac 端却没有任何转写、没有任何输入。

这是一个代码层面的错误，不是设备权限或网络玄学。它提醒我：做这种多设备链路时，不能只看最后一个 UI 提示，必须在每一段留下可核对的收据：手表是否发出、Mac 是否收到、音频是否有效、转写是否返回、文字是否插入。

第二步：文件传输和实时传输，是两件不同的事

即使修正上传调用，文件式传输也不适合“像麦克风一样”使用。

Apple Watch 与 iPhone 的通信可以传递消息和文件，但后台文件传输会由系统调度，不保证立即送达。Apple 的说明也明确提到：文件传输是异步的，系统会为了性能和电量调整速度。Apple 的 Watch Connectivity 文档和 transferFile 说明都写明了这一点。

所以“按住说一段，松开后过几秒传过去”可以做语音便签；但它天然不是实时麦克风。

后来我们改成实时方案：手表每采到一小段声音，就通过局域网发给 Mac。听起来更接近目标，但实际接收端仍是一个临时脚本：它把每小段声音分别处理，而不是一条经过缓冲、同步、丢包处理的连续音频管线。

这意味着它可能有延迟、断续、顺序问题，或在网络稍有波动时直接失去可用性。做演示可以，做日常输入设备不够。

第三步：千问负责“听懂”，但它解决不了前后两端

为了不依赖云端，我们安装了 千问 Qwen3-ASR-0.6B，让 Mac mini 在本地完成中文语音转文字。Mac 接收服务的设计是：收到完整音频后，调用千问转写脚本，把结果保存成文字。

这一步的价值很明确：隐私更可控，也能在本机继续做标点、整理和分类。

但它解决的是其中一段——“拿到可靠音频以后，怎么变成文字”。它解决不了：

• 手表有没有真的把音频送到 Mac；
• 音频是不是连续、完整、可识别；
• 识别结束后，文字应该进哪个应用；
• 文字进去了没有，用户如何确认。

所以这条路线真正的教训不是“千问不行”。恰恰相反，本地转写是整条路线里最正常的一段。问题是我们把一个语音识别模型，误当成了整套语音输入体验。

第四步：自制“通用输入”，没有真的通用

转写完成后，我们没有简单用剪贴板，而是尝试做一个 macOS 输入组件。它的目标是把识别后的文字写进当前应用的输入位置，像换了一种输入法一样。

这部分用的是 macOS 的 InputMethodKit。理论上，这比模拟按键更接近“系统输入”。

但复盘代码后又发现一个很重要的边界：这个组件里明确排除了微信和企业微信。也就是说，它从一开始就不能满足“无论是 Codex、微信聊天还是任何输入框”的完整目标。

排除它们不是偶然：不同应用对输入法、焦点、粘贴和系统权限的处理不一致；而且这类自动输入最危险的地方，就是文字可能进入错误窗口。要让它成为一个可以每天依赖的工具，至少要解决三件事：

1. 明确识别当前到底是谁的输入框；
2. 在写入前给用户足够清楚的确认；
3. 写入失败时不丢内容，也不误输到别处。

我们没有把这三件事做成稳定的体验。因此路线 A 停在了“各段都有原型”，没有成为一个可用产品。

路线 B：把声音送进虚拟麦克风，想借微信输入法完成识别

路线 A 太长，所以我们想到一条看起来更聪明的路：既然微信输入法的中文语音输入本身已经很成熟，为什么不直接借用它？

这条路线的设想是：

Apple Watch 实时声音
        ↓
Mac mini 上的接收脚本
        ↓
BlackHole 虚拟音频设备
        ↓
微信输入法的语音输入
        ↓
当前输入框

这条路线使用的工具是：

• BlackHole 2ch
  ：让声音在 Mac 内部走一条“虚拟麦克风”通道；
• PortAudio / sounddevice
  ：让 Python 脚本把收到的声音播放进这条通道；
• Python 接收服务
  ：接收 Apple Watch 实时发来的音频；
• 微信输入法
  ：我们原本希望借它完成语音识别和文字整理。

技术流程图：路线 B 的实际工具链与断点。图中的工具标识仅用于识别，不代表合作、授权或接口支持；内容基于本次实测复盘绘制。

这条路真正验证了什么？

我们验证到的是：声音可以被接收脚本送进 BlackHole 这个虚拟音频设备。

这很容易让人以为“成功了一大半”。实际上，它只验证了声音在 Mac 内部可以绕一圈，并没有验证“微信输入法会把这条声音当成它能听到的语音输入”。

BlackHole 是音频中转工具，不是一个自动把网络音频变成所有软件都能可靠使用的麦克风。Apple 自己把创建虚拟音频设备放在专门的音频设备开发领域，而不是普通应用的一行配置。Apple 的开发说明在这里。

最大的误判：把输入法当成可调用的语音服务

我们原本以为，只要把声音放进系统输入设备，再触发微信输入法的语音按钮，它就会开始转写。

但这条路缺少一个关键前提：我们没有拿到一个公开、可验证的接口，能把第三方实时音频直接交给微信输入法识别，也没有一个可依赖的方式去控制它开始、停止和返回结果。

“输入法能听麦克风”与“输入法能接受我的网络音频流”是两件事。

实际测试中，虚拟音频通道虽已建立，文字却没有稳定出现在输入框。我们反复尝试触发，也没有获得可复现的结果。到这里就该停止，而不是继续堆更多中转层。

此外，即使这一步能侥幸跑通，它仍会有两个长期问题：

• 输入法不是为第三方应用提供语音识别服务的开发接口，更新后行为不可控；
• 它会把整条系统链路绑在某个具体软件上，无法成为可靠的“通用输入方案”。

所以路线 B 的失败，不是 BlackHole 没安装好，也不是 PortAudio 没装好，而是我们试图把一个面向人使用的输入法，当成一个能被程序稳定调用的语音服务。

两条路线分别踩了什么坑

技术对照图：哪些环节真的完成验证，哪些环节没有走通。它不是产品功能承诺，而是这次实验的失败定位图。

为什么最后决定放弃

真正让我们停下来的，不是某一个报错，而是投入产出已经倒过来了。

为了省下一支简单的语音设备，我们已经维护了：手表 App、手机与手表的连通、局域网、Mac 接收服务、本地模型、虚拟音频、系统权限、当前焦点和输入法行为。

任何一环出问题，用户看到的都是同一件事：我说了话，但文字没有出现。

这不是一个值得每天依赖的输入工具该有的状态。

更关键的是，原始目标其实有两个：

1. 手表做一个手持式 AI 控制器；
2. 手表做 Mac 的通用语音麦克风。

第一个目标很合理。表冠、按键、震动、状态屏都适合开始、停止、确认、取消、切换任务和接收提醒。

第二个目标，在目前这套系统边界下不合算。它要求 Apple Watch、iPhone、Mac、语音识别和任意应用的输入框同时表现得像一个整体。它们并不是为这件事设计的。

这次失败真正留下的经验

1. 先区分“路线”和“步骤”

手表录音、音频传输、语音转文字、文字写入，这些是路线 A 的步骤，不是四条不同方案。真正做决策时，应该问：识别是自己做，还是借第三方做？声音是以文件传，还是模拟成系统麦克风？这才是路线层面的选择。

2. 每一跳都要有可验证的回执

这次“手表显示已发送，但 Mac 什么都没有”的问题，说明一个 UI 提示远远不够。每段都要能独立证明：已发送、已收到、已转写、已写入。没有这些回执，就不要往下叠更多功能。

3. 不能把面向人的软件，当成面向程序的接口

输入法好用，不等于它提供了可被外部程序调用的语音能力。任何依赖“模拟点击”“触发快捷键”“希望它刚好听见”的方案，都应该先用最小实验验证，再决定是否投入。

4. Apple Watch 更适合做控制器，而不是硬拗成通用麦克风

这块外壳没有白买。它仍然是很好的交互形态：按键开始、震动确认、表冠选模式、屏幕显示状态。

如果以后继续，我会把目标收窄成明确的专用动作：记录一条灵感、启动一个任务、确认或取消一个请求。语音可以是其中一个入口，但不会再试图让它接管 Mac 上所有应用的麦克风和输入框。

结尾

这不是一个“Apple Watch 不行”的结论，也不是“千问、BlackHole 或微信输入法不行”的结论。

真正失败的是我们一开始的组合方式：想用一套由多个临时环节拼出来的方案，去替代一件必须稳定、即时、无需解释的输入设备。

这次停下是对的。把失败路线、工具和断点公开写出来，也是为了让下一个想做同样事情的人，能少绕一点路。

公开资料

• Apple Watch 与 iPhone 的通信机制： Apple Developer: Watch Connectivity
• Apple 对后台文件传输的说明： transferFile(_:metadata:)
• Apple 关于 macOS 虚拟音频设备的开发说明： Creating an Audio Server Driver Plug-in

本文基于一次个人设备实测和项目文件复盘。设备、系统与软件版本都会变化；文中结论只针对“Apple Watch 成为 Mac 通用语音输入”的这次实践，不等于对任何产品能力的普遍判断。