用Claude Code破解AirPods 3头部追踪协议，Linux用户成功用耳机控制鼠标

一位开发者首次在Reddit发帖，分享了自己利用Claude Code逆向工程AirPods 3头部追踪数据的经历。他原本想让AirPods的陀螺仪在Linux上充当鼠标控制器，却发现所有开源项目都声称不支持AirPods 3。经过一个下午的尝试，他不仅找到了答案，还发现了一个此前无人公开的协议差异。

从“不支持”到找到突破口

开发者想用AirPods 3的陀螺仪在Linux上控制鼠标指针，但搜遍开源项目后发现，绝大多数方案都只支持AirPods Pro。面对“不支持”的普遍结论，他决定用Claude Code尝试逆向。

过程并不顺利。他经历了大量失败尝试，直到让Claude Code派出多个后台代理，去挖掘其他相关项目的代码库。其中一个代理在iOS框架代码里找到了关键线索：AirPods 3使用的是与Pro型号不同的通信协议。

这个发现解释了为什么此前没有人成功——大家可能都沿着Pro的协议路径去尝试，而AirPods 3需要完全不同的解析方式。

Linux隐藏传感器的蓝牙包大小问题

找到协议差异后，开发者还发现Linux系统本身在“隐藏”传感器数据。问题出在一个蓝牙数据包大小设置上——该设置导致AirPods 3的传感器数据没有被正确暴露。

调整这个设置后，AirPods 3开始以约200Hz的频率流式传输头部追踪数据。这个频率对于鼠标控制来说已经足够流畅。开发者强调，代码大部分由Claude Code编写，他本人负责用真实AirPods做测试和关键决策。

蓝牙低功耗（BLE）中，ATT MTU（Attribute Protocol Maximum Transmission Unit）决定单次数据包能承载的负载大小。默认MTU通常为23字节，扣除ATT头后有效载荷仅20字节；而传感器数据流往往需要更大的包。若MTU协商失败或系统未主动请求更大MTU，较长的数据包会被截断或丢弃，表现为“传感器不存在”。此外，L2CAP的MTU与ATT MTU是两个层级，Linux BlueZ栈对两者的处理策略不同，常需通过btmon抓包或调整内核/BlueZ配置来排查。

AI编程工具在逆向工程中的角色

这次探索展示了AI编程工具在逆向工程中的实际价值。传统上，逆向一个未公开的蓝牙协议需要大量手动分析和试错，而Claude Code的“代理”模式能够并行搜索多个代码库，缩短了发现关键线索的时间。

开发者坦言“速度快得有点不可思议”。不过他也明确了自己的分工：AI负责生成大部分代码，人类负责测试验证和方向判断。这种协作模式在硬件相关的逆向工作中尤其重要，因为AI无法直接操作物理设备。

逆向工程未公开的蓝牙协议通常需要：抓包（如btmon、Wireshark）、识别GATT服务与特征值、推断数据帧格式（帧头、序列号、时间戳、四元数/欧拉角编码）、以及验证数据与物理运动的对应关系。传统流程高度依赖人工阅读反编译代码和试错。Claude Code的“后台代理”模式本质上是让多个LLM实例并行检索不同代码库（如iOS框架、开源驱动、协议文档），再汇总线索，从而缩短“假设—验证”循环。但LLM无法直接操作硬件，也无法保证协议推断的正确性，因此人类仍需负责抓包验证、物理测试和最终决策。

开源项目mousepods

开发者将成果开源在GitHub仓库mousepods中，供其他好奇的用户参考。对于想在Linux上利用AirPods传感器做创意交互的开发者来说，这个项目提供了一个可复现的起点。

目前该项目主要聚焦于鼠标控制场景，但协议层面的发现可能为更多应用打开空间。开发者没有透露具体代码量或性能细节，但从200Hz的采样率来看，实时交互类应用具备可行性。

整个探索耗时一个下午，这与过去需要数天甚至数周的手动逆向形成对比。AI辅助编程正在降低硬件黑客的门槛，让个人开发者也能快速切入此前被视为“无人做过”的领域。

对Linux音频生态的启示

AirPods 3在Linux上的支持一直不完整，这次发现揭示了问题的一部分根源：不仅是协议差异，还有系统层的蓝牙配置问题。对于Linux音频开发者来说，这个案例提示了检查蓝牙包大小设置的必要性。

不过，单个开发者的成功并不意味着AirPods 3在Linux上已经完美支持。该项目的重点在于头部追踪数据流，而非完整的音频功能。但至少，它证明了“不支持”的结论可能只是尚未有人找到正确路径。

开发者最后表示，如果其他人感兴趣可以查看仓库。这种开放分享的态度，正是开源社区推动硬件兼容性进步的方式。