(文章来源：InfoQ，作者 | 希希子)

过去一年，AI 应用又往前走了一截。Coding Agent 已经开始自己拆任务、调用工具，手机里的助手也越来越像一个能办事的角色。发布会上的演示总是流畅，但到了日常生活里，许多 AI 产品仍然要等用户想起它，再打开它。

健康管理尤其容易卡在这一步。当你把一顿午饭吃完，打开某个健康管理的 App，先选餐次，再搜索牛肉面，估一下份量，再补上一杯奶茶，这是目前手机记录的详细链路。目前，健康管理的食物库已经非常全，甚至细化到某个品牌的包子和馅料，热量也算得越来越细，健康管理行业卷成了红海，但是健康管理发力的方向，真的对了吗？

不管 list 再细分，只要按照上述的链路跑，再事无巨细，我们还是会漏记，等到了晚上再回想午餐，一碗面的大小、奶茶喝了多少，往往只剩一个含糊和模糊印象。

HarmonyOS 的穿戴应用「小卡健康」，团队的 3 名 00 后女生开发者，自身经历过减脂、体重反复，切身体会过这套记录流程的负担。而她们给出的解法是把健康记录的入口迁移到手表之上。 抬腕，通过表冠或者智慧手势唤起录音，口述一句 “中午吃了一碗牛肉面，还喝了一杯奶茶”，整条记录流程就此结束。表面看只是减少了几次点击，背后却要串联语音采集、AI 语义解析、健康数据管理、传感器感知、手机手表跨端通信一整套复杂链路。

除了小卡健康实现的 AI 语音健康记录与分析，「开练」「凯格尔运动」两款应用，则演示了同一套底层能力，如何适配真实的运动训练场景。 为完成这样的腕上体验，项目主要依托四大系统 Kit 构建完整业务链路：

· Core Speech Kit

· Health Service Kit

· Sensor Service Kit

· Wear Engine Kit

完备的架构图不等于可用的产品。权限管控、蓝牙断连、息屏后台限制、多设备差异，都是横亘在接口与用户体验之间的现实障碍。小团队究竟如何跨过这些工程鸿沟？

01、几个年轻人，为什么把健康管理搬到手腕上

小卡健康起源于几名 00 后实习生的真实生活痛点：步入职场之后体重上涨，多次开启减脂计划，又多次中断。项目并非源于行业趋势推演，而是从日常需求中生长出来。

小团队模式下，产品、客户端、AI 开发的边界相对模糊，一个功能从想法到上线，往往需要全员参与。最开始团队思考的是：手表还能再多展示哪些内容？真正动手之后才意识到，更重要的是，哪些内容应该拿掉。

手机端复杂食谱、长篇营养报告、大段 AI 对话，并不适合手表狭小屏幕；而热量缺口、当日步数、饮水、体重这类一眼可读的指标，以及语音记录、运动陪练这类“手上没空拿手机” 的场景，才更适配穿戴形态。

“最初做穿戴版时，比较难的应该是‘显示什么对手表用户最有用’。”团队后来这样回忆。这个问题没有一次性解决。功能做出来经过了非常多的调整和优化，内容不断被删除，页面层级需要变浅，按钮需要更靠近表冠和手势，AI 给出的长段分析也必须缩短。手表上的信息应该一眼可读，操作最好一步完成。最后形成的产品形态，和手机端已经不只是尺寸区别。

手表与生俱来的随身属性，带来了手机无法实现的价值：饮食、运动发生的当下就可以完成记录，不再依靠夜晚回忆补录，数据完整性更高，用户操作负担大幅降低。 这一产品判断，决定了后续所有技术的组合逻辑：语音响应要足够快、健康数据可以互相关联、运动过程能够持续感知，即便手机不在身边，本地记录也不能丢失。

02、三个腕上场景，怎样调用系统能力

从一句话记饮食开始，看完整链路怎么跑

小卡健康给出的另一条示例语音更复杂：“早餐吃了一个鸡蛋，喝了两杯水，做了 30 个深蹲、60 个高位下拉，帮我分析一下今天的状态。”正常人说话时，不会在食物、饮水、运动和分析请求之间停下来等软件填完表格。这些信息挤在一句话里，整条业务链路需要完成：声音采集-语音转写-语义解析-数据关联-跨端同步-结果反馈，多个环节互相耦合。

· Core Speech Kit（http://gk.link/a/12LxV ）

先接住声音。开发者创建语音识别引擎，通过回调获得实时转写、识别状态和错误，不必从头搭一套录音上传与识别服务。系统接口省下了基础工作，腕上的异常仍然要由产品处理：餐厅背景声、跑步机噪声、用户说到一半停顿，甚至抬腕后没有马上开口，都可能使一次录音结束得太早或者没有结果。

小卡健康还把录音确认放进了“智慧手势”。用户可以通过拇指和食指快速触碰完成确认，再通过辅助动作切换“确定”或“取消”的焦点。吃饭时另一只手可能拿着餐具，运动时也未必方便在圆形小屏上找按钮，这个交互减少了一次精确触摸。

语音服务完成听写，后面才轮到 AI。“一个鸡蛋”需要匹配食物库，“两杯水”要落到饮水量，30 个深蹲和 60 个高位下拉属于两个运动条目，最后一句还带着分析意图。用户换一种说法，字段位置也会跟着变。团队没有披露模型参数和评测结果，现有资料能确认的是，产品已经把录音、AI 分析、结果生成和确认连成一条表端流程，并称可以识别饮食、饮水、运动等十余类口述信息。

解析后的记录要放进健康上下文。

· Health Service Kit（http://gk.link/a/12LxW）

开放日常活动、心率、睡眠和锻炼记录等数据，应用先申请服务和数据范围，再交由用户手动完成授权。受到权限审批进度约束，小卡健康当前仅仅可以读取步数、历史记录，实现基础的数据同步。而距离、热量，健康、体脂、营养、心率、压力、睡眠等多维度数据，还处在申请流程当中。另外，产品的功能规划也因为权限受到限制：AI 营养师想要结合完整身体指标给予个性化建议，但现阶段只能基于已获批的数据能力做落地，部分设想中的体验还停留在规划阶段：

· 语音记录——已上线

· 小艺调用小卡健康 Agent——处在沟通与 Demo 验证阶段

· 跳绳、哑铃、开合跳、深蹲——后续迭代

开发过程中需要清晰区分已经上线、测试中、待申请的不同能力，不能把规划中的功能当作成品。同时按照官方协议要求，经由 Health Service Kit 获取的数据，仅可以在用户授权范围内读写，不能用作医疗诊断依据。记录完成以后，手表端不适合铺开一份很长的营养报告。小卡健康主要展示识别结果和简短建议，详细趋势留给手机。另一方面，小卡在识别“尚在处理、数据还未同步”或“某一项内容读取不到”，页面也会给出当前状态分布。而对用户来说，他只是在等一句“已经记下”，前面的几层能力是否顺畅，都集中在最后的几秒里了。

同一套底层能力，到了训练现场有了另一种用法

“开练”团队里有一名开发者自己练力量。他反馈：以前用手机记，每完成一组就拿起来点一下，偏偏这时候正好进入休息，手指常常顺势打开短视频。计划休息 60 秒，等他回过神，时间已经过了。手表端做出来以后，完成一组只需要抬腕确认，倒计时结束，手腕振一下。他说：“整个过程终于不需要再打开手机，我可以把注意力全部留在训练本身。”

健身人一次包含 4 个动作、每个动作 4 组的训练，会出现 16 次组间切换。开练把训练前的计划制定和训练后的复盘留给手机，手表则负责现场流程。用户可以临时修改本次重量和次数，但不覆盖手机上的原计划；提前结束时要二次确认，只保留已经完成的有效记录。

· Wear Engine Kit（http://gk.link/a/12LxZ）

在这里承担跨端连接。开练针对不同信息类型设计了差异化传输策略：训练开始、暂停、完成一组，像这类实时性强的简短事件，采用即时消息通道快速双向通知；而包含动作、组数、重量、次数的完整训练计划与最终结果，则采用文件传输模式保障整套数据结构完整可靠。

训练中点一次暂停，另一端需要尽快知道；整份计划则要保证字段完整。而两种通道的分工来自业务节奏，并不是把文档里的接口各用一次。当健身者的手机断开以后，开练把训练计划、当前进度和待发送结果保存在本地文件及 Preferences 中，已经开始的训练可以在表端继续。保证“离线或断连时暂停参数编辑，但用户仍可继续或结束训练。”只有把双端都能改的部分先停下来，才能保证训练本身不中断，完成记录等连接恢复后再传。

凯格尔运动使用了相似的通信和振动能力，场景更私密。用户在手机端选好课程，训练开始后，手表用不同振动区分收缩、放松、休息和阶段切换。盆底肌训练可能发生在办公室的空隙，一直盯着手机显得奇怪，外放声音也不合适。团队没有在表端塞进很多数据，用户需要时看一眼剩余时间和进度，其他时候跟着手腕上的提示完成训练。

Sensor Service Kit（http://gk.link/a/12LxX）则让训练应用进一步读取身体与动作信号。开练也负责监听实时心率；监听失败或出现无效值时，页面显示 --。

除了以上完整链路，小卡健康后续也计划用加速度计、陀螺仪、心率和端侧模型识别更多动作。

对用户来说，如果你的手表戴得松一点，或者换到另一只手、再或者用户动作幅度小一些，波形都会变化；但采样开得太勤，又会增加耗电，应用需要在训练开始后开启监听，暂停或退出时及时停止，再用真机覆盖不同人群和佩戴方式，未来才能覆盖更多人的需求和生活方式。

03、从接口可用到产品可用，工程问题都藏在哪里

接口虽然可用了，并不代表使用没有任何问题。

当四类 Kit 把语音、健康数据、传感器和通信能力开放出来后，这个小团队并不再用从录音引擎、设备发现或底层硬件通道开始写入。但项目进行到最后，时间可能还是会消耗在接口之间：

· 一次语音里混着多个记录，已经上线的分析只能使用获批数据；

· 训练事件和整份计划分开传，断连时先把结果留在手表；

· 后台提醒可能受系统策略影响，页面还要记住倒计时走到了哪里。

开练早期的一次适配失败，把这个差距暴露得更明显。团队把智能手表上的复杂页面直接移到运动手表，结果页面无法正常显示，完整训练流程也跑不稳。通过排查后，团队不仅减少了单页元素，还需要拆分复杂页面，降低图片和动画资源占用，再调整数据加载、内存和状态保存。

团队后来总结：“跨设备的一致体验，不等于在不同设备上使用完全相同的界面和实现；真正的一致，是用户在不同设备上都能稳定、顺畅地完成相同的核心任务。”智能手表可以保留动作图和较完整的编辑面板，资源更紧的运动表先把开始、完成、休息、结束和同步做好。

圆形屏幕也要求另一套操作方式。开练充分利用手表表冠能力，用户转动表冠就可以滚动浏览训练计划、查看详情或是调整训练参数。力量训练时，用户手上往往还握着器械，旋转表冠相比在狭小圆形屏幕上精准点击，操作门槛更低。与此同时，开发们也需要处理不少细节问题：按钮焦点如何跟随画面的滚动变化、画面滚动到健康页面后，如何最便捷的给到用户反馈，如何规避用户误触，每一处都需要单独打磨。

后台运行同样不是把任务扔给系统就结束。开练通过 Background Tasks Kit 发布休息结束提醒，再用 Notification Kit 检查通知通道。设备设置、省电策略和系统状态都可能影响触达，所以训练进度仍要保存在本地，用户重新进入页面后能回到接近离开前的位置。用户看到的是一次振动，开发侧需要同时照看倒计时、页面生命周期和记录写入。

测试指标也要跟着场景走。语音记录需要观察从开口到结果等了多久、解析后改了几次；跨端训练要确认过程消息有没有漏掉，整份结果是否回传，断连后能不能恢复；设备侧还要测首屏、页面切换、峰值内存和一段完整训练的耗电。小卡健康超慢跑功能月度参与人数从不足 200 增长至 10000+，即便数据向好，上线前仍要严格核对统计口径，这个变化至少给团队一个信号：训练入口放到手表以后，用户的使用频次可能随之变化。

标准化接口确实降低了起步成本，产品能不能长期运行，还要看团队是否把噪声、息屏、断连、权限变化和设备差异一项项测过。很多工作不会出现在演示视频里，却会决定用户在一次失败之后还愿不愿意再试。

04、抬腕即交互：看腕上 AI 的落地机遇与现实边界

小卡健康、开练和凯格尔运动没有把手机端完整复制到手表。吃饭时用语音记下一餐，做完一组训练后抬腕确认，盆底肌训练时跟着振动切换阶段，这些动作短，也都有明确的发生时机，但食谱、长报告、计划管理和复盘报告仍然回归到手机侧，不是所有功能都适合于手表，也不是所有功能都要从手机取消。

小卡健康团队还是希望手表在用户正在运动和生活时，能够给一个“刚刚好、不多不少的反馈”，现在看，这个尺度还在调整，或许这个调整未来也会不断进化，但改变的终点永远是为用户服务。小卡健康的语音记录已经上线，更多健康数据、运动识别和 Agent 联动仍要经过测试、权限申请和审核；开练的实时心率也要等待最终版本。开发者能调用的系统能力越来越多，未来产品仍要在每一项具体限制里做选择。

用户不会看到这些材料里的接口列表。他吃完一碗面，或者刚放下杠铃，愿意抬起手腕，通常只是想少做几步。

但，一句话记录有没有被手表听懂，手机断开后是否还在，振动有没有在该来的时候稳定出现，最后决定了下一次他还会不会继续使用。