把录音卡协议文档丢给AI编程工具，一小时搭出全本地会议后台

现在办公真的离不开录音设备，但想买一台合适的、还能接进自己系统的，太难了。

录音需求旺盛的人，多少都经历过这样的循环：大牌设备好用是好用，但录音锁在官方 App 里，转写要开会员，数据先过厂商的服务器——用着用着就发现，自己花钱买的硬件，权限还攥在别人手里。几十块的便宜货倒是随便导出，可杂音大、转写不准，扛不住正经会议。

这一款开源AI录音卡，办公室几个人轮流试用了一周。蓝牙协议逐字节公开，SDK 覆盖 Android / iOS / Flutter 等多端，连桌面 Demo 的源码都躺在 releases 里。也就是说，这张卡出厂时附带的不是一个 App，而是一整套没人拦着你用的接口。收音和续航这一块，这张卡完全没给我操心的机会——三米内说话听得清清楚楚，充一次电撑一整天。

对于音频不上云、转写引擎自己挑这件事，我惦记很久了。公司每周两个项目会，聊的都是客户报价和未发的方案，这种内容谁敢往云上传？官方 App 再好用，数据也得先过一遍别人的服务器，这根刺一直拔不掉。

正好周末没事，我把心一横：协议文档不是全公开吗，那就自己搭一个。把协议文档丢给 AI 编程工具，一小时，搭一个只属于这张卡的全本地会议后台。

第 0–15 分钟：AI 比我先读完文档

仓库 docs 目录的 BLE 协议文档不算短，但 AI 编程工具几分钟就读完了，还顺手把操作顺序给我捋直了：先配对，再订阅 0xAE20 服务下的实时音频特征，录音数据是 16kHz 单声道的 Opus 裸流，按固定长度分包传回来。releases 里的桌面 Demo 源码就是现成的参考答案，AI 照着它的连接逻辑抄，比从零啃协议省了不止一倍工夫。

说白了，文档开源的意义不是「给你看」，是「给 AI 读」。要是换成封闭厂商，这一步压根不存在——没有文档，AI 再厉害也只能干瞪眼。

第 15–35 分钟：写收音服务，踩了两个真坑

AI 写出来的服务一跑，九成都顺：扫描、连接、订阅特征、收帧、解码，一路绿灯。剩下那一成，全在真机上冒出来了——

第一个坑：Opus 裸流没带文件头，解码器按默认参数解，出来的全是沙沙的噪音。对着协议翻了两遍才发现得手动指定 16kHz 单声道，改一行，声音「啪」地就出来了。

第二个坑更阴：长录音老丢最后几秒。排查了半天，原来是分包确认（ACK）没按文档处理，卡那边等不到应答就丢帧重传。补上 ACK，一小时的长录音完完整整落了盘。

这两个坑其实文档里都写着呢——读没读、读没读对，区别就是十分钟和一个下午。第 35–55 分钟：转写引擎，我选的不是它内置的

官方 App 自带的转写、总结、思维导图，日常开会确实够用。但协议摊开了，玩法就不止这些——转写引擎可以自己挑：本地跑 FunASR 小模型，普通办公本 CPU 就带得动，断网照样干活。转写文本直接落盘，今天用 FunASR，明天想试 Whisper？改个配置就行——模型层没人锁，按量计费这四个字，跟这套系统八竿子打不着。