摘要：因为 Mac mini 缺少一个顺手的语音入口，我把 Apple Watch 装进 iPod 外壳，想把它做成手持语音控制器：按一下，说一句，文字就进入当前输入框。我们先后走了两条完全不同的路线：自己搭建“手表录音—本地转写—自动输入”全链路，以及借微信输入法完成识别的“虚拟麦克风”路线。两条都停下了。本文把用过的工具、真正的断点和不建议再踩的坑都写清楚。
起点：我不是想录音，我是想“把话打进去”
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、微信聊天还是任何输入框”的完整目标。
排除它们不是偶然：不同应用对输入法、焦点、粘贴和系统权限的处理不一致；而且这类自动输入最危险的地方，就是文字可能进入错误窗口。要让它成为一个可以每天依赖的工具，至少要解决三件事：
明确识别当前到底是谁的输入框； 在写入前给用户足够清楚的确认； 写入失败时不丢内容，也不误输到别处。
我们没有把这三件事做成稳定的体验。因此路线 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 接收服务、本地模型、虚拟音频、系统权限、当前焦点和输入法行为。
任何一环出问题，用户看到的都是同一件事：我说了话，但文字没有出现。
这不是一个值得每天依赖的输入工具该有的状态。
更关键的是，原始目标其实有两个：
手表做一个手持式 AI 控制器； 手表做 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 通用语音输入”的这次实践，不等于对任何产品能力的普遍判断。
