企业官网建设流程全解析

拿着一个带麦克风的遥控器，按住说出需求，松开转成文字，再按确认键交给 Codex 写代码——这就是我这次想实现的操作方式。

设备选的是小米蓝牙遥控器 2 Pro，电脑运行 Windows 11。原本以为只要完成蓝牙配对，再映射几个快捷键就能使用，实际却遇到了几个问题：

• Windows 蓝牙设置搜不到遥控器；
• 配对后，系统没有把遥控器识别成普通麦克风；
• 方向键能用，返回键却没有反应；
• Codex 听写正常，微信输入法听写时好时坏；
• 切换听写方式会反复弹出管理员确认窗口。

经过排查，最终实现了遥控器语音输入、确认发送、返回删除，以及 Codex 和微信输入法两种听写方式的切换。这篇文章重点介绍几个值得展开的技术问题，安装和操作过程则尽量简化。

一、最终实现了什么

目前这套方案的主要操作如下：

另外，屏幕右下角增加了常驻提示，显示当前使用的听写方式，以及“录音中”“识别中”“可以按住说话”等状态。

这里显示的是遥控器当前调用哪个语音识别工具，不是 Windows 当前选中的文字输入法。两者需要区分。

二、Windows 搜不到设备，不一定是蓝牙驱动坏了

最开始，Windows 的添加设备界面始终找不到遥控器。

检查本机后发现：

• MediaTek 蓝牙适配器状态正常；
• 蓝牙服务正在运行；
• Microsoft 蓝牙 LE 枚举器正常；
• 系统中已有其他低功耗蓝牙设备记录。

这些结果不能证明所有蓝牙功能都正常，但足以说明：暂时没有必要直接重装驱动或重置整个蓝牙环境。

让遥控器靠近电脑，长按 TV 键进入指示灯闪烁的配对状态后，通过主动 BLE 扫描，成功发现了名为“小米蓝牙语音遥控器”的设备，信号强度约为 −50 dBm。

它还广播了 HID 服务：

00001812-0000-1000-8000-00805f9b34fb

这说明电脑能够接收到遥控器，问题需要继续从设备发现和配对流程排查。

普通配对失败，确认式配对成功

直接调用 Windows 的普通配对接口时，返回了失败状态。随后改用自定义配对流程，处理CONFIRM_ONLY配对请求，再接受该设备的确认事件，配对成功。

关键逻辑可以概括为：

custom=device_information.pairing.customdefconfirm(sender,args):args.accept()token=custom.add_pairing_requested(confirm)try:result=awaitcustom.pair_async(DevicePairingKinds.CONFIRM_ONLY)finally:custom.remove_pairing_requested(token)

实际脚本在接受请求前，已经根据扫描结果限定了唯一的小米遥控器，避免对附近其他设备进行不明确的配对。

配对后，Windows 中出现了正常状态的“小米蓝牙语音遥控器”，硬件标识为：

VID：2717 PID：32B8 REV：00A4

需要强调的是：这次成功使用了确认式配对接口，并不意味着所有“Windows 搜不到遥控器”的情况都由同一个原因造成。

如果只是设置界面不显示设备，还可以尝试把 Windows 的“蓝牙设备发现”改成“高级”。这是微软排障文档提供的处理方向。

三、带麦克风的遥控器，为什么没有出现在录音设备里

配对成功后，方向键可以像键盘一样工作，但遥控器麦克风并没有直接出现在 Windows 的声音输入列表中。

原因在于，这款遥控器的按键和语音走的是不同链路：

按键 遥控器 → 蓝牙 HID → Windows 键盘输入 语音 遥控器麦克风 → 私有 ATVV 服务 → 软件解码 → 虚拟麦克风

它的语音数据通过 ATVV 私有 GATT 服务传输，不是 Windows 可以直接使用的普通蓝牙录音设备。

本次确认到的 ATVV 服务 UUID 为：

AB5E0001-5A21-4F05-BC7D-AF01F617B664

因此，除了蓝牙配对，还需要软件完成语音服务连接、协议握手、ADPCM 解码，以及向虚拟音频设备输出声音。

选择 MiVibe Remote 做基础桥接

我最后采用了开源项目 MiVibe Remote，它提供 Windows 版本、遥控器按键映射，以及面向 Codex 的语音预设。

本次使用的 Windows 软件版本为0.1.20，来自仓库的v0.1.22 Release。下载安装包后，核对了 GitHub 发布信息中的 SHA-256。

虚拟音频使用 VB-CABLE。驱动安装包从 VB-Audio 官方来源下载，并检查了安装器签名。

完整语音链路变成了：

遥控器麦克风 ↓ BLE ATVV 语音数据 ↓ MiVibe 解码、重采样 ↓ CABLE Input（播放端） ↓ CABLE Output（录音端） ↓ Codex 或微信输入法

日志最终确认了 ATVV 服务发现、音频路由就绪，以及16 kHz语音格式协商成功。

这些日志证明桥接链路已经建立，但“用户说话后能否真正出字”，仍然要在目标软件中实测。

四、虚拟麦克风与电脑扬声器，要分开配置

安装虚拟音频设备后，我遇到了另一个很容易让人困惑的问题：电脑播放视频没有声音了，因为 Windows 声音输出指向了虚拟音频设备。

实际上，遥控器语音输入和电脑正常播放声音可以同时工作：

关键是：Windows 的默认声音输出不用切到 VB-CABLE。

YouTube、音乐和系统声音继续从真实扬声器播放，MiVibe 则单独把遥控器音频送进虚拟麦克风。

日常需要切换扬声器或耳机时，可以通过 Windows 的声音输出选择界面操作，不必连带修改 Codex 和微信输入法的麦克风设置。

五、Codex 听写：最后用了 Ctrl + Shift + D

基础桥接配置推荐使用右 Alt 触发 Codex 的按住听写。但在我的电脑上，尝试设置右 Alt 时没有得到预期效果，还触发了系统界面。

因此，我把两端统一改为：

Codex 听写快捷键：Ctrl + Shift + D 遥控器语音触发：Ctrl + Shift + D 触发方式：按住型

这只是本次选用的自定义组合键，不是所有电脑必须使用的默认快捷键。

这里还有一个界面上的易混淆点：

• “语音聊天热键”用于启动语音聊天；
• “听写快捷键”用于把说话内容转成文字。

遥控器这次接入的是后者。

完成设置后，实际操作就是：

光标放进 Codex 输入框 ↓ 按住遥控器麦克风键说出需求 ↓ 松开，等待文字出现 ↓ 检查文字 ↓ 按中央确认键发送

中央确认键对应 Enter。它的行为取决于当前焦点：在输入框里可以发送，在其他界面里则可能是确认选项。

六、返回键没有反应，是 HID 信号被丢弃了

另一个典型问题是：方向键和确认键正常，返回键却无法删除文字。

检查对应模块后发现，RC003 返回键使用的 HID usage 为：

0x00F1

Windows 蓝牙 HID 驱动收到这类报告后，没有把它转换成普通的退格键事件，因此只配置“返回键 → Backspace”还不够。

基础软件提供了增强按键模块，通过设备对应的 HidOverGatt 驱动宿主读取报告，再将返回键转换成退格操作。

启用后，日志出现了完整的事件链：

返回键按下 ↓ 读取 HID usage 0x00F1 ↓ 匹配 back 映射 ↓ 发送 Backspace ↓ 返回键松开

随后在输入框中实测，返回键可以正常删除文字。

这个模块需要管理员权限。因此，启动或蓝牙重连时，可能需要一次管理员确认。

七、TV 切换为什么反复弹出管理员提示

最初，为了切换 Codex 和微信输入法，我采用了一个直接的办法：

修改语音快捷键配置 → 重启桥接进程

它确实可以切换模式，但也产生了副作用：增强按键模块随着桥接重启，需要重新连接驱动宿主，于是 TV 键每切换一次，都可能弹出管理员确认。

这个方案在日常使用中明显不方便。

后来改成了：

蓝牙桥接持续运行 ↓ 基础软件只负责音频和按键 ↓ 独立控制器负责听写快捷键 ↓ TV 键只更新当前听写模式

这样，切换模式不再重启蓝牙桥接，也不需要重复初始化增强按键模块。

需要说明的是：独立控制器、模式提示和后续微信兼容处理，是本次在本机增加的辅助功能，不是直接安装上游软件后就自带的完整效果。

八、微信输入法：能弹浮窗，不等于整条链路正常

本机微信输入法的设置是：

启动语音输入：左 Ctrl + F12 按住说话：左 Alt + S 麦克风：CABLE Output

但直接把遥控器麦克风键映射为左 Alt + S 后，微信输入法并不稳定。

排查时，我把问题拆成了三步：

1. 用电脑键盘按住左 Alt + S，检查微信语音浮窗能否启动；
2. 用遥控器录音，检查桥接日志是否收到音频；
3. 观察微信浮窗的波形是否跳动，以及最终是否提交文字。

结果是：键盘可以启动浮窗，遥控器也有音频，后续测试中微信波形能够跳动，但仍出现过不出字的情况。

所以，“出现浮窗”“收到音频”“成功上屏”必须分别验证，不能把前两项当成最终成功。

最后采用：松开后回放识别

稳定一些的处理方式，是将录音和微信快捷键触发分开：

按住遥控器麦克风 ↓ 在内存中缓冲录音 ↓ 松开遥控器 ↓ 分步模拟按住左 Alt + S ↓ 将录音回放到 CABLE Input ↓ 微信从 CABLE Output 接收音频 ↓ 松开快捷键，提交识别

这个方式避开了遥控器按住期间对模拟快捷键的干扰，但有一个明确的取舍：

微信模式不是边说边出字，而是松开遥控器后再进行回放识别。

例如说了 5 秒，松开后还需要等待这段录音回放，以及微信完成识别。音频只在内存中处理，没有为这套流程额外保存录音文件。

Codex 模式则继续保持原来的按住听写方式。

九、最后一个隐蔽问题：F5 状态滞留导致识别被误取消

微信模式最难定位的一次故障，是状态提示会变化、录音有声音，但始终不出字。

日志给出了关键原因：

WETYPE buffered samples=... WETYPE aborted: F5 still held

遥控器麦克风键会产生 F5 信号。为了避免在浏览器或其他程序中误触发刷新，桥接软件会拦截这类事件。

但辅助控制器当时又使用了：

GetAsyncKeyState(VK_F5)

来判断麦克风键是否已经松开。

问题是，这个 Windows 按键状态可能与遥控器实际状态不一致。日志已经收到 ATVV 录音结束事件，检测却仍然认为 F5 按着，于是取消了微信识别。

最终修复是：

• 使用 ATVV 的录音结束事件作为依据；
• 去掉对 F5 全局状态的不可靠判断；
• 保留重复开始和回放重叠保护。

修改后，再次实测确认微信输入法能够正常出字。

这次排查也说明：私有设备协议已经提供了明确事件时，不宜再用被拦截过的系统按键状态作为唯一判断依据。

十、实际使用时，注意微信模式的操作节奏

我曾经这样操作：

先点一下麦克风 → 等微信浮窗 → 再按住说话

在缓冲回放方案中，这会产生两次录音。前一段还在识别，后一段已经开始，容易造成重叠或中断。

现在正确的操作是：

直接按住说话 → 松开 → 等识别结束 → 再开始下一句

为减少误操作，我增加了右下角状态提示，并加入了以下保护：

• 重复的录音开始事件不重复开启采集；
• 识别回放期间不接受新的录音开始；
• 忽略短于 0.65 秒的点按；
• 按键注入失败时释放已经按下的修饰键。

相关自动检查覆盖了按键释放、模式切换、重复录音和 F5 状态误判等情况。微信识别和文字上屏仍然需要真实设备验证。

十一、这套方案适合怎样的使用场景

对于 Codex，遥控器已经可以完成一个比较自然的语音编程循环：

说出需求 → 检查转写 → 确认发送 → 查看结果 → 继续补充。

微信输入法则提供了另一种文字输入方式，可以在普通文本框中使用。不过，本次采用的微信兼容方案仍有回放等待时间，不能把它当作实时听写方案。

目前用户实测确认的功能包括：

• Windows 成功添加遥控器；
• Codex 听写可用；
• 返回键退格可用；
• TV 切换不再反复弹管理员提示；
• 当前模式和录音状态显示正常；
• 修正 F5 误判后，微信输入法能够出字。

这次验证是在一台 Windows 11 电脑和一只小米遥控器 2 Pro 上完成的，还不能代表所有蓝牙适配器、遥控器固件和输入法版本，也没有完成长时间稳定性测试。

如果准备自己尝试，建议先打通 Codex 听写，再逐步加入返回键兼容、输入法切换和状态提示。这样每增加一层功能，都能明确判断故障来自哪里。

参考项目与资料

• MiVibe Remote 开源项目
• 本次使用的 v0.1.22 Release
• MiVibe Remote 的 Codex 配置说明
• Microsoft：Windows 蓝牙问题排查

本文记录一次本机实践。上游项目会继续更新，安装前请检查当前版本说明；本文新增的辅助控制器功能，应与上游原生功能区分。