无手机跑步，说话记饮食：这两个手表开发难度有多大？小卡健康怎么做到？

腕上的一天

早上八点，用户对着早点拍了张照片。

小卡健康在十五秒左右给出结果：约 63.6 千卡，同时计算好蛋白质、碳水、脂肪等三十多项营养素指标。这种识别的原理很好理解，通过数十万级的食物大数据，就可以估算分量。

中午在工位，抬起手腕说句「午饭吃了牛肉面」，手表直接把这条饮食记下来，不用再像图片中那样掏手机或者打字，看起来是不是方便了一些？

晚上九点，只戴手表出门，手机留在家里，直接在手表上启动「超慢跑」。手表按黄金减脂步频引导，心率或步频一旦偏离区间，微振动和音频节拍器马上就能把他拉回节奏。跑完回家，手机迅速触发运动数据传输，打开app就能发现和当天的热量、体重、步数、喝水记录排在一起。

带人健身跟练的开练、提醒利用碎片时间训练的凯格尔运动，也在同一批鸿蒙穿戴应用中。腕上健康这个品类，在鸿蒙生态中一天天热闹起来。

其中任何一个项目单独来看，几年前中小团队都不太会碰的。相关专业技术人员数量不算多，调试能力也有限，这些环节过去一直会卡住穿戴应用的创新速度。现在鸿蒙把这些偏底层的技术要求做成了现成的 Kit，交给开发者到手就能用。

穿戴开发难在哪？

穿戴应用的数量远不如手机应用，门槛的位置不一样是关键原因。

其实数十年来，各种工具一直不断降低软件开发的门槛，提升软件开发的效率。尤其是AI ，几乎算是把前端开发破解了，生成网页、做临时的小工具越来越容易，不靠专业团队的人也能做出软件产品，至少表面上看得过去。但硬件相关的场景没被完全破解。穿戴设备要处理的是硬件设备调试，嵌入式技能相关的内容，在各地区都需要专门培养相关开发人员：手表和手机之间的通信、传感器的采样调度、嵌入式环境下的调试，相关人员大多被大厂招揽或者由部分专业厂商把持。写代码这道门槛确实降低了，调试硬件的门槛依然存在。一部分在大厂看来可以花点代价解决的问题对于小厂难度会高很多，初创企业很难招到合适的人才完成相关任务。

传统穿戴开发至少要跨过下边几道坎。

传感器。不同手表型号的传感器接口不一致，心率、加速度、陀螺仪各有各的取法。采样频率开高了耗电，开低了数据不够用，还要开发者自己处理后台保活。

跨端协同也麻烦。「手机下发训练计划、手表独立运行、数据再回传手机」这条链路，自己写就要直接面对蓝牙底层：连接稳定性、消息时序、断线重连、电量控制，每一道异常处理的研发开销都远大于正常流程，哪一环出问题都能让项目延期。

再来看健康数据。睡眠、心率、体重这类数据高度敏感，自己存储就要考虑手机厂商对数据安全有合规性要求，不同设备的数据格式也不一定统一；自建一套数据中心吧，虽然服务器管理团队以及数据中心对大厂来说是标配，小团队恐怕很难承受这种成本。

最现实的困境，是这些坎叠加在小团队身上：底层基建没做完，预算人力先耗光。细分场景的创新其实早就有人想到，但许多人要么没能活到上线那一天，要么发现已经被其它团队抢先。

鸿蒙的答案，是四个 Kit

鸿蒙给出的解法，是把这几道坎拆成四套标准化的 Kit：底层最难的部分由系统侧实现、调稳，开发者按统一接口调用。

可以在HarmonyOS 穿戴设备应用开发介绍中查看

健康数据这道坎，对应 Health Service Kit（手机端）：

它基于华为账号做授权，一次授权，应用就能读写步数、心率（含 HRV）、睡眠、压力、体重、热量等运动健康数据。开发者不用自建数据中枢也不用操心存储合规，数据的敏感性和多设备格式问题都不用自己处理。小卡健康用它同步体重、步数、热量，再把睡眠、压力、HRV 数据读出来做联合分析。

跨端通信对应 Wear Engine Kit（手机手表互通）：

把查询已连接的穿戴设备、应用间消息通信、状态查询订阅这些都做成了现成的接口。也就省掉自己调试蓝牙协议的步骤。以小卡的超慢跑为例：在手机上制定训练计划，通过 Wear Engine 下发到手表，手表独立运行，数据再沿同一条管道回传。

传感器层，Sensor Service Kit（手表端）：

统一封装心率、步频、加速度、陀螺仪，一并开放振感控制，交由系统管理采样调度与功耗平衡。小卡超慢跑通过它实现实时纠偏，持续订阅心率和步频，一旦偏离黄金减脂区间，立刻触发振动与节拍器提示。

语音识别可以走 Core Speech Kit（手机端）：

这个Kit提供语音识别（ASR）与文本转语音（TTS）两类基础 AI 能力，识别在设备本地完成，不依赖网络。不过这个功能按照官方API并不支持手表端。因而，手表端「说一句话记下饮食」的实现方式我专门研究了一下：手表只负责收音，语音经蓝牙送到手机，由手机端的语音助手完成识别，再把结果回传到手表上。手表不必自己跑语音识别。在手表上直接体验手机的能力，也算是一种分工。

把四个 Kit 放在一起，会发现一个细节：它们分属不同的端。手表端跑传感器订阅，手机端做健康数据归档和语音识别，Wear Engine 作为管道连接两端，最终用户层面看到了手机以及手表上的热量、体重、步数、喝水卡片展示。

小卡健康怎么用起来

产品里应用Kit的体验如何？看小卡健康的两条实际链路。

语音记饮食：用户对手表说「中午吃牛肉面」，手表收音，由蓝牙送语音到手机，手机端的语音助手识别内容，再经过app解析出食物与分量，把结果回传到手表上确认。最后，手机热量账本上已经多了一行，手表上的热量已经改变。整条链路里，开发者不用接语音 SDK，不用自建数据后端，也不用操心合规存储；饮食热量由小卡自己的食物库算出，再通过 Wear Engine 在手机与手表之间同步。这套流程放在过去是几个月的集成量，现在调用几个系统能力就可以。

手表独立超慢跑的链路大约是这样：手机端制定训练计划，经 Wear Engine 下发到手表；手表脱离手机独立拉起训练，Sensor Service Kit 持续订阅心率与步频；一旦偏离黄金减脂区间，振感与音频节拍器实时纠偏；训练结束，数据沿原路回传，同步到手机端，与健康数据摆在一起。传感器实时调度、跨端通信、低功耗运行，这三件过去比较难做稳，在这条链路里由系统能力承担。

这套底层组合并不止小卡在用。开练与凯格尔运动走的是同一套组合——Health Service Kit 加 Wear Engine Kit；一个做健身跟练与训练记录，一个做盆底肌训练与定时提醒。它们背后的开发团队也不是什么巨头：不到两百人的队伍，做了 20 多款应用，累计用户超过 5000 万。同样的 Kit，不同团队用出了不同的细分场景，这套底层能力谁都能用，不归大厂独占。

写代码不是门槛了，那门槛在哪？

写到这里，顺手做个实验：前文说AI 几乎把前端开发破解了，那放到穿戴硬件上，这套说法还成立吗？

我在 DevEco Code 里扔了个prompt：「在当前目录创建一个用于鸿蒙穿戴设备的项目，参考目前可用的虚拟设备的版本。搭载 Health Service Kit、Wear Engine Kit、Sensor Service Kit、Core Speech Kit。」

生成开始后，第一轮编译就报错了，但DevEco Code 自己改了几轮，到编译跑通才停手，我原本以为这个过程需要更多提示才能把配置搞定，没想到十几分钟就完成了。随后我让它启动了模拟器运行。

当然跑起来不一定就能用，界面套了手机布局，没适配手表圆形表盘，健康服务初始化也漏了，按照提示解决了这两处小问题。改完，项目正常运行。

回头看这两处问题：一个是 UI 适配，一个是初始化配置。没有蓝牙断连与传感器时序问题，也没有嵌入式调试。如果让 AI 对着裸的蓝牙协议和传感器底层接口生成，代码看上去都对，一跑全是坑，断连时序、消息重排、型号怪癖，硬件调试的轮回会一个不漏地回来。

一句话生成项目，这种事能成立的前提，是这些 Kit 已经存在。API收敛得相对干净优雅，难的部分在系统侧解决之后，AI 生成代码才能更稳。

Kit其实是AI效率的前提，不会被 AI 淘汰。

「开发易」其实就是这样：复杂度不会凭空消失，只会转移。自己写底层，就是每个团队各踩一遍坑、各付一遍调试成本；用 Kit，平台先调试稳定，后面的开发者直接用现成。对小团队来说，这笔账可能直接决定生死。而且 Kit 除了把旧功能做得更稳，还让「手表端语音记饮食」「脱手机超慢跑」这些原本不存在的体验成为可能，这就是差异化的空间。

当然，我还是自己修了两处问题才跑起来项目。Kit 大幅降低了底层调试成本，但该调试的地方一样省不掉，业务逻辑仍要自己打磨。生态窗口也不承诺成功，它把试错成本降到小团队能承担的水平，在供给尚稀缺的鸿蒙穿戴赛道，这就是小团队占住生态位的时间窗口。

穿戴应用创新的下一步，从比拼硬件理解到比拼用户场景理解。鸿蒙试图修通这条路，让小而美的团队也能开发出局部爆款。

如果对这几个 Kit 感兴趣，可以看看HarmonyOS 穿戴设备应用开发入门的介绍，里面有完整引导：

手表上这块屏幕还空着很多位置，懂场景的人可以大有作为。