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 也有问题。键盘事件不能丢，你按了一下 Ctrl+C，这个包在网络上丢了，后果是整个快捷操作没有生效。所以我在协议层做了一个简单的分级处理：鼠标位移事件走轻量 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 上用 Cmd+Tab 切换应用，到了 visionOS 里你期望的是切换空间，而不是切应用。这类语义冲突需要通过映射层做转换。
seeMote 的映射规则设计成可编程的。支持按应用维度绑定不同的键位映射方案。比如在 Safari 里 Cmd+W 保持关闭标签页的语义，在 Final Cut Pro 里 Cmd+B 被映射为播放暂停。建立一套按应用区分的映射规则，而不是一套全局规则，是解决键位冲突的正确思路。
这个功能在使用初期需要用户花一点时间配置，但配置一次之后基本就是长期收益。我建议首次使用的用户先花十分钟浏览一遍预置的映射方案，再根据自己常用的应用做一些个性化调整。注意的是，键位映射的修改会实时生效，修改时不小心把系统级快捷键覆盖了，可能导致某些系统功能暂时失效，调整的目的要明确，用完后记得还原回去。
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 读取键盘的背光状态并映射到虚拟空间里，可以实现一个非常炫的效果：虚拟屏幕的光环境随着你键盘的灯光模式联动变化。这个功能不复杂，但需要键盘厂家开放协议支持，短期内不会作为主推功能，作为技术展望来说它是成立的。
最后想说的是，空间计算的输入问题是这个生态里绕不开的一环，现在赛道里做相关方案的人还不多，但需求是真实存在的。我在实际使用中最大的体会是，不要试图用传统桌面交互的思路去套空间计算，也不要把空间交互神化。好的工具一定同时具备高效率和低学习成本，而把桌面工具带进空间计算，就是通往这个方向的一条切实可行的路径。
