不做手机缩小版：AI 健康记录迁到手腕，要跨过哪些工程鸿沟？

过去一年，AI 应用又往前走了一截。Coding Agent 已经开始自己拆任务、调用工具，手机里的助手也越来越像一个能办事的角色。发布会上的演示总是流畅，但到了日常生活里，许多 AI 产品仍然要等用户想起它，再打开它。 健康管理尤其容易卡在这一步。当你把一顿午饭吃完，打开某个健康管理的 App，先选餐次，再搜索牛肉面，估一下份量，再补上一杯奶茶，这是目前手机记录的详细链路。目前，健康管理的食物库已经非常全，甚至细化到某个品牌的包子和馅料，热量也算得越来越细，健康管理行业卷成了红海，但是健康管理发力的方向，真的对了吗？ 不管 list 再细分，只要按照上述的链路跑，再事无巨细，我们还是会漏记，等到了晚上再回想午餐，一碗面的大小、奶茶喝了多少，往往只剩一个含糊和模糊印象。 HarmonyOS 的穿戴应用「小卡健康」，团队的 3 名 00 后女生开发者，自身经历过减脂、体重反复，切身体会过这套记录流程的负担。而她们给出的解法是把健康记录的入口迁移到手表之上。 抬腕，通过表冠或者智慧手势唤起录音，口述一句 “中午吃了一碗牛肉面，还喝了一杯奶茶”，整条记录流程就此结束。表面看只是减少了几次点击，背后却要串联语音采集、AI 语义解析、健康数据管理、传感器感知、手机手表跨端通信一整套复杂链路。 除了小卡健康实现的 AI 语音健康记录与分析，「开练」「凯格尔运动」两款应用，则演示了同一套底层能力，如何适配真实的运动训练场景。 为完成这样的腕上体验，项目主要依托四大系统 Kit 构建完整业务链路： Core Speech Kit：http://gk.link/a/12LxVHealth Service Kit：http://gk.link/a/12LxWSensor Service Kit：http://gk.link/a/12LxXWear Engine Kit：http://gk.link/a/12LxZ 完备的架构图不等于可用的产品。权限管控、蓝牙断连、息屏后台限制、多设备差异，都是横亘在接口与用户体验之间的现实障碍。小团队究竟如何跨过这些工程鸿沟？ 1 几个年轻人，为什么把健康管理搬到手腕上 小卡健康起源于几名 00 后实习生的真实生活痛点：步入职场之后体重上涨，多次开启减脂计划，又多次中断。项目并非源于行业趋势推演，而是从日常需求中生长出来。 小团队模式下，产品、客户端、AI 开发的边界相对模糊，一个功能从想法到上线，往往需要全员参与。最开始团队思考的是：手表还能再多展示哪些内容？真正动手之后才意识到，更重要的是，哪些内容应该拿掉。 手机端复杂食谱、长篇营养报告、大段 AI 对话，并不适合手表狭小屏幕；而热量缺口、当日步数、饮水、体重这类一眼可读的指标，以及语音记录、运动陪练这类“手上没空拿手机” 的场景，才更适配穿戴形态。 “最初做穿戴版时，比较难的应该是‘显示什么对手表用户最有用’。”团队后来这样回忆。这个问题没有一次性解决。功能做出来经过了非常多的调整和优化，内容不断被删除，页面层级需要变浅，按钮需要更靠近表冠和手势，AI 给出的长段分析也必须缩短。手表上的信息应该一眼可读，操作最好一步完成。最后形成的产品形态，和手机端已经不只是尺寸区别。 手表与生俱来的随身属性，带来了手机无法实现的价值：饮食、运动发生的当下就可以完成记录，不再依靠夜晚回忆补录，数据完整性更高，用户操作负担大幅降低。 这一产品判断，决定了后续所有技术的组合逻辑：语音响应要足够快、健康数据可以互相关联、运动过程能够持续感知，即便手机不在身边，本地记录也不能丢失。 2 三个腕上场景，怎样调用系统能力 从一句话记饮食开始，看完整链路怎么跑 小卡健康给出的另一条示例语音更复杂：“早餐吃了一个鸡蛋，喝了两杯水，做了 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 次组间切换。开练把训练前的计划制定和训练后的复盘留给手机，手表则负责现场流程。用户可以临时修改