1. 项目概述与核心需求解析先说结论我做的是一款叫 seeMote Cap 的输入桥接配件它要做的事情只有一个——把你在桌面上已经用得顺手的键鼠原封不动带进 visionOS。为什么这件事值得专门做只要你在 Vision Pro 上认真打过超过两百字的文字就会明白。虚拟键盘在空间里悬浮的样子确实很赛博朋克但手指在空气里敲击的体验本质上跟对着空气弹钢琴差不多。我见过不少朋友把 Vision Pro 买回家用了两周最终固定在桌面上的使用场景就剩下两个看片、看片。不是他们不想用它办公是在那个输入效率面前任何创作类的需求都会被劝退。seeMote Cap 的思路很简单做一个硬件适配器插在电脑上接管键鼠信号再通过局域网把键鼠数据投到 Vision Pro 里。你没看错不是蓝牙直连不是把键鼠直接配对给 Vision Pro而是走一条中继路径。这个设计乍一听好像绕了远路但在我实际做完整个项目之后可以负责任地说这条弯路是必要的。先把这个产品的适用人群说清楚。如果你是一个每天要在文档编辑、代码开发、会议记录之间来回切换的重度输入用户seeMote Cap 就是为你做的。如果你只是偶尔想在虚拟屏幕上看个网页、点两下按钮那原生手势足够用没必要再加一个硬件。定位准确比功能堆叠重要得多。项目从原型到可预购版本前后大概迭代了四个月。第一版用的是蓝牙协议直接模拟 HID 设备结果在 visionOS 的输入响应上出现了不可控的丢帧就是因为 visionOS 对蓝牙键鼠原生事件的优先级处理和我们预期的不一致。后来干脆推翻重来改成现在的双通道方案——键鼠信号先到电脑再由电脑通过自定义协议转发到 Vision Pro。这也是项目名里 “Cap” 的来历Capture把桌面输入捕获下来映射进空间。接下来我会把这套方案从设计到落地的整个过程拆开讲。里面包含了键盘鼠标在空间计算环境里的坐标映射逻辑、关键参数的调校过程、我在开发中踩过的坑以及一些我认为值得分享的优化思路。如果你是做空间计算应用的开发者或者对这类输入桥接方案感兴趣这篇文章应该能帮你省掉不少摸底的时间。2. 整体设计思路与方案选型2.1 为什么不能直接用蓝牙配对键鼠先回应一个问题很多人在看到 seeMote Cap 的第一反应是Vision Pro 不是支持蓝牙键鼠吗为什么还要多此一举确实visionOS 2.x 的系统层面已经支持连接蓝牙键盘和触控板但这里面有几个在实际使用中非常明显的问题。第一是设备切换成本。你手头大概率不止一台设备键鼠需要在 Mac、iPad、PC 和 Vision Pro 之间来回切换时每次都要重新配对或者手动切换通道。这种高频摩擦在真实工作流里是非常消耗耐心的一天切十次基本就处于崩溃边缘。第二是输入事件的语义不匹配。visionOS 的 UI 体系不是基于传统的指针事件构建的。它默认的交互模型是眼动定位加捏合确认手势是它的第一交互语言。当你把传统键鼠的输入直接送进系统时系统需要把这些输入强行翻译成可点击可拖拽的事件这个翻译过程在原生通道里做得很有限。结果就是鼠标移动很飘、键盘输入有延迟感甚至有些视图层组件对鼠标事件根本不响应。第三是距离限制。蓝牙在正常办公场景下确实够用但空间计算的魅力之一是你可能把虚拟屏幕摆得离自己很远比如放在三米外看一个巨幕式的代码编辑器。这时候蓝牙信号没问题问题在于光标坐标的增量映射——你手腕移动的量转换成远端虚拟光标移动的量这个比例如果不做精细调校光标要么飘得找不到要么慢得想砸设备。所以 seeMote Cap 的结论是与其去跟系统级的输入管道掰扯不如在更高层级自己架一条输入通路。电脑端把键鼠事件捕获之后先做一层语义化处理再通过局域网协议发送给 Vision Pro 端。2.2 双端架构为什么需要一台“中继电脑”整个系统分为三部分。第一是捕获端也就是 seeMote Cap 的硬件主体。它通过 USB 接入你的电脑内部有一个轻量的信号捕获模块在系统层面挂载一个虚拟 HID 设备接管键鼠的原始输入事件。之所以要用独立硬件而不是纯软件方案是为了绕过 macOS 和 Windows 对后台进程获取输入事件的各种权限限制。你写一个后台程序去全局监听键鼠系统会弹权限、会限制辅助功能接口、会在窗口切换时断掉事件流。但硬件层级的接管走得是系统输入管道的正规通道权限问题少很多。第二是转发端也就是电脑上运行的 seeMote 服务。它负责把捕获到的键鼠事件封装成自定义的数据帧通过局域网发送到 Vision Pro。数据帧的格式是自定义的二进制协议不是 JSON。原因很简单JSON 在编解码上的开销对普通应用无所谓但对键鼠这类高频低延迟事件来说任何多余的开销都会直接体现在体感上可能只有三五毫秒但连续工作一个小时手部的疲劳感会明显不同。第三是接收端也就是运行在 Vision Pro 上的 seeMote 应用。它接收数据帧后把键鼠事件注入到 visionOS 的可访问性指针系统里通过辅助功能指针通道来控制虚拟空间中的焦点移动和确认操作。这个通道是苹果给辅助功能设备预留的系统级接口权限比普通应用的事件注入高得多授权之后可以跨应用生效。也就是说你不光能在 seeMote 自己的窗口里用键鼠在任何一个 visionOS 应用里都能用。选这条中继路径的代价是需要一台常开的电脑。但换来的优势是极大的灵活性。因为所有数据都要经过电脑转发就意味着在电脑这一端可以完成很多系统层面干不了的事情比如自定义按键映射、多设备切换、灵敏度曲线调整、甚至针对不同应用自动切换不同的键位布局。这些能力在纯蓝牙直连方案里是完全不可能实现的。2.3 坐标系映射从二维平面到三维空间这是整个项目里技术难度最高的部分值得单独拿出来详细讲。传统桌面系统的光标是二维坐标屏幕是一个平面鼠标的位移量通过增量累加映射到屏幕坐标上。但在 visionOS 里光标这个概念是微妙且要谨慎处理的。系统没有一个全局可见的系统光标取而代之的是聚焦选中状态——某个视图被聚焦就表示当前选中的是这个视图。初期尝试过直接模拟二维指针坐标但在三维空间里二维坐标如果没有深度信息会遇到一个非常尴尬的问题用户转头看向另一边时原来的二维坐标点在空间中的相对位置已经完全变了但从数据层面它还是一个静态坐标值。后来我换成了基于射线投射的方案。在 Vision Pro 端以一个虚拟的原点出发射出一条射线用鼠标的水平位移控制射线的水平偏转角垂直位移控制垂直偏转角。当用户移动鼠标时实际改变的是这条射线在空间中的朝向。射线与虚拟屏幕平面的交点就是当前指针的位置。这个方案的优势在于它和用户转头、移动视线完全解耦。你头转去哪射线还在它自己的朝向回来之后光标还在原处等你。这个设计背后借鉴的是电视遥控器的空中鼠标原理但区别在于 seeMote Cap 不需要你在空中挥动设备而是用桌面鼠标的位移来驱动射线的旋转。这样既保留了桌面输入的高精度又适配了空间交互的语义模型。在初始版本的实现里灵敏度是固定值结果就是不同用户体感差异很大。后来加了三档预设加一个自定义曲线编辑功能才基本覆盖了主流偏好。这部分在下一节的参数调校里会展开说。2.4 协议设计延迟与可靠性的权衡键鼠数据的网络传输有一个显著特点数据量小、频率高、对延迟敏感、对可靠性要求相对较低。一个键鼠事件的数据撑死几十个字节但它每秒会产生几百次。这决定了传输协议的设计思路不能照搬通用的流式传输。seeMote Cap 采用 UDP 作为底层传输协议没有选择 TCP。原因很简单TCP 的重传机制在丢包时会等待重传这个等待在高速输入场景里会造成事件堆积。你连续移动鼠标中间丢了一个包TCP 会把后续的包堵住直到重传完成体现在用户端就是光标突然顿了一下。而 UDP 丢一个包就丢了下一个包接着到光标会有一帧的跳跃但整体运动是平滑的。在实际体感上一帧的跳跃远好过一次明显的停顿。不过完全裸用 UDP 也有问题。键盘事件不能丢你按了一下 CtrlC这个包在网络上丢了后果是整个快捷操作没有生效。所以我在协议层做了一个简单的分级处理鼠标位移事件走轻量 UDP键盘按下和抬起事件走增强可靠性通道对每个按键事件做确认重发机制如果 10 毫秒内没有收到确认就重发一次。这个分级模型在实测中表现稳定。局域网环境下鼠标事件平均延迟在 5 到 8 毫秒键盘事件平均延迟在 8 到 12 毫秒。人眼能感知到的延迟阈值大概在 15 到 20 毫秒所以这个数据基本是安全的。3. 实操过程与关键环节实现3.1 硬件端从树莓派 Pico 到量产板很多人以为 seeMote Cap 的量产硬件是很复杂的嵌入式设备其实核心就是一个微控制器加一个 USB 芯片。原型阶段用的是树莓派 Pico 加一个 USB Host 扩展板成本不到一百块。当你只需要捕获键鼠信号时树莓派 Pico 的性能完全够用。硬件端要做的事情本质上就是挂载一个 USB Host 控制器把键鼠的 HID 报告捕获下来然后通过串口或者无线模块送给电脑端。但这里有一个细节很多人会踩坑USB 键盘的 HID 报告并不是只有一种格式。普通键盘是 8 字节的标准 HID 报告但带多媒体键的键盘、带宏定义的竞技键盘它们的报告描述符可能完全不同。如果只在软件里硬编码解析标准报告换一个键盘就废了。我的解决方案是做一个报告描述符状态机。枚举设备时先读取设备的 HID 报告描述符解析出每个字段的含义再建立对应的解析规则。这个逻辑大概只占几百行代码但它把设备兼容性的问题解决了大半。目前测试过的键盘里包括各种带旋钮的、带一排宏按键的基本都能正确捕获。硬件端的另一个重要决策是供电与数据合一的 USB 方案。键盘和鼠标分别接入 seeMote Cap 的两个 USB 口Cap 再通过一根数据线接到电脑。电脑端识别到的是一把虚拟键盘和一只虚拟鼠标所有经过 Cap 的键鼠输入都会以标准 HID 报告的形式出现在电脑上。这意味着你完全不需要在电脑上安装任何驱动即插即用。3.2 电脑端虚拟 HID 接管的权限策略电脑端最麻烦的事情在于权限。在 macOS 上如果只是做全局事件监听需要在系统设置里打开辅助功能权限。但通过虚拟 HID 设备接管键鼠输入走的是驱动层的正规通道系统直接认这是一把物理键盘权限门槛低很多。这里有一个取舍如果你在电脑端还要继续正常使用键盘鼠标操作电脑就需要把 HID 报告同时分发给系统如果你只是把电脑当成一个纯转发盒子可以只在后台运行 seeMote 服务不需要界面也不需要用户在前台做任何操作。Windows 端的实现略有不同。Windows 对 HID 驱动的签名要求比较严格非签名驱动在默认状态 态下加载会比较麻烦。我最终采用的是用户态 HID 通道方案通过 Windows 的 Raw Input API 捕获键鼠事件再通过 SendInput 注入一套镜像事件。这样不需要写内核驱动也不需要在开发模式里折腾签名普通用户装完就能用。这里有一个值得分享的经验如果你做的也是这类需要捕获全局键鼠的工具不要一上来就想着写驱动。先用系统提供的用户态 API 做一套能跑通的版本搞清楚数据通路再去优化底层哪怕后面再考虑上内核驱动也至少要有一个可用的基线版本。3.3 坐标转换算法规避空中鼠标的眩晕感看前文的读者应该了解 seeMote Cap 用的是射线投射方案。但射线方案有一个天然的体验问题如果鼠标位移和射线角速度的换算比例是线性的用户会明显感觉到光标在远景端移动幅度过大在近景端又过于迟缓。这有点像是你在控制一根很长的杆子的末端杆子越长末端移动幅度越大控制精度越差。我把角度增量设计成自适应曲线分为粗调区和精调区。鼠标移动的瞬时速度较快时映射为较大的角度增量快速跨越大范围鼠标移动速度慢下来时自动切换到精调模式角度增量变小便于精确点击小尺寸按钮。这套方案的物理直觉是当你想快速把光标从屏幕左边移到右边时会自然地快速甩动鼠标这时候系统应该理解你要的是大范围移动当你要悬停点击一个按钮时鼠标天然会放慢系统就自动进入高精度模式。不需要手动切换基于速度的自适应机制会处理好。判断逻辑的阈值参数在初期版本里是一个固定值 800 像素每秒但是不同人的操作习惯差异很大后来改成了可配置项默认值是 700。这个值既可以用在电脑端的配置文件里手动调整也可以在 Vision Pro 端的设置面板里直接拖动滑块修改。很多用户在拿到设备后的第一个建议就是调整这个参数把它匹配到自己习惯的手速。所以首版固件就加入了三个预设灵敏度档位并在设置面板里放了实时预览页面方便用户在调整时直接看到当前灵敏度下的光标移动表现。3.4 多设备切换与场景记忆中继方案的一个天然优势就是可以在电脑端管理多套设备的切换逻辑。你可以把一套键盘鼠标配对为办公场景另一套配对为演示场景配合不同的响应曲线和按键映射。比如办公场景里把键盘的右键菜单键映射为 visionOS 的返回手势演示场景里把鼠标中键映射为捏合手势。这些映射关系可以在同一个局域网内自动同步到 Vision Pro 端。场景记忆功能是后来加上的。用户在 Vision Pro 里调整了虚拟屏幕的布局、大小和远近后seeMote 会自动记录这些参数。下次打开同一个应用时自动恢复上次的布局配置。这个功能初听像是锦上添花实际用下来会发现它解决的其实是每次进入空间后重新调整布局的挫败感。空间计算应用面对的问题是虚拟屏幕可以随意摆放是这个平台的优势但也正因为如此每次重新布局都会打断思路。能一键恢复到上次的配置对于重度用户来说省下的时间相当可观。为了做到这一点seeMote 在 Vision Pro 端维护了一个轻量级的场景库基于应用包名来区分不同场景。切换应用时自动加载对应的配置从应用到运用之间的切换不会互相干扰。4. 常见问题与排查技巧实录4.1 光标漂移或跳跃现象光标在移动过程中突然跳到一个不合理的位置或者在停止移动鼠标后仍然继续漂移一小段距离。排查思路分两层。第一层确认是不是鼠标硬件问题。先把鼠标直接连接到电脑上关闭 seeMote 的转发通道看看鼠标本身的移动是否平滑。如果直连没有问题那问题大概率出在传输链路。第二层检查局域网环境。seeMote 走的是 UDP 传输Wi-Fi 环境下的丢包和抖动是造成光标跳跃的头号原因。尤其是路由器开启了 QoS 或者多设备抢占带宽时UDP 包的优先级往往会被降级。解决方法是在电脑端和 Vision Pro 端都加入网络质量自检工具。工具会持续监测当前的丢包率和平均延迟一旦指标劣化超过阈值就会在 Vision Pro 端提示用户检查网络。如果你使用的是 5GHz Wi-Fi并且家里设备较多建议优先使用 5GHz 频段并把路由器设置为固定信道避免和邻居的路由器信道冲突造成干扰。实测下来较稳定的 5GHz 无线网络环境下平均丢包率可以控制在 0.1% 以下光标跳跃的概率会变得极低。4.2 键盘输入延迟与重复触发键盘事件走的是带确认重发的可靠性通道理论上不会丢事件但如果局域网延迟不稳定会出现事件延迟波动。重发机制在某些网络抖动严重的场景下会产生一个问题一个按键按下事件在超时后重发了一次刚好第一次的确认包也到达了接收端就会收到两个按下事件表现为按键被触发两次。处理方法是给每个事件加上序列号。接收端维护一个最近处理过的序列号集合如果新事件的序列号已经存在于集合中直接丢弃。这样即使网络层因为重发产生了重复包也不会对应用层产生副作用。另外一个容易忽略的坑是键盘的按键状态同步。传统键盘输入是按下和抬起两个事件成对出现。如果按下事件在网络上丢失了那抬起事件到达后应用层的状态机就会乱掉表现为某个按键一直卡在按下的状态。在基于 UDP 的传输中这种成对事件的保护尤为重要。我的方案是接收端维护一个按键状态表任何一个新的事件到达时先和状态表比对如果发现状态冲突主动向电脑端请求一次全量状态同步。这个机制虽然占用的带宽极低但极大提升了长时间使用时的稳定性。在早期的测试版本中没有这个保护机制的情况下长时间使用大概每小时会出现一次按键卡死。加上状态同步后连续使用一周没有再遇到同类问题。4.3 虚拟键位冲突与误触电脑端的键鼠和 Vision Pro 端的键鼠是两套完全不同的输入映射。很多快捷键组合在桌面上是一个意思在 visionOS 里是另一个意思。比如你在 macOS 上用 CmdTab 切换应用到了 visionOS 里你期望的是切换空间而不是切应用。这类语义冲突需要通过映射层做转换。seeMote 的映射规则设计成可编程的。支持按应用维度绑定不同的键位映射方案。比如在 Safari 里 CmdW 保持关闭标签页的语义在 Final Cut Pro 里 CmdB 被映射为播放暂停。建立一套按应用区分的映射规则而不是一套全局规则是解决键位冲突的正确思路。这个功能在使用初期需要用户花一点时间配置但配置一次之后基本就是长期收益。我建议首次使用的用户先花十分钟浏览一遍预置的映射方案再根据自己常用的应用做一些个性化调整。注意的是键位映射的修改会实时生效修改时不小心把系统级快捷键覆盖了可能导致某些系统功能暂时失效调整的目的要明确用完后记得还原回去。4.4 意识里的参考为什么说手势不会被取代在开发 seeMote Cap 的过程中我反复被问到的一个问题是空间计算的未来是不是不需要键盘鼠标了你折腾这个是不是逆潮流而动我的理解是键盘鼠标在空间计算时代不会消失它们的角色会发生变化。手势操作在空间交互里适合做离散型的操作比如选中、确认、拖拽、缩放这些动作本身不需要高精度的连续输入。但如果要输入一篇两千字的文章或者要精准调整一个 3D 模型的顶点位置手势操作的精度和效率完全不够用。工具的本质是延伸人的能力而不是替代人的能力。键盘鼠标作为人类历史上最高效的文本输入和精细操控工具在空间计算时代依然有它的生态位。真正发生变化的是交互的层次。在传统桌面时代键鼠是唯一的输入通路在空间计算时代键鼠变成了众多输入方式中的一种和手势、眼动、语音并列。这反而对键鼠提出了更高的要求——它需要和其他交互方式协同工作而不是互相干扰。这也正是 seeMote Cap 在产品设计上着力的方向不是把桌面体验原样复制到三维空间里而是让桌面级输入成为空间感知系统的一部分。5. 实操心得与后续扩展思路5.1 开发过程中最值得反思的三个决策回头复盘整个项目有三个决策我觉得对最终结果的影响最大。第一个是放弃蓝牙直连方案改走中继通道。这个决策在当时看起来是绕远路但它为后续所有功能的实现打开了空间。如果不是因为有一个常开的电脑端做中继键位映射、场景记忆、多设备切换这些能力全部无法实现。第二个是在协议层从一开始就想清楚了 UDP 的分级交付模型。如果当初图省事直接用 TCP 一把梭后期的延迟问题会逼着我把整个传输层推倒重来。分级交付模型在一开始确立后期的网络调优都是在既有框架内做参数优化没有伤筋动骨。第三个是坐标转换没有照搬传统的二维指针映射而是用了射线投射加自适应灵敏度曲线。这个设计决策出自对 visionOS 交互模型本质的理解空间计算系统中输入设备的意义不只是移动一个光标而是控制一个方向。想通了这一层整个交互逻辑就成立。5.2 社区反馈带来的功能演进seeMote Cap 在开发过程中邀请了一部分用户参与内测他们反馈的功能需求直接改变了产品的优先级排序。有个内测用户提出希望在 Vision Pro 的虚拟屏幕上用鼠标拖拽文件时能够有类似桌面端的拖拽反馈效果而不是简单的光标移动。这个反馈让我们重新实现了拖拽状态的可视化反馈在鼠标按住左键拖动时射线终点会显示一个半透明的选中框让用户清楚地知道当前正在拖拽的对象是哪一个。另一个用户建议加入“临时穿透模式”当他需要迅速查看现实世界的桌面时不用摘下头显直接按一下快捷键虚拟屏幕会暂时变得透明露出真实的物理桌面。这个功能从提出到上线只花了两周因为它本质上不需要改传输协议只要在 Vision Pro 端调整窗口的透明度参数就可以。但这个功能带来的体感提升非常明显让 seeMote Cap 从一个输入工具变成了一个空间环境的管理工具。5.3 后续扩展方向预判与技术储备seeMote Cap 的硬件和软件架构预留了一些后续扩展空间。当前版本的设备有额外的蓝牙通道没有启用计划中是为触控板设备预留的。触控板在空间计算环境里可以承载更多的手势语义比如双指滚动在三维空间里可以映射为视角旋转目前这个方向还在验证交互模型。另一个储备方向是键盘的背光状态同步。很多高端键盘有 RGB 背光状态由电脑端的驱动控制。如果通过 seeMote Cap 读取键盘的背光状态并映射到虚拟空间里可以实现一个非常炫的效果虚拟屏幕的光环境随着你键盘的灯光模式联动变化。这个功能不复杂但需要键盘厂家开放协议支持短期内不会作为主推功能作为技术展望来说它是成立的。最后想说的是空间计算的输入问题是这个生态里绕不开的一环现在赛道里做相关方案的人还不多但需求是真实存在的。我在实际使用中最大的体会是不要试图用传统桌面交互的思路去套空间计算也不要把空间交互神化。好的工具一定同时具备高效率和低学习成本而把桌面工具带进空间计算就是通往这个方向的一条切实可行的路径。