用 Codex 拆一颗坏掉的血糖仪：AI 能读到的，和读不到的

Mon, 12 Oct 2026 07:50:00 +0800

先说这个场景

花一百美元买了个连续血糖监测仪（CGM），想搞清楚血糖波动到底有没有人们说的那么要紧。第一颗还没预热完就罢工，换来的第二颗撑了两天。钱退了，但作者 Farhan Ahmad 心里不痛快：一个贴在身上的医疗设备，坏了就坏了，连一句「我为什么坏了」都不给。

他是软件工程师出身，也做数据科学，对嵌入式设备有点概念。于是他把那颗已经扔进垃圾桶的传感器翻了出来，连同贴着蓝牙 PIN 的敷贴器一起，去问 Codex 和 OpenAI Astra：

我有一颗坏掉的罗氏连续血糖监测仪，就在这台电脑旁边。它自称 AC-1R00075XXXX。你能不能建立蓝牙连接，把它还在发的东西读出来？

几分钟后，Codex 写好一段 Python，扫描蓝牙、配对，把传感器里残存的数据整个 dump 了出来。

这个细节值得停一下。问题本身是模糊的，「把它发的东西读出来」既没有协议，也没有数据结构，更没说怎么连。Codex 在这里做的事不是写一个 App，而是把他脑子里的一个疑问，翻译成了一段能跑的程序。

工具是 Python 加 Bleak（蓝牙低功耗通信库），在 Mac 上走 Apple 的 CoreBluetooth。

传感器在扫描里出现了，也接受了连接，暴露三个 service：

设备信息回的是 Roche Diabetes Care GmbH、型号 303、固件 FW_V7.5.1-9205bbad。也就是说，虽然 App 判定它死了，射频部分和足够回话的那部分固件还活着。所谓「变砖」，至少在这里是个会话状态，不是彻底断电的硬件。

关键的一步在这里。传感器实现了标准的蓝牙 CGM 服务，里面有个叫 Record Access Control Point 的特征值，客户端可以通过它索要存储的测量记录。作者发了两条请求：先数记录条数，再全部取回。传感器报 96 条，给了 96 条，最后回了成功。

96 条记录拆开是这样：

96 条记录的校验和全部通过。这说明取回来的数据包本身是完整的，但不代表底下的血糖测量是对的。这两件事经常被混为一谈。