台风天宅家，用 AI 把运动 App 改造成支持华为 Watch GT5

第 13 号台风”白海豚”的周末，外面风大雨大，哪儿也去不了。索性窝在家里，把上半年写的一个运动 App 拿出来折腾——目标很明确：让它能连上我的华为 Watch GT5 手表，同时把原版 App 那堆广告和混乱的信息全部清掉。

为什么要重做

上半年我开发了一个运动记录 App（RUNNINGGO），骑行、跑步、心率带都能用，但一直有个遗憾：它连不上我的华为手表。手表上的心率、血氧、体温、HRV、睡眠这些数据，官方 App 能看到，但广告太多、信息太乱，我想要一个干净、专注的记录工具，把运动数据统一收进来，再同步到自己的后端，随时在网页上看趋势。

技术路线：Gadgetbridge + 只移植华为模块

华为手表的蓝牙私有协议没有公开文档，从零逆向工作量太大。好在有个开源项目 Gadgetbridge，已经把市面上大多数手环/手表的连接协议都实现了，其中就包括华为 Watch GT 系列的连接、配对手册和数据字典同步。

所以我的方案是：基于 Gadgetbridge，只把华为相关的模块移植进来，其它品牌全部不要。具体包括：

• 蓝牙连接与自动重连（记住上次配对的设备，断线自动回连）
• P2P 数据字典同步：心率、血氧、体温、HRV、情绪、睡眠、每日状态
• 运动记录导入：汇总 → 详情 → 配速 → GPS 轨迹
• 手表设置下发：心率实时检测、睡眠监测、体温测量等开关

这样既不用从零啃协议，也不会被 Gadgetbridge 里其它几十个品牌的代码拖累，包体和逻辑都保持精简。

两个 AI 结对干活

这次改造我同时用了 DeepSeek-V4-Flash 和 Kimi 两个模型，分工协作：

• 一个负责协议解析和后台逻辑：华为数据字典的字段解析、按小时/按天的去重入库、运动记录合并，这种”啃代码”的活它干得很稳
• 一个负责 UI 和交互：卡片布局、图表、设置页面，以及各种边角 bug 的排查

实测下来，两个模型互补性很强。遇到协议解析卡住时，换一个模型换个思路，往往就有进展；UI 上的细节问题，另一个模型一眼就能看出来。这种”双模型结对”的开发方式，比单打独斗效率高不少。

AI 运动建议的后端实现

除了 App 端，我还给这套体系配了一个 Go 后端（blog_api，Gin 框架），专门负责生成 AI 运动建议：

1. 接口：GET /api/v1/workouts/advice?days=7，带 IP 限流，App 首页的卡片直接调它，支持 7 天 / 30 天切换
2. 输入聚合：把近 N 天的运动数据（次数、总里程、总时长、平均心率、运动类型分布、逐条记录摘要）和当日健康数据（HRV、体温、静息心率、呼吸率、体重、血糖、睡眠时长，没有当天数据时自动回退到最新一条）打包给 AI
3. 生成建议：通过 OpenAI 兼容协议调用 DeepSeek（deepseek-chat），输出结构化的总体评价、运动分析、健康指标、恢复状态、关注提醒和运动建议
4. 恢复状态对比：AI 会把今日 HRV、静息心率、睡眠与近 N 天均值对比，比如”今日 HRV 47ms，低于近 7 天均值 59ms，睡眠不足，建议低强度恢复训练或休息”
5. 缓存：结果最长缓存 12 小时，避免每次进首页都重复调用模型

这样一来，App 首页的 AI 运动建议卡片背后是完整的”数据聚合 → 大模型分析 → 缓存下发”链路，7 天和 30 天两个视角随时切换。

改造后的样子

数据链路打通之后，App 变成了一个纯粹的记录工具：

• 首页：今日里程、消耗、步数、本周负荷、心率、睡眠、血氧，一眼扫完
• 运动统计：本周/本月/本年汇总、本周消耗柱状图、运动日历，干净利落
• 数据同步：所有健康数据 1 分钟同步一次，App 退到后台也有前台服务持续上报，失败自动重试
• 网页端：数据同步到自己的后端，博客上也能看到心率 24 小时/7 天/30 天的趋势

下面是改造过程中的一些截图（可左右滑动/点击箭头查看）：

小结

台风天在家折腾了一天，收获挺大：

1. 开源项目是捷径：Gadgetbridge 这种长期维护的开源协议库，比从零逆向靠谱得多，移植时只取自己需要的模块，干净利落
2. AI 结对是趋势：DeepSeek-V4-Flash 和 Kimi 配合，一个啃协议一个调 UI，一天就能完成原本要一周的改造
3. 数据要掌握在自己手里：官方 App 广告多、信息乱，自己把数据收回来，想看趋势随时看，想怎么展示怎么展示

台风总会过去，但这套运动数据体系，应该能陪我很久。