SomaLoop App 设计

PROTOTYPES两套交互方案

两套方案共享同一套设备、指标与 Agent 能力，只改变用户每天进入 App 后理解身体的方式。点击卡片可直接体验。

00一句话与目标

01产品原则

十一家 AI 教练的形态与失败模式（App 调研合集第一、二部分）浓缩成七条。每条都会在验收里出现。

1. Agent 就是界面。手环无屏，用户与身体数据的全部交互经由 Agent 发生。Today 页不是仪表盘，是 Agent 的时间线。
2. 先说，再等你问。每天最多三张主动卡（醒来、运动后、睡前），加事件触发的推送；没有超出个人基线的变化就不生成。WHOOP 的原则：无事则静。
3. 每句话可点开依据。任何含数字或结论的句子都附「依据」芯片，点开是原始数据段、时间戳与基线。后台统计接地率并展示。这是对 Google、WHOOP 最集中负评（引用不存在的数据）的直接回应。
4. 能动手。Agent 可发起测量（心率、血氧、HRV、ECG）、设提醒（普通、吃药、喝水）、设久坐提醒、远程开启运动模式、写入记忆。七家大厂无一能按下测量键，这是唯一不用比模型聪明的地方。
5. 记得，并且让你看见它记得。记忆分目标、健康史、生活事件、关注与忽略四类，可查、可改、可删；主动消息必须读记忆，否则重蹈 WHOOP Daily Outlook 的投诉。
6. 说人话，不说病名。不出现房颤、呼吸暂停、高血压等疾病名，不做血糖与血压数值；说「节律不规则」「血氧低于你的基线」；所有输出附「健康参考，非医疗建议」。
7. 数据永远免费，只卖解读。原始数据、导出、基础指标不收费；若有付费层，只放 Agent 解读、计划与长期指标（订阅分层报告结论）。
8. 可拆开看，可接出去。面向 BioHacker 的承诺：每个分数都能拆到原始数据；每段数据都能导出（CSV / EDF / WFDB）；实时 RR、PPG、ECG 流可以开给自己的程序；Agent 用的每个工具都以 MCP 暴露，用户可以换成自己的模型。App 里做的每一件事，开发者都能用 SDK 复现。

02用户与场景

首发用户

个人佩戴者，25 到 45 岁，戴过或考虑过 WHOOP、Oura、Fitbit Air，对「订阅制」和「只给分数不给原因」不满，愿意对一个 App 说自己的生活。机构版（护士站、班组、教练看队员）作为后续模块，本版只在信息架构里留位。

DevKit 用户

与首发用户重叠但动机不同：量化自我与生物黑客（自己写脚本看 HRV、做咖啡与睡眠的对照实验）、研究者与学生（要原始 ECG 与时间戳）、AI Agent 开发者（要 MCP 与事件流）、准备做产品的团队（把这个 App 当白标起点）。App 对他们的承诺见第一章第八条；专属入口在 Me 页的「Lab」区：原始数据流开关、导出、实验、MCP 端点与 API key、接地率与记忆保存率面板。演示稿里 Me 页要把这块做出来，因为它是「DevKit for BioHacker」这句话的证据。

核心用例

用户用一句话描述一件生活里的事，Agent 把它变成一个「玩法」（Playbook）：明确目标、要收集什么数据、手环要做什么动作、每天什么节奏说话、什么时候结束并复盘。第四章定义了十二个玩法，三个是主演示。

03信息架构

四个标签加一个常驻输入框。Today 是 Agent 时间线，其余三个标签是 Agent 的「工作台」，每一屏右下角都能追问。

04场景引导系统

用户不知道该对一个健康 Agent 说什么，这是所有 AI 教练冷启动的共同问题。SomaLoop 用「玩法」把开放式对话变成有限的、可预期的入口，并在四个位置持续引导。

引导出现的四个位置

玩法（Playbook）的统一结构

每个玩法是一份声明式配置，Agent 依此执行；开发者未来可以用同样结构写自己的玩法。

playbook:
  id: marathon-4w
  trigger: ["马拉松", "跑马", "半马", "全马", "参赛"]      # 命中即建议开启
  intake: [赛事日期, 目标完赛时间, 每周可训练天数, 最近一次长跑距离]   # 一次问完，写入记忆
  needs: [夜间心率, HRV, 睡眠分期, 运动会话心率, 步数]   # 手环数据
  actions: [开启跑步模式, 训练日晨间恢复门控, 长跑日前夜提醒, 赛前 3 天减量, 赛日 5:30 闹钟]
  cadence: {morning: 训练建议, post_workout: 负荷与区间复盘, evening: 明日预告, weekly: 周报}
  guardrails: [负荷比 > 1.4 强制降级, 夜间心率高于基线 8 bpm 连续两晚建议休息]
  memory_writes: [目标: 10/12 马拉松 4:00, 生活事件: 训练周期]
  end: {at: 赛后 3 天, deliver: 复盘卡 + 是否续接「恢复两周」玩法}

三个主演示玩法

其余九个玩法（摘要）

05Agent 交互规范

消息卡类型

依据（Evidence）

每个含数据的句子绑定一个依据对象：指标、时间范围、数值、基线区间、图表类型。渲染为芯片，点开为底部抽屉，显示原始数据段（可缩放）、采样点、基线阴影区、数据来源（自动监测 / 即时测量）。没有依据的句子在开发者面板里标灰并计入未接地率。目标：含数据句子的依据覆盖率 100%，整体回答接地率 ≥ 80%（WHOOP 自报 56.6%）。

记忆

• 四类：目标、健康史、生活事件、关注与忽略。每条记录来源对话与时间，可编辑、可删除，删除后下一条消息立即不再引用。
• 写入回执必须出现在时间线里，用户看得见 Agent 记了什么。
• 主动卡生成前必须读取记忆；开发者面板显示「应保存上下文的实际保存率」与「主动卡引用记忆的比例」。

三个旋钮与静默原则

• 频率：少（只在偏离基线时）/ 标准（每天最多 3 张）/ 多（加上每次运动后与每周报）。默认标准。
• 长度：一句话 / 标准 / 详细。默认标准（标题 + 3 句 + 3 条要点）。
• 语气：直接 / 温和。默认直接。参照 Oura 的 direct / conversational。
• 静默：夜间 23:00 到 7:00 不推送（SOS 与用户设置的例外除外）；近 7 天已说过的结论不重复；用户点过「今天休息」后当日不再催训练。

语言规范

• 数字先于形容词：「夜间心率 52，比基线低 3」而不是「你的心率很好」。
• 比较对象永远是本人基线，不是人群；基线未满时明说「还不知道」，不用人群区间冒充。
• 不做结论性判断（正常 / 没问题），只说相对变化与可能的生活因素。
• 一张卡最多一个反问句。
• 拒答后必须给动作。

06数据与算法层

全部确定性计算在手机侧完成，LLM 只做解读与编排。手环不跑 AI。

V8 能给什么

没有的：呼吸率字段（从 PPI 的呼吸性窦性心律不齐推算）、原始加速度流（做不了肌肉负荷）、GPS（配速用手机 GPS 补）、震动马达指令（「震一下」用一分钟后的闹钟替代，演示时如实说明）。

指标层（第一版范围）

• 夜间五项基线（心率、HRV、呼吸率推算、皮温、SpO2）：7 到 30 天个人范围，超出即事件。这是 Agent 主动消息的主要事件源，也是 Body 页的第一屏。
• 睡眠分：参照 Apple 公开权重（时长 50 / 就寝规律 30 / 中断 20）做参考实现，贡献项全部可见。
• 恢复分：白盒，六项贡献（RHR 偏离、HRV 平衡、皮温偏离、恢复指数、睡眠、前日活动）各 0 到 100 并给量化说明。
• 负荷：TRIMP 加 7 对 28 天比值，分档抄 Garmin / Polar 公开阈值；不做 EPOC 与肌肉负荷。
• 日间压力：HRV 包加步数排除运动；粒度 30 分钟，标注。
• 校准期：所有分数 14 夜；期间显示「已积累 N / 14 夜」与已能看的原始趋势；第 14 夜主动推送「从今天起可以看恢复分了」并解释组成。

Agent 架构

• 内联注入（WHOOP 做法）：当天摘要、基线、最近事件、记忆在 prompt 渲染时直接注入；只有「发起测量、设提醒、开运动模式、查历史、写记忆」走工具调用。
• 确定性优先（Google 做法）：事件检测、基线、负荷比全部是算法输出，LLM 不做数值计算。
• 拒答门禁：合成 Persona 输入集覆盖疾病名提问，通过率作为发版前置。
• 模型可换：Claude、GPT、Gemini、DeepSeek、本地模型均可；开发者可自带 key。

07屏幕与关键流程

这是演示稿要做出来的清单。带「★」的是三个主演示流程必经的屏。

08设计语言

对齐 WHOOP 与 Oura 的标准，具体到可以验收的规则。页首的小样是按这套规则做的 Today 页。

09边界与合规

• 非医疗器械，仅供健康参考与研发；所有 Agent 输出附「健康参考，非医疗建议」。
• 不出现疾病名；不做血糖、血压数值；HRV 包里的血压与血管老化度隐藏或标「参考」。
• 不用人群阈值冒充个人基线；基线未满时明说。
• 发给医生、联系家属、改用药提醒必须人确认并留痕。
• 数据默认留在手机；云端可选且可自建；明示不用于训练。健康数据按敏感个人信息处理，单独同意。
• 拒答门禁通过率作为发版前置；接地率作为发版门禁指标。

10度量与验收

11路线与演示稿计划

阶段

1. HTML 演示稿（本文档确认后开始）：手机尺寸的可点击原型，深色，按第八章规则实现；三条主演示流程可完整走通；数据为脚本化的假数据，但结构与真实 SDK 字段一致；可部署到 ecg-devband-report.pages.dev/app/demo。
2. 原生 App：建议 Flutter 一套代码，通过平台通道桥接 V8 的 iOS 静态库与 Android aar；BLE 连接与历史同步（每批 50 组、断点续传）在原生层；指标层与 Agent 编排在 Dart 层；多设备并发演示前必须真机实测。若团队更熟原生，则 iOS Swift + Android Kotlin 双写，SDK 直接调用。
3. 白标化：品牌、配色、玩法库、旋钮默认值全部配置化，成为开发者套件的参考 App。

演示稿的三条主线（15 分钟）

剩余 2 分钟：Me 页展示记忆与三个旋钮，再进 Lab 打开一条实时 RR 流、导出一段 ECG、展示 MCP 端点与接地率，说明「这就是 DevKit for BioHacker：消费者能用，开发者能拆」。

可点击的 HTML 演示稿：ecg-devband-report.pages.dev/app/demo（核心页与核心交互，假数据，结构与 SDK 字段一致）。

00三个来源

界面上任何一个数字，来源必须是下面三者之一。混着说就会出现「这个数到底是谁算的」。

01状态词汇

同一个「没有数」，原因不同，说法就得不同。这套词汇全 App 统一。

缺失的四种原因

稳定度四态

服务端返回 scores.stability.level，App 只按它换文案与颜色深浅，不改数值。接入清单明写：首页三卡按它显示。已实现（2026-09-28）。

冷启动的加权由服务端处理：心率与 HRV 两项乘以 w = n/(n+3)，缩掉的份额由当夜睡眠分补上。第 1 晚 w=0.25，第 14 晚 0.82。所以第一晚就有数，没有「空白→突然出数」的跳变，App 不需要自己做冷启动逻辑。

其他状态

• partial_day：当天心率覆盖不足六成（首日佩戴、白天没戴）。load_7d 不计这类天。
• status ∈ provisional | final | revised：稳定度 stable 且非 partial_day 才是 final。修订过的日报要能看出来。
• 来源优先级：手环 > 服务端 > Apple 健康 > 模拟。同一指标多来源不求和，按优先级取一个。
• 历史时区未知时保留未知，不把手机时区套进旧数据。

02首页头部

tab 以上的一整块，四个栏目共用。

报头

• 字标 · 通知铃铛（有未读时带点）· 头像（昵称首字，未设时「T」）

状态行

Hero 左栏

Hero 右栏 · 设备场景

• 佩戴位置手腕 / 上臂：用户自选的设置，不是识别。存本地，服务端无对应字段。原型上的「已识别 · 贴合良好」需要佩戴检测，SDK 没有这个能力。
• 手环佩戴图：静态素材。
• 心电纸网格 + 走动的迹线：心搏间隔由实测心率算（60/bpm），心率高则走得密。波形不是录下来的心电——这条链路没有连续 ECG 流。
• 静息心率读数：resting_heart_rate。服务端定义是睡眠窗内心率 5 秒点的 25 分位；现在用的是手环日汇总，接拉取后换成服务端值。

三张指标卡

恢复 / 睡眠 / 负荷。三项都是服务端评分，未登录时全空——那时按优先级换成手环确实读到的指标顶上（心率、变异性、步数、血氧）。每张卡五层：

缺的：状态行应该按 stability.level 显示「初步 / 校准中 / 覆盖不足」，现在只有「有数」和「—」两态。

03洞察

回答「今天怎么样，凭什么这么说」。

日期切换

前一天 / 后一天 / 日历 / 回到今天。范围 90 天。

话题与趋势

• 四个话题 chips：恢复 / 睡眠 / 心率 / 步数。
• 选中项的 14 天趋势图 + 区间（最小–最大）+ 今日值。缺数的天不补点。
• 结论段落：复述读数与口径，不加判断。例如恢复度那段会说明它由睡眠、静息心率与 HRV 共同得出，且和「今天该不该运动」不是一回事。

亮点（Apple 健康 Highlights 的做法）

自动挑出这周确实变了的最多三项，每条是「本周 X 平均 A，上周是 B」+ 14 天柱图 + 变化百分比。两周各至少 3 天有数、相对变化 ≥ 4% 才入选；够不上就不摆。

身体信号四格

静息心率 / 心率变异性 / 血氧 / 皮温。每格：名称、大数字、个人区间条、区间说明。

皮温要改：服务端给的是 skin_temperature_deviation_c（相对近 7 天中位数的偏差），现在当绝对值在显示，语义不对。

今天的节奏

手环这一天确实记下来的几件事，时间取自数据本身，不是编的时刻表：醒来（睡眠起止 + 时长对目标）、活动（步数 + 折算距离）、静息心率（日间 + 夜间）。

其余

• 入睡提醒入口（本机提醒，不上传）
• 全部指标入口（弹层）
• 「这些结论对你有用吗」——有用 / 没用，目前只存本地
• 免责声明

04长寿

几周以上的变化。单天的起伏在这里被抹平。

打卡应该走 POST /me/events {kind:"habit_checkin", ts, attrs:{habit}}，现在只存本地。event.kind 还支持 reminder / note / medication / supplement / illness / travel——生活记录那一大块的落点就是这个接口。

05睡眠

06Lab

重点是 agent 接入，不是原始记录的计数器。回答「别的程序怎么用到这些数据」。

• 能调的工具：measure / daily / series / raw / sync。可用与否问设备层要，不是写死的清单——心电在这只固件上调不通就标「不可用」。
• 调用示例：代码块，说明返回结构与上传契约同一套（soma.sample/v1、soma.measurement/v1），字段名一个字不差。
• 本地存了什么：原始记录数、等待上传数、有记录的天数、手环与固件。
• 导出：CSV（带时间戳与来源）+ 系统分享。

未做：PPG / PPG+ACC 原始采集与会话管理、信号预览、缺包计数、采集模式与 SDK 版本标注、原始数据与日志导出。原始采集与历史同步不能并行（SDK 会 busy），这个互斥要在界面上表达。

07弹层

全部指标

11 项按主题排列（恢复/变异性 · 睡眠/夜间心率/皮温 · 心率/血氧 · 步数/距离/热量/负荷），每行：圆底图标、名称、口径说明、7 天迷你折线、当日值。带搜索。

指标详情

• 时间范围 7 / 30 / 90 天
• 当日值 + 口径
• 柱状趋势图 + 「N 天中有 M 天的记录」
• 这段时间的平均 / 最低 / 最高

未做：7/14/28 天对比（需求里明确要三档）、数据来源与采集/同步时间标注、覆盖率、过期与部分同步状态。

测量

半高抽屉列出四项，按固件能力灰掉不支持的并写明原因。选一项进具体流程。

未做：类型/日期筛选、前后比较、重复点击保护、设备占用提示、有效与失败记录分开、取消/停止二次确认、按测量类型验证信号质量。不能以倒计时结束冒充有效结果——现在走的是真 SDK 返回，这条满足。

设备

我与设置 · 登录

• 昵称、睡眠目标、每日结论提醒、夜间安静时段、账号登录/退出、数据去向说明、版本与免责
• 登录：手机号 + 验证码，两份同意（service / health_data）带 text_version

未做：PATCH /me {birth_year, sex}——负荷的心率区间要年龄（HRmax = 208 − 0.7×年龄），不填则退化成步频档；也是拒绝 14 岁以下注册的依据。PATCH /me {preferences}——睡眠目标、Insight 推送、安静时段服务端都有字段，现在只存本地。身高体重、体重历史、健康目标、数据处理授权与撤回、导出与删除，全部未做。

08需求对照

团队 MVP 需求九大项，各自落在哪一页、做到哪一步。

需求里两条原则已经落到界面上：无聊天框、无教练对话、无对话记忆（偏好只通过明确设置维护）；演示数值必须属于 mock（启动参数 dev-data 才用模拟数据，不带参数时读不到的显示「—」，并在依据页标明当前是否演示数据）。

10完整数据清单

把三个来源能给的每一项都摆出来，逐条对一遍它在界面上的落点。重点是「展示位置」那一列——写「未展示」的，就是拿得到却没用上的。共 144 项，其中 94 项未展示。

服务端 · 日报 soma.daily/v1（GET /me/days）

38 个字段，一个都没读——GET /me/days 还没接。括号里写的是同一个位置现在显示的东西：要么是手环日汇总，要么是本地按固定比例推算的。

服务端 · 其余读取接口

四个读取接口（/me、/me/timeline、/me/measurements、/me/events、/devices/{id}）一个都没调。样本与测量这两套字段 App 天天在产（上传走的就是这个契约），但从来没读回来过。

手环 SDK · 能力表里的每一项

同步默认只拉五条流：dailyActivity、heartRate、bloodOxygen、hrv、temperature。睡眠流不在里面——不是「存了原文没解析」，是根本没读。

App 现有的十一个指标（Domain）

真实数据下本地库只写得出五项：心率、血氧、HRV、皮温、步数（按天取中位数，步数取当日累计）。恢复度、睡眠时长、睡眠分、夜间心率、负荷没有任何产出方——手环没读，服务端没接，界面上一律是「—」。带 dev-data 启动时才由模拟值顶上。

本地与用户输入 · 运行时状态

09拿不到的东西

不是没做，是当前拿不到。每条写清卡在哪。

11V8 直连包

L1 把一批能力关在闸后面，而 dev-console 用同样的字节在同样的硬件上跑通过——闸在 SDK 里，不在设备里。这个包按厂商源码自己拼包直连 BLE 发，等 L1 放开后整体并回去。

已经建好的：纯字节层

SomaLoop/DeviceV8/V8Protocol.swift，不碰蓝牙，9 个单测全部对着厂商已知样本断言。

一处两份厂商 SDK 互相矛盾：HRV 的子码 Android AutoTestMode 是 0x01，iOS MeasurementDataType_V8 写的是 4（和心电撞号）。按 Android 那份走，因为 dev-console 跑通的是那一套。真机验到哪种就改哪种。

两处要更正的认知

还没写的

• BLE 传输层（扫描 / 连接 / 写 FFF6 / 订阅 FFF7 / 分包重组）
• 回包解析：测量结果、心电波形
• 与 DeviceLink 的接线：L1 拒绝时自动退到直连
• 震动：字节已备好，但要先在实机上验证设备收不收——验通了再往界面上放按钮

12变更记录

S1一页看完

九条。前三条正在挡功能，中间三条是一致性问题，后三条是语义空白。

S2能力闸挡住了测量

现象

手上这台设备（JCV8B，固件 00000808-260604）调 measure(.heartRate) 稳定返回 unverifiedCapability。心率、血氧、HRV 三种都一样。

为什么

《能力与迁移.md》说明了判定规则：

也就是说，闸不是按「设备能不能做」开的，是按「厂商验没验过这一台」开的。这个设计本身没问题——unsupported 必须有证据，不因一次没响应就设置，这条规矩是对的。问题在于结果是一台功能正常的设备被判为不可用，而 App 侧没有任何办法推翻。

反证

develop-console 的 Python 实现，用同一批字节（0x28 子码 02/03/01）在同一台硬件上拿到过结果。原厂 V8 SDK 的源码里也没有任何固件门禁——grep firmware、grep capability 在 BleSDK.java 里一处都没有。所以设备是支持的。

我们的处理

写了一个 V8Protocol 纯字节层，按原厂 SDK 源码把包自己拼出来。没有绕过 SomaLoopClient 去直接写 AppleBLETransport——文档明确要求不要那样做，而且会和客户端自己的命令串行化打架。所以这条路目前是停在「字节拼好了，但没有合法的发送通道」。

S3触觉：绑死在一台设备上，而且没有实现

绑死在参考 MAC

protocol/protocol.json 的兼容性 profile 里写得很直白：

所以触觉只在那一台特定的手环上能发。这对「用振动认出是哪一只手环」这个需求是致命的——恰恰是有多只手环时才需要它。

更根本的问题：V8 层面没有振动

我一开始以为 iOS 头文件里的 MotorVibration_V8 = 14 是个操作码，这是错的。它是回调数据类型枚举的一个成员（一个索引），不是可发送的命令；0x14 在协议里是 Temperature_3NTC。

核对两份原厂 SDK：

• iOS BleSDK_Header_V8.h：全文搜 ibrat，只有 MotorVibration_V8 = 14 这一个枚举成员，没有任何发送函数。
• Android BleSDK.java：搜 ibrat，零命中。

L1 的 97 36 01 / 97 36 00（内部提醒状态开关）是 L1 自己加的，V8 原厂没有这个能力。所以「不绑定就发振动」这条路走不通，我们已经把配对流程里的振动去掉了。

S4版本号与构建证据对不上

版本号差一个后缀

这条本身不算严重，但它坑了我们一次：App 里三个地方把 sdkVersion 写死成 "0.1.4" 上报给服务端，一直是错的，而且不会有任何编译错误或运行时报错。现在改成读 SomaLoop.version，并把 buildRevision 一并上报。

验收记录来自另一个构建

并且那份记录自己写着 "finished": false、failedCases: ["run_not_finished"]。45 个用例里 36 passed、7 gate_verified、1 observed、1 empty_complete。unacceptedCapabilities 列了 6 项，其中三项正好是我们要用的：manual_hrv_numeric_result、continuous_ecg、public_settings_write_api。

这不是说 SDK 有问题，是说随包交付的验收证据对应不上随包交付的二进制，我们没法用它判断手上这份能做什么。

S5两份原厂 SDK 互相矛盾

HRV 子码

Android BleSDK.SetDeviceMeasurementWithType 是显式 switch（不是枚举序号）：

HRV 对不上，而且 iOS 给 HRV 的那个 4 正好是 Android 给心电的值。我们按 Android 那份实现，因为 develop-console 跑通的是那一套；iOS 那份大概率只是没把心电列进去，顺手把号占了。这一点需要在真机上验一次，确认哪一份是对的。

时长的单位

iOS 原厂文档写：「measurementTime : 测量的时间，单位是秒，默认是 30 秒」，demo 里传 30。而 Android 的 ECG demo 传的是 (50 * 1000).toLong()，进的是同一个 byte4–5 字段。如果那也是秒，等于 13.9 小时。两边至少有一边是错的。

一个没写进 SDK 文档的前置条件

也就是说要先发 RealTimeDataWithType:1 打开实时通道，0x28 才会吐数据。L1 SDK 的文档里没有提这条。如果 measure() 内部没有替调用方做这一步，那可能正是某些「发了命令但没有回包」的原因。

S6接口缺口

没有发裸帧的公开入口

ProtocolCodec.command 是公开的、能拼出合法字节，但 SomaLoopClient 没有对应的发送 API。同时文档又要求「不要绕过后直接调用底层 transport 写入」。结果是：知道该发什么、也能拼出来，但没有合法的路把它发出去。

这一条挡住的不只是我们的 workaround。心电流也卡在同一个地方，见下。

研究流没有 duration 参数

develop-console 的实现（advanced.py:298-314）说明心电要两步：

1. write(frame(0x07, 1)) —— 开流
2. request(frame(0x28, 4, 1, 0, duration&255, duration>>8, 1)) —— 启动测量，应答判据 len == 16 && b[1] == 4

而 iOS 的 SomaLoopResearch.start(_:) 只有一个 stream 参数，没有 duration，接口是不透明的：无法判断它内部是只发了第 1 步，还是两步都发了。

• 如果两步都发了 —— 现在这样就是对的；
• 如果只开了流 —— 设备不会吐波形，而适配器没有办法自己补上第 2 步（见上一条）。

这一点我们还没在真机上验证过。

settings 写入未开放

《能力与迁移.md》：「修改时间、个人资料、自动测量、提醒、闹钟等 | 公开 API 未开放 | 6 个具体字段已在内部完成写入、回读、恢复；尚未提升为公开 setter 契约，其余字段未验证；稳定返回 unverifiedCapability」。已知、可接受，记在这里是为了清单完整。

S7语义没声明的字段

这一类不算 bug，是「固件没说，所以谁也不能编」。记下来是因为它们直接决定界面上能写什么。

S8我们为此做了什么

固件证据表

厂商把一条能力标成 experimental，含义是「厂商没验证」，不是「设备不支持」。实测发现固件 00000808 上，被标成实验的血氧一次能完整读回 714 条、HRV 600 条——数据是真的，只是不在厂商的验收清单里。

但直接把全局实验开关打开等于对所有能力一律放行，那就退回到「猜」了。所以我们逐条记：哪个固件、哪条流、什么时候、在哪台设备上、读到了什么。没有证据的一律不放行。

一个适配器文件

全 App 只有 SomaLoopL1Link.swift 可以 import SomaLoopSDK，有一条扫描源码的边界测试钉着。厂商枚举不往外跑，所以上面这些问题将来怎么变，影响面都只有那一个文件。

V8 字节层

按原厂 SDK 源码把包拼出来，纯字节、不碰蓝牙、可单测。等 L1 放开之后整体并回去，对外接口不变。目前缺的是合法的发送通道（见 S6）。

S9给 SDK 方的清单

按「挡住了什么」排序，不按修起来容易排。