先说这个场景#

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

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

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

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

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

读到了什么#

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

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

  • Device Information（设备信息）
  • Continuous Glucose Monitoring（连续血糖监测）
  • Reconnection Configuration（重连配置）

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

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

96 条记录拆开是这样：

  • 34 个有效数字血糖值
  • 29 个 NaN，意思是当时拿不到数字测量结果
  • 33 个 -Infinity，附带一条警告，说结果低于设备能处理的范围

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

故障标志说了什么，又没说什么#

传感器还广播了一个对应 CGM Status 的特征值，读出来只有三个字节：

09 00 00

第一个字节 0x09，第 0 位和第 3 位置位，对应「会话已停止」和「传感器故障」。这是个有用的确认，但判断很粗，没有跟着解释是感应元件断了，还是哪个内部自检没过。

其他标志位也解了：没有低电量、没有温度过高或过低、没有一般性设备故障。传感器的功能信息显示它支持检测这些情况，所以这些没报，不是因为不支持报。

还有个细节：96 条记录全部带着「需要校准」标志，其中 63 条同时还带「不允许校准」。罗氏文档里「需要校准」对应的是 Trend Mode（趋势模式），本来就需要用指尖血校准，而作者一次都没校过。趋势模式下的读数偏差可能到 10%。

能推到哪一步#

从这次抓取能得出的最强结论是：传感器反复没能产出可用的测量值，而且经常在报「结果低于可处理范围」。

往下的解释就有好几种。佩戴中的传感器受到压迫会产生偏低的读数，这点在睡眠姿势和传感器表现的研究里有记录。但那个研究用的是别的传感器，不能直接拿来说这颗罗氏。也可能是感应元件位移或损坏，或者测量处理环节出了问题。手上没有原始电极信号，也没有独立的血糖参考值，这几种可能分不开。

还有一份清单，是这次抓取里明确拿不到的：详细的故障日志、原始电极电流数据流、电池电压历史、崩溃转储。厂商可能有一套私有的诊断流程，但作者没找到。他也没试未公开指令，没重置传感器，没改校准，没重启会话。

对用 Codex 的人，这件事的启发在哪#

这个故事最值钱的地方，是它把 Codex 的能力边界画得挺清楚。

Codex 擅长把模糊问题变成可执行的探测。你不懂 BLE，不知道 GATT 特征值怎么读，它直接给你一段能跑的代码，门槛压得很低。这个能力在硬件上跟在软件上一样有用。

但它的上限由设备暴露的接口决定。软件里 agent 能读源码，顺着调用链往下挖；硬件里它只能戳公开的 API。标准蓝牙 CGM 服务本来就是给用户侧用的，不是给调试用的，所以这次拿到的是「故障了」这个结论，拿不到原因。这条通道上本来就没传这个信息。

问对问题的责任在人这边。作者试了哪两条请求（数条数、取全部），是懂协议的人才做得出的判断。Codex 能替他写代码，决定不了他该问什么。解读取回来的数据也是同一个道理：0x09 说明故障，但它不解释故障，读懂这个区别是使用者的活。

还有一点我比较欣赏：作者没往下乱试。没试未公开指令，没重置，没改校准。对一个可能是治疗用途的设备，这种克制是对的。Codex 从来不缺「再试一步」的能力，缺的是有人替它踩刹车。

现在他想找人一起看#

作者现在手上有一份完整的原始蓝牙抓取、解码后的记录、一张图和所有脚本，他想找人一起看。他列了几类人：懂罗氏 CGM 行为的、懂传感器工程的、懂蓝牙和固件的、有可比案例的，以及最后愿意撬开外壳找调试焊盘的人。

从他自己的复盘看，最想弄清的其实是个产品问题：如果这套系统是我做的，我会塞点遥测进去。是感应元件坏了，还是校准出了问题，还是软件自己判定读数不可信了？现在答案是空白。

一颗一百美元的传感器死了，你得到的信息和它完全没坏过一样多。

参考来源：Farhan Ahmad, “Sniffing a Bricked Glucose Monitor with Codex”, Medium, 2026-10-11. https://medium.com/@farhanhubble/sniffing-a-bricked-glucose-monitor-with-codex-690c74229d02