GarminHealthLab

ericwyuan/GarminHealthLab

Fork 0

Commit Graph

Author	SHA1	Message	Date
ericwyuan	dd4105eb36	docs: 更新进度，记录每日/运动详情持续后台排队功能	2026-09-01 18:15:59 +08:00
ericwyuan	c57c930949	feat(ai): AI 教练 —— 晨间简报、运动处方、趋势归因与 Copilot 数值全部在服务端算好再交给模型，模型只做解读。让模型从 CSV 里自己推 z 分数，它算错的次数足以让简报引用图表反驳它的数字。 - services/insights.py：z 分数（28 天个人基线，且排除当天——用一个值参与算出来的均值去衡量它自己，会把真实离群点摊平）、13 个月趋势斜率（按序数日期最小二乘，手表放充电器上一周不会压缩 x 轴）、近 7 天活动量对比。 - services/coach.py：三套提示词 + 回复解析，每套都配一个规则引擎版本。网关一次生成要几分钟，上游被限流时给一个朴素的答案，好过给一张空卡片。 - services/ai.py：多轮 chat()、SSE stream()、complete()/stream_chat()，以及 extract_json()——上游是推理模型，可见输出以思维链开头，所以从末尾倒着找最后一个配平的 JSON（字符串感知，扛得住引号里的 } 和转义引号）。 - 接口 briefing / trend-insight / copilot(SSE)，缓存表 ai_insights。 - 前端：今日页晨报卡（后台生成 + 轮询升级）、全局 Copilot 浮窗、指标详情页归因面板。features.ai 打开。实测（对着自建 ai-gateway）：晨报一次 273 秒，缓存命中 18 毫秒——所以简报绝不能同步阻塞首屏。网关的流式通道比阻塞通道更不可靠：同一条提示词流式 139 秒后返回「所有模型均不可用」，阻塞则成功，因此 stream_chat() 在流式零输出时对同一模型退回非流式重试。Copilot 实测 TTFB 9ms、全程 40 秒。顺带修两处：refresh 原来只跳过缓存读、不删行，导致「重新生成」后的轮询读到旧行、看到 cached 就停了，用户一直盯着他刚要求替换掉的那段字；基线零方差时原来返回 z=0.0，把「和每一条观测都不同」标成「完全正常」，改为 z=null。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-01 13:57:35 +08:00
ericwyuan	15fba8c25c	feat: NAS 部署 + auth-hub 认证 + 同步逻辑修复部署: - 后端 Python/Flask，数据层可插拔 SQLite/MariaDB - NAS 部署路径 /volume1/web/garmin-health-lab，端口 8124 - Gunicorn 生产服务器 (2 workers / 4 threads) - 开机自启脚本 deploy/S99garmin.sh - frp 隧道甲骨文 8124 → NAS 8124，外网访问 - 前端构建产物纳入版本管理 (backend/static/) 认证: - auth-hub OAuth2/OIDC 统一登录接入 - 新建 NAS 专用 client，注册内外网回调地址 - 前端 LoginPage 支持回调路由 /auth/callback - 数据同步页增加 Garmin 邮箱输入框同步逻辑修复: - 自动同步调度器读取用户 history_days 设置，不再固定 2 天 - 前端 0（全部历史）不再被 \|\| 吞掉，改为 ?? 处理 - 后端路由和 sync_data 中 0 不再被当成 falsy 回退默认值 - sync_data 和调度器中 0 → 730 天（全部历史=最大范围） - 已同步天数显示数据库实际总天数 (totalDays) - 历史范围新增「自上次同步」增量选项 (days=-1) - 后端 settings.py HISTORY 添加 -1 值项目文档: - 创建 PROGRESS.md 跟踪项目进度	2026-09-01 07:39:09 +08:00

Author

SHA1

Message

Date

ericwyuan

dd4105eb36

docs: 更新进度，记录每日/运动详情持续后台排队功能

2026-09-01 18:15:59 +08:00

ericwyuan

c57c930949

feat(ai): AI 教练 —— 晨间简报、运动处方、趋势归因与 Copilot

数值全部在服务端算好再交给模型，模型只做解读。让模型从 CSV 里自己推
z 分数，它算错的次数足以让简报引用图表反驳它的数字。

- services/insights.py：z 分数（28 天个人基线，且**排除当天**——用一个
  值参与算出来的均值去衡量它自己，会把真实离群点摊平）、13 个月趋势斜率
  （按序数日期最小二乘，手表放充电器上一周不会压缩 x 轴）、近 7 天活动量
  对比。
- services/coach.py：三套提示词 + 回复解析，每套都配一个规则引擎版本。
  网关一次生成要几分钟，上游被限流时给一个朴素的答案，好过给一张空卡片。
- services/ai.py：多轮 chat()、SSE stream()、complete()/stream_chat()，
  以及 extract_json()——上游是推理模型，可见输出以思维链开头，所以从末尾
  倒着找最后一个配平的 JSON（字符串感知，扛得住引号里的 } 和转义引号）。
- 接口 briefing / trend-insight / copilot(SSE)，缓存表 ai_insights。
- 前端：今日页晨报卡（后台生成 + 轮询升级）、全局 Copilot 浮窗、指标详情
  页归因面板。features.ai 打开。

实测（对着自建 ai-gateway）：晨报一次 273 秒，缓存命中 18 毫秒——所以简报
绝不能同步阻塞首屏。网关的流式通道比阻塞通道更不可靠：同一条提示词流式
139 秒后返回「所有模型均不可用」，阻塞则成功，因此 stream_chat() 在流式零
输出时对同一模型退回非流式重试。Copilot 实测 TTFB 9ms、全程 40 秒。

顺带修两处：refresh 原来只跳过缓存读、不删行，导致「重新生成」后的轮询读
到旧行、看到 cached 就停了，用户一直盯着他刚要求替换掉的那段字；基线零方差
时原来返回 z=0.0，把「和每一条观测都不同」标成「完全正常」，改为 z=null。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-09-01 13:57:35 +08:00

ericwyuan

15fba8c25c

feat: NAS 部署 + auth-hub 认证 + 同步逻辑修复

部署:
- 后端 Python/Flask，数据层可插拔 SQLite/MariaDB
- NAS 部署路径 /volume1/web/garmin-health-lab，端口 8124
- Gunicorn 生产服务器 (2 workers / 4 threads)
- 开机自启脚本 deploy/S99garmin.sh
- frp 隧道甲骨文 8124 → NAS 8124，外网访问
- 前端构建产物纳入版本管理 (backend/static/)

认证:
- auth-hub OAuth2/OIDC 统一登录接入
- 新建 NAS 专用 client，注册内外网回调地址
- 前端 LoginPage 支持回调路由 /auth/callback
- 数据同步页增加 Garmin 邮箱输入框

同步逻辑修复:
- 自动同步调度器读取用户 history_days 设置，不再固定 2 天
- 前端 0（全部历史）不再被 || 吞掉，改为 ?? 处理
- 后端路由和 sync_data 中 0 不再被当成 falsy 回退默认值
- sync_data 和调度器中 0 → 730 天（全部历史=最大范围）
- 已同步天数显示数据库实际总天数 (totalDays)
- 历史范围新增「自上次同步」增量选项 (days=-1)
- 后端 settings.py HISTORY 添加 -1 值

项目文档:
- 创建 PROGRESS.md 跟踪项目进度

2026-09-01 07:39:09 +08:00

3 Commits